From issues at jboss.org  Sat Oct  1 01:42:00 2016
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Sat, 1 Oct 2016 01:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not
 being created
In-Reply-To: <JIRA.12652843.1475249181000@Atlassian.JIRA>
References: <JIRA.12652843.1475249181000@Atlassian.JIRA>
	<JIRA.12652843.1475249181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652843.1475249181000.45716.1475300520502@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated WFLY-7247:
-------------------------------
    Component/s: Web (Undertow)


> Wildfly 10 JSESSIONIDSSOs not being created
> -------------------------------------------
>
>                 Key: WFLY-7247
>                 URL: https://issues.jboss.org/browse/WFLY-7247
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: M Wardell
>            Assignee: Jason Greene
>
> Found on wildfly 10.1 and 10.0.  With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism.  Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service.
> Issue in intermittent on startup.  After most startups the JESSSIONIDSSO is reliably generated during login.  After some startups the JSESSIONIDSSO is never created after login.
> Details in the referenced forum thread.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  1 01:49:00 2016
From: issues at jboss.org (Jive JIRA Integration (JIRA))
Date: Sat, 1 Oct 2016 01:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not
 being created
In-Reply-To: <JIRA.12652843.1475249181000@Atlassian.JIRA>
References: <JIRA.12652843.1475249181000@Atlassian.JIRA>
	<JIRA.12652843.1475249181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652843.1475249181000.45721.1475300940196@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jive JIRA Integration updated WFLY-7247:
----------------------------------------
    Forum Reference: https://developer.jboss.org/message/962289#962289, https://developer.jboss.org/message/963592  (was: https://developer.jboss.org/message/963592)


> Wildfly 10 JSESSIONIDSSOs not being created
> -------------------------------------------
>
>                 Key: WFLY-7247
>                 URL: https://issues.jboss.org/browse/WFLY-7247
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: M Wardell
>            Assignee: Jason Greene
>
> Found on wildfly 10.1 and 10.0.  With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism.  Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service.
> Issue in intermittent on startup.  After most startups the JESSSIONIDSSO is reliably generated during login.  After some startups the JSESSIONIDSSO is never created after login.
> Details in the referenced forum thread.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  1 08:33:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 1 Oct 2016 08:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-522) Add callbacks for persisting
 and restoring a SecurityIdentity
In-Reply-To: <JIRA.12618003.1462287278000@Atlassian.JIRA>
References: <JIRA.12618003.1462287278000@Atlassian.JIRA>
	<JIRA.12618003.1462287278000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618003.1462287278000.45751.1475325180446@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-522.
----------------------------------
    Fix Version/s: 1.1.0.Beta10
                       (was: 1.1.0.Beta11)
       Resolution: Done


> Add callbacks for persisting and restoring a SecurityIdentity
> -------------------------------------------------------------
>
>                 Key: ELY-522
>                 URL: https://issues.jboss.org/browse/ELY-522
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Pedro Igor
>            Priority: Critical
>             Fix For: 1.1.0.Beta10
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  1 11:55:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Sat, 1 Oct 2016 11:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7250) Infinispan subsystem does not
 expose a proper capability contract
In-Reply-To: <JIRA.12652905.1475337258000@Atlassian.JIRA>
References: <JIRA.12652905.1475337258000@Atlassian.JIRA>
	<JIRA.12652905.1475337258849@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652905.1475337258000.45787.1475337300543@Atlassian.JIRA>

Paul Ferraro created WFLY-7250:
----------------------------------

             Summary: Infinispan subsystem does not expose a proper capability contract
                 Key: WFLY-7250
                 URL: https://issues.jboss.org/browse/WFLY-7250
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  1 11:56:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Sat, 1 Oct 2016 11:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7251) Clustering API does not
 expose a proper capability contract
In-Reply-To: <JIRA.12652906.1475337333000@Atlassian.JIRA>
References: <JIRA.12652906.1475337333000@Atlassian.JIRA>
	<JIRA.12652906.1475337333224@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652906.1475337333000.45803.1475337360364@Atlassian.JIRA>

Paul Ferraro created WFLY-7251:
----------------------------------

             Summary: Clustering API does not expose a proper capability contract
                 Key: WFLY-7251
                 URL: https://issues.jboss.org/browse/WFLY-7251
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  1 13:56:00 2016
From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=)
Date: Sat, 1 Oct 2016 13:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7209) Operation to list installed
 Resource Adapters
In-Reply-To: <JIRA.12651854.1474714280000@Atlassian.JIRA>
References: <JIRA.12651854.1474714280000@Atlassian.JIRA>
	<JIRA.12651854.1474714280000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651854.1474714280000.45831.1475344560264@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillermo Gonz?lez de Ag?ero updated WFLY-7209:
-----------------------------------------------
    Description: 
Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them.

The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()

  was:
Currently there's no way to list all the installed Resource Adapters. Only configured resource adapters can be queried. However, they are automatically enabled at deployment time.

I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them.

The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()



> Operation to list installed Resource Adapters
> ---------------------------------------------
>
>                 Key: WFLY-7209
>                 URL: https://issues.jboss.org/browse/WFLY-7209
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Guillermo Gonz?lez de Ag?ero
>            Assignee: Stefano Maestri
>             Fix For: 10.1.0.Final
>
>
> Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sat Oct  1 14:05:00 2016
From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=)
Date: Sat, 1 Oct 2016 14:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7209) Operation to list installed
 Resource Adapters
In-Reply-To: <JIRA.12651854.1474714280000@Atlassian.JIRA>
References: <JIRA.12651854.1474714280000@Atlassian.JIRA>
	<JIRA.12651854.1474714280000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651854.1474714280000.45838.1475345100240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillermo Gonz?lez de Ag?ero updated WFLY-7209:
-----------------------------------------------
    Attachment: 2-ra.png
                1-jdbc.png


> Operation to list installed Resource Adapters
> ---------------------------------------------
>
>                 Key: WFLY-7209
>                 URL: https://issues.jboss.org/browse/WFLY-7209
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Guillermo Gonz?lez de Ag?ero
>            Assignee: Stefano Maestri
>             Fix For: 10.1.0.Final
>
>         Attachments: 1-jdbc.png, 2-ra.png
>
>
> Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sat Oct  1 14:06:00 2016
From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=)
Date: Sat, 1 Oct 2016 14:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7209) Operation to list installed
 Resource Adapters
In-Reply-To: <JIRA.12651854.1474714280000@Atlassian.JIRA>
References: <JIRA.12651854.1474714280000@Atlassian.JIRA>
	<JIRA.12651854.1474714280000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651854.1474714280000.45842.1475345160202@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillermo Gonz?lez de Ag?ero updated WFLY-7209:
-----------------------------------------------
    Description: 
Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers (see attached screenshots). This would allow HAL to provide a wizard of available options when configuring them.

The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()

  was:
Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them.

The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()



> Operation to list installed Resource Adapters
> ---------------------------------------------
>
>                 Key: WFLY-7209
>                 URL: https://issues.jboss.org/browse/WFLY-7209
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Guillermo Gonz?lez de Ag?ero
>            Assignee: Stefano Maestri
>             Fix For: 10.1.0.Final
>
>         Attachments: 1-jdbc.png, 2-ra.png
>
>
> Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers (see attached screenshots). This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sat Oct  1 14:20:00 2016
From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=)
Date: Sat, 1 Oct 2016 14:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7209) Operation to list installed
 Resource Adapters
In-Reply-To: <JIRA.12651854.1474714280000@Atlassian.JIRA>
References: <JIRA.12651854.1474714280000@Atlassian.JIRA>
	<JIRA.12651854.1474714280000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651854.1474714280000.45847.1475346000231@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301349#comment-13301349 ] 

Guillermo Gonz?lez de Ag?ero commented on WFLY-7209:
----------------------------------------------------

You're right, I was confusing it. Thanks for your explanation. I've updated the issue to better explain my real use case (that I still see intereresting despite my mistake).

There's a command to list enabled JDBC drivers. Web Console benefits from that so you can select from a list instead of manually specifying the archive name (screenshot "1-jbdc.png"). 
In screenshot "2-ra.png" you can see that a handwritten archive has to be specified for resource adapter activation. An operation to list "candidate" archives (e.g: rar files or ears with a @Connector or ra.xml file) would enable HAL to achieve my proposal.

I hope I've explained it better this time.

> Operation to list installed Resource Adapters
> ---------------------------------------------
>
>                 Key: WFLY-7209
>                 URL: https://issues.jboss.org/browse/WFLY-7209
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Guillermo Gonz?lez de Ag?ero
>            Assignee: Stefano Maestri
>             Fix For: 10.1.0.Final
>
>         Attachments: 1-jdbc.png, 2-ra.png
>
>
> Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers (see attached screenshots). This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sun Oct  2 12:27:00 2016
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Sun, 2 Oct 2016 12:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.45985.1475425620509@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301363#comment-13301363 ] 

Shigeru Chiba commented on JASSIST-261:
---------------------------------------

I've committed 3.21.0-GA.  Could you upload it to maven repo?
Then I'll work on 3.22.0-CR1 for Java 9.

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 02:14:00 2016
From: issues at jboss.org (=?UTF-8?Q?Micha=C5=82_Nowakowski_=28JIRA=29?=)
Date: Mon, 3 Oct 2016 02:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for
 server-side invalidated sessions
In-Reply-To: <JIRA.12652201.1474973647000@Atlassian.JIRA>
References: <JIRA.12652201.1474973647000@Atlassian.JIRA>
	<JIRA.12652201.1474973647000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652201.1474973647000.46211.1475475240367@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301384#comment-13301384 ] 

Micha? Nowakowski commented on WFLY-7229:
-----------------------------------------

> I'm not sure why you need to disable server-side invalidation.

It was coded because two standard mechanisms you mentioned were considered not sufficient. I'm not saying they didn't work - they did and still do, but we wished to free resources faster than they can. I didn't say that earlier, but there are actually +30 sessions per user to wipe (+30 apps we thought we needed coordinated logout for, to free resources).

Now, in WF 10.1 (and only there) it's logging errors. That's why I think I need to disable it and try to live without, until the problem is resolved. Thankfully, we don't need to kill the sessions instantly for this logout to take effect. It's only a matter of lingering resources. I'm still not sure, but we hopefully have enough RAM available.

> If the session is later accessed by another node, the thread initiated on the first node will still expire the session

If I understood you right - then this is quite possibly what I want to happen.

> Undeploy of the application will not kill threads started in this way, thus your application will leak its classloader

Not a concern for me, that code is never undeployed.

> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
>                 Key: WFLY-7229
>                 URL: https://issues.jboss.org/browse/WFLY-7229
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 10.1.0.Final
>         Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
>            Reporter: Micha? Nowakowski
>            Assignee: Paul Ferraro
>         Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct  3 03:38:00 2016
From: issues at jboss.org (Teresa Miyar (JIRA))
Date: Mon, 3 Oct 2016 03:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7252) war bean not visible for
	injection
In-Reply-To: <JIRA.12652928.1475480246000@Atlassian.JIRA>
References: <JIRA.12652928.1475480246000@Atlassian.JIRA>
	<JIRA.12652928.1475480246296@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652928.1475480246000.46613.1475480280176@Atlassian.JIRA>

Teresa Miyar created WFLY-7252:
----------------------------------

             Summary: war bean not visible for injection
                 Key: WFLY-7252
                 URL: https://issues.jboss.org/browse/WFLY-7252
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 10.1.0.Final, 10.0.0.Final
            Reporter: Teresa Miyar
            Assignee: Stuart Douglas
            Priority: Critical
         Attachments: DemoProjects.zip

In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
Chapter 12. Packaging and dep...
? In an application deployed as an ear, the container searches every bean archive bundled with
or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
INF/classes directories.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct  3 03:44:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 3 Oct 2016 03:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7253) Upgrade generic JMS RA to
	1.0.8.Final
In-Reply-To: <JIRA.12652931.1475480594000@Atlassian.JIRA>
References: <JIRA.12652931.1475480594000@Atlassian.JIRA>
	<JIRA.12652931.1475480594679@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652931.1475480594000.46632.1475480640370@Atlassian.JIRA>

Jeff Mesnil created WFLY-7253:
---------------------------------

             Summary: Upgrade generic JMS RA to 1.0.8.Final
                 Key: WFLY-7253
                 URL: https://issues.jboss.org/browse/WFLY-7253
             Project: WildFly
          Issue Type: Component Upgrade
          Components: JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 04:23:00 2016
From: issues at jboss.org (COLLIGNON Thomas (JIRA))
Date: Mon, 3 Oct 2016 04:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1335) Add protection in
 RaXmlDeployer to prevent from loading xml resource
In-Reply-To: <JIRA.12652842.1475249080000@Atlassian.JIRA>
References: <JIRA.12652842.1475249080000@Atlassian.JIRA>
	<JIRA.12652842.1475249080000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652842.1475249080000.46882.1475482980461@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

COLLIGNON Thomas updated JBJCA-1335:
------------------------------------
    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/584


> Add protection in RaXmlDeployer to prevent from loading xml resource
> --------------------------------------------------------------------
>
>                 Key: JBJCA-1335
>                 URL: https://issues.jboss.org/browse/JBJCA-1335
>             Project: IronJacamar
>          Issue Type: Enhancement
>          Components: Deployer
>    Affects Versions: 1.2.7.Final
>            Reporter: COLLIGNON Thomas
>            Priority: Minor
>             Fix For: 1.2.8.Final
>
>
> If we place a -ra.xml in jar file, the class RaXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
> The goal of this issue is prevent for loading jar file in RaXmlDeployer .
> The second goal is to provide ability of overring RaXmlDeployer in custom deployer who extends this class.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 04:31:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 3 Oct 2016 04:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1846) WFLYSRV0153 error after
 attempting to explode archived subdeployments of archived deployments
In-Reply-To: <JIRA.12652938.1475483336000@Atlassian.JIRA>
References: <JIRA.12652938.1475483336000@Atlassian.JIRA>
	<JIRA.12652938.1475483336000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652938.1475483336000.46935.1475483460123@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet moved JBEAP-6275 to WFCORE-1846:
--------------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-1846  (was: JBEAP-6275)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s: 3.0.0.Alpha9
                           (was: 7.1.0.DR5)


> WFLYSRV0153 error after attempting to explode archived subdeployments of archived deployments
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1846
>                 URL: https://issues.jboss.org/browse/WFCORE-1846
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> In archived deployments with archived subdeployments, the {{explode}} operation with {{path}} parameter defined to point at archived subdeployment causes the removal of whole deployment from the content repository. 
> This operation is illegal, but the server should produce formed warning message with operation failing gracefully instead of throwing stack trace in this case.
> server.log:
> {code}09:05:07,664 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 29) WFLYUT0022: Unregistered web context: /subdeployment-test-web
> 09:05:07,701 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 09:05:07,719 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0208: Stopped subdeployment (runtime-name: subdeployment-test-ejb.jar) in 65ms
> 09:05:07,719 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0208: Stopped subdeployment (runtime-name: subdeployment-test-web.war) in 66ms
> 09:05:07,722 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment subdeployment-test.ear (runtime-name: subdeployment-test.ear) in 69ms
> 09:05:07,732 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "subdeployment-test.ear" (runtime-name: "subdeployment-test.ear")
> 09:05:07,754 INFO  [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0002: Content removed from location /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/content/13/5a0425d908539149b62eb99b63710c67b13466/content
> 09:05:07,762 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "subdeployment-test.ear" (runtime-name: "subdeployment-test.ear")
> [0m[31m09:05:07,763 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."subdeployment-test.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."subdeployment-test.ear".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment "subdeployment-test.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 	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)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0160: Failed to mount deployment content
> 	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:95)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> 	... 5 more
> Caused by: java.io.FileNotFoundException: /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/managed-exploded/subdeployment-test.ear (No such file or directory)
> 	at java.io.FileInputStream.open0(Native Method)
> 	at java.io.FileInputStream.open(FileInputStream.java:195)
> 	at java.io.FileInputStream.<init>(FileInputStream.java:138)
> 	at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:51)
> 	at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:318)
> 	at org.jboss.vfs.VFS.mountZipExpanded(VFS.java:533)
> 	at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:108)
> 	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:91)
> 	... 6 more
> [0m[31m09:05:07,765 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: (("deployment" => "subdeployment-test.ear")) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment \"subdeployment-test.ear\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0160: Failed to mount deployment content
>     Caused by: java.io.FileNotFoundException: /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/managed-exploded/subdeployment-test.ear (No such file or directory)"},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> 09:05:07,767 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "subdeployment-test.ear" was rolled back with the following failure message: 
> {
>     "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment \"subdeployment-test.ear\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0160: Failed to mount deployment content
>     Caused by: java.io.FileNotFoundException: /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/managed-exploded/subdeployment-test.ear (No such file or directory)"},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> 09:05:07,768 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0028: Stopped deployment subdeployment-test.ear (runtime-name: subdeployment-test.ear) in 1ms
> 09:05:07,770 INFO  [org.jboss.as.controller] (management-handler-thread - 3) WFLYCTL0183: Service status report
> WFLYCTL0186:   Services which failed to start:      service jboss.deployment.unit."subdeployment-test.ear".STRUCTURE{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct  3 04:38:00 2016
From: issues at jboss.org (Teresa Miyar (JIRA))
Date: Mon, 3 Oct 2016 04:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7252) war bean not visible for
	injection
In-Reply-To: <JIRA.12652928.1475480246000@Atlassian.JIRA>
References: <JIRA.12652928.1475480246000@Atlassian.JIRA>
	<JIRA.12652928.1475480246000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652928.1475480246000.46985.1475483880257@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Teresa Miyar updated WFLY-7252:
-------------------------------
    Description: 
In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
Chapter 12. Packaging and dep...
? In an application deployed as an ear, the container searches every bean archive bundled with
or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
INF/classes directories.

Then we have this:
See also the "5.1. Modularity",
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#selection:

"A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture."

"In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."

But the JavaEE spec states it "may" have access... it did have access on EAP6, does not have access on EAP7.

  was:
In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
Chapter 12. Packaging and dep...
? In an application deployed as an ear, the container searches every bean archive bundled with
or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
INF/classes directories.



> war bean not visible for injection
> ----------------------------------
>
>                 Key: WFLY-7252
>                 URL: https://issues.jboss.org/browse/WFLY-7252
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Teresa Miyar
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: DemoProjects.zip
>
>
> In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
> Chapter 12. Packaging and dep...
> ? In an application deployed as an ear, the container searches every bean archive bundled with
> or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
> and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
> INF/classes directories.
> Then we have this:
> See also the "5.1. Modularity",
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#selection:
> "A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture."
> "In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."
> But the JavaEE spec states it "may" have access... it did have access on EAP6, does not have access on EAP7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct  3 05:58:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Mon, 3 Oct 2016 05:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-632) No log messages comming from
 Elytron - authentication process start
In-Reply-To: <JIRA.12651433.1474535762000@Atlassian.JIRA>
References: <JIRA.12651433.1474535762000@Atlassian.JIRA>
	<JIRA.12651433.1474535762000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651433.1474535762000.47396.1475488680482@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned ELY-632:
------------------------------

    Assignee: Ingo Weiss  (was: Darran Lofthouse)


> No log messages comming from Elytron - authentication process start
> -------------------------------------------------------------------
>
>                 Key: ELY-632
>                 URL: https://issues.jboss.org/browse/ELY-632
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta9
>            Reporter: Ondrej Lukas
>            Assignee: Ingo Weiss
>
> Elytron is missing any log messages related to starting authentication process. These log messages should be added. See JBEAP-6041 for more details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 06:26:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 3 Oct 2016 06:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6942) Add a forget operation to the
 transaction subsystem tooling
In-Reply-To: <JIRA.12642921.1470911576000@Atlassian.JIRA>
References: <JIRA.12642921.1470911576000@Atlassian.JIRA>
	<JIRA.12642921.1470911576000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642921.1470911576000.47492.1475490360282@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove resolved WFLY-6942.
------------------------------------
    Release Notes Text: The transactions tooling operation to remove heuristically completed XA resource participants from transaction logs previously (to this release) did not invoke the forget operation on the resource. This call is useful since it facilitates clean up. In this release the forget operation is called when removing such participants. However, by default the result of the forget call is ignored and even if it fails the log is still removed. To override this behaviour the administrator can set a system property called ignoreMBeanHeuristics to the value false. With this value set participants will not be removed from the log if the forget call is unsuccessful.
         Fix Version/s: 11.0.0.Alpha1
            Resolution: Done


This operaton is fixed in WFLY-7241 (Upgrade Narayana to 5.3.5.Final).

Only the docs/release notes update for how to trigger the forget operation is pending.

> Add a forget operation to the transaction subsystem tooling
> -----------------------------------------------------------
>
>                 Key: WFLY-6942
>                 URL: https://issues.jboss.org/browse/WFLY-6942
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 11.0.0.Alpha1
>
>
> The CLI tooling provides two features for dealing with heuristic participants:
> * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed;
> * a delete operation if the admin thinks it safe to do so;
> In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 08:33:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 3 Oct 2016 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7254) pattern-filter disappears if
 predefined-filter is used for configurable-sasl-server-factory in Elytron
 subsystem
In-Reply-To: <JIRA.12652989.1475497943000@Atlassian.JIRA>
References: <JIRA.12652989.1475497943000@Atlassian.JIRA>
	<JIRA.12652989.1475497943552@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652989.1475497943000.48438.1475497981134@Atlassian.JIRA>

Ondrej Lukas created WFLY-7254:
----------------------------------

             Summary: pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
                 Key: WFLY-7254
                 URL: https://issues.jboss.org/browse/WFLY-7254
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears). 

Suggestion:
In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 08:33:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 3 Oct 2016 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7254) pattern-filter disappears if
 predefined-filter is used for configurable-sasl-server-factory in Elytron
 subsystem
In-Reply-To: <JIRA.12652989.1475497944000@Atlassian.JIRA>
References: <JIRA.12652989.1475497944000@Atlassian.JIRA>
	<JIRA.12652989.1475497944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652989.1475497944000.48450.1475497981431@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7254:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7254
>                 URL: https://issues.jboss.org/browse/WFLY-7254
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears). 
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 08:36:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 3 Oct 2016 08:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7254) pattern-filter disappears if
 predefined-filter is used for configurable-sasl-server-factory in Elytron
 subsystem
In-Reply-To: <JIRA.12652989.1475497944000@Atlassian.JIRA>
References: <JIRA.12652989.1475497944000@Atlassian.JIRA>
	<JIRA.12652989.1475497944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652989.1475497944000.48496.1475498160711@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7254:
-----------------------------------
    Affects Version/s:     (was: 11.0.0.Alpha1)


> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7254
>                 URL: https://issues.jboss.org/browse/WFLY-7254
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears). 
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 08:36:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 3 Oct 2016 08:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7254) pattern-filter disappears if
 predefined-filter is used for configurable-sasl-server-factory in Elytron
 subsystem
In-Reply-To: <JIRA.12652989.1475497944000@Atlassian.JIRA>
References: <JIRA.12652989.1475497944000@Atlassian.JIRA>
	<JIRA.12652989.1475497944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652989.1475497944000.48503.1475498160905@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7254:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7254
>                 URL: https://issues.jboss.org/browse/WFLY-7254
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears). 
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 08:58:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 08:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-644) Creating LDAP security realm
 fails with cryptic error message
In-Reply-To: <JIRA.12652320.1475003617000@Atlassian.JIRA>
References: <JIRA.12652320.1475003617000@Atlassian.JIRA>
	<JIRA.12652320.1475003617000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652320.1475003617000.48720.1475499480445@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301620#comment-13301620 ] 

Jan Kalina commented on ELY-644:
--------------------------------

Problem is the LdapRealm obtain value of "writable" attribute directly from query, fail instead of using default.

> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
>                 Key: ELY-644
>                 URL: https://issues.jboss.org/browse/ELY-644
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Zach Rhoads
>            Assignee: Jan Kalina
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
>     "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 08:59:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 08:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7255) Creating LDAP security realm
 fails with cryptic error message
In-Reply-To: <JIRA.12652320.1475003617000@Atlassian.JIRA>
References: <JIRA.12652320.1475003617000@Atlassian.JIRA>
	<JIRA.12652320.1475003617000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652320.1475003617000.48732.1475499540386@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved ELY-644 to WFLY-7255:
--------------------------------------

    Project: WildFly  (was: WildFly Elytron)
        Key: WFLY-7255  (was: ELY-644)


> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
>                 Key: WFLY-7255
>                 URL: https://issues.jboss.org/browse/WFLY-7255
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Zach Rhoads
>            Assignee: Jan Kalina
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
>     "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 08:59:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 08:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7255) Creating LDAP security realm
 fails with cryptic error message
In-Reply-To: <JIRA.12652320.1475003617000@Atlassian.JIRA>
References: <JIRA.12652320.1475003617000@Atlassian.JIRA>
	<JIRA.12652320.1475003617000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652320.1475003617000.48739.1475499540577@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7255:
-----------------------------
    Component/s: Security


> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
>                 Key: WFLY-7255
>                 URL: https://issues.jboss.org/browse/WFLY-7255
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Zach Rhoads
>            Assignee: Jan Kalina
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
>     "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 09:16:00 2016
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 3 Oct 2016 09:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-930) A security-domain can only
 load login-modules from a single JBoss module
In-Reply-To: <JIRA.12597491.1450716628000@Atlassian.JIRA>
References: <JIRA.12597491.1450716628000@Atlassian.JIRA>
	<JIRA.12597491.1450716628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597491.1450716628000.48949.1475500560661@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301637#comment-13301637 ] 

Peter Palaga commented on SECURITY-930:
---------------------------------------

> I'll try to find this commit and check if it has made it into WildFly. I'll post again once I figure this out.

[~sguilhen], any update on this?

>  A security-domain can only load login-modules from a single JBoss module 
> --------------------------------------------------------------------------
>
>                 Key: SECURITY-930
>                 URL: https://issues.jboss.org/browse/SECURITY-930
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>
> A security-domain can only load login-modules from a single JBoss module.  Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.  
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
>   <security-domain name="jmx-console" cache-type="default">
>       <authentication>
>           <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>           <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>       </authentication>
>   </security-domain>
> Unfortunately, it does not work like this.  Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
> There seems to be two issues.  1)  The security subsystem code only "remembers" the last module that is defined within a single security domain.  2)  I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code.  The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 09:19:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 3 Oct 2016 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1316) Missing MBean for Classpath
 causes RHQ/JON plug-in failure to display the whole hierarchy
In-Reply-To: <JIRA.12653001.1475500691000@Atlassian.JIRA>
References: <JIRA.12653001.1475500691000@Atlassian.JIRA>
	<JIRA.12653001.1475500691355@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653001.1475500691000.48989.1475500740085@Atlassian.JIRA>

Matteo Mortari created DROOLS-1316:
--------------------------------------

             Summary: Missing MBean for Classpath causes RHQ/JON plug-in failure to display the whole hierarchy
                 Key: DROOLS-1316
                 URL: https://issues.jboss.org/browse/DROOLS-1316
             Project: Drools
          Issue Type: Bug
          Components: core engine, integration
    Affects Versions: 7.0.0.Beta1, 6.5.0.CR2
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


As RHQ/JON is able to discover the MBean for the KieBase and KieSession but unable to locate the MXBean for the KieContainer, would fail to display the whole hierarchy.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 09:30:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 3 Oct 2016 09:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1316) Missing MBean for Classpath
 KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
In-Reply-To: <JIRA.12653001.1475500691000@Atlassian.JIRA>
References: <JIRA.12653001.1475500691000@Atlassian.JIRA>
	<JIRA.12653001.1475500691000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653001.1475500691000.49056.1475501400099@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-1316:
-----------------------------------
    Summary: Missing MBean for Classpath KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy  (was: Missing MBean for Classpath causes RHQ/JON plug-in failure to display the whole hierarchy)


> Missing MBean for Classpath KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1316
>                 URL: https://issues.jboss.org/browse/DROOLS-1316
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine, integration
>    Affects Versions: 6.5.0.CR2, 7.0.0.Beta1
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>
> As RHQ/JON is able to discover the MBean for the KieBase and KieSession but unable to locate the MXBean for the KieContainer, would fail to display the whole hierarchy.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 09:55:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 3 Oct 2016 09:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for
 server-side invalidated sessions
In-Reply-To: <JIRA.12652201.1474973647000@Atlassian.JIRA>
References: <JIRA.12652201.1474973647000@Atlassian.JIRA>
	<JIRA.12652201.1474973647000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652201.1474973647000.49734.1475502900423@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301669#comment-13301669 ] 

Paul Ferraro commented on WFLY-7229:
------------------------------------

> It was coded because two standard mechanisms you mentioned were considered not sufficient. I'm not saying they didn't work - they did and still do, but we wished to free resources faster than they can. I didn't say that earlier, but there are actually +30 sessions per user to wipe (+30 apps we thought we needed coordinated logout for, to free resources).

The code in MainServlet will not free resources any faster than the standard mechanism.  The distributed session manager in WF 10 does not rely on a polling mechanism (like older releases did), but instead schedules expiration eagerly.  Thus sessions will be destroyed as soon as they are sufficiently idle.

> Now, in WF 10.1 (and only there) it's logging errors.

It's logging errors because this doesn't work in WF10.  In WF10, the distributed HttpSession is not a traditional map of attributes, but rather a proxy to a distributed cache in which the session attributes are stored.  This proxy is only functional within the context of a container thread (e.g. request thread, listener thread, async context thread, etc.).

> If I understood you right - then this is quite possibly what I want to happen.

I don't think you understood me fully.  This would result in premature expiration.  If a request fails over to another node, and the original node is still alive, it will expire the session even though it is still being used.  I highly doubt that this is what you want to happen.

> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
>                 Key: WFLY-7229
>                 URL: https://issues.jboss.org/browse/WFLY-7229
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 10.1.0.Final
>         Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
>            Reporter: Micha? Nowakowski
>            Assignee: Paul Ferraro
>         Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct  3 10:18:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 3 Oct 2016 10:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6899) Upgrade RESTEasy to 3.1.x
In-Reply-To: <JIRA.12641426.1470062534000@Atlassian.JIRA>
References: <JIRA.12641426.1470062534000@Atlassian.JIRA>
	<JIRA.12641426.1470062534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641426.1470062534000.49913.1475504280922@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-6899:
------------------------------
    Summary: Upgrade RESTEasy to 3.1.x  (was: Upgrade RESTEasy to 3.1.0.Beta2)


> Upgrade RESTEasy to 3.1.x
> -------------------------
>
>                 Key: WFLY-6899
>                 URL: https://issues.jboss.org/browse/WFLY-6899
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: REST
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:24:00 2016
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 3 Oct 2016 10:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1847) PatchMerger overrides
 submodule's content merging the outer module
In-Reply-To: <JIRA.12653014.1475504627000@Atlassian.JIRA>
References: <JIRA.12653014.1475504627000@Atlassian.JIRA>
	<JIRA.12653014.1475504627817@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653014.1475504627000.49990.1475504640757@Atlassian.JIRA>

Alexey Loubyansky created WFCORE-1847:
-----------------------------------------

             Summary: PatchMerger overrides submodule's content merging the outer module
                 Key: WFCORE-1847
                 URL: https://issues.jboss.org/browse/WFCORE-1847
             Project: WildFly Core
          Issue Type: Bug
          Components: Patching 
    Affects Versions: 3.0.0.Alpha9
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky


PatchMerger merges two CPs into one. In case the first CP includes updates for modules like org.outermodule and org.outermodule.innermodule. And the second CP including an update for org.outermodule.innermodule only, the merge may not happen correctly in case the modification for the innermodule will appear before the modification for the outermodule in the first CP.
The merger will copy the innermodule's content first and then override it copying the outermodule's content (including the previous version of the innermodule).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:54:01 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 3 Oct 2016 10:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.50208.1475506441270@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301722#comment-13301722 ] 

Scott Marlow commented on JASSIST-261:
--------------------------------------

I got a javadoc build error as AnnotationsAttribute doesn't seem to have invisibleTab but some javadoc links to that:
{code}
/mnt/ssd/work/javassist/src/main/javassist/bytecode/FieldInfo.java:236: error: reference not found
[ERROR] * {@link AnnotationsAttribute#invisibleTab}
{code}

Full output for "mvn  -P centralRelease javadoc:jar deploy" is at [http://pastebin.com/2wTL6qX0].

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:01 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-925) Cannot deploy kie-server to
 Wildfly 10.0.0.CR1
In-Reply-To: <JIRA.12585580.1442862774000@Atlassian.JIRA>
References: <JIRA.12585580.1442862774000@Atlassian.JIRA>
	<JIRA.12585580.1442862774000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585580.1442862774000.50289.1475506741299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-925:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> Cannot deploy kie-server to Wildfly 10.0.0.CR1
> ----------------------------------------------
>
>                 Key: DROOLS-925
>                 URL: https://issues.jboss.org/browse/DROOLS-925
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.3.0.CR2
>         Environment: Wildfly 10.0.0.CR1
>            Reporter: Pokpitch Patcharadamrongkul
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 7.0.0.Beta3
>
>
> Cannot deploy kie-server to Wildfly 10.0.0.CR1 (HornetQ is to be deprecated from Wildfly 10.x.x) Please fixed in kie-server-x.x-x.war/META-INF/kie-server-jms.xml
> {color:red}Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSGAMQ0055: Could not parse file /opt/wildfly-10.0.0.CR1/standalone/tmp/vfs/temp/temp8eb8a1f894857057/content-c7b7cd6a0a56658e/META-INF/kie-server-jms.xml
> 	at org.wildfly.extension.messaging.activemq.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:95)
> 	... 6 more
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1]
> Message: Unexpected element '{urn:jboss:messaging-deployment:1.0}messaging-deployment'
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.wildfly.extension.messaging.activemq.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:89)
> 	... 6 more{color}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:01 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-817) Extremely poor performance
 of the topological sorting implementation for type declarations performs
In-Reply-To: <JIRA.12574901.1434234948000@Atlassian.JIRA>
References: <JIRA.12574901.1434234948000@Atlassian.JIRA>
	<JIRA.12574901.1434234948000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574901.1434234948000.50292.1475506741357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-817:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> Extremely poor performance of the topological sorting implementation for type declarations performs 
> ----------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-817
>                 URL: https://issues.jboss.org/browse/DROOLS-817
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.Beta1
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For: 7.0.0.Beta3
>
>
> The current implementation suffers from thrashing.
> In case of large business object models (e.g. derived from an ontology), 
> the analysis at package build time may take orders of magnitude more 
> than necessary



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:01 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-744) Rule Generation Feature
	Request
In-Reply-To: <JIRA.12566202.1426647181000@Atlassian.JIRA>
References: <JIRA.12566202.1426647181000@Atlassian.JIRA>
	<JIRA.12566202.1426647181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566202.1426647181000.50297.1475506741506@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-744:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> Rule Generation Feature Request
> -------------------------------
>
>                 Key: DROOLS-744
>                 URL: https://issues.jboss.org/browse/DROOLS-744
>             Project: Drools
>          Issue Type: Feature Request
>          Components: core engine, kie server
>    Affects Versions: 6.2.0.Final
>            Reporter: Justin Holmes
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.Beta3
>
>
> As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems. 
> The initial thought process around implementation is to build two things 1) a simple way to author mvel templates in business central, the existing text editor could be used at first and 2) a simple embedded java api in it's own maven module which can checkout the git project that has the mvel template, apply a set of domain objects to the template, check in the resulting rule files to the local git repo and then push the changes back to business central. This allows us to leverage the power of the existing MVEL and JGit tech stack while pushing the complexity to a java api, where we are stronger than the workbench itself. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:01 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-680) "contains" operator behaves
 inconsistently when used with Maps
In-Reply-To: <JIRA.12560583.1420792236000@Atlassian.JIRA>
References: <JIRA.12560583.1420792236000@Atlassian.JIRA>
	<JIRA.12560583.1420792236000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560583.1420792236000.50302.1475506741705@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-680:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> "contains" operator behaves inconsistently when used with Maps
> --------------------------------------------------------------
>
>                 Key: DROOLS-680
>                 URL: https://issues.jboss.org/browse/DROOLS-680
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.6.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.Beta3
>
>
> In a rule
> {code}
> Bean( map contains "x" ) // assuming "map" is a property of type Map
> {code}
> "contains" is arbitrarily interpreted as "containsKey"
> The constrain will then fail after being jitted
> The documentation explicitly states that "contains" applies to collections



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:01 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-670) Generalize inline casts to
 work with traits
In-Reply-To: <JIRA.12559527.1418604958000@Atlassian.JIRA>
References: <JIRA.12559527.1418604958000@Atlassian.JIRA>
	<JIRA.12559527.1418604958000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559527.1418604958000.50305.1475506741801@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-670:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> Generalize inline casts to work with traits
> -------------------------------------------
>
>                 Key: DROOLS-670
>                 URL: https://issues.jboss.org/browse/DROOLS-670
>             Project: Drools
>          Issue Type: Enhancement
>    Affects Versions: 6.2.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>             Fix For: 7.0.0.Beta3
>
>
> The following constraint
> {code}
> Person( this#Worker( wage > 1000 ) )
> {code}
> is admissible when Worker is a subtype of Person.
> It should also be possible to use "#" when Worker is a donned trait.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:02 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-669) Create "behavesAs" operator
 to support traiting
In-Reply-To: <JIRA.12559526.1418604821000@Atlassian.JIRA>
References: <JIRA.12559526.1418604821000@Atlassian.JIRA>
	<JIRA.12559526.1418604821000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559526.1418604821000.50309.1475506742015@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-669:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> Create "behavesAs" operator to support traiting
> -----------------------------------------------
>
>                 Key: DROOLS-669
>                 URL: https://issues.jboss.org/browse/DROOLS-669
>             Project: Drools
>          Issue Type: Feature Request
>    Affects Versions: 6.2.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>             Fix For: 7.0.0.Beta3
>
>
> Define an operator that would check if an object can provide *natively* all the methods required by an interface. This would ensure that, upon donning the interface as a trait, no soft field would be required, and that all methods in the interface would have a concrete implementation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:02 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-607) Match.getObjects() should
 reflect the patterns' order
In-Reply-To: <JIRA.12552849.1411313397000@Atlassian.JIRA>
References: <JIRA.12552849.1411313397000@Atlassian.JIRA>
	<JIRA.12552849.1411313397000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552849.1411313397000.50314.1475506742253@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-607:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> Match.getObjects() should reflect the patterns' order
> -----------------------------------------------------
>
>                 Key: DROOLS-607
>                 URL: https://issues.jboss.org/browse/DROOLS-607
>             Project: Drools
>          Issue Type: Enhancement
>    Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.1.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Minor
>             Fix For: 7.0.0.Beta3
>
>
> if Match.getObjects() is called on a rule with LHS A() B() C(), 
> the resulting list will have the matching objects in reversed order 
> - that is, [c, b, a] - making it more difficult to analyze it. 
> The object's position in the list should reflect the LHS. 
> The order should be preserved even when subnetworks are present.
> For example, A() not B() C() should then result in the list [a, *, c ]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:02 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-542) Expose more Commands through
 the KieCommands API
In-Reply-To: <JIRA.12545563.1404400105000@Atlassian.JIRA>
References: <JIRA.12545563.1404400105000@Atlassian.JIRA>
	<JIRA.12545563.1404400105000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545563.1404400105000.50318.1475506742497@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-542:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> Expose more Commands through the KieCommands API
> ------------------------------------------------
>
>                 Key: DROOLS-542
>                 URL: https://issues.jboss.org/browse/DROOLS-542
>             Project: Drools
>          Issue Type: Feature Request
>    Affects Versions: 6.1.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>             Fix For: 7.0.0.Beta3
>
>
> Not all Commands are exposed by the KieCommands API interface



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:02 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-470) Decision Table (XLS) should
 support fixed conditions, such as SeatDesignation(isNeighborOf($guest))
In-Reply-To: <JIRA.12538885.1398256310000@Atlassian.JIRA>
References: <JIRA.12538885.1398256310000@Atlassian.JIRA>
	<JIRA.12538885.1398256310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538885.1398256310000.50322.1475506742703@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-470:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest))
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-470
>                 URL: https://issues.jboss.org/browse/DROOLS-470
>             Project: Drools
>          Issue Type: Enhancement
>          Components: decision tables
>    Affects Versions: 6.1.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Anstis
>              Labels: optaplanner-request-for-drools
>             Fix For: 7.0.0.Beta3
>
>
> This DT should work:
> ||CONDITION||CONDITION||ACTION|
> |$guest : SeatDesignation()|$neighbor : SeatDesignation(isNeighborOf($guest))||
> |guestName == "$param"|guestName == "$param"|doSomething();|
> It crashes because of the "SeatDesignation(isNeighborOf($guest))". Only empty parenthesis are allowed.
> Failing workaround 1: This workaround (as specified by the docs), does NOT work well, because it adds the same condition (isNeighborOf($guest)) multiple times in the same rule:
> ||CONDITION||CONDITION||CONDITION||ACTION|
> |$guest : SeatDesignation()|$neighbor : SeatDesignation()|||
> |guestName == "$param"|isNeighborOf($guest), guestName == "$param"|isNeighborOf($guest), guestAge == "$param"|doSomething();|
> Failing workaround 2: Adding an extra, hidden column with that condition does not work when new rows are added because condition columns with an empty cell are ignored.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 10:59:02 2016
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 3 Oct 2016 10:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-453) Allow KieSession globals
 configurable via kmodule.xml
In-Reply-To: <JIRA.12534852.1394701072000@Atlassian.JIRA>
References: <JIRA.12534852.1394701072000@Atlassian.JIRA>
	<JIRA.12534852.1394701072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534852.1394701072000.50330.1475506742967@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-453:
------------------------------------------
    Fix Version/s: 7.0.0.Beta3
                       (was: 7.0.0.Beta2)


> Allow KieSession globals configurable via kmodule.xml
> -----------------------------------------------------
>
>                 Key: DROOLS-453
>                 URL: https://issues.jboss.org/browse/DROOLS-453
>             Project: Drools
>          Issue Type: Enhancement
>    Affects Versions: 6.0.0.Final
>            Reporter: Anton Giertli
>            Assignee: Mark Proctor
>             Fix For: 7.0.0.Beta3
>
>
> Looking at the current xsd of kmodule.xml
> https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.0.x/kie-api/src/main/resources/org/kie/api/kmodule.xsd
> It is not possible to configure KieSession globals variables via kmodule.xml.
> Given the fact it is already possible to configure almost every KieSession related features like listeners, handlers, loggers, globals, also session related, should be configurable through the kmodule.xml too.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:03:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 3 Oct 2016 11:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7256) Configuration differences
 between default configuration and read/persisted in messaging and IIOP
In-Reply-To: <JIRA.12653021.1475506934000@Atlassian.JIRA>
References: <JIRA.12653021.1475506934000@Atlassian.JIRA>
	<JIRA.12653021.1475506934000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653021.1475506934000.50357.1475506980490@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-6279 to WFLY-7256:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7256  (was: JBEAP-6279)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Affects Version/s: 10.1.0.Final
                           (was: 7.0.0.ER6)


> Configuration differences between default configuration and read/persisted in messaging and IIOP
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7256
>                 URL: https://issues.jboss.org/browse/WFLY-7256
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> Following up on JBEAP-3093, there are still differences in these 2 subsystems:
> {noformat}
> 258a255
> >             <orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/>
> 337c334
> <                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> ---
> >                     <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
> 339,341c336,338
> <                 <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
> <                 <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="http"/>
> <                 <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http">
> ---
> >                 <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10" redistribution-delay="1000"/>
> >                 <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
> >                 <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
> 353c350
> <                 <cluster-connection name="my-cluster" discovery-group="dg-group1" connector-name="http-connector" address="jms"/>
> ---
> >                 <cluster-connection name="my-cluster" address="jms" connector-name="http-connector" discovery-group="dg-group1"/>
> 356,358c353,355
> <                 <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
> <                 <connection-factory name="RemoteConnectionFactory" reconnect-attempts="-1" block-on-acknowledge="true" ha="true" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
> <                 <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
> ---
> >                 <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory"/>
> >                 <connection-factory name="RemoteConnectionFactory" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
> >                 <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:03:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 3 Oct 2016 11:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7256) Configuration differences
 between default configuration and read/persisted in messaging and IIOP
In-Reply-To: <JIRA.12653021.1475506934000@Atlassian.JIRA>
References: <JIRA.12653021.1475506934000@Atlassian.JIRA>
	<JIRA.12653021.1475506934000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653021.1475506934000.50364.1475506980921@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-7256:
------------------------------
    Component/s: IIOP
                 JMS


> Configuration differences between default configuration and read/persisted in messaging and IIOP
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7256
>                 URL: https://issues.jboss.org/browse/WFLY-7256
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> Following up on JBEAP-3093, there are still differences in these 2 subsystems:
> {noformat}
> 258a255
> >             <orb socket-binding="iiop" ssl-socket-binding="iiop-ssl"/>
> 337c334
> <                     <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> ---
> >                     <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
> 339,341c336,338
> <                 <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
> <                 <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="http"/>
> <                 <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http">
> ---
> >                 <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10" redistribution-delay="1000"/>
> >                 <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
> >                 <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
> 353c350
> <                 <cluster-connection name="my-cluster" discovery-group="dg-group1" connector-name="http-connector" address="jms"/>
> ---
> >                 <cluster-connection name="my-cluster" address="jms" connector-name="http-connector" discovery-group="dg-group1"/>
> 356,358c353,355
> <                 <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
> <                 <connection-factory name="RemoteConnectionFactory" reconnect-attempts="-1" block-on-acknowledge="true" ha="true" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
> <                 <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
> ---
> >                 <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory"/>
> >                 <connection-factory name="RemoteConnectionFactory" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
> >                 <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:05:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 11:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7172) Complex type properties-realm
 in Elytron subsystem
In-Reply-To: <JIRA.12651194.1474462051000@Atlassian.JIRA>
References: <JIRA.12651194.1474462051000@Atlassian.JIRA>
	<JIRA.12651194.1474462051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651194.1474462051000.50417.1475507101675@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7172:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
>                 Key: WFLY-7172
>                 URL: https://issues.jboss.org/browse/WFLY-7172
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:23:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 3 Oct 2016 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7257) Upgrade JGroups to
	3.6.11.Final
In-Reply-To: <JIRA.12653024.1475508142000@Atlassian.JIRA>
References: <JIRA.12653024.1475508142000@Atlassian.JIRA>
	<JIRA.12653024.1475508142586@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653024.1475508142000.50632.1475508180457@Atlassian.JIRA>

Paul Ferraro created WFLY-7257:
----------------------------------

             Summary: Upgrade JGroups to 3.6.11.Final
                 Key: WFLY-7257
                 URL: https://issues.jboss.org/browse/WFLY-7257
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Clustering
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:23:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 3 Oct 2016 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7258) Upgrade JGroups to
	3.6.11.Final
In-Reply-To: <JIRA.12653025.1475508152000@Atlassian.JIRA>
References: <JIRA.12653025.1475508152000@Atlassian.JIRA>
	<JIRA.12653025.1475508152503@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653025.1475508152000.50639.1475508180681@Atlassian.JIRA>

Paul Ferraro created WFLY-7258:
----------------------------------

             Summary: Upgrade JGroups to 3.6.11.Final
                 Key: WFLY-7258
                 URL: https://issues.jboss.org/browse/WFLY-7258
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Clustering
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:28:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 11:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7172) Complex type properties-realm
 in Elytron subsystem
In-Reply-To: <JIRA.12651194.1474462051000@Atlassian.JIRA>
References: <JIRA.12651194.1474462051000@Atlassian.JIRA>
	<JIRA.12651194.1474462051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651194.1474462051000.50750.1475508480437@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7172:
-----------------------------
    Description: 
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.

*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple *_PATH+*_RELATIVE_TO attributes.

  was:Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.



> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
>                 Key: WFLY-7172
>                 URL: https://issues.jboss.org/browse/WFLY-7172
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> *Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple *_PATH+*_RELATIVE_TO attributes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:30:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 11:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7172) Complex type properties-realm
 in Elytron subsystem
In-Reply-To: <JIRA.12651194.1474462051000@Atlassian.JIRA>
References: <JIRA.12651194.1474462051000@Atlassian.JIRA>
	<JIRA.12651194.1474462051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651194.1474462051000.50767.1475508600812@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7172:
-----------------------------
    Description: 
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.

*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple ?_PATH+?_RELATIVE_TO attributes.

  was:
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.

*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple *_PATH+*_RELATIVE_TO attributes.



> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
>                 Key: WFLY-7172
>                 URL: https://issues.jboss.org/browse/WFLY-7172
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> *Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple ?_PATH+?_RELATIVE_TO attributes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:30:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 11:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7172) Complex type properties-realm
 in Elytron subsystem
In-Reply-To: <JIRA.12651194.1474462051000@Atlassian.JIRA>
References: <JIRA.12651194.1474462051000@Atlassian.JIRA>
	<JIRA.12651194.1474462051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651194.1474462051000.50776.1475508601245@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7172:
-----------------------------
    Description: 
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.

*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.

  was:
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.

*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple ?_PATH+?_RELATIVE_TO attributes.



> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
>                 Key: WFLY-7172
>                 URL: https://issues.jboss.org/browse/WFLY-7172
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> *Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:30:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 3 Oct 2016 11:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7172) Complex type properties-realm
 in Elytron subsystem
In-Reply-To: <JIRA.12651194.1474462051000@Atlassian.JIRA>
References: <JIRA.12651194.1474462051000@Atlassian.JIRA>
	<JIRA.12651194.1474462051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651194.1474462051000.50786.1475508601527@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301756#comment-13301756 ] 

Darran Lofthouse commented on WFLY-7172:
----------------------------------------

[~honza889] As I mention in JBEAP-6120 we do not want to remove the object types, all we need to do for this is ensure path is a required attribute if the ObjectType is defined and the relative-to attribute can not support expressions.

> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
>                 Key: WFLY-7172
>                 URL: https://issues.jboss.org/browse/WFLY-7172
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> *Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:33:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 11:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7172) Complex type properties-realm
 in Elytron subsystem
In-Reply-To: <JIRA.12651194.1474462051000@Atlassian.JIRA>
References: <JIRA.12651194.1474462051000@Atlassian.JIRA>
	<JIRA.12651194.1474462051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651194.1474462051000.50850.1475508781629@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301761#comment-13301761 ] 

Jan Kalina commented on WFLY-7172:
----------------------------------

Do we want this even through the HAL team says they dont need this?
http://lists.jboss.org/pipermail/wildfly-dev/2016-September/005492.html

> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
>                 Key: WFLY-7172
>                 URL: https://issues.jboss.org/browse/WFLY-7172
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> *Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:34:02 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 11:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7172) Complex type properties-realm
 in Elytron subsystem
In-Reply-To: <JIRA.12651194.1474462051000@Atlassian.JIRA>
References: <JIRA.12651194.1474462051000@Atlassian.JIRA>
	<JIRA.12651194.1474462051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651194.1474462051000.50874.1475508842021@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7172:
-----------------------------
    Comment: was deleted

(was: Do we want this even through the HAL team says they dont need this?
http://lists.jboss.org/pipermail/wildfly-dev/2016-September/005492.html)


> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
>                 Key: WFLY-7172
>                 URL: https://issues.jboss.org/browse/WFLY-7172
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> *Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:36:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 3 Oct 2016 11:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7172) Complex type properties-realm
 in Elytron subsystem
In-Reply-To: <JIRA.12651194.1474462051000@Atlassian.JIRA>
References: <JIRA.12651194.1474462051000@Atlassian.JIRA>
	<JIRA.12651194.1474462051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651194.1474462051000.50977.1475508960716@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7172:
-----------------------------
    Description: 
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.

-*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.-

1. The 'path' attributes should not be nillable, i.e. if the ObjectType that holds them is defined the path should be specified.
2. The 'relative-to' attributes should not support expressions.

  was:
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.

*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.



> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
>                 Key: WFLY-7172
>                 URL: https://issues.jboss.org/browse/WFLY-7172
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> -*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.-
> 1. The 'path' attributes should not be nillable, i.e. if the ObjectType that holds them is defined the path should be specified.
> 2. The 'relative-to' attributes should not support expressions.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 11:57:01 2016
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Mon, 3 Oct 2016 11:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.51153.1475510221993@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301776#comment-13301776 ] 

Shigeru Chiba commented on JASSIST-261:
---------------------------------------

Ah, I fixed typos and committed.
Can you try to build again?

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 12:28:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 3 Oct 2016 12:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.51408.1475512080554@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301793#comment-13301793 ] 

Scott Marlow commented on JASSIST-261:
--------------------------------------

hmm, now I see:
{code}
[INFO] --- maven-gpg-plugin:1.4:sign (sign-artifacts) @ javassist ---
gpg: no default secret key: unusable secret key
gpg: signing failed: unusable secret key
{code}

To see the above failure, I did:
{quote}
git pull upstream master --tags
git checkout rel_3_21_0_ga
mvn  -P centralRelease javadoc:jar deploy
{quote}

I think that I need to renew my public key as it expired on 2016-05-07.  I'll look into that and try again :)

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 12:30:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 3 Oct 2016 12:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7257) Upgrade JGroups to
	3.6.11.Final
In-Reply-To: <JIRA.12653024.1475508143000@Atlassian.JIRA>
References: <JIRA.12653024.1475508143000@Atlassian.JIRA>
	<JIRA.12653024.1475508143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653024.1475508143000.51412.1475512200261@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7257:
---------------------------------
    Description: https://issues.jboss.org/projects/JGRP/versions/12330930 changelog


> Upgrade JGroups to 3.6.11.Final
> -------------------------------
>
>                 Key: WFLY-7257
>                 URL: https://issues.jboss.org/browse/WFLY-7257
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> https://issues.jboss.org/projects/JGRP/versions/12330930 changelog



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 12:37:01 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 3 Oct 2016 12:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-835) @Resource UserTransaction
 error when file passivation store is selected
In-Reply-To: <JIRA.12486327.1362495445000@Atlassian.JIRA>
References: <JIRA.12486327.1362495445000@Atlassian.JIRA>
	<JIRA.12486327.1362495445000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486327.1362495445000.51438.1475512621158@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated WFLY-835:
----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
>                 Key: WFLY-835
>                 URL: https://issues.jboss.org/browse/WFLY-835
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.CR2
>         Environment: Ubuntu 11.10, Intel? Core? i3-2120 CPU @ 3.30GHz ? 4 
>            Reporter: Abraham Cabanillas Piera
>            Assignee: Michael Musgrove
>            Priority: Critical
>              Labels: jboss
>             Fix For: 11.0.0.Alpha1
>
>         Attachments: serializationerr_server.log
>
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> 	at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> 	at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	... 15 more
> Caused by: an exception which occurred:
> 	in field userTransaction
> 	in field instance
> 	in field instance
> 	in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl at 6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
>             <session-bean>
>                 <stateless>
>                     <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
>                 </stateless>
>                 <stateful default-access-timeout="10000" cache-ref="passivating"/>
>                 <singleton default-access-timeout="5000"/>
>             </session-bean>
>             <mdb>
>                 <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
>                 <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
>             </mdb>
>             <pools>
>                 <bean-instance-pools>
>                     <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                     <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                 </bean-instance-pools>
>             </pools>
>             <caches>
>                 <cache name="simple" aliases="NoPassivationCache"/>
>                 <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
>             </caches>
>             <passivation-stores>
>                 <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
>             </passivation-stores>
>             <async thread-pool-name="default"/>
>             <timer-service thread-pool-name="default">
>                 <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
>             </timer-service>
>             <remote connector-ref="remoting-connector" thread-pool-name="default"/>
>             <thread-pools>
>                 <thread-pool name="default">
>                     <max-threads count="100"/>
>                     <keepalive-time time="100" unit="milliseconds"/>
>                 </thread-pool>
>             </thread-pools>
>             <iiop enable-by-default="false" use-qualified-name="false"/>
>         </subsystem>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct  3 12:42:00 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Mon, 3 Oct 2016 12:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5069) Missing service to represent
 the TransactionListenerRegistry
In-Reply-To: <JIRA.12580609.1438940968000@Atlassian.JIRA>
References: <JIRA.12580609.1438940968000@Atlassian.JIRA>
	<JIRA.12580609.1438940968000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580609.1438940968000.51455.1475512920221@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated WFLY-5069:
-----------------------------------
    Fix Version/s:     (was: 11.0.0.CR1)


> Missing service to represent the TransactionListenerRegistry
> ------------------------------------------------------------
>
>                 Key: WFLY-5069
>                 URL: https://issues.jboss.org/browse/WFLY-5069
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.Alpha6
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Minor
>
> JBTM-2343 added an observer SPI for tracking transaction state association changes for use by the JPA subsystem. This needs to be available as a wildfly service for consumption by other subsystems (currently JPA casts the TM to get hold of the TransactionListenerRegistry).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 12:46:01 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 3 Oct 2016 12:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.51478.1475513161629@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301798#comment-13301798 ] 

Scott Marlow commented on JASSIST-261:
--------------------------------------

[https://sites.lafayette.edu/newquisk/archives/504] was helpful in renewing my gpg keys :)

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 12:51:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 3 Oct 2016 12:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.51506.1475513460661@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301802#comment-13301802 ] 

Scott Marlow commented on JASSIST-261:
--------------------------------------

3.21.0-GA is now released.

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 12:53:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 3 Oct 2016 12:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7254) pattern-filter disappears if
 predefined-filter is used for configurable-sasl-server-factory in Elytron
 subsystem
In-Reply-To: <JIRA.12652989.1475497944000@Atlassian.JIRA>
References: <JIRA.12652989.1475497944000@Atlassian.JIRA>
	<JIRA.12652989.1475497944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652989.1475497944000.51537.1475513580662@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301806#comment-13301806 ] 

Ilia Vassilev commented on WFLY-7254:
-------------------------------------

Hi [~honza889], do you mind if I work on this one?

> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7254
>                 URL: https://issues.jboss.org/browse/WFLY-7254
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears). 
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 13:49:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 3 Oct 2016 13:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS
 protocol constraints
In-Reply-To: <JIRA.12649336.1473350959000@Atlassian.JIRA>
References: <JIRA.12649336.1473350959000@Atlassian.JIRA>
	<JIRA.12649336.1473350959000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649336.1473350959000.51781.1475516940403@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301826#comment-13301826 ] 

Martin Choma commented on ELY-627:
----------------------------------

I am rising to blocker as it is not possible to use openssl protocols  introduced by https://issues.jboss.org/browse/EAP7-576. For example for openssl.TLSv1.1 we get:
{code}
No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([openssl.TLSv1.1])
{code}

> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
>                 Key: ELY-627
>                 URL: https://issues.jboss.org/browse/ELY-627
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SSL
>    Affects Versions: 1.1.0.Beta8
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> {noformat}
>                        "protocols" => {
>                             "type" => LIST,
>                             "description" => "The enabled protocols.",
>                             "expressions-allowed" => true,
>                             "nillable" => false,
>                             "allowed" => [
>                                 "SSLv2",
>                                 "SSLv3",
>                                 "TLSv1",
>                                 "TLSv1_1",
>                                 "TLSv1_2",
>                                 "TLSv1_3"
>                             ],
>                             "value-type" => STRING,
>                             "access-type" => "read-write",
>                             "storage" => "configuration",
>                             "restart-required" => "resource-services"
>                         },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. 
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/protocols.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 13:49:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 3 Oct 2016 13:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS
 protocol constraints
In-Reply-To: <JIRA.12649336.1473350959000@Atlassian.JIRA>
References: <JIRA.12649336.1473350959000@Atlassian.JIRA>
	<JIRA.12649336.1473350959000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649336.1473350959000.51785.1475516940499@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-627:
-----------------------------
    Priority: Blocker  (was: Critical)


> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
>                 Key: ELY-627
>                 URL: https://issues.jboss.org/browse/ELY-627
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SSL
>    Affects Versions: 1.1.0.Beta8
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> {noformat}
>                        "protocols" => {
>                             "type" => LIST,
>                             "description" => "The enabled protocols.",
>                             "expressions-allowed" => true,
>                             "nillable" => false,
>                             "allowed" => [
>                                 "SSLv2",
>                                 "SSLv3",
>                                 "TLSv1",
>                                 "TLSv1_1",
>                                 "TLSv1_2",
>                                 "TLSv1_3"
>                             ],
>                             "value-type" => STRING,
>                             "access-type" => "read-write",
>                             "storage" => "configuration",
>                             "restart-required" => "resource-services"
>                         },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. 
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/protocols.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 13:57:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Oct 2016 13:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6680) :read-proxies-configuration
 and :read-proxies-info fail when at least one of the proxies is unreachable
In-Reply-To: <JIRA.12495353.1372438436000@Atlassian.JIRA>
References: <JIRA.12495353.1372438436000@Atlassian.JIRA>
	<JIRA.12495353.1372438436000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495353.1372438436000.51893.1475517420328@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301830#comment-13301830 ] 

RH Bugzilla Integration commented on WFLY-6680:
-----------------------------------------------

Peter Mackay <pmackay at redhat.com> changed the Status of [bug 1343633|https://bugzilla.redhat.com/show_bug.cgi?id=1343633] from ON_QA to VERIFIED

> :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6680
>                 URL: https://issues.jboss.org/browse/WFLY-6680
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>         Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch, 
>            Reporter: Kristina Clair
>            Assignee: Radoslav Husar
>              Labels: downstream_dependency
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error.
> On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error.  This is the output from the application host:
> {noformat}
> [domain at localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain at localhost:9999 subsystem=modcluster] :list-proxies
> {
>     "outcome" => "success",
>     "result" => [
>         "web02:8009",
>         "web01:8009"
>     ]
> }
> [domain at localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
>     "rolled-back" => true
> }
> [domain at localhost:9999 subsystem=modcluster] :read-proxies-info
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
>     "rolled-back" => true
> }
> {noformat}
> In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 14:08:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 3 Oct 2016 14:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7254) pattern-filter disappears if
 predefined-filter is used for configurable-sasl-server-factory in Elytron
 subsystem
In-Reply-To: <JIRA.12652989.1475497944000@Atlassian.JIRA>
References: <JIRA.12652989.1475497944000@Atlassian.JIRA>
	<JIRA.12652989.1475497944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652989.1475497944000.51915.1475518080750@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7254:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7254
>                 URL: https://issues.jboss.org/browse/WFLY-7254
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>             Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears). 
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 14:48:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 3 Oct 2016 14:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS
 protocol constraints
In-Reply-To: <JIRA.12649336.1473350959000@Atlassian.JIRA>
References: <JIRA.12649336.1473350959000@Atlassian.JIRA>
	<JIRA.12649336.1473350959000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649336.1473350959000.52022.1475520480249@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301840#comment-13301840 ] 

David Lloyd commented on ELY-627:
---------------------------------

The "openssl.TLSv1.1" is not a valid value for protocol, nor will it be.  I think we may have to revisit EAP7-576 if that is the resolution to that issue; to use OpenSSL it should be a provider selection, not a protocol selection.

> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
>                 Key: ELY-627
>                 URL: https://issues.jboss.org/browse/ELY-627
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SSL
>    Affects Versions: 1.1.0.Beta8
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> {noformat}
>                        "protocols" => {
>                             "type" => LIST,
>                             "description" => "The enabled protocols.",
>                             "expressions-allowed" => true,
>                             "nillable" => false,
>                             "allowed" => [
>                                 "SSLv2",
>                                 "SSLv3",
>                                 "TLSv1",
>                                 "TLSv1_1",
>                                 "TLSv1_2",
>                                 "TLSv1_3"
>                             ],
>                             "value-type" => STRING,
>                             "access-type" => "read-write",
>                             "storage" => "configuration",
>                             "restart-required" => "resource-services"
>                         },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. 
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/protocols.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 15:27:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 3 Oct 2016 15:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1848) Domain server process' main
 thread can terminate without triggering process exit
In-Reply-To: <JIRA.12653043.1475522785000@Atlassian.JIRA>
References: <JIRA.12653043.1475522785000@Atlassian.JIRA>
	<JIRA.12653043.1475522785443@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653043.1475522785000.52119.1475522820188@Atlassian.JIRA>

Brian Stansberry created WFCORE-1848:
----------------------------------------

             Summary: Domain server process' main thread can terminate without triggering process exit
                 Key: WFCORE-1848
                 URL: https://issues.jboss.org/browse/WFCORE-1848
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


If a thread completes the DomainServerMain main(String[] args) method, the process must exit. Currently that may not occur, as this stack trace reported while manually checking the WFCORE-1844 fix showed:

{code}
 
[Server:server-one] 14:15:39,022 ERROR [stderr] (main) Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
[Server:server-one] 14:15:39,023 ERROR [stderr] (main) 	at java.lang.Thread.start0(Native Method)
[Server:server-one] 14:15:39,023 ERROR [stderr] (main) 	at java.lang.Thread.start(Thread.java:714)
[Server:server-one] 14:15:39,023 ERROR [stderr] (main) 	at org.jboss.threads.JBossThread.start(JBossThread.java:342)
[Server:server-one] 14:15:39,023 ERROR [stderr] (main) 	at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
[Server:server-one] 14:15:39,023 ERROR [stderr] (main) 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
[Server:server-one] 14:15:39,023 ERROR [stderr] (main) 	at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
[Server:server-one] 14:15:39,023 ERROR [stderr] (main) 	at org.jboss.as.server.mgmt.domain.HostControllerConnection.asyncReconnect(HostControllerConnection.java:165)
[Server:server-one] 14:15:39,023 ERROR [stderr] (main) 	at org.jboss.as.server.mgmt.domain.HostControllerClient.reconnect(HostControllerClient.java:93)
[Server:server-one] 14:15:39,024 ERROR [stderr] (main) 	at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:151)
[Server:server-one] 14:15:39,024 ERROR [stderr] (main) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[Server:server-one] 14:15:39,024 ERROR [stderr] (main) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[Server:server-one] 14:15:39,024 ERROR [stderr] (main) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[Server:server-one] 14:15:39,024 ERROR [stderr] (main) 	at java.lang.reflect.Method.invoke(Method.java:498)
[Server:server-one] 14:15:39,024 ERROR [stderr] (main) 	at org.jboss.modules.Module.run(Module.java:336)
[Server:server-one] 14:15:39,024 ERROR [stderr] (main) 	at org.jboss.modules.Main.main(Main.java:520)
{code}

If the process does not exit, it is no longer under the control of the PC or HC and the only thing they can do with it is kill it. So it should kill itself.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 17:08:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 3 Oct 2016 17:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7252) war bean not visible for
	injection
In-Reply-To: <JIRA.12652928.1475480246000@Atlassian.JIRA>
References: <JIRA.12652928.1475480246000@Atlassian.JIRA>
	<JIRA.12652928.1475480246000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652928.1475480246000.52329.1475528880339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-7252.
----------------------------------
    Resolution: Rejected


> war bean not visible for injection
> ----------------------------------
>
>                 Key: WFLY-7252
>                 URL: https://issues.jboss.org/browse/WFLY-7252
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Teresa Miyar
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: DemoProjects.zip
>
>
> In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
> Chapter 12. Packaging and dep...
> ? In an application deployed as an ear, the container searches every bean archive bundled with
> or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
> and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
> INF/classes directories.
> Then we have this:
> See also the "5.1. Modularity",
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#selection:
> "A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture."
> "In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."
> But the JavaEE spec states it "may" have access... it did have access on EAP6, does not have access on EAP7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct  3 17:14:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 3 Oct 2016 17:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6680) :read-proxies-configuration
 and :read-proxies-info fail when at least one of the proxies is unreachable
In-Reply-To: <JIRA.12495353.1372438436000@Atlassian.JIRA>
References: <JIRA.12495353.1372438436000@Atlassian.JIRA>
	<JIRA.12495353.1372438436000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495353.1372438436000.52352.1475529240879@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-6680:
---------------------------------
    Comment: was deleted

(was: Peter Mackay <pmackay at redhat.com> changed the Status of [bug 1343633|https://bugzilla.redhat.com/show_bug.cgi?id=1343633] from ON_QA to VERIFIED)


> :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6680
>                 URL: https://issues.jboss.org/browse/WFLY-6680
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>         Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch, 
>            Reporter: Kristina Clair
>            Assignee: Radoslav Husar
>              Labels: downstream_dependency
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error.
> On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error.  This is the output from the application host:
> {noformat}
> [domain at localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain at localhost:9999 subsystem=modcluster] :list-proxies
> {
>     "outcome" => "success",
>     "result" => [
>         "web02:8009",
>         "web01:8009"
>     ]
> }
> [domain at localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
>     "rolled-back" => true
> }
> [domain at localhost:9999 subsystem=modcluster] :read-proxies-info
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
>     "rolled-back" => true
> }
> {noformat}
> In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 17:14:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 3 Oct 2016 17:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6680) :read-proxies-configuration
 and :read-proxies-info fail when at least one of the proxies is unreachable
In-Reply-To: <JIRA.12495353.1372438436000@Atlassian.JIRA>
References: <JIRA.12495353.1372438436000@Atlassian.JIRA>
	<JIRA.12495353.1372438436000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495353.1372438436000.52359.1475529241187@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-6680:
---------------------------------
    Comment: was deleted

(was: Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1343633|https://bugzilla.redhat.com/show_bug.cgi?id=1343633] from MODIFIED to ON_QA)


> :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6680
>                 URL: https://issues.jboss.org/browse/WFLY-6680
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>         Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch, 
>            Reporter: Kristina Clair
>            Assignee: Radoslav Husar
>              Labels: downstream_dependency
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error.
> On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error.  This is the output from the application host:
> {noformat}
> [domain at localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain at localhost:9999 subsystem=modcluster] :list-proxies
> {
>     "outcome" => "success",
>     "result" => [
>         "web02:8009",
>         "web01:8009"
>     ]
> }
> [domain at localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
>     "rolled-back" => true
> }
> [domain at localhost:9999 subsystem=modcluster] :read-proxies-info
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
>     "rolled-back" => true
> }
> {noformat}
> In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 17:14:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 3 Oct 2016 17:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6680) :read-proxies-configuration
 and :read-proxies-info fail when at least one of the proxies is unreachable
In-Reply-To: <JIRA.12495353.1372438436000@Atlassian.JIRA>
References: <JIRA.12495353.1372438436000@Atlassian.JIRA>
	<JIRA.12495353.1372438436000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495353.1372438436000.52365.1475529241405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-6680:
---------------------------------
    Comment: was deleted

(was: Aaron Ogburn <aogburn at redhat.com> changed the Status of [bug 1343633|https://bugzilla.redhat.com/show_bug.cgi?id=1343633] from ASSIGNED to POST)


> :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6680
>                 URL: https://issues.jboss.org/browse/WFLY-6680
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>         Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch, 
>            Reporter: Kristina Clair
>            Assignee: Radoslav Husar
>              Labels: downstream_dependency
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error.
> On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error.  This is the output from the application host:
> {noformat}
> [domain at localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain at localhost:9999 subsystem=modcluster] :list-proxies
> {
>     "outcome" => "success",
>     "result" => [
>         "web02:8009",
>         "web01:8009"
>     ]
> }
> [domain at localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
>     "rolled-back" => true
> }
> [domain at localhost:9999 subsystem=modcluster] :read-proxies-info
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
>     "rolled-back" => true
> }
> {noformat}
> In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 17:14:01 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 3 Oct 2016 17:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7252) war bean not visible for
	injection
In-Reply-To: <JIRA.12652928.1475480246000@Atlassian.JIRA>
References: <JIRA.12652928.1475480246000@Atlassian.JIRA>
	<JIRA.12652928.1475480246000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652928.1475480246000.52369.1475529241561@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301880#comment-13301880 ] 

Stuart Douglas commented on WFLY-7252:
--------------------------------------

Relevant spec sections:

CDI 5.1

"A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture. In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."

>From the Java EE spec EE.8.3.1:

"Components in the web container must not have access to the following classes and resources, unless such classes or resources are covered by one of the rules above.
? Other classes or resources in the application package. For example, the appli- cation should not have access to the classes in application client jar files."

This means that wars cannot see the contents of other wars, and beans deployed in the them are not available for injection outside the war. 






> war bean not visible for injection
> ----------------------------------
>
>                 Key: WFLY-7252
>                 URL: https://issues.jboss.org/browse/WFLY-7252
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Teresa Miyar
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: DemoProjects.zip
>
>
> In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
> Chapter 12. Packaging and dep...
> ? In an application deployed as an ear, the container searches every bean archive bundled with
> or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
> and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
> INF/classes directories.
> Then we have this:
> See also the "5.1. Modularity",
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#selection:
> "A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture."
> "In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."
> But the JavaEE spec states it "may" have access... it did have access on EAP6, does not have access on EAP7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct  3 17:15:02 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 3 Oct 2016 17:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7034) JDR is not collecting the
 file .overlays, layer.conf, version.txt config files
In-Reply-To: <JIRA.12648524.1472847780000@Atlassian.JIRA>
References: <JIRA.12648524.1472847780000@Atlassian.JIRA>
	<JIRA.12648524.1472847780000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648524.1472847780000.52372.1475529302981@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301881#comment-13301881 ] 

RH Bugzilla Integration commented on WFLY-7034:
-----------------------------------------------

Peter Mackay <pmackay at redhat.com> changed the Status of [bug 1372781|https://bugzilla.redhat.com/show_bug.cgi?id=1372781] from ON_QA to VERIFIED

> JDR is not collecting the file .overlays, layer.conf, version.txt config files
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7034
>                 URL: https://issues.jboss.org/browse/WFLY-7034
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>    Affects Versions: 10.1.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> The JDR report when collecting files should be collecting
> $JBOSS_HOME/modules/system/layers/base/.overlays/.overlays
> $JBOSS_HOME/.installation/identity.conf
> $JBOSS_HOME/.installation/layers/base/layer.conf
> $JBOSS_HOME/.installation/patches/*/misc/version.txt
> This file is needed to confirm overlay priority and other layer configurations to make sure the installation is not corrupted.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 19:50:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 3 Oct 2016 19:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1849) Wildfly OpenSSL 1.0.0.Alpha2
In-Reply-To: <JIRA.12653059.1475538591000@Atlassian.JIRA>
References: <JIRA.12653059.1475538591000@Atlassian.JIRA>
	<JIRA.12653059.1475538591106@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653059.1475538591000.52709.1475538600097@Atlassian.JIRA>

Stuart Douglas created WFCORE-1849:
--------------------------------------

             Summary: Wildfly OpenSSL 1.0.0.Alpha2
                 Key: WFCORE-1849
                 URL: https://issues.jboss.org/browse/WFCORE-1849
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 19:54:00 2016
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Mon, 3 Oct 2016 19:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.52719.1475538840726@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301904#comment-13301904 ] 

Shigeru Chiba commented on JASSIST-261:
---------------------------------------

Thank you, Scott!

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 20:28:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 3 Oct 2016 20:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7254) pattern-filter disappears if
 predefined-filter is used for configurable-sasl-server-factory in Elytron
 subsystem
In-Reply-To: <JIRA.12652989.1475497944000@Atlassian.JIRA>
References: <JIRA.12652989.1475497944000@Atlassian.JIRA>
	<JIRA.12652989.1475497944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652989.1475497944000.52732.1475540880290@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301908#comment-13301908 ] 

Ilia Vassilev commented on WFLY-7254:
-------------------------------------

[~olukas]: We expect the filters as a list so I think that the CLI command should be:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*)},{predefined-filter=BINDING}])
{code}

If you have to set "enabling" attribute:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*), enabling="false"},{predefined-filter=BINDING}])
{code}

> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7254
>                 URL: https://issues.jboss.org/browse/WFLY-7254
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>             Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears). 
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 22:29:00 2016
From: issues at jboss.org (Steve Ebersole (JIRA))
Date: Mon, 3 Oct 2016 22:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.52800.1475548140477@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301916#comment-13301916 ] 

Steve Ebersole commented on JASSIST-261:
----------------------------------------

To be clear, this 3.21.0-GA release does not support Java 9, right?

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct  3 22:31:00 2016
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Mon, 3 Oct 2016 22:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.52822.1475548260888@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301918#comment-13301918 ] 

Shigeru Chiba commented on JASSIST-261:
---------------------------------------

No, I'll make 3.22.0-CR1 soon (tonight?).  It supports Java 9.

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 00:04:00 2016
From: issues at jboss.org (Matt Smith (JIRA))
Date: Tue, 4 Oct 2016 00:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not
 being created
In-Reply-To: <JIRA.12652843.1475249181000@Atlassian.JIRA>
References: <JIRA.12652843.1475249181000@Atlassian.JIRA>
	<JIRA.12652843.1475249181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652843.1475249181000.52881.1475553840887@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301923#comment-13301923 ] 

Matt Smith commented on WFLY-7247:
----------------------------------

I have also been experiencing this issue on Wildfly 9.0.1 and 9.0.2 (and 10).  For me a single app out of about 8 that are deployed on the server always comes up without the SSO mechanism registered after a service restart.  The other apps never exhibit this issue.  Disabling and re-enabling the app brings it up with SSO registered.  This pattern is 100% reliable - it happens on both nodes of our 2-node UAT cluster and all three nodes of our production cluster.  Having a HTTPd reverse proxy server in front of the Wildfly server seems to trigger the behaviour.

> Wildfly 10 JSESSIONIDSSOs not being created
> -------------------------------------------
>
>                 Key: WFLY-7247
>                 URL: https://issues.jboss.org/browse/WFLY-7247
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: M Wardell
>            Assignee: Jason Greene
>
> Found on wildfly 10.1 and 10.0.  With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism.  Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service.
> Issue in intermittent on startup.  After most startups the JESSSIONIDSSO is reliably generated during login.  After some startups the JSESSIONIDSSO is never created after login.
> Details in the referenced forum thread.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 00:49:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 4 Oct 2016 00:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7193) No log messages comming from
 Elytron - ssl context creation
In-Reply-To: <JIRA.12651499.1474551058000@Atlassian.JIRA>
References: <JIRA.12651499.1474551058000@Atlassian.JIRA>
	<JIRA.12651499.1474551058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651499.1474551058000.52960.1475556540387@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7193:
-----------------------------
    Description: Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.Seems to me it would be useful for troubleshooting to have logged on TRACE level:- Keystore initialization with parameters- Filtering keystore initialization with parameters- KeyManager / TrustManager initialization with parameters- Client / Server SSLContext initialization with parametersWARN level:- Certificate expired (on key store init, all certificates)  (was: Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.

Seems to me it would be useful for troubleshooting to have logged on TRACE level:
- Keystore initialization with parameters
- Filtering keystore initialization with parameters
- KeyManager / TrustManager initialization with parameters
- Client / Server SSLContext initialization with parameters

)


> No log messages comming from Elytron - ssl context creation
> -----------------------------------------------------------
>
>                 Key: WFLY-7193
>                 URL: https://issues.jboss.org/browse/WFLY-7193
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>
> Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.Seems to me it would be useful for troubleshooting to have logged on TRACE level:- Keystore initialization with parameters- Filtering keystore initialization with parameters- KeyManager / TrustManager initialization with parameters- Client / Server SSLContext initialization with parametersWARN level:- Certificate expired (on key store init, all certificates)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 00:50:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 4 Oct 2016 00:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7193) No log messages comming from
 Elytron - ssl context creation
In-Reply-To: <JIRA.12651499.1474551058000@Atlassian.JIRA>
References: <JIRA.12651499.1474551058000@Atlassian.JIRA>
	<JIRA.12651499.1474551058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651499.1474551058000.52966.1475556600344@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7193:
-----------------------------
    Description: 
Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.

Seems to me it would be useful for troubleshooting to have logged on 
TRACE level:
- Keystore initialization with parameters
- Filtering keystore initialization with parameters
- KeyManager / TrustManager initialization with parameters
- Client / Server SSLContext initialization with parameters

WARN level:
- Certificate expired (on key store init, all certificates)

  was:Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.Seems to me it would be useful for troubleshooting to have logged on TRACE level:- Keystore initialization with parameters- Filtering keystore initialization with parameters- KeyManager / TrustManager initialization with parameters- Client / Server SSLContext initialization with parametersWARN level:- Certificate expired (on key store init, all certificates)



> No log messages comming from Elytron - ssl context creation
> -----------------------------------------------------------
>
>                 Key: WFLY-7193
>                 URL: https://issues.jboss.org/browse/WFLY-7193
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>
> Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.
> Seems to me it would be useful for troubleshooting to have logged on 
> TRACE level:
> - Keystore initialization with parameters
> - Filtering keystore initialization with parameters
> - KeyManager / TrustManager initialization with parameters
> - Client / Server SSLContext initialization with parameters
> WARN level:
> - Certificate expired (on key store init, all certificates)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 01:21:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 4 Oct 2016 01:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7254) pattern-filter disappears if
 predefined-filter is used for configurable-sasl-server-factory in Elytron
 subsystem
In-Reply-To: <JIRA.12652989.1475497944000@Atlassian.JIRA>
References: <JIRA.12652989.1475497944000@Atlassian.JIRA>
	<JIRA.12652989.1475497944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652989.1475497944000.52985.1475558460456@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301933#comment-13301933 ] 

Ondrej Lukas commented on WFLY-7254:
------------------------------------

[~ivassile] In case when CLI commands should look like you mentioned in previous comments then command:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*),predefined-filter=BINDING}])
{code}
should lead to "outcome" => "failed".

Currently that command results to store both pattern-filter and predefined-filter in dynamic model, but only predefined-filter is stored in configuration. You can try:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*),predefined-filter=BINDING}])
{code}
then calling read-attribute operation is successful for both attribute:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:read-attribute(name=filters[0].pattern-filter)
{
    "outcome" => "success",
    "result" => "(.*)"
}
{code}
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:read-attribute(name=filters[0].predefined-filter)
{
    "outcome" => "success",
    "result" => "BINDING"
}
{code}
However after {{reload}} pattern-filter disappears:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:read-attribute(name=filters[0].pattern-filter)
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => "WFLYCTL0393: Could not resolve attribute expression: 'filters[0].pattern-filter'",
    "rolled-back" => true
}
{code}

You should also note, that following part of configuration can be correctly loaded when server is started:
{code}
<configurable-sasl-server-factory name="someFactory" sasl-server-factory="global">
    <filters>
        <filter>
            <pattern-filter value="(someFilter)"/>
            <predefined-filter value="BINDING"/>
        </filter>
    </filters>
</configurable-sasl-server-factory>
{code}

> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7254
>                 URL: https://issues.jboss.org/browse/WFLY-7254
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>             Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears). 
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 01:50:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 4 Oct 2016 01:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2106) Prepare for JDK 9
In-Reply-To: <JIRA.12653070.1475560165000@Atlassian.JIRA>
References: <JIRA.12653070.1475560165000@Atlassian.JIRA>
	<JIRA.12653070.1475560165483@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653070.1475560165000.53026.1475560200551@Atlassian.JIRA>

Bela Ban created JGRP-2106:
------------------------------

             Summary: Prepare for JDK 9
                 Key: JGRP-2106
                 URL: https://issues.jboss.org/browse/JGRP-2106
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0


Investigate the changes needed to run with JDK 9. Probably module.info classes are all that's needed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 02:56:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 4 Oct 2016 02:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7259) Review elytron
 kerberos-security-factory resource
In-Reply-To: <JIRA.12653077.1475564091000@Atlassian.JIRA>
References: <JIRA.12653077.1475564091000@Atlassian.JIRA>
	<JIRA.12653077.1475564091000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653077.1475564091000.53196.1475564160514@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6287 to WFLY-7259:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7259  (was: JBEAP-6287)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Review elytron kerberos-security-factory resource
> -------------------------------------------------
>
>                 Key: WFLY-7259
>                 URL: https://issues.jboss.org/browse/WFLY-7259
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>
> * {{mechanism-oids}}
> 	** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code}
> 	** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here. 
> * {{minimum-remaining-lifetime}}
> 	** please, specify units in documentation, e.g. seconds/minutes
> * {{relative-to}}
> 	** as just path reference can be used here, probably should be just "expressions-allowed" => false
> 	** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute."
> * {{server}}
> 	** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation.	
> * {{for-hosts}}
> 	** comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 04:30:00 2016
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 4 Oct 2016 04:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1850) Failed to process logging
 directory /. Log files cannot be listed
In-Reply-To: <JIRA.12653097.1475569783000@Atlassian.JIRA>
References: <JIRA.12653097.1475569783000@Atlassian.JIRA>
	<JIRA.12653097.1475569783946@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653097.1475569783000.53610.1475569800926@Atlassian.JIRA>

Heiko Braun created WFCORE-1850:
-----------------------------------

             Summary: Failed to process logging directory /. Log files cannot be listed
                 Key: WFCORE-1850
                 URL: https://issues.jboss.org/browse/WFCORE-1850
             Project: WildFly Core
          Issue Type: Bug
            Reporter: Heiko Braun






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 04:37:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 4 Oct 2016 04:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1317) Missing MBean for Classpath
 KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
In-Reply-To: <JIRA.12653102.1475570175000@Atlassian.JIRA>
References: <JIRA.12653102.1475570175000@Atlassian.JIRA>
	<JIRA.12653102.1475570175857@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653102.1475570175000.53669.1475570220126@Atlassian.JIRA>

Matteo Mortari created DROOLS-1317:
--------------------------------------

             Summary: Missing MBean for Classpath KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
                 Key: DROOLS-1317
                 URL: https://issues.jboss.org/browse/DROOLS-1317
             Project: Drools
          Issue Type: Bug
          Components: core engine, integration
    Affects Versions: 6.5.0.CR2, 7.0.0.Beta1
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


As RHQ/JON is able to discover the MBean for the KieBase and KieSession but unable to locate the MXBean for the KieContainer, would fail to display the whole hierarchy.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 04:52:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 4 Oct 2016 04:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1316) Missing MBean for Classpath
 KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
In-Reply-To: <JIRA.12653001.1475500691000@Atlassian.JIRA>
References: <JIRA.12653001.1475500691000@Atlassian.JIRA>
	<JIRA.12653001.1475500691000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653001.1475500691000.53770.1475571120110@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-1316:
-----------------------------------
    Attachment: solved.png


> Missing MBean for Classpath KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1316
>                 URL: https://issues.jboss.org/browse/DROOLS-1316
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine, integration
>    Affects Versions: 6.5.0.CR2, 7.0.0.Beta1
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>         Attachments: solved.png
>
>
> As RHQ/JON is able to discover the MBean for the KieBase and KieSession but unable to locate the MXBean for the KieContainer, would fail to display the whole hierarchy.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 04:54:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 4 Oct 2016 04:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1316) Missing MBean for Classpath
 KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
In-Reply-To: <JIRA.12653001.1475500691000@Atlassian.JIRA>
References: <JIRA.12653001.1475500691000@Atlassian.JIRA>
	<JIRA.12653001.1475500691000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653001.1475500691000.53777.1475571240204@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302023#comment-13302023 ] 

Matteo Mortari commented on DROOLS-1316:
----------------------------------------

This solves the problem of RHQ/JON unable to discover the 1st level parent MXBean for the KieContainer making the MXBean available also when the KieContainer is created from the Classpath, the full 3-level hierarchy is built. 

Functional test with RHQ:
!solved.png|thumbnail!
In the screenshot, the Jconsole and JVisualVM is showing the reference nesting of the 3 level, and the actual result on RHQ corresponds correctly. This screenshot has been taken using the demo application(1) using the Classpath KieContainer:

{code:java}
public static void main(String[] args) {
    KieServices ks = KieServices.Factory.get();
    KieContainer kcontainer = ks.getKieClasspathContainer("abcContainer");

    KieSession ksession = kcontainer.newKieSession("rules-session");
    ...
}
{code}

(1) https://github.com/jomarko/drools-project

> Missing MBean for Classpath KieContainer causes RHQ/JON plug-in failure to display the whole hierarchy
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1316
>                 URL: https://issues.jboss.org/browse/DROOLS-1316
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine, integration
>    Affects Versions: 6.5.0.CR2, 7.0.0.Beta1
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>             Fix For: 6.5.0.Final, 7.0.0.Beta3, 7.0.0.Final
>
>         Attachments: solved.png
>
>
> As RHQ/JON is able to discover the MBean for the KieBase and KieSession but unable to locate the MXBean for the KieContainer, would fail to display the whole hierarchy.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 05:16:01 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 4 Oct 2016 05:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.53898.1475572561229@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6289 to WFLY-7260:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7260  (was: JBEAP-6289)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Document in model *-client-auth are mutual exclusive
> ----------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 05:17:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 4 Oct 2016 05:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in elytron model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.53906.1475572620618@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-7260:
-------------------------------
    Summary: Document in elytron model *-client-auth are mutual exclusive  (was: Document in model *-client-auth are mutual exclusive)


> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 05:33:00 2016
From: issues at jboss.org (Juergen Weber (JIRA))
Date: Tue, 4 Oct 2016 05:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6931) add implicit module
 dependency to configuration directory
In-Reply-To: <JIRA.12642577.1470742959000@Atlassian.JIRA>
References: <JIRA.12642577.1470742959000@Atlassian.JIRA>
	<JIRA.12642577.1470742959000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642577.1470742959000.53984.1475573580357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen Weber resolved WFLY-6931.
---------------------------------
    Resolution: Won't Fix


One can use 
<subsystem xmlns="urn:jboss:domain:ee:1.2">
  <global-modules>

> add implicit module dependency to configuration directory
> ---------------------------------------------------------
>
>                 Key: WFLY-6931
>                 URL: https://issues.jboss.org/browse/WFLY-6931
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Class Loading
>    Affects Versions: 10.1.0.CR1
>            Reporter: Juergen Weber
>            Assignee: David Lloyd
>
> Best practice for loading of property files is via classloading.
> Many applications try to load a custom properties file via class loading (e.g. Apache JSPWiki tries to load /jspwiki-custom.properties). With Tomcat, you simply drop property files into tomcat/lib.
> For Wildfly, you have to create a module and add a jboss-dependency.xml to the application:
> https://developer.jboss.org/wiki/HowToPutAnExternalFileInTheClasspath
> Wildfly should have resource folder which by default should be added to the classpath of all applications, i.e. should be an implicit dependency. At least one should be able to switch this on in standalone.xml
> The folder could be standalone/configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 05:52:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 4 Oct 2016 05:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7261) Upgrade jackson-core to
 version that has fix for WFLY-7037
In-Reply-To: <JIRA.12653116.1475574712000@Atlassian.JIRA>
References: <JIRA.12653116.1475574712000@Atlassian.JIRA>
	<JIRA.12653116.1475574712832@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653116.1475574712000.54066.1475574720207@Atlassian.JIRA>

Tomaz Cerar created WFLY-7261:
---------------------------------

             Summary: Upgrade jackson-core to version that has fix for WFLY-7037
                 Key: WFLY-7261
                 URL: https://issues.jboss.org/browse/WFLY-7261
             Project: WildFly
          Issue Type: Component Upgrade
          Components: REST
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Upgrade to jackson that has fix for memory leak found in WFLY-7037



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 05:54:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 4 Oct 2016 05:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7262) Upgrade jackson-core to
 version that has fix for JBEAP-5870
In-Reply-To: <JIRA.12653117.1475574815000@Atlassian.JIRA>
References: <JIRA.12653117.1475574815000@Atlassian.JIRA>
	<JIRA.12653117.1475574815163@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653117.1475574815000.54078.1475574840300@Atlassian.JIRA>

Tomaz Cerar created WFLY-7262:
---------------------------------

             Summary: Upgrade jackson-core to version that has fix for JBEAP-5870
                 Key: WFLY-7262
                 URL: https://issues.jboss.org/browse/WFLY-7262
             Project: WildFly
          Issue Type: Component Upgrade
          Components: REST
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Upgrade to jackson that has fix for memory leak found in WFLY-7037



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 05:57:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 4 Oct 2016 05:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7261) Upgrade jackson to version
 that has fix for WFLY-7037
In-Reply-To: <JIRA.12653116.1475574713000@Atlassian.JIRA>
References: <JIRA.12653116.1475574713000@Atlassian.JIRA>
	<JIRA.12653116.1475574713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653116.1475574713000.54114.1475575020655@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7261:
------------------------------
    Summary: Upgrade jackson to version that has fix for WFLY-7037  (was: Upgrade jackson-core to version that has fix for WFLY-7037)


> Upgrade jackson to version that has fix for WFLY-7037
> -----------------------------------------------------
>
>                 Key: WFLY-7261
>                 URL: https://issues.jboss.org/browse/WFLY-7261
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: REST
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> Upgrade to jackson that has fix for memory leak found in WFLY-7037



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 06:57:00 2016
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Tue, 4 Oct 2016 06:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5239)
 XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5%
 cases with "no physical address for"
In-Reply-To: <JIRA.12583312.1441035651000@Atlassian.JIRA>
References: <JIRA.12583312.1441035651000@Atlassian.JIRA>
	<JIRA.12583312.1441035651000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583312.1441035651000.54367.1475578620574@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302107#comment-13302107 ] 

Petr Kremensky commented on WFLY-5239:
--------------------------------------

The test fails if -Dnode0 (MYTESTIP_1 != localhost) is used:
{noformat}
./integration-tests.sh -Dts.noSmoke -Dts.clustering -Dtest=XSiteSimpleTestCase -Dnode0=$MYTESTIP_1
{noformat}
{noformat}
Running org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 64.527 sec <<< FAILURE! - in org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
testPutRelayedToBackups(org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase)  Time elapsed: 48.265 sec  <<< FAILURE!
java.lang.AssertionError: expected:<200> but was:<500>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotEquals(Assert.java:834)
	at org.junit.Assert.assertEquals(Assert.java:645)
	at org.junit.Assert.assertEquals(Assert.java:631)
	at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutRelayedToBackups(XSiteSimpleTestCase.java:144)


Results :

Failed tests: 
  XSiteSimpleTestCase.testPutRelayedToBackups:144 expected:<200> but was:<500>
{noformat}

> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5239
>                 URL: https://issues.jboss.org/browse/WFLY-5239
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar		&amp#27;[0m&amp#27;[0m15:14:52,808 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &amp#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &amp#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:03,277 WARN  [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &amp#27;[0mExecuted HTTP request
> &amp#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message			17:02
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 07:10:00 2016
From: issues at jboss.org (M G (JIRA))
Date: Tue, 4 Oct 2016 07:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6895) TimerService
	problem(duplicated resource)
In-Reply-To: <JIRA.12641244.1469792648000@Atlassian.JIRA>
References: <JIRA.12641244.1469792648000@Atlassian.JIRA>
	<JIRA.12641244.1469792648000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641244.1469792648000.54461.1475579400398@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302127#comment-13302127 ] 

M G commented on WFLY-6895:
---------------------------

What is the status of this issue? Was the fix reviewed? Will it be included in the nearest release?

> TimerService problem(duplicated resource)
> -----------------------------------------
>
>                 Key: WFLY-6895
>                 URL: https://issues.jboss.org/browse/WFLY-6895
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>         Environment: Two standalone instances connected into a cluster.
> *Master WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master
> {code}
> *Slave WildFly*
> {code}
> standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100
> {code}
> Both instances has the same singleton policy defined in singleton-full-ha.xml:
> {code}
> <singleton-policy name="scada-singleton" cache-container="server">
>   <simple-election-policy>
>     <name-preferences>master</name-preferences>
>   </simple-election-policy>
> </singleton-policy>
> {code}
>            Reporter: Artur Kowalczyk
>            Assignee: Tomasz Adamski
>
> I found a problem with TimerService that occurs when your application is configured as a singleton deployment.
> *Test Case*
> # Start master node, the app is also started - OK
> # Start slave node, the app is deployed but bot stared - OK
> # Stop master node, the app is started on slave - OK
> # Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK
> # Stop master node, the app should be started again on slave but an exception occur. - ERROR
> {code}
> 09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear"  
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)  
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)  
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)  
>         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)  
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB  
>         at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82)  
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)  
>         ... 5 more  
> Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service  
>         at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)  
>         at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)  
>         at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322)  
>         at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219)  
>         at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119)  
>         at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79)  
>         ... 6 more 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 07:35:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 4 Oct 2016 07:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-21) Use Woodstox as the StAX
	engine
In-Reply-To: <JIRA.12653142.1475580894000@Atlassian.JIRA>
References: <JIRA.12653142.1475580894000@Atlassian.JIRA>
	<JIRA.12653142.1475580894588@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653142.1475580894000.54744.1475580900399@Atlassian.JIRA>

Jeff Mesnil created WFBUILD-21:
----------------------------------

             Summary: Use Woodstox as the StAX engine
                 Key: WFBUILD-21
                 URL: https://issues.jboss.org/browse/WFBUILD-21
             Project: WildFly Build Tools
          Issue Type: Enhancement
    Affects Versions: 1.1.3.Final
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil


WildFly's XML persister uses Woodstox as its StAX engine.
By using the same engine for the build tools (especially its maven plug-in), we ensure that the XML generated by the build tools is identical to the XML generated by WildFly's XML persister.

Otherwise, there are differences in the XML declaration (WildFly persisted file have the encoding attribute while the XML generated by the build tools does not).




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 08:06:01 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Oct 2016 08:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1668)
 org.jboss.modules.ModuleNotFoundException when setting annotations=true in
 jboss-deployment-structure.xml
In-Reply-To: <JIRA.12639986.1469062059000@Atlassian.JIRA>
References: <JIRA.12639986.1469062059000@Atlassian.JIRA>
	<JIRA.12639986.1469062059000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639986.1469062059000.55055.1475582761232@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302201#comment-13302201 ] 

RH Bugzilla Integration commented on WFCORE-1668:
-------------------------------------------------

Ivo Hradek <ihradek at redhat.com> changed the Status of [bug 1358556|https://bugzilla.redhat.com/show_bug.cgi?id=1358556] from ON_QA to VERIFIED

> org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1668
>                 URL: https://issues.jboss.org/browse/WFCORE-1668
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 3.0.0.Alpha4
>
>         Attachments: reproducer.zip
>
>
> {code}
> helloWorld.ear 
>  - helloWorld-ejb.jar
>     - HelloBean - @Stateless EJB extends AbstractBean
>  - lib 
>   - helloWorld-api.jar
>     - META-INF
>       - jandex.idx
>     - Hello - EJB interface
>     - AbstractBean - abstract class which has @PostConstruct and implements Hello
> helloWorld2.ear
>  - helloWorld2-ejb.jar
>    - HelloBean2 - @Startup @Singleton extends AbstractBean
>  - META-INF
>   - jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
> {code}
> To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
> When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled).  When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
> It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
> {code}
> 19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	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)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> 	at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> 	... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> 	at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> 	at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
> 	... 6 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 08:27:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 4 Oct 2016 08:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in elytron model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.55288.1475584020709@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7260:
-----------------------------------

    Assignee: Ilia Vassilev


> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 08:30:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 4 Oct 2016 08:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1851) Inconsistent behaviour with
 browse-content(depth=1) operation between archived and exploded deployments
In-Reply-To: <JIRA.12653148.1475584120000@Atlassian.JIRA>
References: <JIRA.12653148.1475584120000@Atlassian.JIRA>
	<JIRA.12653148.1475584120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653148.1475584120000.55324.1475584200355@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved JBEAP-6294 to WFCORE-1851:
-------------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-1851  (was: JBEAP-6294)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s: 3.0.0.Alpha9
                           (was: 7.1.0.DR5)
                           (was: 7.1.0.DR6)


> Inconsistent behaviour with browse-content(depth=1) operation between archived and exploded deployments
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1851
>                 URL: https://issues.jboss.org/browse/WFCORE-1851
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: ehsavoie Hugonnet
>         Attachments: jboss-kitchensink-ear.ear
>
>
> {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} operation returns inconsistent result depending on whether the deployment is exploded or not. Deployment attached.
> Archived:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         }
>     ]
> }
> {code}
> Exploded:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 08:42:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 4 Oct 2016 08:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1052) Add server-config parameter
 to :reload op
In-Reply-To: <JIRA.12588893.1444737333000@Atlassian.JIRA>
References: <JIRA.12588893.1444737333000@Atlassian.JIRA>
	<JIRA.12588893.1444737333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588893.1444737333000.55503.1475584920304@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302231#comment-13302231 ] 

Brian Stansberry commented on WFCORE-1052:
------------------------------------------

Note that this behavior is problematic for the domain config in the context of an HA DC feature (WFCORE-338). It adds another path via which the domain-wide config can be changed underneath the cluster of HCs that are attempting to ensure that the domain is using the correct config.

> Add server-config parameter to :reload op
> -----------------------------------------
>
>                 Key: WFCORE-1052
>                 URL: https://issues.jboss.org/browse/WFCORE-1052
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 3.0.0.Alpha1
>
>
> {code}
> [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml
 looks for that file in the snapshots directory
> [13:48] Kabir Khan: 
> [standalone at localhost:9990 /] :list-snapshots
> 		{
>     "outcome" => "success",
>     "result" => {
>         "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot",
>         "names" => [
>             "20151013-134523280standalone.xml",
>             "20151013-134726769standalone.xml"
>         ]
>     }
> 		}
> 		Show less
> [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation
> {code}
> Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail. 
> For a domain server, we should not have the server-config parameter.
> We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct  4 09:15:03 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 4 Oct 2016 09:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5239)
 XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5%
 cases with "no physical address for"
In-Reply-To: <JIRA.12583312.1441035651000@Atlassian.JIRA>
References: <JIRA.12583312.1441035651000@Atlassian.JIRA>
	<JIRA.12583312.1441035651000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583312.1441035651000.55952.1475586903945@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302295#comment-13302295 ] 

Radoslav Husar commented on WFLY-5239:
--------------------------------------

[~pkremens] thanks for the update, but this issue is unrelated to the intermittent failures. 

Nevertheless, there are 4 nodes in this test case, so specifying binding node0 and node1 to different interfaces (depending on the setup) the LON site will not cluster and the test will fail as per your paste.

Specifying all 4 addresses does work, e.g.
{quote}
[rhusar at syrah wildfly]$ ./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Dtest=org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase -Dnode0=192.168.0.7 -Dnode1=192.168.0.7 -Dnode2=192.168.0.7 -Dnode3=192.168.0.7
{quote}

> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5239
>                 URL: https://issues.jboss.org/browse/WFLY-5239
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar		&amp#27;[0m&amp#27;[0m15:14:52,808 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &amp#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &amp#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:03,277 WARN  [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &amp#27;[0mExecuted HTTP request
> &amp#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message			17:02
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 09:15:04 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 4 Oct 2016 09:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5239)
 XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5%
 cases with "no physical address for"
In-Reply-To: <JIRA.12583312.1441035651000@Atlassian.JIRA>
References: <JIRA.12583312.1441035651000@Atlassian.JIRA>
	<JIRA.12583312.1441035651000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583312.1441035651000.55967.1475586904654@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302295#comment-13302295 ] 

Radoslav Husar edited comment on WFLY-5239 at 10/4/16 9:14 AM:
---------------------------------------------------------------

[~pkremens] thanks for the update, but this issue is unrelated to the intermittent failures. 

Nevertheless, there are 4 nodes in this test case, so specifying binding node0 and node1 to different interfaces (depending on the setup) the LON site will not cluster (or the tcp-bridge) and the test will fail as per your paste.

Specifying all 4 addresses does work, e.g.
{quote}
[rhusar at syrah wildfly]$ ./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Dtest=org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase -Dnode0=192.168.0.7 -Dnode1=192.168.0.7 -Dnode2=192.168.0.7 -Dnode3=192.168.0.7
{quote}


was (Author: rhusar):
[~pkremens] thanks for the update, but this issue is unrelated to the intermittent failures. 

Nevertheless, there are 4 nodes in this test case, so specifying binding node0 and node1 to different interfaces (depending on the setup) the LON site will not cluster and the test will fail as per your paste.

Specifying all 4 addresses does work, e.g.
{quote}
[rhusar at syrah wildfly]$ ./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -Dtest=org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase -Dnode0=192.168.0.7 -Dnode1=192.168.0.7 -Dnode2=192.168.0.7 -Dnode3=192.168.0.7
{quote}

> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5239
>                 URL: https://issues.jboss.org/browse/WFLY-5239
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar		&amp#27;[0m&amp#27;[0m15:14:52,808 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &amp#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &amp#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:03,277 WARN  [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &amp#27;[0mExecuted HTTP request
> &amp#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message			17:02
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 09:50:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 4 Oct 2016 09:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-168) Release new version of
 jboss-annotations-api_1.2_spec
In-Reply-To: <JIRA.12653172.1475588990000@Atlassian.JIRA>
References: <JIRA.12653172.1475588990000@Atlassian.JIRA>
	<JIRA.12653172.1475588990296@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653172.1475588990000.56277.1475589000945@Atlassian.JIRA>

Tomas Remes created JBEE-168:
--------------------------------

             Summary: Release new version of jboss-annotations-api_1.2_spec
                 Key: JBEE-168
                 URL: https://issues.jboss.org/browse/JBEE-168
             Project: JBoss JavaEE Spec APIs
          Issue Type: Task
          Components: jboss-annotations-api
            Reporter: Tomas Remes
            Assignee: Scott Marlow


There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annotation-api%7C1.3%7Cjar recently



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 09:57:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 4 Oct 2016 09:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7150) EJB injection with
 indirection via web.xml is ignored
In-Reply-To: <JIRA.12651000.1474373338000@Atlassian.JIRA>
References: <JIRA.12651000.1474373338000@Atlassian.JIRA>
	<JIRA.12651000.1474373338000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651000.1474373338000.56356.1475589420947@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-7150:
-----------------------------------
    Component/s: CDI / Weld
                 Web (Undertow)


> EJB injection with indirection via web.xml is ignored
> -----------------------------------------------------
>
>                 Key: WFLY-7150
>                 URL: https://issues.jboss.org/browse/WFLY-7150
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Web (Undertow)
>            Reporter: Wolf-Dieter Fink
>            Assignee: Jason Greene
>
> If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected.
> This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code.
> Reproducer can be found here:
> git at github.com:wfink/jboss-eap-quickstarts.git
> BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2
> SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app)
> see ejb-multi-server/README-reproducerEJB-injection



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 10:09:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 4 Oct 2016 10:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in elytron model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.56470.1475590140547@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-7260:
--------------------------------------

    Assignee: Jan Kalina  (was: Ilia Vassilev)


> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 10:12:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 4 Oct 2016 10:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in elytron model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.56518.1475590321132@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302352#comment-13302352 ] 

Darran Lofthouse commented on WFLY-7260:
----------------------------------------

[~honza889] How relevant is this now?  If both are set to true then 'need' will always have the highest priority - if one is set to false your latest code within Elytron handles that correctly now.

> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 10:16:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 4 Oct 2016 10:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in elytron model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.56648.1475590560830@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302360#comment-13302360 ] 

David Lloyd commented on WFLY-7260:
-----------------------------------

In other places (like XNIO) we've historically done an "authentication mode" with three choices: none, want, need.  This is a bit more concise and maybe could avoid a bit of user confusion.  But Darran is also right: it's not that important as no mode combination is actually invalid per se.

> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 10:29:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 4 Oct 2016 10:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-168) Release new version of
 jboss-annotations-api_1.2_spec
In-Reply-To: <JIRA.12653172.1475588990000@Atlassian.JIRA>
References: <JIRA.12653172.1475588990000@Atlassian.JIRA>
	<JIRA.12653172.1475588990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653172.1475588990000.56743.1475591340131@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302375#comment-13302375 ] 

Scott Marlow commented on JBEE-168:
-----------------------------------

Where is the upstream repository for synching up with the new 1.3 release source changes?  I couldn't open the [http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annotation-api%7C1.3%7Cjar] link.

Our repo for jboss-annotations-api is [https://github.com/jboss/jboss-annotations-api_spec].  

[~wolfc], when we release a new jboss-annotations-api_1.3_spec, should we create a new branch for EAP 7.x, so that we have an upstream for EAP 7.x changes to jboss-annotations-api_spec, that is separate from the new EE 8 changes?

> Release new version of jboss-annotations-api_1.2_spec
> -----------------------------------------------------
>
>                 Key: JBEE-168
>                 URL: https://issues.jboss.org/browse/JBEE-168
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Task
>          Components: jboss-annotations-api
>            Reporter: Tomas Remes
>            Assignee: Scott Marlow
>
> There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annotation-api%7C1.3%7Cjar recently



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 11:28:01 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 4 Oct 2016 11:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-124) Change switch statements
 to if/else blocks when translating levels
In-Reply-To: <JIRA.12653195.1475594871000@Atlassian.JIRA>
References: <JIRA.12653195.1475594871000@Atlassian.JIRA>
	<JIRA.12653195.1475594871455@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653195.1475594871000.57116.1475594881102@Atlassian.JIRA>

James Perkins created JBLOGGING-124:
---------------------------------------

             Summary: Change switch statements to if/else blocks when translating levels
                 Key: JBLOGGING-124
                 URL: https://issues.jboss.org/browse/JBLOGGING-124
             Project: JBoss Logging
          Issue Type: Enhancement
            Reporter: James Perkins
            Assignee: James Perkins


Currently a switch statement is used when levels are translated from a JBoss Logging level to the back end log level. This will likely perform better as an if/else block with the mostly likely used level at the top of the comparison.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 11:43:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 4 Oct 2016 11:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-296) Switch URI scheme from
 remoting:// http-remoting:// https-remoting:// to remote:// remote+http://
 and remote+https://
In-Reply-To: <JIRA.12542570.1401734598000@Atlassian.JIRA>
References: <JIRA.12542570.1401734598000@Atlassian.JIRA>
	<JIRA.12542570.1401734598000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542570.1401734598000.57257.1475595780418@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned WFCORE-296:
----------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Darran Lofthouse)


> Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-296
>                 URL: https://issues.jboss.org/browse/WFCORE-296
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI, Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: ehsavoie Hugonnet
>             Fix For: 3.0.0.Alpha10
>
>
> From [~dmlloyd]
> {quote}
> When we have multi-layer protocol going on, the URI scheme we should use 
> is like this:
>    outer+middle+inner://
> {quote}
> Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://
> The existing schemes will be needed for backwards compatibility but somehow deprecated.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 12:10:00 2016
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 4 Oct 2016 12:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.57599.1475597400519@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302471#comment-13302471 ] 

Shigeru Chiba commented on JASSIST-261:
---------------------------------------

I've released 3.22.0-CR1, which can run on the Java 9 VM.

https://github.com/jboss-javassist/javassist/releases/tag/rel_3_22_0_cr1


> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 12:18:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 4 Oct 2016 12:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1730) Singleton service is not
 correctly being set in WILDFLY
In-Reply-To: <JIRA.12644667.1472052505000@Atlassian.JIRA>
References: <JIRA.12644667.1472052505000@Atlassian.JIRA>
	<JIRA.12644667.1472052505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644667.1472052505000.57638.1475597880307@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302484#comment-13302484 ] 

RH Bugzilla Integration commented on WFCORE-1730:
-------------------------------------------------

Ji?? B?lek <jbilek at redhat.com> changed the Status of [bug 1367793|https://bugzilla.redhat.com/show_bug.cgi?id=1367793] from ON_QA to VERIFIED

> Singleton service is not correctly being set in WILDFLY
> -------------------------------------------------------
>
>                 Key: WFCORE-1730
>                 URL: https://issues.jboss.org/browse/WFCORE-1730
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 3.0.0.Alpha5
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Panagiotis Sotiropoulos
>
> WILDFLY doesn't call ServiceLoader (META-INF/services/org.jboss.msc.service.ServiceActivator) when it is deployed in EAR/lib. The SingletonService (not a singleton EJB) is activated in the ServiceLoader so the SingletonService hasn't been activated from the first. It works as expected when deployed as an EJB (not in EAR/lib).
> When the ServiceLoader is called, a message of "HATimerService will be installed!" is logged and the SingletonService will be activated.
> $ fgrep -e HATimerService -e '[org.jboss.as.clustering.singleton]' domain/servers/server-one/log/server.log
> 12:14:52,373 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator] (MSC service thread 1-7) HATimerService will be installed!
> 12:14:56,251 INFO  [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service
> 12:14:56,251 INFO  [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010340: This node will now operate as the singleton provider of the jboss.quickstart.ha.singleton.timer service
> 12:14:56,268 INFO  [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerService] (MSC service thread 1-8) Start HASingleton timer service 'org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATim
> erService'
> 12:14:56,873 INFO  [org.jboss.as.clustering.singleton] (notification-thread-0) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct  4 12:29:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 4 Oct 2016 12:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.57743.1475598540828@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302495#comment-13302495 ] 

Scott Marlow commented on JASSIST-261:
--------------------------------------

Excellent, I'll push to the maven repo!

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 12:34:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 4 Oct 2016 12:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.57762.1475598840783@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302496#comment-13302496 ] 

Scott Marlow commented on JASSIST-261:
--------------------------------------

I uploaded 3.22.0-CR1 to the Maven repo, should be available now.

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 13:23:00 2016
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 4 Oct 2016 13:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-930) A security-domain can only
 load login-modules from a single JBoss module
In-Reply-To: <JIRA.12597491.1450716628000@Atlassian.JIRA>
References: <JIRA.12597491.1450716628000@Atlassian.JIRA>
	<JIRA.12597491.1450716628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597491.1450716628000.57939.1475601780457@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302526#comment-13302526 ] 

Stefan Guilhen commented on SECURITY-930:
-----------------------------------------

[~ppalaga] Yeah, I do have an update. The fix was applied a while ago to PicketBox master, which was not yet used by WildFly until recently. Now that Elytron is being integrated we have upgraded WildFly to use PicketBox 5.0.0 and we can now change the ModuleClassLoaderLocator to make use of the new API that allows for the registration of multiple modules.

So the issue affects two projects. The PicketBox side is covered by this issue and we already have a fix for it. I'll add a reference to the commit that fixes the issue here so we can close this issue. The WildFly side might need a different Jira to fix the ModuleClassLoaderLocator.

I'll try to open the WF Jira and send a PR for it tonight.

>  A security-domain can only load login-modules from a single JBoss module 
> --------------------------------------------------------------------------
>
>                 Key: SECURITY-930
>                 URL: https://issues.jboss.org/browse/SECURITY-930
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>
> A security-domain can only load login-modules from a single JBoss module.  Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.  
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
>   <security-domain name="jmx-console" cache-type="default">
>       <authentication>
>           <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>           <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>       </authentication>
>   </security-domain>
> Unfortunately, it does not work like this.  Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
> There seems to be two issues.  1)  The security subsystem code only "remembers" the last module that is defined within a single security domain.  2)  I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code.  The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 13:31:00 2016
From: issues at jboss.org (Brent Douglas (JIRA))
Date: Tue, 4 Oct 2016 13:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1845) Logging subsystem scans the
 CWD on server boot
In-Reply-To: <JIRA.12652897.1475276050000@Atlassian.JIRA>
References: <JIRA.12652897.1475276050000@Atlassian.JIRA>
	<JIRA.12652897.1475276050000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652897.1475276050000.57979.1475602260640@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brent Douglas updated WFCORE-1845:
----------------------------------
    Issue Type: Bug  (was: Feature Request)


> Logging subsystem scans the CWD on server boot
> ----------------------------------------------
>
>                 Key: WFCORE-1845
>                 URL: https://issues.jboss.org/browse/WFCORE-1845
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 2.0.10.Final
>         Environment: OSX El Capitan, Oracle JDK 1.8.0_92 && 101, swarm 2016.8.1, WF 10.0.0.Final, WF-CORE 2.0.10.Final
>            Reporter: Brent Douglas
>            Assignee: James Perkins
>
> When booting the server from a directory where the subtree is large the server hangs for a long time. JStack shows that the logging subsystem is scanning the CWD.
> Booting the server from the root dir of a maven parent project containing 2 subprojects, a swarm project and a small NPM subproject added 33s to the server boot time compared to stepping into the swarm project and booting it.
> Stacktrace while the server is booting:
> {noformat}
> Thread 25859: (state = IN_NATIVE)
>  - sun.nio.fs.UnixNativeDispatcher.lstat0(long, sun.nio.fs.UnixFileAttributes) @bci=0 (Compiled frame; information may be imprecise)
>  - sun.nio.fs.UnixNativeDispatcher.lstat(sun.nio.fs.UnixPath, sun.nio.fs.UnixFileAttributes) @bci=10, line=300 (Compiled frame)
>  - sun.nio.fs.UnixFileAttributes.get(sun.nio.fs.UnixPath, boolean) @bci=22, line=72 (Compiled frame)
>  - sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes() @bci=15, line=52 (Compiled frame)
>  - sun.nio.fs.UnixFileSystemProvider.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=57, line=144 (Compiled frame)
>  - java.nio.file.Files.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=7, line=1737 (Compiled frame)
>  - java.nio.file.FileTreeWalker.getAttributes(java.nio.file.Path, boolean) @bci=56, line=219 (Compiled frame)
>  - java.nio.file.FileTreeWalker.visit(java.nio.file.Path, boolean, boolean) @bci=3, line=276 (Compiled frame)
>  - java.nio.file.FileTreeWalker.next() @bci=134, line=372 (Compiled frame)
>  - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.util.Set, int, java.nio.file.FileVisitor) @bci=256, line=2706 (Compiled frame)
>  - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.nio.file.FileVisitor) @bci=9, line=2742 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.findFiles(java.lang.String, org.jboss.dmr.ModelNode, boolean) @bci=47, line=251 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.getChildrenNames(java.lang.String) @bci=37, line=157 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.getChildren(java.lang.String) @bci=11, line=171 (Interpreted frame)
>  - org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(java.lang.String) @bci=5, line=362 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=99, line=289 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=189, line=291 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource) @bci=2, line=250 (Interpreted frame)
>  - org.jboss.as.controller.ModelControllerImpl.writeModel(org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl, java.util.Set) @bci=19, line=769 (Interpreted frame)
>  - org.jboss.as.controller.OperationContextImpl.createPersistenceResource() @bci=17, line=519 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.executeDoneStage(org.jboss.dmr.ModelNode) @bci=22, line=708 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.processStages() @bci=277, line=680 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.executeOperation() @bci=27, line=370 (Interpreted frame)
>  - org.jboss.as.controller.OperationContextImpl.executeOperation() @bci=20, line=1344 (Interpreted frame)
>  - org.jboss.as.controller.ModelControllerImpl.boot(java.util.List, org.jboss.as.controller.client.OperationMessageHandler, org.jboss.as.controller.ModelController$OperationTransactionControl, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider, boolean, boolean) @bci=410, line=485 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider) @bci=16, line=387 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean) @bci=7, line=349 (Interpreted frame)
>  - org.jboss.as.server.ServerService.boot(java.util.List, boolean) @bci=22, line=392 (Interpreted frame)
>  - org.jboss.as.server.ServerService.boot(org.jboss.as.controller.BootContext) @bci=907, line=365 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService$1.run() @bci=12, line=299 (Interpreted frame)
>  - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 14:11:00 2016
From: issues at jboss.org (Maciej Swiderski (JIRA))
Date: Tue, 4 Oct 2016 14:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy
 and multi threaded load
In-Reply-To: <JIRA.12593676.1448049351000@Atlassian.JIRA>
References: <JIRA.12593676.1448049351000@Atlassian.JIRA>
	<JIRA.12593676.1448049351000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593676.1448049351000.58081.1475604660480@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302544#comment-13302544 ] 

Maciej Swiderski commented on DROOLS-987:
-----------------------------------------

it looks like the change we have done to resolve the problem are still causing some issue in ejb based tests of jbpm. That at the moment is not found what is the issue but looks like really weird one as it fails most of the time with transaction rollback due to hibernate trying to do an update on an entity that was not yet inserted. Thus causing exception as such update on JDBC layer returns 0 rows updated while the expectation is 1.

So at the moment linked above PRs (especially one in jbpm) cannot be merged.

> Errors in Phreak under heavy and multi threaded load 
> -----------------------------------------------------
>
>                 Key: DROOLS-987
>                 URL: https://issues.jboss.org/browse/DROOLS-987
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final, 6.4.0.Final
>         Environment: linux
> Java 7
> kernel 3.16
>            Reporter: Jose Cavieres
>            Assignee: Mario Fusco
>         Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
>         at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
>         at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
>         at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
>         at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
>         at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
>         at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
>         at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
>         at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
>         at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
>         at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
>         at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
>         at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 15:14:00 2016
From: issues at jboss.org (James Netherton (JIRA))
Date: Tue, 4 Oct 2016 15:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7263) Upgrade HttpClient to 4.5.2
In-Reply-To: <JIRA.12653233.1475608404000@Atlassian.JIRA>
References: <JIRA.12653233.1475608404000@Atlassian.JIRA>
	<JIRA.12653233.1475608404407@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653233.1475608404000.58213.1475608440220@Atlassian.JIRA>

James Netherton created WFLY-7263:
-------------------------------------

             Summary: Upgrade HttpClient to 4.5.2
                 Key: WFLY-7263
                 URL: https://issues.jboss.org/browse/WFLY-7263
             Project: WildFly
          Issue Type: Component Upgrade
            Reporter: James Netherton
            Assignee: Jason Greene


HttpClient 4.5.2 has been available for a while now. Various projects have started to make use of it. It'd be good if WildFly can upgrade. It'd help with integrating some Camel functionality:

https://github.com/wildfly-extras/wildfly-camel/issues/1357



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 15:25:01 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 4 Oct 2016 15:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7263) Upgrade HttpClient to 4.5.2
In-Reply-To: <JIRA.12653233.1475608404000@Atlassian.JIRA>
References: <JIRA.12653233.1475608404000@Atlassian.JIRA>
	<JIRA.12653233.1475608404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653233.1475608404000.58241.1475609101077@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-7263:
--------------------------------------

    Component/s: REST
                 Web Services
       Assignee: Alessio Soldano  (was: Jason Greene)


Our org.apache.httpcomponents module is private and used by the REST and webservices subsystems, so I put those components on this as they control its version.

> Upgrade HttpClient to 4.5.2
> ---------------------------
>
>                 Key: WFLY-7263
>                 URL: https://issues.jboss.org/browse/WFLY-7263
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: REST, Web Services
>            Reporter: James Netherton
>            Assignee: Alessio Soldano
>
> HttpClient 4.5.2 has been available for a while now. Various projects have started to make use of it. It'd be good if WildFly can upgrade. It'd help with integrating some Camel functionality:
> https://github.com/wildfly-extras/wildfly-camel/issues/1357



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 15:26:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 4 Oct 2016 15:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1852) Logging configuration
 service for dynamic deployment resources uses wrong service name for
 deployments
In-Reply-To: <JIRA.12653239.1475609158000@Atlassian.JIRA>
References: <JIRA.12653239.1475609158000@Atlassian.JIRA>
	<JIRA.12653239.1475609158420@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653239.1475609158000.58259.1475609160068@Atlassian.JIRA>

James Perkins created WFCORE-1852:
-------------------------------------

             Summary: Logging configuration service for dynamic deployment resources uses wrong service name for deployments
                 Key: WFCORE-1852
                 URL: https://issues.jboss.org/browse/WFCORE-1852
             Project: WildFly Core
          Issue Type: Bug
            Reporter: James Perkins


Ideally if the use of a service can be removed that would be best. What's needed is a way to associate a deployments resource with a {{LogContextConfiguration}}. One option is to use a custom resource that the OSH can get the {{LogContextConfiguration}} from. This is already done for the child resources. See the {{LoggingDeploymentResources}}. The OSH can cast the resource and just get the configuration.

{quote}
[12:08 PM] Brian Stansberry: @jperkins this doesn't look right: https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java/org/jboss/as/logging/deplo...
[12:09 PM] Brian Stansberry: AFAICT it is using the management name of a deployment to create an MSC ServiceName
[12:10 PM] James R Perkins: @BrianStansberry Hmm. ...yeah. Let me look at why I was doing that.
[12:13 PM] James R Perkins: @BrianStansberry Yes that's what it's doing which thinking about it does seem wrong. Essentially it's trying to figure out which service to use for a dynamic resource on the /deployment=some.war/subsystem=logging/configuration=whatever
[12:14 PM] Brian Stansberry: you need to use the runtime-name attribute of the deployment
[12:14 PM] James R Perkins: Really it's kind of a bad use case for a service.
[12:14 PM] Brian Stansberry: I guess subdeployment has one too, although it's redundant
{quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 15:49:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 4 Oct 2016 15:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in elytron model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.58362.1475610540513@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302576#comment-13302576 ] 

Martin Choma commented on WFLY-7260:
------------------------------------

So just document "If both are set to true then 'need' will always have the highest priority" . And I think documentation of difference between this two (similar) options would be also helpful for users, as not everybody is familiar with that. Btw. I like idea of "authentication mode", but not requesting it here, as I think better documentation will be enough.

Also don't forget to sync new model documentation with XSD documentation.

> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 16:00:02 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 4 Oct 2016 16:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1849) Wildfly OpenSSL 1.0.0.Alpha2
In-Reply-To: <JIRA.12653059.1475538591000@Atlassian.JIRA>
References: <JIRA.12653059.1475538591000@Atlassian.JIRA>
	<JIRA.12653059.1475538591000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653059.1475538591000.58382.1475611202449@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1849:
----------------------------------------

    Fix Version/s: 3.0.0.Alpha10
         Assignee: Stuart Douglas
       Resolution: Done


> Wildfly OpenSSL 1.0.0.Alpha2
> ----------------------------
>
>                 Key: WFCORE-1849
>                 URL: https://issues.jboss.org/browse/WFCORE-1849
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 3.0.0.Alpha10
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 16:43:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 4 Oct 2016 16:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7264) Multicast address of
 modcluster socket-binding should be parametrized
In-Reply-To: <JIRA.12600978.1453719973000@Atlassian.JIRA>
References: <JIRA.12600978.1453719973000@Atlassian.JIRA>
	<JIRA.12600978.1453719973000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600978.1453719973000.58525.1475613781073@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar moved JBEAP-3000 to WFLY-7264:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7264  (was: JBEAP-3000)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: mod_cluster
                           (was: mod_cluster)
    Affects Version/s: 10.1.0.Final
                           (was: 7.0.0.ER4)


> Multicast address of modcluster socket-binding should be parametrized
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7264
>                 URL: https://issues.jboss.org/browse/WFLY-7264
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster
>    Affects Versions: 10.1.0.Final
>            Reporter: Erich Duda
>            Assignee: Radoslav Husar
>              Labels: ux
>
> In {{standalone-ha.xml}} and {{standalone-full-ha.xml}} a {{modcluster}} socket-binding is defined. It has multicast-address parameter which has hard-coded value 224.0.1.105. I need to change this value when I use IPv6 addresses and I can't do it without modifying configuration xml. Although the modcluster is not related to messaging, when the multicast address is IPv4, servers don't create cluster on IPv6 addresses.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 16:43:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 4 Oct 2016 16:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7264) Multicast address of
 modcluster socket-binding should be parametrized
In-Reply-To: <JIRA.12600978.1453719973000@Atlassian.JIRA>
References: <JIRA.12600978.1453719973000@Atlassian.JIRA>
	<JIRA.12600978.1453719973000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12600978.1453719973000.58531.1475613781248@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7264:
---------------------------------
    Affects Version/s: 10.0.0.Final
                           (was: 10.1.0.Final)


> Multicast address of modcluster socket-binding should be parametrized
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7264
>                 URL: https://issues.jboss.org/browse/WFLY-7264
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster
>    Affects Versions: 10.0.0.Final
>            Reporter: Erich Duda
>            Assignee: Radoslav Husar
>              Labels: ux
>
> In {{standalone-ha.xml}} and {{standalone-full-ha.xml}} a {{modcluster}} socket-binding is defined. It has multicast-address parameter which has hard-coded value 224.0.1.105. I need to change this value when I use IPv6 addresses and I can't do it without modifying configuration xml. Although the modcluster is not related to messaging, when the multicast address is IPv4, servers don't create cluster on IPv6 addresses.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 17:37:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 4 Oct 2016 17:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7068) Typo in help for Infinispan
	subsystem
In-Reply-To: <JIRA.12649076.1473236412000@Atlassian.JIRA>
References: <JIRA.12649076.1473236412000@Atlassian.JIRA>
	<JIRA.12649076.1473236412000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649076.1473236412000.58639.1475617020719@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7068:
---------------------------------
    Component/s: Clustering
                     (was: Web Console)


> Typo in help for Infinispan subsystem
> -------------------------------------
>
>                 Key: WFLY-7068
>                 URL: https://issues.jboss.org/browse/WFLY-7068
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Dmitrii Tikhomirov
>            Assignee: Dmitrii Tikhomirov
>            Priority: Trivial
>   Original Estimate: 5 minutes
>  Remaining Estimate: 5 minutes
>
> There is a typo in Passivation paragraph. "f false, the cache store contains a copy of the contents in memory, so writes to cache result in cache store writes."
> There should be "If" instead of "f"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 18:09:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 4 Oct 2016 18:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7150) EJB injection with
 indirection via web.xml is ignored
In-Reply-To: <JIRA.12651000.1474373338000@Atlassian.JIRA>
References: <JIRA.12651000.1474373338000@Atlassian.JIRA>
	<JIRA.12651000.1474373338000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651000.1474373338000.58666.1475618940322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-7150:
------------------------------------

    Assignee: Stuart Douglas  (was: Jason Greene)


> EJB injection with indirection via web.xml is ignored
> -----------------------------------------------------
>
>                 Key: WFLY-7150
>                 URL: https://issues.jboss.org/browse/WFLY-7150
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Web (Undertow)
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>
> If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected.
> This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code.
> Reproducer can be found here:
> git at github.com:wfink/jboss-eap-quickstarts.git
> BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2
> SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app)
> see ejb-multi-server/README-reproducerEJB-injection



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 19:13:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 4 Oct 2016 19:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5863) EE concurency should queue
 scheduled tasks, instead of failing on timeout
In-Reply-To: <JIRA.12596977.1450309851000@Atlassian.JIRA>
References: <JIRA.12596977.1450309851000@Atlassian.JIRA>
	<JIRA.12596977.1450309851000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12596977.1450309851000.58708.1475622780275@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-5863:
--------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9231, https://github.com/wildfly/wildfly/pull/9250  (was: https://github.com/wildfly/wildfly/pull/9250)


> EE concurency should queue scheduled tasks, instead of failing on timeout
> -------------------------------------------------------------------------
>
>                 Key: WFLY-5863
>                 URL: https://issues.jboss.org/browse/WFLY-5863
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Stuart Douglas
>            Assignee: James Perkins
>
> At the moment if a scheduled task is queued and its execution happens when the server is suspended then the task will fail with an exception. It would be better if this was queued as with EJB timers.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 19:36:00 2016
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 4 Oct 2016 19:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.58750.1475624160421@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302600#comment-13302600 ] 

Shigeru Chiba commented on JASSIST-261:
---------------------------------------

Thanks!

> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 19:41:00 2016
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Tue, 4 Oct 2016 19:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-261) Issue with javassist on jdk
	9b112
In-Reply-To: <JIRA.12614521.1460448291000@Atlassian.JIRA>
References: <JIRA.12614521.1460448291000@Atlassian.JIRA>
	<JIRA.12614521.1460448291000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614521.1460448291000.58754.1475624460509@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-261.
-----------------------------------
    Fix Version/s: 3.22.0-CR1
       Resolution: Done


> Issue with javassist on jdk 9b112
> ---------------------------------
>
>                 Key: JASSIST-261
>                 URL: https://issues.jboss.org/browse/JASSIST-261
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.20.0-GA
>         Environment: Javassist with jdk 9b112
>            Reporter: Hoang Chuong Tran
>            Assignee: Shigeru Chiba
>             Fix For: 3.22.0-CR1
>
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code. 
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
>     public static class MyObject {
>         protected Object field;
>         Object getField() {return field;}
>         public void setField(Object field) {}
>     }
>     @Test
>     public void test() throws InstantiationException, IllegalAccessException {
>         Class<? extends MyObject> clazz = compile(MyObject.class);
>         clazz.newInstance().setField(null);
>     }
>     /** Compile a transfer class */
>     public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
>         // Determine class setters
>         Map<String, Method> setters = extractSetters(targetClass);
>         ClassPool classPool = ClassPool.getDefault();
>         classPool.insertClassPath(new ClassClassPath(targetClass));
>         try {
>             // Compile a new transfer class on the fly
>             CtClass baseClass = classPool.get(MyObject.class.getName());
>             CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
>             for(Method originalSetter : setters.values()) {
>                 // Create a field to hold the attribute
>                 Class<?> fieldClass = originalSetter.getParameterTypes()[0];
>                 CtClass fieldType = classPool.get(fieldClass.getName());
>                 String fieldName = originalSetter.getName().substring(3);
>                 CtField field = new CtField(fieldType, fieldName, proxyClass);
>                 proxyClass.addField(field);
>                 // Create a setter method to set that field
>                 CtClass[] parameters = new CtClass[] { fieldType };
>                 String setterBody = "{ System.out.println(\"Hello World\"); }";
>                 CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
>                 proxyClass.addMethod(setter);
>             }
>             Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
>             return javaClass;
>         } catch(Exception e) {
>             throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
>         }
>     }
>     /** Extract setter methods from a class */
>     public static Map<String, Method> extractSetters(Class<?> cls) {
>         Map<String, Method> setters = new HashMap<String, Method>();
>         for(Method method : cls.getMethods()) {
>             // Lookup setter methods
>             if(method.getName().startsWith("set")) {
>                 // Only public setters
>                 int modifiers = method.getModifiers();
>                 if(Modifier.isPublic(modifiers)) {
>                     Class<?>[] exceptions = method.getExceptionTypes();
>                     Class<?>[] parameters = method.getParameterTypes();
>                     Class<?> returnType = method.getReturnType();
>                     if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
>                         setters.put(method.getName(), method);
>                     }
>                 }
>             }
>         }
>         return setters;
>     }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. 
> On jdk 9b112, I got the following exception 
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
>     at MyTests.compile(MyTests.java:68)
>     at MyTests.test(MyTests.java:29)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:531)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
>     at javassist.ClassPool.get(ClassPool.java:450)
>     at MyTests.compile(MyTests.java:51)
>     ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 19:52:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 4 Oct 2016 19:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7243) Web sockets are always enabled
In-Reply-To: <JIRA.12652690.1475224120000@Atlassian.JIRA>
References: <JIRA.12652690.1475224120000@Atlassian.JIRA>
	<JIRA.12652690.1475224120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652690.1475224120000.58766.1475625120285@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-7243.
----------------------------------
    Resolution: Done


> Web sockets are always enabled
> ------------------------------
>
>                 Key: WFLY-7243
>                 URL: https://issues.jboss.org/browse/WFLY-7243
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: Kabir Khan
>            Assignee: Stuart Douglas
>             Fix For: 11.0.0.Alpha1
>
>
> TCK testing for WFLY-6784 unearthed that websockets were always turned on in the undertow subsystem, while they should be explicitly turned on with the websocket element.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct  4 23:07:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 4 Oct 2016 23:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7254) pattern-filter disappears if
 predefined-filter is used for configurable-sasl-server-factory in Elytron
 subsystem
In-Reply-To: <JIRA.12652989.1475497944000@Atlassian.JIRA>
References: <JIRA.12652989.1475497944000@Atlassian.JIRA>
	<JIRA.12652989.1475497944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652989.1475497944000.58928.1475636820343@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302621#comment-13302621 ] 

Ilia Vassilev commented on WFLY-7254:
-------------------------------------

[~olukas] You are right that the following command should lead to "outcome" => "failed" so to fix the issue I'll work on changing the code to prevent such commands.
Invalid CLI command which should be prevented:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*),predefined-filter=BINDING}])
{code}   

Valid command:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*), enabling="false"},{predefined-filter=BINDING}])
{code}
Configuration after executing it:
{code}
                <configurable-sasl-server-factory name="someFactory" sasl-server-factory="global">
                    <filters>
                        <filter enabling="false">
                            <pattern-filter value="(.*)"/>
                        </filter>
                        <filter>
                            <predefined-filter value="BINDING"/>
                        </filter>
                    </filters>
                </configurable-sasl-server-factory>
{code}

The above configuration can be correctly loaded when server is started:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:read-attribute(name=filters)
{
    "outcome" => "success",
    "result" => [
        {
            "enabling" => false,
            "pattern-filter" => "(.*)"
        },
        {"predefined-filter" => "BINDING"}
    ]
}
{code}

> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7254
>                 URL: https://issues.jboss.org/browse/WFLY-7254
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>             Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears). 
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 02:32:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Oct 2016 02:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2106) Prepare for JDK 9
In-Reply-To: <JIRA.12653070.1475560165000@Atlassian.JIRA>
References: <JIRA.12653070.1475560165000@Atlassian.JIRA>
	<JIRA.12653070.1475560165000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653070.1475560165000.59159.1475649120163@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2106:
---------------------------
    Fix Version/s: 4.1
                       (was: 4.0)


> Prepare for JDK 9
> -----------------
>
>                 Key: JGRP-2106
>                 URL: https://issues.jboss.org/browse/JGRP-2106
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.1
>
>
> Investigate the changes needed to run with JDK 9. Probably module.info classes are all that's needed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 02:33:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Oct 2016 02:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2107) Document system properties
In-Reply-To: <JIRA.12653282.1475649127000@Atlassian.JIRA>
References: <JIRA.12653282.1475649127000@Atlassian.JIRA>
	<JIRA.12653282.1475649127292@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653282.1475649127000.59165.1475649180195@Atlassian.JIRA>

Bela Ban created JGRP-2107:
------------------------------

             Summary: Document system properties
                 Key: JGRP-2107
                 URL: https://issues.jboss.org/browse/JGRP-2107
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 4.0


List all system properties in the manual. Link to this from https://developer.jboss.org/docs/12352



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 03:27:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 5 Oct 2016 03:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7265) Adding Elytron ldap-realm
 through CLI throws IllegalArgumentException
In-Reply-To: <JIRA.12653291.1475652366000@Atlassian.JIRA>
References: <JIRA.12653291.1475652366000@Atlassian.JIRA>
	<JIRA.12653291.1475652366589@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653291.1475652366000.59395.1475652420545@Atlassian.JIRA>

Ondrej Lukas created WFLY-7265:
----------------------------------

             Summary: Adding Elytron ldap-realm through CLI throws IllegalArgumentException
                 Key: WFLY-7265
                 URL: https://issues.jboss.org/browse/WFLY-7265
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


In case when ldap-realm is added through CLI then IllegalArgumentException is thrown in all cases when values for {{identity-mapping.user-password-mapper.writable}} and {{identity-mapping.user-password-mapper.verifiable}} are not set. 

According to read-attribute operation these attributes (writable and verifiable) should has set default values hence they should not be required by CLI. 

Following exception is thrown to server log:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("ldap-realm" => "ldap")
]): java.lang.IllegalArgumentException
	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
	at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
	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)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 03:27:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 5 Oct 2016 03:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7265) Adding Elytron ldap-realm
 through CLI throws IllegalArgumentException
In-Reply-To: <JIRA.12653291.1475652367000@Atlassian.JIRA>
References: <JIRA.12653291.1475652367000@Atlassian.JIRA>
	<JIRA.12653291.1475652367000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653291.1475652367000.59404.1475652420858@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7265:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Adding Elytron ldap-realm through CLI throws IllegalArgumentException
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7265
>                 URL: https://issues.jboss.org/browse/WFLY-7265
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when ldap-realm is added through CLI then IllegalArgumentException is thrown in all cases when values for {{identity-mapping.user-password-mapper.writable}} and {{identity-mapping.user-password-mapper.verifiable}} are not set. 
> According to read-attribute operation these attributes (writable and verifiable) should has set default values hence they should not be required by CLI. 
> Following exception is thrown to server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 04:23:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Wed, 5 Oct 2016 04:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1853) Ctrl-C could lead to alias
 not being persisted
In-Reply-To: <JIRA.12653316.1475655732000@Atlassian.JIRA>
References: <JIRA.12653316.1475655732000@Atlassian.JIRA>
	<JIRA.12653316.1475655732459@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653316.1475655732000.59645.1475655780099@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-1853:
--------------------------------------------

             Summary: Ctrl-C could lead to alias not being persisted
                 Key: WFCORE-1853
                 URL: https://issues.jboss.org/browse/WFCORE-1853
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


The bug WFCORE-1729 has revealed it. It seems to only occur on Windows.
I think that a small windows exists (possibly in Aesh) that makes the shutdown hook to not be properly invoked.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 04:25:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 5 Oct 2016 04:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-651) Add error message with
 information that is not allowed to read secret-value and entry-type from
 Credential Store
In-Reply-To: <JIRA.12653317.1475655864000@Atlassian.JIRA>
References: <JIRA.12653317.1475655864000@Atlassian.JIRA>
	<JIRA.12653317.1475655864567@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653317.1475655864000.59665.1475655900582@Atlassian.JIRA>

Hynek ?v?bek created ELY-651:
--------------------------------

             Summary: Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
                 Key: ELY-651
                 URL: https://issues.jboss.org/browse/ELY-651
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek
            Priority: Minor


Add error message with information that is not allowed to read secret value from Credential Store over CLI.

This CLI commands
{code}
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
{code}
end with success result.
{code}
{
    "outcome" => "success",
    "result" => undefined
}
{code}




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 04:25:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 5 Oct 2016 04:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-651) Add error message with
 information that is not allowed to read secret-value and entry-type from
 Credential Store
In-Reply-To: <JIRA.12653317.1475655865000@Atlassian.JIRA>
References: <JIRA.12653317.1475655865000@Atlassian.JIRA>
	<JIRA.12653317.1475655865000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653317.1475655865000.59668.1475655900644@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-651:
-----------------------------
    Description: 
Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.

This CLI commands
{code}
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
{code}
end with success result.
{code}
{
    "outcome" => "success",
    "result" => undefined
}
{code}


  was:
Add error message with information that is not allowed to read secret value from Credential Store over CLI.

This CLI commands
{code}
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
{code}
end with success result.
{code}
{
    "outcome" => "success",
    "result" => undefined
}
{code}




> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-651
>                 URL: https://issues.jboss.org/browse/ELY-651
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>            Priority: Minor
>
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.
> This CLI commands
> {code}
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
> {code}
> end with success result.
> {code}
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 04:26:00 2016
From: issues at jboss.org (Guillermo G (JIRA))
Date: Wed, 5 Oct 2016 04:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6381) CDI Event handler after
 transaction success fails to call transactional method
In-Reply-To: <JIRA.12610713.1458132379000@Atlassian.JIRA>
References: <JIRA.12610713.1458132379000@Atlassian.JIRA>
	<JIRA.12610713.1458132379000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610713.1458132379000.59673.1475655960235@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302724#comment-13302724 ] 

Guillermo G commented on WFLY-6381:
-----------------------------------

I'm also suffering from this. Any news or available workarounds?

> CDI Event handler after transaction success fails to call transactional method
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-6381
>                 URL: https://issues.jboss.org/browse/WFLY-6381
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld, EJB, JCA
>    Affects Versions: 10.0.0.Final
>         Environment: Windows 7, Java 1.8.51
>            Reporter: J?n Hala?a
>            Assignee: Stuart Douglas
>         Attachments: AfterSuccessTest.zip, wildfly.log
>
>
> Scenario:
> # EJB transactional business method fires a CDI event
> # The CDI event is handled by an event observer configured to receive event after its transaction succeeds (during = TransactionPhase.AFTER_SUCCESS)
> # The event handler calls another EJB transactional method, but the call fails with a ResourceException, error code IJ000459 (last part of its stacktrace pasted below). Full log is attached as a file. I think, when the handler is called, the original transaction should not be there anymore and a new one should be created.
> I attached a simple test web application with a servlet which triggers the sequence described before. I tried the test application on Weblogic 12.2.1 and it worked without problems. The application requires a data source - H2 in-memory is good enough, table will be created automatically by JPA.
> {code:java}
> Caused by: javax.resource.ResourceException: IJ000460: Error checking for a transaction
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:424)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> 	... 196 more
> Caused by: javax.resource.ResourceException: IJ000459: Transaction is not active: tx=TransactionImple < ac, BasicAction: 0:ffffac180a71:3fd5e4ea:56e93a24:184 status: ActionStatus.COMMITTED >
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:408)
> 	... 198 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 04:43:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 5 Oct 2016 04:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-652) There isn't possible set
 entry-type for new entry in Credential Store.
In-Reply-To: <JIRA.12653326.1475656931000@Atlassian.JIRA>
References: <JIRA.12653326.1475656931000@Atlassian.JIRA>
	<JIRA.12653326.1475656931173@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653326.1475656931000.59750.1475656980259@Atlassian.JIRA>

Hynek ?v?bek created ELY-652:
--------------------------------

             Summary: There isn't possible set entry-type for new entry in Credential Store.
                 Key: ELY-652
                 URL: https://issues.jboss.org/browse/ELY-652
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek


There isn't possible set entry-type for new entry in Credential Store

This CLI command
{code}
/subsystem=elytron/credential-store=testCS/alias=aliasEntryType:add(secret-value=secretVALUE, entry-type=org.wildfly.security.credential.PasswordCredential)
{code}
ends with
{code}
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'",
    "rolled-back" => true
}
{code}

*Server log:*
{code}
10:30:39,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("credential-store" => "testCS"),
    ("alias" => "aliasEntryType")
]): java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'
        at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.performRuntime(CredentialStoreAliasDefinition.java:166)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
        at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
        at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
        at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
        at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
        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)
        at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 04:43:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 5 Oct 2016 04:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-651) Add error message with
 information that is not allowed to read secret-value and entry-type from
 Credential Store
In-Reply-To: <JIRA.12653317.1475655865000@Atlassian.JIRA>
References: <JIRA.12653317.1475655865000@Atlassian.JIRA>
	<JIRA.12653317.1475655865000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653317.1475655865000.59756.1475656980731@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-651:
-----------------------------
    Tester:   (was: Hynek ?v?bek)


> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-651
>                 URL: https://issues.jboss.org/browse/ELY-651
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>            Priority: Minor
>
> Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.
> This CLI commands
> {code}
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
> /subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
> {code}
> end with success result.
> {code}
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 04:51:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 5 Oct 2016 04:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-652) There isn't possible set
 entry-type for new entry in Credential Store.
In-Reply-To: <JIRA.12653326.1475656931000@Atlassian.JIRA>
References: <JIRA.12653326.1475656931000@Atlassian.JIRA>
	<JIRA.12653326.1475656931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653326.1475656931000.59786.1475657460260@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-652:
-----------------------------
    Description: 
There isn't possibility set entry-type for new entry in Credential Store

This CLI command
{code}
/subsystem=elytron/credential-store=testCS/alias=aliasEntryType:add(secret-value=secretVALUE, entry-type=org.wildfly.security.credential.PasswordCredential)
{code}
ends with
{code}
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'",
    "rolled-back" => true
}
{code}

*Server log:*
{code}
10:30:39,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("credential-store" => "testCS"),
    ("alias" => "aliasEntryType")
]): java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'
        at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.performRuntime(CredentialStoreAliasDefinition.java:166)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
        at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
        at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
        at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
        at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
        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)
        at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}



  was:
There isn't possible set entry-type for new entry in Credential Store

This CLI command
{code}
/subsystem=elytron/credential-store=testCS/alias=aliasEntryType:add(secret-value=secretVALUE, entry-type=org.wildfly.security.credential.PasswordCredential)
{code}
ends with
{code}
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'",
    "rolled-back" => true
}
{code}

*Server log:*
{code}
10:30:39,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("credential-store" => "testCS"),
    ("alias" => "aliasEntryType")
]): java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'
        at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.performRuntime(CredentialStoreAliasDefinition.java:166)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
        at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
        at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
        at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
        at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
        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)
        at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}





> There isn't possible set entry-type for new entry in Credential Store.
> ----------------------------------------------------------------------
>
>                 Key: ELY-652
>                 URL: https://issues.jboss.org/browse/ELY-652
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> There isn't possibility set entry-type for new entry in Credential Store
> This CLI command
> {code}
> /subsystem=elytron/credential-store=testCS/alias=aliasEntryType:add(secret-value=secretVALUE, entry-type=org.wildfly.security.credential.PasswordCredential)
> {code}
> ends with
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'",
>     "rolled-back" => true
> }
> {code}
> *Server log:*
> {code}
> 10:30:39,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("credential-store" => "testCS"),
>     ("alias" => "aliasEntryType")
> ]): java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'
>         at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.performRuntime(CredentialStoreAliasDefinition.java:166)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
>         at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
>         at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.security.auth.Subject.doAs(Subject.java:422)
>         at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
>         at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
>         at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
>         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)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 04:51:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 5 Oct 2016 04:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-652) There isn't possibility set
 entry-type for new entry in Credential Store.
In-Reply-To: <JIRA.12653326.1475656931000@Atlassian.JIRA>
References: <JIRA.12653326.1475656931000@Atlassian.JIRA>
	<JIRA.12653326.1475656931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653326.1475656931000.59792.1475657460680@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-652:
-----------------------------
    Summary: There isn't possibility set entry-type for new entry in Credential Store.  (was: There isn't possible set entry-type for new entry in Credential Store.)


> There isn't possibility set entry-type for new entry in Credential Store.
> -------------------------------------------------------------------------
>
>                 Key: ELY-652
>                 URL: https://issues.jboss.org/browse/ELY-652
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> There isn't possibility set entry-type for new entry in Credential Store
> This CLI command
> {code}
> /subsystem=elytron/credential-store=testCS/alias=aliasEntryType:add(secret-value=secretVALUE, entry-type=org.wildfly.security.credential.PasswordCredential)
> {code}
> ends with
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'",
>     "rolled-back" => true
> }
> {code}
> *Server log:*
> {code}
> 10:30:39,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("credential-store" => "testCS"),
>     ("alias" => "aliasEntryType")
> ]): java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'
>         at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.performRuntime(CredentialStoreAliasDefinition.java:166)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
>         at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
>         at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.security.auth.Subject.doAs(Subject.java:422)
>         at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
>         at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
>         at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
>         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)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 06:00:02 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Oct 2016 06:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2107) Document system properties
In-Reply-To: <JIRA.12653282.1475649127000@Atlassian.JIRA>
References: <JIRA.12653282.1475649127000@Atlassian.JIRA>
	<JIRA.12653282.1475649127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653282.1475649127000.60183.1475661602760@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302787#comment-13302787 ] 

Bela Ban commented on JGRP-2107:
--------------------------------

The section on system props is at file:///home/bela/jgroups.org/build/manual4/index.html#SystemProperties

> Document system properties
> --------------------------
>
>                 Key: JGRP-2107
>                 URL: https://issues.jboss.org/browse/JGRP-2107
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0
>
>
> List all system properties in the manual. Link to this from https://developer.jboss.org/docs/12352



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 06:01:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Oct 2016 06:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2107) Document system properties
In-Reply-To: <JIRA.12653282.1475649127000@Atlassian.JIRA>
References: <JIRA.12653282.1475649127000@Atlassian.JIRA>
	<JIRA.12653282.1475649127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653282.1475649127000.60188.1475661660573@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302787#comment-13302787 ] 

Bela Ban edited comment on JGRP-2107 at 10/5/16 6:00 AM:
---------------------------------------------------------

The section on system props is at http://www.jgroups.org/manual4/index.html#SystemProperties


was (Author: belaban):
The section on system props is at file:///home/bela/jgroups.org/build/manual4/index.html#SystemProperties

> Document system properties
> --------------------------
>
>                 Key: JGRP-2107
>                 URL: https://issues.jboss.org/browse/JGRP-2107
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0
>
>
> List all system properties in the manual. Link to this from https://developer.jboss.org/docs/12352



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 06:01:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 5 Oct 2016 06:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2107) Document system properties
In-Reply-To: <JIRA.12653282.1475649127000@Atlassian.JIRA>
References: <JIRA.12653282.1475649127000@Atlassian.JIRA>
	<JIRA.12653282.1475649127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653282.1475649127000.60196.1475661660933@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2107.
----------------------------
    Resolution: Done


> Document system properties
> --------------------------
>
>                 Key: JGRP-2107
>                 URL: https://issues.jboss.org/browse/JGRP-2107
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0
>
>
> List all system properties in the manual. Link to this from https://developer.jboss.org/docs/12352



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 06:10:01 2016
From: issues at jboss.org (=?UTF-8?Q?Enrique_Gonz=C3=A1lez_Mart=C3=ADnez_=28JIRA=29?=)
Date: Wed, 5 Oct 2016 06:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6882) A client is not able to
 invoke EJB's deployed as "HASingleton deployment"
In-Reply-To: <JIRA.12640877.1469626112000@Atlassian.JIRA>
References: <JIRA.12640877.1469626112000@Atlassian.JIRA>
	<JIRA.12640877.1469626112000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640877.1469626112000.60240.1475662201715@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302794#comment-13302794 ] 

Enrique Gonz?lez Mart?nez commented on WFLY-6882:
-------------------------------------------------

[~pferraro] or [~dmlloyd] 

If this works as designed (as Paul mentioned ), then this should be closed. Any thoughts before closing this one ?

> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
>                 Key: WFLY-6882
>                 URL: https://issues.jboss.org/browse/WFLY-6882
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Enrique Gonz?lez Mart?nez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 06:17:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 5 Oct 2016 06:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7265) Adding Elytron ldap-realm
 through CLI throws IllegalArgumentException
In-Reply-To: <JIRA.12653291.1475652367000@Atlassian.JIRA>
References: <JIRA.12653291.1475652367000@Atlassian.JIRA>
	<JIRA.12653291.1475652367000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653291.1475652367000.60297.1475662620510@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7265:
-----------------------------------
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Adding Elytron ldap-realm through CLI throws IllegalArgumentException
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7265
>                 URL: https://issues.jboss.org/browse/WFLY-7265
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> In case when ldap-realm is added through CLI then IllegalArgumentException is thrown in all cases when values for {{identity-mapping.user-password-mapper.writable}} and {{identity-mapping.user-password-mapper.verifiable}} are not set. 
> According to read-attribute operation these attributes (writable and verifiable) should has set default values hence they should not be required by CLI. 
> Following exception is thrown to server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 06:17:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 5 Oct 2016 06:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7265) Adding Elytron ldap-realm
 through CLI throws IllegalArgumentException
In-Reply-To: <JIRA.12653291.1475652367000@Atlassian.JIRA>
References: <JIRA.12653291.1475652367000@Atlassian.JIRA>
	<JIRA.12653291.1475652367000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653291.1475652367000.60305.1475662620726@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7265:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Adding Elytron ldap-realm through CLI throws IllegalArgumentException
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7265
>                 URL: https://issues.jboss.org/browse/WFLY-7265
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> In case when ldap-realm is added through CLI then IllegalArgumentException is thrown in all cases when values for {{identity-mapping.user-password-mapper.writable}} and {{identity-mapping.user-password-mapper.verifiable}} are not set. 
> According to read-attribute operation these attributes (writable and verifiable) should has set default values hence they should not be required by CLI. 
> Following exception is thrown to server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 06:54:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 5 Oct 2016 06:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7265) Adding Elytron ldap-realm
 through CLI throws IllegalArgumentException
In-Reply-To: <JIRA.12653291.1475652367000@Atlassian.JIRA>
References: <JIRA.12653291.1475652367000@Atlassian.JIRA>
	<JIRA.12653291.1475652367000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653291.1475652367000.60582.1475664840486@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas closed WFLY-7265.
------------------------------
    Resolution: Duplicate


Closing as duplicate of WFLY-7255.

> Adding Elytron ldap-realm through CLI throws IllegalArgumentException
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7265
>                 URL: https://issues.jboss.org/browse/WFLY-7265
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> In case when ldap-realm is added through CLI then IllegalArgumentException is thrown in all cases when values for {{identity-mapping.user-password-mapper.writable}} and {{identity-mapping.user-password-mapper.verifiable}} are not set. 
> According to read-attribute operation these attributes (writable and verifiable) should has set default values hence they should not be required by CLI. 
> Following exception is thrown to server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 07:34:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 5 Oct 2016 07:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-653) KeystorePasswordStore contains
 inconsistency about MODIFIABLE configuration attribute
In-Reply-To: <JIRA.12653362.1475667182000@Atlassian.JIRA>
References: <JIRA.12653362.1475667182000@Atlassian.JIRA>
	<JIRA.12653362.1475667182455@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653362.1475667182000.60831.1475667240319@Atlassian.JIRA>

Hynek ?v?bek created ELY-653:
--------------------------------

             Summary: KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute
                 Key: ELY-653
                 URL: https://issues.jboss.org/browse/ELY-653
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek


KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute.

Here it is used MODIFIABLE attribute:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L275

But it is missing between supported configuration attributes:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L222

I cannot see any condition with isModifiable() in *store()* method:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L317

In my opinion MODIFIABLE attribute should be supported otherwise please remove code about MODIFIABLE from *initialize()* method.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 07:35:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 5 Oct 2016 07:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-637) No log messages comming from
 Elytron - permission assignment
In-Reply-To: <JIRA.12651445.1474536217000@Atlassian.JIRA>
References: <JIRA.12651445.1474536217000@Atlassian.JIRA>
	<JIRA.12651445.1474536217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651445.1474536217000.60843.1475667300550@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-637:
------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> No log messages comming from Elytron - permission assignment
> ------------------------------------------------------------
>
>                 Key: ELY-637
>                 URL: https://issues.jboss.org/browse/ELY-637
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta9
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> Elytron is missing any log messages related to permission assignment. These log messages should be added. See JBEAP-6041 for more details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 07:59:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 5 Oct 2016 07:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-653) KeystorePasswordStore contains
 inconsistency about MODIFIABLE configuration attribute
In-Reply-To: <JIRA.12653362.1475667182000@Atlassian.JIRA>
References: <JIRA.12653362.1475667182000@Atlassian.JIRA>
	<JIRA.12653362.1475667182000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653362.1475667182000.61052.1475668740118@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-653:
-----------------------------
    Description: 
KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute.

Here it is used MODIFIABLE attribute:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L275

But it is missing between supported configuration attributes:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L222

I cannot see any condition with isModifiable() in *store()* or *remove()* method:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L317

In my opinion MODIFIABLE attribute should be supported otherwise please remove code about MODIFIABLE from *initialize()* method.

  was:
KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute.

Here it is used MODIFIABLE attribute:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L275

But it is missing between supported configuration attributes:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L222

I cannot see any condition with isModifiable() in *store()* method:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L317

In my opinion MODIFIABLE attribute should be supported otherwise please remove code about MODIFIABLE from *initialize()* method.



> KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute
> -------------------------------------------------------------------------------------
>
>                 Key: ELY-653
>                 URL: https://issues.jboss.org/browse/ELY-653
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute.
> Here it is used MODIFIABLE attribute:
> https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L275
> But it is missing between supported configuration attributes:
> https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L222
> I cannot see any condition with isModifiable() in *store()* or *remove()* method:
> https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L317
> In my opinion MODIFIABLE attribute should be supported otherwise please remove code about MODIFIABLE from *initialize()* method.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct  5 08:03:00 2016
From: issues at jboss.org (Michal Jurc (JIRA))
Date: Wed, 5 Oct 2016 08:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1851) Inconsistent behaviour with
 browse-content(depth=1) operation between archived and exploded deployments
In-Reply-To: <JIRA.12653148.1475584120000@Atlassian.JIRA>
References: <JIRA.12653148.1475584120000@Atlassian.JIRA>
	<JIRA.12653148.1475584120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653148.1475584120000.61068.1475668980270@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302889#comment-13302889 ] 

Michal Jurc commented on WFCORE-1851:
-------------------------------------

The behaviour is still inconsistent for archived deployments deployed through deployment scanner.

> Inconsistent behaviour with browse-content(depth=1) operation between archived and exploded deployments
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1851
>                 URL: https://issues.jboss.org/browse/WFCORE-1851
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: ehsavoie Hugonnet
>             Fix For: 3.0.0.Alpha10
>
>         Attachments: jboss-kitchensink-ear.ear
>
>
> {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} operation returns inconsistent result depending on whether the deployment is exploded or not. Deployment attached.
> Archived:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         }
>     ]
> }
> {code}
> Exploded:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 08:10:00 2016
From: issues at jboss.org (Michal Jurc (JIRA))
Date: Wed, 5 Oct 2016 08:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1851) Inconsistent behaviour with
 browse-content(depth=1) operation between archived and exploded deployments
In-Reply-To: <JIRA.12653148.1475584120000@Atlassian.JIRA>
References: <JIRA.12653148.1475584120000@Atlassian.JIRA>
	<JIRA.12653148.1475584120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653148.1475584120000.61130.1475669400355@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Jurc updated WFCORE-1851:
--------------------------------
    Comment: was deleted

(was: The behaviour is still inconsistent for archived deployments deployed through deployment scanner.)


> Inconsistent behaviour with browse-content(depth=1) operation between archived and exploded deployments
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1851
>                 URL: https://issues.jboss.org/browse/WFCORE-1851
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: ehsavoie Hugonnet
>             Fix For: 3.0.0.Alpha10
>
>         Attachments: jboss-kitchensink-ear.ear
>
>
> {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} operation returns inconsistent result depending on whether the deployment is exploded or not. Deployment attached.
> Archived:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         }
>     ]
> }
> {code}
> Exploded:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 08:28:01 2016
From: issues at jboss.org (Michal Jurc (JIRA))
Date: Wed, 5 Oct 2016 08:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1854) Wrong result on
 :browse-content(depth>0) on archived deployments deployed by deployment
 scanner
In-Reply-To: <JIRA.12653381.1475670440000@Atlassian.JIRA>
References: <JIRA.12653381.1475670440000@Atlassian.JIRA>
	<JIRA.12653381.1475670440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653381.1475670440000.61224.1475670481135@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Jurc moved JBEAP-6306 to WFCORE-1854:
--------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-1854  (was: JBEAP-6306)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s: 3.0.0.Alpha9
                           (was: 7.1.0.DR5)
                           (was: 7.1.0.DR6)


> Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1854
>                 URL: https://issues.jboss.org/browse/WFCORE-1854
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: Brian Stansberry
>
> With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 08:29:00 2016
From: issues at jboss.org (Michal Jurc (JIRA))
Date: Wed, 5 Oct 2016 08:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1854) Wrong result on
 :browse-content(depth>0) on archived deployments deployed by deployment
 scanner
In-Reply-To: <JIRA.12653381.1475670440000@Atlassian.JIRA>
References: <JIRA.12653381.1475670440000@Atlassian.JIRA>
	<JIRA.12653381.1475670440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653381.1475670440000.61237.1475670540724@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Jurc updated WFCORE-1854:
--------------------------------
    Description: 
With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
{code}{
    "outcome" => "success",
    "result" => [
        {
            "path" => "META-INF/",
            "directory" => true
        },
        {
            "path" => "META-INF/MANIFEST.MF",
            "directory" => false,
            "file-size" => 130L
        },
        {
            "path" => "jboss-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63190L
        },
        {
            "path" => "jboss-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12256L
        },
        {
            "path" => "META-INF/application.xml",
            "directory" => false,
            "file-size" => 802L
        },
        {
            "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
            "directory" => false,
            "file-size" => 1955L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
            "directory" => false,
            "file-size" => 5582L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
            "directory" => false,
            "file-size" => 143L
        }
    ]
}
{code}

WFCORE-1851 does not fix this.

  was:
With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
{code}{
    "outcome" => "success",
    "result" => [
        {
            "path" => "META-INF/",
            "directory" => true
        },
        {
            "path" => "META-INF/MANIFEST.MF",
            "directory" => false,
            "file-size" => 130L
        },
        {
            "path" => "jboss-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63190L
        },
        {
            "path" => "jboss-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12256L
        },
        {
            "path" => "META-INF/application.xml",
            "directory" => false,
            "file-size" => 802L
        },
        {
            "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
            "directory" => false,
            "file-size" => 1955L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
            "directory" => false,
            "file-size" => 5582L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
            "directory" => false,
            "file-size" => 143L
        }
    ]
}
{code}



> Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1854
>                 URL: https://issues.jboss.org/browse/WFCORE-1854
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: Brian Stansberry
>
> With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}
> WFCORE-1851 does not fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 08:29:00 2016
From: issues at jboss.org (Michal Jurc (JIRA))
Date: Wed, 5 Oct 2016 08:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1854) Wrong result on
 :browse-content(depth>0) on archived deployments deployed by deployment
 scanner
In-Reply-To: <JIRA.12653381.1475670440000@Atlassian.JIRA>
References: <JIRA.12653381.1475670440000@Atlassian.JIRA>
	<JIRA.12653381.1475670440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653381.1475670440000.61240.1475670540792@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Jurc updated WFCORE-1854:
--------------------------------
    Description: 
With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
{code}{
    "outcome" => "success",
    "result" => [
        {
            "path" => "META-INF/",
            "directory" => true
        },
        {
            "path" => "META-INF/MANIFEST.MF",
            "directory" => false,
            "file-size" => 130L
        },
        {
            "path" => "jboss-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63190L
        },
        {
            "path" => "jboss-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12256L
        },
        {
            "path" => "META-INF/application.xml",
            "directory" => false,
            "file-size" => 802L
        },
        {
            "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
            "directory" => false,
            "file-size" => 1955L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
            "directory" => false,
            "file-size" => 5582L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
            "directory" => false,
            "file-size" => 143L
        }
    ]
}
{code}
WFCORE-1851 does not fix this.

  was:
With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
{code}{
    "outcome" => "success",
    "result" => [
        {
            "path" => "META-INF/",
            "directory" => true
        },
        {
            "path" => "META-INF/MANIFEST.MF",
            "directory" => false,
            "file-size" => 130L
        },
        {
            "path" => "jboss-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63190L
        },
        {
            "path" => "jboss-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12256L
        },
        {
            "path" => "META-INF/application.xml",
            "directory" => false,
            "file-size" => 802L
        },
        {
            "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
            "directory" => false,
            "file-size" => 1955L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
            "directory" => false,
            "file-size" => 5582L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
            "directory" => false,
            "file-size" => 143L
        }
    ]
}
{code}

WFCORE-1851 does not fix this.



> Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1854
>                 URL: https://issues.jboss.org/browse/WFCORE-1854
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: Brian Stansberry
>
> With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}
> WFCORE-1851 does not fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 09:17:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 5 Oct 2016 09:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-634) No log messages comming from
 Elytron - group assignment
In-Reply-To: <JIRA.12651437.1474535977000@Atlassian.JIRA>
References: <JIRA.12651437.1474535977000@Atlassian.JIRA>
	<JIRA.12651437.1474535977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651437.1474535977000.61507.1475673420262@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-634:
------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> No log messages comming from Elytron - group assignment
> -------------------------------------------------------
>
>                 Key: ELY-634
>                 URL: https://issues.jboss.org/browse/ELY-634
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta9
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> Elytron is missing any log messages related to group assignment. These log messages should be added. See JBEAP-6041 for more details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 09:29:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Oct 2016 09:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1854) Wrong result on
 :browse-content(depth>0) on archived deployments deployed by deployment
 scanner
In-Reply-To: <JIRA.12653381.1475670440000@Atlassian.JIRA>
References: <JIRA.12653381.1475670440000@Atlassian.JIRA>
	<JIRA.12653381.1475670440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653381.1475670440000.61600.1475674140974@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1854:
----------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Brian Stansberry)


> Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1854
>                 URL: https://issues.jboss.org/browse/WFCORE-1854
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: ehsavoie Hugonnet
>
> With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}
> WFCORE-1851 does not fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 09:37:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 5 Oct 2016 09:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1855) Possible NPE on controller
	service start
In-Reply-To: <JIRA.12653404.1475674569000@Atlassian.JIRA>
References: <JIRA.12653404.1475674569000@Atlassian.JIRA>
	<JIRA.12653404.1475674569565@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653404.1475674569000.61699.1475674620314@Atlassian.JIRA>

David Lloyd created WFCORE-1855:
-----------------------------------

             Summary: Possible NPE on controller service start
                 Key: WFCORE-1855
                 URL: https://issues.jboss.org/browse/WFCORE-1855
             Project: WildFly Core
          Issue Type: Bug
            Reporter: David Lloyd


In {{org.jboss.as.controller.AbstractControllerService}}, the {{start}} method starts up a background thread which performs a certain amount of the boot process.  Before this thread is started, a volatile field {{controller}} is initialized with the controller reported by the {{start()}} method.

Inside this thread, some work is performed, and at the end of a certain amount of work, the {{finishBoot()}} method is invoked.  This method calls {{controller.finishBoot()}}, referencing the field that was set in the {{start()}} method.

The problem arises when the service itself is stopped before the boot thread completes.  This causes the {{controller}} field to be nulled out, resulting in an NPE.

I think we need to look at:
* Why are we using a background thread for this?
* Why are we _not_ using the asynchronous startup feature?

I think we must do one of these two things in order to make this code "safe".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 09:37:00 2016
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Wed, 5 Oct 2016 09:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6899) Upgrade RESTEasy to 3.1.0.CR2
In-Reply-To: <JIRA.12641426.1470062534000@Atlassian.JIRA>
References: <JIRA.12641426.1470062534000@Atlassian.JIRA>
	<JIRA.12641426.1470062534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641426.1470062534000.61704.1475674620499@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-6899:
----------------------------------
    Summary: Upgrade RESTEasy to 3.1.0.CR2  (was: Upgrade RESTEasy to 3.1.x)


> Upgrade RESTEasy to 3.1.0.CR2
> -----------------------------
>
>                 Key: WFLY-6899
>                 URL: https://issues.jboss.org/browse/WFLY-6899
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: REST
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 09:39:00 2016
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Wed, 5 Oct 2016 09:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6899) Upgrade RESTEasy to 3.1.0.CR2
In-Reply-To: <JIRA.12641426.1470062534000@Atlassian.JIRA>
References: <JIRA.12641426.1470062534000@Atlassian.JIRA>
	<JIRA.12641426.1470062534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641426.1470062534000.61743.1475674740521@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-6899:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9252  (was: https://github.com/wildfly/wildfly/pull/9181)


> Upgrade RESTEasy to 3.1.0.CR2
> -----------------------------
>
>                 Key: WFLY-6899
>                 URL: https://issues.jboss.org/browse/WFLY-6899
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: REST
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 09:50:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 5 Oct 2016 09:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.1
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.61853.1475675400778@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-6854:
-------------------------------
    Summary: Upgrade Hibernate ORM to 5.1.1  (was: Upgrade Hibernate ORM to 5.1.x)


> Upgrade Hibernate ORM to 5.1.1
> ------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 09:51:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 5 Oct 2016 09:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7155) Update Hibernate to 5.0.11
In-Reply-To: <JIRA.12651051.1474382711000@Atlassian.JIRA>
References: <JIRA.12651051.1474382711000@Atlassian.JIRA>
	<JIRA.12651051.1474382711000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651051.1474382711000.61862.1475675460417@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-7155.
------------------------------
    Fix Version/s:     (was: 11.0.0.Beta1)
                       (was: 10.2.0.Final)
       Resolution: Duplicate Issue


closing as duplicate of [WFLY-6854]

> Update Hibernate to 5.0.11
> --------------------------
>
>                 Key: WFLY-7155
>                 URL: https://issues.jboss.org/browse/WFLY-7155
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JPA / Hibernate
>    Affects Versions: 10.2.0.Final, 11.0.0.Alpha1
>            Reporter: Frank Langelage
>            Assignee: Scott Marlow
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 09:56:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 5 Oct 2016 09:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7155) Update Hibernate to 5.0.11
In-Reply-To: <JIRA.12651051.1474382711000@Atlassian.JIRA>
References: <JIRA.12651051.1474382711000@Atlassian.JIRA>
	<JIRA.12651051.1474382711000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651051.1474382711000.61915.1475675760403@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reopened WFLY-7155:
--------------------------------


hmm, too many Hibernate upgrades.  This is not a duplicate but I don't think we need to upgrade WildFly 10.x to the latest ORM 5.0.x, so will close this after reopening.

> Update Hibernate to 5.0.11
> --------------------------
>
>                 Key: WFLY-7155
>                 URL: https://issues.jboss.org/browse/WFLY-7155
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JPA / Hibernate
>    Affects Versions: 10.2.0.Final, 11.0.0.Alpha1
>            Reporter: Frank Langelage
>            Assignee: Scott Marlow
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 09:57:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 5 Oct 2016 09:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7155) Update Hibernate to 5.0.11
In-Reply-To: <JIRA.12651051.1474382711000@Atlassian.JIRA>
References: <JIRA.12651051.1474382711000@Atlassian.JIRA>
	<JIRA.12651051.1474382711000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651051.1474382711000.61924.1475675820430@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-7155.
------------------------------
    Resolution: Rejected


Rejecting as we are actively maintaining the WildFly master branch.  We can consider upgrading Hibernate in earlier releases if there are strong reasons for doing so, otherwise, lets focus on the "master" branch changes (e.g. getting ORM 5.1.x upgraded for WildFly 11).

> Update Hibernate to 5.0.11
> --------------------------
>
>                 Key: WFLY-7155
>                 URL: https://issues.jboss.org/browse/WFLY-7155
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JPA / Hibernate
>    Affects Versions: 10.2.0.Final, 11.0.0.Alpha1
>            Reporter: Frank Langelage
>            Assignee: Scott Marlow
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 10:09:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Oct 2016 10:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1855) Possible NPE on controller
	service start
In-Reply-To: <JIRA.12653404.1475674570000@Atlassian.JIRA>
References: <JIRA.12653404.1475674570000@Atlassian.JIRA>
	<JIRA.12653404.1475674570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653404.1475674570000.62061.1475676540435@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302989#comment-13302989 ] 

Brian Stansberry commented on WFCORE-1855:
------------------------------------------

Neither of those two approaches will work. Everything depends on the AbstractControllerService being started.

Conceivably the boot thread stuff could be refactored out into a separate service that depends on the AbstractControllerService. It would need some analysis to look into any gotchas. I believe this has been this way since quite early in AS 7.0 so I'm not sure if it's this way for a real good reason or if it was just a result of inexperience.

> Possible NPE on controller service start
> ----------------------------------------
>
>                 Key: WFCORE-1855
>                 URL: https://issues.jboss.org/browse/WFCORE-1855
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: David Lloyd
>
> In {{org.jboss.as.controller.AbstractControllerService}}, the {{start}} method starts up a background thread which performs a certain amount of the boot process.  Before this thread is started, a volatile field {{controller}} is initialized with the controller reported by the {{start()}} method.
> Inside this thread, some work is performed, and at the end of a certain amount of work, the {{finishBoot()}} method is invoked.  This method calls {{controller.finishBoot()}}, referencing the field that was set in the {{start()}} method.
> The problem arises when the service itself is stopped before the boot thread completes.  This causes the {{controller}} field to be nulled out, resulting in an NPE.
> I think we need to look at:
> * Why are we using a background thread for this?
> * Why are we _not_ using the asynchronous startup feature?
> I think we must do one of these two things in order to make this code "safe".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 10:17:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Wed, 5 Oct 2016 10:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1854) Wrong result on
 :browse-content(depth>0) on archived deployments deployed by deployment
 scanner
In-Reply-To: <JIRA.12653381.1475670440000@Atlassian.JIRA>
References: <JIRA.12653381.1475670440000@Atlassian.JIRA>
	<JIRA.12653381.1475670440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653381.1475670440000.62144.1475677020345@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13302996#comment-13302996 ] 

ehsavoie Hugonnet commented on WFCORE-1854:
-------------------------------------------

I don't reproduce it on upstream master (with the fix for WFCORE-1851) :


{code:java}
[standalone at localhost:9990 /] /deployment=wildfly-kitchensink-ear.ear:read-resource(include-runtime)     
{                                                                                                                                                                                                                                                                                                
    "outcome" => "success",                                                                                                                                                                                                                                                                      
    "result" => {                                                                                                                                                                                                                                                                                
        "content" => [{"hash" => bytes {                                                                                                                                                                                                                                                         
            0x3e, 0x04, 0x34, 0xd7, 0xd4, 0x5f, 0x5a, 0x92,                                                                                                                                                                                                                                      
            0xd4, 0x1a, 0x81, 0x96, 0x67, 0xdb, 0x53, 0x4f,                                                                                                                                                                                                                                      
            0x8f, 0xdb, 0xf6, 0x31                                                                                                                                                                                                                                                               
        }}],                                                                                                                                                                                                                                                                                     
        "disabled-time" => 1475676768425L,                                                                                                                                                                                                                                                       
        "disabled-timestamp" => "2016-10-05 16:12:48,425 CEST",                                                                                                                                                                                                                                  
        "enabled" => false,                                                                                                                                                                                                                                                                      
        "enabled-time" => 1475676724207L,                                                                                                                                                                                                                                                        
        "enabled-timestamp" => "2016-10-05 16:12:04,207 CEST",                                                                                                                                                                                                                                   
        "managed" => true,                                                                                                                                                                                                                                                                       
        "name" => "wildfly-kitchensink-ear.ear",                                                                                                                                                                                                                                                 
        "owner" => [                                                                                                                                                                                                                                                                             
            ("subsystem" => "deployment-scanner"),                                                                                                                                                                                                                                               
            ("scanner" => "default")                                                                                                                                                                                                                                                             
        ],                                                                                                                                                                                                                                                                                       
        "persistent" => false,
        "runtime-name" => "wildfly-kitchensink-ear.ear",
        "status" => "STOPPED",
        "subdeployment" => undefined,
        "subsystem" => undefined
    }
}

deployment=wildfly-kitchensink-ear.ear:browse-content(depth=1)
{
    "outcome" => "success",
    "result" => [
        {
            "path" => "META-INF/",
            "directory" => true
        },
        {
            "path" => "wildfly-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63332L
        },
        {
            "path" => "wildfly-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12128L
        }
    ]

{code}



> Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1854
>                 URL: https://issues.jboss.org/browse/WFCORE-1854
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: ehsavoie Hugonnet
>
> With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}
> WFCORE-1851 does not fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 10:45:01 2016
From: issues at jboss.org (kostd kostd (JIRA))
Date: Wed, 5 Oct 2016 10:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7266) BOM
 wildfly-javaee7-with-tools mismanages some dependencies
In-Reply-To: <JIRA.12653431.1475678675000@Atlassian.JIRA>
References: <JIRA.12653431.1475678675000@Atlassian.JIRA>
	<JIRA.12653431.1475678675416@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653431.1475678675000.62375.1475678701392@Atlassian.JIRA>

kostd kostd created WFLY-7266:
---------------------------------

             Summary: BOM wildfly-javaee7-with-tools mismanages some dependencies
                 Key: WFLY-7266
                 URL: https://issues.jboss.org/browse/WFLY-7266
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 10.1.0.Final
         Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
org.wildfly:wildfly-spec-api:10.1.0.Final
            Reporter: kostd kostd
            Assignee: Jason Greene


Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api

Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:

1. I have a dummy project with deps:

{code:title:bom and spec}
<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.wildfly.bom</groupId>
			<artifactId>wildfly-javaee7-with-tools</artifactId>
			<version>10.1.0.Final</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
	</dependencies>
</dependencyManagement>
 
<dependencies>
	<dependency>
		<groupId>org.wildfly</groupId>
		<artifactId>wildfly-spec-api</artifactId>
		<version>10.1.0.Final</version>
		<type>pom</type>
		<scope>provided</scope>
	</dependency>

</dependencies>

{code}

Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
{code:title=mvn dependency:tree fragment}
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
[INFO] ru.argustelecom.argus:test-maven-project:ejb:333
[INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
[INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
[INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
[INFO]    |  \- javax.inject:javax.inject:jar:1:provided
[INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
[INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
[INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
[INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
[INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
[INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
[INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
[INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
[INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
[INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
[INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
[INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
[INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided

{code}

This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:

{code:title=wildfly-javaee7 pom fragment}
..
        <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
...
            <!-- BOM imports -->
            <!-- JBoss distributes a complete set of Java EE 7 APIs including
                a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
                a collection) of artifacts. We use this here so that we always get the correct
                versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
                this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
                this stack with any version of WildFly that implements Java EE 7! -->
            <dependency>
                <groupId>org.jboss.spec</groupId>
                <artifactId>jboss-javaee-7.0</artifactId>
                <version>${version.org.jboss.spec.jboss.javaee.7}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

{code}

{code:title=jboss-javaee-7.0 pom fragment}
...
    <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
...
    <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
...
      <dependency>
        <groupId>org.jboss.spec.javax.el</groupId>
        <artifactId>jboss-el-api_3.0_spec</artifactId>
        <version>${version.org.jboss.spec.javax.el}</version>
      </dependency>
...
      <dependency>
        <groupId>org.jboss.spec.javax.faces</groupId>
        <artifactId>jboss-jsf-api_2.2_spec</artifactId>
        <version>${version.org.jboss.spec.javax.faces}</version>
      </dependency>

{code}

Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)








--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 10:48:00 2016
From: issues at jboss.org (kostd kostd (JIRA))
Date: Wed, 5 Oct 2016 10:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7266) BOM
 wildfly-javaee7-with-tools mismanages some dependencies
In-Reply-To: <JIRA.12653431.1475678675000@Atlassian.JIRA>
References: <JIRA.12653431.1475678675000@Atlassian.JIRA>
	<JIRA.12653431.1475678675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653431.1475678675000.62422.1475678880662@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

kostd kostd updated WFLY-7266:
------------------------------
    Description: 
Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api

Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:

1. I have a dummy project with deps:

{code:title:bom and spec}
<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.wildfly.bom</groupId>
			<artifactId>wildfly-javaee7-with-tools</artifactId>
			<version>10.1.0.Final</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
	</dependencies>
</dependencyManagement>
 
<dependencies>
	<dependency>
		<groupId>org.wildfly</groupId>
		<artifactId>wildfly-spec-api</artifactId>
		<version>10.1.0.Final</version>
		<type>pom</type>
		<scope>provided</scope>
	</dependency>

</dependencies>

{code}

Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
{code:title=mvn dependency:tree fragment}
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
[INFO] ru.argustelecom.argus:test-maven-project:ejb:333
[INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
[INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
[INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
[INFO]    |  \- javax.inject:javax.inject:jar:1:provided
[INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
[INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
[INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
[INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
[INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
[INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
[INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
[INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
[INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
[INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
[INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
[INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
[INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided

{code}

el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively

2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:

{code:title=wildfly-javaee7 pom fragment}
..
        <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
...
            <!-- BOM imports -->
            <!-- JBoss distributes a complete set of Java EE 7 APIs including
                a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
                a collection) of artifacts. We use this here so that we always get the correct
                versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
                this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
                this stack with any version of WildFly that implements Java EE 7! -->
            <dependency>
                <groupId>org.jboss.spec</groupId>
                <artifactId>jboss-javaee-7.0</artifactId>
                <version>${version.org.jboss.spec.jboss.javaee.7}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

{code}

{code:title=jboss-javaee-7.0 pom fragment}
...
    <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
...
    <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
...
      <dependency>
        <groupId>org.jboss.spec.javax.el</groupId>
        <artifactId>jboss-el-api_3.0_spec</artifactId>
        <version>${version.org.jboss.spec.javax.el}</version>
      </dependency>
...
      <dependency>
        <groupId>org.jboss.spec.javax.faces</groupId>
        <artifactId>jboss-jsf-api_2.2_spec</artifactId>
        <version>${version.org.jboss.spec.javax.faces}</version>
      </dependency>

{code}

3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:

org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)






  was:
Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api

Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:

1. I have a dummy project with deps:

{code:title:bom and spec}
<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.wildfly.bom</groupId>
			<artifactId>wildfly-javaee7-with-tools</artifactId>
			<version>10.1.0.Final</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
	</dependencies>
</dependencyManagement>
 
<dependencies>
	<dependency>
		<groupId>org.wildfly</groupId>
		<artifactId>wildfly-spec-api</artifactId>
		<version>10.1.0.Final</version>
		<type>pom</type>
		<scope>provided</scope>
	</dependency>

</dependencies>

{code}

Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
{code:title=mvn dependency:tree fragment}
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
[INFO] ru.argustelecom.argus:test-maven-project:ejb:333
[INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
[INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
[INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
[INFO]    |  \- javax.inject:javax.inject:jar:1:provided
[INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
[INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
[INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
[INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
[INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
[INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
[INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
[INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
[INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
[INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
[INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
[INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
[INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
[INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
[INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided

{code}

This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:

{code:title=wildfly-javaee7 pom fragment}
..
        <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
...
            <!-- BOM imports -->
            <!-- JBoss distributes a complete set of Java EE 7 APIs including
                a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
                a collection) of artifacts. We use this here so that we always get the correct
                versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
                this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
                this stack with any version of WildFly that implements Java EE 7! -->
            <dependency>
                <groupId>org.jboss.spec</groupId>
                <artifactId>jboss-javaee-7.0</artifactId>
                <version>${version.org.jboss.spec.jboss.javaee.7}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

{code}

{code:title=jboss-javaee-7.0 pom fragment}
...
    <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
...
    <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
...
      <dependency>
        <groupId>org.jboss.spec.javax.el</groupId>
        <artifactId>jboss-el-api_3.0_spec</artifactId>
        <version>${version.org.jboss.spec.javax.el}</version>
      </dependency>
...
      <dependency>
        <groupId>org.jboss.spec.javax.faces</groupId>
        <artifactId>jboss-jsf-api_2.2_spec</artifactId>
        <version>${version.org.jboss.spec.javax.faces}</version>
      </dependency>

{code}

Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)








> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
>                 Key: WFLY-7266
>                 URL: https://issues.jboss.org/browse/WFLY-7266
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
>            Reporter: kostd kostd
>            Assignee: Jason Greene
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> 	<dependencies>
> 		<dependency>
> 			<groupId>org.wildfly.bom</groupId>
> 			<artifactId>wildfly-javaee7-with-tools</artifactId>
> 			<version>10.1.0.Final</version>
> 			<type>pom</type>
> 			<scope>import</scope>
> 		</dependency>
> 	</dependencies>
> </dependencyManagement>
>  
> <dependencies>
> 	<dependency>
> 		<groupId>org.wildfly</groupId>
> 		<artifactId>wildfly-spec-api</artifactId>
> 		<version>10.1.0.Final</version>
> 		<type>pom</type>
> 		<scope>provided</scope>
> 	</dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    |  \- javax.inject:javax.inject:jar:1:provided
> [INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
> [INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
>         <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
>             <!-- BOM imports -->
>             <!-- JBoss distributes a complete set of Java EE 7 APIs including
>                 a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
>                 a collection) of artifacts. We use this here so that we always get the correct
>                 versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
>                 this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
>                 this stack with any version of WildFly that implements Java EE 7! -->
>             <dependency>
>                 <groupId>org.jboss.spec</groupId>
>                 <artifactId>jboss-javaee-7.0</artifactId>
>                 <version>${version.org.jboss.spec.jboss.javaee.7}</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
>     <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
>     <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.el</groupId>
>         <artifactId>jboss-el-api_3.0_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.el}</version>
>       </dependency>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.faces</groupId>
>         <artifactId>jboss-jsf-api_2.2_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.faces}</version>
>       </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 10:51:00 2016
From: issues at jboss.org (kostd kostd (JIRA))
Date: Wed, 5 Oct 2016 10:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7266) BOM
 wildfly-javaee7-with-tools mismanages some dependencies
In-Reply-To: <JIRA.12653431.1475678675000@Atlassian.JIRA>
References: <JIRA.12653431.1475678675000@Atlassian.JIRA>
	<JIRA.12653431.1475678675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653431.1475678675000.62458.1475679060166@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

kostd kostd updated WFLY-7266:
------------------------------
    Attachment: pom.xml


pom descriptor of my dummy project attached

> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
>                 Key: WFLY-7266
>                 URL: https://issues.jboss.org/browse/WFLY-7266
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
>            Reporter: kostd kostd
>            Assignee: Jason Greene
>         Attachments: pom.xml
>
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> 	<dependencies>
> 		<dependency>
> 			<groupId>org.wildfly.bom</groupId>
> 			<artifactId>wildfly-javaee7-with-tools</artifactId>
> 			<version>10.1.0.Final</version>
> 			<type>pom</type>
> 			<scope>import</scope>
> 		</dependency>
> 	</dependencies>
> </dependencyManagement>
>  
> <dependencies>
> 	<dependency>
> 		<groupId>org.wildfly</groupId>
> 		<artifactId>wildfly-spec-api</artifactId>
> 		<version>10.1.0.Final</version>
> 		<type>pom</type>
> 		<scope>provided</scope>
> 	</dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    |  \- javax.inject:javax.inject:jar:1:provided
> [INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
> [INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
>         <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
>             <!-- BOM imports -->
>             <!-- JBoss distributes a complete set of Java EE 7 APIs including
>                 a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
>                 a collection) of artifacts. We use this here so that we always get the correct
>                 versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
>                 this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
>                 this stack with any version of WildFly that implements Java EE 7! -->
>             <dependency>
>                 <groupId>org.jboss.spec</groupId>
>                 <artifactId>jboss-javaee-7.0</artifactId>
>                 <version>${version.org.jboss.spec.jboss.javaee.7}</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
>     <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
>     <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.el</groupId>
>         <artifactId>jboss-el-api_3.0_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.el}</version>
>       </dependency>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.faces</groupId>
>         <artifactId>jboss-jsf-api_2.2_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.faces}</version>
>       </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 10:53:00 2016
From: issues at jboss.org (kostd kostd (JIRA))
Date: Wed, 5 Oct 2016 10:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6621) wildfly-spec-api:10.0.0.Final
 mismanages el-api, jsf-api
In-Reply-To: <JIRA.12626622.1463573769000@Atlassian.JIRA>
References: <JIRA.12626622.1463573769000@Atlassian.JIRA>
	<JIRA.12626622.1463573769000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626622.1463573769000.62474.1475679180935@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303025#comment-13303025 ] 

kostd kostd commented on WFLY-6621:
-----------------------------------

see also WFLY-7266 BOM wildfly-javaee7-with-tools mismanages some dependencies

> wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> --------------------------------------------------------
>
>                 Key: WFLY-6621
>                 URL: https://issues.jboss.org/browse/WFLY-6621
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Vsevolod Golovanov
>            Assignee: Tomaz Cerar
>         Attachments: pom_el.png, pom_jsf.png
>
>
> Manages el-api to 1.0.4.Final, should be 1.0.5.Final: !pom_el.png|thumbnail!
> Manages jsf-api to 2.2.11, should be 2.2.12: !pom_jsf.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 10:54:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 5 Oct 2016 10:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7266) BOM
 wildfly-javaee7-with-tools mismanages some dependencies
In-Reply-To: <JIRA.12653431.1475678675000@Atlassian.JIRA>
References: <JIRA.12653431.1475678675000@Atlassian.JIRA>
	<JIRA.12653431.1475678675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653431.1475678675000.62502.1475679240544@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-7266:
---------------------------------

    Assignee: Tomaz Cerar  (was: Jason Greene)


> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
>                 Key: WFLY-7266
>                 URL: https://issues.jboss.org/browse/WFLY-7266
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
>            Reporter: kostd kostd
>            Assignee: Tomaz Cerar
>         Attachments: pom.xml
>
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> 	<dependencies>
> 		<dependency>
> 			<groupId>org.wildfly.bom</groupId>
> 			<artifactId>wildfly-javaee7-with-tools</artifactId>
> 			<version>10.1.0.Final</version>
> 			<type>pom</type>
> 			<scope>import</scope>
> 		</dependency>
> 	</dependencies>
> </dependencyManagement>
>  
> <dependencies>
> 	<dependency>
> 		<groupId>org.wildfly</groupId>
> 		<artifactId>wildfly-spec-api</artifactId>
> 		<version>10.1.0.Final</version>
> 		<type>pom</type>
> 		<scope>provided</scope>
> 	</dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    |  \- javax.inject:javax.inject:jar:1:provided
> [INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
> [INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
>         <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
>             <!-- BOM imports -->
>             <!-- JBoss distributes a complete set of Java EE 7 APIs including
>                 a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
>                 a collection) of artifacts. We use this here so that we always get the correct
>                 versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
>                 this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
>                 this stack with any version of WildFly that implements Java EE 7! -->
>             <dependency>
>                 <groupId>org.jboss.spec</groupId>
>                 <artifactId>jboss-javaee-7.0</artifactId>
>                 <version>${version.org.jboss.spec.jboss.javaee.7}</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
>     <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
>     <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.el</groupId>
>         <artifactId>jboss-el-api_3.0_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.el}</version>
>       </dependency>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.faces</groupId>
>         <artifactId>jboss-jsf-api_2.2_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.faces}</version>
>       </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 10:54:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 5 Oct 2016 10:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7266) BOM
 wildfly-javaee7-with-tools mismanages some dependencies
In-Reply-To: <JIRA.12653431.1475678675000@Atlassian.JIRA>
References: <JIRA.12653431.1475678675000@Atlassian.JIRA>
	<JIRA.12653431.1475678675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653431.1475678675000.62506.1475679240756@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7266:
------------------------------
    Priority: Optional  (was: Major)


> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
>                 Key: WFLY-7266
>                 URL: https://issues.jboss.org/browse/WFLY-7266
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
>            Reporter: kostd kostd
>            Assignee: Tomaz Cerar
>            Priority: Optional
>         Attachments: pom.xml
>
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> 	<dependencies>
> 		<dependency>
> 			<groupId>org.wildfly.bom</groupId>
> 			<artifactId>wildfly-javaee7-with-tools</artifactId>
> 			<version>10.1.0.Final</version>
> 			<type>pom</type>
> 			<scope>import</scope>
> 		</dependency>
> 	</dependencies>
> </dependencyManagement>
>  
> <dependencies>
> 	<dependency>
> 		<groupId>org.wildfly</groupId>
> 		<artifactId>wildfly-spec-api</artifactId>
> 		<version>10.1.0.Final</version>
> 		<type>pom</type>
> 		<scope>provided</scope>
> 	</dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    |  \- javax.inject:javax.inject:jar:1:provided
> [INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
> [INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
>         <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
>             <!-- BOM imports -->
>             <!-- JBoss distributes a complete set of Java EE 7 APIs including
>                 a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
>                 a collection) of artifacts. We use this here so that we always get the correct
>                 versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
>                 this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
>                 this stack with any version of WildFly that implements Java EE 7! -->
>             <dependency>
>                 <groupId>org.jboss.spec</groupId>
>                 <artifactId>jboss-javaee-7.0</artifactId>
>                 <version>${version.org.jboss.spec.jboss.javaee.7}</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
>     <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
>     <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.el</groupId>
>         <artifactId>jboss-el-api_3.0_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.el}</version>
>       </dependency>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.faces</groupId>
>         <artifactId>jboss-jsf-api_2.2_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.faces}</version>
>       </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 10:57:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 5 Oct 2016 10:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7266) BOM
 wildfly-javaee7-with-tools mismanages some dependencies
In-Reply-To: <JIRA.12653431.1475678675000@Atlassian.JIRA>
References: <JIRA.12653431.1475678675000@Atlassian.JIRA>
	<JIRA.12653431.1475678675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653431.1475678675000.62515.1475679420395@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303029#comment-13303029 ] 

Tomaz Cerar commented on WFLY-7266:
-----------------------------------

Well, given that it goes for API which doesn't change between minor versions your app should still work just fine as you only need it for compile against API not runtime.

Also I don't see why do you depend upon <artifactId>wildfly-spec-api</artifactId> ? as that makes no real sense as all same deps you get as part of bom and more.

> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
>                 Key: WFLY-7266
>                 URL: https://issues.jboss.org/browse/WFLY-7266
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
>            Reporter: kostd kostd
>            Assignee: Tomaz Cerar
>            Priority: Optional
>         Attachments: pom.xml
>
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> 	<dependencies>
> 		<dependency>
> 			<groupId>org.wildfly.bom</groupId>
> 			<artifactId>wildfly-javaee7-with-tools</artifactId>
> 			<version>10.1.0.Final</version>
> 			<type>pom</type>
> 			<scope>import</scope>
> 		</dependency>
> 	</dependencies>
> </dependencyManagement>
>  
> <dependencies>
> 	<dependency>
> 		<groupId>org.wildfly</groupId>
> 		<artifactId>wildfly-spec-api</artifactId>
> 		<version>10.1.0.Final</version>
> 		<type>pom</type>
> 		<scope>provided</scope>
> 	</dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    |  \- javax.inject:javax.inject:jar:1:provided
> [INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
> [INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
>         <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
>             <!-- BOM imports -->
>             <!-- JBoss distributes a complete set of Java EE 7 APIs including
>                 a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
>                 a collection) of artifacts. We use this here so that we always get the correct
>                 versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
>                 this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
>                 this stack with any version of WildFly that implements Java EE 7! -->
>             <dependency>
>                 <groupId>org.jboss.spec</groupId>
>                 <artifactId>jboss-javaee-7.0</artifactId>
>                 <version>${version.org.jboss.spec.jboss.javaee.7}</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
>     <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
>     <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.el</groupId>
>         <artifactId>jboss-el-api_3.0_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.el}</version>
>       </dependency>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.faces</groupId>
>         <artifactId>jboss-jsf-api_2.2_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.faces}</version>
>       </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 11:06:00 2016
From: issues at jboss.org (kostd kostd (JIRA))
Date: Wed, 5 Oct 2016 11:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7266) BOM
 wildfly-javaee7-with-tools mismanages some dependencies
In-Reply-To: <JIRA.12653431.1475678675000@Atlassian.JIRA>
References: <JIRA.12653431.1475678675000@Atlassian.JIRA>
	<JIRA.12653431.1475678675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653431.1475678675000.62549.1475679960246@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303036#comment-13303036 ] 

kostd kostd commented on WFLY-7266:
-----------------------------------

{quote}
 I don't see why do you depend upon <artifactId>wildfly-spec-api</artifactId> ? as that makes no real sense as all same deps you get as part of bom and more.
{quote}

Yes, this  happened historically. If I'm not mistaken, in older Wildfly (or jboss-as-7) was not bom, but spec-api already existed. This 	 rudimentary  survived throu migrations on new wildflys


> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
>                 Key: WFLY-7266
>                 URL: https://issues.jboss.org/browse/WFLY-7266
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
>            Reporter: kostd kostd
>            Assignee: Tomaz Cerar
>            Priority: Optional
>         Attachments: pom.xml
>
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> 	<dependencies>
> 		<dependency>
> 			<groupId>org.wildfly.bom</groupId>
> 			<artifactId>wildfly-javaee7-with-tools</artifactId>
> 			<version>10.1.0.Final</version>
> 			<type>pom</type>
> 			<scope>import</scope>
> 		</dependency>
> 	</dependencies>
> </dependencyManagement>
>  
> <dependencies>
> 	<dependency>
> 		<groupId>org.wildfly</groupId>
> 		<artifactId>wildfly-spec-api</artifactId>
> 		<version>10.1.0.Final</version>
> 		<type>pom</type>
> 		<scope>provided</scope>
> 	</dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    |  \- javax.inject:javax.inject:jar:1:provided
> [INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
> [INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
>         <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
>             <!-- BOM imports -->
>             <!-- JBoss distributes a complete set of Java EE 7 APIs including
>                 a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
>                 a collection) of artifacts. We use this here so that we always get the correct
>                 versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
>                 this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
>                 this stack with any version of WildFly that implements Java EE 7! -->
>             <dependency>
>                 <groupId>org.jboss.spec</groupId>
>                 <artifactId>jboss-javaee-7.0</artifactId>
>                 <version>${version.org.jboss.spec.jboss.javaee.7}</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
>     <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
>     <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.el</groupId>
>         <artifactId>jboss-el-api_3.0_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.el}</version>
>       </dependency>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.faces</groupId>
>         <artifactId>jboss-jsf-api_2.2_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.faces}</version>
>       </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 11:08:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 5 Oct 2016 11:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6621) wildfly-spec-api:10.0.0.Final
 mismanages el-api, jsf-api
In-Reply-To: <JIRA.12626622.1463573769000@Atlassian.JIRA>
References: <JIRA.12626622.1463573769000@Atlassian.JIRA>
	<JIRA.12626622.1463573769000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626622.1463573769000.62568.1475680080559@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303039#comment-13303039 ] 

Tomaz Cerar commented on WFLY-6621:
-----------------------------------

[~kostd] please keep to the topic, this is different issue, somewhat similar but different. One is talking about boms another about wildfly-spec-api.

> wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> --------------------------------------------------------
>
>                 Key: WFLY-6621
>                 URL: https://issues.jboss.org/browse/WFLY-6621
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Vsevolod Golovanov
>            Assignee: Tomaz Cerar
>         Attachments: pom_el.png, pom_jsf.png
>
>
> Manages el-api to 1.0.4.Final, should be 1.0.5.Final: !pom_el.png|thumbnail!
> Manages jsf-api to 2.2.11, should be 2.2.12: !pom_jsf.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 11:09:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Oct 2016 11:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1855) Possible NPE on controller
	service start
In-Reply-To: <JIRA.12653404.1475674570000@Atlassian.JIRA>
References: <JIRA.12653404.1475674570000@Atlassian.JIRA>
	<JIRA.12653404.1475674570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653404.1475674570000.62573.1475680140224@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303040#comment-13303040 ] 

Brian Stansberry commented on WFCORE-1855:
------------------------------------------

A simple workaround is to expose the controller via the BootContext and switch all uses of it by the boot thread to that. That's largely equivalent to passing it into a new dependent service via injection. If instead we created a new service and injected the controller, once that new service's start() was called and it got a ref to the controller it would use it until completion of start(). Trying to stop the AbstractControllerService would not result in the execution of start() terminating.

A separate service would be better as it would ensure the AbstractControllerService could not stop while the boot service was starting. That could have unintended side effects though, e.g. ServiceContainer not terminating resulting in the shutdown hook not returning.

> Possible NPE on controller service start
> ----------------------------------------
>
>                 Key: WFCORE-1855
>                 URL: https://issues.jboss.org/browse/WFCORE-1855
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: David Lloyd
>
> In {{org.jboss.as.controller.AbstractControllerService}}, the {{start}} method starts up a background thread which performs a certain amount of the boot process.  Before this thread is started, a volatile field {{controller}} is initialized with the controller reported by the {{start()}} method.
> Inside this thread, some work is performed, and at the end of a certain amount of work, the {{finishBoot()}} method is invoked.  This method calls {{controller.finishBoot()}}, referencing the field that was set in the {{start()}} method.
> The problem arises when the service itself is stopped before the boot thread completes.  This causes the {{controller}} field to be nulled out, resulting in an NPE.
> I think we need to look at:
> * Why are we using a background thread for this?
> * Why are we _not_ using the asynchronous startup feature?
> I think we must do one of these two things in order to make this code "safe".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 11:55:00 2016
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 5 Oct 2016 11:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.62840.1475682900846@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis moved GUVNOR-2694 to DROOLS-1318:
------------------------------------------------

              Project: Drools  (was: Guvnor)
                  Key: DROOLS-1318  (was: GUVNOR-2694)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s: 6.4.0.Final
                           (was: drools_6.4.0.Final)
                           (was: drools_6.5.0.CR2)


> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 11:56:00 2016
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 5 Oct 2016 11:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.62854.1475682960515@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303090#comment-13303090 ] 

Michael Anstis commented on DROOLS-1318:
----------------------------------------

This, I believe, [~mfusco] is the issue [~nheron] was talking about on IRC where use of "Java" dialect works, but "MVEL" not.

> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 12:19:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 5 Oct 2016 12:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.62960.1475684340273@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-1318:
-----------------------------------

    Assignee: Nicolas Heron


> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Nicolas Heron
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 12:25:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 5 Oct 2016 12:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.62987.1475684700344@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303108#comment-13303108 ] 

Mario Fusco commented on DROOLS-1318:
-------------------------------------

I added an enum Type to our Address test pojo and used it in a test case as it follows

{code}
    @Test
    public void testMvelWithEnum() {
        String drl =
                "import " + Address.class.getCanonicalName() + ";\n" +
                "rule R dialect \"mvel\" when\n" +
                "    $a : Address(type == Address.Type.OFFICE)\n" +
                "then\n" +
                "    $a.setType(Address.Type.HOME);\n" +
                "    update($a);\n" +
                "end";

        KieSession kieSession = new KieHelper().addContent(drl, ResourceType.DRL).build().newKieSession();

        Address address = new Address();
        address.setType( Address.Type.OFFICE );
        kieSession.insert( address );
        kieSession.fireAllRules();

        assertEquals(Address.Type.HOME, address.getType());
    }
{code}

As you can see I'm using the enum in both LHS and RHS and it works as expected.

[~nheron] Please provide a reproducer for this issue.

> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Nicolas Heron
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 12:26:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Wed, 5 Oct 2016 12:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1856) Completion for variable
 value is not appropriate
In-Reply-To: <JIRA.12653455.1475684752000@Atlassian.JIRA>
References: <JIRA.12653455.1475684752000@Atlassian.JIRA>
	<JIRA.12653455.1475684752326@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653455.1475684752000.62992.1475684760102@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-1856:
--------------------------------------------

             Summary: Completion for variable value is not appropriate
                 Key: WFCORE-1856
                 URL: https://issues.jboss.org/browse/WFCORE-1856
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


For example: set x=b<TAB> ==> A command is proposed. 
Command and operation completion should only be proposed when we want the value of the variable to be evaluated:  set value=`:read-attribute(name=release-version)`



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 12:49:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 5 Oct 2016 12:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7140) Injection with @EJB is not
 working as expected with CDI (REST) beans
In-Reply-To: <JIRA.12650832.1474302652000@Atlassian.JIRA>
References: <JIRA.12650832.1474302652000@Atlassian.JIRA>
	<JIRA.12650832.1474302652000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650832.1474302652000.63067.1475686140632@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-7140:
--------------------------------------

    Assignee: Tomas Remes  (was: Jason Greene)


> Injection with @EJB is not working as expected with CDI (REST) beans
> --------------------------------------------------------------------
>
>                 Key: WFLY-7140
>                 URL: https://issues.jboss.org/browse/WFLY-7140
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB
>            Reporter: Wolf-Dieter Fink
>            Assignee: Tomas Remes
>
> The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet.
> @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne")
> is not working correct if used in a CDI Bean in the reproducer example.
> Reproducer can be found here:
>     git at github.com:wfink/jboss-eap-quickstarts.git
>     BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection
>     SubProject: ejb-multi-server  (used only a part of it to have a web-app and a ejb-app)
>                       see ejb-multi-server/README-reproducerEJB-injection



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 13:34:00 2016
From: issues at jboss.org (Nicolas Heron (JIRA))
Date: Wed, 5 Oct 2016 13:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.63196.1475688840216@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303136#comment-13303136 ] 

Nicolas Heron commented on DROOLS-1318:
---------------------------------------

[~mfusco]  In your case, the enum is in the Class definition. 
The error is in the when part in the example
Period( seasonType == SeasonType.day )


> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Nicolas Heron
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 13:34:00 2016
From: issues at jboss.org (Nicolas Heron (JIRA))
Date: Wed, 5 Oct 2016 13:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.63201.1475688840367@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303136#comment-13303136 ] 

Nicolas Heron edited comment on DROOLS-1318 at 10/5/16 1:33 PM:
----------------------------------------------------------------

[~mfusco]  In your case, the enum is in the Class definition. 
The error is in the when part in the example
Period( seasonType == SeasonType.day )
SeasonType is an enum defined outside the class



was (Author: nheron):
[~mfusco]  In your case, the enum is in the Class definition. 
The error is in the when part in the example
Period( seasonType == SeasonType.day )


> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Nicolas Heron
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 14:16:01 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Oct 2016 14:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-123) Support for tinylog
In-Reply-To: <JIRA.12642938.1470917740000@Atlassian.JIRA>
References: <JIRA.12642938.1470917740000@Atlassian.JIRA>
	<JIRA.12642938.1470917740000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642938.1470917740000.63313.1475691361282@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBLOGGING-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed JBLOGGING-123.
-----------------------------------
    Resolution: Out of Date


I'm going to close this based on this commit to tinylog itself https://github.com/pmwmedia/tinylog/commit/108dd2cb4043e903fd066add372946296864fb34

> Support for tinylog
> -------------------
>
>                 Key: JBLOGGING-123
>                 URL: https://issues.jboss.org/browse/JBLOGGING-123
>             Project: JBoss Logging
>          Issue Type: Feature Request
>            Reporter: Martin Winandy
>            Assignee: James Perkins
>
> tinylog is a lightweight logging framework for Java with a static logger class. For supporting tinylog in JBoss Logging, a logger provider has to be implemented and added to the LoggerProviders class.
> Link to tinylog website: http://www.tinylog.org/
> Example implementation for JBoss Logging: https://github.com/pmwmedia/jboss-logging/
> The tinylog implementation for JBoss Logging is out-dated, but I could adapt to the newest version.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 14:22:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Oct 2016 14:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-92) Add support for Equinox
 ExtendedLogService
In-Reply-To: <JIRA.12487414.1363617292000@Atlassian.JIRA>
References: <JIRA.12487414.1363617292000@Atlassian.JIRA>
	<JIRA.12487414.1363617292000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487414.1363617292000.63317.1475691720353@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBLOGGING-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed JBLOGGING-92.
----------------------------------
    Resolution: Out of Date


I'm going to close this as I think it's out of date. I'd prefer in most cases not add support for other logging frameworks in jboss-logging itself and rather have the project itself supply a [{{LoggerProvider}}|https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/LoggerProvider.java] This uses a standard ServiceLoader to find a matching provider.

> Add support for Equinox ExtendedLogService
> ------------------------------------------
>
>                 Key: JBLOGGING-92
>                 URL: https://issues.jboss.org/browse/JBLOGGING-92
>             Project: JBoss Logging
>          Issue Type: Feature Request
>          Components: jboss-logging-spi
>            Reporter: Philippe Marschall
>            Assignee: David Lloyd
>
> We are running some JBoss libraries that use jboss-logging inside Eclipse RCP. We'd like to centralise all our logging. Unfortunately OSGi LogService does not support named loggers, for now they're only available through the Equinox ExtendedLogService.
> I'll attach a pull request.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 14:28:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Oct 2016 14:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-124) Change switch statements
 to if/else blocks when translating levels
In-Reply-To: <JIRA.12653195.1475594871000@Atlassian.JIRA>
References: <JIRA.12653195.1475594871000@Atlassian.JIRA>
	<JIRA.12653195.1475594871000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653195.1475594871000.63333.1475692080125@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBLOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed JBLOGGING-124.
-----------------------------------
    Fix Version/s: 3.3.0.Beta2
       Resolution: Done


> Change switch statements to if/else blocks when translating levels
> ------------------------------------------------------------------
>
>                 Key: JBLOGGING-124
>                 URL: https://issues.jboss.org/browse/JBLOGGING-124
>             Project: JBoss Logging
>          Issue Type: Enhancement
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 3.3.0.Beta2
>
>
> Currently a switch statement is used when levels are translated from a JBoss Logging level to the back end log level. This will likely perform better as an if/else block with the mostly likely used level at the top of the comparison.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 14:31:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Oct 2016 14:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-124) Change switch statements
 to if/else blocks when translating levels
In-Reply-To: <JIRA.12653195.1475594871000@Atlassian.JIRA>
References: <JIRA.12653195.1475594871000@Atlassian.JIRA>
	<JIRA.12653195.1475594871000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653195.1475594871000.63338.1475692260265@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBLOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reopened JBLOGGING-124:
-------------------------------------


> Change switch statements to if/else blocks when translating levels
> ------------------------------------------------------------------
>
>                 Key: JBLOGGING-124
>                 URL: https://issues.jboss.org/browse/JBLOGGING-124
>             Project: JBoss Logging
>          Issue Type: Enhancement
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 3.3.0.Final
>
>
> Currently a switch statement is used when levels are translated from a JBoss Logging level to the back end log level. This will likely perform better as an if/else block with the mostly likely used level at the top of the comparison.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 14:31:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 5 Oct 2016 14:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-124) Change switch statements
 to if/else blocks when translating levels
In-Reply-To: <JIRA.12653195.1475594871000@Atlassian.JIRA>
References: <JIRA.12653195.1475594871000@Atlassian.JIRA>
	<JIRA.12653195.1475594871000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653195.1475594871000.63339.1475692260286@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBLOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated JBLOGGING-124:
------------------------------------
    Fix Version/s: 3.3.1.Final
                       (was: 3.3.0.Final)


> Change switch statements to if/else blocks when translating levels
> ------------------------------------------------------------------
>
>                 Key: JBLOGGING-124
>                 URL: https://issues.jboss.org/browse/JBLOGGING-124
>             Project: JBoss Logging
>          Issue Type: Enhancement
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 3.3.1.Final
>
>
> Currently a switch statement is used when levels are translated from a JBoss Logging level to the back end log level. This will likely perform better as an if/else block with the mostly likely used level at the top of the comparison.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 18:14:00 2016
From: issues at jboss.org (Joe Carder (JIRA))
Date: Wed, 5 Oct 2016 18:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7031) Redirect Port Fails to
 Redirect to 3rd Party HTTP Port
In-Reply-To: <JIRA.12648161.1472739224000@Atlassian.JIRA>
References: <JIRA.12648161.1472739224000@Atlassian.JIRA>
	<JIRA.12648161.1472739224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648161.1472739224000.63923.1475705640180@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303215#comment-13303215 ] 

Joe Carder commented on WFLY-7031:
----------------------------------

Hi, Just curious if any additional information is needed for this issue?  Thank you.

> Redirect Port Fails to Redirect to 3rd Party HTTP Port
> ------------------------------------------------------
>
>                 Key: WFLY-7031
>                 URL: https://issues.jboss.org/browse/WFLY-7031
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Joe Carder
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception:
> ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> With the redirect socket to a port opened by JBoss, it works as expected.  I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 19:23:00 2016
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 5 Oct 2016 19:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-114) Actually make use of the
 provided callback handler in RemotingConnector or set up the callback
 handler appropriately if it hasn't been provided
In-Reply-To: <JIRA.12653486.1475709746000@Atlassian.JIRA>
References: <JIRA.12653486.1475709746000@Atlassian.JIRA>
	<JIRA.12653486.1475709746625@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653486.1475709746000.63952.1475709780088@Atlassian.JIRA>

Farah Juma created REMJMX-114:
---------------------------------

             Summary: Actually make use of the provided callback handler in RemotingConnector or set up the callback handler appropriately if it hasn't been provided
                 Key: REMJMX-114
                 URL: https://issues.jboss.org/browse/REMJMX-114
             Project: Remoting JMX
          Issue Type: Bug
            Reporter: Farah Juma
            Assignee: Farah Juma






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 19:27:00 2016
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 5 Oct 2016 19:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-114) Actually make use of the
 provided callback handler in RemotingConnector or set up the callback
 handler appropriately if it hasn't been provided
In-Reply-To: <JIRA.12653486.1475709747000@Atlassian.JIRA>
References: <JIRA.12653486.1475709747000@Atlassian.JIRA>
	<JIRA.12653486.1475709747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653486.1475709747000.63957.1475710020060@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated REMJMX-114:
------------------------------
    Git Pull Request: https://github.com/jbossas/remoting-jmx/pull/23


> Actually make use of the provided callback handler in RemotingConnector or set up the callback handler appropriately if it hasn't been provided
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: REMJMX-114
>                 URL: https://issues.jboss.org/browse/REMJMX-114
>             Project: Remoting JMX
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct  5 20:58:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 5 Oct 2016 20:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7267) [Proxy] No failover on empty
 response from node
In-Reply-To: <JIRA.12653491.1475715417000@Atlassian.JIRA>
References: <JIRA.12653491.1475715417000@Atlassian.JIRA>
	<JIRA.12653491.1475715417000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653491.1475715417000.64035.1475715480287@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-6311 to WFLY-7267:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7267  (was: JBEAP-6311)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Web (Undertow)
                           (was: Web (Undertow))
    Affects Version/s:     (was: 7.0.1.GA)
                           (was: 7.0.2.GA)
                           (was: 7.1.0.DR4)


> [Proxy] No failover on empty response from node
> -----------------------------------------------
>
>                 Key: WFLY-7267
>                 URL: https://issues.jboss.org/browse/WFLY-7267
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> Undertow balancer do not recognizes empty response as an error.
> Can happen when JVM got killed when handling request (System.exit())
> {code}
> @Override
>         public void failed(final HttpServerExchange exchange) {
>             final long time = System.currentTimeMillis();
>             if (tries++ < maxRetryAttempts) { 
>             ...
> {code}
> Undertow make curl hang.
> Apache httpd correctly recognizes empty response as error and starts fail over method. If unsuccessful, 50x is returned in response.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 02:08:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 02:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-114) Actually make use of the
 provided callback handler in RemotingConnector or set up the callback
 handler appropriately if it hasn't been provided
In-Reply-To: <JIRA.12653486.1475709747000@Atlassian.JIRA>
References: <JIRA.12653486.1475709747000@Atlassian.JIRA>
	<JIRA.12653486.1475709747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653486.1475709747000.64210.1475734080137@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-114:
------------------------------------
    Fix Version/s: 3.0.0.Alpha2


> Actually make use of the provided callback handler in RemotingConnector or set up the callback handler appropriately if it hasn't been provided
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: REMJMX-114
>                 URL: https://issues.jboss.org/browse/REMJMX-114
>             Project: Remoting JMX
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: 3.0.0.Alpha2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 02:15:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 02:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-115) Release Remoting JMX
	3.0.0.Alpha2
In-Reply-To: <JIRA.12653498.1475734496000@Atlassian.JIRA>
References: <JIRA.12653498.1475734496000@Atlassian.JIRA>
	<JIRA.12653498.1475734496172@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653498.1475734496000.64219.1475734501446@Atlassian.JIRA>

Darran Lofthouse created REMJMX-115:
---------------------------------------

             Summary: Release Remoting JMX 3.0.0.Alpha2
                 Key: REMJMX-115
                 URL: https://issues.jboss.org/browse/REMJMX-115
             Project: Remoting JMX
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha2






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 03:17:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 03:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-116) Upgrade to XNIO 3.4.0.Final
In-Reply-To: <JIRA.12653504.1475738194000@Atlassian.JIRA>
References: <JIRA.12653504.1475738194000@Atlassian.JIRA>
	<JIRA.12653504.1475738194044@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653504.1475738194000.64394.1475738220236@Atlassian.JIRA>

Darran Lofthouse created REMJMX-116:
---------------------------------------

             Summary: Upgrade to XNIO 3.4.0.Final
                 Key: REMJMX-116
                 URL: https://issues.jboss.org/browse/REMJMX-116
             Project: Remoting JMX
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha2






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 03:19:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 03:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-116) Upgrade to XNIO 3.4.0.Final
In-Reply-To: <JIRA.12653504.1475738194000@Atlassian.JIRA>
References: <JIRA.12653504.1475738194000@Atlassian.JIRA>
	<JIRA.12653504.1475738194000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653504.1475738194000.64401.1475738340289@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-116.
-------------------------------------
    Resolution: Done


> Upgrade to XNIO 3.4.0.Final
> ---------------------------
>
>                 Key: REMJMX-116
>                 URL: https://issues.jboss.org/browse/REMJMX-116
>             Project: Remoting JMX
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 03:20:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 03:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-117) Upgrade to WildFly Elytron
	1.1.0.Beta10
In-Reply-To: <JIRA.12653505.1475738374000@Atlassian.JIRA>
References: <JIRA.12653505.1475738374000@Atlassian.JIRA>
	<JIRA.12653505.1475738374780@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653505.1475738374000.64404.1475738400259@Atlassian.JIRA>

Darran Lofthouse created REMJMX-117:
---------------------------------------

             Summary: Upgrade to WildFly Elytron 1.1.0.Beta10
                 Key: REMJMX-117
                 URL: https://issues.jboss.org/browse/REMJMX-117
             Project: Remoting JMX
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha2






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 03:27:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 03:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-117) Upgrade to WildFly Elytron
	1.1.0.Beta10
In-Reply-To: <JIRA.12653505.1475738375000@Atlassian.JIRA>
References: <JIRA.12653505.1475738375000@Atlassian.JIRA>
	<JIRA.12653505.1475738375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653505.1475738375000.64408.1475738820152@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-117:
------------------------------------
    Description: Also add jboss threads 2.2.1.Final to test scope.


> Upgrade to WildFly Elytron 1.1.0.Beta10
> ---------------------------------------
>
>                 Key: REMJMX-117
>                 URL: https://issues.jboss.org/browse/REMJMX-117
>             Project: Remoting JMX
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha2
>
>
> Also add jboss threads 2.2.1.Final to test scope.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 03:28:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 03:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-117) Upgrade to WildFly Elytron
	1.1.0.Beta10
In-Reply-To: <JIRA.12653505.1475738375000@Atlassian.JIRA>
References: <JIRA.12653505.1475738375000@Atlassian.JIRA>
	<JIRA.12653505.1475738375000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653505.1475738375000.64411.1475738880299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-117.
-------------------------------------
    Resolution: Done


> Upgrade to WildFly Elytron 1.1.0.Beta10
> ---------------------------------------
>
>                 Key: REMJMX-117
>                 URL: https://issues.jboss.org/browse/REMJMX-117
>             Project: Remoting JMX
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha2
>
>
> Also add jboss threads 2.2.1.Final to test scope.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 03:29:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 03:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-118) Upgrade to WildFly Client
 Config 1.0.0.Beta1
In-Reply-To: <JIRA.12653506.1475738906000@Atlassian.JIRA>
References: <JIRA.12653506.1475738906000@Atlassian.JIRA>
	<JIRA.12653506.1475738906229@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653506.1475738906000.64418.1475738940169@Atlassian.JIRA>

Darran Lofthouse created REMJMX-118:
---------------------------------------

             Summary: Upgrade to WildFly Client Config 1.0.0.Beta1
                 Key: REMJMX-118
                 URL: https://issues.jboss.org/browse/REMJMX-118
             Project: Remoting JMX
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha2






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 03:31:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 03:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-118) Upgrade to WildFly Client
 Config 1.0.0.Beta1
In-Reply-To: <JIRA.12653506.1475738906000@Atlassian.JIRA>
References: <JIRA.12653506.1475738906000@Atlassian.JIRA>
	<JIRA.12653506.1475738906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653506.1475738906000.64426.1475739060372@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-118.
-------------------------------------
    Resolution: Done


> Upgrade to WildFly Client Config 1.0.0.Beta1
> --------------------------------------------
>
>                 Key: REMJMX-118
>                 URL: https://issues.jboss.org/browse/REMJMX-118
>             Project: Remoting JMX
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 04:02:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 6 Oct 2016 04:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in elytron model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.64499.1475740920738@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303287#comment-13303287 ] 

Jan Kalina commented on WFLY-7260:
----------------------------------

Yes, correct. If 'need' is true, value of 'want' is ignored.

> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 04:18:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 6 Oct 2016 04:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7031) Redirect Port Fails to
 Redirect to 3rd Party HTTP Port
In-Reply-To: <JIRA.12648161.1472739224000@Atlassian.JIRA>
References: <JIRA.12648161.1472739224000@Atlassian.JIRA>
	<JIRA.12648161.1472739224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648161.1472739224000.64524.1475741880672@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-7031.
-----------------------------
      Assignee: Tomaz Cerar  (was: Stuart Douglas)
    Resolution: Rejected


This is not an issue at all.
It is just misconfiguration and nothing else.

You need to configure secure port binding for http-listener so server knows to what https port to redirect if needed to. See "redirect-socket" config on http-listener


I think easiest for you would be to just upgrade to WildFly 10.1.0.Final which by default comes with https-listener configured and also redirect ports.

> Redirect Port Fails to Redirect to 3rd Party HTTP Port
> ------------------------------------------------------
>
>                 Key: WFLY-7031
>                 URL: https://issues.jboss.org/browse/WFLY-7031
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Joe Carder
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception:
> ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> With the redirect socket to a port opened by JBoss, it works as expected.  I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 04:44:00 2016
From: issues at jboss.org (lorenzo benvenuti (JIRA))
Date: Thu, 6 Oct 2016 04:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1321) Statement.cancel() is not
 invoked until the statement is completed
In-Reply-To: <JIRA.12628732.1464698993000@Atlassian.JIRA>
References: <JIRA.12628732.1464698993000@Atlassian.JIRA>
	<JIRA.12628732.1464698993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628732.1464698993000.64629.1475743440358@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303305#comment-13303305 ] 

lorenzo benvenuti commented on JBJCA-1321:
------------------------------------------

Hi, 

unfortunately this bug has became critical for our customers and we can't wait for a new version of Wildfly. We were thinking to proceed in this way:

- Download sources for tag 1.2.5.Final (the version Wildfly 9.0.2 is using)
- Apply patches from the PRs
- Build a new jar and swap the original with it

Should we perform some additional operation in order to be able to cancel the statement (such as enabling it in some configuration file or something like that)? Judging from the PRs I guess overwriting the jar should be enough but we want to be sure.

Thank you,

lorenzo

> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1321
>                 URL: https://issues.jboss.org/browse/JBJCA-1321
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
>            Reporter: lorenzo benvenuti
>            Assignee: Lin Gao
>            Priority: Critical
>             Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
>     {
>       if (doLocking)
>           lock();
>        try
>        {
>         /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock. 
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 05:00:03 2016
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Thu, 6 Oct 2016 05:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1321) Statement.cancel() is not
 invoked until the statement is completed
In-Reply-To: <JIRA.12628732.1464698993000@Atlassian.JIRA>
References: <JIRA.12628732.1464698993000@Atlassian.JIRA>
	<JIRA.12628732.1464698993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628732.1464698993000.64737.1475744403314@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303322#comment-13303322 ] 

Stefano Maestri commented on JBJCA-1321:
----------------------------------------

It would be better to ask this questions through our forum than jira.
Anyway the steps you described are correct. An alternative would be building latest 1.2 branch which already include this patch.

regards
S.

> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1321
>                 URL: https://issues.jboss.org/browse/JBJCA-1321
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
>            Reporter: lorenzo benvenuti
>            Assignee: Lin Gao
>            Priority: Critical
>             Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
>     {
>       if (doLocking)
>           lock();
>        try
>        {
>         /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock. 
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 05:01:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Thu, 6 Oct 2016 05:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1854) Wrong result on
 :browse-content(depth>0) on archived deployments deployed by deployment
 scanner
In-Reply-To: <JIRA.12653381.1475670440000@Atlassian.JIRA>
References: <JIRA.12653381.1475670440000@Atlassian.JIRA>
	<JIRA.12653381.1475670440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653381.1475670440000.64739.1475744460695@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet closed WFCORE-1854.
-------------------------------------
    Resolution: Cannot Reproduce Bug


> Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1854
>                 URL: https://issues.jboss.org/browse/WFCORE-1854
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: ehsavoie Hugonnet
>
> With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}
> WFCORE-1851 does not fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 05:02:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Thu, 6 Oct 2016 05:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1854) Wrong result on
 :browse-content(depth>0) on archived deployments deployed by deployment
 scanner
In-Reply-To: <JIRA.12653381.1475670440000@Atlassian.JIRA>
References: <JIRA.12653381.1475670440000@Atlassian.JIRA>
	<JIRA.12653381.1475670440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653381.1475670440000.64754.1475744520194@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303324#comment-13303324 ] 

ehsavoie Hugonnet commented on WFCORE-1854:
-------------------------------------------

Fixed by WFCORE-1851

> Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1854
>                 URL: https://issues.jboss.org/browse/WFCORE-1854
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: Michal Jurc
>            Assignee: ehsavoie Hugonnet
>
> With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result:
> {code}{
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         }
>     ]
> }
> {code}
> WFCORE-1851 does not fix this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 05:16:03 2016
From: issues at jboss.org (lorenzo benvenuti (JIRA))
Date: Thu, 6 Oct 2016 05:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1321) Statement.cancel() is not
 invoked until the statement is completed
In-Reply-To: <JIRA.12628732.1464698993000@Atlassian.JIRA>
References: <JIRA.12628732.1464698993000@Atlassian.JIRA>
	<JIRA.12628732.1464698993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628732.1464698993000.64831.1475745363565@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303333#comment-13303333 ] 

lorenzo benvenuti commented on JBJCA-1321:
------------------------------------------

Thank you Stefano (next time I'll post the question in the forum).

lorenzo



> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1321
>                 URL: https://issues.jboss.org/browse/JBJCA-1321
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
>            Reporter: lorenzo benvenuti
>            Assignee: Lin Gao
>            Priority: Critical
>             Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
>     {
>       if (doLocking)
>           lock();
>        try
>        {
>         /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock. 
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 05:37:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 6 Oct 2016 05:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7268) Elytron jdbc-realm *-index
 attributes validation
In-Reply-To: <JIRA.12653533.1475746550000@Atlassian.JIRA>
References: <JIRA.12653533.1475746550000@Atlassian.JIRA>
	<JIRA.12653533.1475746550000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653533.1475746550000.65005.1475746620275@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6314 to WFLY-7268:
-------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-7268  (was: JBEAP-6314)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Security
                     (was: Security)


> Elytron jdbc-realm *-index attributes validation
> ------------------------------------------------
>
>                 Key: WFLY-7268
>                 URL: https://issues.jboss.org/browse/WFLY-7268
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Priority: Minor
>
> If I try to set any of password mapper (e.g. {{clear-password-mapper}}) and any of *-index attribute (e.g. {{password-index}}) with 0 value I get error from elytron
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/jdbc-realm=d:add(principal-query=[{sql="a",data-source="ExampleDS", bcrypt-mapper={password-index=0, salt-index=1, iteration-count-index=2}}])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: COM00001: Parameter 'hashColumn' must not be less than 1",
>     "rolled-back" => true
> }
> {code}
> and exception in server log
> {code}
> 07:16:47,608 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("jdbc-realm" => "b")
> ]): java.lang.IllegalArgumentException: COM00001: Parameter 'hashColumn' must not be less than 1
> 	at org.wildfly.common.Assert.checkMinimumParameter(Assert.java:132)
> 	at org.wildfly.security.auth.realm.jdbc.mapper.PasswordKeyMapper.<init>(PasswordKeyMapper.java:63)
> 	at org.wildfly.security.auth.realm.jdbc.mapper.PasswordKeyMapper$Builder.build(PasswordKeyMapper.java:389)
> 	at org.wildfly.extension.elytron.JdbcRealmDefinition$ClearPasswordObjectDefinition.toPasswordKeyMapper(JdbcRealmDefinition.java:133)
> 	at org.wildfly.extension.elytron.JdbcRealmDefinition$RealmAddHandler.resolveKeyMappers(JdbcRealmDefinition.java:571)
> 	at org.wildfly.extension.elytron.JdbcRealmDefinition$RealmAddHandler.performRuntime(JdbcRealmDefinition.java:534)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Could that be validated in subsystem? There would be 2 benefits:
> * no exception is thrown in log. Exception seems like something suprised us.
> * message contains more proper attribute name, e.g. hashColumn -> password-index.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 05:51:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Thu, 6 Oct 2016 05:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6409) Update default domain
 configuration to use remote+http
In-Reply-To: <JIRA.12611162.1458392141000@Atlassian.JIRA>
References: <JIRA.12611162.1458392141000@Atlassian.JIRA>
	<JIRA.12611162.1458392141000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611162.1458392141000.65037.1475747460326@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFLY-6409:
------------------------------------
    Summary: Update default domain configuration to use remote+http  (was: Update default domain configuration to use http-remoting)


> Update default domain configuration to use remote+http
> ------------------------------------------------------
>
>                 Key: WFLY-6409
>                 URL: https://issues.jboss.org/browse/WFLY-6409
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Our default domain configuration still use the native remote protocol on port 9999 for DC-HC communication. Update those files so that we use http-remoting on port 9990.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 06:15:01 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Thu, 6 Oct 2016 06:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7236) DatasourceNonCcmTestCase
 fails with security manager
In-Reply-To: <JIRA.12652491.1475131449000@Atlassian.JIRA>
References: <JIRA.12652491.1475131449000@Atlassian.JIRA>
	<JIRA.12652491.1475131449000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652491.1475131449000.65178.1475748901277@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFLY-7236:
--------------------------------

    Assignee: Ingo Weiss  (was: Jan Tymel)


> DatasourceNonCcmTestCase fails with security manager
> ----------------------------------------------------
>
>                 Key: WFLY-7236
>                 URL: https://issues.jboss.org/browse/WFLY-7236
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ingo Weiss
>
> *org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase#testJTADS*
> *org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase#testNonJTADS*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase -Dsecurity.manager}}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/dummy.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.dummy.jar:main" from Service Module Loader")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:85)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:120)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:64)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:139)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:114)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> 	... 146 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 07:12:00 2016
From: issues at jboss.org (Kavi sri (JIRA))
Date: Thu, 6 Oct 2016 07:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1319) Workbench Remote Maven
 artifacts deployment
In-Reply-To: <JIRA.12653574.1475752306000@Atlassian.JIRA>
References: <JIRA.12653574.1475752306000@Atlassian.JIRA>
	<JIRA.12653574.1475752306014@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653574.1475752306000.65498.1475752320194@Atlassian.JIRA>

Kavi sri created DROOLS-1319:
--------------------------------

             Summary: Workbench Remote Maven artifacts deployment
                 Key: DROOLS-1319
                 URL: https://issues.jboss.org/browse/DROOLS-1319
             Project: Drools
          Issue Type: Feature Request
            Reporter: Kavi sri
            Assignee: Edson Tirelli


Hi,

I created Rules in Drools workbench 6.2. And deployed the same as a Maven artifact to my local folder in Centos (/local/.m2 - Assuming my Workbench also deployed in the same Centos. Now i want to deploy the artifacts from Drools workbench to remote server [Say other Centos / Nexus repository]. How can i achieve it. Please suggest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 07:18:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Thu, 6 Oct 2016 07:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7235) InfinispanResourceRefTestCase
 fails with security manager
In-Reply-To: <JIRA.12652486.1475130784000@Atlassian.JIRA>
References: <JIRA.12652486.1475130784000@Atlassian.JIRA>
	<JIRA.12652486.1475130784000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652486.1475130784000.65522.1475752680994@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFLY-7235:
--------------------------------

    Assignee: Ingo Weiss  (was: Jan Tymel)


> InfinispanResourceRefTestCase fails with security manager
> ---------------------------------------------------------
>
>                 Key: WFLY-7235
>                 URL: https://issues.jboss.org/browse/WFLY-7235
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ingo Weiss
>
> *org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" from Service Module Loader")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> 	at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
> 	at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
> 	at org.infinispan.commons.util.Util.loadClassStrict(Util.java:163)
> 	at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319)
> 	at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313)
> 	at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810)
> 	at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213)
> 	at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
> 	at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171)
> 	at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163)
> 	at org.infinispan.factories.ComponentRegistry.<init>(ComponentRegistry.java:79)
> 	... 210 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 08:06:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 6 Oct 2016 08:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7268) Elytron jdbc-realm *-index
 attributes validation
In-Reply-To: <JIRA.12653533.1475746550000@Atlassian.JIRA>
References: <JIRA.12653533.1475746550000@Atlassian.JIRA>
	<JIRA.12653533.1475746550000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653533.1475746550000.65761.1475755560483@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7268:
-----------------------------------

    Assignee: Ilia Vassilev


> Elytron jdbc-realm *-index attributes validation
> ------------------------------------------------
>
>                 Key: WFLY-7268
>                 URL: https://issues.jboss.org/browse/WFLY-7268
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Minor
>
> If I try to set any of password mapper (e.g. {{clear-password-mapper}}) and any of *-index attribute (e.g. {{password-index}}) with 0 value I get error from elytron
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/jdbc-realm=d:add(principal-query=[{sql="a",data-source="ExampleDS", bcrypt-mapper={password-index=0, salt-index=1, iteration-count-index=2}}])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: COM00001: Parameter 'hashColumn' must not be less than 1",
>     "rolled-back" => true
> }
> {code}
> and exception in server log
> {code}
> 07:16:47,608 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("jdbc-realm" => "b")
> ]): java.lang.IllegalArgumentException: COM00001: Parameter 'hashColumn' must not be less than 1
> 	at org.wildfly.common.Assert.checkMinimumParameter(Assert.java:132)
> 	at org.wildfly.security.auth.realm.jdbc.mapper.PasswordKeyMapper.<init>(PasswordKeyMapper.java:63)
> 	at org.wildfly.security.auth.realm.jdbc.mapper.PasswordKeyMapper$Builder.build(PasswordKeyMapper.java:389)
> 	at org.wildfly.extension.elytron.JdbcRealmDefinition$ClearPasswordObjectDefinition.toPasswordKeyMapper(JdbcRealmDefinition.java:133)
> 	at org.wildfly.extension.elytron.JdbcRealmDefinition$RealmAddHandler.resolveKeyMappers(JdbcRealmDefinition.java:571)
> 	at org.wildfly.extension.elytron.JdbcRealmDefinition$RealmAddHandler.performRuntime(JdbcRealmDefinition.java:534)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Could that be validated in subsystem? There would be 2 benefits:
> * no exception is thrown in log. Exception seems like something suprised us.
> * message contains more proper attribute name, e.g. hashColumn -> password-index.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 08:23:00 2016
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Thu, 6 Oct 2016 08:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1320) [OSGi] drools-compiler uses
 wrong package name to import kie-ci
In-Reply-To: <JIRA.12653598.1475756560000@Atlassian.JIRA>
References: <JIRA.12653598.1475756560000@Atlassian.JIRA>
	<JIRA.12653598.1475756560552@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653598.1475756560000.65828.1475756580474@Atlassian.JIRA>

Petr ?irok? created DROOLS-1320:
-----------------------------------

             Summary: [OSGi] drools-compiler uses wrong package name to import kie-ci
                 Key: DROOLS-1320
                 URL: https://issues.jboss.org/browse/DROOLS-1320
             Project: Drools
          Issue Type: Bug
            Reporter: Petr ?irok?
            Assignee: Petr ?irok?


drools-compiler is optionally importing {{org.kie.scanner}} package as that is needed to work with the {{kie-ci}} in OSGi. The package import is, however, incorrect: {{=org.kie.scanner.*;resolution:=optional}} will _not_ get transformed into the actual package name, but rather stays as {{org.kie.scanner.*}}, which is not valid. This needs to be changed to just {{org.kie.scanner}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct  6 08:24:00 2016
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Thu, 6 Oct 2016 08:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1320) [OSGi] drools-compiler uses
 wrong package name to import kie-ci
In-Reply-To: <JIRA.12653598.1475756561000@Atlassian.JIRA>
References: <JIRA.12653598.1475756561000@Atlassian.JIRA>
	<JIRA.12653598.1475756561000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653598.1475756561000.65830.1475756640100@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? updated DROOLS-1320:
--------------------------------
    Description: drools-compiler is optionally importing {{org.kie.scanner}} package as that is needed to work with the {{kie-ci}} in OSGi. The package import is, however, incorrect: {{=org.kie.scanner.\*;resolution:=optional}} will _not_ get transformed into the actual package name, but rather stays as {{org.kie.scanner.*}}, which is not valid. This needs to be changed to just {{org.kie.scanner}}.  (was: drools-compiler is optionally importing {{org.kie.scanner}} package as that is needed to work with the {{kie-ci}} in OSGi. The package import is, however, incorrect: {{=org.kie.scanner.*;resolution:=optional}} will _not_ get transformed into the actual package name, but rather stays as {{org.kie.scanner.*}}, which is not valid. This needs to be changed to just {{org.kie.scanner}}.)


> [OSGi] drools-compiler uses wrong package name to import kie-ci
> ---------------------------------------------------------------
>
>                 Key: DROOLS-1320
>                 URL: https://issues.jboss.org/browse/DROOLS-1320
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Petr ?irok?
>            Assignee: Petr ?irok?
>
> drools-compiler is optionally importing {{org.kie.scanner}} package as that is needed to work with the {{kie-ci}} in OSGi. The package import is, however, incorrect: {{=org.kie.scanner.\*;resolution:=optional}} will _not_ get transformed into the actual package name, but rather stays as {{org.kie.scanner.*}}, which is not valid. This needs to be changed to just {{org.kie.scanner}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct  6 08:50:00 2016
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 6 Oct 2016 08:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1319) Workbench Remote Maven
 artifacts deployment
In-Reply-To: <JIRA.12653574.1475752306000@Atlassian.JIRA>
References: <JIRA.12653574.1475752306000@Atlassian.JIRA>
	<JIRA.12653574.1475752306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653574.1475752306000.66023.1475758200732@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303440#comment-13303440 ] 

Edson Tirelli commented on DROOLS-1319:
---------------------------------------

Configure the maven settings.xml file to deploy to the remote server.

> Workbench Remote Maven artifacts deployment
> -------------------------------------------
>
>                 Key: DROOLS-1319
>                 URL: https://issues.jboss.org/browse/DROOLS-1319
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Kavi sri
>            Assignee: Edson Tirelli
>
> Hi,
> I created Rules in Drools workbench 6.2. And deployed the same as a Maven artifact to my local folder in Centos (/local/.m2 - Assuming my Workbench also deployed in the same Centos. Now i want to deploy the artifacts from Drools workbench to remote server [Say other Centos / Nexus repository]. How can i achieve it. Please suggest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 08:50:00 2016
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 6 Oct 2016 08:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1319) Workbench Remote Maven
 artifacts deployment
In-Reply-To: <JIRA.12653574.1475752306000@Atlassian.JIRA>
References: <JIRA.12653574.1475752306000@Atlassian.JIRA>
	<JIRA.12653574.1475752306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653574.1475752306000.66026.1475758200835@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed DROOLS-1319.
---------------------------------
    Resolution: Rejected


> Workbench Remote Maven artifacts deployment
> -------------------------------------------
>
>                 Key: DROOLS-1319
>                 URL: https://issues.jboss.org/browse/DROOLS-1319
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Kavi sri
>            Assignee: Edson Tirelli
>
> Hi,
> I created Rules in Drools workbench 6.2. And deployed the same as a Maven artifact to my local folder in Centos (/local/.m2 - Assuming my Workbench also deployed in the same Centos. Now i want to deploy the artifacts from Drools workbench to remote server [Say other Centos / Nexus repository]. How can i achieve it. Please suggest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 09:16:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 6 Oct 2016 09:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.66667.1475759760679@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303456#comment-13303456 ] 

Mario Fusco commented on DROOLS-1318:
-------------------------------------

[~nheron] I also tried to define an enum in a top level class (as you can see in the following test case) but it still works for me.

{code}
    @Test
    public void testMvelWithEnum() {
        String drl =
                "import " + Address.class.getCanonicalName() + ";\n" +
                "import " + AddressType.class.getCanonicalName() + ";\n" +
                "rule R dialect \"mvel\" when\n" +
                "    $a : Address(addressType == AddressType.OFFICE)\n" +
                "then\n" +
                "    $a.setAddressType(AddressType.HOME);\n" +
                "    update($a);\n" +
                "end";

        KieSession kieSession = new KieHelper().addContent(drl, ResourceType.DRL).build().newKieSession();

        Address address = new Address();
        address.setAddressType( AddressType.OFFICE );
        kieSession.insert( address );
        kieSession.fireAllRules();

        assertEquals(AddressType.HOME, address.getAddressType());
    }
{code}

> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Nicolas Heron
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 09:19:00 2016
From: issues at jboss.org (Kavi sri (JIRA))
Date: Thu, 6 Oct 2016 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1319) Workbench Remote Maven
 artifacts deployment
In-Reply-To: <JIRA.12653574.1475752306000@Atlassian.JIRA>
References: <JIRA.12653574.1475752306000@Atlassian.JIRA>
	<JIRA.12653574.1475752306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653574.1475752306000.66710.1475759940368@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303462#comment-13303462 ] 

Kavi sri commented on DROOLS-1319:
----------------------------------

Hi Edson,

Could you please share me some links / sample configs so that i  can try out the same in my project ?

Thanks,
Kavi sri K K

> Workbench Remote Maven artifacts deployment
> -------------------------------------------
>
>                 Key: DROOLS-1319
>                 URL: https://issues.jboss.org/browse/DROOLS-1319
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Kavi sri
>            Assignee: Edson Tirelli
>
> Hi,
> I created Rules in Drools workbench 6.2. And deployed the same as a Maven artifact to my local folder in Centos (/local/.m2 - Assuming my Workbench also deployed in the same Centos. Now i want to deploy the artifacts from Drools workbench to remote server [Say other Centos / Nexus repository]. How can i achieve it. Please suggest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 09:35:00 2016
From: issues at jboss.org (Farah Juma (JIRA))
Date: Thu, 6 Oct 2016 09:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-114) Actually make use of the
 provided callback handler in RemotingConnector or set up the callback
 handler appropriately if it hasn't been provided
In-Reply-To: <JIRA.12653486.1475709747000@Atlassian.JIRA>
References: <JIRA.12653486.1475709747000@Atlassian.JIRA>
	<JIRA.12653486.1475709747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653486.1475709747000.66790.1475760900213@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma resolved REMJMX-114.
-------------------------------
    Resolution: Done


> Actually make use of the provided callback handler in RemotingConnector or set up the callback handler appropriately if it hasn't been provided
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: REMJMX-114
>                 URL: https://issues.jboss.org/browse/REMJMX-114
>             Project: Remoting JMX
>          Issue Type: Bug
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: 3.0.0.Alpha2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 09:52:01 2016
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 6 Oct 2016 09:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1319) Workbench Remote Maven
 artifacts deployment
In-Reply-To: <JIRA.12653574.1475752306000@Atlassian.JIRA>
References: <JIRA.12653574.1475752306000@Atlassian.JIRA>
	<JIRA.12653574.1475752306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653574.1475752306000.66991.1475761921019@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303496#comment-13303496 ] 

Edson Tirelli commented on DROOLS-1319:
---------------------------------------

Chapter 4.2.3.5:

http://docs.jboss.org/drools/release/6.4.0.Final/drools-docs/html/ch04.html#KIEDeployingSection




> Workbench Remote Maven artifacts deployment
> -------------------------------------------
>
>                 Key: DROOLS-1319
>                 URL: https://issues.jboss.org/browse/DROOLS-1319
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Kavi sri
>            Assignee: Edson Tirelli
>
> Hi,
> I created Rules in Drools workbench 6.2. And deployed the same as a Maven artifact to my local folder in Centos (/local/.m2 - Assuming my Workbench also deployed in the same Centos. Now i want to deploy the artifacts from Drools workbench to remote server [Say other Centos / Nexus repository]. How can i achieve it. Please suggest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:01:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Thu, 6 Oct 2016 10:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6937) Some JMS tests fail with
	security manager
In-Reply-To: <JIRA.12642680.1470810463000@Atlassian.JIRA>
References: <JIRA.12642680.1470810463000@Atlassian.JIRA>
	<JIRA.12642680.1470810463000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642680.1470810463000.67049.1475762460092@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303503#comment-13303503 ] 

Ingo Weiss commented on WFLY-6937:
----------------------------------

It seems these are fixed on {{master}}.

> Some JMS tests fail with security manager
> -----------------------------------------
>
>                 Key: WFLY-6937
>                 URL: https://issues.jboss.org/browse/WFLY-6937
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Jan Tymel
>
> *org.jboss.as.test.integration.messaging.jms.context.VaultedInjectedJMSContextTestCase#sendMessage*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.messaging.jms.context.VaultedInjectedJMSContextTestCase#sendMessage -Dsecurity.manager}}
> Fails with:
> {code}
> WARN  [org.apache.activemq.artemis.core.client] (pool-3-thread-1) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/VaultedInjectedJMSContextTestCase.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.Class.checkMemberAccess(Class.java:2348)
> 	at java.lang.Class.getDeclaredFields(Class.java:1915)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:938)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:896)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.init(AbstractChannelHandlerContext.java:968)
> 	at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.newInstance(AbstractChannelHandlerContext.java:1044)
> 	at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.access$1600(AbstractChannelHandlerContext.java:1032)
> 	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:707)
> 	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:691)
> 	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:717)
> 	at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:954)
> 	at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:244)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:662)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1009)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1053)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1232)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:867)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:769)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:760)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createContext(ActiveMQConnectionFactory.java:255)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.AbstractJMSContext.createContext(AbstractJMSContext.java:64)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.AbstractJMSContext.getContext(AbstractJMSContext.java:49)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:109)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createProducer(JMSContextWrapper.java:66)
> 	at org.jboss.as.test.integration.messaging.jms.context.auxiliary.VaultedMessageProducer.sendToDestination(VaultedMessageProducer.java:47)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.messaging.jms.context.auxiliary.VaultedMessageProducer$$$view5.sendToDestination(Unknown Source)
> 	at org.jboss.as.test.integration.messaging.jms.context.VaultedInjectedJMSContextTestCase.sendMessage(VaultedInjectedJMSContextTestCase.java:171)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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}
> *org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase#testAnnotationBasedDefinitionsWithVaultedAttributes*
> *org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase#testDeploymendDescriptorBasedDefinitionsWithVaultedAttributes*
> *org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase#testInjectedDefinitions*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase -Dsecurity.manager}}
> Fails with:
> {code}
> WARN  [org.apache.activemq.artemis.core.client] (pool-3-thread-2) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/JMSResourceDefinitionsTestCase.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.Class.checkMemberAccess(Class.java:200)
> 	at java.lang.Class.getDeclaredFields(Class.java:823)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:938)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:896)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.init(AbstractChannelHandlerContext.java:968)
> 	at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.newInstance(AbstractChannelHandlerContext.java:1044)
> 	at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.access$1600(AbstractChannelHandlerContext.java:1032)
> 	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:707)
> 	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:691)
> 	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:717)
> 	at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:954)
> 	at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:244)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:662)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1009)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1053)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1232)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:867)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:769)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:760)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXAConnection(ActiveMQConnectionFactory.java:304)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:782)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:163)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:149)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1320)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:699)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:598)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:739)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:467)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:420)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:410)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:405)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean.checkDeploymendDescriptorBasedDefinitionsWithVaultedAttributes(MessagingBean.java:201)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean$$$view238.checkDeploymendDescriptorBasedDefinitionsWithVaultedAttributes(Unknown Source)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase.testDeploymendDescriptorBasedDefinitionsWithVaultedAttributes(JMSResourceDefinitionsTestCase.java:163)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83)
> 	at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at javax.security.auth.Subject.doAs(Subject.java:569)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> {code}
> I saw these tests also failing with:
> {code}
> WARN  [org.apache.activemq.artemis.core.client] (pool-3-thread-1) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost" "resolve")" in code source "(vfs:/content/JMSResourceDefinitionsTestCase.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkConnect(SecurityManager.java:1048)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:407)
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1268)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> 	at java.net.InetAddress.getByName(InetAddress.java:1076)
> 	at java.net.InetSocketAddress.<init>(InetSocketAddress.java:220)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:575)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1009)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1053)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1232)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:867)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:769)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:760)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXAConnection(ActiveMQConnectionFactory.java:304)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:782)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:163)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:149)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1320)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:699)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:598)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:739)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:467)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:420)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean.checkInjectedResources(MessagingBean.java:182)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean$$$view1.checkInjectedResources(Unknown Source)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase.testInjectedDefinitions(JMSResourceDefinitionsTestCase.java:153)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:02:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 6 Oct 2016 10:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4376) Incorrect callback handler
 used during authentication (SASL)
In-Reply-To: <JIRA.12563759.1424418580000@Atlassian.JIRA>
References: <JIRA.12563759.1424418580000@Atlassian.JIRA>
	<JIRA.12563759.1424418580000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12563759.1424418580000.67055.1475762520508@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303504#comment-13303504 ] 

RH Bugzilla Integration commented on WFLY-4376:
-----------------------------------------------

Ji?? B?lek <jbilek at redhat.com> changed the Status of [bug 901248|https://bugzilla.redhat.com/show_bug.cgi?id=901248] from ON_QA to ASSIGNED

> Incorrect callback handler used  during authentication (SASL)
> -------------------------------------------------------------
>
>                 Key: WFLY-4376
>                 URL: https://issues.jboss.org/browse/WFLY-4376
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>            Reporter: Enrique Gonz?lez Mart?nez
>            Assignee: Enrique Gonz?lez Mart?nez
>             Fix For: 10.0.0.CR5
>
>
> Cluster topology messages are not using the proper callbackhandler when the connection is being established.
> {code}
> 06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> 06:59:44,611 INFO  [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> 	at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
> 	at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
> 	at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406)
> 	at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:662)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> 	at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382)
> 	at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> 	at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> 	at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> 	at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386)
> 	at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151)
> 	at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132)
> 	at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87)
> 	... 7 more
> {code}
> Before that, this log is produced:
> {code}
> DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct  6 10:03:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Thu, 6 Oct 2016 10:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6936) RebindTestCase fails with
	security manager
In-Reply-To: <JIRA.12642677.1470808871000@Atlassian.JIRA>
References: <JIRA.12642677.1470808871000@Atlassian.JIRA>
	<JIRA.12642677.1470808871000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642677.1470808871000.67076.1475762580965@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFLY-6936:
--------------------------------

    Assignee: Ingo Weiss  (was: Jan Tymel)


> RebindTestCase fails with security manager
> ------------------------------------------
>
>                 Key: WFLY-6936
>                 URL: https://issues.jboss.org/browse/WFLY-6936
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ingo Weiss
>
> *org.jboss.as.test.integration.naming.RebindTestCase#testRebinding*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.naming.RebindTestCase#testRebinding -Dsecurity.manager}}
> Fails with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/RebindTestCase.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:85)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:120)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:64)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:139)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:114)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> 	... 145 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:41:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 6 Oct 2016 10:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6884) Add XSD schema testing for
 clustering subsystems
In-Reply-To: <JIRA.12640927.1469640337000@Atlassian.JIRA>
References: <JIRA.12640927.1469640337000@Atlassian.JIRA>
	<JIRA.12640927.1469640337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640927.1469640337000.67460.1475764860271@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-6884.
--------------------------------
    Resolution: Rejected


I don't see the value actually of these tests.


> Add XSD schema testing for clustering subsystems
> ------------------------------------------------
>
>                 Key: WFLY-6884
>                 URL: https://issues.jboss.org/browse/WFLY-6884
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 10.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> I noticed a large batch of ignored tests in clustering subsystems, the missing bits and pieces that allow for XSD testing were missing in infinispan, jgroups and singleton subsystems.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:45:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 6 Oct 2016 10:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7269) Infinispan XSD schema does
 not allow <backup-for> and <backups> to coexist
In-Reply-To: <JIRA.12653629.1475765072000@Atlassian.JIRA>
References: <JIRA.12653629.1475765072000@Atlassian.JIRA>
	<JIRA.12653629.1475765072402@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653629.1475765072000.67479.1475765100286@Atlassian.JIRA>

Radoslav Husar created WFLY-7269:
------------------------------------

             Summary: Infinispan XSD schema does not allow <backup-for> and <backups> to coexist
                 Key: WFLY-7269
                 URL: https://issues.jboss.org/browse/WFLY-7269
             Project: WildFly
          Issue Type: Bug
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:45:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 6 Oct 2016 10:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7269) Infinispan XSD schema does
 not allow <backup-for> and <backups> to coexist
In-Reply-To: <JIRA.12653629.1475765072000@Atlassian.JIRA>
References: <JIRA.12653629.1475765072000@Atlassian.JIRA>
	<JIRA.12653629.1475765072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653629.1475765072000.67482.1475765101565@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7269:
---------------------------------
    Component/s: Clustering


> Infinispan XSD schema does not allow <backup-for> and <backups> to coexist
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7269
>                 URL: https://issues.jboss.org/browse/WFLY-7269
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.Final, 10.0.0.Final, 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:45:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 6 Oct 2016 10:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7269) Infinispan XSD schema does
 not allow <backup-for> and <backups> to coexist
In-Reply-To: <JIRA.12653629.1475765072000@Atlassian.JIRA>
References: <JIRA.12653629.1475765072000@Atlassian.JIRA>
	<JIRA.12653629.1475765072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653629.1475765072000.67485.1475765101668@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7269:
---------------------------------
    Affects Version/s: 10.1.0.Final
                       10.0.0.Final


> Infinispan XSD schema does not allow <backup-for> and <backups> to coexist
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7269
>                 URL: https://issues.jboss.org/browse/WFLY-7269
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.Final, 10.0.0.Final, 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:45:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 6 Oct 2016 10:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7269) Infinispan XSD schema does
 not allow <backup-for> and <backups> to coexist
In-Reply-To: <JIRA.12653629.1475765072000@Atlassian.JIRA>
References: <JIRA.12653629.1475765072000@Atlassian.JIRA>
	<JIRA.12653629.1475765072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653629.1475765072000.67488.1475765101745@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7269:
---------------------------------
    Affects Version/s: 9.0.0.Final


> Infinispan XSD schema does not allow <backup-for> and <backups> to coexist
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7269
>                 URL: https://issues.jboss.org/browse/WFLY-7269
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.Final, 10.0.0.Final, 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:48:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 6 Oct 2016 10:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7270) Infinispan XSD schema does
 not allow <backup-for> and <backups> to coexist
In-Reply-To: <JIRA.12653630.1475765271000@Atlassian.JIRA>
References: <JIRA.12653630.1475765271000@Atlassian.JIRA>
	<JIRA.12653630.1475765271825@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653630.1475765271000.67509.1475765280474@Atlassian.JIRA>

Radoslav Husar created WFLY-7270:
------------------------------------

             Summary: Infinispan XSD schema does not allow <backup-for> and <backups> to coexist
                 Key: WFLY-7270
                 URL: https://issues.jboss.org/browse/WFLY-7270
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 9.0.0.Final, 10.0.0.Final, 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:48:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 6 Oct 2016 10:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7269) Infinispan XSD schema does
 not allow <backup-for> and <backups> to coexist
In-Reply-To: <JIRA.12653629.1475765072000@Atlassian.JIRA>
References: <JIRA.12653629.1475765072000@Atlassian.JIRA>
	<JIRA.12653629.1475765072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653629.1475765072000.67507.1475765280429@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7269:
---------------------------------
    Priority: Minor  (was: Major)


> Infinispan XSD schema does not allow <backup-for> and <backups> to coexist
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7269
>                 URL: https://issues.jboss.org/browse/WFLY-7269
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.Final, 10.0.0.Final, 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 10:52:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 6 Oct 2016 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1677) Make
 AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with
 substitutions properly
In-Reply-To: <JIRA.12640924.1469638377000@Atlassian.JIRA>
References: <JIRA.12640924.1469638377000@Atlassian.JIRA>
	<JIRA.12640924.1469638377000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640924.1469638377000.67542.1475765520206@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303548#comment-13303548 ] 

Radoslav Husar commented on WFCORE-1677:
----------------------------------------

Ok, I don't see the usefullness of these tests in general as well as these cannot be reliable (given this Jira) so I think we should remove them actually completely since StandardConfigsXMLValidationUnitTestCase.java is satisfactory.

> Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1677
>                 URL: https://issues.jboss.org/browse/WFCORE-1677
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 2.2.0.CR8
>            Reporter: Radoslav Husar
>            Assignee: Kabir Khan
>            Priority: Minor
>
> It sounds to me that the test should really be validating the generated XML files, rather than the templates.
> {noformat}
> testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase)  Time elapsed: 0.052 sec  <<< FAILURE!
> java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73)
> 	at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
> 	at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
> 	at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> 	at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383)
> 	at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894)
> 	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673)
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
> 	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> 	at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
> 	at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
> 	at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186)
> 	at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129)
> 	at javax.xml.validation.Validator.validate(Validator.java:124)
> 	at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123)
> 	at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101)
> 	at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144)
> 	at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130)
> Results :
> Failed tests:
>   SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 11:12:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Thu, 6 Oct 2016 11:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6934) ParticipantTestCase fails
 with security manager
In-Reply-To: <JIRA.12642620.1470751116000@Atlassian.JIRA>
References: <JIRA.12642620.1470751116000@Atlassian.JIRA>
	<JIRA.12642620.1470751116000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642620.1470751116000.67696.1475766720333@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFLY-6934:
--------------------------------

    Assignee: Ingo Weiss  (was: Jan Tymel)


> ParticipantTestCase fails with security manager
> -----------------------------------------------
>
>                 Key: WFLY-6934
>                 URL: https://issues.jboss.org/browse/WFLY-6934
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ingo Weiss
>
> *org.wildfly.test.extension.rts.ParticipantTestCase*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.rts -Dtest=org.wildfly.test.extension.rts.ParticipantTestCase -Dsecurity.manager}}
> {code}
> 15:56:43,121 ERROR [stderr] (default task-1) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/test-deployment.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "null")
> 15:56:43,129 ERROR [stderr] (default task-1) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 15:56:43,130 ERROR [stderr] (default task-1) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 15:56:43,131 ERROR [stderr] (default task-1) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
> 15:56:43,139 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
> 15:56:43,143 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
> 15:56:43,144 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
> 15:56:43,146 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
> 15:56:43,148 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
> 15:56:43,148 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
> 15:56:43,154 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
> 15:56:43,164 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
> 15:56:43,168 ERROR [stderr] (default task-1) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 15:56:43,173 ERROR [stderr] (default task-1) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 15:56:43,174 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 15:56:43,175 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 15:56:43,177 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 15:56:43,180 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 15:56:43,182 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:56:43,183 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 15:56:43,190 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 15:56:43,191 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:56:43,194 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 15:56:43,201 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 15:56:43,208 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 15:56:43,210 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 15:56:43,212 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 15:56:43,215 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 15:56:43,219 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:56:43,222 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 15:56:43,239 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:56:43,248 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:56:43,255 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 15:56:43,261 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 15:56:43,262 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 15:56:43,263 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 15:56:43,269 ERROR [stderr] (default task-1) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 15:56:43,271 ERROR [stderr] (default task-1) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 15:56:43,274 ERROR [stderr] (default task-1) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:56:43,278 ERROR [stderr] (default task-1) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:56:43,282 ERROR [stderr] (default task-1) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:56:43,284 ERROR [stderr] (default task-1) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:56:43,285 ERROR [stderr] (default task-1) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:56:43,288 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 15:56:43,290 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 15:56:43,291 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> 15:56:43,292 ERROR [stderr] (default task-1) 	at java.security.AccessController.doPrivileged(Native Method)
> 15:56:43,293 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> 15:56:43,299 ERROR [stderr] (default task-1) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 15:56:43,301 ERROR [stderr] (default task-1) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> 15:56:43,304 ERROR [stderr] (default task-1) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 15:56:43,306 ERROR [stderr] (default task-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 11:19:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Thu, 6 Oct 2016 11:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6933) CompensationScopedTestCase
 fails with security managed
In-Reply-To: <JIRA.12642613.1470749481000@Atlassian.JIRA>
References: <JIRA.12642613.1470749481000@Atlassian.JIRA>
	<JIRA.12642613.1470749481000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642613.1470749481000.67738.1475767140134@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFLY-6933:
--------------------------------

    Assignee: Ingo Weiss  (was: Jan Tymel)


> CompensationScopedTestCase fails with security managed
> ------------------------------------------------------
>
>                 Key: WFLY-6933
>                 URL: https://issues.jboss.org/browse/WFLY-6933
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ingo Weiss
>
> *org.jboss.as.test.xts.annotation.compensationScoped.CompensationScopedTestCase#shouldSeeDifferentValuesInDifferentTransactions*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=org.jboss.as.test.xts.annotation.compensationScoped.CompensationScopedTestCase#shouldSeeDifferentValuesInDifferentTransactions -Dsecurity.manager}}
> {code}
> 15:26:29,602 ERROR [stderr] (default task-2) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/test.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "null")
> 15:26:29,603 ERROR [stderr] (default task-2) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 15:26:29,604 ERROR [stderr] (default task-2) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 15:26:29,604 ERROR [stderr] (default task-2) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
> 15:26:29,612 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
> 15:26:29,618 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
> 15:26:29,619 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
> 15:26:29,619 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
> 15:26:29,620 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
> 15:26:29,621 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
> 15:26:29,621 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
> 15:26:29,624 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
> 15:26:29,624 ERROR [stderr] (default task-2) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 15:26:29,636 ERROR [stderr] (default task-2) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 15:26:29,638 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 15:26:29,639 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 15:26:29,639 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 15:26:29,640 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 15:26:29,641 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:26:29,642 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 15:26:29,642 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 15:26:29,643 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:26:29,644 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 15:26:29,644 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 15:26:29,645 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 15:26:29,646 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 15:26:29,646 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 15:26:29,647 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 15:26:29,648 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:26:29,649 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 15:26:29,650 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:26:29,651 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 15:26:29,651 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 15:26:29,652 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 15:26:29,652 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 15:26:29,653 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 15:26:29,653 ERROR [stderr] (default task-2) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 15:26:29,654 ERROR [stderr] (default task-2) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 15:26:29,654 ERROR [stderr] (default task-2) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:26:29,655 ERROR [stderr] (default task-2) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:26:29,655 ERROR [stderr] (default task-2) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:26:29,656 ERROR [stderr] (default task-2) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:26:29,656 ERROR [stderr] (default task-2) 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 15:26:29,657 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 15:26:29,658 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 15:26:29,658 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> 15:26:29,659 ERROR [stderr] (default task-2) 	at java.security.AccessController.doPrivileged(Native Method)
> 15:26:29,660 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> 15:26:29,661 ERROR [stderr] (default task-2) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 15:26:29,662 ERROR [stderr] (default task-2) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> 15:26:29,663 ERROR [stderr] (default task-2) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 15:26:29,664 ERROR [stderr] (default task-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 15:26:29,664 ERROR [stderr] (default task-2) 	at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 11:38:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 6 Oct 2016 11:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7271) Review elytron jdbc-realm
 resource XSD definition
In-Reply-To: <JIRA.12653639.1475767977000@Atlassian.JIRA>
References: <JIRA.12653639.1475767977000@Atlassian.JIRA>
	<JIRA.12653639.1475767977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653639.1475767977000.67913.1475768280374@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6322 to WFLY-7271:
-------------------------------------------

           Project: WildFly  (was: JBoss Enterprise Application Platform)
               Key: WFLY-7271  (was: JBEAP-6322)
          Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
       Component/s: Security
                        (was: Security)
    Target Release:   (was: 7.1.0.GA)


> Review elytron jdbc-realm resource XSD definition
> -------------------------------------------------
>
>                 Key: WFLY-7271
>                 URL: https://issues.jboss.org/browse/WFLY-7271
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>
> * Wouldn't {{xsd:all}} be more proper than {{xsd:sequence}} here, as it doesn't required elements in exact order.
> * In XSD attribute-mapping attribute {{to}} is declared as optional, but in fact it is required.
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/jdbc-realm=a:add(principal-query=[{sql="a",data-source="ExampleDS",attribute-mapping=[{index=0}]}])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0155: to may not be null",
>     "rolled-back" => true
> }
> {code}
> * simple-digest-mapper, salted-simple-digest-mapper and scram-mapper missing {{algorithm}} attribute in XSD



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 12:13:01 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 6 Oct 2016 12:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7272) Elytron attribute-mapping
	index validation
In-Reply-To: <JIRA.12653664.1475770325000@Atlassian.JIRA>
References: <JIRA.12653664.1475770325000@Atlassian.JIRA>
	<JIRA.12653664.1475770325000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653664.1475770325000.68187.1475770381479@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6325 to WFLY-7272:
-------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-7272  (was: JBEAP-6325)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Security
                     (was: Security)


> Elytron attribute-mapping index validation
> ------------------------------------------
>
>                 Key: WFLY-7272
>                 URL: https://issues.jboss.org/browse/WFLY-7272
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>
> To be consistent with other *-index attributes in jdbc-realm. Please, introduce model validation for attribute {{index}} of {{attribute-mapping}} element, as valid values are 1..maxint . Such validation could be useful also in elytron project, as elytron can be used without subsystem.
> Elytron subsystem allows to user to set value 0. Such configured jdbc-realm throws error in runtime.
> {code}
> 17:15:44,546 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /secured-webapp/index.jsp: java.lang.RuntimeException: ELY01052: Unexpected error when processing authentication query "SELECT password,roles FROM test.wildfly_users WHERE username=?"
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.executePrincipalQuery(JdbcSecurityRealm.java:264)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$getIdentity$2(JdbcSecurityRealm.java:202)
> 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.getIdentity(JdbcSecurityRealm.java:224)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.exists(JdbcSecurityRealm.java:188)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1583)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1608)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:466)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:461)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:724)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authorize(UsernamePasswordAuthenticationMechanism.java:85)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [user1]
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$null$0(JdbcSecurityRealm.java:215)
> 	at java.util.ArrayList.forEach(ArrayList.java:1249)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$null$1(JdbcSecurityRealm.java:207)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.executePrincipalQuery(JdbcSecurityRealm.java:259)
> 	... 53 more
> Caused by: org.postgresql.util.PSQLException: The column index is out of range: 0, number of columns: 2.
> 	at org.postgresql.jdbc.PgResultSet.checkColumnIndex(PgResultSet.java:2754)
> 	at org.postgresql.jdbc.PgResultSet.checkResultSet(PgResultSet.java:2774)
> 	at org.postgresql.jdbc.PgResultSet.getString(PgResultSet.java:1881)
> 	at org.jboss.jca.adapters.jdbc.WrappedResultSet.getString(WrappedResultSet.java:1954)
> 	at org.wildfly.security.auth.realm.jdbc.mapper.AttributeMapper.map(AttributeMapper.java:40)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$null$0(JdbcSecurityRealm.java:209)
> 	... 56 more
> {code}
> Also, there is wrong exception message  "ELY01079: Ldap-backed realm failed to obtain attributes for entry [user1]" . Apparently should be "Jdbc realm". 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 14:10:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 6 Oct 2016 14:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7271) Review elytron jdbc-realm
 resource XSD definition
In-Reply-To: <JIRA.12653639.1475767977000@Atlassian.JIRA>
References: <JIRA.12653639.1475767977000@Atlassian.JIRA>
	<JIRA.12653639.1475767977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653639.1475767977000.69268.1475777400707@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7271:
-----------------------------------

    Assignee: Ilia Vassilev


> Review elytron jdbc-realm resource XSD definition
> -------------------------------------------------
>
>                 Key: WFLY-7271
>                 URL: https://issues.jboss.org/browse/WFLY-7271
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> * Wouldn't {{xsd:all}} be more proper than {{xsd:sequence}} here, as it doesn't required elements in exact order.
> * In XSD attribute-mapping attribute {{to}} is declared as optional, but in fact it is required.
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/jdbc-realm=a:add(principal-query=[{sql="a",data-source="ExampleDS",attribute-mapping=[{index=0}]}])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0155: to may not be null",
>     "rolled-back" => true
> }
> {code}
> * simple-digest-mapper, salted-simple-digest-mapper and scram-mapper missing {{algorithm}} attribute in XSD



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 14:12:01 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 6 Oct 2016 14:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7272) Elytron attribute-mapping
	index validation
In-Reply-To: <JIRA.12653664.1475770325000@Atlassian.JIRA>
References: <JIRA.12653664.1475770325000@Atlassian.JIRA>
	<JIRA.12653664.1475770325000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653664.1475770325000.69290.1475777521251@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7272:
-----------------------------------

    Assignee: Ilia Vassilev


> Elytron attribute-mapping index validation
> ------------------------------------------
>
>                 Key: WFLY-7272
>                 URL: https://issues.jboss.org/browse/WFLY-7272
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> To be consistent with other *-index attributes in jdbc-realm. Please, introduce model validation for attribute {{index}} of {{attribute-mapping}} element, as valid values are 1..maxint . Such validation could be useful also in elytron project, as elytron can be used without subsystem.
> Elytron subsystem allows to user to set value 0. Such configured jdbc-realm throws error in runtime.
> {code}
> 17:15:44,546 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /secured-webapp/index.jsp: java.lang.RuntimeException: ELY01052: Unexpected error when processing authentication query "SELECT password,roles FROM test.wildfly_users WHERE username=?"
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.executePrincipalQuery(JdbcSecurityRealm.java:264)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$getIdentity$2(JdbcSecurityRealm.java:202)
> 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.getIdentity(JdbcSecurityRealm.java:224)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.exists(JdbcSecurityRealm.java:188)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1583)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1608)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:466)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:461)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:724)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authorize(UsernamePasswordAuthenticationMechanism.java:85)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [user1]
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$null$0(JdbcSecurityRealm.java:215)
> 	at java.util.ArrayList.forEach(ArrayList.java:1249)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$null$1(JdbcSecurityRealm.java:207)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.executePrincipalQuery(JdbcSecurityRealm.java:259)
> 	... 53 more
> Caused by: org.postgresql.util.PSQLException: The column index is out of range: 0, number of columns: 2.
> 	at org.postgresql.jdbc.PgResultSet.checkColumnIndex(PgResultSet.java:2754)
> 	at org.postgresql.jdbc.PgResultSet.checkResultSet(PgResultSet.java:2774)
> 	at org.postgresql.jdbc.PgResultSet.getString(PgResultSet.java:1881)
> 	at org.jboss.jca.adapters.jdbc.WrappedResultSet.getString(WrappedResultSet.java:1954)
> 	at org.wildfly.security.auth.realm.jdbc.mapper.AttributeMapper.map(AttributeMapper.java:40)
> 	at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.lambda$null$0(JdbcSecurityRealm.java:209)
> 	... 56 more
> {code}
> Also, there is wrong exception message  "ELY01079: Ldap-backed realm failed to obtain attributes for entry [user1]" . Apparently should be "Jdbc realm". 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 17:14:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 6 Oct 2016 17:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-115) Release Remoting JMX
	3.0.0.Alpha2
In-Reply-To: <JIRA.12653498.1475734496000@Atlassian.JIRA>
References: <JIRA.12653498.1475734496000@Atlassian.JIRA>
	<JIRA.12653498.1475734496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653498.1475734496000.69641.1475788440963@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-115.
-------------------------------------
    Resolution: Done


> Release Remoting JMX 3.0.0.Alpha2
> ---------------------------------
>
>                 Key: REMJMX-115
>                 URL: https://issues.jboss.org/browse/REMJMX-115
>             Project: Remoting JMX
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha2
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct  6 17:31:00 2016
From: issues at jboss.org (Gail Badner (JIRA))
Date: Thu, 6 Oct 2016 17:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.2
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.69680.1475789460540@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gail Badner updated WFLY-6854:
------------------------------
    Summary: Upgrade Hibernate ORM to 5.1.2  (was: Upgrade Hibernate ORM to 5.1.1)


> Upgrade Hibernate ORM to 5.1.2
> ------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 02:32:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 7 Oct 2016 02:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron
 sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914295@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.70179.1475821921568@Atlassian.JIRA>

Ondrej Lukas created WFLY-7273:
----------------------------------

             Summary: Adding ldap-realm in Elytron sometimes register capability even if add operation failed
                 Key: WFLY-7273
                 URL: https://issues.jboss.org/browse/WFLY-7273
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Security
            Reporter: Ondrej Lukas
            Assignee: Brian Stansberry


In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.

I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 02:33:02 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 7 Oct 2016 02:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron
 sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.70188.1475821982613@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7273:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-7273
>                 URL: https://issues.jboss.org/browse/WFLY-7273
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 02:46:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 7 Oct 2016 02:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron
 sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.70382.1475822760297@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7273:
-------------------------------
    Description: 
In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.

I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.

Exception in server log:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("ldap-realm" => "ldap")
]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
	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)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}

  was:
In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.

I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.



> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-7273
>                 URL: https://issues.jboss.org/browse/WFLY-7273
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> 	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> 	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> 	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 03:41:00 2016
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Fri, 7 Oct 2016 03:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5239)
 XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5%
 cases with "no physical address for"
In-Reply-To: <JIRA.12583312.1441035651000@Atlassian.JIRA>
References: <JIRA.12583312.1441035651000@Atlassian.JIRA>
	<JIRA.12583312.1441035651000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583312.1441035651000.70655.1475826060204@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303802#comment-13303802 ] 

Petr Kremensky commented on WFLY-5239:
--------------------------------------

Well that's rather unfortunate situation, since this is the only test case, I'm aware of, included in standard execution (-DallTests) which requires 4 nodes to pass - only servers in Perf and Messaging lab have these four configured (+ maybe some exceptions in mwqe lab). I'll see what can be done on our side to workaround this.

> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5239
>                 URL: https://issues.jboss.org/browse/WFLY-5239
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar		&amp#27;[0m&amp#27;[0m15:14:52,808 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &amp#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &amp#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:03,277 WARN  [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &amp#27;[0mExecuted HTTP request
> &amp#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message			17:02
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 04:05:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 7 Oct 2016 04:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7266) BOM
 wildfly-javaee7-with-tools mismanages some dependencies
In-Reply-To: <JIRA.12653431.1475678675000@Atlassian.JIRA>
References: <JIRA.12653431.1475678675000@Atlassian.JIRA>
	<JIRA.12653431.1475678675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653431.1475678675000.70733.1475827500973@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303811#comment-13303811 ] 

Tomaz Cerar commented on WFLY-7266:
-----------------------------------

We do publish it, as it is needed for testing EE7 compatibility, but not really something end user apps would need to depend upon.
Well, they can, but you get all EE7 APIs at once, not just ones you need.
It could be that we only started doing boms around WF8 times.

> BOM wildfly-javaee7-with-tools mismanages some dependencies
> -----------------------------------------------------------
>
>                 Key: WFLY-7266
>                 URL: https://issues.jboss.org/browse/WFLY-7266
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: org.wildfly.bom:wildfly-javaee7-with-tools:10.1.0.Final
> org.wildfly:wildfly-spec-api:10.1.0.Final
>            Reporter: kostd kostd
>            Assignee: Tomaz Cerar
>            Priority: Optional
>         Attachments: pom.xml
>
>
> Earlier was created WFLY-6621 wildfly-spec-api:10.0.0.Final mismanages el-api, jsf-api
> Problem still exists in 10.1.0.Final. At this time I understood problem more clearly, so:
> 1. I have a dummy project with deps:
> {code:title:bom and spec}
> <dependencyManagement>
> 	<dependencies>
> 		<dependency>
> 			<groupId>org.wildfly.bom</groupId>
> 			<artifactId>wildfly-javaee7-with-tools</artifactId>
> 			<version>10.1.0.Final</version>
> 			<type>pom</type>
> 			<scope>import</scope>
> 		</dependency>
> 	</dependencies>
> </dependencyManagement>
>  
> <dependencies>
> 	<dependency>
> 		<groupId>org.wildfly</groupId>
> 		<artifactId>wildfly-spec-api</artifactId>
> 		<version>10.1.0.Final</version>
> 		<type>pom</type>
> 		<scope>provided</scope>
> 	</dependency>
> </dependencies>
> {code}
> Maven dependency tree for my project shows that it depends on el-api and jsf-api older than contained in wildfly-dist:10.1.0.Final`s modules:
> {code:title=mvn dependency:tree fragment}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ test-maven-project ---
> [INFO] ru.argustelecom.argus:test-maven-project:ejb:333
> [INFO] \- org.wildfly:wildfly-spec-api:pom:10.1.0.Final:provided
> [INFO]    +- org.glassfish:javax.json:jar:1.0.3:provided
> [INFO]    +- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.batch:jboss-batch-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    |  \- javax.inject:javax.inject:jar:1:provided
> [INFO]    +- org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.el:jboss-el-api_3.0_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.enterprise.concurrent:jboss-concurrency-api_1.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.faces:jboss-jsf-api_2.2_spec:jar:2.2.11:provided
> [INFO]    +- org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.jms:jboss-jms-api_2.0_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.resource:jboss-connector-api_1.7_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jsp:jboss-jsp-api_2.3_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final:provided
> [INFO]    +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.2_spec:jar:1.0.4.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.rpc:jboss-jaxrpc-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec:jar:1.0.3.Final:provided
> [INFO]    +- org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final:provided
> [INFO]    +- org.hibernate.javax.persistence:hibernate-jpa-2.1-api:jar:1.0.0.Final:provided
> [INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided
> [INFO]    +- com.sun.mail:javax.mail:jar:1.5.3:provided
> [INFO]    |  \- javax.activation:activation:jar:1.1.1:provided
> [INFO]    +- org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]    +- javax.validation:validation-api:jar:1.1.0.Final:provided
> [INFO]    +- org.jboss.spec.javax.management.j2ee:jboss-j2eemgmt-api_1.1_spec:jar:1.0.1.Final:provided
> [INFO]    \- org.wildfly.checkstyle:wildfly-checkstyle-config:jar:1.0.4.Final:provided
> {code}
> el-api and jsf-api must have 1.0.7.Final and 2.2.13 versions respectively
> 2. This is because wildly-javaee7-with-tools inherits from wildfly-javaee7 which imports org.jboss.spec:jboss-javaee-7.0:1.0.3.Final who depends on too old el-api and jsf-api:
> {code:title=wildfly-javaee7 pom fragment}
> ..
>         <version.org.jboss.spec.jboss.javaee.7>1.0.3.Final</version.org.jboss.spec.jboss.javaee.7>
> ...
>             <!-- BOM imports -->
>             <!-- JBoss distributes a complete set of Java EE 7 APIs including
>                 a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
>                 a collection) of artifacts. We use this here so that we always get the correct
>                 versions of artifacts. Here we use the jboss-javaee-7.0 stack (you can read
>                 this as the JBoss stack of the Java EE full Profile 7 APIs). You can actually use
>                 this stack with any version of WildFly that implements Java EE 7! -->
>             <dependency>
>                 <groupId>org.jboss.spec</groupId>
>                 <artifactId>jboss-javaee-7.0</artifactId>
>                 <version>${version.org.jboss.spec.jboss.javaee.7}</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
> {code}
> {code:title=jboss-javaee-7.0 pom fragment}
> ...
>     <version.org.jboss.spec.javax.el>1.0.4.Final</version.org.jboss.spec.javax.el>
> ...
>     <version.org.jboss.spec.javax.faces>2.2.11</version.org.jboss.spec.javax.faces>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.el</groupId>
>         <artifactId>jboss-el-api_3.0_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.el}</version>
>       </dependency>
> ...
>       <dependency>
>         <groupId>org.jboss.spec.javax.faces</groupId>
>         <artifactId>jboss-jsf-api_2.2_spec</artifactId>
>         <version>${version.org.jboss.spec.javax.faces}</version>
>       </dependency>
> {code}
> 3. Also can see some other dependencies (not only el-api and jsf-api), which version doubtful:
> org.jboss.spec.javax.servlet.jstl:jboss-jstl-api_1.2_spec:jar:1.1.2.Final (must be 1.1.3.Final)
> org.jboss.spec.javax.websocket:jboss-websocket-api_1.1_spec:jar:1.1.0.Final (must be 1.1.1.Final)
> org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec:jar:2.0.2.Final (must be 2.0.3.Final)
> com.sun.mail:javax.mail:jar:1.5.3 (must be 1.5.5)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 05:02:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 7 Oct 2016 05:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2056) Measure latency for RPCs
In-Reply-To: <JIRA.12616361.1461310753000@Atlassian.JIRA>
References: <JIRA.12616361.1461310753000@Atlassian.JIRA>
	<JIRA.12616361.1461310753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616361.1461310753000.71009.1475830920566@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303837#comment-13303837 ] 

Bela Ban commented on JGRP-2056:
--------------------------------

Latency for members A and B in the same JVM is ~60us for regular messages (JChannel) (bla) and 3-4us higher for MessageDispatcher (bla2).

Using {{SenderSendsBundler}}, the numbers drop to 42us (bla) and 47us (bla2).

RoundTrip shows RTT times (A and B are 2 processes on the same box) of 102us ({{TransferQueueBundler}}) and 83us ({{SenderSendsBundler}}), which is about twice the latency, which is OK.

> Measure latency for RPCs
> ------------------------
>
>                 Key: JGRP-2056
>                 URL: https://issues.jboss.org/browse/JGRP-2056
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 05:02:01 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 7 Oct 2016 05:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2056) Measure latency for RPCs
In-Reply-To: <JIRA.12616361.1461310753000@Atlassian.JIRA>
References: <JIRA.12616361.1461310753000@Atlassian.JIRA>
	<JIRA.12616361.1461310753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616361.1461310753000.71024.1475830921094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2056:
---------------------------
    Attachment:     (was: bla.java)


> Measure latency for RPCs
> ------------------------
>
>                 Key: JGRP-2056
>                 URL: https://issues.jboss.org/browse/JGRP-2056
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 05:03:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 7 Oct 2016 05:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2056) Measure latency for RPCs
In-Reply-To: <JIRA.12616361.1461310753000@Atlassian.JIRA>
References: <JIRA.12616361.1461310753000@Atlassian.JIRA>
	<JIRA.12616361.1461310753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616361.1461310753000.71027.1475830980271@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2056:
---------------------------
    Attachment: bla2.java
                bla.java


> Measure latency for RPCs
> ------------------------
>
>                 Key: JGRP-2056
>                 URL: https://issues.jboss.org/browse/JGRP-2056
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>         Attachments: bla.java, bla2.java
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 05:37:01 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 7 Oct 2016 05:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6932) LookupTestCase fails with
	security manager
In-Reply-To: <JIRA.12642595.1470746100000@Atlassian.JIRA>
References: <JIRA.12642595.1470746100000@Atlassian.JIRA>
	<JIRA.12642595.1470746100000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642595.1470746100000.71283.1475833021017@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303854#comment-13303854 ] 

Ingo Weiss commented on WFLY-6932:
----------------------------------

Seems to be working on the latest {{master}} branch.

> LookupTestCase fails with security manager
> ------------------------------------------
>
>                 Key: WFLY-6932
>                 URL: https://issues.jboss.org/browse/WFLY-6932
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Jan Tymel
>
> *org.jboss.as.test.integration.ee.remotelookup.LookupTestCase#testServerLocalLookup*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.remotelookup.LookupTestCase#testServerLocalLookup -Dsecurity.manager}}
> Fails with:
> {code}
> WARN  [org.apache.activemq.artemis.core.client] (pool-3-thread-1) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost" "resolve")" in code source "(vfs:/content/deploy.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkConnect(SecurityManager.java:1048)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:407)
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1268)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> 	at java.net.InetAddress.getByName(InetAddress.java:1076)
> 	at java.net.InetSocketAddress.<init>(InetSocketAddress.java:220)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:575)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1009)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1053)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1232)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:867)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:769)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:760)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
> 	at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.lookupConnectionFactory(LookupTestCase.java:81)
> 	at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.testServerLocalLookup(LookupTestCase.java:66)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 05:55:01 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 7 Oct 2016 05:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-848) "XNIO001001: No XNIO
 provider found" by some tests running with security manager
In-Reply-To: <JIRA.12579731.1438160339000@Atlassian.JIRA>
References: <JIRA.12579731.1438160339000@Atlassian.JIRA>
	<JIRA.12579731.1438160339000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579731.1438160339000.71433.1475834101220@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFCORE-848:
---------------------------------

    Assignee: Ingo Weiss  (was: Josef Cacek)


> "XNIO001001: No XNIO provider found" by some tests running with security manager
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-848
>                 URL: https://issues.jboss.org/browse/WFCORE-848
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Petr Kremensky
>            Assignee: Ingo Weiss
>
> Some tests in wildfly-core fails due to "XNIO001001: No XNIO provider found" while run with security manager enabled.
> {noformat}
> mvn test -Dtest=SuspendResumeTestCase -Dsecurity.manager -DtestLogToFile=false
> 10:27:16,814 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.test-undertow-server: org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 	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)
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> 	at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> 	at org.xnio.Xnio.getInstance(Xnio.java:181)
> 	at io.undertow.Undertow.start(Undertow.java:97)
> 	at org.wildfly.test.suspendresumeendpoint.TestUndertowService.start(TestUndertowService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	... 3 more
> 10:27:16,816 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "web-suspend.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
>     Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> 10:27:16,817 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "web-suspend.jar" was rolled back with the following failure message: 
> {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
>     Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> {noformat}
> Affected tests found so far:
> * org.wildfly.core.test.standalone.suspend.web.SuspendResumeTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainGracefulShutdownTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainSuspendResumeTestCase



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 05:56:02 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 7 Oct 2016 05:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2056) Measure latency for RPCs
In-Reply-To: <JIRA.12616361.1461310753000@Atlassian.JIRA>
References: <JIRA.12616361.1461310753000@Atlassian.JIRA>
	<JIRA.12616361.1461310753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616361.1461310753000.71446.1475834162003@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2056.
----------------------------
    Resolution: Done


> Measure latency for RPCs
> ------------------------
>
>                 Key: JGRP-2056
>                 URL: https://issues.jboss.org/browse/JGRP-2056
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>         Attachments: bla.java, bla2.java
>
>
> Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
> * message bundlers at the sender and
> * message batch handling at the receiver
> This needs to be done for both requests and responses.
> Perhaps provide a way for callbacks to be invoked to measure the latency, e.g. request sent (dest, ID), response received (ID), so that tests like IspnPerfTest could collect them and create histograms.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 05:56:02 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 7 Oct 2016 05:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1321) Prefer https over http for
 absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
In-Reply-To: <JIRA.12653762.1475834150000@Atlassian.JIRA>
References: <JIRA.12653762.1475834150000@Atlassian.JIRA>
	<JIRA.12653762.1475834150488@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653762.1475834150000.71461.1475834162644@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-1321:
----------------------------------------

             Summary: Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
                 Key: DROOLS-1321
                 URL: https://issues.jboss.org/browse/DROOLS-1321
             Project: Drools
          Issue Type: Task
          Components: build
            Reporter: Geoffrey De Smet
            Assignee: Michael Biarnes Kiefer


Motivation:
1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.

To do:
- Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
- This includes canonical meta elements
- This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
- This does not include external links, such as to wikipedia etc.

Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.

Exceptions:
- ci.optaplanner.org must be on http, because those sites don't work over https...



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 05:59:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 7 Oct 2016 05:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1321) Prefer https over http for
 absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
In-Reply-To: <JIRA.12653762.1475834150000@Atlassian.JIRA>
References: <JIRA.12653762.1475834150000@Atlassian.JIRA>
	<JIRA.12653762.1475834150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653762.1475834150000.71489.1475834340443@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304083#comment-13304083 ] 

Geoffrey De Smet commented on DROOLS-1321:
------------------------------------------

I've already done the change for optaplanner.org:
  http://github.com/droolsjbpm/optaplanner-website/commit/3b25c74d6
Michael, if you can do similar changes for the other websites and user manuals, that would be great :)

> Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1321
>                 URL: https://issues.jboss.org/browse/DROOLS-1321
>             Project: Drools
>          Issue Type: Task
>          Components: build
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>
> Motivation:
> 1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
> https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
> 2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.
> To do:
> - Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
> - This includes canonical meta elements
> - This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
> - This does not include external links, such as to wikipedia etc.
> Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.
> Exceptions:
> - ci.optaplanner.org must be on http, because those sites don't work over https...



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 06:16:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 7 Oct 2016 06:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.71603.1475835360782@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-1318:
-----------------------------------

    Assignee: Mario Fusco  (was: Nicolas Heron)


> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Mario Fusco
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 06:16:01 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 7 Oct 2016 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.71610.1475835361161@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1318.
---------------------------------
    Resolution: Cannot Reproduce Bug


> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Mario Fusco
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 06:36:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Oct 2016 06:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron
 sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.71794.1475836560681@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7273:
-----------------------------------
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-7273
>                 URL: https://issues.jboss.org/browse/WFLY-7273
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>             Fix For: 11.0.0.Alpha1
>
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> 	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> 	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> 	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 06:36:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Oct 2016 06:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7273) Adding ldap-realm in Elytron
 sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.71801.1475836560869@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7273:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-7273
>                 URL: https://issues.jboss.org/browse/WFLY-7273
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>             Fix For: 11.0.0.Alpha1
>
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> 	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> 	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> 	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 07:05:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 7 Oct 2016 07:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1321) Prefer https over http for
 absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
In-Reply-To: <JIRA.12653762.1475834150000@Atlassian.JIRA>
References: <JIRA.12653762.1475834150000@Atlassian.JIRA>
	<JIRA.12653762.1475834150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653762.1475834150000.72046.1475838300357@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304083#comment-13304083 ] 

Geoffrey De Smet edited comment on DROOLS-1321 at 10/7/16 7:04 AM:
-------------------------------------------------------------------

I've already done the change for optaplanner.org:
  http://github.com/droolsjbpm/optaplanner-website/commit/3b25c74d6
  http://github.com/droolsjbpm/optaplanner/commit/77ef50f00
Michael, if you can do similar changes for the other websites and user manuals, that would be great :)


was (Author: ge0ffrey):
I've already done the change for optaplanner.org:
  http://github.com/droolsjbpm/optaplanner-website/commit/3b25c74d6
Michael, if you can do similar changes for the other websites and user manuals, that would be great :)

> Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1321
>                 URL: https://issues.jboss.org/browse/DROOLS-1321
>             Project: Drools
>          Issue Type: Task
>          Components: build
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>
> Motivation:
> 1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
> https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
> 2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.
> To do:
> - Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
> - This includes canonical meta elements
> - This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
> - This does not include external links, such as to wikipedia etc.
> Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.
> Exceptions:
> - ci.optaplanner.org must be on http, because those sites don't work over https...



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 07:06:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 7 Oct 2016 07:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1321) Prefer https over http for
 absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
In-Reply-To: <JIRA.12653762.1475834150000@Atlassian.JIRA>
References: <JIRA.12653762.1475834150000@Atlassian.JIRA>
	<JIRA.12653762.1475834150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653762.1475834150000.72056.1475838360804@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1321:
-------------------------------------
    Description: 
Motivation:
1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.

To do:
- Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
- This includes canonical meta elements
- This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
- This does not include external links, such as to wikipedia etc.

Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.

Exceptions:
- ci.optaplanner.org must be on http, because those sites don't work over https...

Note: I've asked eng-ops to do ssl monitoring of our websites. So basically no risk of out of date certifications etc.

  was:
Motivation:
1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.

To do:
- Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
- This includes canonical meta elements
- This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
- This does not include external links, such as to wikipedia etc.

Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.

Exceptions:
- ci.optaplanner.org must be on http, because those sites don't work over https...



> Prefer https over http for absolute links on drools.org, optaplanner.org, jbpm.org and kiegroup.org
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1321
>                 URL: https://issues.jboss.org/browse/DROOLS-1321
>             Project: Drools
>          Issue Type: Task
>          Components: build
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>
> Motivation:
> 1) Chrome has "a long-term plan to mark all HTTP sites as non-secure."
> https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
> 2) SEO: Google/Bing penalize website (lower ranking) that use http or mix http and https.
> To do:
> - Change all absolute links on our websites _and in our user manuals_ that lead to redhat.com, jboss.org, drools.org, optaplanner.org, jbpm.org and kiegroup.org to https.
> - This includes canonical meta elements
> - This includes tabzilla.js/.css loading of images (those actually give us the mixed https and http errors in chrome's inspect tooling if you go to https://www.drools.org today)
> - This does not include external links, such as to wikipedia etc.
> Keep an eye out on google webmaster tools to verify this doesn't introduce broken links.
> Exceptions:
> - ci.optaplanner.org must be on http, because those sites don't work over https...
> Note: I've asked eng-ops to do ssl monitoring of our websites. So basically no risk of out of date certifications etc.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 08:19:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 7 Oct 2016 08:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7274) Undertow request failed
 HttpServerExchange due to replication timeout
In-Reply-To: <JIRA.12653797.1475842664000@Atlassian.JIRA>
References: <JIRA.12653797.1475842664000@Atlassian.JIRA>
	<JIRA.12653797.1475842664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653797.1475842664000.72614.1475842740222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved JBEAP-6343 to WFLY-7274:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7274  (was: JBEAP-6343)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Clustering
                           (was: Clustering)
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR5)


> Undertow request failed HttpServerExchange due to replication timeout
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7274
>                 URL: https://issues.jboss.org/browse/WFLY-7274
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> Occured on server during eap-7x-failover-ejb-ejbservlet-shutdown-dist-async scenario.
> Server log stacktrace:
> {code}
> 15:29:15,717 WARN  [org.jboss.weld.Servlet] (default task-104) WELD-000717: Unable to deactivate context org.jboss.weld.context.http.HttpSessionContextImpl at 351bc717 when destroying request HttpServletRequestImpl [ GET /clusterbench/ejbservlet ]
> [JBossINF] 15:29:15,718 ERROR [io.undertow.request] (default task-104) UT005071: Undertow request failed HttpServerExchange{ GET /clusterbench/ejbservlet request {Cookie=[$Version=0; JSESSIONID=YiEdTzoqqzKiWxjI1VqEQNz8BB0id8L6GKrA1Uix.dev215; $Path=/clusterbench], Content-Length=[0], User-Agent=[Jakarta Commons-HttpClient/3.1], Host=[dev220:8080]} response {Set-Cookie=[JSESSIONID=YiEdTzoqqzKiWxjI1VqEQNz8BB0id8L6GKrA1Uix.dev213; path=/clusterbench], Content-Type=[text/html;charset=UTF-8], Content-Length=[80], Date=[Wed, 21 Sep 2016 19:29:00 GMT]}}: org.infinispan.util.concurrent.TimeoutException: Replication timeout for dev213
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:801)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Followed by:
> {code}
> 15:29:15,720 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p7-t17) ISPN000136: Error executing command LockControlCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on SessionCreationMetaDataKey(bprpzS1jzQGMjU9vmr1uwUvsN0ehaPpWtpRQYUhA) in behalf of transaction GlobalTransaction:<dev213>:108660:remote. Current owner GlobalTransaction:<dev213>:90576:remote.
> [JBossINF] 	at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:261)
> ...
> {code}
> or:
> {code}
> 15:29:19,720 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-54) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on SessionCreationMetaDataKey(bprpzS1jzQGMjU9vmr1uwUvsN0ehaPpWtpRQYUhA) in behalf of transaction GlobalTransaction:<dev215>:112942:local. Current owner GlobalTransaction:<dev213>:90576:remote.
> [JBossINF] 	at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:261)
> ...
> {code}
> Server logs:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbservlet-shutdown-dist-async/29/console-dev215/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 08:49:01 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 7 Oct 2016 08:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1857) Invalid operation shouldn't
 be completed at all
In-Reply-To: <JIRA.12653804.1475844532000@Atlassian.JIRA>
References: <JIRA.12653804.1475844532000@Atlassian.JIRA>
	<JIRA.12653804.1475844532845@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653804.1475844532000.73075.1475844541886@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-1857:
--------------------------------------------

             Summary: Invalid operation shouldn't be completed at all
                 Key: WFCORE-1857
                 URL: https://issues.jboss.org/browse/WFCORE-1857
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


When an operation doesn't exist, the character ')' is added by completion although nothing should be proposed.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 08:50:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 7 Oct 2016 08:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1857) Invalid operation shouldn't
 be completed at all
In-Reply-To: <JIRA.12653804.1475844533000@Atlassian.JIRA>
References: <JIRA.12653804.1475844533000@Atlassian.JIRA>
	<JIRA.12653804.1475844533000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653804.1475844533000.73089.1475844600730@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304249#comment-13304249 ] 

Jean-Francois Denise commented on WFCORE-1857:
----------------------------------------------

The elytron subsystem is not present in JBEAP-6134 although the operation is completed.


> Invalid operation shouldn't be completed at all
> -----------------------------------------------
>
>                 Key: WFCORE-1857
>                 URL: https://issues.jboss.org/browse/WFCORE-1857
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> When an operation doesn't exist, the character ')' is added by completion although nothing should be proposed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 08:51:01 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 7 Oct 2016 08:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1857) Invalid operation shouldn't
 be completed at all
In-Reply-To: <JIRA.12653804.1475844533000@Atlassian.JIRA>
References: <JIRA.12653804.1475844533000@Atlassian.JIRA>
	<JIRA.12653804.1475844533000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653804.1475844533000.73114.1475844661231@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304249#comment-13304249 ] 

Jean-Francois Denise edited comment on WFCORE-1857 at 10/7/16 8:50 AM:
-----------------------------------------------------------------------

The elytron subsystem is not present in JBEAP-6143 although the operation is completed.



was (Author: jdenise):
The elytron subsystem is not present in JBEAP-6134 although the operation is completed.


> Invalid operation shouldn't be completed at all
> -----------------------------------------------
>
>                 Key: WFCORE-1857
>                 URL: https://issues.jboss.org/browse/WFCORE-1857
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> When an operation doesn't exist, the character ')' is added by completion although nothing should be proposed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 09:09:01 2016
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 7 Oct 2016 09:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7111) Distributable web
 applications cause Infinispan exceptions when Elytron is used
In-Reply-To: <JIRA.12650251.1473922079000@Atlassian.JIRA>
References: <JIRA.12650251.1473922079000@Atlassian.JIRA>
	<JIRA.12650251.1473922079000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650251.1473922079000.73388.1475845741604@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor reassigned WFLY-7111:
--------------------------------

    Assignee: Pedro Igor  (was: Darran Lofthouse)


> Distributable web applications cause Infinispan exceptions when Elytron is used
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-7111
>                 URL: https://issues.jboss.org/browse/WFLY-7111
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Pedro Igor
>            Priority: Blocker
>
> When a distributable secured web application mapped to Elytron domain is deployed to EAP and accessed. It throws intermittently {{org.infinispan.util.concurrent.TimeoutException}} 
> *Expected behavior:*
> Distributable applications should be accessible without exceptions when Elytron is used.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 09:33:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 7 Oct 2016 09:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-654) Ensure that negative values are
 converted to zero when setting sessionCacheSize and sessionTimeout on
 SSLSessionContext.
In-Reply-To: <JIRA.12653816.1475847162000@Atlassian.JIRA>
References: <JIRA.12653816.1475847162000@Atlassian.JIRA>
	<JIRA.12653816.1475847162525@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653816.1475847162000.73653.1475847180242@Atlassian.JIRA>

Ilia Vassilev created ELY-654:
---------------------------------

             Summary: Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout on SSLSessionContext.
                 Key: ELY-654
                 URL: https://issues.jboss.org/browse/ELY-654
             Project: WildFly Elytron
          Issue Type: Bug
          Components: SSL
    Affects Versions: 1.1.0.Beta10
            Reporter: Ilia Vassilev
            Assignee: Darran Lofthouse


Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout on SSLSessionContext.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 09:33:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 7 Oct 2016 09:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-654) Ensure that negative values are
 converted to zero when setting sessionCacheSize and sessionTimeout on
 SSLSessionContext.
In-Reply-To: <JIRA.12653816.1475847163000@Atlassian.JIRA>
References: <JIRA.12653816.1475847163000@Atlassian.JIRA>
	<JIRA.12653816.1475847163000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653816.1475847163000.73658.1475847180463@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-654:
---------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout on SSLSessionContext.
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-654
>                 URL: https://issues.jboss.org/browse/ELY-654
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SSL
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>
> Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout on SSLSessionContext.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 09:35:01 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 7 Oct 2016 09:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-654) Ensure that negative values are
 converted to zero when setting sessionCacheSize and sessionTimeout in
 SSLSessionContext.
In-Reply-To: <JIRA.12653816.1475847163000@Atlassian.JIRA>
References: <JIRA.12653816.1475847163000@Atlassian.JIRA>
	<JIRA.12653816.1475847163000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653816.1475847163000.73677.1475847301036@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-654:
------------------------------
    Summary: Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout in SSLSessionContext.  (was: Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout on SSLSessionContext.)


> Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout in SSLSessionContext.
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-654
>                 URL: https://issues.jboss.org/browse/ELY-654
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SSL
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>
> Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout on SSLSessionContext.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 09:37:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 7 Oct 2016 09:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-655) Ensure that negative values are
 converted to zero when setting sessionCacheSize and sessionTimeout in
 SSLSessionContext.
In-Reply-To: <JIRA.12653818.1475847367000@Atlassian.JIRA>
References: <JIRA.12653818.1475847367000@Atlassian.JIRA>
	<JIRA.12653818.1475847367751@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653818.1475847367000.73694.1475847420490@Atlassian.JIRA>

Ilia Vassilev created ELY-655:
---------------------------------

             Summary: Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout in SSLSessionContext.
                 Key: ELY-655
                 URL: https://issues.jboss.org/browse/ELY-655
             Project: WildFly Elytron
          Issue Type: Bug
          Components: SSL
    Affects Versions: 1.1.0.Beta10
            Reporter: Ilia Vassilev
            Assignee: Ilia Vassilev


Ensure that negative values are converted to zero when setting sessionCacheSize and sessionTimeout on SSLSessionContext.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 10:07:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 7 Oct 2016 10:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1858) Upgrade to Elytron Web
	1.0.0.Beta5
In-Reply-To: <JIRA.12653825.1475849219000@Atlassian.JIRA>
References: <JIRA.12653825.1475849219000@Atlassian.JIRA>
	<JIRA.12653825.1475849219572@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653825.1475849219000.74048.1475849221303@Atlassian.JIRA>

Darran Lofthouse created WFCORE-1858:
----------------------------------------

             Summary: Upgrade to Elytron Web 1.0.0.Beta5
                 Key: WFCORE-1858
                 URL: https://issues.jboss.org/browse/WFCORE-1858
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha10






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 10:32:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 7 Oct 2016 10:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-635) No log messages comming from
 Elytron - role mapping
In-Reply-To: <JIRA.12651439.1474536062000@Atlassian.JIRA>
References: <JIRA.12651439.1474536062000@Atlassian.JIRA>
	<JIRA.12651439.1474536062000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651439.1474536062000.74435.1475850720233@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-635:
------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> No log messages comming from Elytron - role mapping
> ---------------------------------------------------
>
>                 Key: ELY-635
>                 URL: https://issues.jboss.org/browse/ELY-635
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta9
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> Elytron is missing any log messages related to role mapping. These log messages should be added. See JBEAP-6041 for more details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 10:52:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 7 Oct 2016 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-848) "XNIO001001: No XNIO
 provider found" by some tests running with security manager
In-Reply-To: <JIRA.12579731.1438160339000@Atlassian.JIRA>
References: <JIRA.12579731.1438160339000@Atlassian.JIRA>
	<JIRA.12579731.1438160339000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579731.1438160339000.74613.1475851920543@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304370#comment-13304370 ] 

Ingo Weiss commented on WFCORE-848:
-----------------------------------

Hi [~jcacek], I talked about this with Brian and it seems there might be a need to get {{subsystem=security-manager}} into wildfly-core. WDYT?

> "XNIO001001: No XNIO provider found" by some tests running with security manager
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-848
>                 URL: https://issues.jboss.org/browse/WFCORE-848
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Petr Kremensky
>            Assignee: Ingo Weiss
>
> Some tests in wildfly-core fails due to "XNIO001001: No XNIO provider found" while run with security manager enabled.
> {noformat}
> mvn test -Dtest=SuspendResumeTestCase -Dsecurity.manager -DtestLogToFile=false
> 10:27:16,814 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.test-undertow-server: org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 	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)
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> 	at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> 	at org.xnio.Xnio.getInstance(Xnio.java:181)
> 	at io.undertow.Undertow.start(Undertow.java:97)
> 	at org.wildfly.test.suspendresumeendpoint.TestUndertowService.start(TestUndertowService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	... 3 more
> 10:27:16,816 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "web-suspend.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
>     Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> 10:27:16,817 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "web-suspend.jar" was rolled back with the following failure message: 
> {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
>     Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> {noformat}
> Affected tests found so far:
> * org.wildfly.core.test.standalone.suspend.web.SuspendResumeTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainGracefulShutdownTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainSuspendResumeTestCase



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 11:45:01 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 7 Oct 2016 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2108) TCP_NIO2: make default
In-Reply-To: <JIRA.12653840.1475855078000@Atlassian.JIRA>
References: <JIRA.12653840.1475855078000@Atlassian.JIRA>
	<JIRA.12653840.1475855078041@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653840.1475855078000.74875.1475855101207@Atlassian.JIRA>

Bela Ban created JGRP-2108:
------------------------------

             Summary: TCP_NIO2: make default
                 Key: JGRP-2108
                 URL: https://issues.jboss.org/browse/JGRP-2108
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.1


This requires the following things:
* performance of {{TCP_NIO2}} must be better than {{TCP}}
* (possibly) use multiple selectors: each selector handles only a max number of connections; create more selectors when the number of connections per selector exceeds a certain value
* (possibly) get rid of the reader thread and let the above selector do the read (the write is already done by the selector thread)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 12:14:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 7 Oct 2016 12:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5239)
 XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5%
 cases with "no physical address for"
In-Reply-To: <JIRA.12583312.1441035651000@Atlassian.JIRA>
References: <JIRA.12583312.1441035651000@Atlassian.JIRA>
	<JIRA.12583312.1441035651000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583312.1441035651000.75003.1475856840466@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304413#comment-13304413 ] 

Radoslav Husar commented on WFLY-5239:
--------------------------------------

You can easily set node0/1 to one address and node2/3 to the other one..

> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5239
>                 URL: https://issues.jboss.org/browse/WFLY-5239
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar		&amp#27;[0m&amp#27;[0m15:14:52,808 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &amp#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &amp#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:03,277 WARN  [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &amp#27;[0mExecuted HTTP request
> &amp#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message			17:02
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 12:16:00 2016
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 7 Oct 2016 12:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1859) Investigate JDK9 modular
 params propagation to forked processes
In-Reply-To: <JIRA.12653846.1475856901000@Atlassian.JIRA>
References: <JIRA.12653846.1475856901000@Atlassian.JIRA>
	<JIRA.12653846.1475856901520@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653846.1475856901000.75021.1475856960216@Atlassian.JIRA>

Richard Opalka created WFCORE-1859:
--------------------------------------

             Summary: Investigate JDK9 modular params propagation to forked processes
                 Key: WFCORE-1859
                 URL: https://issues.jboss.org/browse/WFCORE-1859
             Project: WildFly Core
          Issue Type: Sub-task
          Components: Server, Test Suite
            Reporter: Richard Opalka






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 12:28:00 2016
From: issues at jboss.org (Kerem Kacel (JIRA))
Date: Fri, 7 Oct 2016 12:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2109) S3_PING: add support for
	instance metadata
In-Reply-To: <JIRA.12653850.1475857628000@Atlassian.JIRA>
References: <JIRA.12653850.1475857628000@Atlassian.JIRA>
	<JIRA.12653850.1475857628421@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653850.1475857628000.75081.1475857680146@Atlassian.JIRA>

Kerem Kacel created JGRP-2109:
---------------------------------

             Summary: S3_PING: add support for instance metadata
                 Key: JGRP-2109
                 URL: https://issues.jboss.org/browse/JGRP-2109
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Kerem Kacel
            Assignee: Bela Ban


The AWS libraries used by S3_PING do not support authenticating into the AWS API via the EC2 instance profile (implicit credentials stored on the AWS EC2 instance).
The AWS SDK for Java supports instance profile. This eliminates the need for storing AWS access keys in config files.

Are there any plans to add official support for this in JGroups?

Resources:
http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html
http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html

Example third-party protocols:
https://github.com/tagbangers/jgroups-s3-client-ping
https://github.com/mcacker/jgroups-native-s3-ping




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 12:51:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 7 Oct 2016 12:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-258) Redesign mod_cluster subsystem
In-Reply-To: <JIRA.12458353.1328480847000@Atlassian.JIRA>
References: <JIRA.12458353.1328480847000@Atlassian.JIRA>
	<JIRA.12458353.1328480847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458353.1328480847000.75176.1475859060329@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-258:
--------------------------------
    Summary: Redesign mod_cluster subsystem  (was: mod_cluster schema 2.0)


> Redesign mod_cluster subsystem
> ------------------------------
>
>                 Key: WFLY-258
>                 URL: https://issues.jboss.org/browse/WFLY-258
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: mod_cluster
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Changes to the schema
> * simplified names and sync in line with scheme recommendations
> * remove redundant <mod-cluster-config .. /> for good, everything should be element of the subsystem
> * fix load factor enum: no pool metric supported
> * make load-balancers configurable via socket-outbuound-group mechanism
> * add missing load-balancer properties to <proxies/>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 12:52:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 7 Oct 2016 12:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-258) Redesign mod_cluster subsystem
In-Reply-To: <JIRA.12458353.1328480847000@Atlassian.JIRA>
References: <JIRA.12458353.1328480847000@Atlassian.JIRA>
	<JIRA.12458353.1328480847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458353.1328480847000.75186.1475859120769@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-258:
--------------------------------
    Affects Version/s: JBoss AS7 7.1.1.Final


> Redesign mod_cluster subsystem
> ------------------------------
>
>                 Key: WFLY-258
>                 URL: https://issues.jboss.org/browse/WFLY-258
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: mod_cluster
>    Affects Versions: JBoss AS7 7.1.1.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Changes to the schema
> * simplified names and sync in line with scheme recommendations
> * remove redundant <mod-cluster-config .. /> for good, everything should be element of the subsystem
> * fix load factor enum: no pool metric supported
> * make load-balancers configurable via socket-outbuound-group mechanism
> * add missing load-balancer properties to <proxies/>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 13:37:00 2016
From: issues at jboss.org (Krisztian Kocsis (JIRA))
Date: Fri, 7 Oct 2016 13:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764234@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.75314.1475861820177@Atlassian.JIRA>

Krisztian Kocsis created WFLY-7275:
--------------------------------------

             Summary: Wildfly eats the CPU up to 100% and does not respond
                 Key: WFLY-7275
                 URL: https://issues.jboss.org/browse/WFLY-7275
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 10.1.0.Final
         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
            Reporter: Krisztian Kocsis
            Assignee: Jason Greene
         Attachments: wildfly-hang.txt

Hi!
 
I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
 
I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 14:01:07 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 7 Oct 2016 14:01:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.75343.1475863267585@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304445#comment-13304445 ] 

David Lloyd commented on WFLY-7275:
-----------------------------------

What thread? You can find out by using "ps" or "top" to display the PID of the thread, and then convert that value to hexadecimal and search for that value in the output of jstack.

> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Jason Greene
>         Attachments: wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 14:04:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 7 Oct 2016 14:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.75350.1475863440193@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304446#comment-13304446 ] 

James Perkins commented on WFLY-7275:
-------------------------------------

Are you using a scheduled job with the {{ManagedScheduledExecutorService}}? I didn't look in detail on the thread-dump, but noticed some parked EE concurrency threads. They don't look unusual, just trying to get an idea of what your application might be doing.

> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Jason Greene
>         Attachments: wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 14:11:00 2016
From: issues at jboss.org (Krisztian Kocsis (JIRA))
Date: Fri, 7 Oct 2016 14:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.75366.1475863860414@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304448#comment-13304448 ] 

Krisztian Kocsis commented on WFLY-7275:
----------------------------------------

@David: I try to reproduce the issue, it takes some time. The main thread was show and 10108 in htop as using 100% but I think there was an other thread too (I don't remember correctly).

@James: Yes, I run a periodic (every 2 minutes) EJB task that imports data from one datasource to an other datasource.


> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Jason Greene
>         Attachments: wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 14:26:00 2016
From: issues at jboss.org (Krisztian Kocsis (JIRA))
Date: Fri, 7 Oct 2016 14:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.75391.1475864760390@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Krisztian Kocsis updated WFLY-7275:
-----------------------------------
    Attachment: Screen Shot 2016-10-07 at 20.18.31.png
                Screen Shot 2016-10-07 at 20.18.27.png
                wildfly-after-hang+1min.txt
                wildfly-after-hang.txt


> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Jason Greene
>         Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 14:31:00 2016
From: issues at jboss.org (Krisztian Kocsis (JIRA))
Date: Fri, 7 Oct 2016 14:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.75419.1475865060323@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304453#comment-13304453 ] 

Krisztian Kocsis commented on WFLY-7275:
----------------------------------------

So, I run a test with *h2load -n 5000 -c 1000 https://...*. After that even -c 10 does not work (10 concurrent conn.). I'v attached the screenshots of htop after the load test + two stack traces directly after the hang and after 1min (unable to recover without restart). SSL config: TLS 1.2 only, (ciphers only: AES128GCM, ECDHE+RSA). Note that actually the scheduled EJB task is properly executed in every 2 minutes (checked the log files), only the web interface is dead, but it is totally.

> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Jason Greene
>         Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 14:48:00 2016
From: issues at jboss.org (Krisztian Kocsis (JIRA))
Date: Fri, 7 Oct 2016 14:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.75459.1475866080216@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304459#comment-13304459 ] 

Krisztian Kocsis commented on WFLY-7275:
----------------------------------------

Note that I 2 months ago I was able to produce h2load -n 1000000 -c 20000 without any errors to a Vert.X (Netty) server on the same machine.

> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Jason Greene
>         Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 16:14:00 2016
From: issues at jboss.org (Krisztian Kocsis (JIRA))
Date: Fri, 7 Oct 2016 16:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.75735.1475871240820@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Krisztian Kocsis updated WFLY-7275:
-----------------------------------
    Attachment: wildfly-hang-real-stacktrace.txt


> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Jason Greene
>         Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 16:18:00 2016
From: issues at jboss.org (Krisztian Kocsis (JIRA))
Date: Fri, 7 Oct 2016 16:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.75743.1475871480272@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304484#comment-13304484 ] 

Krisztian Kocsis commented on WFLY-7275:
----------------------------------------

Ok, now I uploaded the real stacktrace *wildfly-hang-real-stacktrace.txt*. Unfortunately, the hung threads are in compiled code except 2-3 which are in:
* org.xnio.ChannelListener.invokeChannelListener(java.nio.channels.Channel, org.xnio.ChannelListener)
* org.xnio.nio.QueuedTcpServer$1.run()


> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Jason Greene
>         Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 16:24:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 7 Oct 2016 16:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7276) EE Concurrency tasks continue
 running after a deployment has been removed
In-Reply-To: <JIRA.12653866.1475871804000@Atlassian.JIRA>
References: <JIRA.12653866.1475871804000@Atlassian.JIRA>
	<JIRA.12653866.1475871804750@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653866.1475871804000.75752.1475871840142@Atlassian.JIRA>

James Perkins created WFLY-7276:
-----------------------------------

             Summary: EE Concurrency tasks continue running after a deployment has been removed
                 Key: WFLY-7276
                 URL: https://issues.jboss.org/browse/WFLY-7276
             Project: WildFly
          Issue Type: Bug
          Components: EE
            Reporter: James Perkins
            Assignee: James Perkins


Tasks submitted via a managed executor service continue running after an undeploy. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 18:35:00 2016
From: issues at jboss.org (Darryl Miles (JIRA))
Date: Fri, 7 Oct 2016 18:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.75937.1475879700116@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304528#comment-13304528 ] 

Darryl Miles commented on WFLY-6663:
------------------------------------

Really sorry I don't know how to make a simply enough project to demonstrate the problem.

For example out of Arquillian and Unit Tests that exist, how do I make a simple/fake JPA project that takes ~8 seconds to bootup ?
As in how do I simulate a particular project type with @PostConstruct annotation that takes some order of time to process / bootup (like needing to ask SQL for data).
Thus forcing a timing/race issue to be exposed ?


> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 18:36:00 2016
From: issues at jboss.org (Darryl Miles (JIRA))
Date: Fri, 7 Oct 2016 18:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.75940.1475879760113@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304529#comment-13304529 ] 

Darryl Miles commented on WFLY-6663:
------------------------------------

Here is another common stacktrace (I think the same kind of problem)

LOTS of STACKTRACE removed above....
...
Caused by: javax.naming.NameNotFoundException: env/com.domain.ejb.impl.MyJEjbNameImpl/httpClient [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
	... 41 more
Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
	... 46 more
Caused by: java.lang.NullPointerException
	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:56)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$DefaultViewInstanceFactory.createViewInstance(ViewService.java:305)
	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
	... 47 more

> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 18:45:00 2016
From: issues at jboss.org (Darryl Miles (JIRA))
Date: Fri, 7 Oct 2016 18:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.75946.1475880300091@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304530#comment-13304530 ] 

Darryl Miles commented on WFLY-6663:
------------------------------------

My gut thoughts are that the 3 class level annotations shown in a previous comment are a major cause of the triggering this issue.
Maybe the transaction management is guarding embryonic component interactions ?  and because it is BEAN managed those guards don't exist ?

> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 18:46:00 2016
From: issues at jboss.org (Darryl Miles (JIRA))
Date: Fri, 7 Oct 2016 18:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.75949.1475880360090@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304530#comment-13304530 ] 

Darryl Miles edited comment on WFLY-6663 at 10/7/16 6:45 PM:
-------------------------------------------------------------

My gut thoughts are that the 3 class level annotations shown in a previous comment are a major cause of the triggering this issue.
Maybe the default TransactionManagement.CONTAINER is guarding embryonic component interactions ?  and because it is BEAN managed those guards don't exist so expose race issue ?


was (Author: dlmiles):
My gut thoughts are that the 3 class level annotations shown in a previous comment are a major cause of the triggering this issue.
Maybe the transaction management is guarding embryonic component interactions ?  and because it is BEAN managed those guards don't exist ?

> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct  7 18:48:00 2016
From: issues at jboss.org (Darryl Miles (JIRA))
Date: Fri, 7 Oct 2016 18:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.75952.1475880480089@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304530#comment-13304530 ] 

Darryl Miles edited comment on WFLY-6663 at 10/7/16 6:47 PM:
-------------------------------------------------------------

My gut thoughts are that the 3 class level annotations shown in a previous comment are a major cause of the triggering this issue.
Maybe the default TransactionManagement.CONTAINER is guarding embryonic component interactions ?  and because it is BEAN managed those guards don't exist so expose race issue ?



was (Author: dlmiles):
My gut thoughts are that the 3 class level annotations shown in a previous comment are a major cause of the triggering this issue.
Maybe the default TransactionManagement.CONTAINER is guarding embryonic component interactions ?  and because it is BEAN managed those guards don't exist so expose race issue ?

> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  8 10:09:00 2016
From: issues at jboss.org (=?UTF-8?Q?Miroslav_Za=C5=A5ko_=28JIRA=29?=)
Date: Sat, 8 Oct 2016 10:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-68) execute-commands does not
 work for module command
In-Reply-To: <JIRA.12539159.1398464209000@Atlassian.JIRA>
References: <JIRA.12539159.1398464209000@Atlassian.JIRA>
	<JIRA.12539159.1398464209000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539159.1398464209000.76064.1475935740491@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304548#comment-13304548 ] 

Miroslav Za?ko commented on JBASMP-68:
--------------------------------------

still not fixed in most recent
{code:xml}
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>1.1.0.Alpha11</version>`
{code}

> execute-commands does not work for module command
> -------------------------------------------------
>
>                 Key: JBASMP-68
>                 URL: https://issues.jboss.org/browse/JBASMP-68
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>    Affects Versions: 7.6.Final
>            Reporter: Alfio Gloria
>
> I'm trying to remove a jboss module by means of maven.
> {code:xml}
> <configuration>
>     <jbossHome>${project.build.directory}/server/jboss72</jbossHome>
>     <execute-commands>
>         <commands>
>             <command>module remove --slot=main --name=system.layers.base.org.jboss.weld.core</command>
>         </commands>
>     </execute-commands>
> </configuration>
> {code}
> execute-commands fails with the following stack trace:
> {code}
> Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:483)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	... 19 more
> Caused by: java.lang.IllegalArgumentException: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> 	at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:180)
> 	at org.jboss.as.plugin.cli.Commands.execute(Commands.java:134)
> 	at org.jboss.as.plugin.cli.ExecuteCommands.execute(ExecuteCommands.java:71)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> 	... 20 more
> Caused by: org.jboss.as.cli.CommandLineException: JBOSS_HOME environment variable is not set.
> 	at org.jboss.as.cli.handlers.module.ASModuleHandler.getModulesDir(ASModuleHandler.java:362)
> 	at org.jboss.as.cli.handlers.module.ASModuleHandler.removeModule(ASModuleHandler.java:326)
> 	at org.jboss.as.cli.handlers.module.ASModuleHandler.doHandle(ASModuleHandler.java:214)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581)
> 	at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:176)
> 	... 23 more
> {code}
> (tested with the last snapshot too) 
> The problem comes from jboss-as-cli that needs the JBOSS_HOME to be set in order to add or remove modules. This is not a requirement for other commands such as deploy.
> There are some points of confusion:
> # JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others;
> # usually there are more than one installation or jboss-as-maven-plugin can download the server;
> # jbossHome config parameter is not take into account;
> # what if I want to make operations on more the one server at the same time?
> At the moment I solved by patching jboss-as-cli using a system property instead of environment variable. I don't know how to solve without touching jboss-as-cli.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sat Oct  8 11:34:00 2016
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Sat, 8 Oct 2016 11:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.76086.1475940840197@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304553#comment-13304553 ] 

jaikiran pai commented on WFLY-6663:
------------------------------------

I see what's going on (and am able to reproduce it within the WildFly testsuite). It isn't related to anything transaction management. The root cause of the issue is that the startup singleton bean injects a *remote view of a stateful session bean*. Internally, when the injection process on that singleton startup bean is in progress, it triggers a session creation on the stateful session bean, even before the (MSC service backing the) stateful component has started. 

The relevant piece of code in WildFly is (I think) this https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EjbInjectionSource.java#L93 where it skips adding a dependency and instead sets up the RemoteViewManagedReferenceFactory which later on just goes ahead and tries to create a component session for the stateful bean https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/RemoteViewManagedReferenceFactory.java#L95

I have been away from WildFly code for a while now and can't think of a way to fix this properly, given that ejb: lookups in theory don't need to depend on the component, if the component is really "remote" and doesn't reside on the same server, which is not the case in the example above. Someone else in the WildFly dev team, I believe, will be able to fix this properly.

The only workaround that I can think of is, if you MainEjb which I believe is a stateful bean has a local business interface too, then use that interface for injection instead of the remove business interface here:

{code}

        @EJB
        private MainEjb mainEjb;  // use a local business interface instead of a remote one

{code}





> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  8 11:35:00 2016
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Sat, 8 Oct 2016 11:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.76090.1475940900167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304553#comment-13304553 ] 

jaikiran pai edited comment on WFLY-6663 at 10/8/16 11:34 AM:
--------------------------------------------------------------

I see what's going on (and am able to reproduce it within the WildFly testsuite). It isn't related to anything transaction management. The root cause of the issue is that the startup singleton bean injects a *remote view of a stateful session bean*. Internally, when the injection process on that singleton startup bean is in progress, it triggers a session creation on the stateful session bean, even before the (MSC service backing the) stateful component has started. 

The relevant piece of code in WildFly is (I think) this https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EjbInjectionSource.java#L93 where it skips adding a dependency and instead sets up the RemoteViewManagedReferenceFactory which later on just goes ahead and tries to create a component session for the stateful bean https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/RemoteViewManagedReferenceFactory.java#L95

I have been away from WildFly code for a while now and can't think of a way to fix this properly, given that ejb: lookups in theory don't need to depend on the component, if the component is really "remote" and doesn't reside on the same server, which is not the case in the example above. Someone else in the WildFly dev team, I believe, will be able to fix this properly.

The only workaround that I can think of is, if your MainEjb which I believe is a stateful bean has a local business interface too, then use that interface for injection instead of the remove business interface here:

{code}

        @EJB
        private MainEjb mainEjb;  // use a local business interface instead of a remote one

{code}






was (Author: jaikiran):
I see what's going on (and am able to reproduce it within the WildFly testsuite). It isn't related to anything transaction management. The root cause of the issue is that the startup singleton bean injects a *remote view of a stateful session bean*. Internally, when the injection process on that singleton startup bean is in progress, it triggers a session creation on the stateful session bean, even before the (MSC service backing the) stateful component has started. 

The relevant piece of code in WildFly is (I think) this https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EjbInjectionSource.java#L93 where it skips adding a dependency and instead sets up the RemoteViewManagedReferenceFactory which later on just goes ahead and tries to create a component session for the stateful bean https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/RemoteViewManagedReferenceFactory.java#L95

I have been away from WildFly code for a while now and can't think of a way to fix this properly, given that ejb: lookups in theory don't need to depend on the component, if the component is really "remote" and doesn't reside on the same server, which is not the case in the example above. Someone else in the WildFly dev team, I believe, will be able to fix this properly.

The only workaround that I can think of is, if you MainEjb which I believe is a stateful bean has a local business interface too, then use that interface for injection instead of the remove business interface here:

{code}

        @EJB
        private MainEjb mainEjb;  // use a local business interface instead of a remote one

{code}





> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  8 18:36:00 2016
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Sat, 8 Oct 2016 18:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-853) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12579931.1438279913000@Atlassian.JIRA>
References: <JIRA.12579931.1438279913000@Atlassian.JIRA>
	<JIRA.12579931.1438279913000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579931.1438279913000.21.1475966160287@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski closed WFCORE-853.
---------------------------------
    Resolution: Rejected


Problem not existent in the new client.

> Simplify the remote-outbound connections
> ----------------------------------------
>
>                 Key: WFCORE-853
>                 URL: https://issues.jboss.org/browse/WFCORE-853
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Remoting
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>
> Create remote-outbound-group element in remoting configuration which gather connections that share the same configuration.
> http://lists.jboss.org/pipermail/wildfly-dev/2015-July/004235.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  8 18:38:00 2016
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Sat, 8 Oct 2016 18:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6585) IIOP bean lookup fails after
 transaction timeout happens
In-Reply-To: <JIRA.12618266.1462439471000@Atlassian.JIRA>
References: <JIRA.12618266.1462439471000@Atlassian.JIRA>
	<JIRA.12618266.1462439471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618266.1462439471000.25.1475966280331@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski closed WFLY-6585.
--------------------------------
    Resolution: Done


> IIOP bean lookup fails after transaction timeout happens
> --------------------------------------------------------
>
>                 Key: WFLY-6585
>                 URL: https://issues.jboss.org/browse/WFLY-6585
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>
> IIOP lookup call for a bean could fails when transaction timeout happens on the lookuped bean. The exception is {{javax.naming.NameNotFoundException: null}} [1]
> My feeling is that the issue has something to do with transaction timeout when JTS/iiop lookup is used. My experience is that the same type of testcase passes when JTA/ejb remoting is used.
> What I can say I think that lookup fails on server at time when 'get_txcontext' is used. I mean that is what could be seen from server.log file [2] (attached).
> [1]
> {code}
> javax.naming.NameNotFoundException: null
>  at org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read(NotFoundHelper.java:72)
>  at org.omg.CosNaming._NamingContextStub.resolve(_NamingContextStub.java:251)
>  at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:486)
>  at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:539)
>  at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:517)
>  at javax.naming.InitialContext.lookup(InitialContext.java:417)
>  at org.jboss.as.test.integration.transactions.TransactionTestLookupUtil.lookupIIOP(TransactionTestLookupUtil.java:77)
>  at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.lookupStateful(IIOPTimeoutTestCase.java:176)
>  at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful(IIOPTimeoutTestCase.java:157)
> {code}
> [2]
> 2016-04-27 19:38:09,297 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionClientRequestInterceptorImpl::send_request ( get_txcontext ) nodeId=1 requestId=64
> 2016-04-27 19:38:09,297 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( get_txcontext ) nodeId=1 requestId=70
> 2016-04-27 19:38:09,297 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) Intercepting receive_request_service_contexts, operation: get_txcontext
> 2016-04-27 19:38:09,300 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) send_exception: get_txcontext
> 2016-04-27 19:38:09,300 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::send_exception ( get_txcontext ) nodeId=1 requestId=70
> 2016-04-27 19:38:09,300 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::suspendContext ( get_txcontext ) nodeId=1 requestId=70
> 2016-04-27 19:38:09,303 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionClientRequestInterceptorImpl::receive_exception ( get_txcontext ) nodeId=1 requestId=64
> 2016-04-27 19:38:09,305 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) send_exception: resolve
> 2016-04-27 19:38:09,305 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::send_exception ( resolve ) nodeId=1 requestId=69
> 2016-04-27 19:38:09,305 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::suspendContext ( resolve ) nodeId=1 requestId=69 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct  8 18:39:00 2016
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Sat, 8 Oct 2016 18:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6935) CMTTxInterceptor transaction
	comparison
In-Reply-To: <JIRA.12642666.1470772077000@Atlassian.JIRA>
References: <JIRA.12642666.1470772077000@Atlassian.JIRA>
	<JIRA.12642666.1470772077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642666.1470772077000.27.1475966340157@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski closed WFLY-6935.
--------------------------------
    Resolution: Done


> CMTTxInterceptor transaction comparison
> ---------------------------------------
>
>                 Key: WFLY-6935
>                 URL: https://issues.jboss.org/browse/WFLY-6935
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.CR1
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct  9 05:19:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 9 Oct 2016 05:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.63.1476004740150@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-6663:
------------------------------------

    Assignee: Stuart Douglas


> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>            Assignee: Stuart Douglas
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct  9 05:36:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 9 Oct 2016 05:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7277) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12653910.1476005717000@Atlassian.JIRA>
References: <JIRA.12653910.1476005717000@Atlassian.JIRA>
	<JIRA.12653910.1476005717545@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653910.1476005717000.74.1476005760219@Atlassian.JIRA>

Stuart Douglas created WFLY-7277:
------------------------------------

             Summary: NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
                 Key: WFLY-7277
                 URL: https://issues.jboss.org/browse/WFLY-7277
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 10.0.0.Final, 10.1.0.Final
         Environment: Win7 64bit + JDK8 64bit
            Reporter: Darryl Miles
            Assignee: Stuart Douglas


1 in 8 deployments fail to deploy, usually a redeploy fixes it.

If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.

09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	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)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
	... 6 more
Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
	... 11 more
Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
	... 26 more
Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
	... 43 more
Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
	... 48 more
Caused by: java.lang.NullPointerException
	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct  9 11:44:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 9 Oct 2016 11:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2110) Transport: revisit buffers
	and threading
In-Reply-To: <JIRA.12653915.1476027787000@Atlassian.JIRA>
References: <JIRA.12653915.1476027787000@Atlassian.JIRA>
	<JIRA.12653915.1476027787083@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653915.1476027787000.113.1476027840361@Atlassian.JIRA>

Bela Ban created JGRP-2110:
------------------------------

             Summary: Transport: revisit buffers and threading
                 Key: JGRP-2110
                 URL: https://issues.jboss.org/browse/JGRP-2110
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0


(Concerns only the receiver side)

h4. Parsing
Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only receive fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.

This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).

h4. Buffers
* UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
* TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
* TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.

h4. Approaches
# The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
# The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
# UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
# To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.

h4. Goals
Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct  9 11:45:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 9 Oct 2016 11:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2110) Transport: revisit buffers
	and threading
In-Reply-To: <JIRA.12653915.1476027787000@Atlassian.JIRA>
References: <JIRA.12653915.1476027787000@Atlassian.JIRA>
	<JIRA.12653915.1476027787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653915.1476027787000.116.1476027900256@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304624#comment-13304624 ] 

Bela Ban commented on JGRP-2110:
--------------------------------

http://ithare.com/network-programming-socket-peculiarities-threads-and-testing

> Transport: revisit buffers and threading
> ----------------------------------------
>
>                 Key: JGRP-2110
>                 URL: https://issues.jboss.org/browse/JGRP-2110
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> (Concerns only the receiver side)
> h4. Parsing
> Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only receive fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
> This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
> h4. Buffers
> * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
> * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
> * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
> h4. Approaches
> # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
> # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
> # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
> # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
> h4. Goals
> Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct  9 12:55:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sun, 9 Oct 2016 12:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Elytron LdapKeyStore -
 classloading of LdapCtxFactory
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088004@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.135.1476032100152@Atlassian.JIRA>

Jan Kalina created WFLY-7278:
--------------------------------

             Summary: Elytron LdapKeyStore - classloading of LdapCtxFactory
                 Key: WFLY-7278
                 URL: https://issues.jboss.org/browse/WFLY-7278
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Jan Kalina
            Assignee: Jan Kalina


When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:

{code:java}
java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
	... 28 more
{code}




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct  9 12:57:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sun, 9 Oct 2016 12:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Elytron LdapKeyStore -
 classloading of LdapCtxFactory
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.145.1476032220439@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7278:
-----------------------------
    Description: 
When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:

{code:java}
Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
	at javax.naming.InitialContext.init(InitialContext.java:244)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
	... 16 more
java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
	... 28 more
{code}


  was:
When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:

{code:java}
java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
	... 28 more
{code}




> Elytron LdapKeyStore - classloading of LdapCtxFactory
> -----------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct  9 12:58:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sun, 9 Oct 2016 12:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Elytron LdapKeyStore -
 classloading of LdapCtxFactory
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.151.1476032280332@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7278:
-----------------------------
    Description: 
When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:

{code:java}
Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
	at javax.naming.InitialContext.init(InitialContext.java:244)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
	... 16 more
java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
	... 28 more
{code}

Direct key-store aliases listing using  works ok:
{code:java}
/subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
{code}

  was:
When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:

{code:java}
Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
	at javax.naming.InitialContext.init(InitialContext.java:244)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
	... 16 more
java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
	... 28 more
{code}




> Elytron LdapKeyStore - classloading of LdapCtxFactory
> -----------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct  9 16:47:00 2016
From: issues at jboss.org (Darryl Miles (JIRA))
Date: Sun, 9 Oct 2016 16:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.212.1476046020335@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304629#comment-13304629 ] 

Darryl Miles commented on WFLY-6663:
------------------------------------

Just to report back the use of a @Local interface instead of @Remote does not change the problem.
However I see the .waitForComponentStart();  just before the SFSB id creation in the current pull request, so I look forward to this being this thing to fix the problem as it is also similar a fix for the bug I cited in my 2nd comment here.

> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>            Assignee: Stuart Douglas
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 00:00:03 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 10 Oct 2016 00:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to add trust-manager
 with ldap-key-store
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.518.1476072003653@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7278:
-----------------------------
    Summary: Unable to add trust-manager with ldap-key-store  (was: Elytron LdapKeyStore - classloading of LdapCtxFactory)


> Unable to add trust-manager with ldap-key-store
> -----------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 00:01:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 10 Oct 2016 00:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to add trust-manager
 with ldap-key-store (classloading)
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.524.1476072060240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7278:
-----------------------------
    Summary: Unable to add trust-manager with ldap-key-store (classloading)  (was: Unable to add trust-manager with ldap-key-store)


> Unable to add trust-manager with ldap-key-store (classloading)
> --------------------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 01:20:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 10 Oct 2016 01:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2109) S3_PING: add support for
	instance metadata
In-Reply-To: <JIRA.12653850.1475857628000@Atlassian.JIRA>
References: <JIRA.12653850.1475857628000@Atlassian.JIRA>
	<JIRA.12653850.1475857628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653850.1475857628000.547.1476076800298@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2109:
---------------------------
    Fix Version/s: 4.1


I'm not an expert on S3, although I wrote the original S3_PING (copying code from the Amazon example).
I know there are other S3 discovery implementations (you listed Zalando's impl). Have you asked them if they were planning on adding support for this?

> S3_PING: add support for instance metadata
> ------------------------------------------
>
>                 Key: JGRP-2109
>                 URL: https://issues.jboss.org/browse/JGRP-2109
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Kerem Kacel
>            Assignee: Bela Ban
>             Fix For: 4.1
>
>
> The AWS libraries used by S3_PING do not support authenticating into the AWS API via the EC2 instance profile (implicit credentials stored on the AWS EC2 instance).
> The AWS SDK for Java supports instance profile. This eliminates the need for storing AWS access keys in config files.
> Are there any plans to add official support for this in JGroups?
> Resources:
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html
> Example third-party protocols:
> https://github.com/tagbangers/jgroups-s3-client-ping
> https://github.com/mcacker/jgroups-native-s3-ping



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 02:08:00 2016
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Mon, 10 Oct 2016 02:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-848) "XNIO001001: No XNIO
 provider found" by some tests running with security manager
In-Reply-To: <JIRA.12579731.1438160339000@Atlassian.JIRA>
References: <JIRA.12579731.1438160339000@Atlassian.JIRA>
	<JIRA.12579731.1438160339000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579731.1438160339000.628.1476079680308@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304666#comment-13304666 ] 

Petr Kremensky commented on WFCORE-848:
---------------------------------------

FYI JBEAP-6063

> "XNIO001001: No XNIO provider found" by some tests running with security manager
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-848
>                 URL: https://issues.jboss.org/browse/WFCORE-848
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Petr Kremensky
>            Assignee: Ingo Weiss
>
> Some tests in wildfly-core fails due to "XNIO001001: No XNIO provider found" while run with security manager enabled.
> {noformat}
> mvn test -Dtest=SuspendResumeTestCase -Dsecurity.manager -DtestLogToFile=false
> 10:27:16,814 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.test-undertow-server: org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 	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)
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> 	at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> 	at org.xnio.Xnio.getInstance(Xnio.java:181)
> 	at io.undertow.Undertow.start(Undertow.java:97)
> 	at org.wildfly.test.suspendresumeendpoint.TestUndertowService.start(TestUndertowService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	... 3 more
> 10:27:16,816 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "web-suspend.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
>     Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> 10:27:16,817 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "web-suspend.jar" was rolled back with the following failure message: 
> {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
>     Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> {noformat}
> Affected tests found so far:
> * org.wildfly.core.test.standalone.suspend.web.SuspendResumeTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainGracefulShutdownTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainSuspendResumeTestCase



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 03:33:01 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 10 Oct 2016 03:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-68) execute-commands does not
 work for module command
In-Reply-To: <JIRA.12539159.1398464209000@Atlassian.JIRA>
References: <JIRA.12539159.1398464209000@Atlassian.JIRA>
	<JIRA.12539159.1398464209000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539159.1398464209000.913.1476084781288@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304695#comment-13304695 ] 

James Perkins commented on JBASMP-68:
-------------------------------------

What is the target container you're trying to execute the {{module}} command on?

> execute-commands does not work for module command
> -------------------------------------------------
>
>                 Key: JBASMP-68
>                 URL: https://issues.jboss.org/browse/JBASMP-68
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>    Affects Versions: 7.6.Final
>            Reporter: Alfio Gloria
>
> I'm trying to remove a jboss module by means of maven.
> {code:xml}
> <configuration>
>     <jbossHome>${project.build.directory}/server/jboss72</jbossHome>
>     <execute-commands>
>         <commands>
>             <command>module remove --slot=main --name=system.layers.base.org.jboss.weld.core</command>
>         </commands>
>     </execute-commands>
> </configuration>
> {code}
> execute-commands fails with the following stack trace:
> {code}
> Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:483)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	... 19 more
> Caused by: java.lang.IllegalArgumentException: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set.
> 	at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:180)
> 	at org.jboss.as.plugin.cli.Commands.execute(Commands.java:134)
> 	at org.jboss.as.plugin.cli.ExecuteCommands.execute(ExecuteCommands.java:71)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> 	... 20 more
> Caused by: org.jboss.as.cli.CommandLineException: JBOSS_HOME environment variable is not set.
> 	at org.jboss.as.cli.handlers.module.ASModuleHandler.getModulesDir(ASModuleHandler.java:362)
> 	at org.jboss.as.cli.handlers.module.ASModuleHandler.removeModule(ASModuleHandler.java:326)
> 	at org.jboss.as.cli.handlers.module.ASModuleHandler.doHandle(ASModuleHandler.java:214)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581)
> 	at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:176)
> 	... 23 more
> {code}
> (tested with the last snapshot too) 
> The problem comes from jboss-as-cli that needs the JBOSS_HOME to be set in order to add or remove modules. This is not a requirement for other commands such as deploy.
> There are some points of confusion:
> # JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others;
> # usually there are more than one installation or jboss-as-maven-plugin can download the server;
> # jbossHome config parameter is not take into account;
> # what if I want to make operations on more the one server at the same time?
> At the moment I solved by patching jboss-as-cli using a system property instead of environment variable. I don't know how to solve without touching jboss-as-cli.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 03:49:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 10 Oct 2016 03:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7279) Upgrade to Elytron Subsystem
	1.0.0.Alpha12
In-Reply-To: <JIRA.12653935.1476085736000@Atlassian.JIRA>
References: <JIRA.12653935.1476085736000@Atlassian.JIRA>
	<JIRA.12653935.1476085736116@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653935.1476085736000.1103.1476085741285@Atlassian.JIRA>

Darran Lofthouse created WFLY-7279:
--------------------------------------

             Summary: Upgrade to Elytron Subsystem 1.0.0.Alpha12
                 Key: WFLY-7279
                 URL: https://issues.jboss.org/browse/WFLY-7279
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 03:54:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 10 Oct 2016 03:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1860) Upgrade to jandex 2.0.3
In-Reply-To: <JIRA.12653936.1476085990000@Atlassian.JIRA>
References: <JIRA.12653936.1476085990000@Atlassian.JIRA>
	<JIRA.12653936.1476085990879@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653936.1476085990000.1120.1476086040351@Atlassian.JIRA>

Tomaz Cerar created WFCORE-1860:
-----------------------------------

             Summary: Upgrade to jandex 2.0.3
                 Key: WFCORE-1860
                 URL: https://issues.jboss.org/browse/WFCORE-1860
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Server
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Jandex 2.0.3 changes are used by Weld 2.4.0.Final and it complains a  bit if they are not present.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 04:43:01 2016
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Mon, 10 Oct 2016 04:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5239)
 XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5%
 cases with "no physical address for"
In-Reply-To: <JIRA.12583312.1441035651000@Atlassian.JIRA>
References: <JIRA.12583312.1441035651000@Atlassian.JIRA>
	<JIRA.12583312.1441035651000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583312.1441035651000.1371.1476088981086@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304722#comment-13304722 ] 

Petr Kremensky commented on WFLY-5239:
--------------------------------------

Yep, that's exactly what I was going to do, thanks for the assistance.

> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5239
>                 URL: https://issues.jboss.org/browse/WFLY-5239
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Alpha1
>
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar		&amp#27;[0m&amp#27;[0m15:14:52,808 INFO  [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> &amp#27;[0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> &amp#27;[33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:03,277 WARN  [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> &amp#27;[0mExecuted HTTP request
> &amp#27;[33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> &amp#27;[0m&amp#27;[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message			17:02
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 05:17:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 10 Oct 2016 05:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1322) JPAKnowledgeService session
 does not support mbeans
In-Reply-To: <JIRA.12653952.1476091002000@Atlassian.JIRA>
References: <JIRA.12653952.1476091002000@Atlassian.JIRA>
	<JIRA.12653952.1476091002608@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653952.1476091002000.1622.1476091020856@Atlassian.JIRA>

Matteo Mortari created DROOLS-1322:
--------------------------------------

             Summary: JPAKnowledgeService session does not support mbeans
                 Key: DROOLS-1322
                 URL: https://issues.jboss.org/browse/DROOLS-1322
             Project: Drools
          Issue Type: Bug
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 05:39:00 2016
From: issues at jboss.org (kin zhu (JIRA))
Date: Mon, 10 Oct 2016 05:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7280) getSession() Always Creating
 HttpSession Problem
In-Reply-To: <JIRA.12653956.1476092315000@Atlassian.JIRA>
References: <JIRA.12653956.1476092315000@Atlassian.JIRA>
	<JIRA.12653956.1476092315672@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653956.1476092315000.1811.1476092340884@Atlassian.JIRA>

kin zhu created WFLY-7280:
-----------------------------

             Summary: getSession()  Always Creating HttpSession Problem
                 Key: WFLY-7280
                 URL: https://issues.jboss.org/browse/WFLY-7280
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 10.1.0.Final
         Environment: jdk8u102,  win7x64,  wildfly-servlet-10.1.0.Final.tar.gz
            Reporter: kin zhu
            Assignee: Stuart Douglas


I have a login application called cas.war.  I store the captcha code in session. This application has been running smoothly in JBoss7 and Tomcat7. But when I tried to migrate to wildfly10, I found the captcha code will always be null.  I dug a little deeper, and found out that the server is creating new session each time I post a request(the JSESSIONID cookie changes on every request).  I traced the code and pinned down the problem on this location (as of undertow-servlet-1.4.0.Final-sources.jar ) :
{color:#f6c342}io.undertow.servlet.spec.ServletContextImpl.java,  method  getSession:{color}


{code:java}
public HttpSessionImpl getSession(final ServletContextImpl originalServletContext, final HttpServerExchange exchange, boolean create) {
        SessionConfig c = originalServletContext.getSessionConfig();
        HttpSessionImpl httpSession = exchange.getAttachment(sessionAttachmentKey);
{code}

while  
sessionAttachmentKey =  {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.servlet.spec.HttpSessionImpl>{color}
		
the exchange.attachments map will only contain one such key:   {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.server.session.InMemorySessionManager$SessionImpl>{color}

thus the server will create new session once  request.getSession() is called, regardless one session exist or not.

And please have a look at the relate class InMemorySessionManager  too.








--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 06:13:01 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 10 Oct 2016 06:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7281) IllegalStateException:
 DummyTransaction is not in a valid state to be invoking cache operations on
In-Reply-To: <JIRA.12653960.1476094335000@Atlassian.JIRA>
References: <JIRA.12653960.1476094335000@Atlassian.JIRA>
	<JIRA.12653960.1476094335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653960.1476094335000.2011.1476094381492@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved JBEAP-6365 to WFLY-7281:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7281  (was: JBEAP-6365)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Clustering
                           (was: Clustering)
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR5)


> IllegalStateException: DummyTransaction is not in a valid state to be invoking cache operations on
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7281
>                 URL: https://issues.jboss.org/browse/WFLY-7281
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> Occured on server during scenario eap-7x-failover-http-granular-shutdown-repl-sync.
> Server log stacktrace:
> {code}
> 23:04:41,857 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-97) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=19027}, status=1} is not in a valid state to be invoking cache operations on.
> [JBossINF] 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> [JBossINF] 	at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:351)
> [JBossINF] 	at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [JBossINF] 	at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
> [JBossINF] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154)
> [JBossINF] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] 	at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [JBossINF] 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> [JBossINF] 	at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> [JBossINF] 	at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> [JBossINF] 	at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [JBossINF] 	at org.wildfly.clustering.web.infinispan.session.fine.FineImmutableSessionAttributes.getAttribute(FineImmutableSessionAttributes.java:59)
> [JBossINF] 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.lambda$findListeners$13(InfinispanSessionManager.java:406)
> [JBossINF] 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> [JBossINF] 	at java.util.concurrent.ConcurrentHashMap$KeySpliterator.forEachRemaining(ConcurrentHashMap.java:3527)
> [JBossINF] 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> [JBossINF] 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> [JBossINF] 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> [JBossINF] 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> [JBossINF] 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> [JBossINF] 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:406)
> [JBossINF] 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPrePassivationEvents(InfinispanSessionManager.java:389)
> [JBossINF] 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.close(InfinispanSessionManager.java:457)
> [JBossINF] 	at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:80)
> [JBossINF] 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:814)
> [JBossINF] 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:572)
> [JBossINF] 	at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:171)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:327)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
> [JBossINF] 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
> [JBossINF] 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
> [JBossINF] 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> [JBossINF] 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Link to server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-granular-shutdown-repl-sync/14/console-dev214/
> WARN occured on client at the same time:
> {code}
> 2016/09/21 23:04:41:857 EDT [WARN ][Runner - 1402] HOST dev220.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data:  <org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>>
>         org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> 	at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:163)
> 	at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> 	at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Link to client log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-granular-shutdown-repl-sync/14/console-dev220/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 07:29:00 2016
From: issues at jboss.org (Kerem Kacel (JIRA))
Date: Mon, 10 Oct 2016 07:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2109) S3_PING: add support for
	instance metadata
In-Reply-To: <JIRA.12653850.1475857628000@Atlassian.JIRA>
References: <JIRA.12653850.1475857628000@Atlassian.JIRA>
	<JIRA.12653850.1475857628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653850.1475857628000.2350.1476098940163@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304817#comment-13304817 ] 

Kerem Kacel commented on JGRP-2109:
-----------------------------------

Thanks for responding.

The implementations I listed already support it, but I'm asking if there is a plan to add support in the official JGroups project.

A commercial product we bought uses JGroups, and it's much easier to ask them to upgrade to the latest JGroups.

Why the feature is valuable:
A cloud security best-practice is to secure resources using IAM roles instead of IAM users, and to use instance profile instead of storing long-lived AWS access keys in config files.

> S3_PING: add support for instance metadata
> ------------------------------------------
>
>                 Key: JGRP-2109
>                 URL: https://issues.jboss.org/browse/JGRP-2109
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Kerem Kacel
>            Assignee: Bela Ban
>             Fix For: 4.1
>
>
> The AWS libraries used by S3_PING do not support authenticating into the AWS API via the EC2 instance profile (implicit credentials stored on the AWS EC2 instance).
> The AWS SDK for Java supports instance profile. This eliminates the need for storing AWS access keys in config files.
> Are there any plans to add official support for this in JGroups?
> Resources:
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html
> Example third-party protocols:
> https://github.com/tagbangers/jgroups-s3-client-ping
> https://github.com/mcacker/jgroups-native-s3-ping



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 07:41:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 10 Oct 2016 07:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2109) S3_PING: add support for
	instance metadata
In-Reply-To: <JIRA.12653850.1475857628000@Atlassian.JIRA>
References: <JIRA.12653850.1475857628000@Atlassian.JIRA>
	<JIRA.12653850.1475857628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653850.1475857628000.2415.1476099660219@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304825#comment-13304825 ] 

Bela Ban commented on JGRP-2109:
--------------------------------

{quote}
The implementations I listed already support it, but I'm asking if there is a plan to add support in the official JGroups project.
{quote}

No, we cannot officially support these protocols as they were written by a 3rd party. So you'd have to contact the respective companies which write these protocols anyway.

Also, they have additional dependencies, so they would not be able to make it into JGroups proper, at least for the time being.

Note that there are some protocols which are semi-supported in jgroups-extras (\[1\]).

\[1\] https://github.com/jgroups-extras

> S3_PING: add support for instance metadata
> ------------------------------------------
>
>                 Key: JGRP-2109
>                 URL: https://issues.jboss.org/browse/JGRP-2109
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Kerem Kacel
>            Assignee: Bela Ban
>             Fix For: 4.1
>
>
> The AWS libraries used by S3_PING do not support authenticating into the AWS API via the EC2 instance profile (implicit credentials stored on the AWS EC2 instance).
> The AWS SDK for Java supports instance profile. This eliminates the need for storing AWS access keys in config files.
> Are there any plans to add official support for this in JGroups?
> Resources:
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-roles.html
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html
> Example third-party protocols:
> https://github.com/tagbangers/jgroups-s3-client-ping
> https://github.com/mcacker/jgroups-native-s3-ping



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 08:05:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 10 Oct 2016 08:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2110) Transport: revisit buffers
	and threading
In-Reply-To: <JIRA.12653915.1476027787000@Atlassian.JIRA>
References: <JIRA.12653915.1476027787000@Atlassian.JIRA>
	<JIRA.12653915.1476027787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653915.1476027787000.2531.1476101100259@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2110:
---------------------------
    Description: 
(Concerns only the receiver side)

h4. Parsing
Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.

This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).

h4. Buffers
* UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
* TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
* TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.

h4. Approaches
# The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
# The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
# UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
# To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.

h4. Goals
Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.

  was:
(Concerns only the receiver side)

h4. Parsing
Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only receive fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.

This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).

h4. Buffers
* UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
* TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
* TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.

h4. Approaches
# The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
# The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
# UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
# To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.

h4. Goals
Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.



> Transport: revisit buffers and threading
> ----------------------------------------
>
>                 Key: JGRP-2110
>                 URL: https://issues.jboss.org/browse/JGRP-2110
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> (Concerns only the receiver side)
> h4. Parsing
> Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
> This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
> h4. Buffers
> * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
> * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
> * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
> h4. Approaches
> # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
> # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
> # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
> # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
> h4. Goals
> Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 09:06:00 2016
From: issues at jboss.org (Luca Bueti (JIRA))
Date: Mon, 10 Oct 2016 09:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1925) Unclear error message about
	conflict
In-Reply-To: <JIRA.12499170.1377170711000@Atlassian.JIRA>
References: <JIRA.12499170.1377170711000@Atlassian.JIRA>
	<JIRA.12499170.1377170711000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499170.1377170711000.3192.1476104760164@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304884#comment-13304884 ] 

Luca Bueti commented on WFLY-1925:
----------------------------------

After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on JBoss EAP documentation that explains that override and preserve commands work only for misc files. In my humble opinion, the error message
Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict.
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).

> Unclear error message about conflict
> ------------------------------------
>
>                 Key: WFLY-1925
>                 URL: https://issues.jboss.org/browse/WFLY-1925
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> {noformat}
> [standalone at localhost:9990 /] patch apply /tmp/7e387d2d-a9de-4537-ad29-6f66ada17e53/77cc1914-21ea-4c9e-b023-d981b3cb80e0.zip
> Conflicts detected: jboss-modules.jar
> {noformat}
> That message doesn't say much. It should say something like 'the hash of xxx has changed, you have probably applied manual changes to xxx. Use --override or --preserve arguments to specify how the conflicts should be dealt with.'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 09:07:01 2016
From: issues at jboss.org (Luca Bueti (JIRA))
Date: Mon, 10 Oct 2016 09:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1925) Unclear error message about
	conflict
In-Reply-To: <JIRA.12499170.1377170711000@Atlassian.JIRA>
References: <JIRA.12499170.1377170711000@Atlassian.JIRA>
	<JIRA.12499170.1377170711000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499170.1377170711000.3222.1476104821879@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304884#comment-13304884 ] 

Luca Bueti edited comment on WFLY-1925 at 10/10/16 9:06 AM:
------------------------------------------------------------

After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on JBoss EAP documentation that explains that override and preserve commands work only for misc files. I verified that it's true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).


was (Author: luck17):
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on JBoss EAP documentation that explains that override and preserve commands work only for misc files. In my humble opinion, the error message
Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict.
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).

> Unclear error message about conflict
> ------------------------------------
>
>                 Key: WFLY-1925
>                 URL: https://issues.jboss.org/browse/WFLY-1925
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> {noformat}
> [standalone at localhost:9990 /] patch apply /tmp/7e387d2d-a9de-4537-ad29-6f66ada17e53/77cc1914-21ea-4c9e-b023-d981b3cb80e0.zip
> Conflicts detected: jboss-modules.jar
> {noformat}
> That message doesn't say much. It should say something like 'the hash of xxx has changed, you have probably applied manual changes to xxx. Use --override or --preserve arguments to specify how the conflicts should be dealt with.'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 09:12:00 2016
From: issues at jboss.org (Luca Bueti (JIRA))
Date: Mon, 10 Oct 2016 09:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1925) Unclear error message about
	conflict
In-Reply-To: <JIRA.12499170.1377170711000@Atlassian.JIRA>
References: <JIRA.12499170.1377170711000@Atlassian.JIRA>
	<JIRA.12499170.1377170711000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499170.1377170711000.3248.1476105120361@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304884#comment-13304884 ] 

Luca Bueti edited comment on WFLY-1925 at 10/10/16 9:11 AM:
------------------------------------------------------------

After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on [JBoss EAP documentation|https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html-single/Installation_Guide/index.html#sect-Patch_Installation] that explains that override and preserve commands work only for misc files. I verified that it's true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).


was (Author: luck17):
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on JBoss EAP documentation that explains that override and preserve commands work only for misc files. I verified that it's true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).

> Unclear error message about conflict
> ------------------------------------
>
>                 Key: WFLY-1925
>                 URL: https://issues.jboss.org/browse/WFLY-1925
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> {noformat}
> [standalone at localhost:9990 /] patch apply /tmp/7e387d2d-a9de-4537-ad29-6f66ada17e53/77cc1914-21ea-4c9e-b023-d981b3cb80e0.zip
> Conflicts detected: jboss-modules.jar
> {noformat}
> That message doesn't say much. It should say something like 'the hash of xxx has changed, you have probably applied manual changes to xxx. Use --override or --preserve arguments to specify how the conflicts should be dealt with.'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 09:12:00 2016
From: issues at jboss.org (Luca Bueti (JIRA))
Date: Mon, 10 Oct 2016 09:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1925) Unclear error message about
	conflict
In-Reply-To: <JIRA.12499170.1377170711000@Atlassian.JIRA>
References: <JIRA.12499170.1377170711000@Atlassian.JIRA>
	<JIRA.12499170.1377170711000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499170.1377170711000.3252.1476105120482@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304884#comment-13304884 ] 

Luca Bueti edited comment on WFLY-1925 at 10/10/16 9:11 AM:
------------------------------------------------------------

After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on [JBoss EAP documentation|https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html-single/Installation_Guide/index.html#sect-Patch_Installation] that explains that override and preserve commands work only for misc files. I verified this is true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).


was (Author: luck17):
After unsuccessfully trying to preserve module conflicts for the last 4 hours, I found an article on [JBoss EAP documentation|https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html-single/Installation_Guide/index.html#sect-Patch_Installation] that explains that override and preserve commands work only for misc files. I verified that it's true by looking at wfly cli source code. In my humble opinion, the error message
_Use the --override-all, --override=[] or --preserve=[] arguments in order to resolve the conflict._
could be improved to add this useful information (which I couldn't find in wildfly Admin Docs).

> Unclear error message about conflict
> ------------------------------------
>
>                 Key: WFLY-1925
>                 URL: https://issues.jboss.org/browse/WFLY-1925
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Emanuel Muckenhuber
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> {noformat}
> [standalone at localhost:9990 /] patch apply /tmp/7e387d2d-a9de-4537-ad29-6f66ada17e53/77cc1914-21ea-4c9e-b023-d981b3cb80e0.zip
> Conflicts detected: jboss-modules.jar
> {noformat}
> That message doesn't say much. It should say something like 'the hash of xxx has changed, you have probably applied manual changes to xxx. Use --override or --preserve arguments to specify how the conflicts should be dealt with.'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 09:20:01 2016
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Mon, 10 Oct 2016 09:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-848) "XNIO001001: No XNIO
 provider found" by some tests running with security manager
In-Reply-To: <JIRA.12579731.1438160339000@Atlassian.JIRA>
References: <JIRA.12579731.1438160339000@Atlassian.JIRA>
	<JIRA.12579731.1438160339000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579731.1438160339000.3335.1476105601121@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13304899#comment-13304899 ] 

Josef Cacek commented on WFCORE-848:
------------------------------------

[~pkremens] Thanks for the comment.

[~iweiss] Yes, as comments show in the JIRA Petr had mentioned, we are eager to consume Widfly Security Manager from the Core.

> "XNIO001001: No XNIO provider found" by some tests running with security manager
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-848
>                 URL: https://issues.jboss.org/browse/WFCORE-848
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 2.0.0.Alpha11
>            Reporter: Petr Kremensky
>            Assignee: Ingo Weiss
>
> Some tests in wildfly-core fails due to "XNIO001001: No XNIO provider found" while run with security manager enabled.
> {noformat}
> mvn test -Dtest=SuspendResumeTestCase -Dsecurity.manager -DtestLogToFile=false
> 10:27:16,814 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.test-undertow-server: org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 	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)
> Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> 	at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> 	at org.xnio.Xnio.getInstance(Xnio.java:181)
> 	at io.undertow.Undertow.start(Undertow.java:97)
> 	at org.wildfly.test.suspendresumeendpoint.TestUndertowService.start(TestUndertowService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	... 3 more
> 10:27:16,816 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "web-suspend.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
>     Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> 10:27:16,817 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "web-suspend.jar" was rolled back with the following failure message: 
> {"WFLYCTL0080: Failed services" => {"jboss.test-undertow-server" => "org.jboss.msc.service.StartException in service jboss.test-undertow-server: Failed to start service
>     Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found"}}
> {noformat}
> Affected tests found so far:
> * org.wildfly.core.test.standalone.suspend.web.SuspendResumeTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainGracefulShutdownTestCase
> * org.jboss.as.test.integration.domain.suspendresume.DomainSuspendResumeTestCase



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 10:27:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 10 Oct 2016 10:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1861) Subsystem parsers should be
 created lazily when needed
In-Reply-To: <JIRA.12654004.1476109477000@Atlassian.JIRA>
References: <JIRA.12654004.1476109477000@Atlassian.JIRA>
	<JIRA.12654004.1476109477000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654004.1476109477000.3996.1476109620485@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved STXM-16 to WFCORE-1861:
-----------------------------------------

     Project: WildFly Core  (was: StAXMapper)
         Key: WFCORE-1861  (was: STXM-16)
    Workflow: GIT Pull Request workflow   (was: classic default workflow)


> Subsystem parsers should be created lazily when needed
> ------------------------------------------------------
>
>                 Key: WFCORE-1861
>                 URL: https://issues.jboss.org/browse/WFCORE-1861
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> Currently when we register parsers for different versions of subsystem schema we always pass over instance of whole parser which is usually statically initialized.
> In practice legacy (non current) parsers are only used rarely and there is no point in having them loaded in memory when not needed.
> Impl should be based on provider pattern and as such also allow us to on demand create new instance of parser when needed, as well as enable us for parsers to be GCed, when they are not in use.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 10:27:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 10 Oct 2016 10:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1861) Subsystem parsers should be
 created lazily when needed
In-Reply-To: <JIRA.12654004.1476109477000@Atlassian.JIRA>
References: <JIRA.12654004.1476109477000@Atlassian.JIRA>
	<JIRA.12654004.1476109477000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654004.1476109477000.3999.1476109620595@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-1861:
--------------------------------
    Component/s: Domain Management


> Subsystem parsers should be created lazily when needed
> ------------------------------------------------------
>
>                 Key: WFCORE-1861
>                 URL: https://issues.jboss.org/browse/WFCORE-1861
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> Currently when we register parsers for different versions of subsystem schema we always pass over instance of whole parser which is usually statically initialized.
> In practice legacy (non current) parsers are only used rarely and there is no point in having them loaded in memory when not needed.
> Impl should be based on provider pattern and as such also allow us to on demand create new instance of parser when needed, as well as enable us for parsers to be GCed, when they are not in use.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 10:52:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 10 Oct 2016 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-141)
 StringIndexOutOfBoundsException throw while formatting log with truncation
In-Reply-To: <JIRA.12635714.1467135971000@Atlassian.JIRA>
References: <JIRA.12635714.1467135971000@Atlassian.JIRA>
	<JIRA.12635714.1467135971000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12635714.1467135971000.4146.1476111120616@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-141:
---------------------------------
    Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/98, https://github.com/jboss-logging/jboss-logmanager/pull/99, https://github.com/jboss-logging/jboss-logmanager/pull/100  (was: https://github.com/jboss-logging/jboss-logmanager/pull/98)


> StringIndexOutOfBoundsException throw while formatting log with truncation
> --------------------------------------------------------------------------
>
>                 Key: LOGMGR-141
>                 URL: https://issues.jboss.org/browse/LOGMGR-141
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 1.5.7.Final, 2.0.5.Final, 2.1.0.Beta1
>
>
> When value in left-justified field is longer than maximum width following exception is thrown:
> {code}
> java.lang.StringIndexOutOfBoundsException
>         at java.lang.AbstractStringBuilder.delete(AbstractStringBuilder.java:733)
>         at java.lang.StringBuilder.delete(StringBuilder.java:244)
>         at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:212)
>         at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:83)
>         at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:32)
>         at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:46)
>         at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
>         at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:302)
>         at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
>         at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
>         at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
>         at org.jboss.logmanager.Logger.logRaw(Logger.java:719)
>         at org.jboss.logmanager.Logger.log(Logger.java:670)
>         at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:50)
>         at org.jboss.logging.Logger.logf(Logger.java:2096)
> {code}
> Steps to Reproduce:
> 1. Configure formatter with left-justified field with maximum width:
> {code}
> /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter,value="%d{HH:mm:ss,SSS} %-5p [%c{1.}] [%-20.-20t] %s%E%n")
> {code}
> (in the example above thread name should be truncated to 20 characters, left-justified)
> 2. Write a log from a thread which has a name containg 21 characters or more. During server startup logs are written by "MSC service thread 1-7" thread.
> It seems there is an error in {{org.jboss.logmanager.formatters.Formatters()}} class, line 212. There is:
> {code:java}
> builder.delete(oldLen, overflow + 1);
> {code}
> but should be:
> {code:java}
> builder.delete(oldLen, oldLen + overflow);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 10:52:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 10 Oct 2016 10:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-141)
 StringIndexOutOfBoundsException throw while formatting log with truncation
In-Reply-To: <JIRA.12635714.1467135971000@Atlassian.JIRA>
References: <JIRA.12635714.1467135971000@Atlassian.JIRA>
	<JIRA.12635714.1467135971000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12635714.1467135971000.4147.1476111120633@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-141:
---------------------------------
    Fix Version/s: 1.5.7.Final
                   2.0.5.Final


> StringIndexOutOfBoundsException throw while formatting log with truncation
> --------------------------------------------------------------------------
>
>                 Key: LOGMGR-141
>                 URL: https://issues.jboss.org/browse/LOGMGR-141
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 1.5.7.Final, 2.0.5.Final, 2.1.0.Beta1
>
>
> When value in left-justified field is longer than maximum width following exception is thrown:
> {code}
> java.lang.StringIndexOutOfBoundsException
>         at java.lang.AbstractStringBuilder.delete(AbstractStringBuilder.java:733)
>         at java.lang.StringBuilder.delete(StringBuilder.java:244)
>         at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:212)
>         at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:83)
>         at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:32)
>         at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:46)
>         at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
>         at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:302)
>         at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
>         at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
>         at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
>         at org.jboss.logmanager.Logger.logRaw(Logger.java:719)
>         at org.jboss.logmanager.Logger.log(Logger.java:670)
>         at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:50)
>         at org.jboss.logging.Logger.logf(Logger.java:2096)
> {code}
> Steps to Reproduce:
> 1. Configure formatter with left-justified field with maximum width:
> {code}
> /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter,value="%d{HH:mm:ss,SSS} %-5p [%c{1.}] [%-20.-20t] %s%E%n")
> {code}
> (in the example above thread name should be truncated to 20 characters, left-justified)
> 2. Write a log from a thread which has a name containg 21 characters or more. During server startup logs are written by "MSC service thread 1-7" thread.
> It seems there is an error in {{org.jboss.logmanager.formatters.Formatters()}} class, line 212. There is:
> {code:java}
> builder.delete(oldLen, overflow + 1);
> {code}
> but should be:
> {code:java}
> builder.delete(oldLen, oldLen + overflow);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 12:11:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 10 Oct 2016 12:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.4801.1476115860397@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1323:
-------------------------------------
    Attachment: Selection_240.png
                Selection_241.png


> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png
>
>
> Mario and Geoffrey will investigate, but here's the jprofiler report to prove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 12:11:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 10 Oct 2016 12:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115811000@Atlassian.JIRA>
References: <JIRA.12654021.1476115811000@Atlassian.JIRA>
	<JIRA.12654021.1476115811865@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115811000.4798.1476115860340@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-1323:
----------------------------------------

             Summary: DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
                 Key: DROOLS-1323
                 URL: https://issues.jboss.org/browse/DROOLS-1323
             Project: Drools
          Issue Type: Task
          Components: core engine
            Reporter: Geoffrey De Smet
            Assignee: Mario Fusco


Mario and Geoffrey will investigate, but here's the jprofiler report to prove



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 12:11:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 10 Oct 2016 12:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.4804.1476115860465@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1323:
-------------------------------------
    Description: Mario and Geoffrey will investigate, but here's the profiler reports to prove it.  (was: Mario and Geoffrey will investigate, but here's the jprofiler report to prove)


> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 12:12:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 10 Oct 2016 12:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.4807.1476115920111@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1323:
-------------------------------------
    Description: 
Mario and Geoffrey will investigate, but here's the profiler reports to prove it.

to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve

  was:Mario and Geoffrey will investigate, but here's the profiler reports to prove it.



> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 12:15:03 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 10 Oct 2016 12:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.4829.1476116103235@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1313.
---------------------------------
    Resolution: Rejected


I believe there isn't any leak. Old releases are just kept in the KieRepository. If you want to remove them you can do it programmatically with

{code}
KieServices.Factory.get().getRepository().removeKieModule( oldReleaseId );
{code}

Please try to add this to your code and if the problem persists feel free to reopen this ticket.

> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 16:26:00 2016
From: issues at jboss.org (Bill Tuminaro (JIRA))
Date: Mon, 10 Oct 2016 16:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.5709.1476131160249@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Tuminaro reopened DROOLS-1313:
-----------------------------------


I added the code suggested, but the results reported by the Memory Analyzer appear to be the same as before.  Please see the SAVE_SimpleTest4.java file and the simpleTestThirdDump4.png screenshot.

-BillT

> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 16:28:00 2016
From: issues at jboss.org (Bill Tuminaro (JIRA))
Date: Mon, 10 Oct 2016 16:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.5715.1476131280183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Tuminaro updated DROOLS-1313:
----------------------------------
    Attachment: SAVE_SimpleTest4.java
                simpleTestThirdDump4.png


> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 16:59:00 2016
From: issues at jboss.org (Nicolas Heron (JIRA))
Date: Mon, 10 Oct 2016 16:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1318) Using java enum when
 setting a variable of type enum does not work
In-Reply-To: <JIRA.12650751.1474288713000@Atlassian.JIRA>
References: <JIRA.12650751.1474288713000@Atlassian.JIRA>
	<JIRA.12650751.1474288713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650751.1474288713000.5764.1476133140124@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305155#comment-13305155 ] 

Nicolas Heron commented on DROOLS-1318:
---------------------------------------

I did a small project to identify the problem https://github.com/nheron/use-case1


> Using java enum when setting a variable of type enum does not work
> ------------------------------------------------------------------
>
>                 Key: DROOLS-1318
>                 URL: https://issues.jboss.org/browse/DROOLS-1318
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Mario Fusco
>              Labels: OnBoarding
>
> In project https://github.com/chtiJBUG/onboarding-nautic-project
> when running the TestBirthday reduction
> TestBirthdayReduction : [Error: could not access/write property (seasonType) in: org.chtijbug.example.swimmingpool.Period] [Near :
> the source code of the rule is 
> package org.training.leisure.swimmingpool;
> import java.lang.Number;
> import org.chtijbug.example.swimmingpool.CalculatedAttribute;
> import org.chtijbug.example.swimmingpool.Price;
> import org.chtijbug.example.swimmingpool.Person;
> import org.chtijbug.example.swimmingpool.Period;
> import org.chtijbug.example.swimmingpool.PriceType;
> rule "BirthdayReduction"
> 	dialect "mvel"
> 	ruleflow-group "reduction"
> 	when
> 		ccat : CalculatedAttribute( key == "IsPersonBirthday" , stringValue == "true" )
> 		pper : Person( calculatedAttributeList contains ccat , sprice : standardPrice > 0.0B )
> 		not (pprice : Price( description == "BirthdayReduction" ) and Person( priceList contains pprice , this == pper )) 
> 		Period( seasonType == SeasonType.day )
> 	then
> 		Price nprice = new Price();
> 		nprice.setDescription( "BirthdayReduction" );
> 		nprice.setAmount( sprice.divide(new BigDecimal("10.0"),BigDecimal.ROUND_HALF_UP) );
> 		nprice.setPriceType( PriceType.promotion );
> 		insert( nprice );
> 		pper.addPrice( nprice );
> 		modify( pper ) {
> 				setPriceList( pper.getPriceList() )
> 		}
> end



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 10 18:41:01 2016
From: issues at jboss.org (Yeray Santana Borges (JIRA))
Date: Mon, 10 Oct 2016 18:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1791) Strange operation-id
 handling in domain server reload execution
In-Reply-To: <JIRA.12650054.1473797538000@Atlassian.JIRA>
References: <JIRA.12650054.1473797538000@Atlassian.JIRA>
	<JIRA.12650054.1473797538000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650054.1473797538000.5784.1476139261243@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Santana Borges reassigned WFCORE-1791:
--------------------------------------------

    Assignee: Yeray Santana Borges


> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
>                 Key: WFCORE-1791
>                 URL: https://issues.jboss.org/browse/WFCORE-1791
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Yeray Santana Borges
>            Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don?t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df15c88cc89ffd90 is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete. 
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then 
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 10 19:03:00 2016
From: issues at jboss.org (Yeray Santana Borges (JIRA))
Date: Mon, 10 Oct 2016 19:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1791) Strange operation-id
 handling in domain server reload execution
In-Reply-To: <JIRA.12650054.1473797538000@Atlassian.JIRA>
References: <JIRA.12650054.1473797538000@Atlassian.JIRA>
	<JIRA.12650054.1473797538000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650054.1473797538000.5815.1476140580155@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305160#comment-13305160 ] 

Yeray Santana Borges commented on WFCORE-1791:
----------------------------------------------

It seems the operation-id is sent back to the HC in this method: HostControllerConnection.ServerRegisterRequest.sendRequest. As far as I have been able to check, this is the sequence which enables the operation-id being sent back:

# Reload is executed in a domain mode, so HC sends the current operation-id in the reload operation to the managed server(s)
# On server(s) side, ServerDomainProcessReloadHandler is executed which updates the static instance variable DomainServerCommunicationServices.initialOperationID
# Server(s) is reloaded, the root service for an application server process is ApplicationServerService, its start() method is then invoked which activates two service activators: DomainServerCommunicationServices and an anonymous service activator created in ServerStartTask
# DomainServerCommunicationServices.activate is invoked which creates a new HostControllerConnectionService and installs it, so its HostControllerConnectionService.start method is invoked which creates a new HostControllerConnection instance. This instance is the instance used to send the operation-id back to the HC. In this point the HostControllerConnection has the operation-id updated in point 2) by the reload operation on server side.
# The anonymous service activator in ServerStartTask class is activated too. This class installs the ServerBootOperationsService service. This service in L68 invokes HostControllerClient.resolveBootUpdates which invokes HostControllerConnection.openConnection. The connection is then opened using ServerRegisterRequest which sends the operation-id the HC in ServerRegisterRequest.sendRequest. 
# The server is registered then by the HC executing the register operation and without blocking since it has the correct operation-id received before.


> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
>                 Key: WFCORE-1791
>                 URL: https://issues.jboss.org/browse/WFCORE-1791
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Yeray Santana Borges
>            Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don?t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df15c88cc89ffd90 is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete. 
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then 
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 11 01:54:00 2016
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Tue, 11 Oct 2016 01:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7282) Double diamond in EJB
	Transaction
In-Reply-To: <JIRA.12654056.1476165225000@Atlassian.JIRA>
References: <JIRA.12654056.1476165225000@Atlassian.JIRA>
	<JIRA.12654056.1476165225121@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654056.1476165225000.5921.1476165240103@Atlassian.JIRA>

Flavia Rainone created WFLY-7282:
------------------------------------

             Summary: Double diamond in EJB Transaction
                 Key: WFLY-7282
                 URL: https://issues.jboss.org/browse/WFLY-7282
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 10.1.0.Final
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 10.2.0.Final, 11.0.0.Alpha1


At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 01:56:00 2016
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Tue, 11 Oct 2016 01:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7282) Double diamond in EJB
	Transaction
In-Reply-To: <JIRA.12654056.1476165225000@Atlassian.JIRA>
References: <JIRA.12654056.1476165225000@Atlassian.JIRA>
	<JIRA.12654056.1476165225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654056.1476165225000.5926.1476165360070@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-7282:
---------------------------------
           Description: 
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.



  was:At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.

    Steps to Reproduce: 
You need a reinvocation at a server that was already participating in the transaction, as the scenario below for example:
server1 -> server2 -> server1


> Double diamond in EJB Transaction
> ---------------------------------
>
>                 Key: WFLY-7282
>                 URL: https://issues.jboss.org/browse/WFLY-7282
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>
> At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 02:21:00 2016
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Tue, 11 Oct 2016 02:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7282) Deadlock in BasicAction when
 jboss remoting and JTA is used
In-Reply-To: <JIRA.12654056.1476165225000@Atlassian.JIRA>
References: <JIRA.12654056.1476165225000@Atlassian.JIRA>
	<JIRA.12654056.1476165225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654056.1476165225000.5974.1476166860195@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-7282:
---------------------------------
    Description: 
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem and a deadlock.

Issue created based on discussion at jboss-support-transactions list: http://post-office.corp.redhat.com/archives/jboss-support-transactions/2016-September/msg00000.html

Current jboss remoting implementation on JTA does not provide correct handling of double diamond transaction propagation problem.

If transaction is propagated from one server to other one and then back to the first one then such situation can cause deadlock. Remote calls and transactions are processed but when servers using the same remote resource the prepare phase of 2PC can stuck. Transaction is timed-out later and recovery process rolls it back.

IIOP/JTS does not suffer with this flaw.


  was:
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.



        Summary: Deadlock in BasicAction when jboss remoting and JTA is used  (was: Double diamond in EJB Transaction)


> Deadlock in BasicAction when jboss remoting and JTA is used
> -----------------------------------------------------------
>
>                 Key: WFLY-7282
>                 URL: https://issues.jboss.org/browse/WFLY-7282
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>
> At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem and a deadlock.
> Issue created based on discussion at jboss-support-transactions list: http://post-office.corp.redhat.com/archives/jboss-support-transactions/2016-September/msg00000.html
> Current jboss remoting implementation on JTA does not provide correct handling of double diamond transaction propagation problem.
> If transaction is propagated from one server to other one and then back to the first one then such situation can cause deadlock. Remote calls and transactions are processed but when servers using the same remote resource the prepare phase of 2PC can stuck. Transaction is timed-out later and recovery process rolls it back.
> IIOP/JTS does not suffer with this flaw.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 02:29:00 2016
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Tue, 11 Oct 2016 02:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7283) Update EJB to use txn spi
In-Reply-To: <JIRA.12654068.1476167295000@Atlassian.JIRA>
References: <JIRA.12654068.1476167295000@Atlassian.JIRA>
	<JIRA.12654068.1476167295550@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654068.1476167295000.6001.1476167340248@Atlassian.JIRA>

Flavia Rainone created WFLY-7283:
------------------------------------

             Summary: Update EJB to use txn spi
                 Key: WFLY-7283
                 URL: https://issues.jboss.org/browse/WFLY-7283
             Project: WildFly
          Issue Type: Enhancement
          Components: EJB
    Affects Versions: 10.1.0.Final
            Reporter: Flavia Rainone
            Priority: Minor
             Fix For: 10.2.0.Final, 11.0.0.Alpha1


Remote references from EJB to internal transaction classes, replacing then by references to the spi.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 02:29:00 2016
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Tue, 11 Oct 2016 02:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7283) Update EJB to use txn spi
In-Reply-To: <JIRA.12654068.1476167296000@Atlassian.JIRA>
References: <JIRA.12654068.1476167296000@Atlassian.JIRA>
	<JIRA.12654068.1476167296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654068.1476167296000.6003.1476167340299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone reassigned WFLY-7283:
------------------------------------

    Assignee: Flavia Rainone


> Update EJB to use txn spi
> -------------------------
>
>                 Key: WFLY-7283
>                 URL: https://issues.jboss.org/browse/WFLY-7283
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>            Priority: Minor
>             Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>
> Remote references from EJB to internal transaction classes, replacing then by references to the spi.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 03:42:00 2016
From: issues at jboss.org (Joni Niemi (JIRA))
Date: Tue, 11 Oct 2016 03:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1199) Memory leak in KieScanner
In-Reply-To: <JIRA.12629750.1465228010000@Atlassian.JIRA>
References: <JIRA.12629750.1465228010000@Atlassian.JIRA>
	<JIRA.12629750.1465228010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629750.1465228010000.6387.1476171720455@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305219#comment-13305219 ] 

Joni Niemi commented on DROOLS-1199:
------------------------------------

This bug makes version 6.4.0.Final unusable in a production environment. Your options are either to downgrade or fork and make your own build.

> Memory leak in KieScanner
> -------------------------
>
>                 Key: DROOLS-1199
>                 URL: https://issues.jboss.org/browse/DROOLS-1199
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>            Reporter: Viacheslav Krot
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.Beta1
>
>
> I'm not sure, but it seems there is a memory leak in KieScanner, not in scanner directly, but somewhere in plexus used internally.
> If you start KieScanner with version = LATEST, start it with interval say 1 second and sample memory with visualvm (or any other), you can watch number of instances org.eclipse.sisu.plexus.* growing over time. And they cannot be garbage collected - memory root is timer thread. This happens in drools 6.4.0, in 6.3.0 this issue was absent.
> Eventually application fails with OOM.
> As a workaround we call KieScanner#scan manually in a separate thread pool that is recreated from time to time.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 04:13:00 2016
From: issues at jboss.org (Karel Suta (JIRA))
Date: Tue, 11 Oct 2016 04:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1324) CNFE when stopping server
 with enabled scanner
In-Reply-To: <JIRA.12654096.1476173559000@Atlassian.JIRA>
References: <JIRA.12654096.1476173559000@Atlassian.JIRA>
	<JIRA.12654096.1476173559872@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654096.1476173559000.6898.1476173580434@Atlassian.JIRA>

Karel Suta created DROOLS-1324:
----------------------------------

             Summary: CNFE when stopping server with enabled scanner
                 Key: DROOLS-1324
                 URL: https://issues.jboss.org/browse/DROOLS-1324
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 7.0.0.Beta2, 6.5.0.CR2
         Environment: Kie server 6.5.0-SNAPSHOT
            Reporter: Karel Suta
            Assignee: Edson Tirelli
            Priority: Minor
         Attachments: stacktrace-server.txt

When I stop application server with Kie server containing container with started scanner, sometimes I get ClassNotFoundException, see attachment.
This exception doesn't seem to have any affect on functionality, but still it should be resolved as it may hide some other problem.
This exception occurs randomly, you may need to start/stop server several times to see it.

Interesting is that class, which wasn't found by classloader, is actually present in Kie server in artefact sisu-guice-3.2.3-no_aop.jar.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 04:14:00 2016
From: issues at jboss.org (Karel Suta (JIRA))
Date: Tue, 11 Oct 2016 04:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1324) CNFE when stopping server
 with enabled scanner
In-Reply-To: <JIRA.12654096.1476173560000@Atlassian.JIRA>
References: <JIRA.12654096.1476173560000@Atlassian.JIRA>
	<JIRA.12654096.1476173560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654096.1476173560000.6902.1476173640579@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Suta reassigned DROOLS-1324:
----------------------------------

    Assignee: Maciej Swiderski  (was: Edson Tirelli)


> CNFE when stopping server with enabled scanner
> ----------------------------------------------
>
>                 Key: DROOLS-1324
>                 URL: https://issues.jboss.org/browse/DROOLS-1324
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.5.0.CR2, 7.0.0.Beta2
>         Environment: Kie server 6.5.0-SNAPSHOT
>            Reporter: Karel Suta
>            Assignee: Maciej Swiderski
>            Priority: Minor
>              Labels: reported-by-qe
>         Attachments: stacktrace-server.txt
>
>
> When I stop application server with Kie server containing container with started scanner, sometimes I get ClassNotFoundException, see attachment.
> This exception doesn't seem to have any affect on functionality, but still it should be resolved as it may hide some other problem.
> This exception occurs randomly, you may need to start/stop server several times to see it.
> Interesting is that class, which wasn't found by classloader, is actually present in Kie server in artefact sisu-guice-3.2.3-no_aop.jar.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 04:35:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 11 Oct 2016 04:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5542) Look into using apache's
	upstream JSTL
In-Reply-To: <JIRA.12589570.1445255749000@Atlassian.JIRA>
References: <JIRA.12589570.1445255749000@Atlassian.JIRA>
	<JIRA.12589570.1445255749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589570.1445255749000.7227.1476174900177@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305294#comment-13305294 ] 

Tomaz Cerar commented on WFLY-5542:
-----------------------------------

2) shouldn't be an issue anymore as it looks like apache version uses different fix that should also work. But only way to be sure is to pass tck.
3) i don't see that as an issue, secure by default is better default in any case. I am surprised we don't have it as well. There (w)are bugs raised to fix that.

> Look into using apache's upstream JSTL
> --------------------------------------
>
>                 Key: WFLY-5542
>                 URL: https://issues.jboss.org/browse/WFLY-5542
>             Project: WildFly
>          Issue Type: Task
>          Components: EE, Web (Undertow)
>    Affects Versions: 10.0.0.CR2
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> We are now using forked combination of apache & java.net's version of JSTL.
> We should look into using upstream version if possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 05:26:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 11 Oct 2016 05:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1862) [QE] 7.1.0 Server hanging
 on HP-UX when reload is initiated quickly after server was sending large
 amount of data
In-Reply-To: <JIRA.12654153.1476177730000@Atlassian.JIRA>
References: <JIRA.12654153.1476177730000@Atlassian.JIRA>
	<JIRA.12654153.1476177730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654153.1476177730000.7827.1476177960416@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka moved JBEAP-6377 to WFCORE-1862:
-------------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-1862  (was: JBEAP-6377)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Server
                           (was: Server)
                           (was: Web (Undertow))
    Affects Version/s: 2.2.0.Final
                           (was: 7.1.0.DR6)
      Affects Testing:   (was: Regression)
        Fix Version/s:     (was: 7.1.0.GA)


> [QE] 7.1.0 Server hanging on HP-UX when reload is initiated quickly after server was sending large amount of data
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1862
>                 URL: https://issues.jboss.org/browse/WFCORE-1862
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 2.2.0.Final
>         Environment: Noticed only on HP-UX ia64 with java version "1.8.0.04-hp-ux"
>            Reporter: Radim Hatlapatka
>            Assignee: David Lloyd
>            Priority: Blocker
>         Attachments: connector-metrics.war, duringReload.jstack, eap.jstack
>
>
> Originally reported for EAP 7.0.3.CP.CR2, still this issue is valid also for EAP 7.1.0.DR6
> Upgrade to XNIO 3.4.0.Final causes regression resulting in server hanging during reload on HP-UX in situation when servlet was sending more than 4 GB of data and suddenly reload operation is called. The reload operation doesn't finish.
> The deployment sending the data is according to log stopped, still there is visible running thread in awaitWritable \[1\].
> Note: If I use older version of XNIO => replacing XNIO 3.4.0.Final with XNIO 3.3.6.Final (version used in EAP 7.0.2.CP), it works just fine.
> Attaching eap.jstack (thread dump when arquillian tries to stop the server after reload operation timed out) and duringReload.jstack (thread dump when reload is called and it is waited for server to be reloaded) 
> \[1\]
> {noformat}
> "default task-1" #786 prio=5 os_prio=-179 tid=0x00c18000 nid=796 lwp_id=8999064 runnable [0x27cc0000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
> 	at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
> 	at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:84)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0x6c393e50> (a sun.nio.ch.Util$2)
> 	- locked <0x6c393e40> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0x6c393d40> (a sun.nio.ch.DevPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
> 	at org.xnio.nio.NioSocketConduit.awaitWritable(NioSocketConduit.java:233)
> 	at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
> 	at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.awaitWritable(ChunkedStreamSinkConduit.java:361)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.awaitWritable(ConduitStreamSinkChannel.java:134)
> 	at io.undertow.channels.DetachableStreamSinkChannel.awaitWritable(DetachableStreamSinkChannel.java:87)
> 	at io.undertow.server.HttpServerExchange$WriteDispatchChannel.awaitWritable(HttpServerExchange.java:1951)
> 	at org.xnio.channels.Channels.writeBlocking(Channels.java:154)
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:184)
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128)
> 	at org.jboss.qa.management.web.resources.DataSenderServlet.doGet(DataSenderServlet.java:33)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
> 	at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
> 	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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 05:27:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 11 Oct 2016 05:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1862) [QE] 7.1.0 Server hanging
 on HP-UX when reload is initiated quickly after server was sending large
 amount of data
In-Reply-To: <JIRA.12654153.1476177730000@Atlassian.JIRA>
References: <JIRA.12654153.1476177730000@Atlassian.JIRA>
	<JIRA.12654153.1476177730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654153.1476177730000.7842.1476178020335@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFCORE-1862:
-------------------------------------
    Description: 
Originally reported for EAP 7.0.3.CP.CR2, still this issue is valid also for WildFly 10.1.0.Final

Upgrade to XNIO 3.4.0.Final causes regression resulting in server hanging during reload on HP-UX in situation when servlet was sending more than 4 GB of data and suddenly reload operation is called. The reload operation doesn't finish.

The deployment sending the data is according to log stopped, still there is visible running thread in awaitWritable \[1\].

Note: If I use older version of XNIO => replacing XNIO 3.4.0.Final with XNIO 3.3.6.Final, it works just fine.

Attaching eap.jstack (thread dump when arquillian tries to stop the server after reload operation timed out) and duringReload.jstack (thread dump when reload is called and it is waited for server to be reloaded) 


\[1\]
{noformat}
"default task-1" #786 prio=5 os_prio=-179 tid=0x00c18000 nid=796 lwp_id=8999064 runnable [0x27cc0000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
	at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
	at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:84)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
	- locked <0x6c393e50> (a sun.nio.ch.Util$2)
	- locked <0x6c393e40> (a java.util.Collections$UnmodifiableSet)
	- locked <0x6c393d40> (a sun.nio.ch.DevPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
	at org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
	at org.xnio.nio.NioSocketConduit.awaitWritable(NioSocketConduit.java:233)
	at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
	at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
	at io.undertow.conduits.ChunkedStreamSinkConduit.awaitWritable(ChunkedStreamSinkConduit.java:361)
	at org.xnio.conduits.ConduitStreamSinkChannel.awaitWritable(ConduitStreamSinkChannel.java:134)
	at io.undertow.channels.DetachableStreamSinkChannel.awaitWritable(DetachableStreamSinkChannel.java:87)
	at io.undertow.server.HttpServerExchange$WriteDispatchChannel.awaitWritable(HttpServerExchange.java:1951)
	at org.xnio.channels.Channels.writeBlocking(Channels.java:154)
	at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:184)
	at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128)
	at org.jboss.qa.management.web.resources.DataSenderServlet.doGet(DataSenderServlet.java:33)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
	at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
	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)
{noformat}

  was:
Originally reported for EAP 7.0.3.CP.CR2, still this issue is valid also for EAP 7.1.0.DR6

Upgrade to XNIO 3.4.0.Final causes regression resulting in server hanging during reload on HP-UX in situation when servlet was sending more than 4 GB of data and suddenly reload operation is called. The reload operation doesn't finish.

The deployment sending the data is according to log stopped, still there is visible running thread in awaitWritable \[1\].

Note: If I use older version of XNIO => replacing XNIO 3.4.0.Final with XNIO 3.3.6.Final (version used in EAP 7.0.2.CP), it works just fine.

Attaching eap.jstack (thread dump when arquillian tries to stop the server after reload operation timed out) and duringReload.jstack (thread dump when reload is called and it is waited for server to be reloaded) 


\[1\]
{noformat}
"default task-1" #786 prio=5 os_prio=-179 tid=0x00c18000 nid=796 lwp_id=8999064 runnable [0x27cc0000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
	at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
	at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:84)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
	- locked <0x6c393e50> (a sun.nio.ch.Util$2)
	- locked <0x6c393e40> (a java.util.Collections$UnmodifiableSet)
	- locked <0x6c393d40> (a sun.nio.ch.DevPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
	at org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
	at org.xnio.nio.NioSocketConduit.awaitWritable(NioSocketConduit.java:233)
	at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
	at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
	at io.undertow.conduits.ChunkedStreamSinkConduit.awaitWritable(ChunkedStreamSinkConduit.java:361)
	at org.xnio.conduits.ConduitStreamSinkChannel.awaitWritable(ConduitStreamSinkChannel.java:134)
	at io.undertow.channels.DetachableStreamSinkChannel.awaitWritable(DetachableStreamSinkChannel.java:87)
	at io.undertow.server.HttpServerExchange$WriteDispatchChannel.awaitWritable(HttpServerExchange.java:1951)
	at org.xnio.channels.Channels.writeBlocking(Channels.java:154)
	at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:184)
	at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128)
	at org.jboss.qa.management.web.resources.DataSenderServlet.doGet(DataSenderServlet.java:33)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
	at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
	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)
{noformat}



> [QE] 7.1.0 Server hanging on HP-UX when reload is initiated quickly after server was sending large amount of data
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1862
>                 URL: https://issues.jboss.org/browse/WFCORE-1862
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 2.2.0.Final
>         Environment: Noticed only on HP-UX ia64 with java version "1.8.0.04-hp-ux"
>            Reporter: Radim Hatlapatka
>            Assignee: David Lloyd
>            Priority: Blocker
>         Attachments: connector-metrics.war, duringReload.jstack, eap.jstack
>
>
> Originally reported for EAP 7.0.3.CP.CR2, still this issue is valid also for WildFly 10.1.0.Final
> Upgrade to XNIO 3.4.0.Final causes regression resulting in server hanging during reload on HP-UX in situation when servlet was sending more than 4 GB of data and suddenly reload operation is called. The reload operation doesn't finish.
> The deployment sending the data is according to log stopped, still there is visible running thread in awaitWritable \[1\].
> Note: If I use older version of XNIO => replacing XNIO 3.4.0.Final with XNIO 3.3.6.Final, it works just fine.
> Attaching eap.jstack (thread dump when arquillian tries to stop the server after reload operation timed out) and duringReload.jstack (thread dump when reload is called and it is waited for server to be reloaded) 
> \[1\]
> {noformat}
> "default task-1" #786 prio=5 os_prio=-179 tid=0x00c18000 nid=796 lwp_id=8999064 runnable [0x27cc0000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
> 	at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223)
> 	at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:84)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0x6c393e50> (a sun.nio.ch.Util$2)
> 	- locked <0x6c393e40> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0x6c393d40> (a sun.nio.ch.DevPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
> 	at org.xnio.nio.NioSocketConduit.awaitWritable(NioSocketConduit.java:233)
> 	at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
> 	at org.xnio.conduits.AbstractSinkConduit.awaitWritable(AbstractSinkConduit.java:66)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.awaitWritable(ChunkedStreamSinkConduit.java:361)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.awaitWritable(ConduitStreamSinkChannel.java:134)
> 	at io.undertow.channels.DetachableStreamSinkChannel.awaitWritable(DetachableStreamSinkChannel.java:87)
> 	at io.undertow.server.HttpServerExchange$WriteDispatchChannel.awaitWritable(HttpServerExchange.java:1951)
> 	at org.xnio.channels.Channels.writeBlocking(Channels.java:154)
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:184)
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:128)
> 	at org.jboss.qa.management.web.resources.DataSenderServlet.doGet(DataSenderServlet.java:33)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
> 	at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
> 	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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 05:59:00 2016
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 11 Oct 2016 05:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-656) while initializing
 KeystorePasswordStore an NPE is thrown instead of proper log message
In-Reply-To: <JIRA.12654170.1476179925000@Atlassian.JIRA>
References: <JIRA.12654170.1476179925000@Atlassian.JIRA>
	<JIRA.12654170.1476179925328@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654170.1476179925000.8024.1476179940825@Atlassian.JIRA>

Peter Skopek created ELY-656:
--------------------------------

             Summary: while initializing KeystorePasswordStore an NPE is thrown instead of proper log message
                 Key: ELY-656
                 URL: https://issues.jboss.org/browse/ELY-656
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
    Affects Versions: 1.1.0.Beta10
            Reporter: Peter Skopek
            Assignee: Peter Skopek


While initializing KeystorePasswordStore an NPE is thrown instead of proper log message.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 06:21:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 11 Oct 2016 06:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.8180.1476181260840@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-1313:
--------------------------------
    Attachment: heap.png


Heap after 20 incremental updates

> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 06:22:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 11 Oct 2016 06:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.8186.1476181320205@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-1313:
--------------------------------
    Comment: was deleted

(was: Heap after 20 incremental updates)


> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 06:29:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 11 Oct 2016 06:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.8235.1476181740416@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305368#comment-13305368 ] 

Mario Fusco commented on DROOLS-1313:
-------------------------------------

I changed your last reproducer adding a for loop to deploy the last 2 releases 10 times each and taking a heap dump at the end of this process as it follows 

{code}
    public static void main(String[] args) {
        System.out.println("current working dir is: " + System.getProperty("user.dir"));
        SAVE_SimpleTest4 st = new SAVE_SimpleTest4();
        st.initializeKfs();
        st.firstBuildOfRulesAndContainer();
        for (int i = 0; i < 10; i++) {
            st.secondBuildOfRulesAndContainer();
            st.thirdBuildOfRulesAndContainer();
        }
        HeapDump.dumpHeap( "heap.bin", true );
        st.done(null);
    }
{code}

To take that dump I added a specific test class among our tests: https://github.com/droolsjbpm/drools/blob/master/drools-core/src/test/java/org/drools/core/util/HeapDump.java

Regardless of how many loops I do, I always see only 2 instances of that PackageClassLoader class on my heap (see the screenshot I attached) and this confirms my first impression that we don't have any leak here.

Consider that I tested this against our master. Please use a newer drools version (6.5.0.Final should be available before the end of this week) and try to do the same.

> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 06:30:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 11 Oct 2016 06:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.8238.1476181800547@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1313.
---------------------------------
    Resolution: Cannot Reproduce Bug


> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 06:32:00 2016
From: issues at jboss.org (Maciej Swiderski (JIRA))
Date: Tue, 11 Oct 2016 06:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1324) CNFE when stopping server
 with enabled scanner
In-Reply-To: <JIRA.12654096.1476173560000@Atlassian.JIRA>
References: <JIRA.12654096.1476173560000@Atlassian.JIRA>
	<JIRA.12654096.1476173560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654096.1476173560000.8252.1476181920458@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maciej Swiderski reassigned DROOLS-1324:
----------------------------------------

    Assignee: Petr ?irok?  (was: Maciej Swiderski)


> CNFE when stopping server with enabled scanner
> ----------------------------------------------
>
>                 Key: DROOLS-1324
>                 URL: https://issues.jboss.org/browse/DROOLS-1324
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.5.0.CR2, 7.0.0.Beta2
>         Environment: Kie server 6.5.0-SNAPSHOT
>            Reporter: Karel Suta
>            Assignee: Petr ?irok?
>            Priority: Minor
>              Labels: reported-by-qe
>         Attachments: stacktrace-server.txt
>
>
> When I stop application server with Kie server containing container with started scanner, sometimes I get ClassNotFoundException, see attachment.
> This exception doesn't seem to have any affect on functionality, but still it should be resolved as it may hide some other problem.
> This exception occurs randomly, you may need to start/stop server several times to see it.
> Interesting is that class, which wasn't found by classloader, is actually present in Kie server in artefact sisu-guice-3.2.3-no_aop.jar.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 11 06:32:00 2016
From: issues at jboss.org (Maciej Swiderski (JIRA))
Date: Tue, 11 Oct 2016 06:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1324) CNFE when stopping server
 with enabled scanner
In-Reply-To: <JIRA.12654096.1476173560000@Atlassian.JIRA>
References: <JIRA.12654096.1476173560000@Atlassian.JIRA>
	<JIRA.12654096.1476173560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654096.1476173560000.8248.1476181920318@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305370#comment-13305370 ] 

Maciej Swiderski commented on DROOLS-1324:
------------------------------------------

I believe we need to first stop scanner before stopping container to avoid this kind of errors as we might be leaving scanner still running there until it fails and kills the timer thread.

> CNFE when stopping server with enabled scanner
> ----------------------------------------------
>
>                 Key: DROOLS-1324
>                 URL: https://issues.jboss.org/browse/DROOLS-1324
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.5.0.CR2, 7.0.0.Beta2
>         Environment: Kie server 6.5.0-SNAPSHOT
>            Reporter: Karel Suta
>            Assignee: Maciej Swiderski
>            Priority: Minor
>              Labels: reported-by-qe
>         Attachments: stacktrace-server.txt
>
>
> When I stop application server with Kie server containing container with started scanner, sometimes I get ClassNotFoundException, see attachment.
> This exception doesn't seem to have any affect on functionality, but still it should be resolved as it may hide some other problem.
> This exception occurs randomly, you may need to start/stop server several times to see it.
> Interesting is that class, which wasn't found by classloader, is actually present in Kie server in artefact sisu-guice-3.2.3-no_aop.jar.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 06:40:00 2016
From: issues at jboss.org (Maciej Swiderski (JIRA))
Date: Tue, 11 Oct 2016 06:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1268) When using the
 RuleServicesClient for a remote rest interface,
 get the following error java.io.EOFException: No content to map to Object
 due to end of input
In-Reply-To: <JIRA.12644723.1472115177000@Atlassian.JIRA>
References: <JIRA.12644723.1472115177000@Atlassian.JIRA>
	<JIRA.12644723.1472115177000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644723.1472115177000.8335.1476182400414@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305381#comment-13305381 ] 

Maciej Swiderski commented on DROOLS-1268:
------------------------------------------

any update on this or we can close it?

> When using the RuleServicesClient for a remote rest interface,  get the following error java.io.EOFException: No content to map to Object due to end of input
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1268
>                 URL: https://issues.jboss.org/browse/DROOLS-1268
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Maciej Swiderski
>              Labels: OnBoarding
>         Attachments: logerror.txt, picture1.png
>
>
> here is the JSON http://pastebin.com/t1CdHg9F
> The logs are in the file attached logerror.txt
> Going further
> the error comes from class org.kie.remote.common.rest.KieRemoteHttpRequest line 1329
> and the error behind is "not enough data"
> I put in attachement and it seems true



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:12:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 11 Oct 2016 08:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7284) group-properties can be added
 without path in Elytron properties-realm which results to invalid server
 configuration
In-Reply-To: <JIRA.12654202.1476187869000@Atlassian.JIRA>
References: <JIRA.12654202.1476187869000@Atlassian.JIRA>
	<JIRA.12654202.1476187869275@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654202.1476187869000.9083.1476187920458@Atlassian.JIRA>

Ondrej Lukas created WFLY-7284:
----------------------------------

             Summary: group-properties can be added without path in Elytron properties-realm which results to invalid server configuration
                 Key: WFLY-7284
                 URL: https://issues.jboss.org/browse/WFLY-7284
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


Adding {{groups-properties}} without {{path}} through CLI is allowed by Elytron subsystem which results to XMLStreamException after server is reloaded/restarted.

Exception in server log after reload/restart:
{code}
ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
	at org.jboss.as.server.ServerService.boot(ServerService.java:355)
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[345,21]
Message: WFLYCTL0133: Missing required attribute(s): path
	at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:180)
	at org.wildfly.extension.elytron.RealmParser.readFileAttributes(RealmParser.java:522)
	at org.wildfly.extension.elytron.RealmParser.readPropertiesRealm(RealmParser.java:337)
	at org.wildfly.extension.elytron.RealmParser.readRealms(RealmParser.java:118)
	at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:114)
	at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:72)
	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
	at org.jboss.as.server.parsing.StandaloneXml_5.parseServerProfile(StandaloneXml_5.java:591)
	at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:245)
	at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144)
	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
	... 3 more
FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:12:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 11 Oct 2016 08:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7284) group-properties can be added
 without path in Elytron properties-realm which results to invalid server
 configuration
In-Reply-To: <JIRA.12654202.1476187869000@Atlassian.JIRA>
References: <JIRA.12654202.1476187869000@Atlassian.JIRA>
	<JIRA.12654202.1476187869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654202.1476187869000.9093.1476187920794@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7284:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> group-properties can be added without path in Elytron properties-realm which results to invalid server configuration
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7284
>                 URL: https://issues.jboss.org/browse/WFLY-7284
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> Adding {{groups-properties}} without {{path}} through CLI is allowed by Elytron subsystem which results to XMLStreamException after server is reloaded/restarted.
> Exception in server log after reload/restart:
> {code}
> ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:355)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[345,21]
> Message: WFLYCTL0133: Missing required attribute(s): path
> 	at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:180)
> 	at org.wildfly.extension.elytron.RealmParser.readFileAttributes(RealmParser.java:522)
> 	at org.wildfly.extension.elytron.RealmParser.readPropertiesRealm(RealmParser.java:337)
> 	at org.wildfly.extension.elytron.RealmParser.readRealms(RealmParser.java:118)
> 	at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:114)
> 	at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:72)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml_5.parseServerProfile(StandaloneXml_5.java:591)
> 	at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:245)
> 	at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> 	... 3 more
> FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:14:01 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 11 Oct 2016 08:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2110) Transport: revisit buffers
	and threading
In-Reply-To: <JIRA.12653915.1476027787000@Atlassian.JIRA>
References: <JIRA.12653915.1476027787000@Atlassian.JIRA>
	<JIRA.12653915.1476027787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653915.1476027787000.9113.1476188041356@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305457#comment-13305457 ] 

Bela Ban commented on JGRP-2110:
--------------------------------

Moving the parsing to the thread pool did *not* improve performance (UPerf, IspnPerfTest on cluster01-04). As a matter of fact, performance dropped slightly (~3-5%, with TCP)!

Next step: use a buffer pool and refer to the buffer from Message.buf (+offset +length). Release the buffer when the message has been delivered.

Complication for MessageBatch: release the buffer when all batches (read from a message list) have been delivered.


> Transport: revisit buffers and threading
> ----------------------------------------
>
>                 Key: JGRP-2110
>                 URL: https://issues.jboss.org/browse/JGRP-2110
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> (Concerns only the receiver side)
> h4. Parsing
> Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
> This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
> h4. Buffers
> * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
> * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
> * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
> h4. Approaches
> # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
> # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
> # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
> # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
> h4. Goals
> Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:14:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 11 Oct 2016 08:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7285) Elytron - inconsistency
 between DMR and XSD representation of simple-permission-mapper
In-Reply-To: <JIRA.12654204.1476188032000@Atlassian.JIRA>
References: <JIRA.12654204.1476188032000@Atlassian.JIRA>
	<JIRA.12654204.1476188032719@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654204.1476188032000.9131.1476188041753@Atlassian.JIRA>

Ondrej Lukas created WFLY-7285:
----------------------------------

             Summary: Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper
                 Key: WFLY-7285
                 URL: https://issues.jboss.org/browse/WFLY-7285
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Optional


There are inconsistencies between DMR and XSD representation of {{simple-permission-mapper}}.

According to XSD both {{permission-mapping}} [1] and its inner {{permission}} [2] must occur at least one times in {{simple-permission-mapper}}. According to DMR they are {{"nillable" => true}}. This should be unified.

[1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1513
[2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1516



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:14:02 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 11 Oct 2016 08:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7285) Elytron - inconsistency
 between DMR and XSD representation of simple-permission-mapper
In-Reply-To: <JIRA.12654204.1476188033000@Atlassian.JIRA>
References: <JIRA.12654204.1476188033000@Atlassian.JIRA>
	<JIRA.12654204.1476188033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654204.1476188033000.9140.1476188042233@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7285:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-7285
>                 URL: https://issues.jboss.org/browse/WFLY-7285
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Optional
>
> There are inconsistencies between DMR and XSD representation of {{simple-permission-mapper}}.
> According to XSD both {{permission-mapping}} [1] and its inner {{permission}} [2] must occur at least one times in {{simple-permission-mapper}}. According to DMR they are {{"nillable" => true}}. This should be unified.
> [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1513
> [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1516



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:16:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 11 Oct 2016 08:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7286) Elytron - inconsistency
 between DMR and XSD representation of
 mechanism-provider-filtering-sasl-server-factory
In-Reply-To: <JIRA.12654207.1476188153000@Atlassian.JIRA>
References: <JIRA.12654207.1476188153000@Atlassian.JIRA>
	<JIRA.12654207.1476188153385@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654207.1476188153000.9184.1476188160807@Atlassian.JIRA>

Ondrej Lukas created WFLY-7286:
----------------------------------

             Summary: Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory
                 Key: WFLY-7286
                 URL: https://issues.jboss.org/browse/WFLY-7286
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Optional


There is an inconsistency between DMR and XSD representation of {{mechanism-provider-filtering-sasl-server-factory}}.

According to XSD [1] {{filters}} may not occur in {{mechanism-provider-filtering-sasl-server-factory}}. According to DMR {{filters}} is {{"nillable" => false}}. This should be unified.

[1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L2734



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:16:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 11 Oct 2016 08:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7286) Elytron - inconsistency
 between DMR and XSD representation of
 mechanism-provider-filtering-sasl-server-factory
In-Reply-To: <JIRA.12654207.1476188153000@Atlassian.JIRA>
References: <JIRA.12654207.1476188153000@Atlassian.JIRA>
	<JIRA.12654207.1476188153000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654207.1476188153000.9193.1476188161271@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7286:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7286
>                 URL: https://issues.jboss.org/browse/WFLY-7286
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Optional
>
> There is an inconsistency between DMR and XSD representation of {{mechanism-provider-filtering-sasl-server-factory}}.
> According to XSD [1] {{filters}} may not occur in {{mechanism-provider-filtering-sasl-server-factory}}. According to DMR {{filters}} is {{"nillable" => false}}. This should be unified.
> [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L2734



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:21:02 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 11 Oct 2016 08:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7287) User should be able to
 specify only one password mapper in jdbc-realm resource
In-Reply-To: <JIRA.12654212.1476188423000@Atlassian.JIRA>
References: <JIRA.12654212.1476188423000@Atlassian.JIRA>
	<JIRA.12654212.1476188423000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654212.1476188423000.9297.1476188462532@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6384 to WFLY-7287:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7287  (was: JBEAP-6384)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> User should be able to specify only one password mapper in jdbc-realm resource
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7287
>                 URL: https://issues.jboss.org/browse/WFLY-7287
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Pedro Igor
>            Priority: Minor
>
> It is possible to specify in {{principal-query}} all of {{clear-password-mapper}}, {{bcrypt-mapper}}, {{simple-digest-mapper}}, {{salted-simple-digest-mapper}}, {{scram-mapper}} at one moment. But, in fact, specifying only one mapper per principal query make sense. Change model/subsystem , that only adding on password mapper at a moment is allowed.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:22:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 11 Oct 2016 08:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7288) Elytron - inconsistency
 between DMR and XSD representation of ldap-realm
In-Reply-To: <JIRA.12654214.1476188470000@Atlassian.JIRA>
References: <JIRA.12654214.1476188470000@Atlassian.JIRA>
	<JIRA.12654214.1476188470412@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654214.1476188470000.9350.1476188521306@Atlassian.JIRA>

Ondrej Lukas created WFLY-7288:
----------------------------------

             Summary: Elytron - inconsistency between DMR and XSD representation of ldap-realm
                 Key: WFLY-7288
                 URL: https://issues.jboss.org/browse/WFLY-7288
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Optional


There are inconsistencies between DMR and XSD representation of ldap-realm.

* According to XSD [1] {{from}} attribute from user-password-mapper is required in ldap-realm. According to DMR {{from}} attribute is {{"nillable" => true}}.
* According to XSD [2] every attribute ({{algorithm-from}}, {{hash-from}}, {{seed-from}}, {{sequence-from}}) from otp-credential-mapper is required in ldap-realm. According to DMR all these attributes are {{"nillable" => true}}.
* According to XSD [3] {{name}} of {{attribute}} from new-identity-attributes is required in ldap-realm. According to DMR {{name}} of {{attribute}} is {{"nillable" => true}}.

These inconsistencies should be unified.

[1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1008
[2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1031
[3] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1079



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:22:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 11 Oct 2016 08:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7288) Elytron - inconsistency
 between DMR and XSD representation of ldap-realm
In-Reply-To: <JIRA.12654214.1476188470000@Atlassian.JIRA>
References: <JIRA.12654214.1476188470000@Atlassian.JIRA>
	<JIRA.12654214.1476188470000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654214.1476188470000.9364.1476188521905@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7288:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Elytron - inconsistency between DMR and XSD representation of ldap-realm
> ------------------------------------------------------------------------
>
>                 Key: WFLY-7288
>                 URL: https://issues.jboss.org/browse/WFLY-7288
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Optional
>
> There are inconsistencies between DMR and XSD representation of ldap-realm.
> * According to XSD [1] {{from}} attribute from user-password-mapper is required in ldap-realm. According to DMR {{from}} attribute is {{"nillable" => true}}.
> * According to XSD [2] every attribute ({{algorithm-from}}, {{hash-from}}, {{seed-from}}, {{sequence-from}}) from otp-credential-mapper is required in ldap-realm. According to DMR all these attributes are {{"nillable" => true}}.
> * According to XSD [3] {{name}} of {{attribute}} from new-identity-attributes is required in ldap-realm. According to DMR {{name}} of {{attribute}} is {{"nillable" => true}}.
> These inconsistencies should be unified.
> [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1008
> [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1031
> [3] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1079



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:25:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 11 Oct 2016 08:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to add trust-manager
 with ldap-key-store (classloading)
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.9398.1476188700527@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305470#comment-13305470 ] 

Jan Kalina commented on WFLY-7278:
----------------------------------

Mentioned by Martin Chroma: The same exception will occure also if follows:
1. add ldap-key-store 2. remove ldap-key-store

> Unable to add trust-manager with ldap-key-store (classloading)
> --------------------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:40:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Oct 2016 08:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7178) Review empty-role-decoder
 resource in Elytron subsystem
In-Reply-To: <JIRA.12651209.1474462913000@Atlassian.JIRA>
References: <JIRA.12651209.1474462913000@Atlassian.JIRA>
	<JIRA.12651209.1474462913000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651209.1474462913000.9626.1476189601761@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7178:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Review empty-role-decoder resource in Elytron subsystem
> -------------------------------------------------------
>
>                 Key: WFLY-7178
>                 URL: https://issues.jboss.org/browse/WFLY-7178
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> We have an empty-role-decoder resource but it is a bit pointless really as it contains no configuration.
> Instead I think all references to role-decoder should be optional and where there is no reference to a role decoder we automatically use the empty implementation instead.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:40:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Oct 2016 08:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7178) Review empty-role-decoder
 resource in Elytron subsystem
In-Reply-To: <JIRA.12651209.1474462913000@Atlassian.JIRA>
References: <JIRA.12651209.1474462913000@Atlassian.JIRA>
	<JIRA.12651209.1474462913000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651209.1474462913000.9640.1476189602534@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7178:
-----------------------------------
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Review empty-role-decoder resource in Elytron subsystem
> -------------------------------------------------------
>
>                 Key: WFLY-7178
>                 URL: https://issues.jboss.org/browse/WFLY-7178
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Alpha1
>
>
> We have an empty-role-decoder resource but it is a bit pointless really as it contains no configuration.
> Instead I think all references to role-decoder should be optional and where there is no reference to a role decoder we automatically use the empty implementation instead.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:46:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 11 Oct 2016 08:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7289) Adding ldap-key-store
 requires accessible ldap server
In-Reply-To: <JIRA.12654219.1476189896000@Atlassian.JIRA>
References: <JIRA.12654219.1476189896000@Atlassian.JIRA>
	<JIRA.12654219.1476189896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654219.1476189896000.9771.1476189960954@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6388 to WFLY-7289:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7289  (was: JBEAP-6388)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Adding ldap-key-store requires accessible ldap server
> -----------------------------------------------------
>
>                 Key: WFLY-7289
>                 URL: https://issues.jboss.org/browse/WFLY-7289
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>
> Playing with ldap-key-store . What I consider very unconvenient is fact, that in moment of adding ldap-key-store, ldap server has to be running and accessible. Elytron ldap-realm does not need that. Doubt about legacy security realms. Is it possible to decouple that dependency and leave that check till first ldap-key-store usage?
> Steps to reproduce:
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=a:add()
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=a:add(dir-context=a, search-path="a")
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> {code}
> leads to exception in server log
> {code}
> 14:37:25,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
>     "address" => [
>         ("subsystem" => "elytron"),
>         ("ldap-key-store" => "a")
>     ],
>     "operation" => "add",
>     "search-path" => "a",
>     "dir-context" => "a",
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE"
>     }
> }]: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildTypes(AbstractModelResource.java:372)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:787)
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:520)
> 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:758)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:709)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: Cannot parse url: undefined [Root exception is java.net.MalformedURLException: Invalid URI: undefined]
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:92)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:163)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 39 more
> Caused by: java.net.MalformedURLException: Invalid URI: undefined
> 	at com.sun.jndi.toolkit.url.Uri.parse(Uri.java:199)
> 	at com.sun.jndi.toolkit.url.Uri.init(Uri.java:138)
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:82)
> 	... 56 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 08:48:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Oct 2016 08:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7255) Creating LDAP security realm
 fails with cryptic error message
In-Reply-To: <JIRA.12652320.1475003617000@Atlassian.JIRA>
References: <JIRA.12652320.1475003617000@Atlassian.JIRA>
	<JIRA.12652320.1475003617000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652320.1475003617000.9808.1476190081167@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7255:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
>                 Key: WFLY-7255
>                 URL: https://issues.jboss.org/browse/WFLY-7255
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Zach Rhoads
>            Assignee: Jan Kalina
>             Fix For: 11.0.0.Alpha1
>
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
>     "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> 	at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 09:00:03 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 11 Oct 2016 09:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7290) Unable to remove elytron
	ldap-key-store
In-Reply-To: <JIRA.12654226.1476190726000@Atlassian.JIRA>
References: <JIRA.12654226.1476190726000@Atlassian.JIRA>
	<JIRA.12654226.1476190726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654226.1476190726000.10023.1476190803715@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6390 to WFLY-7290:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7290  (was: JBEAP-6390)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Unable to remove elytron ldap-key-store
> ---------------------------------------
>
>                 Key: WFLY-7290
>                 URL: https://issues.jboss.org/browse/WFLY-7290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Critical
>
> Once ldap-key-store is added it can't be removed.
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=b:add(url=ldap://dev156-w2012-x86-64.mw.lab.eng.bos.redhat.com, principal="CN=jbossqa,CN=Users,DC=JBOSS3,DC=test", credential=jboss42)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:add(dir-context=b,search-path="O=eapqe,DC=JBOSS3,DC=test")
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:remove()
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
>     "rolled-back" => true
> }
> {code}
> which leads to error in server log
> {code}
> 14:55:41,841 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 12) WFLYCTL0013: Operation ("remove") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-key-store" => "b")
> ]): java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.AbstractRemoveStepHandler.execute(AbstractRemoveStepHandler.java:66)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 31 more
> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 09:09:01 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 11 Oct 2016 09:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6882) A client is not able to
 invoke EJB's deployed as "HASingleton deployment"
In-Reply-To: <JIRA.12640877.1469626112000@Atlassian.JIRA>
References: <JIRA.12640877.1469626112000@Atlassian.JIRA>
	<JIRA.12640877.1469626112000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640877.1469626112000.10138.1476191341157@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-6882.
------------------------------
    Resolution: Rejected


> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
>                 Key: WFLY-6882
>                 URL: https://issues.jboss.org/browse/WFLY-6882
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Enrique Gonz?lez Mart?nez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 11 09:17:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Oct 2016 09:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7137) Attribute "required" on
 key-store makes no difference of behaviour
In-Reply-To: <JIRA.12650636.1474272442000@Atlassian.JIRA>
References: <JIRA.12650636.1474272442000@Atlassian.JIRA>
	<JIRA.12650636.1474272442000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650636.1474272442000.10367.1476191821058@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7137:
-----------------------------------
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Attribute "required" on key-store makes no difference of behaviour
> ------------------------------------------------------------------
>
>                 Key: WFLY-7137
>                 URL: https://issues.jboss.org/browse/WFLY-7137
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> There is attribute {{required}} which can be set on key-store, that should disable check "does keystore file exists?"
> {code}
> "required" => {
>     "type" => BOOLEAN,
>     "description" => "Is the file required to exist at the time the KeyStore service starts?",
>     "attribute-group" => "file",
>     "expressions-allowed" => true,
>     "nillable" => true,
>     "default" => false,
>     "requires" => ["path"],
>     "access-type" => "read-write",
>     "storage" => "configuration",
>     "restart-required" => "resource-services"
> },
> {code}
> However, when I try to use it, there is no difference if  {{required}} attribute is set to true or false.
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=false)
> {
>     "outcome" => "failed",
>     "failure-description" => {
>         "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service.
>     Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"},
>         "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"],
>         "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
>     },
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=true)
> {
>     "outcome" => "failed",
>     "failure-description" => {
>         "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service.
>     Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"},
>         "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"],
>         "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
>     },
>     "rolled-back" => true
> }
> {code}
> I have already seen people generating keystores in their app, so I think this option would be useful for them.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 09:17:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Oct 2016 09:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7137) Attribute "required" on
 key-store makes no difference of behaviour
In-Reply-To: <JIRA.12650636.1474272442000@Atlassian.JIRA>
References: <JIRA.12650636.1474272442000@Atlassian.JIRA>
	<JIRA.12650636.1474272442000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650636.1474272442000.10377.1476191821565@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7137:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Attribute "required" on key-store makes no difference of behaviour
> ------------------------------------------------------------------
>
>                 Key: WFLY-7137
>                 URL: https://issues.jboss.org/browse/WFLY-7137
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> There is attribute {{required}} which can be set on key-store, that should disable check "does keystore file exists?"
> {code}
> "required" => {
>     "type" => BOOLEAN,
>     "description" => "Is the file required to exist at the time the KeyStore service starts?",
>     "attribute-group" => "file",
>     "expressions-allowed" => true,
>     "nillable" => true,
>     "default" => false,
>     "requires" => ["path"],
>     "access-type" => "read-write",
>     "storage" => "configuration",
>     "restart-required" => "resource-services"
> },
> {code}
> However, when I try to use it, there is no difference if  {{required}} attribute is set to true or false.
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=false)
> {
>     "outcome" => "failed",
>     "failure-description" => {
>         "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service.
>     Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"},
>         "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"],
>         "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
>     },
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=true)
> {
>     "outcome" => "failed",
>     "failure-description" => {
>         "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service.
>     Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"},
>         "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"],
>         "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
>     },
>     "rolled-back" => true
> }
> {code}
> I have already seen people generating keystores in their app, so I think this option would be useful for them.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 09:30:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Oct 2016 09:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7219) Wrong description of missing
 target-name in simple-permission-mapper
In-Reply-To: <JIRA.12651417.1474532622000@Atlassian.JIRA>
References: <JIRA.12651417.1474532622000@Atlassian.JIRA>
	<JIRA.12651417.1474532622000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651417.1474532622000.10494.1476192601497@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7219:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Wrong description of missing target-name in simple-permission-mapper
> --------------------------------------------------------------------
>
>                 Key: WFLY-7219
>                 URL: https://issues.jboss.org/browse/WFLY-7219
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>             Fix For: 11.0.0.Alpha1
>
>
> In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null".



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 09:47:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Oct 2016 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in elytron model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.10685.1476193621392@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7260:
-----------------------------------
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 09:47:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 11 Oct 2016 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7260) Document in elytron model
 *-client-auth are mutual exclusive
In-Reply-To: <JIRA.12653107.1475572508000@Atlassian.JIRA>
References: <JIRA.12653107.1475572508000@Atlassian.JIRA>
	<JIRA.12653107.1475572508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653107.1475572508000.10695.1476193621624@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7260:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
>                 Key: WFLY-7260
>                 URL: https://issues.jboss.org/browse/WFLY-7260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 10:07:00 2016
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 11 Oct 2016 10:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1863) Make CredentialReference
	thread safe
In-Reply-To: <JIRA.12654256.1476194771000@Atlassian.JIRA>
References: <JIRA.12654256.1476194771000@Atlassian.JIRA>
	<JIRA.12654256.1476194771862@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654256.1476194771000.10906.1476194820462@Atlassian.JIRA>

Peter Skopek created WFCORE-1863:
------------------------------------

             Summary: Make CredentialReference thread safe
                 Key: WFCORE-1863
                 URL: https://issues.jboss.org/browse/WFCORE-1863
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Security
    Affects Versions: 3.0.0.Alpha9
            Reporter: Peter Skopek
            Assignee: Peter Skopek


CredentialReference is not thread safe nor documented that fact.
  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 10:15:01 2016
From: issues at jboss.org (Nicolas Heron (JIRA))
Date: Tue, 11 Oct 2016 10:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1268) When using the
 RuleServicesClient for a remote rest interface,
 get the following error java.io.EOFException: No content to map to Object
 due to end of input
In-Reply-To: <JIRA.12644723.1472115177000@Atlassian.JIRA>
References: <JIRA.12644723.1472115177000@Atlassian.JIRA>
	<JIRA.12644723.1472115177000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644723.1472115177000.11012.1476195301469@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305615#comment-13305615 ] 

Nicolas Heron commented on DROOLS-1268:
---------------------------------------

no update
I will try to build a reproducer

> When using the RuleServicesClient for a remote rest interface,  get the following error java.io.EOFException: No content to map to Object due to end of input
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1268
>                 URL: https://issues.jboss.org/browse/DROOLS-1268
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.4.0.Final
>            Reporter: Nicolas Heron
>            Assignee: Maciej Swiderski
>              Labels: OnBoarding
>         Attachments: logerror.txt, picture1.png
>
>
> here is the JSON http://pastebin.com/t1CdHg9F
> The logs are in the file attached logerror.txt
> Going further
> the error comes from class org.kie.remote.common.rest.KieRemoteHttpRequest line 1329
> and the error behind is "not enough data"
> I put in attachement and it seems true



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 10:24:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 11 Oct 2016 10:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1325) JPAKnowledgeService session
 does not support mbeans
In-Reply-To: <JIRA.12654260.1476195790000@Atlassian.JIRA>
References: <JIRA.12654260.1476195790000@Atlassian.JIRA>
	<JIRA.12654260.1476195790947@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654260.1476195790000.11058.1476195840586@Atlassian.JIRA>

Matteo Mortari created DROOLS-1325:
--------------------------------------

             Summary: JPAKnowledgeService session does not support mbeans
                 Key: DROOLS-1325
                 URL: https://issues.jboss.org/browse/DROOLS-1325
             Project: Drools
          Issue Type: Bug
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 11:13:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 11 Oct 2016 11:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5542) Look into using apache's
	upstream JSTL
In-Reply-To: <JIRA.12589570.1445255749000@Atlassian.JIRA>
References: <JIRA.12589570.1445255749000@Atlassian.JIRA>
	<JIRA.12589570.1445255749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589570.1445255749000.11550.1476198780281@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305666#comment-13305666 ] 

Radim Hatlapatka commented on WFLY-5542:
----------------------------------------

I agree with [~ctomc] that it is better to use secure by default. I believe to achieve some behavior you might need to set secure to false (operation which are not by default safe). Those features required user to know what he is doing as he can be more easily exposed to some attacks (I believe allowing to use some external includes or something similar). I am OK with this change, if such use case is found valid, it can be easily solved by adding system property allowing to switch the secure to false.

> Look into using apache's upstream JSTL
> --------------------------------------
>
>                 Key: WFLY-5542
>                 URL: https://issues.jboss.org/browse/WFLY-5542
>             Project: WildFly
>          Issue Type: Task
>          Components: EE, Web (Undertow)
>    Affects Versions: 10.0.0.CR2
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> We are now using forked combination of apache & java.net's version of JSTL.
> We should look into using upstream version if possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 14:02:00 2016
From: issues at jboss.org (Bill Tuminaro (JIRA))
Date: Tue, 11 Oct 2016 14:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.12029.1476208920247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Tuminaro reopened DROOLS-1313:
-----------------------------------


I followed your code suggestion and added the loop 10 times to main. I see results that are similar to yours, memory usage does not seem to grow incrementally. THANK YOU !!

Now, I am back to my original question. Our code is written similar to the 1st reproducer I attached (SAVE_SimpleTest.java) which uses a different approach than the other code (SAVE_SimpleTest4.java).  Basically the 1st reproducer uses a single releaseId and a single KieFileSystem.  It just changes the contents of the file system and does an incremental build.  I added the code to remove the old module "KieServices.Factory.get().getRepository().removeKieModule(  )", however it seems memory continues to grow using this approach.

What is the correct way to make incremental changes to a KieFileSystem and use ((InternalKieBuilder) kb ).incrementalBuild() to build it?  BTW, we use stateful sessions and are trying to keep the state intact between builds.


> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 14:03:00 2016
From: issues at jboss.org (Bill Tuminaro (JIRA))
Date: Tue, 11 Oct 2016 14:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.12032.1476208980092@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305721#comment-13305721 ] 

Bill Tuminaro commented on DROOLS-1313:
---------------------------------------

In my last round of testing, I used Drools 6.3.0.final and Drools 6.5.0CR2 - the results are the same.
-BillT


> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 14:18:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 11 Oct 2016 14:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.12045.1476209880192@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305723#comment-13305723 ] 

Mario Fusco commented on DROOLS-1313:
-------------------------------------

What I think it is not supported or anyway incorrect is keep reusing the same releaseId. Drools 6.x has been designed with a maven-like approach and you cannot deploy 2 artifacts with the same releaseId on a maven repository. To be honest I'm also surprised that the incremental compilation keeps working in that case and I'd need to debug your first reproducer to figure out why it is working even if I didn't expect this (and of course I cannot guarantee it will work in future).

> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 14:33:00 2016
From: issues at jboss.org (Bill Tuminaro (JIRA))
Date: Tue, 11 Oct 2016 14:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.12080.1476210780088@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305729#comment-13305729 ] 

Bill Tuminaro commented on DROOLS-1313:
---------------------------------------

We never have 2 artifacts with the same releaseId in the file system.  When a rule changes, we always delete the existing file and increment/change the file name for the new rule (essentially write a new file).

I understand we probably have to change our approach, however, I am trying to understand what to change to.  

What is the correct way to make incremental changes to a KieFileSystem and use ((InternalKieBuilder) kb ).incrementalBuild() to build it? 

One approach would be to make a duplicate of the entire original file system then make modifications to the newly created file system, build it and update to it, however, I think/hope there is a more efficient way to do this that takes advantage of   ((InternalKieBuilder) kb ).incrementalBuild().


> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 18:37:00 2016
From: issues at jboss.org (George Gastaldi (JIRA))
Date: Tue, 11 Oct 2016 18:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7291)
 InfinispanCacheDeploymentListener throws ServiceNotFoundException when
 stopping
In-Reply-To: <JIRA.12654317.1476225371000@Atlassian.JIRA>
References: <JIRA.12654317.1476225371000@Atlassian.JIRA>
	<JIRA.12654317.1476225371571@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654317.1476225371000.12574.1476225420122@Atlassian.JIRA>

George Gastaldi created WFLY-7291:
-------------------------------------

             Summary: InfinispanCacheDeploymentListener throws ServiceNotFoundException when stopping
                 Key: WFLY-7291
                 URL: https://issues.jboss.org/browse/WFLY-7291
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 10.1.0.Final
            Reporter: George Gastaldi
            Assignee: Scott Marlow
         Attachments: demosrc.zip

Deploying a WAR produced by the attached project produces the following error in the logs when shutting down the server: 

{code}
[ERROR [org.jboss.as.jpa] (ServerService Thread Pool -- 38) WFLYJPA0007: Failed to stop persistence unit service demo.war#primary: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.hibernate."demo.war#primary" not found
    at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:669)
    at org.jboss.as.jpa.processor.secondLevelCache.InfinispanCacheDeploymentListener.stopCache(InfinispanCacheDeploymentListener.java:144)
    at org.jboss.as.jpa.processor.secondLevelCache.CacheDeploymentListener.stopCache(CacheDeploymentListener.java:96)
    at org.jipijapa.event.impl.internal.Notification.stopCache(Notification.java:107)
    at org.jboss.as.jpa.hibernate5.infinispan.InfinispanRegionFactory.stopCacheManager(InfinispanRegionFactory.java:80)
    at org.hibernate.cache.infinispan.InfinispanRegionFactory.stop(InfinispanRegionFactory.java:443)
    at org.hibernate.internal.CacheImpl.close(CacheImpl.java:266)
    at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1074)
    at org.hibernate.jpa.internal.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:347)
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2$1.run(PersistenceUnitServiceImpl.java:237)
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2$1.run(PersistenceUnitServiceImpl.java:217)
    at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2.run(PersistenceUnitServiceImpl.java:262)
    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)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 19:08:00 2016
From: issues at jboss.org (Bill Tuminaro (JIRA))
Date: Tue, 11 Oct 2016 19:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.12624.1476227280161@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305802#comment-13305802 ] 

Bill Tuminaro commented on DROOLS-1313:
---------------------------------------


I found a way to easily clone an existing KieFileSystem:
		MemoryFileSystem mfs = ((KieFileSystemImpl)kfs).asMemoryFileSystem().clone();
		KieFileSystem newKfs = new KieFileSystemImpl(mfs);
		KieBuilder newKb = ks.newKieBuilder(newKfs);
		updateTo = "1.0." + ver++;
		newReleaseId = ks.newReleaseId(pkgName, artifactId, updateTo);
		newKfs.generateAndWritePomXML(newReleaseId);
                ........
		newKb.buildAll();
		KieModule newModule = newKb.getKieModule();
		ReleaseId ri = newModule.getReleaseId();
		Results r = kContainer.updateToVersion( ri );

I can then make modifications to the new KieFileSystem and use this new KieBuilder to build it and then update to it.

I've attached a reproducer (SAVE_SimpleTest5.java)that uses this approach, memory does not grow and the rules are present in the module.

Is this a supported approach? Would stateful session keep their state through the updateToVersion() calls?

-BillT

> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 11 19:09:00 2016
From: issues at jboss.org (Bill Tuminaro (JIRA))
Date: Tue, 11 Oct 2016 19:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.12627.1476227340115@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Tuminaro updated DROOLS-1313:
----------------------------------
    Attachment: SAVE_SimpleTest5.java


> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SAVE_SimpleTest5.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 02:15:01 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 12 Oct 2016 02:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7290) Unable to remove elytron
	ldap-key-store
In-Reply-To: <JIRA.12654226.1476190726000@Atlassian.JIRA>
References: <JIRA.12654226.1476190726000@Atlassian.JIRA>
	<JIRA.12654226.1476190726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654226.1476190726000.12819.1476252901258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-7290:
-------------------------------
    Description: 
Once ldap-key-store is added it can't be removed.

{code}
[standalone at localhost:9990 /] /subsystem=elytron/dir-context=b:add(url=ldap://localhost, principal="CN=user,DC=wildfly,DC=org", credential=password)
{"outcome" => "success"}
[standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:add(dir-context=b,search-path="DC=wildfly,DC=org")
{"outcome" => "success"}
[standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:remove()
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
    "rolled-back" => true
}
{code}

which leads to error in server log

{code}
14:55:41,841 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 12) WFLYCTL0013: Operation ("remove") failed - address: ([
    ("subsystem" => "elytron"),
    ("ldap-key-store" => "b")
]): java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
	at java.security.KeyStore.size(KeyStore.java:1271)
	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
	at java.security.KeyStore.size(KeyStore.java:1271)
	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
	at org.jboss.as.controller.AbstractRemoveStepHandler.execute(AbstractRemoveStepHandler.java:66)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
	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)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]]
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
	at javax.naming.InitialContext.init(InitialContext.java:244)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
	... 31 more
Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
	... 43 more
{code}

  was:
Once ldap-key-store is added it can't be removed.

{code}
[standalone at localhost:9990 /] /subsystem=elytron/dir-context=b:add(url=ldap://dev156-w2012-x86-64.mw.lab.eng.bos.redhat.com, principal="CN=jbossqa,CN=Users,DC=JBOSS3,DC=test", credential=jboss42)
{"outcome" => "success"}
[standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:add(dir-context=b,search-path="O=eapqe,DC=JBOSS3,DC=test")
{"outcome" => "success"}
[standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:remove()
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
    "rolled-back" => true
}
{code}

which leads to error in server log

{code}
14:55:41,841 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 12) WFLYCTL0013: Operation ("remove") failed - address: ([
    ("subsystem" => "elytron"),
    ("ldap-key-store" => "b")
]): java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
	at java.security.KeyStore.size(KeyStore.java:1271)
	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
	at java.security.KeyStore.size(KeyStore.java:1271)
	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
	at org.jboss.as.controller.AbstractRemoveStepHandler.execute(AbstractRemoveStepHandler.java:66)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
	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)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]]
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
	at javax.naming.InitialContext.init(InitialContext.java:244)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
	... 31 more
Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
	... 43 more
{code}



> Unable to remove elytron ldap-key-store
> ---------------------------------------
>
>                 Key: WFLY-7290
>                 URL: https://issues.jboss.org/browse/WFLY-7290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Critical
>
> Once ldap-key-store is added it can't be removed.
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=b:add(url=ldap://localhost, principal="CN=user,DC=wildfly,DC=org", credential=password)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:add(dir-context=b,search-path="DC=wildfly,DC=org")
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:remove()
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
>     "rolled-back" => true
> }
> {code}
> which leads to error in server log
> {code}
> 14:55:41,841 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 12) WFLYCTL0013: Operation ("remove") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-key-store" => "b")
> ]): java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.AbstractRemoveStepHandler.execute(AbstractRemoveStepHandler.java:66)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 31 more
> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 03:12:00 2016
From: issues at jboss.org (Mrunali Patil (JIRA))
Date: Wed, 12 Oct 2016 03:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1199) Memory leak in KieScanner
In-Reply-To: <JIRA.12629750.1465228010000@Atlassian.JIRA>
References: <JIRA.12629750.1465228010000@Atlassian.JIRA>
	<JIRA.12629750.1465228010000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629750.1465228010000.12939.1476256320661@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305838#comment-13305838 ] 

Mrunali Patil commented on DROOLS-1199:
---------------------------------------

Hi Joni,

Thanks for the update. We have downgraded the version to 6.2.0 Final. 

Thanks,
Mrunali

> Memory leak in KieScanner
> -------------------------
>
>                 Key: DROOLS-1199
>                 URL: https://issues.jboss.org/browse/DROOLS-1199
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>            Reporter: Viacheslav Krot
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.Beta1
>
>
> I'm not sure, but it seems there is a memory leak in KieScanner, not in scanner directly, but somewhere in plexus used internally.
> If you start KieScanner with version = LATEST, start it with interval say 1 second and sample memory with visualvm (or any other), you can watch number of instances org.eclipse.sisu.plexus.* growing over time. And they cannot be garbage collected - memory root is timer thread. This happens in drools 6.4.0, in 6.3.0 this issue was absent.
> Eventually application fails with OOM.
> As a workaround we call KieScanner#scan manually in a separate thread pool that is recreated from time to time.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 03:34:01 2016
From: issues at jboss.org (David Maes (JIRA))
Date: Wed, 12 Oct 2016 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after
	undeployment
In-Reply-To: <JIRA.12603477.1455161695000@Atlassian.JIRA>
References: <JIRA.12603477.1455161695000@Atlassian.JIRA>
	<JIRA.12603477.1455161695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603477.1455161695000.13180.1476257641355@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305853#comment-13305853 ] 

David Maes commented on WFLY-6173:
----------------------------------

Hello [~mkouba],

Our development team is using wildfly 10.1.0 for the moment. 
We are having the same issue described here. After multiple deploys/undeploys our server crashes with een OOM exception. The "fix version" field for this issue has not yet been set. But I'm guessing it was fixed in the 10.1.0 release. The changelog of this release did not contain the bug.

If this issue was resolved in the 10.1.0 release then I am guessing we are having another cause for the OOM. If so we will investigate and log an issue here.

 Greetings,

David 

> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 03:43:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 12 Oct 2016 03:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after
	undeployment
In-Reply-To: <JIRA.12603477.1455161695000@Atlassian.JIRA>
References: <JIRA.12603477.1455161695000@Atlassian.JIRA>
	<JIRA.12603477.1455161695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603477.1455161695000.13249.1476258180565@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305857#comment-13305857 ] 

Tomas Remes commented on WFLY-6173:
-----------------------------------

Hi,
In 10.1.0.Final there is https://issues.jboss.org/browse/WFLY-7037. So maybe this could cause the problem.

> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 03:45:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 12 Oct 2016 03:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after
	undeployment
In-Reply-To: <JIRA.12603477.1455161695000@Atlassian.JIRA>
References: <JIRA.12603477.1455161695000@Atlassian.JIRA>
	<JIRA.12603477.1455161695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603477.1455161695000.13268.1476258301252@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305859#comment-13305859 ] 

Martin Kouba commented on WFLY-6173:
------------------------------------

[~davidmaes] The first problem with {{org.jboss.el.cache.BeanPropertiesCache}} was fixed in 10.1.0 (see also WFLY-6347). But the other issue with {{com.fasterxml.jackson.databind.util.ClassUtil#sCached}} is fixed in 11.0.0.Alpha1 (see also WFLY-7037). Neither of these issues is caused by CDI/Weld.

> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 03:58:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 12 Oct 2016 03:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.13307.1476259080137@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305866#comment-13305866 ] 

Mario Fusco commented on DROOLS-1313:
-------------------------------------

There are 2 distinct things to be considered here:

1. Will this work? 
Also looking at what it does internally, yes I believe your approach is ok (for now, see 2.).

2. Is this supported?
Every time you use an internal class (not belonging to public kie api) you are doing something that by definition is not supported. We don't give any guarantee that those internal classes will remain as they are now and their behaviour can change literally at any new commit.

I hope this helps,
Mario


> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SAVE_SimpleTest5.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 04:04:00 2016
From: issues at jboss.org (David Maes (JIRA))
Date: Wed, 12 Oct 2016 04:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after
	undeployment
In-Reply-To: <JIRA.12603477.1455161695000@Atlassian.JIRA>
References: <JIRA.12603477.1455161695000@Atlassian.JIRA>
	<JIRA.12603477.1455161695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603477.1455161695000.13339.1476259440782@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305870#comment-13305870 ] 

David Maes commented on WFLY-6173:
----------------------------------

[~mkouba] thank you for the quick reply.
Our memory issue will probably not be caused by the jackson problem. So I think we'll have to do some investigation on our own. 

> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 04:43:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 12 Oct 2016 04:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-168) Release new version of
 jboss-annotations-api_1.2_spec
In-Reply-To: <JIRA.12653172.1475588990000@Atlassian.JIRA>
References: <JIRA.12653172.1475588990000@Atlassian.JIRA>
	<JIRA.12653172.1475588990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653172.1475588990000.13765.1476261780764@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated JBEE-168:
-----------------------------
    Forum Reference: https://jcp.org/aboutJava/communityprocess/mrel/jsr250/index3.html


> Release new version of jboss-annotations-api_1.2_spec
> -----------------------------------------------------
>
>                 Key: JBEE-168
>                 URL: https://issues.jboss.org/browse/JBEE-168
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Task
>          Components: jboss-annotations-api
>            Reporter: Tomas Remes
>            Assignee: Scott Marlow
>
> There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annotation-api%7C1.3%7Cjar recently



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 04:50:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 12 Oct 2016 04:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-168) Release new version of
 jboss-annotations-api_1.2_spec
In-Reply-To: <JIRA.12653172.1475588990000@Atlassian.JIRA>
References: <JIRA.12653172.1475588990000@Atlassian.JIRA>
	<JIRA.12653172.1475588990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653172.1475588990000.13787.1476262201419@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated JBEE-168:
-----------------------------
    Description: 
There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annotation-api%7C1.3%7Cjar recently
change log

{noformat}
Added @Target(PARAMETER) to the Priority annotation.
Made Resource and DataSourceDefinition annotations repeatable.
Clarified rules for use of PostConstruct and PreDestroy annotations to correct inconsistencies with other Java EE specifications.
Replaced example in section 2.1 referencing WebService/WebMethod, which was inconsistent with the JAX-WS and Web Services Metadata specifications. 
{noformat}

  was:There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annotation-api%7C1.3%7Cjar recently



> Release new version of jboss-annotations-api_1.2_spec
> -----------------------------------------------------
>
>                 Key: JBEE-168
>                 URL: https://issues.jboss.org/browse/JBEE-168
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Task
>          Components: jboss-annotations-api
>            Reporter: Tomas Remes
>            Assignee: Scott Marlow
>
> There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annotation-api%7C1.3%7Cjar recently
> change log
> {noformat}
> Added @Target(PARAMETER) to the Priority annotation.
> Made Resource and DataSourceDefinition annotations repeatable.
> Clarified rules for use of PostConstruct and PreDestroy annotations to correct inconsistencies with other Java EE specifications.
> Replaced example in section 2.1 referencing WebService/WebMethod, which was inconsistent with the JAX-WS and Web Services Metadata specifications. 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:05:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 12 Oct 2016 05:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6863) Excluded contexts which are
 not specific to a host should be excluded on all hosts
In-Reply-To: <JIRA.12639956.1469035782000@Atlassian.JIRA>
References: <JIRA.12639956.1469035782000@Atlassian.JIRA>
	<JIRA.12639956.1469035782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639956.1469035782000.13893.1476263101624@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-6863:
---------------------------------
    Fix Version/s:     (was: 10.1.0.CR1)
                       (was: 10.1.0.Final)


> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-6863
>                 URL: https://issues.jboss.org/browse/WFLY-6863
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>         Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" 
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric" 
> loadMetricCapacity="1" 
> loadHistory="9" 
> loadDecayFactor="2" 
> stickySession="true" 
> stickySessionForce="false" 
> stickySessionRemove="true" 
> advertise="true" 
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs  examples  host-manager  manager  ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST"  appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>        prefix="localhost_access_log" suffix=".txt"
>        pattern="%h %l %u %t &quot;%r&quot; %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>        prefix="localhost_access_log" suffix=".txt"
>        pattern="%h %l %u %t &quot;%r&quot; %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:05:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 12 Oct 2016 05:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6863) Excluded contexts which are
 not specific to a host should be excluded on all hosts
In-Reply-To: <JIRA.12639956.1469035782000@Atlassian.JIRA>
References: <JIRA.12639956.1469035782000@Atlassian.JIRA>
	<JIRA.12639956.1469035782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639956.1469035782000.13892.1476263101544@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reopened WFLY-6863:
----------------------------------


> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-6863
>                 URL: https://issues.jboss.org/browse/WFLY-6863
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>         Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" 
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric" 
> loadMetricCapacity="1" 
> loadHistory="9" 
> loadDecayFactor="2" 
> stickySession="true" 
> stickySessionForce="false" 
> stickySessionRemove="true" 
> advertise="true" 
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs  examples  host-manager  manager  ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST"  appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>        prefix="localhost_access_log" suffix=".txt"
>        pattern="%h %l %u %t &quot;%r&quot; %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>        prefix="localhost_access_log" suffix=".txt"
>        pattern="%h %l %u %t &quot;%r&quot; %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:06:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 12 Oct 2016 05:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6863) Excluded contexts which are
 not specific to a host should be excluded on all hosts
In-Reply-To: <JIRA.12639956.1469035782000@Atlassian.JIRA>
References: <JIRA.12639956.1469035782000@Atlassian.JIRA>
	<JIRA.12639956.1469035782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639956.1469035782000.13895.1476263160220@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-6863:
---------------------------------
    Priority: Major  (was: Minor)


> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-6863
>                 URL: https://issues.jboss.org/browse/WFLY-6863
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>         Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" 
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric" 
> loadMetricCapacity="1" 
> loadHistory="9" 
> loadDecayFactor="2" 
> stickySession="true" 
> stickySessionForce="false" 
> stickySessionRemove="true" 
> advertise="true" 
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs  examples  host-manager  manager  ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST"  appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>        prefix="localhost_access_log" suffix=".txt"
>        pattern="%h %l %u %t &quot;%r&quot; %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>        prefix="localhost_access_log" suffix=".txt"
>        pattern="%h %l %u %t &quot;%r&quot; %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:15:03 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 12 Oct 2016 05:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7280) getSession() Always Creating
 HttpSession Problem
In-Reply-To: <JIRA.12653956.1476092316000@Atlassian.JIRA>
References: <JIRA.12653956.1476092316000@Atlassian.JIRA>
	<JIRA.12653956.1476092316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653956.1476092316000.13967.1476263703999@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-7280.
----------------------------------
    Resolution: Cannot Reproduce Bug


You are going to need to provide more details about how to reproduce this.

> getSession()  Always Creating HttpSession Problem
> -------------------------------------------------
>
>                 Key: WFLY-7280
>                 URL: https://issues.jboss.org/browse/WFLY-7280
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>         Environment: jdk8u102,  win7x64,  wildfly-servlet-10.1.0.Final.tar.gz
>            Reporter: kin zhu
>            Assignee: Stuart Douglas
>
> I have a login application called cas.war.  I store the captcha code in session. This application has been running smoothly in JBoss7 and Tomcat7. But when I tried to migrate to wildfly10, I found the captcha code will always be null.  I dug a little deeper, and found out that the server is creating new session each time I post a request(the JSESSIONID cookie changes on every request).  I traced the code and pinned down the problem on this location (as of undertow-servlet-1.4.0.Final-sources.jar ) :
> {color:#f6c342}io.undertow.servlet.spec.ServletContextImpl.java,  method  getSession:{color}
> {code:java}
> public HttpSessionImpl getSession(final ServletContextImpl originalServletContext, final HttpServerExchange exchange, boolean create) {
>         SessionConfig c = originalServletContext.getSessionConfig();
>         HttpSessionImpl httpSession = exchange.getAttachment(sessionAttachmentKey);
> {code}
> while  
> sessionAttachmentKey =  {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.servlet.spec.HttpSessionImpl>{color}
> 		
> the exchange.attachments map will only contain one such key:   {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.server.session.InMemorySessionManager$SessionImpl>{color}
> thus the server will create new session once  request.getSession() is called, regardless one session exist or not.
> And please have a look at the relate class InMemorySessionManager  too.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:30:00 2016
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Wed, 12 Oct 2016 05:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1859) Investigate JDK9 modular
 params propagation to forked processes
In-Reply-To: <JIRA.12653846.1475856902000@Atlassian.JIRA>
References: <JIRA.12653846.1475856902000@Atlassian.JIRA>
	<JIRA.12653846.1475856902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653846.1475856902000.13996.1476264600143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated WFCORE-1859:
-----------------------------------
    Priority: Blocker  (was: Major)


> Investigate JDK9 modular params propagation to forked processes
> ---------------------------------------------------------------
>
>                 Key: WFCORE-1859
>                 URL: https://issues.jboss.org/browse/WFCORE-1859
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Server, Test Suite
>            Reporter: Richard Opalka
>            Priority: Blocker
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:31:00 2016
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Wed, 12 Oct 2016 05:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1859) Investigate and fix JDK9
 modular params propagation to forked processes
In-Reply-To: <JIRA.12653846.1475856902000@Atlassian.JIRA>
References: <JIRA.12653846.1475856902000@Atlassian.JIRA>
	<JIRA.12653846.1475856902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653846.1475856902000.13998.1476264660142@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated WFCORE-1859:
-----------------------------------
    Summary: Investigate and fix JDK9 modular params propagation to forked processes  (was: Investigate JDK9 modular params propagation to forked processes)


> Investigate and fix JDK9 modular params propagation to forked processes
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-1859
>                 URL: https://issues.jboss.org/browse/WFCORE-1859
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Server, Test Suite
>            Reporter: Richard Opalka
>            Priority: Blocker
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:32:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 12 Oct 2016 05:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7292) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12654358.1476264668000@Atlassian.JIRA>
References: <JIRA.12654358.1476264668000@Atlassian.JIRA>
	<JIRA.12654358.1476264668227@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654358.1476264668000.14006.1476264720350@Atlassian.JIRA>

Stuart Douglas created WFLY-7292:
------------------------------------

             Summary: Wildfly eats the CPU up to 100% and does not respond
                 Key: WFLY-7292
                 URL: https://issues.jboss.org/browse/WFLY-7292
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 10.1.0.Final
         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
            Reporter: Krisztian Kocsis
            Assignee: Jason Greene


Hi!
 
I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
 
I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:38:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 12 Oct 2016 05:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.14034.1476265080435@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-7275:
------------------------------------

    Assignee: Stuart Douglas  (was: Jason Greene)


> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Stuart Douglas
>         Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:39:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 12 Oct 2016 05:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.14040.1476265140274@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305943#comment-13305943 ] 

Stuart Douglas commented on WFLY-7275:
--------------------------------------

I have submitted an XNIO pull request that should fix this. I think the problem is caused by the use of  CONNECTION_HIGH_WATER to control the max number of connections.

> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Stuart Douglas
>         Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:43:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 12 Oct 2016 05:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7293) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12654364.1476265368000@Atlassian.JIRA>
References: <JIRA.12654364.1476265368000@Atlassian.JIRA>
	<JIRA.12654364.1476265368415@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654364.1476265368000.14070.1476265380470@Atlassian.JIRA>

Stuart Douglas created WFLY-7293:
------------------------------------

             Summary: Wildfly eats the CPU up to 100% and does not respond
                 Key: WFLY-7293
                 URL: https://issues.jboss.org/browse/WFLY-7293
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 10.1.0.Final
         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
            Reporter: Krisztian Kocsis
            Assignee: Stuart Douglas


Hi!
 
I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
 
I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 05:48:00 2016
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Wed, 12 Oct 2016 05:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1859) Investigate and fix JDK9
 modular params propagation to forked processes
In-Reply-To: <JIRA.12653846.1475856902000@Atlassian.JIRA>
References: <JIRA.12653846.1475856902000@Atlassian.JIRA>
	<JIRA.12653846.1475856902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653846.1475856902000.14098.1476265680576@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305952#comment-13305952 ] 

Richard Opalka commented on WFCORE-1859:
----------------------------------------

On JDK 9 it is necessary (at least for now) to run WildFly's DomainController, HostController and ServerInstance 
with some modular options present on command line to make them work.
It is not clear if JDK 9 modular params should be copied from DomainController to HostController
and further from HostController to ServerInstance or these options should be configured separately and different way.

Anyway this issue will be addressed in near future. For now I'm sending temporary solution to make 
WildFly-Core at least work on JDK9 so we can track the regressions as JDK9 EAs are released.

> Investigate and fix JDK9 modular params propagation to forked processes
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-1859
>                 URL: https://issues.jboss.org/browse/WFCORE-1859
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Server, Test Suite
>            Reporter: Richard Opalka
>            Priority: Blocker
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 06:00:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 12 Oct 2016 06:00:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-657) Wrong error message in
	OAuth2Client
In-Reply-To: <JIRA.12654370.1476266339000@Atlassian.JIRA>
References: <JIRA.12654370.1476266339000@Atlassian.JIRA>
	<JIRA.12654370.1476266339841@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654370.1476266339000.14155.1476266400192@Atlassian.JIRA>

David Lloyd created ELY-657:
-------------------------------

             Summary: Wrong error message in OAuth2Client
                 Key: ELY-657
                 URL: https://issues.jboss.org/browse/ELY-657
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: Authentication Mechanisms
            Reporter: David Lloyd
            Priority: Minor


In OAuth2Client, if the bearer token callback is unsupported, an {{mechCallbackHandlerDoesNotSupportUserName}} is generated.  There should be an error that is more specific to the token callback.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 06:13:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 12 Oct 2016 06:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to add trust-manager
 with ldap-key-store (classloading)
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.14207.1476267180326@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305960#comment-13305960 ] 

Jan Kalina commented on WFLY-7278:
----------------------------------

Also would be better to not require to have a LDAP server online to create the resource - LDAP should be contacted when required - this behavior would solve this issue too probably.

> Unable to add trust-manager with ldap-key-store (classloading)
> --------------------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 06:21:00 2016
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Wed, 12 Oct 2016 06:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1859) Investigate and fix JDK9
 modular params propagation to forked processes
In-Reply-To: <JIRA.12653846.1475856902000@Atlassian.JIRA>
References: <JIRA.12653846.1475856902000@Atlassian.JIRA>
	<JIRA.12653846.1475856902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653846.1475856902000.14228.1476267660933@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned WFCORE-1859:
--------------------------------------

    Assignee: Richard Opalka


> Investigate and fix JDK9 modular params propagation to forked processes
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-1859
>                 URL: https://issues.jboss.org/browse/WFCORE-1859
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Server, Test Suite
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>            Priority: Blocker
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 06:31:03 2016
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 12 Oct 2016 06:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7193) No log messages comming from
 Elytron - ssl context creation
In-Reply-To: <JIRA.12651499.1474551058000@Atlassian.JIRA>
References: <JIRA.12651499.1474551058000@Atlassian.JIRA>
	<JIRA.12651499.1474551058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651499.1474551058000.14284.1476268263866@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305966#comment-13305966 ] 

Peter Skopek commented on WFLY-7193:
------------------------------------

PR: https://github.com/wildfly-security/wildfly-elytron/pull/502
has been merged

> No log messages comming from Elytron - ssl context creation
> -----------------------------------------------------------
>
>                 Key: WFLY-7193
>                 URL: https://issues.jboss.org/browse/WFLY-7193
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>
> Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.
> Seems to me it would be useful for troubleshooting to have logged on 
> TRACE level:
> - Keystore initialization with parameters
> - Filtering keystore initialization with parameters
> - KeyManager / TrustManager initialization with parameters
> - Client / Server SSLContext initialization with parameters
> WARN level:
> - Certificate expired (on key store init, all certificates)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 06:41:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 12 Oct 2016 06:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS
 protocol constraints
In-Reply-To: <JIRA.12649336.1473350959000@Atlassian.JIRA>
References: <JIRA.12649336.1473350959000@Atlassian.JIRA>
	<JIRA.12649336.1473350959000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649336.1473350959000.14381.1476268860244@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305974#comment-13305974 ] 

Jan Kalina commented on ELY-627:
--------------------------------

IBM values: we dont need to support SSL_TLS + SSL_TLSv2, as it is only shortcut to select more protocols which we already support.
I will add the mapping from standard text names (like "TLSv1.2") to enum values.

> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
>                 Key: ELY-627
>                 URL: https://issues.jboss.org/browse/ELY-627
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SSL
>    Affects Versions: 1.1.0.Beta8
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> {noformat}
>                        "protocols" => {
>                             "type" => LIST,
>                             "description" => "The enabled protocols.",
>                             "expressions-allowed" => true,
>                             "nillable" => false,
>                             "allowed" => [
>                                 "SSLv2",
>                                 "SSLv3",
>                                 "TLSv1",
>                                 "TLSv1_1",
>                                 "TLSv1_2",
>                                 "TLSv1_3"
>                             ],
>                             "value-type" => STRING,
>                             "access-type" => "read-write",
>                             "storage" => "configuration",
>                             "restart-required" => "resource-services"
>                         },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. 
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/protocols.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 07:37:00 2016
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 12 Oct 2016 07:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-658) OAuth2 Resource Owner Password
 Credentials Callback
In-Reply-To: <JIRA.12654391.1476272183000@Atlassian.JIRA>
References: <JIRA.12654391.1476272183000@Atlassian.JIRA>
	<JIRA.12654391.1476272183821@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654391.1476272183000.14729.1476272220127@Atlassian.JIRA>

Pedro Igor created ELY-658:
------------------------------

             Summary: OAuth2 Resource Owner Password Credentials Callback
                 Key: ELY-658
                 URL: https://issues.jboss.org/browse/ELY-658
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: Callbacks
    Affects Versions: 1.1.0.Beta10
            Reporter: Pedro Igor
            Assignee: Pedro Igor


We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with grant type.

This should also allow Elytron to support other grant types defined by OAuth2 in the future.

Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].

In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.

[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 07:38:00 2016
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 12 Oct 2016 07:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-658) OAuth2 Resource Owner Password
 Credentials Callback
In-Reply-To: <JIRA.12654391.1476272184000@Atlassian.JIRA>
References: <JIRA.12654391.1476272184000@Atlassian.JIRA>
	<JIRA.12654391.1476272184000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654391.1476272184000.14737.1476272280499@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated ELY-658:
---------------------------
    Description: 
We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with this grant type.

This should also allow Elytron to support other grant types defined by OAuth2 in the future.

Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].

In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.

[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html

  was:
We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with grant type.

This should also allow Elytron to support other grant types defined by OAuth2 in the future.

Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].

In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.

[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html



> OAuth2 Resource Owner Password Credentials Callback
> ---------------------------------------------------
>
>                 Key: ELY-658
>                 URL: https://issues.jboss.org/browse/ELY-658
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Callbacks
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with this grant type.
> This should also allow Elytron to support other grant types defined by OAuth2 in the future.
> Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].
> In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.
> [1] https://tools.ietf.org/html/rfc6749#page-9
> [2] https://openid.net/specs/openid-connect-discovery-1_0.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 07:52:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 12 Oct 2016 07:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7294) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication
In-Reply-To: <JIRA.12654400.1476273068000@Atlassian.JIRA>
References: <JIRA.12654400.1476273068000@Atlassian.JIRA>
	<JIRA.12654400.1476273068843@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654400.1476273068000.14855.1476273120537@Atlassian.JIRA>

Ondrej Lukas created WFLY-7294:
----------------------------------

             Summary: Deployment fails when unreachable LDAP is used for Elytron LDAP authentication
                 Key: WFLY-7294
                 URL: https://issues.jboss.org/browse/WFLY-7294
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Blocker


In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.

We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.

Deployment fails with following exception in server log:
{code}
ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	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)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
	... 6 more
Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:349)
	at java.lang.Iterable.forEach(Iterable.java:75)
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:346)
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:294)
	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:402)
	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:206)
	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
	... 8 more

ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
    "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
    Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
    Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 07:52:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 12 Oct 2016 07:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7294) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication
In-Reply-To: <JIRA.12654400.1476273069000@Atlassian.JIRA>
References: <JIRA.12654400.1476273069000@Atlassian.JIRA>
	<JIRA.12654400.1476273069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654400.1476273069000.14864.1476273120856@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7294:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7294
>                 URL: https://issues.jboss.org/browse/WFLY-7294
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:349)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:346)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:294)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:402)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:206)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 08:02:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 12 Oct 2016 08:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Internal server error is
 returned for Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683069@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.14929.1476273720890@Atlassian.JIRA>

Ondrej Lukas created WFLY-7295:
----------------------------------

             Summary: Internal server error is returned for Elytron authentication when LDAP server is unreachable
                 Key: WFLY-7295
                 URL: https://issues.jboss.org/browse/WFLY-7295
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Critical


In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.

Exception in server log:
{code}
ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
	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)
Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
	at javax.naming.InitialContext.init(InitialContext.java:244)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
	... 45 more
Caused by: java.net.ConnectException: Connection refused
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.net.Socket.connect(Socket.java:589)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
	... 67 more
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 08:02:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 12 Oct 2016 08:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Internal server error is
 returned for Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.14940.1476273721261@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7295:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Internal server error is returned for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 08:16:00 2016
From: issues at jboss.org (kin zhu (JIRA))
Date: Wed, 12 Oct 2016 08:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7280) getSession() Always Creating
 HttpSession Problem
In-Reply-To: <JIRA.12653956.1476092316000@Atlassian.JIRA>
References: <JIRA.12653956.1476092316000@Atlassian.JIRA>
	<JIRA.12653956.1476092316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653956.1476092316000.15137.1476274560450@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306040#comment-13306040 ] 

kin zhu commented on WFLY-7280:
-------------------------------

I'm sorry for the false alarm.  Turns out that there're two JSESSIONID cookie and firefox  won't  merge them.   The problem solved after I clear the cookies and try login again.

> getSession()  Always Creating HttpSession Problem
> -------------------------------------------------
>
>                 Key: WFLY-7280
>                 URL: https://issues.jboss.org/browse/WFLY-7280
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>         Environment: jdk8u102,  win7x64,  wildfly-servlet-10.1.0.Final.tar.gz
>            Reporter: kin zhu
>            Assignee: Stuart Douglas
>
> I have a login application called cas.war.  I store the captcha code in session. This application has been running smoothly in JBoss7 and Tomcat7. But when I tried to migrate to wildfly10, I found the captcha code will always be null.  I dug a little deeper, and found out that the server is creating new session each time I post a request(the JSESSIONID cookie changes on every request).  I traced the code and pinned down the problem on this location (as of undertow-servlet-1.4.0.Final-sources.jar ) :
> {color:#f6c342}io.undertow.servlet.spec.ServletContextImpl.java,  method  getSession:{color}
> {code:java}
> public HttpSessionImpl getSession(final ServletContextImpl originalServletContext, final HttpServerExchange exchange, boolean create) {
>         SessionConfig c = originalServletContext.getSessionConfig();
>         HttpSessionImpl httpSession = exchange.getAttachment(sessionAttachmentKey);
> {code}
> while  
> sessionAttachmentKey =  {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.servlet.spec.HttpSessionImpl>{color}
> 		
> the exchange.attachments map will only contain one such key:   {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.server.session.InMemorySessionManager$SessionImpl>{color}
> thus the server will create new session once  request.getSession() is called, regardless one session exist or not.
> And please have a look at the relate class InMemorySessionManager  too.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 08:18:00 2016
From: issues at jboss.org (kin zhu (JIRA))
Date: Wed, 12 Oct 2016 08:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7280) getSession() Always Creating
 HttpSession Problem
In-Reply-To: <JIRA.12653956.1476092316000@Atlassian.JIRA>
References: <JIRA.12653956.1476092316000@Atlassian.JIRA>
	<JIRA.12653956.1476092316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653956.1476092316000.15148.1476274680254@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306040#comment-13306040 ] 

kin zhu edited comment on WFLY-7280 at 10/12/16 8:17 AM:
---------------------------------------------------------

I'm sorry for the false alarm.  Turns out that there're two JSESSIONID cookies and firefox  won't  merge them.   The problem solved right after I cleared the cookies and tried login again.


was (Author: daxiaoming200):
I'm sorry for the false alarm.  Turns out that there're two JSESSIONID cookie and firefox  won't  merge them.   The problem solved after I clear the cookies and try login again.

> getSession()  Always Creating HttpSession Problem
> -------------------------------------------------
>
>                 Key: WFLY-7280
>                 URL: https://issues.jboss.org/browse/WFLY-7280
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>         Environment: jdk8u102,  win7x64,  wildfly-servlet-10.1.0.Final.tar.gz
>            Reporter: kin zhu
>            Assignee: Stuart Douglas
>
> I have a login application called cas.war.  I store the captcha code in session. This application has been running smoothly in JBoss7 and Tomcat7. But when I tried to migrate to wildfly10, I found the captcha code will always be null.  I dug a little deeper, and found out that the server is creating new session each time I post a request(the JSESSIONID cookie changes on every request).  I traced the code and pinned down the problem on this location (as of undertow-servlet-1.4.0.Final-sources.jar ) :
> {color:#f6c342}io.undertow.servlet.spec.ServletContextImpl.java,  method  getSession:{color}
> {code:java}
> public HttpSessionImpl getSession(final ServletContextImpl originalServletContext, final HttpServerExchange exchange, boolean create) {
>         SessionConfig c = originalServletContext.getSessionConfig();
>         HttpSessionImpl httpSession = exchange.getAttachment(sessionAttachmentKey);
> {code}
> while  
> sessionAttachmentKey =  {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.servlet.spec.HttpSessionImpl>{color}
> 		
> the exchange.attachments map will only contain one such key:   {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.server.session.InMemorySessionManager$SessionImpl>{color}
> thus the server will create new session once  request.getSession() is called, regardless one session exist or not.
> And please have a look at the relate class InMemorySessionManager  too.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 08:25:00 2016
From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=)
Date: Wed, 12 Oct 2016 08:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7296) (7.1.0) When JASPIC's
 register session is used, Subject not propagated to EJB
In-Reply-To: <JIRA.12654414.1476275058000@Atlassian.JIRA>
References: <JIRA.12654414.1476275058000@Atlassian.JIRA>
	<JIRA.12654414.1476275058520@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654414.1476275058000.15244.1476275100816@Atlassian.JIRA>

Bartosz Spyrko-?mietanko created WFLY-7296:
----------------------------------------------

             Summary: (7.1.0) When JASPIC's register session is used, Subject not propagated to EJB
                 Key: WFLY-7296
                 URL: https://issues.jboss.org/browse/WFLY-7296
             Project: WildFly
          Issue Type: Bug
          Components: Security
    Affects Versions: 10.0.0.Final
            Reporter: Bartosz Spyrko-?mietanko
            Assignee: Darran Lofthouse
             Fix For: 10.1.0.CR1, 10.1.0.Final


When the JASPIC 1.1 register session ({{javax.servlet.http.registerSession}}) is used, the authenticated identity (via the Subject) is not propagated to the EJB container.

The problems seems to be with {{JASPICAuthenticationMechanism.createAccount}}. When a cached account is re-used, a {{null}} is passed for the {{Subject}} parameter in the call to {{jbossSct.getUtil().createSubjectInfo}}. This will set indeed set a {{SubjectInfo}} with subject being null.

{{EJBContext#getCallerPrincipal}} checks exactly this subject, and when seeing a null will consider the user to be unauthenticated, even when the caller is authenticated in the web layer.

See the code below:

{code:java}
   // SAM handled the same principal found in the cached account: indicates we must use the cached account.
        if (cachedAccount != null && cachedAccount.getPrincipal() == userPrincipal) {
            // populate the security context using the cached account data.
            jbossSct.getUtil().createSubjectInfo(
                userPrincipal, ((AccountImpl) cachedAccount).getCredential(), 
                null); // PROBLEMATIC NULL
            RoleGroup roleGroup = new SimpleRoleGroup(SecurityConstants.ROLES_IDENTIFIER);
            for (String role : cachedAccount.getRoles())
                roleGroup.addRole(new SimpleRole(role));
            jbossSct.getUtil().setRoles(roleGroup);
            return cachedAccount;
        }
{code}

Instead of passing a {{null}}, passing the existing subject as set by the JASPIC callback handler seems to work:

{code:java}
jbossSct.getUtil().createSubjectInfo(
    userPrincipal, ((AccountImpl) cachedAccount).getCredential(), 
    jbossSct.getUtil().getSubject());
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct 12 09:23:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 12 Oct 2016 09:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.15748.1476278580291@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306093#comment-13306093 ] 

Geoffrey De Smet commented on DROOLS-1323:
------------------------------------------

Experiment that needs to be run: remove DefaultAgenda line 1459: stateMachineLock.notifyAll();
and see if it affects CloudBalancing's speed and profiling.

> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 09:37:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 12 Oct 2016 09:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism
	implementations final
In-Reply-To: <JIRA.12654448.1476279387000@Atlassian.JIRA>
References: <JIRA.12654448.1476279387000@Atlassian.JIRA>
	<JIRA.12654448.1476279387642@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654448.1476279387000.15929.1476279420210@Atlassian.JIRA>

David Lloyd created ELY-659:
-------------------------------

             Summary: Make all mechanism implementations final
                 Key: ELY-659
                 URL: https://issues.jboss.org/browse/ELY-659
             Project: WildFly Elytron
          Issue Type: Task
          Components: Authentication Mechanisms, HTTP, SASL
            Reporter: David Lloyd
            Priority: Critical
             Fix For: 1.1.0.Beta11


It is very important to make all the mechanism implementations final.  Relatedly, they should have no protected members.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 10:33:00 2016
From: issues at jboss.org (Jan Stefl (JIRA))
Date: Wed, 12 Oct 2016 10:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7297) It is not possible to explode
 and browse deployments within deployment
In-Reply-To: <JIRA.12654464.1476282729000@Atlassian.JIRA>
References: <JIRA.12654464.1476282729000@Atlassian.JIRA>
	<JIRA.12654464.1476282729206@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654464.1476282729000.16506.1476282780213@Atlassian.JIRA>

Jan Stefl created WFLY-7297:
-------------------------------

             Summary: It is not possible to explode and browse deployments within deployment
                 Key: WFLY-7297
                 URL: https://issues.jboss.org/browse/WFLY-7297
             Project: WildFly
          Issue Type: Bug
          Components: Web Console
    Affects Versions: 11.0.0.Alpha1
            Reporter: Jan Stefl
            Assignee: Claudio Miranda
         Attachments: jboss-kitchensink-ear.ear

It is possible to explode and browse content of top level deployment but there is no possibility for such operation with deployment. 

Attaching test deployent for experiments.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 10:51:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 12 Oct 2016 10:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7298) Testsuite IO ops cleanup
In-Reply-To: <JIRA.12654467.1476283812000@Atlassian.JIRA>
References: <JIRA.12654467.1476283812000@Atlassian.JIRA>
	<JIRA.12654467.1476283812920@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654467.1476283812000.16600.1476283861232@Atlassian.JIRA>

Tomaz Cerar created WFLY-7298:
---------------------------------

             Summary: Testsuite IO ops cleanup
                 Key: WFLY-7298
                 URL: https://issues.jboss.org/browse/WFLY-7298
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Do some needed housekeeping of testsuite



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 10:51:02 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 12 Oct 2016 10:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7298) Testsuite IO ops housekeeping
In-Reply-To: <JIRA.12654467.1476283813000@Atlassian.JIRA>
References: <JIRA.12654467.1476283813000@Atlassian.JIRA>
	<JIRA.12654467.1476283813000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654467.1476283813000.16628.1476283862103@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7298:
------------------------------
    Summary: Testsuite IO ops housekeeping  (was: Testsuite IO ops cleanup)


> Testsuite IO ops housekeeping
> -----------------------------
>
>                 Key: WFLY-7298
>                 URL: https://issues.jboss.org/browse/WFLY-7298
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> Do some needed housekeeping of testsuite



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 10:51:02 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 12 Oct 2016 10:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7299) Testsuite IO ops housekeeping
In-Reply-To: <JIRA.12654469.1476283852000@Atlassian.JIRA>
References: <JIRA.12654469.1476283852000@Atlassian.JIRA>
	<JIRA.12654469.1476283852180@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654469.1476283852000.16633.1476283862235@Atlassian.JIRA>

Tomaz Cerar created WFLY-7299:
---------------------------------

             Summary: Testsuite IO ops housekeeping
                 Key: WFLY-7299
                 URL: https://issues.jboss.org/browse/WFLY-7299
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Do some needed housekeeping of testsuite



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 11:00:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Wed, 12 Oct 2016 11:00:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7300) OperationHandlers that
 register DeploymentProcessor should do it only on boot
In-Reply-To: <JIRA.12654473.1476284330000@Atlassian.JIRA>
References: <JIRA.12654473.1476284330000@Atlassian.JIRA>
	<JIRA.12654473.1476284330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654473.1476284330000.16681.1476284400152@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet moved JBEAP-6412 to WFLY-7300:
------------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7300  (was: JBEAP-6412)
           Issue Type: Bug  (was: Feature Request)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Affects Version/s:     (was: 7.1.0.DR6)


> OperationHandlers that register DeploymentProcessor should do it only on boot
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7300
>                 URL: https://issues.jboss.org/browse/WFLY-7300
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend  AbstractBoottimeAddStepHandler



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 11:03:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Wed, 12 Oct 2016 11:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7300) OperationHandlers that
 register DeploymentProcessor should do it only on boot
In-Reply-To: <JIRA.12654473.1476284330000@Atlassian.JIRA>
References: <JIRA.12654473.1476284330000@Atlassian.JIRA>
	<JIRA.12654473.1476284330000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654473.1476284330000.16689.1476284580220@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306195#comment-13306195 ] 

ehsavoie Hugonnet commented on WFLY-7300:
-----------------------------------------

To reproduce:
/extension=org.jboss.as.jsr77:add(module=org.jboss.as.jsr77)
/subsystem=jsr77:add()
:reload() 

> OperationHandlers that register DeploymentProcessor should do it only on boot
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7300
>                 URL: https://issues.jboss.org/browse/WFLY-7300
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend  AbstractBoottimeAddStepHandler



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 11:24:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 12 Oct 2016 11:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-660) Elytron introduces SSL/TLS
 protocol constraints
In-Reply-To: <JIRA.12654479.1476285828000@Atlassian.JIRA>
References: <JIRA.12654479.1476285828000@Atlassian.JIRA>
	<JIRA.12654479.1476285828264@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654479.1476285828000.16819.1476285840173@Atlassian.JIRA>

Jan Kalina created ELY-660:
------------------------------

             Summary: Elytron introduces SSL/TLS protocol constraints
                 Key: ELY-660
                 URL: https://issues.jboss.org/browse/ELY-660
             Project: WildFly Elytron
          Issue Type: Bug
          Components: SSL
    Affects Versions: 1.1.0.Beta8
            Reporter: Jan Kalina
            Assignee: Jan Kalina
            Priority: Blocker



{noformat}
                       "protocols" => {
                            "type" => LIST,
                            "description" => "The enabled protocols.",
                            "expressions-allowed" => true,
                            "nillable" => false,
                            "allowed" => [
                                "SSLv2",
                                "SSLv3",
                                "TLSv1",
                                "TLSv1_1",
                                "TLSv1_2",
                                "TLSv1_3"
                            ],
                            "value-type" => STRING,
                            "access-type" => "read-write",
                            "storage" => "configuration",
                            "restart-required" => "resource-services"
                        },
{noformat}

Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. 

Note, IBM java already today defines little bit different protocols set [2]

I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext
[2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/protocols.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 11:25:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 12 Oct 2016 11:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7301) Elytron introduces SSL/TLS
 protocol constraints
In-Reply-To: <JIRA.12654479.1476285828000@Atlassian.JIRA>
References: <JIRA.12654479.1476285828000@Atlassian.JIRA>
	<JIRA.12654479.1476285828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654479.1476285828000.16825.1476285900333@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved ELY-660 to WFLY-7301:
--------------------------------------

              Project: WildFly  (was: WildFly Elytron)
                  Key: WFLY-7301  (was: ELY-660)
          Component/s: Security
                           (was: SSL)
    Affects Version/s:     (was: 1.1.0.Beta8)


> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
>                 Key: WFLY-7301
>                 URL: https://issues.jboss.org/browse/WFLY-7301
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> {noformat}
>                        "protocols" => {
>                             "type" => LIST,
>                             "description" => "The enabled protocols.",
>                             "expressions-allowed" => true,
>                             "nillable" => false,
>                             "allowed" => [
>                                 "SSLv2",
>                                 "SSLv3",
>                                 "TLSv1",
>                                 "TLSv1_1",
>                                 "TLSv1_2",
>                                 "TLSv1_3"
>                             ],
>                             "value-type" => STRING,
>                             "access-type" => "read-write",
>                             "storage" => "configuration",
>                             "restart-required" => "resource-services"
>                         },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. 
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SSLContext
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/protocols.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 12 13:56:00 2016
From: issues at jboss.org (Bill Tuminaro (JIRA))
Date: Wed, 12 Oct 2016 13:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a
 supported scenario for Dynamic rule management
In-Reply-To: <JIRA.12652621.1475165964000@Atlassian.JIRA>
References: <JIRA.12652621.1475165964000@Atlassian.JIRA>
	<JIRA.12652621.1475165964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652621.1475165964000.17277.1476294960093@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306275#comment-13306275 ] 

Bill Tuminaro commented on DROOLS-1313:
---------------------------------------

I could not find a public interface to duplicate a KieFileSystem, I could not even find a way to get a directory or a list of paths so I could read all the existing files so I could iterate over them to create a new KieFileSystem.  Is there one?

Is there a correct way (or public api ) that supports making incremental changes to a KieFileSystem and use ((InternalKieBuilder) kb ).incrementalBuild() to build it?

> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-1313
>                 URL: https://issues.jboss.org/browse/DROOLS-1313
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>            Reporter: Bill Tuminaro
>            Assignee: Mario Fusco
>         Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SAVE_SimpleTest5.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario.  If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> -  Create a new ReleaseId
> -  Create a new KieFileSystem
> -  Generate and write the PomXML for the ReleaseId created above
> -  Create a new KieModuleModel
> -  Create a new KieBaseModel
> -  Write the ModuleModel XML to the KieFileSystem
> -  Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> -  Create a new KieBuilder
> -  Do a buildall() with the KieBuilder
> -  Create a new KieContainer
> -  Create a new KieSession from the KieContainer
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> -  Delete 2 rules from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
>     -  Rule_120_Triggered_Part_1_ 0 is not there
>     -  Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> -  Delete 1 rule from the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Add 2 new rules to the KieFileSystem created above
> -  Call incrementalBuild() on the KieBuilder created above
> -  Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> -  Print out the rules in the KieContainer for the package used in my rules
> -  Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
>     -  Rule_120_Triggered_Part_1_ 0 is STILL not there
>     -  TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> -  Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 01:07:00 2016
From: issues at jboss.org (=?UTF-8?Q?=E4=BF=90=E4=BD=B3_=E5=BC=A0_=28JIRA=29?=)
Date: Thu, 13 Oct 2016 01:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2102) bind_interface="eth0" and
 bind_addr="LINK_LOCAL" config are conflict
In-Reply-To: <JIRA.12652400.1475060146000@Atlassian.JIRA>
References: <JIRA.12652400.1475060146000@Atlassian.JIRA>
	<JIRA.12652400.1475060146000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652400.1475060146000.18198.1476335220112@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306383#comment-13306383 ] 

?? ? commented on JGRP-2102:
----------------------------

This issue happens during when there're two ethernet card. eth0 and eth1, both have global and Link Local address enabled. 

> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
>                 Key: JGRP-2102
>                 URL: https://issues.jboss.org/browse/JGRP-2102
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.1
>         Environment: {noformat}
> [root at wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>     inet6 2606:ae00:e200:3f::83/128 scope global
>  valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>  valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>     link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
>     inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
>     inet6 2606:ae00:e200:3f::28/64 scope global
>  valid_lft forever preferred_lft forever
>     inet6 fe80::250:56ff:feab:2aea/64 scope link
>  valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>     link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
>     inet6 fe80::250:56ff:feab:d612/64 scope link
>  valid_lft forever preferred_lft forever
> {noformat}
> There're eth0 and eth1 exists in the environment
>            Reporter: ?? ?
>            Assignee: Bela Ban
>             Fix For: 3.6.12
>
>         Attachments: jgroups-udp.xml
>
>
> Error happens while 
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
>         at java.lang.reflect.Method.invoke(Method.java:620)
>         at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
>         at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
>         at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
>         at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
>         at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
>         at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
>         ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
>         at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
>         at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
>         at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
>         at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
>         at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
>         at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
>         at org.jgroups.JChannel.init(JChannel.java:854)
>         at org.jgroups.JChannel.<init>(JChannel.java:159)
>         at org.jgroups.JChannel.<init>(JChannel.java:129)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
>         ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
>         at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
>         at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
>         ... 48 more
> Caused by: java.lang.mail at example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
>         at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> {code}
> public static InetAddress getAddress(AddressScope scope)     //                     ----> scope is LINK_LOCAL
>     throws SocketException
>   {
>     InetAddress address = null;
>     Enumeration intfs = NetworkInterface.getNetworkInterfaces();
>     while (intfs.hasMoreElements()) {
>       NetworkInterface intf = (NetworkInterface)intfs.nextElement();
>       try {
>         if (intf.isUp()) {
>           address = getAddress(intf, scope);    //  -------> It will return the first LINK_LOCAL address from NICs list
>           if (address != null)
>             return address;
>         }
>       }
>       catch (SocketException e) {
>       }
>     }
>     return null;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 13 02:06:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 13 Oct 2016 02:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7302) Usernames started with
 rdn-identifier works incorrectly in Elytron ldap-realm
In-Reply-To: <JIRA.12654575.1476338734000@Atlassian.JIRA>
References: <JIRA.12654575.1476338734000@Atlassian.JIRA>
	<JIRA.12654575.1476338734155@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654575.1476338734000.18250.1476338760639@Atlassian.JIRA>

Ondrej Lukas created WFLY-7302:
----------------------------------

             Summary: Usernames started with rdn-identifier works incorrectly in Elytron ldap-realm
                 Key: WFLY-7302
                 URL: https://issues.jboss.org/browse/WFLY-7302
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Critical


In case username passed to {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity}} starts with the same string as is used in {{identityMapping.rdnIdentifier}} then authentication fails. It is caused by wrong condition in [1].

Thrown exception in server log:
{code}
ERROR [io.undertow.request] (default task-12) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "uidyllic" from server
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:625)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
	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)
Caused by: javax.naming.InvalidNameException: Invalid name: uidyllic
	at javax.naming.ldap.Rfc2253Parser.doParse(Rfc2253Parser.java:111)
	at javax.naming.ldap.Rfc2253Parser.parseDn(Rfc2253Parser.java:70)
	at javax.naming.ldap.LdapName.parse(LdapName.java:785)
	at javax.naming.ldap.LdapName.<init>(LdapName.java:123)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:571)
	... 45 more
{code}

[1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L570



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 02:06:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 13 Oct 2016 02:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7302) Usernames started with
 rdn-identifier works incorrectly in Elytron ldap-realm
In-Reply-To: <JIRA.12654575.1476338734000@Atlassian.JIRA>
References: <JIRA.12654575.1476338734000@Atlassian.JIRA>
	<JIRA.12654575.1476338734000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654575.1476338734000.18261.1476338760972@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7302:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Usernames started with rdn-identifier works incorrectly in Elytron ldap-realm
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7302
>                 URL: https://issues.jboss.org/browse/WFLY-7302
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case username passed to {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity}} starts with the same string as is used in {{identityMapping.rdnIdentifier}} then authentication fails. It is caused by wrong condition in [1].
> Thrown exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-12) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "uidyllic" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:625)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.InvalidNameException: Invalid name: uidyllic
> 	at javax.naming.ldap.Rfc2253Parser.doParse(Rfc2253Parser.java:111)
> 	at javax.naming.ldap.Rfc2253Parser.parseDn(Rfc2253Parser.java:70)
> 	at javax.naming.ldap.LdapName.parse(LdapName.java:785)
> 	at javax.naming.ldap.LdapName.<init>(LdapName.java:123)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:571)
> 	... 45 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L570



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 03:05:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Thu, 13 Oct 2016 03:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Statefull working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273418@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.18364.1476342300307@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-1326:
----------------------------------------

             Summary: Statefull working memory regression OCT-2016: nurserostering long_hint01.xml
                 Key: DROOLS-1326
                 URL: https://issues.jboss.org/browse/DROOLS-1326
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.0.0.Beta2
            Reporter: Geoffrey De Smet
            Assignee: Mario Fusco


Something regressed in Drools master between 27-SEP and 11-OCT.

See:
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/

I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 03:08:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Thu, 13 Oct 2016 03:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Statefull working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.18367.1476342480409@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1326:
-------------------------------------
    Priority: Blocker  (was: Major)


> Statefull working memory regression OCT-2016: nurserostering long_hint01.xml
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-1326
>                 URL: https://issues.jboss.org/browse/DROOLS-1326
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/
> I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 04:31:00 2016
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Thu, 13 Oct 2016 04:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5839) Create "Best practice"
 document for writing tests
In-Reply-To: <JIRA.12596430.1449843248000@Atlassian.JIRA>
References: <JIRA.12596430.1449843248000@Atlassian.JIRA>
	<JIRA.12596430.1449843248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12596430.1449843248000.18938.1476347460594@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rostislav Svoboda resolved WFLY-5839.
-------------------------------------
    Fix Version/s: No Release
       Resolution: Done


> Create "Best practice" document for writing tests
> -------------------------------------------------
>
>                 Key: WFLY-5839
>                 URL: https://issues.jboss.org/browse/WFLY-5839
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Rostislav Svoboda
>            Assignee: Tomaz Cerar
>             Fix For: No Release
>
>
> Please create "Best practice" document for writing tests
> In AS TS there are currently multiple solutions for the same thing, ARQ is used where WF deployer would be sufficient, tests are not exactly in the correct location - they can be even in WF Core TS.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 04:47:00 2016
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Thu, 13 Oct 2016 04:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Stateful working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.19057.1476348420662@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jiri Locker updated DROOLS-1326:
--------------------------------
    Summary: Stateful working memory regression OCT-2016: nurserostering long_hint01.xml  (was: Statefull working memory regression OCT-2016: nurserostering long_hint01.xml)


> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-1326
>                 URL: https://issues.jboss.org/browse/DROOLS-1326
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/
> I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 05:11:00 2016
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Thu, 13 Oct 2016 05:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5839) Create "Best practice"
 document for writing tests
In-Reply-To: <JIRA.12596430.1449843248000@Atlassian.JIRA>
References: <JIRA.12596430.1449843248000@Atlassian.JIRA>
	<JIRA.12596430.1449843248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12596430.1449843248000.19224.1476349860924@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306498#comment-13306498 ] 

Rostislav Svoboda commented on WFLY-5839:
-----------------------------------------

Enhanced syntax slide on https://drive.google.com/file/d/0B1UdSRDDWsroLW52TngyMEpkVTA/view is nice too.

> Create "Best practice" document for writing tests
> -------------------------------------------------
>
>                 Key: WFLY-5839
>                 URL: https://issues.jboss.org/browse/WFLY-5839
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Rostislav Svoboda
>            Assignee: Tomaz Cerar
>             Fix For: No Release
>
>
> Please create "Best practice" document for writing tests
> In AS TS there are currently multiple solutions for the same thing, ARQ is used where WF deployer would be sufficient, tests are not exactly in the correct location - they can be even in WF Core TS.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 05:13:00 2016
From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=)
Date: Thu, 13 Oct 2016 05:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1864) Whitespaces are not removed
 from dependencies in module add command
In-Reply-To: <JIRA.12654599.1476349950000@Atlassian.JIRA>
References: <JIRA.12654599.1476349950000@Atlassian.JIRA>
	<JIRA.12654599.1476349950930@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654599.1476349950000.19236.1476349980254@Atlassian.JIRA>

Bartosz Spyrko-?mietanko created WFCORE-1864:
------------------------------------------------

             Summary: Whitespaces are not removed from dependencies in module add command
                 Key: WFCORE-1864
                 URL: https://issues.jboss.org/browse/WFCORE-1864
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 3.0.0.Alpha9
            Reporter: Bartosz Spyrko-?mietanko
            Assignee: Bartosz Spyrko-?mietanko


Running 
{{module add --name=foo.bar --resources=foo.jar --dependencies=[org.a, org.b ]}}

will result in following dependencies in module.xml
{{
...
    <dependencies>
        <module name="org.a"/>
        <module name=" org.b "/>
    </dependencies>
...
}}

The module name in dependencies should be stripped of leading and trailing whitespaces.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 13 05:43:00 2016
From: issues at jboss.org (Farah Juma (JIRA))
Date: Thu, 13 Oct 2016 05:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7303) Unignore tests in
 org.jboss.as.test.integration.ejb.mdb.MDBTestCase and
 org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase
In-Reply-To: <JIRA.12654629.1476351727000@Atlassian.JIRA>
References: <JIRA.12654629.1476351727000@Atlassian.JIRA>
	<JIRA.12654629.1476351727439@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654629.1476351727000.19414.1476351780960@Atlassian.JIRA>

Farah Juma created WFLY-7303:
--------------------------------

             Summary: Unignore tests in org.jboss.as.test.integration.ejb.mdb.MDBTestCase and org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase
                 Key: WFLY-7303
                 URL: https://issues.jboss.org/browse/WFLY-7303
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Farah Juma
            Assignee: Farah Juma


When tests in {{org.jboss.as.test.integration.ejb.mdb.MDBTestCase}} and {{org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase}}, the tests that get run after these ones fail as well. These tests in MDBTestCases will be fixed during Phase III Remoting 5 integration but temporarily ignoring them for now to try to get the CI job in better shape.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 05:43:01 2016
From: issues at jboss.org (Farah Juma (JIRA))
Date: Thu, 13 Oct 2016 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7303) Unignore tests in
 org.jboss.as.test.integration.ejb.mdb.MDBTestCase and
 org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase
In-Reply-To: <JIRA.12654629.1476351727000@Atlassian.JIRA>
References: <JIRA.12654629.1476351727000@Atlassian.JIRA>
	<JIRA.12654629.1476351727000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654629.1476351727000.19416.1476351781011@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-7303:
-----------------------------
    Description: When tests in {{org.jboss.as.test.integration.ejb.mdb.MDBTestCase}} and {{org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase}} fail, the tests that get run after these ones fail as well. These tests in MDBTestCases will be fixed during Phase III Remoting 5 integration but temporarily ignoring them for now to try to get the CI job in better shape.  (was: When tests in {{org.jboss.as.test.integration.ejb.mdb.MDBTestCase}} and {{org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase}}, the tests that get run after these ones fail as well. These tests in MDBTestCases will be fixed during Phase III Remoting 5 integration but temporarily ignoring them for now to try to get the CI job in better shape.)


> Unignore tests in org.jboss.as.test.integration.ejb.mdb.MDBTestCase and org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7303
>                 URL: https://issues.jboss.org/browse/WFLY-7303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>              Labels: affects_elytron
>
> When tests in {{org.jboss.as.test.integration.ejb.mdb.MDBTestCase}} and {{org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase}} fail, the tests that get run after these ones fail as well. These tests in MDBTestCases will be fixed during Phase III Remoting 5 integration but temporarily ignoring them for now to try to get the CI job in better shape.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 05:44:01 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 13 Oct 2016 05:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7304) Compensations subsystem
In-Reply-To: <JIRA.12654630.1476351822000@Atlassian.JIRA>
References: <JIRA.12654630.1476351822000@Atlassian.JIRA>
	<JIRA.12654630.1476351822802@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654630.1476351822000.19438.1476351841016@Atlassian.JIRA>

Gytis Trikleris created WFLY-7304:
-------------------------------------

             Summary: Compensations subsystem
                 Key: WFLY-7304
                 URL: https://issues.jboss.org/browse/WFLY-7304
             Project: WildFly
          Issue Type: Task
          Components: Transactions
            Reporter: Gytis Trikleris
            Assignee: Gytis Trikleris
            Priority: Minor
             Fix For: 11.0.0.Alpha1


Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 05:46:00 2016
From: issues at jboss.org (Jive JIRA Integration (JIRA))
Date: Thu, 13 Oct 2016 05:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7304) Compensations subsystem
In-Reply-To: <JIRA.12654630.1476351823000@Atlassian.JIRA>
References: <JIRA.12654630.1476351823000@Atlassian.JIRA>
	<JIRA.12654630.1476351823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654630.1476351823000.19460.1476351960920@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jive JIRA Integration updated WFLY-7304:
----------------------------------------
    Forum Reference: https://developer.jboss.org/message/963125#963125


> Compensations subsystem
> -----------------------
>
>                 Key: WFLY-7304
>                 URL: https://issues.jboss.org/browse/WFLY-7304
>             Project: WildFly
>          Issue Type: Task
>          Components: Transactions
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 07:12:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 13 Oct 2016 07:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7305) Getting identity by DN in
 Elytron ldap-realm should be case insensitive
In-Reply-To: <JIRA.12654645.1476357069000@Atlassian.JIRA>
References: <JIRA.12654645.1476357069000@Atlassian.JIRA>
	<JIRA.12654645.1476357069566@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654645.1476357069000.19813.1476357120482@Atlassian.JIRA>

Ondrej Lukas created WFLY-7305:
----------------------------------

             Summary: Getting identity by DN in Elytron ldap-realm should be case insensitive
                 Key: WFLY-7305
                 URL: https://issues.jboss.org/browse/WFLY-7305
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. 

LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 07:12:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 13 Oct 2016 07:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7305) Getting identity by DN in
 Elytron ldap-realm should be case insensitive
In-Reply-To: <JIRA.12654645.1476357070000@Atlassian.JIRA>
References: <JIRA.12654645.1476357070000@Atlassian.JIRA>
	<JIRA.12654645.1476357070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654645.1476357070000.19822.1476357120769@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7305:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Getting identity by DN in Elytron ldap-realm should be case insensitive
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7305
>                 URL: https://issues.jboss.org/browse/WFLY-7305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. 
> LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 07:42:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 13 Oct 2016 07:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7306) Empty result of password
 search in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654658.1476358890000@Atlassian.JIRA>
References: <JIRA.12654658.1476358890000@Atlassian.JIRA>
	<JIRA.12654658.1476358890869@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654658.1476358890000.20005.1476358921341@Atlassian.JIRA>

Ondrej Lukas created WFLY-7306:
----------------------------------

             Summary: Empty result of password search in Elytron ldap-realm causes NPE
                 Key: WFLY-7306
                 URL: https://issues.jboss.org/browse/WFLY-7306
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


In case when Elytron ldap-realm is configured to return some attribute as password (i.e. direct verification is set to false) and LDAP search does not find this attribute, then NPE occurs.

It is caused by missing null check for {{attribute}} in [1].

Exception thrown to server log:
{code}
ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.NullPointerException
	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.getCredential(UserPasswordCredentialLoader.java:130)
	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.verifyEvidence(UserPasswordCredentialLoader.java:151)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:531)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
	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}

[1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/UserPasswordCredentialLoader.java#L129



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 07:43:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 13 Oct 2016 07:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7306) Empty result of password
 search in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654658.1476358891000@Atlassian.JIRA>
References: <JIRA.12654658.1476358891000@Atlassian.JIRA>
	<JIRA.12654658.1476358891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654658.1476358891000.20014.1476358980223@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7306:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Empty result of password search in Elytron ldap-realm causes NPE
> ----------------------------------------------------------------
>
>                 Key: WFLY-7306
>                 URL: https://issues.jboss.org/browse/WFLY-7306
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when Elytron ldap-realm is configured to return some attribute as password (i.e. direct verification is set to false) and LDAP search does not find this attribute, then NPE occurs.
> It is caused by missing null check for {{attribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.getCredential(UserPasswordCredentialLoader.java:130)
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.verifyEvidence(UserPasswordCredentialLoader.java:151)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:531)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/UserPasswordCredentialLoader.java#L129



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 07:58:00 2016
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Thu, 13 Oct 2016 07:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7307) Some XTS tests fail with
	security manager
In-Reply-To: <JIRA.12654662.1476359866000@Atlassian.JIRA>
References: <JIRA.12654662.1476359866000@Atlassian.JIRA>
	<JIRA.12654662.1476359866053@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654662.1476359866000.20093.1476359880159@Atlassian.JIRA>

Jan Tymel created WFLY-7307:
-------------------------------

             Summary: Some XTS tests fail with security manager
                 Key: WFLY-7307
                 URL: https://issues.jboss.org/browse/WFLY-7307
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Jan Tymel
            Assignee: Jan Tymel


*org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorApplicationException*
*org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorCannotComplete*
*org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorClientCancel*
*org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorCompletionFailToComplete*
*org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSimple*
*org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSingle*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=BACoordinatorCompletionTestCase -Dsecurity.manager}}

{code}
13:49:00,854 ERROR [stderr] (default task-1) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/wsba-coordinatorcompletition-test.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.wsba-coordinatorcompletition-test.war:main" from Service Module Loader")
13:49:00,856 ERROR [stderr] (default task-1) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
13:49:00,857 ERROR [stderr] (default task-1) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
13:49:00,859 ERROR [stderr] (default task-1) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
13:49:00,872 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
13:49:00,873 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
13:49:00,874 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
13:49:00,874 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
13:49:00,886 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
13:49:00,890 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
13:49:00,891 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
13:49:00,894 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
13:49:00,895 ERROR [stderr] (default task-1) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
13:49:00,898 ERROR [stderr] (default task-1) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
13:49:00,899 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
13:49:00,900 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
13:49:00,901 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
13:49:00,908 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
13:49:00,909 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:49:00,910 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
13:49:00,911 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
13:49:00,911 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:49:00,916 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
13:49:00,917 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
13:49:00,918 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
13:49:00,920 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
13:49:00,923 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
13:49:00,924 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
13:49:00,925 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:49:00,927 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
13:49:00,928 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:49:00,929 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:49:00,930 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
13:49:00,931 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
13:49:00,933 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
13:49:00,934 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
13:49:00,935 ERROR [stderr] (default task-1) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
13:49:00,935 ERROR [stderr] (default task-1) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
13:49:00,939 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
13:49:00,940 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:49:00,941 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:49:00,942 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:49:00,943 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:49:00,944 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
13:49:00,944 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
13:49:00,945 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
13:49:00,946 ERROR [stderr] (default task-1) 	at java.security.AccessController.doPrivileged(Native Method)
13:49:00,947 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
13:49:00,948 ERROR [stderr] (default task-1) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
13:49:00,952 ERROR [stderr] (default task-1) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
13:49:00,953 ERROR [stderr] (default task-1) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
13:49:00,955 ERROR [stderr] (default task-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
13:49:00,956 ERROR [stderr] (default task-1) 	at java.lang.Thread.run(Thread.java:745)
{code}


*org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATApplicationException*
*org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATApplicationExceptionCommit*
*org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATClientRollback*
*org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATRollbackOnly*
*org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATSimple*
*org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATSingleSimple*
*org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteReadOnly*
*org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteRollback*
*org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteRollbackPrePrepare*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=ATTestCase -Dsecurity.manager}}

{code}
13:52:13,655 ERROR [stderr] (default task-2) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/wsat-test.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.wsat-test.war:main" from Service Module Loader")
13:52:13,656 ERROR [stderr] (default task-2) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
13:52:13,657 ERROR [stderr] (default task-2) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
13:52:13,658 ERROR [stderr] (default task-2) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
13:52:13,658 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
13:52:13,659 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
13:52:13,660 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
13:52:13,660 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
13:52:13,661 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
13:52:13,662 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
13:52:13,662 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
13:52:13,663 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
13:52:13,664 ERROR [stderr] (default task-2) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
13:52:13,664 ERROR [stderr] (default task-2) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
13:52:13,665 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
13:52:13,666 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
13:52:13,666 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
13:52:13,667 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
13:52:13,668 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:52:13,668 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
13:52:13,669 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
13:52:13,669 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:52:13,670 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
13:52:13,671 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
13:52:13,671 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
13:52:13,672 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
13:52:13,673 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
13:52:13,673 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
13:52:13,674 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:52:13,677 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
13:52:13,678 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:52:13,679 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:52:13,680 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
13:52:13,681 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
13:52:13,682 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
13:52:13,683 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
13:52:13,684 ERROR [stderr] (default task-2) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
13:52:13,685 ERROR [stderr] (default task-2) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
13:52:13,685 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
13:52:13,686 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:52:13,687 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:52:13,689 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:52:13,690 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:52:13,691 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
13:52:13,692 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
13:52:13,693 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
13:52:13,694 ERROR [stderr] (default task-2) 	at java.security.AccessController.doPrivileged(Native Method)
13:52:13,695 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
13:52:13,696 ERROR [stderr] (default task-2) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
13:52:13,696 ERROR [stderr] (default task-2) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
13:52:13,698 ERROR [stderr] (default task-2) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
13:52:13,699 ERROR [stderr] (default task-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
13:52:13,699 ERROR [stderr] (default task-2) 	at java.lang.Thread.run(Thread.java:745)
{code}


*org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testActiveTransaction*
*org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testNoTransaction*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=TransactionalTestCase -Dsecurity.manager}}

{code}
13:53:42,849 ERROR [stderr] (default task-6) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/transactional-test.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.transactional-test.war:main" from Service Module Loader")
13:53:42,854 ERROR [stderr] (default task-6) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
13:53:42,855 ERROR [stderr] (default task-6) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
13:53:42,855 ERROR [stderr] (default task-6) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
13:53:42,856 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
13:53:42,858 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
13:53:42,859 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
13:53:42,859 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
13:53:42,860 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
13:53:42,861 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
13:53:42,861 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
13:53:42,862 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
13:53:42,863 ERROR [stderr] (default task-6) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
13:53:42,863 ERROR [stderr] (default task-6) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
13:53:42,864 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
13:53:42,865 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
13:53:42,865 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
13:53:42,866 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
13:53:42,866 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:53:42,867 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
13:53:42,867 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
13:53:42,868 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:53:42,868 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
13:53:42,869 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
13:53:42,869 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
13:53:42,870 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
13:53:42,870 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
13:53:42,871 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
13:53:42,871 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:53:42,872 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
13:53:42,872 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:53:42,873 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:53:42,873 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
13:53:42,874 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
13:53:42,874 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
13:53:42,875 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
13:53:42,875 ERROR [stderr] (default task-6) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
13:53:42,875 ERROR [stderr] (default task-6) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
13:53:42,876 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
13:53:42,878 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:53:42,880 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:53:42,881 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:53:42,882 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:53:42,882 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
13:53:42,883 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
13:53:42,883 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
13:53:42,884 ERROR [stderr] (default task-6) 	at java.security.AccessController.doPrivileged(Native Method)
13:53:42,885 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
13:53:42,885 ERROR [stderr] (default task-6) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
13:53:42,886 ERROR [stderr] (default task-6) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
13:53:42,886 ERROR [stderr] (default task-6) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
13:53:42,887 ERROR [stderr] (default task-6) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
13:53:42,887 ERROR [stderr] (default task-6) 	at java.lang.Thread.run(Thread.java:745)
{code}

*org.jboss.as.test.xts.annotation.client.CompensatableTestCase#testActiveTransaction*
*org.jboss.as.test.xts.annotation.client.CompensatableTestCase#testNoTransaction*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=CompensatableTestCase -Dsecurity.manager}}

{code}
13:55:03,742 ERROR [stderr] (default task-6) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/compensatable-test.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.compensatable-test.war:main" from Service Module Loader")
13:55:03,743 ERROR [stderr] (default task-6) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
13:55:03,744 ERROR [stderr] (default task-6) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
13:55:03,745 ERROR [stderr] (default task-6) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
13:55:03,745 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
13:55:03,746 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
13:55:03,747 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
13:55:03,747 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
13:55:03,748 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
13:55:03,749 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
13:55:03,749 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
13:55:03,750 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
13:55:03,750 ERROR [stderr] (default task-6) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
13:55:03,751 ERROR [stderr] (default task-6) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
13:55:03,752 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
13:55:03,752 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
13:55:03,753 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
13:55:03,753 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
13:55:03,757 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:55:03,758 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
13:55:03,758 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
13:55:03,759 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:55:03,759 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
13:55:03,760 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
13:55:03,760 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
13:55:03,761 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
13:55:03,762 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
13:55:03,762 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
13:55:03,763 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:55:03,763 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
13:55:03,764 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:55:03,765 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
13:55:03,766 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
13:55:03,766 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
13:55:03,767 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
13:55:03,769 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
13:55:03,774 ERROR [stderr] (default task-6) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
13:55:03,775 ERROR [stderr] (default task-6) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
13:55:03,776 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
13:55:03,776 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:55:03,777 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:55:03,777 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:55:03,778 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
13:55:03,779 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
13:55:03,779 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
13:55:03,780 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
13:55:03,781 ERROR [stderr] (default task-6) 	at java.security.AccessController.doPrivileged(Native Method)
13:55:03,782 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
13:55:03,783 ERROR [stderr] (default task-6) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
13:55:03,783 ERROR [stderr] (default task-6) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
13:55:03,784 ERROR [stderr] (default task-6) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
13:55:03,785 ERROR [stderr] (default task-6) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
13:55:03,786 ERROR [stderr] (default task-6) 	at java.lang.Thread.run(Thread.java:745)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 08:08:00 2016
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Thu, 13 Oct 2016 08:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7308) JspELTestCase fails with
	security manager
In-Reply-To: <JIRA.12654667.1476360442000@Atlassian.JIRA>
References: <JIRA.12654667.1476360442000@Atlassian.JIRA>
	<JIRA.12654667.1476360442293@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654667.1476360442000.20170.1476360480277@Atlassian.JIRA>

Jan Tymel created WFLY-7308:
-------------------------------

             Summary: JspELTestCase fails with security manager
                 Key: WFLY-7308
                 URL: https://issues.jboss.org/browse/WFLY-7308
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Jan Tymel
            Assignee: Jan Tymel


*org.wildfly.test.integration.jsp.JspELTestCase#testJavaLangImplicitClassELEvaluation*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=JspELTestCase -Dsecurity.manager}}

{code}
ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /d0ead681-8b75-48ba-8af6-7f08323da424/index.jsp: org.apache.jasper.JasperException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/d0ead681-8b75-48ba-8af6-7f08323da424.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader at 14183b28")
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
	at java.security.AccessController.doPrivileged(Native Method)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
	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)
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/d0ead681-8b75-48ba-8af6-7f08323da424.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader at 14183b28")
	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
	at java.lang.Thread.getContextClassLoader(Thread.java:1440)
	at javax.el.ImportHandler.getClassFor(ImportHandler.java:176)
	at javax.el.ImportHandler.resolveClassFor(ImportHandler.java:165)
	at javax.el.ImportHandler.resolveClass(ImportHandler.java:128)
	at org.wildfly.extension.undertow.ImportedClassELResolver.getValue(ImportedClassELResolver.java:58)
	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:96)
	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116)
	at com.sun.el.parser.AstValue.getBase(AstValue.java:150)
	at com.sun.el.parser.AstValue.getValue(AstValue.java:199)
	at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
	at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:917)
	at org.apache.jsp.index_jsp._jspService(index_jsp.java:100)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
	... 43 more
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 08:21:00 2016
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 13 Oct 2016 08:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6960) SFSB concurrent access
 timeout when the bean defines CDI producer for another SFSB
In-Reply-To: <JIRA.12643553.1471352454000@Atlassian.JIRA>
References: <JIRA.12643553.1471352454000@Atlassian.JIRA>
	<JIRA.12643553.1471352454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643553.1471352454000.20218.1476361260808@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated WFLY-6960:
--------------------------------
    Attachment: 0001-Use-EJB-as-opposed-to-Inject.patch


Please try with {{@EJB}} as opposed to {{@Inject}} in SFBean3.

> SFSB concurrent access timeout when the bean defines CDI producer for another SFSB
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-6960
>                 URL: https://issues.jboss.org/browse/WFLY-6960
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Enrique Gonz?lez Mart?nez
>         Attachments: 0001-Use-EJB-as-opposed-to-Inject.patch, test-case.zip
>
>
> In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to:
> {noformat}
> 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> 	at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99)
> 	at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
> 	at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181)
> 	at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742)
> 	at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140)
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70)
> 	at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53)
> 	at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61)
> 	at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149)
> 	at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 13 08:59:02 2016
From: issues at jboss.org (=?UTF-8?Q?Enrique_Gonz=C3=A1lez_Mart=C3=ADnez_=28JIRA=29?=)
Date: Thu, 13 Oct 2016 08:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6960) SFSB concurrent access
 timeout when the bean defines CDI producer for another SFSB
In-Reply-To: <JIRA.12643553.1471352454000@Atlassian.JIRA>
References: <JIRA.12643553.1471352454000@Atlassian.JIRA>
	<JIRA.12643553.1471352454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643553.1471352454000.20471.1476363542081@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306631#comment-13306631 ] 

Enrique Gonz?lez Mart?nez commented on WFLY-6960:
-------------------------------------------------

I have done already that exercise... but what is the point of doing it if you are not using the cdi container to inject and it is completely different from using @EJB injection ?

> SFSB concurrent access timeout when the bean defines CDI producer for another SFSB
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-6960
>                 URL: https://issues.jboss.org/browse/WFLY-6960
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Enrique Gonz?lez Mart?nez
>         Attachments: 0001-Use-EJB-as-opposed-to-Inject.patch, test-case.zip
>
>
> In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to:
> {noformat}
> 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> 	at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99)
> 	at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
> 	at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181)
> 	at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742)
> 	at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140)
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70)
> 	at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53)
> 	at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61)
> 	at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149)
> 	at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 13 09:03:00 2016
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Thu, 13 Oct 2016 09:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6937) Some JMS tests fail with
	security manager
In-Reply-To: <JIRA.12642680.1470810463000@Atlassian.JIRA>
References: <JIRA.12642680.1470810463000@Atlassian.JIRA>
	<JIRA.12642680.1470810463000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642680.1470810463000.20513.1476363780476@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel closed WFLY-6937.
---------------------------
    Resolution: Done


This issue is no longer valid. Feel free to reopen if this issue occurs again in the future.

> Some JMS tests fail with security manager
> -----------------------------------------
>
>                 Key: WFLY-6937
>                 URL: https://issues.jboss.org/browse/WFLY-6937
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Jan Tymel
>
> *org.jboss.as.test.integration.messaging.jms.context.VaultedInjectedJMSContextTestCase#sendMessage*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.messaging.jms.context.VaultedInjectedJMSContextTestCase#sendMessage -Dsecurity.manager}}
> Fails with:
> {code}
> WARN  [org.apache.activemq.artemis.core.client] (pool-3-thread-1) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/VaultedInjectedJMSContextTestCase.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.Class.checkMemberAccess(Class.java:2348)
> 	at java.lang.Class.getDeclaredFields(Class.java:1915)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:938)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:896)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.init(AbstractChannelHandlerContext.java:968)
> 	at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.newInstance(AbstractChannelHandlerContext.java:1044)
> 	at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.access$1600(AbstractChannelHandlerContext.java:1032)
> 	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:707)
> 	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:691)
> 	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:717)
> 	at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:954)
> 	at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:244)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:662)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1009)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1053)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1232)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:867)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:769)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:760)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createContext(ActiveMQConnectionFactory.java:255)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.AbstractJMSContext.createContext(AbstractJMSContext.java:64)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.AbstractJMSContext.getContext(AbstractJMSContext.java:49)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.TransactedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:109)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createProducer(JMSContextWrapper.java:66)
> 	at org.jboss.as.test.integration.messaging.jms.context.auxiliary.VaultedMessageProducer.sendToDestination(VaultedMessageProducer.java:47)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.messaging.jms.context.auxiliary.VaultedMessageProducer$$$view5.sendToDestination(Unknown Source)
> 	at org.jboss.as.test.integration.messaging.jms.context.VaultedInjectedJMSContextTestCase.sendMessage(VaultedInjectedJMSContextTestCase.java:171)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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}
> *org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase#testAnnotationBasedDefinitionsWithVaultedAttributes*
> *org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase#testDeploymendDescriptorBasedDefinitionsWithVaultedAttributes*
> *org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase#testInjectedDefinitions*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase -Dsecurity.manager}}
> Fails with:
> {code}
> WARN  [org.apache.activemq.artemis.core.client] (pool-3-thread-2) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/JMSResourceDefinitionsTestCase.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.Class.checkMemberAccess(Class.java:200)
> 	at java.lang.Class.getDeclaredFields(Class.java:823)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:938)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:945)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.estimateSize(AbstractChannelHandlerContext.java:896)
> 	at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.init(AbstractChannelHandlerContext.java:968)
> 	at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.newInstance(AbstractChannelHandlerContext.java:1044)
> 	at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.access$1600(AbstractChannelHandlerContext.java:1032)
> 	at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:707)
> 	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:691)
> 	at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:717)
> 	at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:954)
> 	at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:244)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:662)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1009)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1053)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1232)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:867)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:769)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:760)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXAConnection(ActiveMQConnectionFactory.java:304)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:782)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:163)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:149)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1320)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:699)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:598)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:739)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:467)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:420)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:410)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:405)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean.checkDeploymendDescriptorBasedDefinitionsWithVaultedAttributes(MessagingBean.java:201)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean$$$view238.checkDeploymendDescriptorBasedDefinitionsWithVaultedAttributes(Unknown Source)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase.testDeploymendDescriptorBasedDefinitionsWithVaultedAttributes(JMSResourceDefinitionsTestCase.java:163)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83)
> 	at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at javax.security.auth.Subject.doAs(Subject.java:569)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 	at java.lang.Thread.run(Thread.java:785)
> {code}
> I saw these tests also failing with:
> {code}
> WARN  [org.apache.activemq.artemis.core.client] (pool-3-thread-1) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost" "resolve")" in code source "(vfs:/content/JMSResourceDefinitionsTestCase.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkConnect(SecurityManager.java:1048)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:407)
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1268)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> 	at java.net.InetAddress.getByName(InetAddress.java:1076)
> 	at java.net.InetSocketAddress.<init>(InetSocketAddress.java:220)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:575)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1009)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1053)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1232)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:867)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:769)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:760)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXAConnection(ActiveMQConnectionFactory.java:304)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:782)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:163)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:149)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1320)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:699)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:598)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:739)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:467)
> 	at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:420)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean.checkInjectedResources(MessagingBean.java:182)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean$$$view1.checkInjectedResources(Unknown Source)
> 	at org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase.testInjectedDefinitions(JMSResourceDefinitionsTestCase.java:153)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 09:03:01 2016
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Thu, 13 Oct 2016 09:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6932) LookupTestCase fails with
	security manager
In-Reply-To: <JIRA.12642595.1470746100000@Atlassian.JIRA>
References: <JIRA.12642595.1470746100000@Atlassian.JIRA>
	<JIRA.12642595.1470746100000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642595.1470746100000.20526.1476363781063@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel closed WFLY-6932.
---------------------------
    Resolution: Done


This issue is no longer valid. Feel free to reopen if this issue occurs again in the future.

> LookupTestCase fails with security manager
> ------------------------------------------
>
>                 Key: WFLY-6932
>                 URL: https://issues.jboss.org/browse/WFLY-6932
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Jan Tymel
>
> *org.jboss.as.test.integration.ee.remotelookup.LookupTestCase#testServerLocalLookup*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.remotelookup.LookupTestCase#testServerLocalLookup -Dsecurity.manager}}
> Fails with:
> {code}
> WARN  [org.apache.activemq.artemis.core.client] (pool-3-thread-1) AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost" "resolve")" in code source "(vfs:/content/deploy.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkConnect(SecurityManager.java:1048)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:407)
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1268)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> 	at java.net.InetAddress.getByName(InetAddress.java:1076)
> 	at java.net.InetSocketAddress.<init>(InetSocketAddress.java:220)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:575)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1009)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1053)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1232)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:867)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:769)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:760)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
> 	at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.lookupConnectionFactory(LookupTestCase.java:81)
> 	at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.testServerLocalLookup(LookupTestCase.java:66)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 09:05:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 13 Oct 2016 09:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6960) SFSB concurrent access
 timeout when the bean defines CDI producer for another SFSB
In-Reply-To: <JIRA.12643553.1471352454000@Atlassian.JIRA>
References: <JIRA.12643553.1471352454000@Atlassian.JIRA>
	<JIRA.12643553.1471352454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643553.1471352454000.20540.1476363900308@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306641#comment-13306641 ] 

Tomas Remes commented on WFLY-6960:
-----------------------------------

[~elguardian] yes +1. 

So workaround is to use CDI but it's not so good one.

> SFSB concurrent access timeout when the bean defines CDI producer for another SFSB
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-6960
>                 URL: https://issues.jboss.org/browse/WFLY-6960
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Enrique Gonz?lez Mart?nez
>         Attachments: 0001-Use-EJB-as-opposed-to-Inject.patch, test-case.zip
>
>
> In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to:
> {noformat}
> 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> 	at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99)
> 	at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
> 	at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181)
> 	at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742)
> 	at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140)
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70)
> 	at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53)
> 	at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61)
> 	at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149)
> 	at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 13 09:15:03 2016
From: issues at jboss.org (=?UTF-8?Q?Enrique_Gonz=C3=A1lez_Mart=C3=ADnez_=28JIRA=29?=)
Date: Thu, 13 Oct 2016 09:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6960) SFSB concurrent access
 timeout when the bean defines CDI producer for another SFSB
In-Reply-To: <JIRA.12643553.1471352454000@Atlassian.JIRA>
References: <JIRA.12643553.1471352454000@Atlassian.JIRA>
	<JIRA.12643553.1471352454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643553.1471352454000.20610.1476364503210@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306653#comment-13306653 ] 

Enrique Gonz?lez Mart?nez commented on WFLY-6960:
-------------------------------------------------

the other way round. The workaround is to use @EJB instead of CDI... but they are different ways of injecting stuff AFAIK.

> SFSB concurrent access timeout when the bean defines CDI producer for another SFSB
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-6960
>                 URL: https://issues.jboss.org/browse/WFLY-6960
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Enrique Gonz?lez Mart?nez
>         Attachments: 0001-Use-EJB-as-opposed-to-Inject.patch, test-case.zip
>
>
> In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to:
> {noformat}
> 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> 	at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99)
> 	at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
> 	at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181)
> 	at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742)
> 	at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140)
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70)
> 	at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53)
> 	at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61)
> 	at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149)
> 	at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 13 09:19:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Thu, 13 Oct 2016 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6960) SFSB concurrent access
 timeout when the bean defines CDI producer for another SFSB
In-Reply-To: <JIRA.12643553.1471352454000@Atlassian.JIRA>
References: <JIRA.12643553.1471352454000@Atlassian.JIRA>
	<JIRA.12643553.1471352454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643553.1471352454000.20632.1476364740513@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306656#comment-13306656 ] 

Tomas Remes commented on WFLY-6960:
-----------------------------------

Ah sorry. Sure

> SFSB concurrent access timeout when the bean defines CDI producer for another SFSB
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-6960
>                 URL: https://issues.jboss.org/browse/WFLY-6960
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Enrique Gonz?lez Mart?nez
>         Attachments: 0001-Use-EJB-as-opposed-to-Inject.patch, test-case.zip
>
>
> In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to:
> {noformat}
> 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> 	at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99)
> 	at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
> 	at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181)
> 	at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742)
> 	at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140)
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70)
> 	at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53)
> 	at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61)
> 	at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149)
> 	at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 13 09:55:01 2016
From: issues at jboss.org (Duncan Doyle (JIRA))
Date: Thu, 13 Oct 2016 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1327) Drools declared types
 cannot be references in jBPM Drools expressions due to compilation order.
In-Reply-To: <JIRA.12654698.1476366901000@Atlassian.JIRA>
References: <JIRA.12654698.1476366901000@Atlassian.JIRA>
	<JIRA.12654698.1476366901008@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654698.1476366901000.21000.1476366901696@Atlassian.JIRA>

Duncan Doyle created DROOLS-1327:
------------------------------------

             Summary: Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
                 Key: DROOLS-1327
                 URL: https://issues.jboss.org/browse/DROOLS-1327
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.4.0.Final
         Environment: JBoss BPM Suite 6.3.3.GA
            Reporter: Duncan Doyle
            Assignee: Mario Fusco


When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project.

The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled.

Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 09:56:00 2016
From: issues at jboss.org (Duncan Doyle (JIRA))
Date: Thu, 13 Oct 2016 09:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1327) Drools declared types
 cannot be references in jBPM Drools expressions due to compilation order.
In-Reply-To: <JIRA.12654698.1476366901000@Atlassian.JIRA>
References: <JIRA.12654698.1476366901000@Atlassian.JIRA>
	<JIRA.12654698.1476366901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654698.1476366901000.21003.1476366960323@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Duncan Doyle reassigned DROOLS-1327:
------------------------------------

    Assignee: Duncan Doyle  (was: Mario Fusco)


> Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1327
>                 URL: https://issues.jboss.org/browse/DROOLS-1327
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>         Environment: JBoss BPM Suite 6.3.3.GA
>            Reporter: Duncan Doyle
>            Assignee: Duncan Doyle
>
> When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project.
> The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled.
> Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 10:15:02 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 10:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7309) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654704.1476368088000@Atlassian.JIRA>
References: <JIRA.12654704.1476368088000@Atlassian.JIRA>
	<JIRA.12654704.1476368088929@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654704.1476368088000.21287.1476368102062@Atlassian.JIRA>

Filippe Spolti created WFLY-7309:
------------------------------------

             Summary: Make the authentication configurable in the eap testsuite 
                 Key: WFLY-7309
                 URL: https://issues.jboss.org/browse/WFLY-7309
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Filippe Spolti
            Priority: Optional


Actually some tests cases of EAP's testsuite failes when running against a remote eap instance. 

In this specific case, EAP 6/7 instances running on Openshift v3.
In order to get those tests working we have to modify some classes to configure the authentication.
Example: 

org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:

{code:java}
    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
        return connector.getMBeanServerConnection();

    }
{code}

To:

{code:java}

    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
        String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
        propEnv.put(JMXConnector.CREDENTIALS, credentials);
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
        return connector.getMBeanServerConnection();
    }
{code}


Could these kind of authentication being configurable?
It is important to us because this allows the tests to be executed against the docker images running in openshift.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 10:15:02 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 10:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7309) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654704.1476368089000@Atlassian.JIRA>
References: <JIRA.12654704.1476368089000@Atlassian.JIRA>
	<JIRA.12654704.1476368089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654704.1476368089000.21290.1476368102222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti reassigned WFLY-7309:
------------------------------------

    Assignee: Filippe Spolti


> Make the authentication configurable in the eap testsuite 
> ----------------------------------------------------------
>
>                 Key: WFLY-7309
>                 URL: https://issues.jboss.org/browse/WFLY-7309
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>
> Actually some tests cases of EAP's testsuite failes when running against a remote eap instance. 
> In this specific case, EAP 6/7 instances running on Openshift v3.
> In order to get those tests working we have to modify some classes to configure the authentication.
> Example: 
> org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
>         return connector.getMBeanServerConnection();
>     }
> {code}
> To:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
>         String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
>         propEnv.put(JMXConnector.CREDENTIALS, credentials);
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
>         return connector.getMBeanServerConnection();
>     }
> {code}
> Could these kind of authentication being configurable?
> It is important to us because this allows the tests to be executed against the docker images running in openshift.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 10:16:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 10:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7310) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654705.1476368111000@Atlassian.JIRA>
References: <JIRA.12654705.1476368111000@Atlassian.JIRA>
	<JIRA.12654705.1476368111330@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654705.1476368111000.21295.1476368160576@Atlassian.JIRA>

Filippe Spolti created WFLY-7310:
------------------------------------

             Summary: Make the authentication configurable in the eap testsuite 
                 Key: WFLY-7310
                 URL: https://issues.jboss.org/browse/WFLY-7310
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Filippe Spolti
            Assignee: Filippe Spolti
            Priority: Optional


Actually some tests cases of EAP's testsuite failes when running against a remote eap instance. 

In this specific case, EAP 6/7 instances running on Openshift v3.
In order to get those tests working we have to modify some classes to configure the authentication.
Example: 

org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:

{code:java}
    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
        return connector.getMBeanServerConnection();

    }
{code}

To:

{code:java}

    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
        String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
        propEnv.put(JMXConnector.CREDENTIALS, credentials);
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
        return connector.getMBeanServerConnection();
    }
{code}


Could these kind of authentication being configurable?
It is important to us because this allows the tests to be executed against the docker images running in openshift.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 10:16:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 10:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7310) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654705.1476368111000@Atlassian.JIRA>
References: <JIRA.12654705.1476368111000@Atlassian.JIRA>
	<JIRA.12654705.1476368111000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654705.1476368111000.21302.1476368160783@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti closed WFLY-7310.
--------------------------------
    Resolution: Done


> Make the authentication configurable in the eap testsuite 
> ----------------------------------------------------------
>
>                 Key: WFLY-7310
>                 URL: https://issues.jboss.org/browse/WFLY-7310
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>
> Actually some tests cases of EAP's testsuite failes when running against a remote eap instance. 
> In this specific case, EAP 6/7 instances running on Openshift v3.
> In order to get those tests working we have to modify some classes to configure the authentication.
> Example: 
> org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
>         return connector.getMBeanServerConnection();
>     }
> {code}
> To:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
>         String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
>         propEnv.put(JMXConnector.CREDENTIALS, credentials);
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
>         return connector.getMBeanServerConnection();
>     }
> {code}
> Could these kind of authentication being configurable?
> It is important to us because this allows the tests to be executed against the docker images running in openshift.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 10:19:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7309) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654704.1476368089000@Atlassian.JIRA>
References: <JIRA.12654704.1476368089000@Atlassian.JIRA>
	<JIRA.12654704.1476368089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654704.1476368089000.21327.1476368340727@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti updated WFLY-7309:
---------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1384542


> Make the authentication configurable in the eap testsuite 
> ----------------------------------------------------------
>
>                 Key: WFLY-7309
>                 URL: https://issues.jboss.org/browse/WFLY-7309
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>
> Actually some tests cases of EAP's testsuite failes when running against a remote eap instance. 
> In this specific case, EAP 6/7 instances running on Openshift v3.
> In order to get those tests working we have to modify some classes to configure the authentication.
> Example: 
> org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
>         return connector.getMBeanServerConnection();
>     }
> {code}
> To:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
>         String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
>         propEnv.put(JMXConnector.CREDENTIALS, credentials);
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
>         return connector.getMBeanServerConnection();
>     }
> {code}
> Could these kind of authentication being configurable?
> It is important to us because this allows the tests to be executed against the docker images running in openshift.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 10:26:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 10:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7311) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654708.1476368757000@Atlassian.JIRA>
References: <JIRA.12654708.1476368757000@Atlassian.JIRA>
	<JIRA.12654708.1476368757262@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654708.1476368757000.21418.1476368760473@Atlassian.JIRA>

Filippe Spolti created WFLY-7311:
------------------------------------

             Summary: Make the authentication configurable in the eap testsuite 
                 Key: WFLY-7311
                 URL: https://issues.jboss.org/browse/WFLY-7311
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Filippe Spolti
            Assignee: Filippe Spolti
            Priority: Optional


Actually some tests cases of EAP's testsuite failes when running against a remote eap instance. 

In this specific case, EAP 6/7 instances running on Openshift v3.
In order to get those tests working we have to modify some classes to configure the authentication.
Example: 

org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:

{code:java}
    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
        return connector.getMBeanServerConnection();

    }
{code}

To:

{code:java}

    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
        String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
        propEnv.put(JMXConnector.CREDENTIALS, credentials);
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
        return connector.getMBeanServerConnection();
    }
{code}


Could these kind of authentication being configurable?
It is important to us because this allows the tests to be executed against the docker images running in openshift.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 11:06:00 2016
From: issues at jboss.org (Josef Ludvicek (JIRA))
Date: Thu, 13 Oct 2016 11:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7312) wildfly parent specifies
 *.jbossorg-1 dependency which is not present in maven central
In-Reply-To: <JIRA.12654725.1476371120000@Atlassian.JIRA>
References: <JIRA.12654725.1476371120000@Atlassian.JIRA>
	<JIRA.12654725.1476371120333@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654725.1476371120000.21712.1476371160400@Atlassian.JIRA>

Josef Ludvicek created WFLY-7312:
------------------------------------

             Summary: wildfly parent specifies *.jbossorg-1 dependency which is not present in maven central
                 Key: WFLY-7312
                 URL: https://issues.jboss.org/browse/WFLY-7312
             Project: WildFly
          Issue Type: Bug
            Reporter: Josef Ludvicek
            Assignee: Jason Greene


{{wildfly-parent}} BOM is present in maven central,
but it specifies certain dependencies, which were not published to central and hence breaking the build.

For example
{code:xml}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>org.jboss.fuse.qa</groupId>
	<artifactId>slf4j-reproducer</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.wildfly</groupId>
				<artifactId>wildfly-parent</artifactId>
				<version>10.1.0.Final</version>
				<scope>import</scope>
				<type>pom</type>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<dependencies>
		<dependency>
			<groupId>org.arquillian.cube</groupId>
			<artifactId>arquillian-cube-docker</artifactId>
			<version>1.0.0.Alpha15</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</project>
{code}

fails:
{code}
[ERROR] Failed to execute goal on project slf4j-reproducer: 
Could not resolve dependencies for project org.jboss.fuse.qa:slf4j-reproducer:jar:0.0.1-SNAPSHOT: 
    The following artifacts could not be resolved: org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1, org.slf4j:jcl-over-slf4j:jar:1.7.7.jbossorg-1: 
    Could not find artifact org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
[ERROR] 
{code}

There is workaround - add jboss repository https://repository.jboss.org/nexus/content/groups/public/.

Shouldn't we publish all required artifacts to central to avoid similar problems in future ?




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 11:06:00 2016
From: issues at jboss.org (Josef Ludvicek (JIRA))
Date: Thu, 13 Oct 2016 11:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7312) wildfly parent specifies
 *.jbossorg-1 dependency which is not present in maven central
In-Reply-To: <JIRA.12654725.1476371120000@Atlassian.JIRA>
References: <JIRA.12654725.1476371120000@Atlassian.JIRA>
	<JIRA.12654725.1476371120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654725.1476371120000.21716.1476371160536@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Ludvicek updated WFLY-7312:
---------------------------------
    Affects Version/s: 10.1.0.Final


> wildfly parent specifies *.jbossorg-1 dependency which is not present in maven central
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-7312
>                 URL: https://issues.jboss.org/browse/WFLY-7312
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>            Reporter: Josef Ludvicek
>            Assignee: Jason Greene
>
> {{wildfly-parent}} BOM is present in maven central,
> but it specifies certain dependencies, which were not published to central and hence breaking the build.
> For example
> {code:xml}
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
> 	<modelVersion>4.0.0</modelVersion>
> 	<groupId>org.jboss.fuse.qa</groupId>
> 	<artifactId>slf4j-reproducer</artifactId>
> 	<version>0.0.1-SNAPSHOT</version>
> 	<dependencyManagement>
> 		<dependencies>
> 			<dependency>
> 				<groupId>org.wildfly</groupId>
> 				<artifactId>wildfly-parent</artifactId>
> 				<version>10.1.0.Final</version>
> 				<scope>import</scope>
> 				<type>pom</type>
> 			</dependency>
> 		</dependencies>
> 	</dependencyManagement>
> 	<dependencies>
> 		<dependency>
> 			<groupId>org.arquillian.cube</groupId>
> 			<artifactId>arquillian-cube-docker</artifactId>
> 			<version>1.0.0.Alpha15</version>
> 			<scope>test</scope>
> 		</dependency>
> 	</dependencies>
> </project>
> {code}
> fails:
> {code}
> [ERROR] Failed to execute goal on project slf4j-reproducer: 
> Could not resolve dependencies for project org.jboss.fuse.qa:slf4j-reproducer:jar:0.0.1-SNAPSHOT: 
>     The following artifacts could not be resolved: org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1, org.slf4j:jcl-over-slf4j:jar:1.7.7.jbossorg-1: 
>     Could not find artifact org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
> [ERROR] 
> {code}
> There is workaround - add jboss repository https://repository.jboss.org/nexus/content/groups/public/.
> Shouldn't we publish all required artifacts to central to avoid similar problems in future ?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 11:07:00 2016
From: issues at jboss.org (Josef Ludvicek (JIRA))
Date: Thu, 13 Oct 2016 11:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7312) wildfly parent specifies
 *.jbossorg-1 dependency which is not present in maven central
In-Reply-To: <JIRA.12654725.1476371120000@Atlassian.JIRA>
References: <JIRA.12654725.1476371120000@Atlassian.JIRA>
	<JIRA.12654725.1476371120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654725.1476371120000.21720.1476371220221@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Ludvicek updated WFLY-7312:
---------------------------------
    Description: 
{{wildfly-parent}} BOM is present in maven central,
but itt's {{dependenciesManagement}} section specifies certain dependencies, which were not published to central and hence breaking the build.

For example
{code:xml}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>org.jboss.fuse.qa</groupId>
	<artifactId>slf4j-reproducer</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.wildfly</groupId>
				<artifactId>wildfly-parent</artifactId>
				<version>10.1.0.Final</version>
				<scope>import</scope>
				<type>pom</type>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<dependencies>
		<dependency>
			<groupId>org.arquillian.cube</groupId>
			<artifactId>arquillian-cube-docker</artifactId>
			<version>1.0.0.Alpha15</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</project>
{code}

fails:
{code}
[ERROR] Failed to execute goal on project slf4j-reproducer: 
Could not resolve dependencies for project org.jboss.fuse.qa:slf4j-reproducer:jar:0.0.1-SNAPSHOT: 
    The following artifacts could not be resolved: org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1, org.slf4j:jcl-over-slf4j:jar:1.7.7.jbossorg-1: 
    Could not find artifact org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
[ERROR] 
{code}

There is workaround - add jboss repository https://repository.jboss.org/nexus/content/groups/public/.

Shouldn't we publish all required artifacts to central to avoid similar problems in future ?


  was:
{{wildfly-parent}} BOM is present in maven central,
but it specifies certain dependencies, which were not published to central and hence breaking the build.

For example
{code:xml}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>org.jboss.fuse.qa</groupId>
	<artifactId>slf4j-reproducer</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.wildfly</groupId>
				<artifactId>wildfly-parent</artifactId>
				<version>10.1.0.Final</version>
				<scope>import</scope>
				<type>pom</type>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<dependencies>
		<dependency>
			<groupId>org.arquillian.cube</groupId>
			<artifactId>arquillian-cube-docker</artifactId>
			<version>1.0.0.Alpha15</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</project>
{code}

fails:
{code}
[ERROR] Failed to execute goal on project slf4j-reproducer: 
Could not resolve dependencies for project org.jboss.fuse.qa:slf4j-reproducer:jar:0.0.1-SNAPSHOT: 
    The following artifacts could not be resolved: org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1, org.slf4j:jcl-over-slf4j:jar:1.7.7.jbossorg-1: 
    Could not find artifact org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
[ERROR] 
{code}

There is workaround - add jboss repository https://repository.jboss.org/nexus/content/groups/public/.

Shouldn't we publish all required artifacts to central to avoid similar problems in future ?




> wildfly parent specifies *.jbossorg-1 dependency which is not present in maven central
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-7312
>                 URL: https://issues.jboss.org/browse/WFLY-7312
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>            Reporter: Josef Ludvicek
>            Assignee: Jason Greene
>
> {{wildfly-parent}} BOM is present in maven central,
> but itt's {{dependenciesManagement}} section specifies certain dependencies, which were not published to central and hence breaking the build.
> For example
> {code:xml}
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
> 	<modelVersion>4.0.0</modelVersion>
> 	<groupId>org.jboss.fuse.qa</groupId>
> 	<artifactId>slf4j-reproducer</artifactId>
> 	<version>0.0.1-SNAPSHOT</version>
> 	<dependencyManagement>
> 		<dependencies>
> 			<dependency>
> 				<groupId>org.wildfly</groupId>
> 				<artifactId>wildfly-parent</artifactId>
> 				<version>10.1.0.Final</version>
> 				<scope>import</scope>
> 				<type>pom</type>
> 			</dependency>
> 		</dependencies>
> 	</dependencyManagement>
> 	<dependencies>
> 		<dependency>
> 			<groupId>org.arquillian.cube</groupId>
> 			<artifactId>arquillian-cube-docker</artifactId>
> 			<version>1.0.0.Alpha15</version>
> 			<scope>test</scope>
> 		</dependency>
> 	</dependencies>
> </project>
> {code}
> fails:
> {code}
> [ERROR] Failed to execute goal on project slf4j-reproducer: 
> Could not resolve dependencies for project org.jboss.fuse.qa:slf4j-reproducer:jar:0.0.1-SNAPSHOT: 
>     The following artifacts could not be resolved: org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1, org.slf4j:jcl-over-slf4j:jar:1.7.7.jbossorg-1: 
>     Could not find artifact org.slf4j:slf4j-api:jar:1.7.7.jbossorg-1 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
> [ERROR] 
> {code}
> There is workaround - add jboss repository https://repository.jboss.org/nexus/content/groups/public/.
> Shouldn't we publish all required artifacts to central to avoid similar problems in future ?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 11:10:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 11:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7309) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654704.1476368089000@Atlassian.JIRA>
References: <JIRA.12654704.1476368089000@Atlassian.JIRA>
	<JIRA.12654704.1476368089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654704.1476368089000.21754.1476371400445@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti updated WFLY-7309:
---------------------------------
    Description: 
Actually some tests cases fails when running against a remote eap instance. 

In this specific case instances running on Openshift v3.
In order to get those tests working we have to modify some classes to configure the authentication.
Example: 

org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:

{code:java}
    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
        return connector.getMBeanServerConnection();

    }
{code}

To:

{code:java}

    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
        String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
        propEnv.put(JMXConnector.CREDENTIALS, credentials);
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
        return connector.getMBeanServerConnection();
    }
{code}


Could these kind of authentication being configurable?
It is important to us because this allows the tests to be executed against the docker images running in openshift.

  was:
Actually some tests cases of EAP's testsuite failes when running against a remote eap instance. 

In this specific case, EAP 6/7 instances running on Openshift v3.
In order to get those tests working we have to modify some classes to configure the authentication.
Example: 

org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:

{code:java}
    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
        return connector.getMBeanServerConnection();

    }
{code}

To:

{code:java}

    private MBeanServerConnection getMBeanServerConnection() throws IOException {
        HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
        String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
        propEnv.put(JMXConnector.CREDENTIALS, credentials);
        final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
        connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
        return connector.getMBeanServerConnection();
    }
{code}


Could these kind of authentication being configurable?
It is important to us because this allows the tests to be executed against the docker images running in openshift.



> Make the authentication configurable in the eap testsuite 
> ----------------------------------------------------------
>
>                 Key: WFLY-7309
>                 URL: https://issues.jboss.org/browse/WFLY-7309
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>
> Actually some tests cases fails when running against a remote eap instance. 
> In this specific case instances running on Openshift v3.
> In order to get those tests working we have to modify some classes to configure the authentication.
> Example: 
> org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
>         return connector.getMBeanServerConnection();
>     }
> {code}
> To:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
>         String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
>         propEnv.put(JMXConnector.CREDENTIALS, credentials);
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
>         return connector.getMBeanServerConnection();
>     }
> {code}
> Could these kind of authentication being configurable?
> It is important to us because this allows the tests to be executed against the docker images running in openshift.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 11:29:01 2016
From: issues at jboss.org (andrea tarocchi (JIRA))
Date: Thu, 13 Oct 2016 11:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1328) CEP KieSession
 deserialization NullPointerException with Timer and expiration
In-Reply-To: <JIRA.12654754.1476372481000@Atlassian.JIRA>
References: <JIRA.12654754.1476372481000@Atlassian.JIRA>
	<JIRA.12654754.1476372481932@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654754.1476372481000.22022.1476372541185@Atlassian.JIRA>

andrea tarocchi created DROOLS-1328:
---------------------------------------

             Summary: CEP KieSession deserialization NullPointerException with Timer and expiration
                 Key: DROOLS-1328
                 URL: https://issues.jboss.org/browse/DROOLS-1328
             Project: Drools
          Issue Type: Bug
    Affects Versions: 7.0.0.Beta2
            Reporter: andrea tarocchi
            Assignee: Mario Fusco
            Priority: Critical


When a Cep KieSession containing events with expiration is serialized and then deserialized there is a NullPointerExceptions is thrown:

{code:java}
java.lang.NullPointerException
	at org.drools.core.reteoo.ObjectTypeNode$ExpireJobContextTimerInputMarshaller.deserialize(ObjectTypeNode.java:672)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readTimer(ProtobufInputMarshaller.java:709)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:291)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:162)
	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:116)
	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:52)
	at org.drools.compiler.integrationtests.CepEspTest$1KieSessionByteArraySerializer.readSession(CepEspTest.java:220)
	at org.drools.compiler.integrationtests.CepEspTest.testSerializationDeserliaizationWithRectractedExpireFact(CepEspTest.java:253)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.lang.Thread.run(Thread.java:745)
{code}

you have a reproducer in PR: https://github.com/droolsjbpm/drools/pull/959

Just run:
{code:bash}
cd drools-compiler
mvn clean test -Dtest=CepEspTest#testSerializationDeserliaizationWithRectractedExpireFact
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 11:52:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 13 Oct 2016 11:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-661) Add ability to match URI path
 by pattern or other partial match
In-Reply-To: <JIRA.12654761.1476373898000@Atlassian.JIRA>
References: <JIRA.12654761.1476373898000@Atlassian.JIRA>
	<JIRA.12654761.1476373898634@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654761.1476373898000.22462.1476373920689@Atlassian.JIRA>

David Lloyd created ELY-661:
-------------------------------

             Summary: Add ability to match URI path by pattern or other partial match
                 Key: ELY-661
                 URL: https://issues.jboss.org/browse/ELY-661
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: Authentication Client
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.Beta11


Path matching in the authentication client only matches the whole path which is not ideal.  We need the ability to match paths by prefix and/or wildcard.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 11:58:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 13 Oct 2016 11:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-661) Add ability to match URI path
 by pattern or other partial match
In-Reply-To: <JIRA.12654761.1476373899000@Atlassian.JIRA>
References: <JIRA.12654761.1476373899000@Atlassian.JIRA>
	<JIRA.12654761.1476373899000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654761.1476373899000.22483.1476374280160@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved ELY-661.
-----------------------------
    Resolution: Rejected


Actually the current path matcher is already a prefix matcher. Reopen if we want to add in an exact-only matcher.

> Add ability to match URI path by pattern or other partial match
> ---------------------------------------------------------------
>
>                 Key: ELY-661
>                 URL: https://issues.jboss.org/browse/ELY-661
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.Beta11
>
>
> Path matching in the authentication client only matches the whole path which is not ideal.  We need the ability to match paths by prefix and/or wildcard.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 13:30:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 13 Oct 2016 13:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1329) Events already expired at
 insertion time don't have a chance to produce a match
In-Reply-To: <JIRA.12654770.1476379789000@Atlassian.JIRA>
References: <JIRA.12654770.1476379789000@Atlassian.JIRA>
	<JIRA.12654770.1476379789551@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654770.1476379789000.22864.1476379800130@Atlassian.JIRA>

Mario Fusco created DROOLS-1329:
-----------------------------------

             Summary: Events already expired at insertion time don't have a chance to produce a match
                 Key: DROOLS-1329
                 URL: https://issues.jboss.org/browse/DROOLS-1329
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco


When flushing the insertion of an event that is already expired at processing (firing) time it is required that the event should however have at least a chance to produce joins and activations.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 14:04:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 13 Oct 2016 14:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1330) Events already expired at
 insertion time don't have a chance to produce a match
In-Reply-To: <JIRA.12654772.1476381784000@Atlassian.JIRA>
References: <JIRA.12654772.1476381784000@Atlassian.JIRA>
	<JIRA.12654772.1476381784207@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654772.1476381784000.22908.1476381840645@Atlassian.JIRA>

Mario Fusco created DROOLS-1330:
-----------------------------------

             Summary: Events already expired at insertion time don't have a chance to produce a match
                 Key: DROOLS-1330
                 URL: https://issues.jboss.org/browse/DROOLS-1330
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco


When flushing the insertion of an event that is already expired at processing (firing) time it is required that the event should however have at least a chance to produce joins and activations.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 15:21:00 2016
From: issues at jboss.org (Adrian Boangiu (JIRA))
Date: Thu, 13 Oct 2016 15:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7313) Impossible to use environment
 variables or system properties in permissions.xml
In-Reply-To: <JIRA.12654778.1476386429000@Atlassian.JIRA>
References: <JIRA.12654778.1476386429000@Atlassian.JIRA>
	<JIRA.12654778.1476386429914@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654778.1476386429000.23051.1476386460173@Atlassian.JIRA>

Adrian Boangiu created WFLY-7313:
------------------------------------

             Summary: Impossible to use environment variables or system properties in permissions.xml
                 Key: WFLY-7313
                 URL: https://issues.jboss.org/browse/WFLY-7313
             Project: WildFly
          Issue Type: Feature Request
    Affects Versions: 10.1.0.Final
            Reporter: Adrian Boangiu
            Assignee: Jason Greene
            Priority: Blocker
             Fix For: 10.2.0.Final, 10.1.0.Final






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 15:22:00 2016
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Thu, 13 Oct 2016 15:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Stateful working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.23056.1476386520167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306884#comment-13306884 ] 

Jiri Locker commented on DROOLS-1326:
-------------------------------------

[~ge0ffrey], I can't reproduce locally with current master. I invoke
{noformat}
mvn test -DrunTurtleTests -Dtest=NurseRosteringSolveAllTurtleTest
{noformat}
I also checked out commits from the date when the failed Jenkins build was launched and it didn't help. I suggest re-running the job. If it fails again, either I or the job does something wrong. Any other ideas?

> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-1326
>                 URL: https://issues.jboss.org/browse/DROOLS-1326
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/
> I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 15:25:00 2016
From: issues at jboss.org (Adrian Boangiu (JIRA))
Date: Thu, 13 Oct 2016 15:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7313) Impossible to use environment
 variables or system properties in permissions.xml
In-Reply-To: <JIRA.12654778.1476386430000@Atlassian.JIRA>
References: <JIRA.12654778.1476386430000@Atlassian.JIRA>
	<JIRA.12654778.1476386430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654778.1476386430000.23062.1476386700143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Boangiu updated WFLY-7313:
---------------------------------
    Description: 
Without this feature it is impossible to migrate "variable" Java file permissions such as:

permission java.io.FilePermission "${java.io.tmpdir}","read";
permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";

that were defined in Java policy file up to the version J7


> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-7313
>                 URL: https://issues.jboss.org/browse/WFLY-7313
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 10.1.0.Final
>            Reporter: Adrian Boangiu
>            Assignee: Jason Greene
>            Priority: Blocker
>             Fix For: 10.1.0.Final, 10.2.0.Final
>
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> that were defined in Java policy file up to the version J7



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 15:27:00 2016
From: issues at jboss.org (Adrian Boangiu (JIRA))
Date: Thu, 13 Oct 2016 15:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7313) Impossible to use environment
 variables or system properties in permissions.xml
In-Reply-To: <JIRA.12654778.1476386430000@Atlassian.JIRA>
References: <JIRA.12654778.1476386430000@Atlassian.JIRA>
	<JIRA.12654778.1476386430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654778.1476386430000.23068.1476386820250@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Boangiu updated WFLY-7313:
---------------------------------
    Description: 
Without this feature it is impossible to migrate "variable" Java file permissions such as:

permission java.io.FilePermission "${java.io.tmpdir}","read";
permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";

that were defined in Java policy file in previous verions of JBoss.

  was:
Without this feature it is impossible to migrate "variable" Java file permissions such as:

permission java.io.FilePermission "${java.io.tmpdir}","read";
permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";

that were defined in Java policy file up to the version J7



> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-7313
>                 URL: https://issues.jboss.org/browse/WFLY-7313
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 10.1.0.Final
>            Reporter: Adrian Boangiu
>            Assignee: Jason Greene
>            Priority: Blocker
>             Fix For: 10.1.0.Final, 10.2.0.Final
>
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> that were defined in Java policy file in previous verions of JBoss.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 17:09:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 17:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1865) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654788.1476392914000@Atlassian.JIRA>
References: <JIRA.12654788.1476392914000@Atlassian.JIRA>
	<JIRA.12654788.1476392914469@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654788.1476392914000.23362.1476392940315@Atlassian.JIRA>

Filippe Spolti created WFCORE-1865:
--------------------------------------

             Summary: Make the authentication configurable in the eap testsuite
                 Key: WFCORE-1865
                 URL: https://issues.jboss.org/browse/WFCORE-1865
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Test Suite
            Reporter: Filippe Spolti
            Assignee: Filippe Spolti
            Priority: Optional






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 17:09:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 17:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1866) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654789.1476392929000@Atlassian.JIRA>
References: <JIRA.12654789.1476392929000@Atlassian.JIRA>
	<JIRA.12654789.1476392929431@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654789.1476392929000.23367.1476392940450@Atlassian.JIRA>

Filippe Spolti created WFCORE-1866:
--------------------------------------

             Summary: Make the authentication configurable in the eap testsuite
                 Key: WFCORE-1866
                 URL: https://issues.jboss.org/browse/WFCORE-1866
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Test Suite
            Reporter: Filippe Spolti
            Assignee: Filippe Spolti
            Priority: Optional






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 17:14:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 13 Oct 2016 17:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1866) Make the authentication
 configurable in the eap testsuite
In-Reply-To: <JIRA.12654789.1476392929000@Atlassian.JIRA>
References: <JIRA.12654789.1476392929000@Atlassian.JIRA>
	<JIRA.12654789.1476392929000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654789.1476392929000.23376.1476393240213@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti closed WFCORE-1866.
----------------------------------
    Resolution: Done


> Make the authentication configurable in the eap testsuite
> ---------------------------------------------------------
>
>                 Key: WFCORE-1866
>                 URL: https://issues.jboss.org/browse/WFCORE-1866
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 18:00:01 2016
From: issues at jboss.org (Darryl Miles (JIRA))
Date: Thu, 13 Oct 2016 18:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6663) NPE
 o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
In-Reply-To: <JIRA.12628823.1464727640000@Atlassian.JIRA>
References: <JIRA.12628823.1464727640000@Atlassian.JIRA>
	<JIRA.12628823.1464727640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628823.1464727640000.23417.1476396001706@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306917#comment-13306917 ] 

Darryl Miles commented on WFLY-6663:
------------------------------------

Just to report back some good news.
I built wildfly 10.1.0.Final.  Then cherry-pick this pull request patch.  Then rebuilt.  Then replaced wildfly-ejb3-10.1.0.Final.jar and I have not seen the issue I am reporting here occur.
Thanks for patch.

> NPE o.j.a.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6663
>                 URL: https://issues.jboss.org/browse/WFLY-6663
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>         Environment: Win7 64bit + JDK8 64bit
>            Reporter: Darryl Miles
>            Assignee: Stuart Douglas
>
> 1 in 8 deployments fail to deploy, usually a redeploy fixes it.
> If there is anyway to get a module state logging out of it, I can send over two logs to compare, one that deploy ok and one that fails.  I guess there is a race bug there somewhere.
> 09:42:01,687 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 529) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	... 26 more
> Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> 	... 43 more
> Caused by: java.lang.RuntimeException: WFLYEJB0423: Could not create session for stateful bean MainEjbImpl
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:99)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> 	... 48 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.openSession(LocalEjbReceiver.java:296)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:176)
> 	at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:97)
> 	... 49 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 13 18:26:00 2016
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Thu, 13 Oct 2016 18:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-898) Rename drools-osgi* modules
	to kie-osgi*
In-Reply-To: <JIRA.12583288.1441028797000@Atlassian.JIRA>
References: <JIRA.12583288.1441028797000@Atlassian.JIRA>
	<JIRA.12583288.1441028797000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583288.1441028797000.23434.1476397560059@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306921#comment-13306921 ] 

Petr ?irok? commented on DROOLS-898:
------------------------------------

Steps needed for upgrade described in https://github.com/droolsjbpm/drools-website/blob/master/download/upgradeRecipe/upgradeRecipe7.0.adoc

> Rename drools-osgi* modules to kie-osgi*
> ----------------------------------------
>
>                 Key: DROOLS-898
>                 URL: https://issues.jboss.org/browse/DROOLS-898
>             Project: Drools
>          Issue Type: Task
>          Components: build
>    Affects Versions: 6.3.0.CR2
>            Reporter: Petr ?irok?
>            Assignee: Petr ?irok?
>
> The {{drools-osgi}} module no longer contains only Drools specific integration. For quite some time there is also jBPM related code and recently also OptaPlanner. We should rename the module to {{kie-osgi}} to be consistent with the other components (e.g. {{kie-maven-plugin}}, {{kie-server}}, etc)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 14 02:48:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 14 Oct 2016 02:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7314) Elytron new-item-attributes
 are not serialized into standalone.xml
In-Reply-To: <JIRA.12654801.1476427606000@Atlassian.JIRA>
References: <JIRA.12654801.1476427606000@Atlassian.JIRA>
	<JIRA.12654801.1476427606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654801.1476427606000.23678.1476427680607@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6428 to WFLY-7314:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7314  (was: JBEAP-6428)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Elytron new-item-attributes are not serialized into standalone.xml
> ------------------------------------------------------------------
>
>                 Key: WFLY-7314
>                 URL: https://issues.jboss.org/browse/WFLY-7314
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Critical
>
> {{new-item-attributes}}  of {{ldap-key-store}} doesn't survive restart of server.
> See steps to reproduce for details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 02:58:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 02:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Stateful working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.23698.1476428280473@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306958#comment-13306958 ] 

Geoffrey De Smet commented on DROOLS-1326:
------------------------------------------

[~jlocker] go in SolveAllTurtleTest (the superclass) and play with the time spends... and this is where it sucks:
those turtle tests run 3 solvers (2 minutes, 5 minutes and 3 minutes for a total of 10 minutes):

{code}
        Solution_ planningProblem = readPlanningProblem();
        // Specifically use NON_INTRUSIVE_FULL_ASSERT instead of FULL_ASSERT to flush out bugs hidden by intrusiveness
        // 1) NON_INTRUSIVE_FULL_ASSERT ASSERT to find CH bugs (but covers little ground)
        planningProblem = buildAndSolve(solverFactory, EnvironmentMode.NON_INTRUSIVE_FULL_ASSERT, planningProblem, 2L);
        // 2) FAST_ASSERT to run past CH into LS to find easy bugs (but covers much ground)
        planningProblem = buildAndSolve(solverFactory, EnvironmentMode.FAST_ASSERT, planningProblem, 5L);
        // 3) NON_INTRUSIVE_FULL_ASSERT ASSERT to find LS bugs (but covers little ground)
        planningProblem = buildAndSolve(solverFactory, EnvironmentMode.NON_INTRUSIVE_FULL_ASSERT, planningProblem, 3L);
{code}

You need to mimic this output:

{code}
016-10-11 12:44:26,305 [main] INFO  Opened: data/nurserostering/unsolved/long_hint01.xml
2016-10-11 12:44:26,592 [main] INFO  Solving started: time spent (63), best score (-740init/0hard/-1580soft), environment mode (NON_INTRUSIVE_FULL_ASSERT), random (JDK with seed 0).
2016-10-11 12:46:26,542 [main] INFO  Construction Heuristic phase (0) ended: time spent (120013), best score (-337init/0hard/-580soft), score calculation speed (167/sec), step total (403).
2016-10-11 12:46:26,543 [main] INFO  Solving ended: time spent (120014), best score (-337init/0hard/-580soft), score calculation speed (167/sec), phase total (2), environment mode (NON_INTRUSIVE_FULL_ASSERT).
2016-10-11 12:46:26,882 [main] INFO  Solving started: time spent (97), best score (-337init/0hard/-580soft), environment mode (FAST_ASSERT), random (JDK with seed 0).
2016-10-11 12:46:28,889 [main] INFO  Construction Heuristic phase (0) ended: time spent (2104), best score (0hard/-175soft), score calculation speed (17127/sec), step total (337).
2016-10-11 12:51:26,785 [main] INFO  Local Search phase (1) ended: time spent (300000), best score (0hard/-74soft), score calculation speed (6848/sec), step total (1233).
2016-10-11 12:51:26,785 [main] INFO  Solving ended: time spent (300000), best score (0hard/-74soft), score calculation speed (6914/sec), phase total (2), environment mode (FAST_ASSERT).
2016-10-11 12:51:27,164 [main] INFO  Solving started: time spent (157), best score (0hard/-74soft), environment mode (NON_INTRUSIVE_FULL_ASSERT), random (JDK with seed 0).
2016-10-11 12:51:27,165 [main] INFO  Construction Heuristic phase (0) ended: time spent (158), best score (0hard/-74soft), score calculation speed (1000/sec), step total (0).
{code}

As this happens in the 3th solver, this isn't easy to reproduce, but it is possible: use stepCountLimit to get the exact same return state of the first solver and then the second solver and then just run the 3th solver for a long time (in case your cpu is slower than jenkins's), it should hit it.

> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-1326
>                 URL: https://issues.jboss.org/browse/DROOLS-1326
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/
> I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 03:29:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 03:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to add trust-manager
 with ldap-key-store (classloading)
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.23886.1476430141042@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7278:
-----------------------------
    Steps to Reproduce: 
{code:java}
/subsystem=elytron/dir-context=DC1:add(url="ldap://localhost:10389/", authentication-level=none)
/subsystem=elytron/ldap-key-store=LKS1/:add(dir-context=DC1, search-path="ou=keystore,dc=elytron,dc=wildfly,dc=org")
/subsystem=elytron/trust-managers=MyTrustManager/:add(algorithm=SunX509, key-store=LKS1)
{code}
{code:java}
/subsystem=elytron/dir-context=DC1:add(url="ldap://localhost:10389/", authentication-level=none)
/subsystem=elytron/ldap-key-store=LKS1/:add(dir-context=DC2,search-path="ou=keystore,dc=example,dc=com",search-recursive=true)
/subsystem=elytron/ldap-key-store=LKS1:remove
{code}

  was:
{code:java}
/subsystem=elytron/ldap-key-store=LKS1/:add(dir-context=Ldap1, search-path="ou=keystore,dc=elytron,dc=wildfly,dc=org")
/subsystem=elytron/trust-managers=MyTrustManager/:add(algorithm=SunX509, key-store=LKS1)
{code}



> Unable to add trust-manager with ldap-key-store (classloading)
> --------------------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 03:38:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 14 Oct 2016 03:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7289) Adding ldap-key-store
 requires accessible ldap server
In-Reply-To: <JIRA.12654219.1476189896000@Atlassian.JIRA>
References: <JIRA.12654219.1476189896000@Atlassian.JIRA>
	<JIRA.12654219.1476189896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654219.1476189896000.23916.1476430680443@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306981#comment-13306981 ] 

Martin Choma commented on WFLY-7289:
------------------------------------

And also could not start EAP if LDAP is down. Also seems like any CLI operation on resource (even read operation) cause LDAP server is touched.
{code} 
[standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=c:read-attribute(name=new-item-path)
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
    "rolled-back" => true
}
{code}

Based on this findings going to raise priority.

> Adding ldap-key-store requires accessible ldap server
> -----------------------------------------------------
>
>                 Key: WFLY-7289
>                 URL: https://issues.jboss.org/browse/WFLY-7289
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>
> Playing with ldap-key-store . What I consider very unconvenient is fact, that in moment of adding ldap-key-store, ldap server has to be running and accessible. Elytron ldap-realm does not need that. Doubt about legacy security realms. Is it possible to decouple that dependency and leave that check till first ldap-key-store usage?
> Steps to reproduce:
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=a:add()
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=a:add(dir-context=a, search-path="a")
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> {code}
> leads to exception in server log
> {code}
> 14:37:25,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
>     "address" => [
>         ("subsystem" => "elytron"),
>         ("ldap-key-store" => "a")
>     ],
>     "operation" => "add",
>     "search-path" => "a",
>     "dir-context" => "a",
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE"
>     }
> }]: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildTypes(AbstractModelResource.java:372)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:787)
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:520)
> 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:758)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:709)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: Cannot parse url: undefined [Root exception is java.net.MalformedURLException: Invalid URI: undefined]
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:92)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:163)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 39 more
> Caused by: java.net.MalformedURLException: Invalid URI: undefined
> 	at com.sun.jndi.toolkit.url.Uri.parse(Uri.java:199)
> 	at com.sun.jndi.toolkit.url.Uri.init(Uri.java:138)
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:82)
> 	... 56 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 03:38:01 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 14 Oct 2016 03:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7289) Adding ldap-key-store
 requires accessible ldap server
In-Reply-To: <JIRA.12654219.1476189896000@Atlassian.JIRA>
References: <JIRA.12654219.1476189896000@Atlassian.JIRA>
	<JIRA.12654219.1476189896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654219.1476189896000.23921.1476430681595@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-7289:
-------------------------------
    Priority: Critical  (was: Major)


> Adding ldap-key-store requires accessible ldap server
> -----------------------------------------------------
>
>                 Key: WFLY-7289
>                 URL: https://issues.jboss.org/browse/WFLY-7289
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Critical
>
> Playing with ldap-key-store . What I consider very unconvenient is fact, that in moment of adding ldap-key-store, ldap server has to be running and accessible. Elytron ldap-realm does not need that. Doubt about legacy security realms. Is it possible to decouple that dependency and leave that check till first ldap-key-store usage?
> Steps to reproduce:
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=a:add()
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=a:add(dir-context=a, search-path="a")
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> {code}
> leads to exception in server log
> {code}
> 14:37:25,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
>     "address" => [
>         ("subsystem" => "elytron"),
>         ("ldap-key-store" => "a")
>     ],
>     "operation" => "add",
>     "search-path" => "a",
>     "dir-context" => "a",
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE"
>     }
> }]: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildTypes(AbstractModelResource.java:372)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:787)
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:520)
> 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:758)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:709)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: Cannot parse url: undefined [Root exception is java.net.MalformedURLException: Invalid URI: undefined]
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:92)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:163)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 39 more
> Caused by: java.net.MalformedURLException: Invalid URI: undefined
> 	at com.sun.jndi.toolkit.url.Uri.parse(Uri.java:199)
> 	at com.sun.jndi.toolkit.url.Uri.init(Uri.java:138)
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:82)
> 	... 56 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 03:49:00 2016
From: issues at jboss.org (Duncan Doyle (JIRA))
Date: Fri, 14 Oct 2016 03:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1327) Drools declared types
 cannot be references in jBPM Drools expressions due to compilation order.
In-Reply-To: <JIRA.12654698.1476366901000@Atlassian.JIRA>
References: <JIRA.12654698.1476366901000@Atlassian.JIRA>
	<JIRA.12654698.1476366901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654698.1476366901000.23952.1476431340058@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306985#comment-13306985 ] 

Duncan Doyle commented on DROOLS-1327:
--------------------------------------

PR: https://github.com/droolsjbpm/drools/pull/961

> Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1327
>                 URL: https://issues.jboss.org/browse/DROOLS-1327
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>         Environment: JBoss BPM Suite 6.3.3.GA
>            Reporter: Duncan Doyle
>            Assignee: Duncan Doyle
>
> When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project.
> The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled.
> Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 03:54:00 2016
From: issues at jboss.org (Duncan Doyle (JIRA))
Date: Fri, 14 Oct 2016 03:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1327) Drools declared types
 cannot be references in jBPM Drools expressions due to compilation order.
In-Reply-To: <JIRA.12654698.1476366901000@Atlassian.JIRA>
References: <JIRA.12654698.1476366901000@Atlassian.JIRA>
	<JIRA.12654698.1476366901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654698.1476366901000.23982.1476431640313@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306990#comment-13306990 ] 

Duncan Doyle commented on DROOLS-1327:
--------------------------------------

And the PR with the unit-test in jBPM: https://github.com/droolsjbpm/jbpm/pull/636

> Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1327
>                 URL: https://issues.jboss.org/browse/DROOLS-1327
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>         Environment: JBoss BPM Suite 6.3.3.GA
>            Reporter: Duncan Doyle
>            Assignee: Duncan Doyle
>
> When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project.
> The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled.
> Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 03:55:00 2016
From: issues at jboss.org (Duncan Doyle (JIRA))
Date: Fri, 14 Oct 2016 03:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1327) Drools declared types
 cannot be references in jBPM Drools expressions due to compilation order.
In-Reply-To: <JIRA.12654698.1476366901000@Atlassian.JIRA>
References: <JIRA.12654698.1476366901000@Atlassian.JIRA>
	<JIRA.12654698.1476366901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654698.1476366901000.23987.1476431700261@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Duncan Doyle reassigned DROOLS-1327:
------------------------------------

    Assignee: Mario Fusco  (was: Duncan Doyle)


> Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1327
>                 URL: https://issues.jboss.org/browse/DROOLS-1327
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>         Environment: JBoss BPM Suite 6.3.3.GA
>            Reporter: Duncan Doyle
>            Assignee: Mario Fusco
>
> When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project.
> The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled.
> Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 04:07:00 2016
From: issues at jboss.org (Bartosz Andrzejewski (JIRA))
Date: Fri, 14 Oct 2016 04:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.24065.1476432420655@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306999#comment-13306999 ] 

Bartosz Andrzejewski commented on WFLY-5213:
--------------------------------------------

Hello [~jmesnil],
I did it the same way you described, with one difference:
I'm using latest WildFly 10.1.0 and while configuring external-config I used "org.wildfly.extension.messaging-activemq" module, where i configured all the connectors.
It seems that JMS Context and Queue is injecting, but while I'm trying to use Context there is runtime exception (NameNotFoundException) - looking for comp/TransactionSynchronizationRegistry. 
Any idea what that could be ? I would really appreciate any clues(I already spend few days on that).

A bit of stacktrace: 
...
Caused by: javax.naming.NameNotFoundException: comp/TransactionSynchronizationRegistry -- service jboss.naming.context.java.comp.TransactionSynchronizationRegistry
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
	at org.apache.activemq.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:223)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.lookup(InjectedJMSContext.java:132)
	... 74 more

> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 14 04:07:00 2016
From: issues at jboss.org (Bartosz Andrzejewski (JIRA))
Date: Fri, 14 Oct 2016 04:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.24071.1476432420962@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13306999#comment-13306999 ] 

Bartosz Andrzejewski edited comment on WFLY-5213 at 10/14/16 4:06 AM:
----------------------------------------------------------------------

Hello [~jmesnil],
I did it the same way you described, with one difference:
I'm using latest WildFly 10.1.0 and while configuring external-context I used "org.wildfly.extension.messaging-activemq" module, where i configured all the connectors.
It seems that JMS Context and Queue is injecting, but while I'm trying to use Context there is runtime exception (NameNotFoundException) - looking for comp/TransactionSynchronizationRegistry. 
Any idea what that could be ? I would really appreciate any clues(I already spend few days on that).

A bit of stacktrace: 
...
Caused by: javax.naming.NameNotFoundException: comp/TransactionSynchronizationRegistry -- service jboss.naming.context.java.comp.TransactionSynchronizationRegistry
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
	at org.apache.activemq.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:223)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.lookup(InjectedJMSContext.java:132)
	... 74 more


was (Author: drzeyan):
Hello [~jmesnil],
I did it the same way you described, with one difference:
I'm using latest WildFly 10.1.0 and while configuring external-config I used "org.wildfly.extension.messaging-activemq" module, where i configured all the connectors.
It seems that JMS Context and Queue is injecting, but while I'm trying to use Context there is runtime exception (NameNotFoundException) - looking for comp/TransactionSynchronizationRegistry. 
Any idea what that could be ? I would really appreciate any clues(I already spend few days on that).

A bit of stacktrace: 
...
Caused by: javax.naming.NameNotFoundException: comp/TransactionSynchronizationRegistry -- service jboss.naming.context.java.comp.TransactionSynchronizationRegistry
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
	at org.apache.activemq.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:223)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.lookup(InjectedJMSContext.java:132)
	... 74 more

> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 14 04:27:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 14 Oct 2016 04:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1331) CEP KieSession
 deserialization NullPointerException with Timer and expiration
In-Reply-To: <JIRA.12654815.1476433572000@Atlassian.JIRA>
References: <JIRA.12654815.1476433572000@Atlassian.JIRA>
	<JIRA.12654815.1476433572797@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654815.1476433572000.24225.1476433620529@Atlassian.JIRA>

Mario Fusco created DROOLS-1331:
-----------------------------------

             Summary: CEP KieSession deserialization NullPointerException with Timer and expiration
                 Key: DROOLS-1331
                 URL: https://issues.jboss.org/browse/DROOLS-1331
             Project: Drools
          Issue Type: Bug
    Affects Versions: 7.0.0.Beta2
            Reporter: andrea tarocchi
            Assignee: Mario Fusco
            Priority: Critical


When a Cep KieSession containing events with expiration is serialized and then deserialized there is a NullPointerExceptions is thrown:

{code:java}
java.lang.NullPointerException
	at org.drools.core.reteoo.ObjectTypeNode$ExpireJobContextTimerInputMarshaller.deserialize(ObjectTypeNode.java:672)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readTimer(ProtobufInputMarshaller.java:709)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:291)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:162)
	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:116)
	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:52)
	at org.drools.compiler.integrationtests.CepEspTest$1KieSessionByteArraySerializer.readSession(CepEspTest.java:220)
	at org.drools.compiler.integrationtests.CepEspTest.testSerializationDeserliaizationWithRectractedExpireFact(CepEspTest.java:253)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.lang.Thread.run(Thread.java:745)
{code}

you have a reproducer in PR: https://github.com/droolsjbpm/drools/pull/959

Just run:
{code:bash}
cd drools-compiler
mvn clean test -Dtest=CepEspTest#testSerializationDeserliaizationWithRectractedExpireFact
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 04:28:02 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 14 Oct 2016 04:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1332) Drools declared types
 cannot be references in jBPM Drools expressions due to compilation order.
In-Reply-To: <JIRA.12654816.1476433642000@Atlassian.JIRA>
References: <JIRA.12654816.1476433642000@Atlassian.JIRA>
	<JIRA.12654816.1476433642495@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654816.1476433642000.24260.1476433682077@Atlassian.JIRA>

Mario Fusco created DROOLS-1332:
-----------------------------------

             Summary: Drools declared types cannot be references in jBPM Drools expressions due to compilation order.
                 Key: DROOLS-1332
                 URL: https://issues.jboss.org/browse/DROOLS-1332
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.4.0.Final
         Environment: JBoss BPM Suite 6.3.3.GA
            Reporter: Duncan Doyle
            Assignee: Mario Fusco


When you declare a type in a DRL using the "declare" syntax, that type cannot be referenced by Drools LHS expressions in a Sequence Flow (for example in the context of an X-OR Gateway). The DRL and BPMN2 file are in the same project.

The problem is the order of compilation of CompositeKnowledgeBuilderImpl. The builder compiles the process definitions before the DRLs, which results in a situation where the declared types used in the process are not yet available in the Drools ProjectClassloader when. the process is compiled.

Easy fix is to compile the process after the rules, which makes sense as the rules will normally not really on processes, but processes can really on rules.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 04:50:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 04:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to add trust-manager
 with ldap-key-store (classloading)
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.24414.1476435001633@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307032#comment-13307032 ] 

Jan Kalina commented on WFLY-7278:
----------------------------------

Ok, dir-context works ok when is this class already loaded using *"org.jboss.as.server:main"* module loader.
It is failing when *"org.wildfly.extension.elytron:main"* module loader is used - but even through the module.xml contains *<module name="sun.jdk"/>* dependency...

> Unable to add trust-manager with ldap-key-store (classloading)
> --------------------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 04:51:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 04:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to load
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.24430.1476435060525@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7278:
-----------------------------
    Summary: Unable to load   (was: Unable to add trust-manager with ldap-key-store (classloading))


> Unable to load 
> ---------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 04:51:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 04:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to load LdapCtxFactory
 from elytron module
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.24438.1476435060735@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7278:
-----------------------------
    Summary: Unable to load LdapCtxFactory from elytron module  (was: Unable to load )


> Unable to load LdapCtxFactory from elytron module
> -------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 05:03:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 05:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7314) Elytron new-item-attributes
 are not serialized into standalone.xml
In-Reply-To: <JIRA.12654801.1476427606000@Atlassian.JIRA>
References: <JIRA.12654801.1476427606000@Atlassian.JIRA>
	<JIRA.12654801.1476427606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654801.1476427606000.24462.1476435780499@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307039#comment-13307039 ] 

Jan Kalina commented on WFLY-7314:
----------------------------------

Missing testcase for ldap.xml in SubsystemParsingTestCase.

> Elytron new-item-attributes are not serialized into standalone.xml
> ------------------------------------------------------------------
>
>                 Key: WFLY-7314
>                 URL: https://issues.jboss.org/browse/WFLY-7314
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Critical
>
> {{new-item-attributes}}  of {{ldap-key-store}} doesn't survive restart of server.
> See steps to reproduce for details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 05:06:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 05:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7314) Elytron new-item-attributes
 are not serialized into standalone.xml
In-Reply-To: <JIRA.12654801.1476427606000@Atlassian.JIRA>
References: <JIRA.12654801.1476427606000@Atlassian.JIRA>
	<JIRA.12654801.1476427606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654801.1476427606000.24490.1476435960894@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7314:
--------------------------------

    Assignee: Jan Kalina


> Elytron new-item-attributes are not serialized into standalone.xml
> ------------------------------------------------------------------
>
>                 Key: WFLY-7314
>                 URL: https://issues.jboss.org/browse/WFLY-7314
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> {{new-item-attributes}}  of {{ldap-key-store}} doesn't survive restart of server.
> See steps to reproduce for details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 05:13:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 05:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to load LdapCtxFactory
 from elytron module
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.24529.1476436380494@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307050#comment-13307050 ] 

Jan Kalina commented on WFLY-7278:
----------------------------------

Well... the problem was missing <module name="sun.jdk"/> in *elytron-subsystem*. (Was present only in wildfly-elytron.)

> Unable to load LdapCtxFactory from elytron module
> -------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 06:34:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 14 Oct 2016 06:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7315) Empty result of attribute
 search in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654859.1476441198000@Atlassian.JIRA>
References: <JIRA.12654859.1476441198000@Atlassian.JIRA>
	<JIRA.12654859.1476441198440@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654859.1476441198000.25138.1476441240322@Atlassian.JIRA>

Ondrej Lukas created WFLY-7315:
----------------------------------

             Summary: Empty result of attribute search in Elytron ldap-realm causes NPE
                 Key: WFLY-7315
                 URL: https://issues.jboss.org/browse/WFLY-7315
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


In case when Elytron ldap-realm is configured through attribute-mapping to return some attribute and LDAP search does not find this attribute for some entry, then NPE is thrown and authentication fails.
It is caused by missing null check for {{ldapAttribute}} in [1].

Exception thrown to server log:
{code}
ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:690)
	at java.util.stream.Collectors.lambda$toMap$215(Collectors.java:1321)
	at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractAttributes(LdapSecurityRealm.java:753)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributes(LdapSecurityRealm.java:634)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$getIdentity$1(LdapSecurityRealm.java:593)
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
	at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
	at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
	at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:598)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
	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)
Caused by: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:678)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
	at java.util.Spliterator.forEachRemaining(Spliterator.java:326)
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:650)
	... 67 more
Caused by: java.lang.NullPointerException
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:672)
	... 71 more
{code}

[1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L672



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 06:34:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 14 Oct 2016 06:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7315) Empty result of attribute
 search in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654859.1476441198000@Atlassian.JIRA>
References: <JIRA.12654859.1476441198000@Atlassian.JIRA>
	<JIRA.12654859.1476441198000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654859.1476441198000.25147.1476441240639@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7315:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> Empty result of attribute search in Elytron ldap-realm causes NPE
> -----------------------------------------------------------------
>
>                 Key: WFLY-7315
>                 URL: https://issues.jboss.org/browse/WFLY-7315
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when Elytron ldap-realm is configured through attribute-mapping to return some attribute and LDAP search does not find this attribute for some entry, then NPE is thrown and authentication fails.
> It is caused by missing null check for {{ldapAttribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:690)
> 	at java.util.stream.Collectors.lambda$toMap$215(Collectors.java:1321)
> 	at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> 	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractAttributes(LdapSecurityRealm.java:753)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributes(LdapSecurityRealm.java:634)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$getIdentity$1(LdapSecurityRealm.java:593)
> 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
> 	at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:598)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:678)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.Spliterator.forEachRemaining(Spliterator.java:326)
> 	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:650)
> 	... 67 more
> Caused by: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:672)
> 	... 71 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L672



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 07:23:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 07:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7314) Elytron new-item-attributes
 are not serialized into standalone.xml
In-Reply-To: <JIRA.12654801.1476427606000@Atlassian.JIRA>
References: <JIRA.12654801.1476427606000@Atlassian.JIRA>
	<JIRA.12654801.1476427606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654801.1476427606000.25549.1476444180236@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307138#comment-13307138 ] 

Jan Kalina commented on WFLY-7314:
----------------------------------

The problem was the new-item-* attributes should depend each other. Added check to model.

> Elytron new-item-attributes are not serialized into standalone.xml
> ------------------------------------------------------------------
>
>                 Key: WFLY-7314
>                 URL: https://issues.jboss.org/browse/WFLY-7314
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> {{new-item-attributes}}  of {{ldap-key-store}} doesn't survive restart of server.
> See steps to reproduce for details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 07:55:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 14 Oct 2016 07:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore
 interaction from within SASL mechanisms.
In-Reply-To: <JIRA.12654913.1476446085000@Atlassian.JIRA>
References: <JIRA.12654913.1476446085000@Atlassian.JIRA>
	<JIRA.12654913.1476446085905@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654913.1476446085000.25798.1476446100567@Atlassian.JIRA>

Darran Lofthouse created ELY-662:
------------------------------------

             Summary: Eliminate CredentialStore interaction from within SASL mechanisms.
                 Key: ELY-662
                 URL: https://issues.jboss.org/browse/ELY-662
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: Credential Store, SASL
            Reporter: Darran Lofthouse
            Assignee: Peter Skopek
            Priority: Critical
             Fix For: 1.1.0.Beta11


The conversion between callbacks and credential store should be handled centrally within the callback handler and not within the mechanism.

This way all mechanisms can use the core integration including mechanisms that may not be Elytron aware just using standard Java callbacks.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 07:57:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 14 Oct 2016 07:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7316) LDAP referrals does not work
 for Elytron dir-context since value of dir-context.referral-mode is always
 ignored
In-Reply-To: <JIRA.12654915.1476446215000@Atlassian.JIRA>
References: <JIRA.12654915.1476446215000@Atlassian.JIRA>
	<JIRA.12654915.1476446215644@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446215000.25835.1476446221131@Atlassian.JIRA>

Ondrej Lukas created WFLY-7316:
----------------------------------

             Summary: LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored
                 Key: WFLY-7316
                 URL: https://issues.jboss.org/browse/WFLY-7316
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Blocker


Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 

InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].

We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.

[1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 07:58:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 14 Oct 2016 07:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7316) LDAP referrals does not work
 for Elytron dir-context since value of dir-context.referral-mode is always
 ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.25844.1476446280255@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7316:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7316
>                 URL: https://issues.jboss.org/browse/WFLY-7316
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:14:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 08:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.25938.1476447240281@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1323:
-------------------------------------
    Attachment: Selection_245.png


Here a run without the notifyAll():
!Selection_245.png|thumbnail!



> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:17:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 08:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.25943.1476447420279@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1323:
-------------------------------------
    Attachment: Selection_246.png


Here are 2 normal runs and 2 hacked (= without the notifyAll()) call runs:
[^Selection_246.png]

> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:20:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 08:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.25950.1476447600209@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307181#comment-13307181 ] 

Geoffrey De Smet edited comment on DROOLS-1323 at 10/14/16 8:19 AM:
--------------------------------------------------------------------

Here a run without the notifyAll():
!Selection_245.png|thumbnail!

Interestingly, the score calculation speed went up from 60k to 70k/sec while being profiled.
But in a normal benchmark, no such speed increase is visible (at most 1%, not 16%).


was (Author: ge0ffrey):
Here a run without the notifyAll():
!Selection_245.png|thumbnail!



> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:21:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 08:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.25953.1476447660225@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307183#comment-13307183 ] 

Geoffrey De Smet edited comment on DROOLS-1323 at 10/14/16 8:20 AM:
--------------------------------------------------------------------

Here are 2 normal runs and 2 hacked (= without the notifyAll()) call runs:

[^Selection_246.png]


was (Author: ge0ffrey):
Here are 2 normal runs and 2 hacked (= without the notifyAll()) call runs:
[^Selection_246.png]

> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:24:00 2016
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Fri, 14 Oct 2016 08:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7315) Empty result of attribute
 search in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654859.1476441198000@Atlassian.JIRA>
References: <JIRA.12654859.1476441198000@Atlassian.JIRA>
	<JIRA.12654859.1476441198000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654859.1476441198000.25967.1476447840540@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307186#comment-13307186 ] 

Dmitrii Tikhomirov commented on WFLY-7315:
------------------------------------------

[~dlofthouse] could i assign this issue to me please ?

> Empty result of attribute search in Elytron ldap-realm causes NPE
> -----------------------------------------------------------------
>
>                 Key: WFLY-7315
>                 URL: https://issues.jboss.org/browse/WFLY-7315
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when Elytron ldap-realm is configured through attribute-mapping to return some attribute and LDAP search does not find this attribute for some entry, then NPE is thrown and authentication fails.
> It is caused by missing null check for {{ldapAttribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:690)
> 	at java.util.stream.Collectors.lambda$toMap$215(Collectors.java:1321)
> 	at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> 	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractAttributes(LdapSecurityRealm.java:753)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributes(LdapSecurityRealm.java:634)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$getIdentity$1(LdapSecurityRealm.java:593)
> 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
> 	at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:598)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:678)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.Spliterator.forEachRemaining(Spliterator.java:326)
> 	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:650)
> 	... 67 more
> Caused by: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:672)
> 	... 71 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L672



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:27:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 08:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.25972.1476448020696@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307183#comment-13307183 ] 

Geoffrey De Smet edited comment on DROOLS-1323 at 10/14/16 8:26 AM:
--------------------------------------------------------------------

Here are 2 normal runs and 2 hacked (= without the notifyAll()) call runs on the benchmarker config (not the same as the one that's being profiled, running that one now):

[^Selection_246.png]


was (Author: ge0ffrey):
Here are 2 normal runs and 2 hacked (= without the notifyAll()) call runs:

[^Selection_246.png]

> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:27:01 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 08:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.25994.1476448021232@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307183#comment-13307183 ] 

Geoffrey De Smet edited comment on DROOLS-1323 at 10/14/16 8:26 AM:
--------------------------------------------------------------------

Here are 2 normal runs and 2 hacked (= without the notifyAll()) call runs on the benchmarker config (not the same as the one that's being profiled, running that one now):

[^Selection_246.png]

In this case, there is maybe a 1% improvement.


was (Author: ge0ffrey):
Here are 2 normal runs and 2 hacked (= without the notifyAll()) call runs on the benchmarker config (not the same as the one that's being profiled, running that one now):

[^Selection_246.png]

> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:35:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 08:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.26029.1476448500642@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1323:
-------------------------------------
    Attachment: Selection_247.png


And here's with the vanilla config:

[^Selection_247.png]

That's a 5% improvement.



> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png, Selection_247.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:35:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 14 Oct 2016 08:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7315) Empty result of attribute
 search in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654859.1476441198000@Atlassian.JIRA>
References: <JIRA.12654859.1476441198000@Atlassian.JIRA>
	<JIRA.12654859.1476441198000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654859.1476441198000.26026.1476448500397@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307191#comment-13307191 ] 

Darran Lofthouse commented on WFLY-7315:
----------------------------------------

Please contact [~honza889] as he is looking after these kinds of issue at the moment.  Additional contribution is welcome but Honza will be able to tell you if this is likely to conflict with something he is already working on or is possibly being fixed as a side effect of another issue.

> Empty result of attribute search in Elytron ldap-realm causes NPE
> -----------------------------------------------------------------
>
>                 Key: WFLY-7315
>                 URL: https://issues.jboss.org/browse/WFLY-7315
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when Elytron ldap-realm is configured through attribute-mapping to return some attribute and LDAP search does not find this attribute for some entry, then NPE is thrown and authentication fails.
> It is caused by missing null check for {{ldapAttribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:690)
> 	at java.util.stream.Collectors.lambda$toMap$215(Collectors.java:1321)
> 	at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> 	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractAttributes(LdapSecurityRealm.java:753)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributes(LdapSecurityRealm.java:634)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$getIdentity$1(LdapSecurityRealm.java:593)
> 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
> 	at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:598)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:678)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.Spliterator.forEachRemaining(Spliterator.java:326)
> 	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:650)
> 	... 67 more
> Caused by: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:672)
> 	... 71 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L672



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:37:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 08:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.26035.1476448620207@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307183#comment-13307183 ] 

Geoffrey De Smet edited comment on DROOLS-1323 at 10/14/16 8:36 AM:
--------------------------------------------------------------------

Here are 2 normal runs and 2 hacked (= without the notifyAll()) call runs on the benchmarker config (not the same as the one that's being profiled, running that one now):

[^Selection_246.png]

In this case, there is maybe a 1% improvement. Update: ON THE SMALL DATASET.


was (Author: ge0ffrey):
Here are 2 normal runs and 2 hacked (= without the notifyAll()) call runs on the benchmarker config (not the same as the one that's being profiled, running that one now):

[^Selection_246.png]

In this case, there is maybe a 1% improvement.

> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png, Selection_247.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:37:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 08:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.26038.1476448620360@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307192#comment-13307192 ] 

Geoffrey De Smet edited comment on DROOLS-1323 at 10/14/16 8:36 AM:
--------------------------------------------------------------------

And here's with the vanilla config:

[^Selection_247.png]

That's a 5% improvement.  Update: ON THE SMALL DATASET.




was (Author: ge0ffrey):
And here's with the vanilla config:

[^Selection_247.png]

That's a 5% improvement.



> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png, Selection_247.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:55:01 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 14 Oct 2016 08:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7317) Elytron ldap-key-store DMR
 XSD inconsistency
In-Reply-To: <JIRA.12654928.1476449660000@Atlassian.JIRA>
References: <JIRA.12654928.1476449660000@Atlassian.JIRA>
	<JIRA.12654928.1476449660000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654928.1476449660000.26241.1476449701839@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6441 to WFLY-7317:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7317  (was: JBEAP-6441)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Elytron ldap-key-store DMR XSD inconsistency 
> ---------------------------------------------
>
>                 Key: WFLY-7317
>                 URL: https://issues.jboss.org/browse/WFLY-7317
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>
> * in XSD there are missing attributes {{key-attribute}} and {{key-type}}
> * in XSD {{value}} attribute of {{new-item-template}} is not a list type as in DMR
> * in DMR {{name}} in {{new-item-attributes}} is optional. In XSD it is marked as required. Should be required in DMR as well.
> * synchronize documenation of XSD and DMR. Documentation in XSD seems little bit detailed.
> * In {{certificate-type}} and {{certificate-attribute}} probably remove link to oracle java 8 documentation. I consider it usefull, but I see couple of maintaining issues. Link can change. Java 9 is comming and can have own enumaration. We also support IBM java. Just stating "For possible values see java documentation of CertificateFactory/CertPathEncodings" would be enough here



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 08:56:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 08:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7316) LDAP referrals does not work
 for Elytron dir-context since value of dir-context.referral-mode is always
 ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.26248.1476449760337@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7316:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7316
>                 URL: https://issues.jboss.org/browse/WFLY-7316
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:10:02 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 09:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7315) Empty result of attribute
 search in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654859.1476441198000@Atlassian.JIRA>
References: <JIRA.12654859.1476441198000@Atlassian.JIRA>
	<JIRA.12654859.1476441198000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654859.1476441198000.26348.1476450602468@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307217#comment-13307217 ] 

Jan Kalina commented on WFLY-7315:
----------------------------------

This will not be in conflict - no problem to assign.

> Empty result of attribute search in Elytron ldap-realm causes NPE
> -----------------------------------------------------------------
>
>                 Key: WFLY-7315
>                 URL: https://issues.jboss.org/browse/WFLY-7315
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when Elytron ldap-realm is configured through attribute-mapping to return some attribute and LDAP search does not find this attribute for some entry, then NPE is thrown and authentication fails.
> It is caused by missing null check for {{ldapAttribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:690)
> 	at java.util.stream.Collectors.lambda$toMap$215(Collectors.java:1321)
> 	at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> 	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractAttributes(LdapSecurityRealm.java:753)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributes(LdapSecurityRealm.java:634)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$getIdentity$1(LdapSecurityRealm.java:593)
> 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
> 	at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:598)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:678)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.Spliterator.forEachRemaining(Spliterator.java:326)
> 	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:650)
> 	... 67 more
> Caused by: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:672)
> 	... 71 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L672



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:11:00 2016
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Fri, 14 Oct 2016 09:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7315) Empty result of attribute
 search in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654859.1476441198000@Atlassian.JIRA>
References: <JIRA.12654859.1476441198000@Atlassian.JIRA>
	<JIRA.12654859.1476441198000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654859.1476441198000.26358.1476450660869@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitrii Tikhomirov reassigned WFLY-7315:
----------------------------------------

    Assignee: Dmitrii Tikhomirov  (was: Darran Lofthouse)


> Empty result of attribute search in Elytron ldap-realm causes NPE
> -----------------------------------------------------------------
>
>                 Key: WFLY-7315
>                 URL: https://issues.jboss.org/browse/WFLY-7315
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Dmitrii Tikhomirov
>
> In case when Elytron ldap-realm is configured through attribute-mapping to return some attribute and LDAP search does not find this attribute for some entry, then NPE is thrown and authentication fails.
> It is caused by missing null check for {{ldapAttribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:690)
> 	at java.util.stream.Collectors.lambda$toMap$215(Collectors.java:1321)
> 	at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> 	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractAttributes(LdapSecurityRealm.java:753)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.extractFilteredAttributes(LdapSecurityRealm.java:634)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$getIdentity$1(LdapSecurityRealm.java:593)
> 	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
> 	at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 	at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:598)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: java.lang.RuntimeException: ELY01079: Ldap-backed realm failed to obtain attributes for entry [uid=jduke,ou=People,dc=jboss,dc=org]
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:678)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:944)
> 	at java.util.Spliterator.forEachRemaining(Spliterator.java:326)
> 	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$extractFilteredAttributes$6(LdapSecurityRealm.java:650)
> 	... 67 more
> Caused by: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.lambda$null$5(LdapSecurityRealm.java:672)
> 	... 71 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L672



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:19:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 14 Oct 2016 09:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.26424.1476451140349@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1323:
-------------------------------------
    Attachment: Selection_249.png


but a big dataset benchmark doesn't confirm: no gain (loss even)...

[^Selection_249.png]

> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png, Selection_247.png, Selection_249.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:22:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 09:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7314) Elytron new-item-attributes
 are not serialized into standalone.xml
In-Reply-To: <JIRA.12654801.1476427606000@Atlassian.JIRA>
References: <JIRA.12654801.1476427606000@Atlassian.JIRA>
	<JIRA.12654801.1476427606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654801.1476427606000.26447.1476451320379@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307226#comment-13307226 ] 

Jan Kalina commented on WFLY-7314:
----------------------------------

I will enclose new-item-* things into object yet, as Martin suggested.

> Elytron new-item-attributes are not serialized into standalone.xml
> ------------------------------------------------------------------
>
>                 Key: WFLY-7314
>                 URL: https://issues.jboss.org/browse/WFLY-7314
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> {{new-item-attributes}}  of {{ldap-key-store}} doesn't survive restart of server.
> See steps to reproduce for details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:27:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 09:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7316) LDAP referrals does not work
 for Elytron dir-context since value of dir-context.referral-mode is always
 ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.26498.1476451621283@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307233#comment-13307233 ] 

Jan Kalina commented on WFLY-7316:
----------------------------------

By discussion, maybe there will be need to add "filter" attribute to the ldap-realm, similar like in ldap-key-store already is to work with referrals:

(|(objectClass=refferal)(uid={0}))

(will have to check yet if it helps, but by Ond?ej it is solved in Picketbox by this way)

> LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7316
>                 URL: https://issues.jboss.org/browse/WFLY-7316
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 14 09:27:02 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 09:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7316) LDAP referrals does not work
 for Elytron dir-context since value of dir-context.referral-mode is always
 ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.26526.1476451622533@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307233#comment-13307233 ] 

Jan Kalina edited comment on WFLY-7316 at 10/14/16 9:26 AM:
------------------------------------------------------------

By discussion, maybe there will be need to add "filter" attribute to the ldap-realm, similar like in ldap-key-store already is to work with referrals:


{code:java}
(|(objectClass=refferal)(uid={0}))
{code}


(will have to check yet if it helps, but by Ond?ej it is solved in Picketbox by this way)


was (Author: honza889):
By discussion, maybe there will be need to add "filter" attribute to the ldap-realm, similar like in ldap-key-store already is to work with referrals:

(|(objectClass=refferal)(uid={0}))

(will have to check yet if it helps, but by Ond?ej it is solved in Picketbox by this way)

> LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7316
>                 URL: https://issues.jboss.org/browse/WFLY-7316
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 14 09:42:00 2016
From: issues at jboss.org (Jive JIRA Integration (JIRA))
Date: Fri, 14 Oct 2016 09:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7313) Impossible to use environment
 variables or system properties in permissions.xml
In-Reply-To: <JIRA.12654778.1476386430000@Atlassian.JIRA>
References: <JIRA.12654778.1476386430000@Atlassian.JIRA>
	<JIRA.12654778.1476386430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654778.1476386430000.26635.1476452520620@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jive JIRA Integration updated WFLY-7313:
----------------------------------------
    Forum Reference: https://developer.jboss.org/message/964059#964059


> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-7313
>                 URL: https://issues.jboss.org/browse/WFLY-7313
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 10.1.0.Final
>            Reporter: Adrian Boangiu
>            Assignee: Jason Greene
>            Priority: Blocker
>             Fix For: 10.1.0.Final, 10.2.0.Final
>
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> that were defined in Java policy file in previous verions of JBoss.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:43:00 2016
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Fri, 14 Oct 2016 09:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7313) Impossible to use environment
 variables or system properties in permissions.xml
In-Reply-To: <JIRA.12654778.1476386430000@Atlassian.JIRA>
References: <JIRA.12654778.1476386430000@Atlassian.JIRA>
	<JIRA.12654778.1476386430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654778.1476386430000.26639.1476452580370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated WFLY-7313:
-------------------------------
    Priority: Major  (was: Blocker)


> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-7313
>                 URL: https://issues.jboss.org/browse/WFLY-7313
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 10.1.0.Final
>            Reporter: Adrian Boangiu
>            Assignee: Jason Greene
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> that were defined in Java policy file in previous verions of JBoss.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:43:00 2016
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Fri, 14 Oct 2016 09:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7313) Impossible to use environment
 variables or system properties in permissions.xml
In-Reply-To: <JIRA.12654778.1476386430000@Atlassian.JIRA>
References: <JIRA.12654778.1476386430000@Atlassian.JIRA>
	<JIRA.12654778.1476386430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654778.1476386430000.26643.1476452580477@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated WFLY-7313:
-------------------------------
    Fix Version/s:     (was: 10.1.0.Final)
                       (was: 10.2.0.Final)


> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-7313
>                 URL: https://issues.jboss.org/browse/WFLY-7313
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 10.1.0.Final
>            Reporter: Adrian Boangiu
>            Assignee: Jason Greene
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> that were defined in Java policy file in previous verions of JBoss.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:43:00 2016
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Fri, 14 Oct 2016 09:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7313) Impossible to use environment
 variables or system properties in permissions.xml
In-Reply-To: <JIRA.12654778.1476386430000@Atlassian.JIRA>
References: <JIRA.12654778.1476386430000@Atlassian.JIRA>
	<JIRA.12654778.1476386430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654778.1476386430000.26646.1476452580554@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated WFLY-7313:
-------------------------------
    Component/s: EE


> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-7313
>                 URL: https://issues.jboss.org/browse/WFLY-7313
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 10.1.0.Final
>            Reporter: Adrian Boangiu
>            Assignee: Jason Greene
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> that were defined in Java policy file in previous verions of JBoss.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:52:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 14 Oct 2016 09:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7271) Review elytron jdbc-realm
 resource XSD definition
In-Reply-To: <JIRA.12653639.1475767977000@Atlassian.JIRA>
References: <JIRA.12653639.1475767977000@Atlassian.JIRA>
	<JIRA.12653639.1475767977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653639.1475767977000.26687.1476453120549@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7271:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Review elytron jdbc-realm resource XSD definition
> -------------------------------------------------
>
>                 Key: WFLY-7271
>                 URL: https://issues.jboss.org/browse/WFLY-7271
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>             Fix For: 11.0.0.Alpha1
>
>
> * Wouldn't {{xsd:all}} be more proper than {{xsd:sequence}} here, as it doesn't required elements in exact order.
> * In XSD attribute-mapping attribute {{to}} is declared as optional, but in fact it is required.
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/jdbc-realm=a:add(principal-query=[{sql="a",data-source="ExampleDS",attribute-mapping=[{index=0}]}])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0155: to may not be null",
>     "rolled-back" => true
> }
> {code}
> * simple-digest-mapper, salted-simple-digest-mapper and scram-mapper missing {{algorithm}} attribute in XSD



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:56:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 14 Oct 2016 09:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7278) Unable to load LdapCtxFactory
 from elytron module
In-Reply-To: <JIRA.12653918.1476032088000@Atlassian.JIRA>
References: <JIRA.12653918.1476032088000@Atlassian.JIRA>
	<JIRA.12653918.1476032088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653918.1476032088000.26714.1476453360644@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7278:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Unable to load LdapCtxFactory from elytron module
> -------------------------------------------------
>
>                 Key: WFLY-7278
>                 URL: https://issues.jboss.org/browse/WFLY-7278
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 11.0.0.Alpha1
>
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 28 more
> {code}
> Direct key-store aliases listing using  works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 09:56:01 2016
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Fri, 14 Oct 2016 09:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Stateful working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.26726.1476453361086@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307258#comment-13307258 ] 

Jiri Locker commented on DROOLS-1326:
-------------------------------------

So what I did is that I removed the 1st solver, which only does a part of CH. Then I took the 2nd solver running with FAST_ASSERT, I let it do the whole CH (740 steps total), and I limited its LS to 1233 steps, which should lead to the same state as the original 1st and 2nd solvers without any modifications. Then I left the 3rd solver with NON_INTRUSIVE_FULL_ASSERT to solve for 30 minutes, supposedly starting from the same state, but it didn't fail.

The output with the described modifications looks like this:
{noformat}
2016-10-14 14:32:48,296 [main] INFO  Opened: data/nurserostering/unsolved/long_hint01.xml
2016-10-14 14:32:49,902 [main] INFO  Solving started: time spent (177), best score (-740init/0hard/-1580soft), environment mode (FAST_ASSERT), random (JDK with seed 0).
2016-10-14 14:32:54,252 [main] INFO  Construction Heuristic phase (0) ended: time spent (4527), best score (0hard/-180soft), score calculation speed (17355/sec), step total (740).
2016-10-14 14:36:46,131 [main] INFO  Local Search phase (1) ended: time spent (236406), best score (0hard/-62soft), score calculation speed (8812/sec), step total (1233).
2016-10-14 14:36:46,132 [main] INFO  Solving ended: time spent (236407), best score (0hard/-62soft), score calculation speed (8962/sec), phase total (2), environment mode (FAST_ASSERT).
2016-10-14 14:36:46,630 [main] INFO  Solving started: time spent (153), best score (0hard/-62soft), environment mode (NON_INTRUSIVE_FULL_ASSERT), random (JDK with seed 0).
2016-10-14 14:36:46,631 [main] INFO  Construction Heuristic phase (0) ended: time spent (154), best score (0hard/-62soft), score calculation speed (1000/sec), step total (0).
{noformat}


> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-1326
>                 URL: https://issues.jboss.org/browse/DROOLS-1326
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/
> I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 10:01:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 14 Oct 2016 10:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7314) Elytron new-item-attributes
 are not serialized into standalone.xml
In-Reply-To: <JIRA.12654801.1476427606000@Atlassian.JIRA>
References: <JIRA.12654801.1476427606000@Atlassian.JIRA>
	<JIRA.12654801.1476427606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654801.1476427606000.26772.1476453660416@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7314:
-----------------------------------
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Elytron new-item-attributes are not serialized into standalone.xml
> ------------------------------------------------------------------
>
>                 Key: WFLY-7314
>                 URL: https://issues.jboss.org/browse/WFLY-7314
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> {{new-item-attributes}}  of {{ldap-key-store}} doesn't survive restart of server.
> See steps to reproduce for details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 10:02:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 14 Oct 2016 10:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7314) Elytron new-item-attributes
 are not serialized into standalone.xml
In-Reply-To: <JIRA.12654801.1476427606000@Atlassian.JIRA>
References: <JIRA.12654801.1476427606000@Atlassian.JIRA>
	<JIRA.12654801.1476427606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654801.1476427606000.26779.1476453720439@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7314:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Elytron new-item-attributes are not serialized into standalone.xml
> ------------------------------------------------------------------
>
>                 Key: WFLY-7314
>                 URL: https://issues.jboss.org/browse/WFLY-7314
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> {{new-item-attributes}}  of {{ldap-key-store}} doesn't survive restart of server.
> See steps to reproduce for details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 11:25:00 2016
From: issues at jboss.org (Alexandre Porcelli (JIRA))
Date: Fri, 14 Oct 2016 11:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1333) Enhance MavenEmbedder in
 order to be able to use it to execute maven builds
In-Reply-To: <JIRA.12654984.1476458642000@Atlassian.JIRA>
References: <JIRA.12654984.1476458642000@Atlassian.JIRA>
	<JIRA.12654984.1476458642881@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654984.1476458642000.27490.1476458700178@Atlassian.JIRA>

Alexandre Porcelli created DROOLS-1333:
------------------------------------------

             Summary: Enhance MavenEmbedder in order to be able to use it to execute maven builds
                 Key: DROOLS-1333
                 URL: https://issues.jboss.org/browse/DROOLS-1333
             Project: Drools
          Issue Type: Enhancement
            Reporter: Alexandre Porcelli
            Assignee: Alexandre Porcelli






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 11:44:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 14 Oct 2016 11:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7318) Add EAP 7.0 transformer tests
 for mod_cluster subsystem
In-Reply-To: <JIRA.12654989.1476459786000@Atlassian.JIRA>
References: <JIRA.12654989.1476459786000@Atlassian.JIRA>
	<JIRA.12654989.1476459786185@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654989.1476459786000.27607.1476459840375@Atlassian.JIRA>

Radoslav Husar created WFLY-7318:
------------------------------------

             Summary: Add EAP 7.0 transformer tests for mod_cluster subsystem
                 Key: WFLY-7318
                 URL: https://issues.jboss.org/browse/WFLY-7318
             Project: WildFly
          Issue Type: Task
          Components: mod_cluster
    Affects Versions: 10.1.0.Final, 10.0.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 11:45:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 14 Oct 2016 11:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7318) Add EAP 7.0.0 transformers
 tests for mod_cluster subsystem
In-Reply-To: <JIRA.12654989.1476459786000@Atlassian.JIRA>
References: <JIRA.12654989.1476459786000@Atlassian.JIRA>
	<JIRA.12654989.1476459786000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654989.1476459786000.27620.1476459900486@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7318:
---------------------------------
    Summary: Add EAP 7.0.0 transformers tests for mod_cluster subsystem  (was: Add EAP 7.0 transformer tests for mod_cluster subsystem)


> Add EAP 7.0.0 transformers tests for mod_cluster subsystem
> ----------------------------------------------------------
>
>                 Key: WFLY-7318
>                 URL: https://issues.jboss.org/browse/WFLY-7318
>             Project: WildFly
>          Issue Type: Task
>          Components: mod_cluster
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 11:48:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 14 Oct 2016 11:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7318) Add EAP 7.0.0 transformers
 tests for mod_cluster subsystem
In-Reply-To: <JIRA.12654989.1476459786000@Atlassian.JIRA>
References: <JIRA.12654989.1476459786000@Atlassian.JIRA>
	<JIRA.12654989.1476459786000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654989.1476459786000.27638.1476460080663@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7318:
---------------------------------
    Description: Needs to be added before any elytron integration work.


> Add EAP 7.0.0 transformers tests for mod_cluster subsystem
> ----------------------------------------------------------
>
>                 Key: WFLY-7318
>                 URL: https://issues.jboss.org/browse/WFLY-7318
>             Project: WildFly
>          Issue Type: Task
>          Components: mod_cluster
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Needs to be added before any elytron integration work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 13:43:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 14 Oct 2016 13:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7319) Processing of variables
 doesn't work in servlet mapping
In-Reply-To: <JIRA.12654998.1476466919000@Atlassian.JIRA>
References: <JIRA.12654998.1476466919000@Atlassian.JIRA>
	<JIRA.12654998.1476466919941@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654998.1476466919000.28012.1476466980258@Atlassian.JIRA>

John Ament created WFLY-7319:
--------------------------------

             Summary: Processing of variables doesn't work in servlet mapping
                 Key: WFLY-7319
                 URL: https://issues.jboss.org/browse/WFLY-7319
             Project: WildFly
          Issue Type: Bug
            Reporter: John Ament
            Assignee: Jason Greene


I have the following servlet mapping:

{code}
    <servlet>
        <servlet-name>TogglzConsoleServlet</servlet-name>
        <servlet-class>org.togglz.console.TogglzConsoleServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>TogglzConsoleServlet</servlet-name>
        <url-pattern>${togglz.uri}</url-pattern>
    </servlet-mapping>
{code}

Regardless of system property, the value is not processed.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 13:43:00 2016
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 14 Oct 2016 13:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7319) Processing of variables
 doesn't work in servlet mapping
In-Reply-To: <JIRA.12654998.1476466920000@Atlassian.JIRA>
References: <JIRA.12654998.1476466920000@Atlassian.JIRA>
	<JIRA.12654998.1476466920000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654998.1476466920000.28016.1476466980415@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ament updated WFLY-7319:
-----------------------------
    Affects Version/s: 10.1.0.Final


> Processing of variables doesn't work in servlet mapping
> -------------------------------------------------------
>
>                 Key: WFLY-7319
>                 URL: https://issues.jboss.org/browse/WFLY-7319
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>            Reporter: John Ament
>            Assignee: Jason Greene
>
> I have the following servlet mapping:
> {code}
>     <servlet>
>         <servlet-name>TogglzConsoleServlet</servlet-name>
>         <servlet-class>org.togglz.console.TogglzConsoleServlet</servlet-class>
>     </servlet>
>     <servlet-mapping>
>         <servlet-name>TogglzConsoleServlet</servlet-name>
>         <url-pattern>${togglz.uri}</url-pattern>
>     </servlet-mapping>
> {code}
> Regardless of system property, the value is not processed.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 15:44:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 14 Oct 2016 15:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-663) LDAP referrals does not work
 for Elytron dir-context since value of dir-context.referral-mode is always
 ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.28258.1476474240156@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7316 to ELY-663:
--------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-663  (was: WFLY-7316)
          Component/s:     (was: Security)
    Affects Version/s:     (was: 11.0.0.Alpha1)


> LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-663
>                 URL: https://issues.jboss.org/browse/ELY-663
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 16:11:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 14 Oct 2016 16:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-664) Ensure that the "index"
 attribute in AttributeMapper is greater than 1.
In-Reply-To: <JIRA.12655011.1476475817000@Atlassian.JIRA>
References: <JIRA.12655011.1476475817000@Atlassian.JIRA>
	<JIRA.12655011.1476475817791@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655011.1476475817000.28270.1476475860247@Atlassian.JIRA>

Ilia Vassilev created ELY-664:
---------------------------------

             Summary: Ensure that the "index" attribute in AttributeMapper is greater than 1. 
                 Key: ELY-664
                 URL: https://issues.jboss.org/browse/ELY-664
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Realms
    Affects Versions: 1.1.0.Beta10
            Reporter: Ilia Vassilev
            Assignee: Darran Lofthouse






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 16:11:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 14 Oct 2016 16:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-664) Ensure that the "index"
 attribute in AttributeMapper is greater than 1.
In-Reply-To: <JIRA.12655011.1476475818000@Atlassian.JIRA>
References: <JIRA.12655011.1476475818000@Atlassian.JIRA>
	<JIRA.12655011.1476475818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655011.1476475818000.28273.1476475860388@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-664:
---------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Ensure that the "index" attribute in AttributeMapper is greater than 1. 
> ------------------------------------------------------------------------
>
>                 Key: ELY-664
>                 URL: https://issues.jboss.org/browse/ELY-664
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 16:13:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 14 Oct 2016 16:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-665) Ensure that the "index"
 attribute in AttributeMapper is greater than 1.
In-Reply-To: <JIRA.12655012.1476475952000@Atlassian.JIRA>
References: <JIRA.12655012.1476475952000@Atlassian.JIRA>
	<JIRA.12655012.1476475952156@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655012.1476475952000.28275.1476475980057@Atlassian.JIRA>

Ilia Vassilev created ELY-665:
---------------------------------

             Summary: Ensure that the "index" attribute in AttributeMapper is greater than 1. 
                 Key: ELY-665
                 URL: https://issues.jboss.org/browse/ELY-665
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Realms
    Affects Versions: 1.1.0.Beta10
            Reporter: Ilia Vassilev
            Assignee: Ilia Vassilev






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 17:15:02 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 14 Oct 2016 17:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7284) group-properties can be added
 without path in Elytron properties-realm which results to invalid server
 configuration
In-Reply-To: <JIRA.12654202.1476187869000@Atlassian.JIRA>
References: <JIRA.12654202.1476187869000@Atlassian.JIRA>
	<JIRA.12654202.1476187869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654202.1476187869000.28371.1476479702336@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7284:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> group-properties can be added without path in Elytron properties-realm which results to invalid server configuration
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7284
>                 URL: https://issues.jboss.org/browse/WFLY-7284
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>
> Adding {{groups-properties}} without {{path}} through CLI is allowed by Elytron subsystem which results to XMLStreamException after server is reloaded/restarted.
> Exception in server log after reload/restart:
> {code}
> ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:355)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[345,21]
> Message: WFLYCTL0133: Missing required attribute(s): path
> 	at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:180)
> 	at org.wildfly.extension.elytron.RealmParser.readFileAttributes(RealmParser.java:522)
> 	at org.wildfly.extension.elytron.RealmParser.readPropertiesRealm(RealmParser.java:337)
> 	at org.wildfly.extension.elytron.RealmParser.readRealms(RealmParser.java:118)
> 	at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:114)
> 	at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:72)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml_5.parseServerProfile(StandaloneXml_5.java:591)
> 	at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:245)
> 	at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> 	... 3 more
> FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 17:18:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 14 Oct 2016 17:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7285) Elytron - inconsistency
 between DMR and XSD representation of simple-permission-mapper
In-Reply-To: <JIRA.12654204.1476188033000@Atlassian.JIRA>
References: <JIRA.12654204.1476188033000@Atlassian.JIRA>
	<JIRA.12654204.1476188033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654204.1476188033000.28386.1476479880381@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7285:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-7285
>                 URL: https://issues.jboss.org/browse/WFLY-7285
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>            Priority: Optional
>
> There are inconsistencies between DMR and XSD representation of {{simple-permission-mapper}}.
> According to XSD both {{permission-mapping}} [1] and its inner {{permission}} [2] must occur at least one times in {{simple-permission-mapper}}. According to DMR they are {{"nillable" => true}}. This should be unified.
> [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1513
> [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1516



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 17:19:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 14 Oct 2016 17:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7286) Elytron - inconsistency
 between DMR and XSD representation of
 mechanism-provider-filtering-sasl-server-factory
In-Reply-To: <JIRA.12654207.1476188153000@Atlassian.JIRA>
References: <JIRA.12654207.1476188153000@Atlassian.JIRA>
	<JIRA.12654207.1476188153000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654207.1476188153000.28401.1476479940308@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7286:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7286
>                 URL: https://issues.jboss.org/browse/WFLY-7286
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>            Priority: Optional
>
> There is an inconsistency between DMR and XSD representation of {{mechanism-provider-filtering-sasl-server-factory}}.
> According to XSD [1] {{filters}} may not occur in {{mechanism-provider-filtering-sasl-server-factory}}. According to DMR {{filters}} is {{"nillable" => false}}. This should be unified.
> [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L2734



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 14 18:37:00 2016
From: issues at jboss.org (=?UTF-8?Q?Radom=C3=ADr_Vach_=28JIRA=29?=)
Date: Fri, 14 Oct 2016 18:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@Atlassian.JIRA>
References: <JIRA.12508879.1382966687000@Atlassian.JIRA>
	<JIRA.12508879.1382966687000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.28458.1476484620949@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307429#comment-13307429 ] 

Radom?r Vach commented on WFLY-2391:
------------------------------------

Hi,
I have the same problem with exploded files. After some time wildfly start to cache XHTML file and provide me old files. I have Wildfly 10.1

> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>         Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Sat Oct 15 04:09:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 15 Oct 2016 04:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in statefull cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.28499.1476518940248@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1323:
-------------------------------------
    Priority: Minor  (was: Major)


> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png, Selection_247.png, Selection_249.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct 15 04:27:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 15 Oct 2016 04:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Stateful working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.28510.1476520020186@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307441#comment-13307441 ] 

Geoffrey De Smet commented on DROOLS-1326:
------------------------------------------

That went into a different path, and a apparently this is a rare bug, so it didn't reproduce there.

The first solver should have a CH stepCountLimit termination of 403 steps.
The second solver should run the rest of the CH entirely and have an LS stepCountLimit termination of 1233 steps.
The third solver should just run.

At each point confirm that the score is the same as in the original log.

There's still an edge case that that doesn't reproduce it - if the the last step of the first solver's CH saw only half the moves and picked a less optimal one - but let's worry about that if we see that. Let's talk on Monday if you can use more info.

> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-1326
>                 URL: https://issues.jboss.org/browse/DROOLS-1326
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/
> I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct 15 04:58:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 15 Oct 2016 04:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-666) LDAP referrals does not work
 for Elytron dir-context since value of dir-context.referral-mode is always
 ignored
In-Reply-To: <JIRA.12655021.1476521834000@Atlassian.JIRA>
References: <JIRA.12655021.1476521834000@Atlassian.JIRA>
	<JIRA.12655021.1476521834544@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655021.1476521834000.28520.1476521880275@Atlassian.JIRA>

Jan Kalina created ELY-666:
------------------------------

             Summary: LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored
                 Key: ELY-666
                 URL: https://issues.jboss.org/browse/ELY-666
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Jan Kalina
            Assignee: Jan Kalina
            Priority: Blocker


Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 

InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].

We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.

[1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct 15 04:58:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 15 Oct 2016 04:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7320) LDAP referrals does not work
 for Elytron dir-context since value of dir-context.referral-mode is always
 ignored
In-Reply-To: <JIRA.12655021.1476521835000@Atlassian.JIRA>
References: <JIRA.12655021.1476521835000@Atlassian.JIRA>
	<JIRA.12655021.1476521835000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655021.1476521835000.28523.1476521880399@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved ELY-666 to WFLY-7320:
--------------------------------------

    Project: WildFly  (was: WildFly Elytron)
        Key: WFLY-7320  (was: ELY-666)


> LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7320
>                 URL: https://issues.jboss.org/browse/WFLY-7320
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct 15 04:58:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 15 Oct 2016 04:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7320) LDAP referrals does not work
 for Elytron dir-context since value of dir-context.referral-mode is always
 ignored
In-Reply-To: <JIRA.12655021.1476521835000@Atlassian.JIRA>
References: <JIRA.12655021.1476521835000@Atlassian.JIRA>
	<JIRA.12655021.1476521835000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655021.1476521835000.28528.1476521880566@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7320:
-----------------------------
    Component/s: Security


> LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7320
>                 URL: https://issues.jboss.org/browse/WFLY-7320
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct 15 05:07:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 15 Oct 2016 05:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7320) LDAP referrals does not work
 - need to set custom filter
In-Reply-To: <JIRA.12655021.1476521835000@Atlassian.JIRA>
References: <JIRA.12655021.1476521835000@Atlassian.JIRA>
	<JIRA.12655021.1476521835000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655021.1476521835000.28534.1476522420307@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7320:
-----------------------------
    Summary: LDAP referrals does not work - need to set custom filter  (was: LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored)


> LDAP referrals does not work - need to set custom filter
> --------------------------------------------------------
>
>                 Key: WFLY-7320
>                 URL: https://issues.jboss.org/browse/WFLY-7320
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct 15 05:08:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 15 Oct 2016 05:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-663) LDAP referrals does not work -
 dir-context.referral-mode is always ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.28537.1476522480224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-663:
---------------------------
    Summary: LDAP referrals does not work - dir-context.referral-mode is always ignored  (was: LDAP referrals does not work for Elytron dir-context since value of dir-context.referral-mode is always ignored)


> LDAP referrals does not work - dir-context.referral-mode is always ignored
> --------------------------------------------------------------------------
>
>                 Key: ELY-663
>                 URL: https://issues.jboss.org/browse/ELY-663
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct 15 07:09:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 15 Oct 2016 07:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-667) Release WildFly Elytron
	1.1.0.Beta11
In-Reply-To: <JIRA.12655024.1476529730000@Atlassian.JIRA>
References: <JIRA.12655024.1476529730000@Atlassian.JIRA>
	<JIRA.12655024.1476529730606@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655024.1476529730000.28600.1476529740411@Atlassian.JIRA>

Darran Lofthouse created ELY-667:
------------------------------------

             Summary: Release WildFly Elytron 1.1.0.Beta11
                 Key: ELY-667
                 URL: https://issues.jboss.org/browse/ELY-667
             Project: WildFly Elytron
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta11






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct 15 07:22:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 15 Oct 2016 07:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1867) Upgrade to WildFly Elytron
	1.1.0.Beta11
In-Reply-To: <JIRA.12655025.1476530491000@Atlassian.JIRA>
References: <JIRA.12655025.1476530491000@Atlassian.JIRA>
	<JIRA.12655025.1476530491863@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655025.1476530491000.28604.1476530520339@Atlassian.JIRA>

Darran Lofthouse created WFCORE-1867:
----------------------------------------

             Summary: Upgrade to WildFly Elytron 1.1.0.Beta11
                 Key: WFCORE-1867
                 URL: https://issues.jboss.org/browse/WFCORE-1867
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha10






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 04:46:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 16 Oct 2016 04:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2111) Sticky site masters
In-Reply-To: <JIRA.12655118.1476607550000@Atlassian.JIRA>
References: <JIRA.12655118.1476607550000@Atlassian.JIRA>
	<JIRA.12655118.1476607550690@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655118.1476607550000.238.1476607560159@Atlassian.JIRA>

Bela Ban created JGRP-2111:
------------------------------

             Summary: Sticky site masters
                 Key: JGRP-2111
                 URL: https://issues.jboss.org/browse/JGRP-2111
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.6.12, 4.0


If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.

Example:
* Member C in site LON sends messages C1 and C2 to site NYC
* C1 picks SM1 and C2 picks SM2
* Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 04:47:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 16 Oct 2016 04:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2112) Sticky site masters
In-Reply-To: <JIRA.12655119.1476607609000@Atlassian.JIRA>
References: <JIRA.12655119.1476607609000@Atlassian.JIRA>
	<JIRA.12655119.1476607609634@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655119.1476607609000.241.1476607620191@Atlassian.JIRA>

Bela Ban created JGRP-2112:
------------------------------

             Summary: Sticky site masters
                 Key: JGRP-2112
                 URL: https://issues.jboss.org/browse/JGRP-2112
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.6.12, 4.0


If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.

Example:
* Member C in site LON sends messages C1 and C2 to site NYC
* C1 picks SM1 and C2 picks SM2
* Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 05:01:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 16 Oct 2016 05:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2112) Sticky site masters
In-Reply-To: <JIRA.12655119.1476607610000@Atlassian.JIRA>
References: <JIRA.12655119.1476607610000@Atlassian.JIRA>
	<JIRA.12655119.1476607610000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655119.1476607610000.254.1476608460251@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2112:
---------------------------
    Description: 
If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.

Example:
* Member C in site LON sends messages C1 and C2 to site NYC
* C1 picks SM1 and C2 picks SM2
* Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues

h4. Design
* When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller
* Note that this only applies when we have more than one site master.
* The callback passes the address of the original caller and the list of available site masters, and needs to return a site master

h5. Transactions
* Transactions by different originators with overlapping key sets cannot be reliably ordered
* Transactional support therefore requires single site masters
* This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates


  was:
If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.

Example:
* Member C in site LON sends messages C1 and C2 to site NYC
* C1 picks SM1 and C2 picks SM2
* Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues



> Sticky site masters
> -------------------
>
>                 Key: JGRP-2112
>                 URL: https://issues.jboss.org/browse/JGRP-2112
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.12, 4.0
>
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
> h4. Design
> * When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller
> * Note that this only applies when we have more than one site master.
> * The callback passes the address of the original caller and the list of available site masters, and needs to return a site master
> h5. Transactions
> * Transactions by different originators with overlapping key sets cannot be reliably ordered
> * Transactional support therefore requires single site masters
> * This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 05:06:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 16 Oct 2016 05:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2111) Sticky site masters
In-Reply-To: <JIRA.12655118.1476607551000@Atlassian.JIRA>
References: <JIRA.12655118.1476607551000@Atlassian.JIRA>
	<JIRA.12655118.1476607551000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655118.1476607551000.259.1476608760288@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-2111.
--------------------------
    Resolution: Done


> Sticky site masters
> -------------------
>
>                 Key: JGRP-2111
>                 URL: https://issues.jboss.org/browse/JGRP-2111
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.12, 4.0
>
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 05:07:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 16 Oct 2016 05:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2111) Sticky site masters
In-Reply-To: <JIRA.12655118.1476607551000@Atlassian.JIRA>
References: <JIRA.12655118.1476607551000@Atlassian.JIRA>
	<JIRA.12655118.1476607551000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655118.1476607551000.261.1476608820085@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban deleted JGRP-2111:
---------------------------


> Sticky site masters
> -------------------
>
>                 Key: JGRP-2111
>                 URL: https://issues.jboss.org/browse/JGRP-2111
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 05:27:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 16 Oct 2016 05:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2110) Transport: revisit buffers
	and threading
In-Reply-To: <JIRA.12653915.1476027787000@Atlassian.JIRA>
References: <JIRA.12653915.1476027787000@Atlassian.JIRA>
	<JIRA.12653915.1476027787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653915.1476027787000.264.1476610020114@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307531#comment-13307531 ] 

Bela Ban commented on JGRP-2110:
--------------------------------

Measure performance on edg-perf. The current thinking is that I'll revisit this in 5.0 when supporting direct buffers and off-heap.

> Transport: revisit buffers and threading
> ----------------------------------------
>
>                 Key: JGRP-2110
>                 URL: https://issues.jboss.org/browse/JGRP-2110
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> (Concerns only the receiver side)
> h4. Parsing
> Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
> This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
> h4. Buffers
> * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
> * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
> * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
> h4. Approaches
> # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
> # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
> # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
> # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
> h4. Goals
> Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 06:43:00 2016
From: issues at jboss.org (Marcel Kolsteren (JIRA))
Date: Sun, 16 Oct 2016 06:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6885) Exception swallowed by
 CmtTxInterceptor if transaction has been cancelled by reaper
In-Reply-To: <JIRA.12640957.1469657640000@Atlassian.JIRA>
References: <JIRA.12640957.1469657640000@Atlassian.JIRA>
	<JIRA.12640957.1469657640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640957.1469657640000.271.1476614580213@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307533#comment-13307533 ] 

Marcel Kolsteren commented on WFLY-6885:
----------------------------------------

Apparently the auto-assign has left the issue unassigned. Can someone please assign it? I think exception swallowing is a major issue.

> Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-6885
>                 URL: https://issues.jboss.org/browse/WFLY-6885
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Marcel Kolsteren
>         Attachments: tx-timeout.zip
>
>
> The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method.
> I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test).
> I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here
> [https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/org/jboss/as/ejb3/tx/CMTTxInterceptor.java]
> This happens (I verified by stepping through the code with the debugger):
> * The catch block of invokeInOurTx is entered.
> * The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception.
> * The finally block of invokeInOurTx is entered.
> * The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause.
> The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-667) Release WildFly Elytron
	1.1.0.Beta11
In-Reply-To: <JIRA.12655024.1476529731000@Atlassian.JIRA>
References: <JIRA.12655024.1476529731000@Atlassian.JIRA>
	<JIRA.12655024.1476529731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655024.1476529731000.274.1476616022003@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-667:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Release WildFly Elytron 1.1.0.Beta11
> ------------------------------------
>
>                 Key: ELY-667
>                 URL: https://issues.jboss.org/browse/ELY-667
>             Project: WildFly Elytron
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore
 interaction from within SASL mechanisms.
In-Reply-To: <JIRA.12654913.1476446086000@Atlassian.JIRA>
References: <JIRA.12654913.1476446086000@Atlassian.JIRA>
	<JIRA.12654913.1476446086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654913.1476446086000.278.1476616022194@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-662:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Eliminate CredentialStore interaction from within SASL mechanisms.
> ------------------------------------------------------------------
>
>                 Key: ELY-662
>                 URL: https://issues.jboss.org/browse/ELY-662
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Credential Store, SASL
>            Reporter: Darran Lofthouse
>            Assignee: Peter Skopek
>            Priority: Critical
>             Fix For: 1.1.0.Beta12
>
>
> The conversion between callbacks and credential store should be handled centrally within the callback handler and not within the mechanism.
> This way all mechanisms can use the core integration including mechanisms that may not be Elytron aware just using standard Java callbacks.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism
	implementations final
In-Reply-To: <JIRA.12654448.1476279388000@Atlassian.JIRA>
References: <JIRA.12654448.1476279388000@Atlassian.JIRA>
	<JIRA.12654448.1476279388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654448.1476279388000.281.1476616022253@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-659:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Make all mechanism implementations final
> ----------------------------------------
>
>                 Key: ELY-659
>                 URL: https://issues.jboss.org/browse/ELY-659
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Mechanisms, HTTP, SASL
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.0.Beta12
>
>
> It is very important to make all the mechanism implementations final.  Relatedly, they should have no protected members.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-650) Improvements to Elytron Web and
 Undertow Testsuite
In-Reply-To: <JIRA.12652890.1475268145000@Atlassian.JIRA>
References: <JIRA.12652890.1475268145000@Atlassian.JIRA>
	<JIRA.12652890.1475268145000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652890.1475268145000.284.1476616022370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-650:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Improvements to Elytron Web and Undertow Testsuite
> --------------------------------------------------
>
>                 Key: ELY-650
>                 URL: https://issues.jboss.org/browse/ELY-650
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-625) Include the client schema in
	the jar
In-Reply-To: <JIRA.12649008.1473182069000@Atlassian.JIRA>
References: <JIRA.12649008.1473182069000@Atlassian.JIRA>
	<JIRA.12649008.1473182069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649008.1473182069000.297.1476616022703@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-625:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Include the client schema in the jar
> ------------------------------------
>
>                 Key: ELY-625
>                 URL: https://issues.jboss.org/browse/ELY-625
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>
> We need to get the schema into the jar so when assembled in a WildFly feature pack it can be extracted.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-617) Review 'null' handling for
 MechanismConfiguration and MechanismRealmConfiguration
In-Reply-To: <JIRA.12641565.1470136074000@Atlassian.JIRA>
References: <JIRA.12641565.1470136074000@Atlassian.JIRA>
	<JIRA.12641565.1470136074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641565.1470136074000.300.1476616022792@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-617:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration
> ---------------------------------------------------------------------------------
>
>                 Key: ELY-617
>                 URL: https://issues.jboss.org/browse/ELY-617
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>
> Javadoc states various NameRewriter instances will not be null, implementation suggests otherwise.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-639) SecurityIdentity and
 PeerIdentity should have more runAs* variants
In-Reply-To: <JIRA.12651566.1474559731000@Atlassian.JIRA>
References: <JIRA.12651566.1474559731000@Atlassian.JIRA>
	<JIRA.12651566.1474559731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651566.1474559731000.294.1476616022609@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-639:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> SecurityIdentity and PeerIdentity should have more runAs* variants
> ------------------------------------------------------------------
>
>                 Key: ELY-639
>                 URL: https://issues.jboss.org/browse/ELY-639
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI
>            Reporter: David Lloyd
>             Fix For: 1.1.0.Beta12
>
>
> The XxxIdentity classes have fewer runAs modes than (for example) Contextual objects do.  Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-606) Wrap the match elements with an
 outer match element.
In-Reply-To: <JIRA.12641108.1469719591000@Atlassian.JIRA>
References: <JIRA.12641108.1469719591000@Atlassian.JIRA>
	<JIRA.12641108.1469719591000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641108.1469719591000.312.1476616023130@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-606:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Wrap the match elements with an outer match element.
> ----------------------------------------------------
>
>                 Key: ELY-606
>                 URL: https://issues.jboss.org/browse/ELY-606
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.1.0.Beta12
>
>
> For each match type we support at most one definition of each - by adding a wrapper element we can use xsd:all to more accurately reflect this.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-643) On the SSLContextBuilder
 support setUseCipherSuitesOrder
In-Reply-To: <JIRA.12652051.1474912734000@Atlassian.JIRA>
References: <JIRA.12652051.1474912734000@Atlassian.JIRA>
	<JIRA.12652051.1474912734000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652051.1474912734000.291.1476616022522@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-643:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> On the SSLContextBuilder support setUseCipherSuitesOrder
> --------------------------------------------------------
>
>                 Key: ELY-643
>                 URL: https://issues.jboss.org/browse/ELY-643
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SSL
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.1.0.Beta12
>
>
> Currently we hard code this value to 'true' which should remain the default as the OpenSSL style cipher suite selection includes preferred mechanism ordering - however it should be possible to override this and set it to false.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-583) Add ability for outbound
 clients to directly consume IdentityCredentials
In-Reply-To: <JIRA.12635646.1467118850000@Atlassian.JIRA>
References: <JIRA.12635646.1467118850000@Atlassian.JIRA>
	<JIRA.12635646.1467118850000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12635646.1467118850000.324.1476616023523@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-583:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Add ability for outbound clients to directly consume IdentityCredentials
> ------------------------------------------------------------------------
>
>                 Key: ELY-583
>                 URL: https://issues.jboss.org/browse/ELY-583
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.Beta12
>
>
> Outbound clients can gain substantial flexibility by being able to use {{IdentityCredentials}} directly.  This allows a non-type-specific object like a {{byte[]}} to be interpreted as many different types of credentials.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-649) Make the exists and create
 methods on HttpScope default
In-Reply-To: <JIRA.12652555.1475150598000@Atlassian.JIRA>
References: <JIRA.12652555.1475150598000@Atlassian.JIRA>
	<JIRA.12652555.1475150598000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652555.1475150598000.287.1476616022422@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-649:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Make the exists and create methods on HttpScope default
> -------------------------------------------------------
>
>                 Key: ELY-649
>                 URL: https://issues.jboss.org/browse/ELY-649
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI, HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-509) Multi Step HTTP Authentication
In-Reply-To: <JIRA.12616266.1461247017000@Atlassian.JIRA>
References: <JIRA.12616266.1461247017000@Atlassian.JIRA>
	<JIRA.12616266.1461247017000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616266.1461247017000.335.1476616023736@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-509:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Multi Step HTTP Authentication
> ------------------------------
>
>                 Key: ELY-509
>                 URL: https://issues.jboss.org/browse/ELY-509
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Farah Juma
>             Fix For: 1.1.0.Beta12
>
>
> This is a variation of FORM authentication and closely related to  ELY-508.
> The scenario would be prompt for a username, then prompt for a password and if the password is valid and the account supports OTP prompt for the OTP.
> The mechanism may also be responsible for sending the OTP but that is probably a side topic.
> I have raised this in terms of being a HTTP mechanism but the main point we need to ensure is covered is the requirements about identifying what checks are required for a specific user and tracking they are all complete.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:02 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-613) Some nested classes should be
 considered to be static nested in Elytron
In-Reply-To: <JIRA.12641227.1469789814000@Atlassian.JIRA>
References: <JIRA.12641227.1469789814000@Atlassian.JIRA>
	<JIRA.12641227.1469789814000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641227.1469789814000.304.1476616022942@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-613:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Some nested classes should be considered to be static nested in Elytron
> -----------------------------------------------------------------------
>
>                 Key: ELY-613
>                 URL: https://issues.jboss.org/browse/ELY-613
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta7
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta12
>
>
> There are some inner classes in Elytron which should be considered to be static nested to avoid dependency on their outer class. Following nested classes should be considered:
> * LoadedIdentity and Identity from org.wildfly.security.auth.realm.FileSystemSecurityRealm
> * DecoderState from org.wildfly.security.asn1.DERDecoder
> * AccountEntry from org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm
> * JaasAuthorizationIdentity and DefaultCallbackHandler from org.wildfly.security.auth.realm.JaasSecurityRealm
> * LoadKey from org.wildfly.security.keystore.AtomicLoadKeyStore



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-595) Ability to provide
 CallbackHandler and SSLContext when AuthenticationConfiguration dynamically
 loaded.
In-Reply-To: <JIRA.12640311.1469199395000@Atlassian.JIRA>
References: <JIRA.12640311.1469199395000@Atlassian.JIRA>
	<JIRA.12640311.1469199395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640311.1469199395000.321.1476616023415@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-595:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Ability to provide CallbackHandler and SSLContext when AuthenticationConfiguration dynamically loaded.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-595
>                 URL: https://issues.jboss.org/browse/ELY-595
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-559) Token-based authentication
 should forward authentication
In-Reply-To: <JIRA.12629124.1464822065000@Atlassian.JIRA>
References: <JIRA.12629124.1464822065000@Atlassian.JIRA>
	<JIRA.12629124.1464822065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629124.1464822065000.327.1476616023580@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-559:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Token-based authentication should forward authentication
> --------------------------------------------------------
>
>                 Key: ELY-559
>                 URL: https://issues.jboss.org/browse/ELY-559
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Mechanisms
>            Reporter: David Lloyd
>             Fix For: 1.1.0.Beta12
>
>
> Mechanisms that handle BearerTokenCredetials (ELY-557) should forward them as public or private credentials (ELY-473 / https://github.com/wildfly-security/wildfly-elytron/pull/434 ).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-490) Add JavaDoc for the
 'org.wildfly.security.ssl' package and sub packages.
In-Reply-To: <JIRA.12613309.1459854206000@Atlassian.JIRA>
References: <JIRA.12613309.1459854206000@Atlassian.JIRA>
	<JIRA.12613309.1459854206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613309.1459854206000.338.1476616023835@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-490:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages.
> ------------------------------------------------------------------------
>
>                 Key: ELY-490
>                 URL: https://issues.jboss.org/browse/ELY-490
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.309.1476616023031@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-609:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Unguarded read in ElytronPolicyConfiguration
> --------------------------------------------
>
>                 Key: ELY-609
>                 URL: https://issues.jboss.org/browse/ELY-609
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta7
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta12
>
>
> Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-489) Add JavaDoc for the
 'org.wildfly.security.mechanism' package and sub packages.
In-Reply-To: <JIRA.12613308.1459854107000@Atlassian.JIRA>
References: <JIRA.12613308.1459854107000@Atlassian.JIRA>
	<JIRA.12613308.1459854107000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613308.1459854107000.341.1476616023893@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-489:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Add JavaDoc for the 'org.wildfly.security.mechanism' package and sub packages.
> ------------------------------------------------------------------------------
>
>                 Key: ELY-489
>                 URL: https://issues.jboss.org/browse/ELY-489
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-601) Adjust all
 AuthenticationConfiguration 'use' methods to more closely match the schema
In-Reply-To: <JIRA.12640663.1469539027000@Atlassian.JIRA>
References: <JIRA.12640663.1469539027000@Atlassian.JIRA>
	<JIRA.12640663.1469539027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640663.1469539027000.315.1476616023197@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-601:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Adjust all AuthenticationConfiguration 'use' methods to more closely match the schema
> -------------------------------------------------------------------------------------
>
>                 Key: ELY-601
>                 URL: https://issues.jboss.org/browse/ELY-601
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.1.0.Beta12
>
>
> Within the schema a lot of these are configured using 'set'*' elements - switch the methods over to set as well.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-524) Caching support in the LDAP
	realm
In-Reply-To: <JIRA.12618201.1462379575000@Atlassian.JIRA>
References: <JIRA.12618201.1462379575000@Atlassian.JIRA>
	<JIRA.12618201.1462379575000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618201.1462379575000.331.1476616023662@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-524:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Caching support in the LDAP realm
> ---------------------------------
>
>                 Key: ELY-524
>                 URL: https://issues.jboss.org/browse/ELY-524
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Realms
>            Reporter: David Lloyd
>            Assignee: Pedro Igor
>            Priority: Critical
>             Fix For: 1.1.0.Beta12
>
>
> The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic.
> The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these.  Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention.
> For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes.
> Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name.
> This is a complex design topic so discussion is welcome.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-600) Remove minOccurs="1" and
 maxOccurs="1" from the schema as these are the defaults.
In-Reply-To: <JIRA.12640625.1469529058000@Atlassian.JIRA>
References: <JIRA.12640625.1469529058000@Atlassian.JIRA>
	<JIRA.12640625.1469529058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640625.1469529058000.318.1476616023319@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-600:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults.
> ---------------------------------------------------------------------------------
>
>                 Key: ELY-600
>                 URL: https://issues.jboss.org/browse/ELY-600
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-477)
 XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
In-Reply-To: <JIRA.12613085.1459771072000@Atlassian.JIRA>
References: <JIRA.12613085.1459771072000@Atlassian.JIRA>
	<JIRA.12613085.1459771072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613085.1459771072000.350.1476616024138@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-477:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
> ----------------------------------------------------------
>
>                 Key: ELY-477
>                 URL: https://issues.jboss.org/browse/ELY-477
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.1.0.Beta4
>            Reporter: Ondrej Lukas
>             Fix For: 1.1.0.Beta12
>
>
> Test XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK with:
> {code}
> expected:<-1> but was:<7>
> and stacktrace:
> java.lang.AssertionError: expected:<-1> but was:<7>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:743)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.junit.Assert.assertEquals(Assert.java:555)
> 	at org.junit.Assert.assertEquals(Assert.java:542)
> 	at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:96)
>     ...
> {code}
> It is caused by undefined line number of XML parsing failure for IBM JDK. 
> Stacktrace of checked XMLStreamException for IBM JDK:
> {code}
> org.wildfly.client.config.ConfigXMLParseException: 
> CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered
> 	at authentication-client.xml:
> 	at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118)
> 	at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93)
>     ...
> {code}
> Stacktrace of checked XMLStreamException for Oracle JDK:
> {code}
> org.wildfly.client.config.ConfigXMLParseException: 
> CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered
> 	at authentication-client.xml:7:39:
> 	at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118)
> 	at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93)
>     ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-457) SASL SAML Authentication
	Mechanism
In-Reply-To: <JIRA.12610630.1458114939000@Atlassian.JIRA>
References: <JIRA.12610630.1458114939000@Atlassian.JIRA>
	<JIRA.12610630.1458114939000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610630.1458114939000.353.1476616024241@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-457:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> SASL SAML Authentication Mechanism
> ----------------------------------
>
>                 Key: ELY-457
>                 URL: https://issues.jboss.org/browse/ELY-457
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>
> https://tools.ietf.org/html/rfc6595



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-433) Support verification of a users
 certificate against an LDAP Server
In-Reply-To: <JIRA.12608617.1456935208000@Atlassian.JIRA>
References: <JIRA.12608617.1456935208000@Atlassian.JIRA>
	<JIRA.12608617.1456935208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12608617.1456935208000.370.1476616024598@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-433:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Support verification of a users certificate against an LDAP Server
> ------------------------------------------------------------------
>
>                 Key: ELY-433
>                 URL: https://issues.jboss.org/browse/ELY-433
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Realms, SSL
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.1.0.Beta12
>
>
> LDAP realm should be able to authenticate user using user certificate.
> This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-456) HTTP SAML Authentication
	Mechanism
In-Reply-To: <JIRA.12610629.1458114904000@Atlassian.JIRA>
References: <JIRA.12610629.1458114904000@Atlassian.JIRA>
	<JIRA.12610629.1458114904000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610629.1458114904000.356.1476616024310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-456:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> HTTP SAML Authentication Mechanism
> ----------------------------------
>
>                 Key: ELY-456
>                 URL: https://issues.jboss.org/browse/ELY-456
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:03 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-486) Add JavaDoc for the
 'org.wildfly.security.credential' package and sub packages.
In-Reply-To: <JIRA.12613298.1459853853000@Atlassian.JIRA>
References: <JIRA.12613298.1459853853000@Atlassian.JIRA>
	<JIRA.12613298.1459853853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613298.1459853853000.344.1476616023992@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-486:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Add JavaDoc for the 'org.wildfly.security.credential' package and sub packages.
> -------------------------------------------------------------------------------
>
>                 Key: ELY-486
>                 URL: https://issues.jboss.org/browse/ELY-486
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-449) Add CredentialStore support to
 Elytron client configuration
In-Reply-To: <JIRA.12610491.1458044783000@Atlassian.JIRA>
References: <JIRA.12610491.1458044783000@Atlassian.JIRA>
	<JIRA.12610491.1458044783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610491.1458044783000.362.1476616024457@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-449:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Add CredentialStore support to Elytron client configuration
> -----------------------------------------------------------
>
>                 Key: ELY-449
>                 URL: https://issues.jboss.org/browse/ELY-449
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Authentication Client, Credential Store
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-455) OAuth2 Credential Store
In-Reply-To: <JIRA.12610625.1458113565000@Atlassian.JIRA>
References: <JIRA.12610625.1458113565000@Atlassian.JIRA>
	<JIRA.12610625.1458113565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610625.1458113565000.359.1476616024406@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-455:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> OAuth2 Credential Store
> -----------------------
>
>                 Key: ELY-455
>                 URL: https://issues.jboss.org/browse/ELY-455
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Credential Store
>            Reporter: David Lloyd
>             Fix For: 1.1.0.Beta12
>
>
> Need an OAuth2 credential store which can acquire a cached OAuth2 token or instigate a new authentication.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore
	xsd/parser mismatch
In-Reply-To: <JIRA.12586656.1443615679000@Atlassian.JIRA>
References: <JIRA.12586656.1443615679000@Atlassian.JIRA>
	<JIRA.12586656.1443615679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586656.1443615679000.377.1476616024777@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-298:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> load-from/uri keystore xsd/parser mismatch
> ------------------------------------------
>
>                 Key: ELY-298
>                 URL: https://issues.jboss.org/browse/ELY-298
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>
> The xsd has
> {code}
>   <xsd:complexType name="key-store-type">
>         <xsd:sequence minOccurs="1" maxOccurs="1">
>             <!-- Access source type -->
>             <xsd:choice minOccurs="1" maxOccurs="1">
>                 <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {code}
> The parser seems to look for 'uri' rather than 'load-from'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-444) AuthorizationIdentity and
	PermissionMapper
In-Reply-To: <JIRA.12610300.1457958793000@Atlassian.JIRA>
References: <JIRA.12610300.1457958793000@Atlassian.JIRA>
	<JIRA.12610300.1457958793000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610300.1457958793000.366.1476616024531@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-444:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> AuthorizationIdentity and PermissionMapper
> ------------------------------------------
>
>                 Key: ELY-444
>                 URL: https://issues.jboss.org/browse/ELY-444
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI, Realms
>            Reporter: David Lloyd
>             Fix For: 1.1.0.Beta12
>
>
> When we initially designed the PermissionMapper we went to certain lengths to avoid exposing details of the realm.  But now as the API has evolved it is clear that the permission mapper will need access to more information.  The AuthorizationIdentity (or perhaps another object which includes the AuthorizationIdentity) should be made available to the permission mapper.
> In addition, this object could be expanded to include more information about the authentication, for example mechanism-specific information, which can feed into the authorization decision and could be useful for other things.  Examples include: authentication timestamp, mechanism name/kind, forwarding credentials, and other attributes which derive from the mechanism as opposed to the identity.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-398) Authorization decisions for
 identity manipulation
In-Reply-To: <JIRA.12596730.1450185483000@Atlassian.JIRA>
References: <JIRA.12596730.1450185483000@Atlassian.JIRA>
	<JIRA.12596730.1450185483000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12596730.1450185483000.373.1476616024694@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-398:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Authorization decisions for identity manipulation
> -------------------------------------------------
>
>                 Key: ELY-398
>                 URL: https://issues.jboss.org/browse/ELY-398
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Realms
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>
> We need to ensure we have appropriate permissions checks in place where one identity is manipulating another identity.
> It is possible the subsystem will take a lot of the responsibility but lets start here with an issue.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-485) Add JavaDoc for the
 'org.wildfly.security.auth.server' package and sub packages.
In-Reply-To: <JIRA.12613296.1459853809000@Atlassian.JIRA>
References: <JIRA.12613296.1459853809000@Atlassian.JIRA>
	<JIRA.12613296.1459853809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613296.1459853809000.347.1476616024047@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-485:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Add JavaDoc for the 'org.wildfly.security.auth.server' package and sub packages.
> --------------------------------------------------------------------------------
>
>                 Key: ELY-485
>                 URL: https://issues.jboss.org/browse/ELY-485
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:04 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-212) Client-side SSL context
 configuration is subtly wrong
In-Reply-To: <JIRA.12574725.1434036061000@Atlassian.JIRA>
References: <JIRA.12574725.1434036061000@Atlassian.JIRA>
	<JIRA.12574725.1434036061000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574725.1434036061000.380.1476616024892@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-212:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Client-side SSL context configuration is subtly wrong
> -----------------------------------------------------
>
>                 Key: ELY-212
>                 URL: https://issues.jboss.org/browse/ELY-212
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.Beta12
>
>
> SSL context client-side configuration is problematic in that the SSL context is not (and cannot be) cached.  This means that we lose SSL session reuse and other benefits which may cause problems for users.
> However we also cannot just cache an SSL context on a configuration either - the client credentials may vary on each request, causing leakage between identities.
> What we need to do is have a separate SSL context client configuration mechanism, and use the generic client context configuration to reference this SSL context client configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:05 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-211) Client-side trust store
	configuration
In-Reply-To: <JIRA.12574700.1434031461000@Atlassian.JIRA>
References: <JIRA.12574700.1434031461000@Atlassian.JIRA>
	<JIRA.12574700.1434031461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574700.1434031461000.383.1476616025003@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-211:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Client-side trust store configuration
> -------------------------------------
>
>                 Key: ELY-211
>                 URL: https://issues.jboss.org/browse/ELY-211
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.Beta12
>
>
> Lest I forget.  The client needs the ability to supplement the default trust store, to restrict the set of acceptable peer certificates/signers, for mutual authentication purposes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:07:05 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:07:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB
	subsystems
In-Reply-To: <JIRA.12569743.1429897656000@Atlassian.JIRA>
References: <JIRA.12569743.1429897656000@Atlassian.JIRA>
	<JIRA.12569743.1429897656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569743.1429897656000.386.1476616025066@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-181:
---------------------------------
    Fix Version/s: 1.1.0.Beta12
                       (was: 1.1.0.Beta11)


> Review JACC in Servlet and EJB subsystems
> -----------------------------------------
>
>                 Key: ELY-181
>                 URL: https://issues.jboss.org/browse/ELY-181
>             Project: WildFly Elytron
>          Issue Type: Sub-task
>          Components: API / SPI
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:09:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-667) Release WildFly Elytron
	1.1.0.Beta11
In-Reply-To: <JIRA.12655024.1476529731000@Atlassian.JIRA>
References: <JIRA.12655024.1476529731000@Atlassian.JIRA>
	<JIRA.12655024.1476529731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655024.1476529731000.390.1476616140172@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-667.
----------------------------------
    Fix Version/s: 1.1.0.Beta11
                       (was: 1.1.0.Beta12)
       Resolution: Done


> Release WildFly Elytron 1.1.0.Beta11
> ------------------------------------
>
>                 Key: ELY-667
>                 URL: https://issues.jboss.org/browse/ELY-667
>             Project: WildFly Elytron
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta11
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:42:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7193) No log messages comming from
 Elytron - ssl context creation
In-Reply-To: <JIRA.12651499.1474551058000@Atlassian.JIRA>
References: <JIRA.12651499.1474551058000@Atlassian.JIRA>
	<JIRA.12651499.1474551058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651499.1474551058000.397.1476618120563@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7193:
-----------------------------------
    Affects Version/s:     (was: 11.0.0.Alpha1)


> No log messages comming from Elytron - ssl context creation
> -----------------------------------------------------------
>
>                 Key: WFLY-7193
>                 URL: https://issues.jboss.org/browse/WFLY-7193
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.
> Seems to me it would be useful for troubleshooting to have logged on 
> TRACE level:
> - Keystore initialization with parameters
> - Filtering keystore initialization with parameters
> - KeyManager / TrustManager initialization with parameters
> - Client / Server SSLContext initialization with parameters
> WARN level:
> - Certificate expired (on key store init, all certificates)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 16 07:42:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 16 Oct 2016 07:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7193) No log messages comming from
 Elytron - ssl context creation
In-Reply-To: <JIRA.12651499.1474551058000@Atlassian.JIRA>
References: <JIRA.12651499.1474551058000@Atlassian.JIRA>
	<JIRA.12651499.1474551058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651499.1474551058000.405.1476618120765@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7193:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> No log messages comming from Elytron - ssl context creation
> -----------------------------------------------------------
>
>                 Key: WFLY-7193
>                 URL: https://issues.jboss.org/browse/WFLY-7193
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.
> Seems to me it would be useful for troubleshooting to have logged on 
> TRACE level:
> - Keystore initialization with parameters
> - Filtering keystore initialization with parameters
> - KeyManager / TrustManager initialization with parameters
> - Client / Server SSLContext initialization with parameters
> WARN level:
> - Certificate expired (on key store init, all certificates)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 01:47:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 17 Oct 2016 01:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1329) Events already expired at
 insertion time don't have a chance to produce a match
In-Reply-To: <JIRA.12654770.1476379790000@Atlassian.JIRA>
References: <JIRA.12654770.1476379790000@Atlassian.JIRA>
	<JIRA.12654770.1476379790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654770.1476379790000.1017.1476683220056@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307594#comment-13307594 ] 

Mario Fusco commented on DROOLS-1329:
-------------------------------------

This commit is also necessary https://github.com/droolsjbpm/drools/commit/7f882d7485bf792c6d6596a02d096a57170c3b0c

> Events already expired at insertion time don't have a chance to produce a match
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-1329
>                 URL: https://issues.jboss.org/browse/DROOLS-1329
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.Beta3
>
>
> When flushing the insertion of an event that is already expired at processing (firing) time it is required that the event should however have at least a chance to produce joins and activations.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 04:37:02 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 04:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7305) Getting identity by DN in
 Elytron ldap-realm should be case insensitive
In-Reply-To: <JIRA.12654645.1476357070000@Atlassian.JIRA>
References: <JIRA.12654645.1476357070000@Atlassian.JIRA>
	<JIRA.12654645.1476357070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654645.1476357070000.1742.1476693422810@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7305:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Getting identity by DN in Elytron ldap-realm should be case insensitive
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7305
>                 URL: https://issues.jboss.org/browse/WFLY-7305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. 
> LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 04:46:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 17 Oct 2016 04:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.2097.1476693960700@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307664#comment-13307664 ] 

Jeff Mesnil commented on WFLY-5213:
-----------------------------------

I'm not sure this is a correct use case.

If you specify the org.wildfly.extension.messaging-activemq module, the code that injects JMSContext will do a JNDI lookup to locate the TransactionSynchronizationRegistry *in Artemis JNDI*.
As the code is written now, only the JNDI lookup for external resources (Artemis ConnectionFactory) must use external-context.

What's the use case? If you really want to leverage org.wildfly.extension.messaging-activemq module, it is recommended to configure a pooled-connection-factory to connect to a remote Artemis broker as explained in https://docs.jboss.org/author/display/WFLY10/Connect+a+pooled-connection-factory+to+a+Remote+Artemis+Server?_sscc=t


> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 17 04:46:00 2016
From: issues at jboss.org (Slavomir Krupa (JIRA))
Date: Mon, 17 Oct 2016 04:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1334) Kie service client should
 not allow null parameters
In-Reply-To: <JIRA.12655203.1476693923000@Atlassian.JIRA>
References: <JIRA.12655203.1476693923000@Atlassian.JIRA>
	<JIRA.12655203.1476693923514@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655203.1476693923000.2102.1476693960916@Atlassian.JIRA>

Slavomir Krupa created DROOLS-1334:
--------------------------------------

             Summary: Kie service client should not allow null parameters
                 Key: DROOLS-1334
                 URL: https://issues.jboss.org/browse/DROOLS-1334
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 6.4.0.Final
            Reporter: Slavomir Krupa
            Assignee: Edson Tirelli


This issue occurs when you are using a kie-server-client and want to query i.e. 
{code:java}
List<TaskSummary> findTasksByStatusByProcessInstanceId(Long processInstanceId, List<String> status, Integer page, Integer pageSize);
{code}
If you don't provide a processInstanceId it creates this URL:
{noformat}
http://localhost:8080/kie-server/services/rest/server/queries/tasks/instances/process/%7BpInstanceId%7D?status=Ready&page=0&pageSize=50
{noformat}
Result is a exception on the server, but I think it should be validated in a client and should not even query the server:

{noformat}
ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (http-127.0.0.1:8080-6) RESTEASY000100: Failed executing GET server/queries/tasks/instances/process/{pInstanceId}: org.jboss.resteasy.spi.BadRequestException: RESTEASY001720: Unable to extract parameter from http request: javax.ws.rs.PathParam("pInstanceId") value is {1} for public javax.ws.rs.core.Response org.kie.server.remote.rest.jbpm.RuntimeDataResource.getTasksByStatusByProcessInstanceId(javax.ws.rs.core.HttpHeaders,java.lang.Long,java.util.List,java.lang.Integer,java.lang.Integer,java.lang.String,boolean)
	at org.jboss.resteasy.core.StringParameterInjector.extractValue(StringParameterInjector.java:310) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.PathParamInjector.inject(PathParamInjector.java:117) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:137) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:160) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:560) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:130) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.10.Final-redhat-2.jar:7.5.10.Final-redhat-2]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.GeneratedConstructorAccessor154.newInstance(Unknown Source) [:1.8.0_65]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_65]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_65]
	at org.jboss.resteasy.core.StringParameterInjector.extractValue(StringParameterInjector.java:298) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
	... 28 more
Caused by: java.lang.NumberFormatException: For input string: "{pInstanceId}"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_65]
	at java.lang.Long.parseLong(Long.java:589) [rt.jar:1.8.0_65]
	at java.lang.Long.<init>(Long.java:965) [rt.jar:1.8.0_65]
	... 32 more
{noformat}






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 04:50:01 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Mon, 17 Oct 2016 04:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5879) Some multinode tests fail
 with security manager
In-Reply-To: <JIRA.12597217.1450441124000@Atlassian.JIRA>
References: <JIRA.12597217.1450441124000@Atlassian.JIRA>
	<JIRA.12597217.1450441124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597217.1450441124000.2187.1476694201767@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307672#comment-13307672 ] 

Ingo Weiss commented on WFLY-5879:
----------------------------------

[~swd847], do you mind if I take this one from you? I fixed the last of the failing tests.

> Some multinode tests fail with security manager
> -----------------------------------------------
>
>                 Key: WFLY-5879
>                 URL: https://issues.jboss.org/browse/WFLY-5879
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Test Suite
>            Reporter: Ondrej Kotek
>            Assignee: Stuart Douglas
>             Fix For: 10.2.0.Final
>
>
> *org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase}}
> fails with:
> {noformat}
> javax.naming.NamingException: Failed to create proxy
> 	at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:873)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:222)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:230)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.getStatefulRemote(ClientEjb.java:60)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.testSameTransactionEachCall(ClientEjb.java:77)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb$$$view1.testSameTransactionEachCall(Unknown Source)
> 	at org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSameTransactionEachCall(TransactionInvocationTestCase.java:97)
> {noformat}
> *org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase}}
> fails with:
> {noformat}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-2) Failed: org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances: javax.naming.NameNotFoundException: StatefulBeanA!org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.doLookup(InitialContext.java:290)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances(DynamicJNDIContextEJBInvocationTestCase.java:116)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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)
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
> 	... 145 more
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.distributable.DistributableCache.create(DistributableCache.java:94)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$DefaultViewInstanceFactory.createViewInstance(ViewService.java:302)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> 	... 148 more
> Caused by: javax.naming.NamingException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null") [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null")]
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:137)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA.onConstruct(StatefulBeanA.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:117)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBCreateInterceptor.processInvocation(SFSBCreateInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 164 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at org.jboss.ejb.client.EJBClientContext.create(EJBClientContext.java:198)
> 	at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:90)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:256)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
> 	at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:133)
> 	... 223 more
> {noformat}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> fails with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy62.remoteCall(Unknown Source)
> 	at org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote(RemoteLocalCallProfileTestCase.java:185)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
> 	at java.lang.Class.getClassLoader(Class.java:683)
> 	at org.jboss.marshalling.reflect.SerializableClassRegistry.lookup(SerializableClassRegistry.java:70)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:916)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1255)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> 	at org.jboss.ejb.client.remoting.SessionOpenResponseHandler$SessionIDResultProducer.getResult(SessionOpenResponseHandler.java:94)
> 	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:454)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:227)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:204)
> 	... 226 more
> {code}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> Fail with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy65.remoteCall(Unknown Source)
> 	at 
> {code}
> *org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode}}
> Fails with:
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.security.AccessControlException: WFSM000001: Permission check failed (permission ""(""java.net.SocketPermission"" ""10.16.91.218:9092"" ""connect,resolve"")"" in code source ""(vfs:/content/testTimerServiceSimple.war/WEB-INF/classes <no signer certificates>)"" of ""null"")" [50000-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:160)
> 	at org.h2.message.DbException.convert(DbException.java:283)
> 	at org.h2.message.DbException.toSQLException(DbException.java:256)
> 	at org.h2.message.TraceObject.logAndConvert(TraceObject.java:368)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:119)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:90)
> 	at org.h2.Driver.connect(Driver.java:73)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:319)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:350)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:285)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1319)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:708)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:607)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> 	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> 	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:614)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:482)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:308)
> 	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.java:57)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 05:22:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 05:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Internal server error is
 returned for Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.2481.1476696121349@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7295:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Internal server error is returned for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 05:35:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 05:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Internal server error is
 returned for Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.2567.1476696901362@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307714#comment-13307714 ] 

Jan Kalina commented on WFLY-7295:
----------------------------------

The cause is the Undertow obtains list of supported mechanism using getCredentialAcquireSupport(), which in LdapRealm obtains DirContext, even through no realm.ldap.CredentialLoader use it.

> Internal server error is returned for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 05:37:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 05:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7294) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication
In-Reply-To: <JIRA.12654400.1476273069000@Atlassian.JIRA>
References: <JIRA.12654400.1476273069000@Atlassian.JIRA>
	<JIRA.12654400.1476273069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654400.1476273069000.2574.1476697020486@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307715#comment-13307715 ] 

Jan Kalina commented on WFLY-7294:
----------------------------------

The cause is the Undertow obtains list of supported mechanism using getCredentialAcquireSupport(), which in LdapRealm obtains DirContext, even through no realm.ldap.CredentialLoader use it.

> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7294
>                 URL: https://issues.jboss.org/browse/WFLY-7294
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:349)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:346)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:294)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:402)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:206)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 05:37:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 05:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Internal server error is
 returned for Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.2589.1476697020968@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7295:
-----------------------------
    Comment: was deleted

(was: The cause is the Undertow obtains list of supported mechanism using getCredentialAcquireSupport(), which in LdapRealm obtains DirContext, even through no realm.ldap.CredentialLoader use it.)


> Internal server error is returned for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 05:38:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 05:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7294) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication
In-Reply-To: <JIRA.12654400.1476273069000@Atlassian.JIRA>
References: <JIRA.12654400.1476273069000@Atlassian.JIRA>
	<JIRA.12654400.1476273069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654400.1476273069000.2596.1476697080231@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7294:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7294
>                 URL: https://issues.jboss.org/browse/WFLY-7294
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:349)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:346)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:294)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:402)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:206)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 05:41:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 05:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-668) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication
In-Reply-To: <JIRA.12654400.1476273069000@Atlassian.JIRA>
References: <JIRA.12654400.1476273069000@Atlassian.JIRA>
	<JIRA.12654400.1476273069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654400.1476273069000.2603.1476697260185@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7294 to ELY-668:
--------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-668  (was: WFLY-7294)
          Component/s: Realms
                           (was: Security)
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication
> ------------------------------------------------------------------------------
>
>                 Key: ELY-668
>                 URL: https://issues.jboss.org/browse/ELY-668
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:349)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:346)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:294)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:402)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:206)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 05:52:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 17 Oct 2016 05:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2102) bind_interface="eth0" and
 bind_addr="LINK_LOCAL" config are conflict
In-Reply-To: <JIRA.12652400.1475060146000@Atlassian.JIRA>
References: <JIRA.12652400.1475060146000@Atlassian.JIRA>
	<JIRA.12652400.1475060146000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652400.1475060146000.2647.1476697920299@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307721#comment-13307721 ] 

Bela Ban commented on JGRP-2102:
--------------------------------

Why can't you use {{bind_addr="match-interface:eth2"}}?

> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
>                 Key: JGRP-2102
>                 URL: https://issues.jboss.org/browse/JGRP-2102
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.1
>         Environment: {noformat}
> [root at wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>     inet6 2606:ae00:e200:3f::83/128 scope global
>  valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>  valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>     link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
>     inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
>     inet6 2606:ae00:e200:3f::28/64 scope global
>  valid_lft forever preferred_lft forever
>     inet6 fe80::250:56ff:feab:2aea/64 scope link
>  valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
>     link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
>     inet6 fe80::250:56ff:feab:d612/64 scope link
>  valid_lft forever preferred_lft forever
> {noformat}
> There're eth0 and eth1 exists in the environment
>            Reporter: ?? ?
>            Assignee: Bela Ban
>             Fix For: 3.6.12
>
>         Attachments: jgroups-udp.xml
>
>
> Error happens while 
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
>         at java.lang.reflect.Method.invoke(Method.java:620)
>         at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
>         at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
>         at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
>         at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
>         at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
>         at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
>         ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
>         at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
>         at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
>         at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
>         at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
>         at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
>         at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
>         at org.jgroups.JChannel.init(JChannel.java:854)
>         at org.jgroups.JChannel.<init>(JChannel.java:159)
>         at org.jgroups.JChannel.<init>(JChannel.java:129)
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
>         ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
>         at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
>         at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
>         ... 48 more
> Caused by: java.lang.mail at example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
>         at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> {code}
> public static InetAddress getAddress(AddressScope scope)     //                     ----> scope is LINK_LOCAL
>     throws SocketException
>   {
>     InetAddress address = null;
>     Enumeration intfs = NetworkInterface.getNetworkInterfaces();
>     while (intfs.hasMoreElements()) {
>       NetworkInterface intf = (NetworkInterface)intfs.nextElement();
>       try {
>         if (intf.isUp()) {
>           address = getAddress(intf, scope);    //  -------> It will return the first LINK_LOCAL address from NICs list
>           if (address != null)
>             return address;
>         }
>       }
>       catch (SocketException e) {
>       }
>     }
>     return null;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 17 05:57:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 05:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Internal server error is
 returned for Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.2673.1476698220494@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307725#comment-13307725 ] 

Jan Kalina commented on WFLY-7295:
----------------------------------

As unavailable LDAP server IS internal error in this case (cannot continue until LDAP online), what is expected behaviour?

> Internal server error is returned for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 06:06:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 17 Oct 2016 06:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Internal server error is
 returned for Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.2716.1476698760373@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307733#comment-13307733 ] 

Ondrej Lukas commented on WFLY-7295:
------------------------------------

In previous server version which uses PicketBox, unreachable LDAP results to status code 401. It can be useful for eventual fallback to another type of authentication.

However, in case when returning internal server error (status code 500) to application is behavior intended by engineering then we can accept it. New documentation jira has to be reported to covered this issue since it is different behavior between Elytron and legacy configuration.

> Internal server error is returned for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 06:31:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 17 Oct 2016 06:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2110) Transport: revisit buffers
	and threading
In-Reply-To: <JIRA.12653915.1476027787000@Atlassian.JIRA>
References: <JIRA.12653915.1476027787000@Atlassian.JIRA>
	<JIRA.12653915.1476027787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653915.1476027787000.2829.1476700260198@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-2110.
--------------------------
    Resolution: Deferred


We'll revisit this in 5.0 when adding support for NIO ByteBuffers and direct memory buffers

> Transport: revisit buffers and threading
> ----------------------------------------
>
>                 Key: JGRP-2110
>                 URL: https://issues.jboss.org/browse/JGRP-2110
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> (Concerns only the receiver side)
> h4. Parsing
> Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down.
> This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below).
> h4. Buffers
> * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message.
> * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns
> * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied.
> h4. Approaches
> # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation.
> # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages.
> # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up.
> # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed.
> h4. Goals
> Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 06:32:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Mon, 17 Oct 2016 06:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7321) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700309000@Atlassian.JIRA>
References: <JIRA.12655227.1476700309000@Atlassian.JIRA>
	<JIRA.12655227.1476700309826@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700309000.2831.1476700320104@Atlassian.JIRA>

Hisanobu Okuda created WFLY-7321:
------------------------------------

             Summary: wrong parse of double quote in `\\"` 
                 Key: WFLY-7321
                 URL: https://issues.jboss.org/browse/WFLY-7321
             Project: WildFly
          Issue Type: Bug
          Components: CLI
         Environment: JBoss EAP 7.0.0
            Reporter: Hisanobu Okuda
            Assignee: Jason Greene


jboss-cli does not parse command line if command line contains `\\"`.
When a command is `/system-property=foo4:add(value="vvv\\")`, it shows the sub-prompt '> '

[standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> 




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 06:36:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Mon, 17 Oct 2016 06:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7321) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.2849.1476700560180@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hisanobu Okuda updated WFLY-7321:
---------------------------------
    Description: 
jboss-cli does not parse command line if command line contains {code}\\"{code}

When a command is 
{code}/system-property=foo4:add(value="vvv\\"){code}
it shows the sub-prompt '> ' like:

{code}
[standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> 
{code}

  was:
jboss-cli does not parse command line if command line contains `\\"`.
When a command is `/system-property=foo4:add(value="vvv\\")`, it shows the sub-prompt '> '

[standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> 




> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFLY-7321
>                 URL: https://issues.jboss.org/browse/WFLY-7321
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jason Greene
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 06:37:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 17 Oct 2016 06:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2113) TP: support multiple entries
	in bind_addr
In-Reply-To: <JIRA.12655230.1476700587000@Atlassian.JIRA>
References: <JIRA.12655230.1476700587000@Atlassian.JIRA>
	<JIRA.12655230.1476700587182@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655230.1476700587000.2856.1476700620267@Atlassian.JIRA>

Bela Ban created JGRP-2113:
------------------------------

             Summary: TP: support multiple entries in bind_addr
                 Key: JGRP-2113
                 URL: https://issues.jboss.org/browse/JGRP-2113
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0


Add support for multiple entries in {{bind_addr}}, e.g.

{code:xml}
  bind_addr="match-interface:eth2,10.5.5.5,match-interface:en*,127.0.0.1"
{code}

This would try to bind to {{eth2}} first. If not found, then an interface with address {{10.5.5.5}} would be tried, then an interface starting with {{en}} would be tried. If still not found, we'd bind to {{127.0.0.1}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 06:37:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Mon, 17 Oct 2016 06:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7321) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.2860.1476700620350@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307749#comment-13307749 ] 

Hisanobu Okuda commented on WFLY-7321:
--------------------------------------

In org.jboss.aesh.parser.Parser.doesStringContainOpenQuote(), if a back-slash is ahead of the second double quote, it wrongly returns true even if a back-slash is escaped with another back-slash.
{code}
521     public static boolean doesStringContainOpenQuote(String text) {
522         boolean doubleQuote = false;
523         boolean singleQuote = false;
524         for (int i = 0; i < text.length(); i++) {
525             if (text.charAt(i) == SINGLE_QUOTE) {
526                 if (!doubleQuote &&
527                         (i == 0 || (i > 0 && !(text.charAt(i - 1) == BACK_SLASH))))
528                     singleQuote = !singleQuote;
529             }
530             else if (text.charAt(i) == DOUBLE_QUOTE) {
531                 if (!singleQuote &&
532                         (i == 0 || (i > 0 && !(text.charAt(i - 1) == BACK_SLASH))))
533                     doubleQuote = !doubleQuote;
534             }
535         }
536         return doubleQuote || singleQuote;
537     }
{code}

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFLY-7321
>                 URL: https://issues.jboss.org/browse/WFLY-7321
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jason Greene
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 07:39:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 17 Oct 2016 07:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313370@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.3373.1476704340883@Atlassian.JIRA>

Ondrej Lukas created WFLY-7322:
----------------------------------

             Summary: LDAP referrals does not work in Elytron ldap-realm
                 Key: WFLY-7322
                 URL: https://issues.jboss.org/browse/WFLY-7322
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Blocker


LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:

* {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
* implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals

Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 07:39:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 17 Oct 2016 07:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.3382.1476704341147@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-7322:
-------------------------------
    Affects Version/s: 11.0.0.Alpha1


> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 08:08:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 08:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Internal server error is
 returned for Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.3691.1476706080912@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307808#comment-13307808 ] 

Jan Kalina commented on WFLY-7295:
----------------------------------

Probably need to be discussed yet, however I dont think the 401 can be useful for "useful for eventual fallback to another type of authentication."

> Internal server error is returned for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 08:09:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 08:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Internal server error is
 returned for Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.3706.1476706140714@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307808#comment-13307808 ] 

Jan Kalina edited comment on WFLY-7295 at 10/17/16 8:08 AM:
------------------------------------------------------------

Probably need to be discussed yet, however I dont think the 401 can be useful for "eventual fallback to another type of authentication."


was (Author: honza889):
Probably need to be discussed yet, however I dont think the 401 can be useful for "useful for eventual fallback to another type of authentication."

> Internal server error is returned for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 08:17:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 08:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.3760.1476706620775@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307815#comment-13307815 ] 

Jan Kalina commented on WFLY-7322:
----------------------------------

What exactly should do the "logic which handles referrals"? When the referral-mode is *follow* and the filter-name is (|(objectClass=refferal)(uid={0})), I am able to log in as user of referred server. (After appliing ELY-663 and WFLY-7320 patches)

> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 08:18:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 08:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.3767.1476706680594@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307815#comment-13307815 ] 

Jan Kalina edited comment on WFLY-7322 at 10/17/16 8:17 AM:
------------------------------------------------------------

What exactly should do the "logic which handles referrals"? When the referral-mode is *follow* and the filter-name is 
{code:java}
(|(objectClass=refferal)(uid={0}))
{code}
, I am able to log in as user of referred server. (After appliing ELY-663 and WFLY-7320 patches)


was (Author: honza889):
What exactly should do the "logic which handles referrals"? When the referral-mode is *follow* and the filter-name is (|(objectClass=refferal)(uid={0})), I am able to log in as user of referred server. (After appliing ELY-663 and WFLY-7320 patches)

> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 08:18:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 08:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.3774.1476706680817@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307815#comment-13307815 ] 

Jan Kalina edited comment on WFLY-7322 at 10/17/16 8:17 AM:
------------------------------------------------------------

What exactly should do the "logic which handles referrals"? When the referral-mode is *follow* and the filter-name is 
{code:java}
(|(objectClass=referral)(uid={0}))
{code}
, I am able to log in as user of referred server. (After appliing ELY-663 and WFLY-7320 patches)


was (Author: honza889):
What exactly should do the "logic which handles referrals"? When the referral-mode is *follow* and the filter-name is 
{code:java}
(|(objectClass=refferal)(uid={0}))
{code}
, I am able to log in as user of referred server. (After appliing ELY-663 and WFLY-7320 patches)

> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 08:18:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 08:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-663) LDAP referrals does not work -
 dir-context.referral-mode is always ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.3778.1476706680961@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307233#comment-13307233 ] 

Jan Kalina edited comment on ELY-663 at 10/17/16 8:17 AM:
----------------------------------------------------------

By discussion, maybe there will be need to add "filter" attribute to the ldap-realm, similar like in ldap-key-store already is to work with referrals:


{code:java}
(|(objectclass=refferal)(uid={0}))
{code}


(will have to check yet if it helps, but by Ond?ej it is solved in Picketbox by this way)


was (Author: honza889):
By discussion, maybe there will be need to add "filter" attribute to the ldap-realm, similar like in ldap-key-store already is to work with referrals:


{code:java}
(|(objectClass=refferal)(uid={0}))
{code}


(will have to check yet if it helps, but by Ond?ej it is solved in Picketbox by this way)

> LDAP referrals does not work - dir-context.referral-mode is always ignored
> --------------------------------------------------------------------------
>
>                 Key: ELY-663
>                 URL: https://issues.jboss.org/browse/ELY-663
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 17 08:19:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 08:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-663) LDAP referrals does not work -
 dir-context.referral-mode is always ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.3780.1476706740328@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307233#comment-13307233 ] 

Jan Kalina edited comment on ELY-663 at 10/17/16 8:18 AM:
----------------------------------------------------------

By discussion, maybe there will be need to add "filter" attribute to the ldap-realm, similar like in ldap-key-store already is to work with referrals:

{code:java}
(|(objectclass=referral)(uid={0}))
{code}

(will have to check yet if it helps, but by Ond?ej it is solved in Picketbox by this way)


was (Author: honza889):
By discussion, maybe there will be need to add "filter" attribute to the ldap-realm, similar like in ldap-key-store already is to work with referrals:


{code:java}
(|(objectclass=refferal)(uid={0}))
{code}


(will have to check yet if it helps, but by Ond?ej it is solved in Picketbox by this way)

> LDAP referrals does not work - dir-context.referral-mode is always ignored
> --------------------------------------------------------------------------
>
>                 Key: ELY-663
>                 URL: https://issues.jboss.org/browse/ELY-663
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 17 08:19:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 08:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.3787.1476706740478@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307815#comment-13307815 ] 

Jan Kalina edited comment on WFLY-7322 at 10/17/16 8:18 AM:
------------------------------------------------------------

What exactly should do the "logic which handles referrals"? When the referral-mode is *follow* and the filter-name is 
{code:java}
(|(objectclass=referral)(uid={0}))
{code}
, I am able to log in as user of referred server. (After appliing ELY-663 and WFLY-7320 patches)


was (Author: honza889):
What exactly should do the "logic which handles referrals"? When the referral-mode is *follow* and the filter-name is 
{code:java}
(|(objectClass=referral)(uid={0}))
{code}
, I am able to log in as user of referred server. (After appliing ELY-663 and WFLY-7320 patches)

> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 08:38:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 08:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7305) Getting identity by DN in
 Elytron ldap-realm should be case insensitive
In-Reply-To: <JIRA.12654645.1476357070000@Atlassian.JIRA>
References: <JIRA.12654645.1476357070000@Atlassian.JIRA>
	<JIRA.12654645.1476357070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654645.1476357070000.3866.1476707880260@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307822#comment-13307822 ] 

Jan Kalina commented on WFLY-7305:
----------------------------------

1) When I am now looking on it, maybe we could also skip nameFilter when user entry is defined by DN...
2) I now see bigger problem: the check compare test only if the RDN is at begin of DN - but without "=" - for example username "uidahaar" will be interpreted as DN, because it starts by "uid".


> Getting identity by DN in Elytron ldap-realm should be case insensitive
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7305
>                 URL: https://issues.jboss.org/browse/WFLY-7305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. 
> LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 08:44:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 17 Oct 2016 08:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-168) Release new version of
 jboss-annotations-api_1.2_spec
In-Reply-To: <JIRA.12653172.1475588990000@Atlassian.JIRA>
References: <JIRA.12653172.1475588990000@Atlassian.JIRA>
	<JIRA.12653172.1475588990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653172.1475588990000.3927.1476708240267@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307826#comment-13307826 ] 

David Lloyd commented on JBEE-168:
----------------------------------

I don't know if we can update this to a newer spec version and still be compliant with Java EE 7.

> Release new version of jboss-annotations-api_1.2_spec
> -----------------------------------------------------
>
>                 Key: JBEE-168
>                 URL: https://issues.jboss.org/browse/JBEE-168
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Task
>          Components: jboss-annotations-api
>            Reporter: Tomas Remes
>            Assignee: Scott Marlow
>
> There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annotation-api%7C1.3%7Cjar recently
> change log
> {noformat}
> Added @Target(PARAMETER) to the Priority annotation.
> Made Resource and DataSourceDefinition annotations repeatable.
> Clarified rules for use of PostConstruct and PreDestroy annotations to correct inconsistencies with other Java EE specifications.
> Replaced example in section 2.1 referencing WebService/WebMethod, which was inconsistent with the JAX-WS and Web Services Metadata specifications. 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 08:59:00 2016
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Mon, 17 Oct 2016 08:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Stateful working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.4052.1476709140149@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307844#comment-13307844 ] 

Jiri Locker commented on DROOLS-1326:
-------------------------------------

[~ge0ffrey] reproduced, thanks for the hints!

> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-1326
>                 URL: https://issues.jboss.org/browse/DROOLS-1326
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/
> I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 09:04:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 17 Oct 2016 09:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7313) Impossible to use environment
 variables or system properties in permissions.xml
In-Reply-To: <JIRA.12654778.1476386430000@Atlassian.JIRA>
References: <JIRA.12654778.1476386430000@Atlassian.JIRA>
	<JIRA.12654778.1476386430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654778.1476386430000.4130.1476709440929@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-7313:
------------------------------
    Description: 
Without this feature it is impossible to migrate "variable" Java file permissions such as:

{noformat}
permission java.io.FilePermission "${java.io.tmpdir}","read";
permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
{noformat}

that were defined in Java policy file in previous verions of JBoss.

  was:
Without this feature it is impossible to migrate "variable" Java file permissions such as:

permission java.io.FilePermission "${java.io.tmpdir}","read";
permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";

that were defined in Java policy file in previous verions of JBoss.



> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-7313
>                 URL: https://issues.jboss.org/browse/WFLY-7313
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 10.1.0.Final
>            Reporter: Adrian Boangiu
>            Assignee: Jason Greene
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> {noformat}
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> {noformat}
> that were defined in Java policy file in previous verions of JBoss.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 09:04:01 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 17 Oct 2016 09:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Stateful working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.4134.1476709441034@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307853#comment-13307853 ] 

Geoffrey De Smet commented on DROOLS-1326:
------------------------------------------

Great :) Talk about tracking down the needle in the haystack!

> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-1326
>                 URL: https://issues.jboss.org/browse/DROOLS-1326
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/
> I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 09:05:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 17 Oct 2016 09:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7313) Impossible to use environment
 variables or system properties in permissions.xml
In-Reply-To: <JIRA.12654778.1476386430000@Atlassian.JIRA>
References: <JIRA.12654778.1476386430000@Atlassian.JIRA>
	<JIRA.12654778.1476386430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654778.1476386430000.4141.1476709500325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-7313:
------------------------------
    Component/s: Security Manager
                     (was: EE)


> Impossible to use environment variables or system properties in permissions.xml
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-7313
>                 URL: https://issues.jboss.org/browse/WFLY-7313
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security Manager
>    Affects Versions: 10.1.0.Final
>            Reporter: Adrian Boangiu
>            Assignee: Jason Greene
>
> Without this feature it is impossible to migrate "variable" Java file permissions such as:
> {noformat}
> permission java.io.FilePermission "${java.io.tmpdir}","read";
> permission java.io.FilePermission "${jboss.home.dir}${/}bin${/}javamelody${/}-","read,write,delete";
> permission java.io.FilePermission "${app.home.dir}${/}log${/}-","read,write,delete";
> {noformat}
> that were defined in Java policy file in previous verions of JBoss.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 09:11:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 17 Oct 2016 09:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.4185.1476709860890@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307858#comment-13307858 ] 

Ondrej Lukas commented on WFLY-7322:
------------------------------------

In case when Elytron is able to work with referral based on added filter-name then no additional logic for *follow* will be needed in the code.

However some logic which handles *throw* should be added as well. I am not sure, but from quick code review I think it results to throwing Exception to Undertow, which will result to Internal Server Error.

> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 09:14:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 17 Oct 2016 09:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7305) Getting identity by DN in
 Elytron ldap-realm should be case insensitive
In-Reply-To: <JIRA.12654645.1476357070000@Atlassian.JIRA>
References: <JIRA.12654645.1476357070000@Atlassian.JIRA>
	<JIRA.12654645.1476357070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654645.1476357070000.4226.1476710040781@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307860#comment-13307860 ] 

Ondrej Lukas commented on WFLY-7305:
------------------------------------

About second point. This has been already reported in WFLY-7302.

> Getting identity by DN in Elytron ldap-realm should be case insensitive
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7305
>                 URL: https://issues.jboss.org/browse/WFLY-7305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. 
> LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 09:14:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 17 Oct 2016 09:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7305) Getting identity by DN in
 Elytron ldap-realm should be case insensitive
In-Reply-To: <JIRA.12654645.1476357070000@Atlassian.JIRA>
References: <JIRA.12654645.1476357070000@Atlassian.JIRA>
	<JIRA.12654645.1476357070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654645.1476357070000.4235.1476710041085@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307860#comment-13307860 ] 

Ondrej Lukas edited comment on WFLY-7305 at 10/17/16 9:13 AM:
--------------------------------------------------------------

About second point. It has been already reported in WFLY-7302.


was (Author: olukas):
About second point. This has been already reported in WFLY-7302.

> Getting identity by DN in Elytron ldap-realm should be case insensitive
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7305
>                 URL: https://issues.jboss.org/browse/WFLY-7305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. 
> LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 09:15:02 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 17 Oct 2016 09:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7282) Deadlock in BasicAction when
 jboss remoting and JTA is used
In-Reply-To: <JIRA.12654056.1476165225000@Atlassian.JIRA>
References: <JIRA.12654056.1476165225000@Atlassian.JIRA>
	<JIRA.12654056.1476165225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654056.1476165225000.4254.1476710102103@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-7282:
-----------------------------
    Fix Version/s:     (was: 10.2.0.Final)


> Deadlock in BasicAction when jboss remoting and JTA is used
> -----------------------------------------------------------
>
>                 Key: WFLY-7282
>                 URL: https://issues.jboss.org/browse/WFLY-7282
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 11.0.0.Alpha1
>
>
> At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem and a deadlock.
> Issue created based on discussion at jboss-support-transactions list: http://post-office.corp.redhat.com/archives/jboss-support-transactions/2016-September/msg00000.html
> Current jboss remoting implementation on JTA does not provide correct handling of double diamond transaction propagation problem.
> If transaction is propagated from one server to other one and then back to the first one then such situation can cause deadlock. Remote calls and transactions are processed but when servers using the same remote resource the prepare phase of 2PC can stuck. Transaction is timed-out later and recovery process rolls it back.
> IIOP/JTS does not suffer with this flaw.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 09:27:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 09:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.4459.1476710820841@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7322:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 09:48:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 09:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1859) Investigate and fix JDK9
 modular params propagation to forked processes
In-Reply-To: <JIRA.12653846.1475856902000@Atlassian.JIRA>
References: <JIRA.12653846.1475856902000@Atlassian.JIRA>
	<JIRA.12653846.1475856902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653846.1475856902000.4728.1476712083336@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307898#comment-13307898 ] 

Brian Stansberry commented on WFCORE-1859:
------------------------------------------

Note that the ProcessController and the HostController are meant to run from the same JRE. It's possible there is some fine detail involved that needs to be sorted, but the basic assumption is they are on the same JRE. I don't believe we ever intentionally provided a way to change that, although perhaps some hacker of domain.conf could figure out something.

The servers are a completely different story. There we have explicit configuration of the server jvm with an absolute expectation that it could be different from the PC/HC.

The DomainController is just a HostController configured to have some special responsibilities. In this area, those responsibilities are no different from any other HC. The DC does not impact the JRE used by other HCs.

> Investigate and fix JDK9 modular params propagation to forked processes
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-1859
>                 URL: https://issues.jboss.org/browse/WFCORE-1859
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Server, Test Suite
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>            Priority: Blocker
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 10:15:02 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 10:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7304) Compensations subsystem
In-Reply-To: <JIRA.12654630.1476351823000@Atlassian.JIRA>
References: <JIRA.12654630.1476351823000@Atlassian.JIRA>
	<JIRA.12654630.1476351823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654630.1476351823000.5076.1476713702806@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307920#comment-13307920 ] 

Brian Stansberry commented on WFLY-7304:
----------------------------------------

Is this functionality exposed via the management API in any .Final or .GA release of WildFly or EAP? If so we'd need to deal with compatibility. If not, great!

> Compensations subsystem
> -----------------------
>
>                 Key: WFLY-7304
>                 URL: https://issues.jboss.org/browse/WFLY-7304
>             Project: WildFly
>          Issue Type: Task
>          Components: Transactions
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 10:50:01 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 10:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7319) Processing of variables
 doesn't work in servlet mapping
In-Reply-To: <JIRA.12654998.1476466920000@Atlassian.JIRA>
References: <JIRA.12654998.1476466920000@Atlassian.JIRA>
	<JIRA.12654998.1476466920000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654998.1476466920000.5470.1476715801098@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-7319:
--------------------------------------

    Component/s: Web (Undertow)
       Assignee: Stuart Douglas  (was: Jason Greene)


> Processing of variables doesn't work in servlet mapping
> -------------------------------------------------------
>
>                 Key: WFLY-7319
>                 URL: https://issues.jboss.org/browse/WFLY-7319
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: John Ament
>            Assignee: Stuart Douglas
>
> I have the following servlet mapping:
> {code}
>     <servlet>
>         <servlet-name>TogglzConsoleServlet</servlet-name>
>         <servlet-class>org.togglz.console.TogglzConsoleServlet</servlet-class>
>     </servlet>
>     <servlet-mapping>
>         <servlet-name>TogglzConsoleServlet</servlet-name>
>         <url-pattern>${togglz.uri}</url-pattern>
>     </servlet-mapping>
> {code}
> Regardless of system property, the value is not processed.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 11:10:01 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 11:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.5530.1476717001358@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-7321 to WFCORE-1868:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-1868  (was: WFLY-7321)
    Component/s: CLI
                     (was: CLI)


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jason Greene
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 11:10:01 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 11:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.5536.1476717001492@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1868:
----------------------------------------

    Assignee:     (was: Jason Greene)


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 11:11:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 11:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.5542.1476717060418@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1868:
----------------------------------------

    Assignee: Jean-Francois Denise


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 11:16:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 17 Oct 2016 11:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1869) When unregistering a
 ressource in the MMR,
 if the address targets an alias then we should just 'ignore' the
 unregistering of hte submodel
In-Reply-To: <JIRA.12655333.1476717336000@Atlassian.JIRA>
References: <JIRA.12655333.1476717336000@Atlassian.JIRA>
	<JIRA.12655333.1476717336244@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655333.1476717336000.5563.1476717360071@Atlassian.JIRA>

ehsavoie Hugonnet created WFCORE-1869:
-----------------------------------------

             Summary: When unregistering a ressource in the MMR, if the address targets an alias then we should just 'ignore' the unregistering of hte submodel
                 Key: WFCORE-1869
                 URL: https://issues.jboss.org/browse/WFCORE-1869
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 3.0.0.Alpha9
            Reporter: ehsavoie Hugonnet
            Assignee: ehsavoie Hugonnet


When unregistering the submodel of a resource, if it targets an alias with children the operation will fail like this:
java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE': java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE'
????????at org.jboss.as.controller.registry.AliasResourceRegistration.alreadyRegistered(AliasResourceRegistration.java:291)
????????at org.jboss.as.controller.registry.AliasResourceRegistration.unregisterSubModel(AliasResourceRegistration.java:123)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.extension.ExtensionRegistry.removeExtension(ExtensionRegistry.java:341)

We should ignore the removal of the children of an alias ressource



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 17 11:21:01 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 11:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1869) When unregistering a
 ressource in the MMR,
 if the address targets an alias then we should just 'ignore' the
 unregistering of hte submodel
In-Reply-To: <JIRA.12655333.1476717336000@Atlassian.JIRA>
References: <JIRA.12655333.1476717336000@Atlassian.JIRA>
	<JIRA.12655333.1476717336000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655333.1476717336000.5593.1476717661097@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1869:
-------------------------------------
    Description: 
When unregistering the submodel of a resource, if it targets an alias with children the operation will fail like this:
java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE': java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE'
????????at org.jboss.as.controller.registry.AliasResourceRegistration.alreadyRegistered(AliasResourceRegistration.java:291)
????????at org.jboss.as.controller.registry.AliasResourceRegistration.unregisterSubModel(AliasResourceRegistration.java:123)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.extension.ExtensionRegistry.removeExtension(ExtensionRegistry.java:341)

We should ignore the removal of the children of an alias resource registration.

  was:
When unregistering the submodel of a resource, if it targets an alias with children the operation will fail like this:
java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE': java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE'
????????at org.jboss.as.controller.registry.AliasResourceRegistration.alreadyRegistered(AliasResourceRegistration.java:291)
????????at org.jboss.as.controller.registry.AliasResourceRegistration.unregisterSubModel(AliasResourceRegistration.java:123)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
????????at org.jboss.as.controller.extension.ExtensionRegistry.removeExtension(ExtensionRegistry.java:341)

We should ignore the removal of the children of an alias ressource



> When unregistering a ressource in the MMR, if the address targets an alias then we should just 'ignore' the unregistering of hte submodel
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1869
>                 URL: https://issues.jboss.org/browse/WFCORE-1869
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> When unregistering the submodel of a resource, if it targets an alias with children the operation will fail like this:
> java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE': java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE'
> ????????at org.jboss.as.controller.registry.AliasResourceRegistration.alreadyRegistered(AliasResourceRegistration.java:291)
> ????????at org.jboss.as.controller.registry.AliasResourceRegistration.unregisterSubModel(AliasResourceRegistration.java:123)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.extension.ExtensionRegistry.removeExtension(ExtensionRegistry.java:341)
> We should ignore the removal of the children of an alias resource registration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 17 11:31:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 17 Oct 2016 11:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1869) When unregistering a
 resource in the MMR,
 if the address targets an alias then we should just 'ignore' the
 unregistering of hte submodel
In-Reply-To: <JIRA.12655333.1476717336000@Atlassian.JIRA>
References: <JIRA.12655333.1476717336000@Atlassian.JIRA>
	<JIRA.12655333.1476717336000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655333.1476717336000.5666.1476718260604@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFCORE-1869:
--------------------------------------
    Summary: When unregistering a resource in the MMR, if the address targets an alias then we should just 'ignore' the unregistering of hte submodel  (was: When unregistering a ressource in the MMR, if the address targets an alias then we should just 'ignore' the unregistering of hte submodel)


> When unregistering a resource in the MMR, if the address targets an alias then we should just 'ignore' the unregistering of hte submodel
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1869
>                 URL: https://issues.jboss.org/browse/WFCORE-1869
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> When unregistering the submodel of a resource, if it targets an alias with children the operation will fail like this:
> java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE': java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE'
> ????????at org.jboss.as.controller.registry.AliasResourceRegistration.alreadyRegistered(AliasResourceRegistration.java:291)
> ????????at org.jboss.as.controller.registry.AliasResourceRegistration.unregisterSubModel(AliasResourceRegistration.java:123)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.extension.ExtensionRegistry.removeExtension(ExtensionRegistry.java:341)
> We should ignore the removal of the children of an alias resource registration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 17 11:31:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 17 Oct 2016 11:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7323) Add EAP 7.0.0 transformers
 tests for jgroups subsystem
In-Reply-To: <JIRA.12655338.1476718223000@Atlassian.JIRA>
References: <JIRA.12655338.1476718223000@Atlassian.JIRA>
	<JIRA.12655338.1476718223901@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655338.1476718223000.5668.1476718260652@Atlassian.JIRA>

Radoslav Husar created WFLY-7323:
------------------------------------

             Summary: Add EAP 7.0.0 transformers tests for jgroups subsystem
                 Key: WFLY-7323
                 URL: https://issues.jboss.org/browse/WFLY-7323
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 11:31:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 17 Oct 2016 11:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7323) Add EAP 7.0.0 transformers
 tests for jgroups subsystem
In-Reply-To: <JIRA.12655338.1476718224000@Atlassian.JIRA>
References: <JIRA.12655338.1476718224000@Atlassian.JIRA>
	<JIRA.12655338.1476718224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655338.1476718224000.5672.1476718260783@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7323:
---------------------------------
    Description: 
Needs to be added before any elytron integration work.



> Add EAP 7.0.0 transformers tests for jgroups subsystem
> ------------------------------------------------------
>
>                 Key: WFLY-7323
>                 URL: https://issues.jboss.org/browse/WFLY-7323
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Needs to be added before any elytron integration work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 11:31:00 2016
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 17 Oct 2016 11:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1869) When unregistering a
 resource in the MMR,
 if the address targets an alias then we should just 'ignore' the
 unregistering of the submodel
In-Reply-To: <JIRA.12655333.1476717336000@Atlassian.JIRA>
References: <JIRA.12655333.1476717336000@Atlassian.JIRA>
	<JIRA.12655333.1476717336000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655333.1476717336000.5674.1476718260912@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet updated WFCORE-1869:
--------------------------------------
    Summary: When unregistering a resource in the MMR, if the address targets an alias then we should just 'ignore' the unregistering of the submodel  (was: When unregistering a resource in the MMR, if the address targets an alias then we should just 'ignore' the unregistering of hte submodel)


> When unregistering a resource in the MMR, if the address targets an alias then we should just 'ignore' the unregistering of the submodel
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1869
>                 URL: https://issues.jboss.org/browse/WFCORE-1869
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha9
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> When unregistering the submodel of a resource, if it targets an alias with children the operation will fail like this:
> java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE': java.lang.IllegalArgumentException: WFLYCTL0277: An alias is already registered at location '/subsystem=infinispan/cache-container=*/distributed-cache=*/file-store=FILE_STORE'
> ????????at org.jboss.as.controller.registry.AliasResourceRegistration.alreadyRegistered(AliasResourceRegistration.java:291)
> ????????at org.jboss.as.controller.registry.AliasResourceRegistration.unregisterSubModel(AliasResourceRegistration.java:123)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:261)
> ????????at org.jboss.as.controller.extension.ExtensionRegistry.removeExtension(ExtensionRegistry.java:341)
> We should ignore the removal of the children of an alias resource registration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 17 11:37:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 17 Oct 2016 11:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7323) Add EAP 7.0.0 transformers
 tests for jgroups subsystem
In-Reply-To: <JIRA.12655338.1476718224000@Atlassian.JIRA>
References: <JIRA.12655338.1476718224000@Atlassian.JIRA>
	<JIRA.12655338.1476718224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655338.1476718224000.5710.1476718620453@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7323:
---------------------------------
    Issue Type: Task  (was: Bug)


> Add EAP 7.0.0 transformers tests for jgroups subsystem
> ------------------------------------------------------
>
>                 Key: WFLY-7323
>                 URL: https://issues.jboss.org/browse/WFLY-7323
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Needs to be added before any elytron integration work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 11:38:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 17 Oct 2016 11:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7324) Add EAP 7.0.0 transformers
 tests for infinispan subsystem
In-Reply-To: <JIRA.12655339.1476718661000@Atlassian.JIRA>
References: <JIRA.12655339.1476718661000@Atlassian.JIRA>
	<JIRA.12655339.1476718661079@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655339.1476718661000.5719.1476718680333@Atlassian.JIRA>

Radoslav Husar created WFLY-7324:
------------------------------------

             Summary: Add EAP 7.0.0 transformers tests for infinispan subsystem
                 Key: WFLY-7324
                 URL: https://issues.jboss.org/browse/WFLY-7324
             Project: WildFly
          Issue Type: Task
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


Needs to be added before any elytron integration work.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 11:38:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 17 Oct 2016 11:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7318) Add EAP 7.0.0 transformers
 tests for mod_cluster subsystem
In-Reply-To: <JIRA.12654989.1476459786000@Atlassian.JIRA>
References: <JIRA.12654989.1476459786000@Atlassian.JIRA>
	<JIRA.12654989.1476459786000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654989.1476459786000.5725.1476718680535@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7318:
---------------------------------
    Affects Version/s:     (was: 10.0.0.Final)


> Add EAP 7.0.0 transformers tests for mod_cluster subsystem
> ----------------------------------------------------------
>
>                 Key: WFLY-7318
>                 URL: https://issues.jboss.org/browse/WFLY-7318
>             Project: WildFly
>          Issue Type: Task
>          Components: mod_cluster
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Needs to be added before any elytron integration work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 11:51:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 11:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.5817.1476719460412@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307990#comment-13307990 ] 

Jan Kalina commented on WFLY-7322:
----------------------------------

Problem in FOLLOW mode: NamingEnumeration.hasMore create new LdapReferralContext and socket, which is not covered by DelegatingDirContext yet.
{code:text}
java.lang.RuntimeException: ELY01084: Error while consuming results from search. SearchDn [dc=users,dc=elytron,dc=wildfly,dc=org], Filter [(|(objectclass=referral)(uid={0}))], Filter Args [[refUser]].
Caused by: javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]]
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:237)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:938)
	... 39 more
Caused by: javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]
	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:95)
	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(AbstractLdapNamingEnumeration.java:325)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:227)
	... 41 more
Caused by: java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting
	at org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory.getDefault(ThreadLocalSSLSocketFactory.java:46)
	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:284)
	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1614)
	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:151)
	at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(ldapURLContextFactory.java:52)
	at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
	at javax.naming.spi.NamingManager.processURL(NamingManager.java:381)
	at javax.naming.spi.NamingManager.processURLAddrs(NamingManager.java:361)
	at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:333)
	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:114)
	... 44 more
{code}


> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 12:35:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 12:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-669) LDAP referrals following -
 SSLSocketFactory not set
In-Reply-To: <JIRA.12655351.1476722046000@Atlassian.JIRA>
References: <JIRA.12655351.1476722046000@Atlassian.JIRA>
	<JIRA.12655351.1476722046927@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655351.1476722046000.6005.1476722100129@Atlassian.JIRA>

Jan Kalina created ELY-669:
------------------------------

             Summary: LDAP referrals following - SSLSocketFactory not set
                 Key: ELY-669
                 URL: https://issues.jboss.org/browse/ELY-669
             Project: WildFly Elytron
          Issue Type: Bug
          Components: SSL
            Reporter: Jan Kalina
            Assignee: Jan Kalina


When the referral-mode="follow" is used, NamingEnumeration.hasMore create new LdapReferralContext and socket, which is not covered by DelegatingDirContext yet.

{code:text}
java.lang.RuntimeException: ELY01084: Error while consuming results from search. SearchDn [dc=users,dc=elytron,dc=wildfly,dc=org], Filter [(|(objectclass=referral)(uid={0}))], Filter Args [[refUser]].
Caused by: javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]]
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:237)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:938)
	... 39 more
Caused by: javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]
	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:95)
	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(AbstractLdapNamingEnumeration.java:325)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:227)
	... 41 more
Caused by: java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting
	at org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory.getDefault(ThreadLocalSSLSocketFactory.java:46)
	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:284)
	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1614)
	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:151)
	at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(ldapURLContextFactory.java:52)
	at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
	at javax.naming.spi.NamingManager.processURL(NamingManager.java:381)
	at javax.naming.spi.NamingManager.processURLAddrs(NamingManager.java:361)
	at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:333)
	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:114)
	... 44 more
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 13:03:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 13:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-670) LDAP referrals following -
 SSLSocketFactory not set
In-Reply-To: <JIRA.12655356.1476723768000@Atlassian.JIRA>
References: <JIRA.12655356.1476723768000@Atlassian.JIRA>
	<JIRA.12655356.1476723768501@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655356.1476723768000.6082.1476723780074@Atlassian.JIRA>

Jan Kalina created ELY-670:
------------------------------

             Summary: LDAP referrals following - SSLSocketFactory not set
                 Key: ELY-670
                 URL: https://issues.jboss.org/browse/ELY-670
             Project: WildFly Elytron
          Issue Type: Bug
          Components: SSL
            Reporter: Jan Kalina
            Assignee: Jan Kalina


When the referral-mode="follow" is used, NamingEnumeration.hasMore create new LdapReferralContext and socket, which is not covered by DelegatingDirContext yet.

{code:text}
java.lang.RuntimeException: ELY01084: Error while consuming results from search. SearchDn [dc=users,dc=elytron,dc=wildfly,dc=org], Filter [(|(objectclass=referral)(uid={0}))], Filter Args [[refUser]].
Caused by: javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]]
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:237)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:938)
	... 39 more
Caused by: javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]
	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:95)
	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(AbstractLdapNamingEnumeration.java:325)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:227)
	... 41 more
Caused by: java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting
	at org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory.getDefault(ThreadLocalSSLSocketFactory.java:46)
	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:284)
	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1614)
	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:151)
	at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(ldapURLContextFactory.java:52)
	at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
	at javax.naming.spi.NamingManager.processURL(NamingManager.java:381)
	at javax.naming.spi.NamingManager.processURLAddrs(NamingManager.java:361)
	at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:333)
	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:114)
	... 44 more
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 13:04:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 13:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7325) LDAP referrals following -
 SSLSocketFactory not set
In-Reply-To: <JIRA.12655356.1476723769000@Atlassian.JIRA>
References: <JIRA.12655356.1476723769000@Atlassian.JIRA>
	<JIRA.12655356.1476723769000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655356.1476723769000.6093.1476723840263@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved ELY-670 to WFLY-7325:
--------------------------------------

        Project: WildFly  (was: WildFly Elytron)
            Key: WFLY-7325  (was: ELY-670)
    Component/s: Security
                     (was: SSL)


> LDAP referrals following - SSLSocketFactory not set
> ---------------------------------------------------
>
>                 Key: WFLY-7325
>                 URL: https://issues.jboss.org/browse/WFLY-7325
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> When the referral-mode="follow" is used, NamingEnumeration.hasMore create new LdapReferralContext and socket, which is not covered by DelegatingDirContext yet.
> {code:text}
> java.lang.RuntimeException: ELY01084: Error while consuming results from search. SearchDn [dc=users,dc=elytron,dc=wildfly,dc=org], Filter [(|(objectclass=referral)(uid={0}))], Filter Args [[refUser]].
> Caused by: javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]]
> 	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:237)
> 	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:938)
> 	... 39 more
> Caused by: javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]
> 	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:95)
> 	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
> 	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(AbstractLdapNamingEnumeration.java:325)
> 	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:227)
> 	... 41 more
> Caused by: java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting
> 	at org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory.getDefault(ThreadLocalSSLSocketFactory.java:46)
> 	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:284)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1614)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:151)
> 	at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(ldapURLContextFactory.java:52)
> 	at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
> 	at javax.naming.spi.NamingManager.processURL(NamingManager.java:381)
> 	at javax.naming.spi.NamingManager.processURLAddrs(NamingManager.java:361)
> 	at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:333)
> 	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:114)
> 	... 44 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 13:09:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 17 Oct 2016 13:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.6103.1476724140369@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7322:
-----------------------------
    Comment: was deleted

(was: Problem in FOLLOW mode: NamingEnumeration.hasMore create new LdapReferralContext and socket, which is not covered by DelegatingDirContext yet.
{code:text}
java.lang.RuntimeException: ELY01084: Error while consuming results from search. SearchDn [dc=users,dc=elytron,dc=wildfly,dc=org], Filter [(|(objectclass=referral)(uid={0}))], Filter Args [[refUser]].
Caused by: javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]]
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:237)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189)
	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch$1.tryAdvance(LdapSecurityRealm.java:938)
	... 39 more
Caused by: javax.naming.CommunicationException: localhost:11391 [Root exception is java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting]
	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:95)
	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(AbstractLdapNamingEnumeration.java:325)
	at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:227)
	... 41 more
Caused by: java.lang.IllegalStateException: ELY04025: DirContext tries to connect without SSLSocketFactory thread local setting
	at org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory.getDefault(ThreadLocalSSLSocketFactory.java:46)
	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:284)
	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1614)
	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:151)
	at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(ldapURLContextFactory.java:52)
	at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
	at javax.naming.spi.NamingManager.processURL(NamingManager.java:381)
	at javax.naming.spi.NamingManager.processURLAddrs(NamingManager.java:361)
	at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:333)
	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:114)
	... 44 more
{code}
)


> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 16:09:00 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 17 Oct 2016 16:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7326) :add operations implemented
 using AbstractBoottimeAddStepHandler should report that reload is required
 in the read-operation-description output
In-Reply-To: <JIRA.12655372.1476734907000@Atlassian.JIRA>
References: <JIRA.12655372.1476734907000@Atlassian.JIRA>
	<JIRA.12655372.1476734907081@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655372.1476734907000.6523.1476734940655@Atlassian.JIRA>

Kabir Khan created WFLY-7326:
--------------------------------

             Summary: :add operations implemented using AbstractBoottimeAddStepHandler should report that reload is required in the read-operation-description output
                 Key: WFLY-7326
                 URL: https://issues.jboss.org/browse/WFLY-7326
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Brian Stansberry
             Fix For: 11.0.0.Alpha1


As discussed on https://github.com/wildfly/wildfly/pull/9264



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 17:03:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 17:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1870) :add operations implemented
 using AbstractBoottimeAddStepHandler should report that reload is required
 in the read-operation-description output
In-Reply-To: <JIRA.12655372.1476734907000@Atlassian.JIRA>
References: <JIRA.12655372.1476734907000@Atlassian.JIRA>
	<JIRA.12655372.1476734907000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655372.1476734907000.6741.1476738180435@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-7326 to WFCORE-1870:
------------------------------------------------

          Project: WildFly Core  (was: WildFly)
              Key: WFCORE-1870  (was: WFLY-7326)
      Component/s: Domain Management
                       (was: Domain Management)
    Fix Version/s:     (was: 11.0.0.Alpha1)


> :add operations implemented using AbstractBoottimeAddStepHandler should report that reload is required in the read-operation-description output
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1870
>                 URL: https://issues.jboss.org/browse/WFCORE-1870
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>
> As discussed on https://github.com/wildfly/wildfly/pull/9264



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 17:05:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 17:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1870) :add operations implemented
 using AbstractBoottimeAddStepHandler should report that reload is required
 in the read-operation-description output
In-Reply-To: <JIRA.12655372.1476734907000@Atlassian.JIRA>
References: <JIRA.12655372.1476734907000@Atlassian.JIRA>
	<JIRA.12655372.1476734907000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655372.1476734907000.6747.1476738300154@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1870:
-------------------------------------
    Description: 
As discussed on https://github.com/wildfly/wildfly/pull/9264

CRITICAL POINT: Solving this generically can have the effect of changing the management API of many, many subsystems. It doesn't actually change their behavior though.

  was:As discussed on https://github.com/wildfly/wildfly/pull/9264



> :add operations implemented using AbstractBoottimeAddStepHandler should report that reload is required in the read-operation-description output
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1870
>                 URL: https://issues.jboss.org/browse/WFCORE-1870
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>
> As discussed on https://github.com/wildfly/wildfly/pull/9264
> CRITICAL POINT: Solving this generically can have the effect of changing the management API of many, many subsystems. It doesn't actually change their behavior though.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 17:24:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 17 Oct 2016 17:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1871) AbstractDeploymentChainStep
 should fail if executed post-boot
In-Reply-To: <JIRA.12655378.1476739394000@Atlassian.JIRA>
References: <JIRA.12655378.1476739394000@Atlassian.JIRA>
	<JIRA.12655378.1476739394193@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655378.1476739394000.6791.1476739440070@Atlassian.JIRA>

Brian Stansberry created WFCORE-1871:
----------------------------------------

             Summary: AbstractDeploymentChainStep should fail if executed post-boot
                 Key: WFCORE-1871
                 URL: https://issues.jboss.org/browse/WFCORE-1871
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


AbstractDeploymentChainStep is intended to be called from AbstractBoottimeAddStepHandler or a functional equivalent that only calls it during boot. But WFLY-7300 and https://github.com/wildfly/wildfly/pull/9264 show that usage pattern is not being followed. So we should enforce it and fail if called post-boot.

As a nice-to-have, instead of always failing the impl could check the OperationDefinition for the currently executing operation and if it reports that reload is required, then AbstractDeploymentChainStep can do the reload-required stuff currently done by AbstractBoottimeAddStepHandler. If the definition doesn't report reload-required, then the definition is wrong and the usage is wrong, so we should fail.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 18:28:00 2016
From: issues at jboss.org (Bartosz Andrzejewski (JIRA))
Date: Mon, 17 Oct 2016 18:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.6872.1476743280280@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308118#comment-13308118 ] 

Bartosz Andrzejewski commented on WFLY-5213:
--------------------------------------------

I'm trying to connect to remote Artemis standalone server and be able to use MDB's.
I thought it can be configured in massaging-activemq module - since it has dependency to org.apache.activemq.artemis, but apparently it can not.

Should I add *org.apache.activemq.artemis* extension to the configuration (since it is not listed in standalone-full configuration by deafult), and define remote-connector + pooled-connection-factory in this module (instead of defining it massaging-activemq module)? 


> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 17 20:26:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 17 Oct 2016 20:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7319) Processing of variables
 doesn't work in servlet mapping
In-Reply-To: <JIRA.12654998.1476466920000@Atlassian.JIRA>
References: <JIRA.12654998.1476466920000@Atlassian.JIRA>
	<JIRA.12654998.1476466920000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654998.1476466920000.6982.1476750360293@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-7319.
----------------------------------
    Resolution: Rejected


You need to change:


            <spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>

to 


            <spec-descriptor-property-replacement>true</spec-descriptor-property-replacement>

in the ee subsystem.

> Processing of variables doesn't work in servlet mapping
> -------------------------------------------------------
>
>                 Key: WFLY-7319
>                 URL: https://issues.jboss.org/browse/WFLY-7319
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: John Ament
>            Assignee: Stuart Douglas
>
> I have the following servlet mapping:
> {code}
>     <servlet>
>         <servlet-name>TogglzConsoleServlet</servlet-name>
>         <servlet-class>org.togglz.console.TogglzConsoleServlet</servlet-class>
>     </servlet>
>     <servlet-mapping>
>         <servlet-name>TogglzConsoleServlet</servlet-name>
>         <url-pattern>${togglz.uri}</url-pattern>
>     </servlet-mapping>
> {code}
> Regardless of system property, the value is not processed.  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 17 20:32:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 17 Oct 2016 20:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-124) Change switch statements
 to if/else blocks when translating levels
In-Reply-To: <JIRA.12653195.1475594871000@Atlassian.JIRA>
References: <JIRA.12653195.1475594871000@Atlassian.JIRA>
	<JIRA.12653195.1475594871000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653195.1475594871000.6994.1476750720699@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBLOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated JBLOGGING-124:
------------------------------------
    Git Pull Request: https://github.com/jboss-logging/jboss-logging/pull/22, https://github.com/jboss-logging/jboss-logging/pull/23  (was: https://github.com/jboss-logging/jboss-logging/pull/22)


> Change switch statements to if/else blocks when translating levels
> ------------------------------------------------------------------
>
>                 Key: JBLOGGING-124
>                 URL: https://issues.jboss.org/browse/JBLOGGING-124
>             Project: JBoss Logging
>          Issue Type: Enhancement
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 3.3.1.Final
>
>
> Currently a switch statement is used when levels are translated from a JBoss Logging level to the back end log level. This will likely perform better as an if/else block with the mostly likely used level at the top of the comparison.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 00:14:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 18 Oct 2016 00:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7327) Improve wording in logging
 message for key WFLYWELD0013
In-Reply-To: <JIRA.12655391.1476764018000@Atlassian.JIRA>
References: <JIRA.12655391.1476764018000@Atlassian.JIRA>
	<JIRA.12655391.1476764018725@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655391.1476764018000.7256.1476764040217@Atlassian.JIRA>

Stuart Douglas created WFLY-7327:
------------------------------------

             Summary: Improve wording in logging message for key WFLYWELD0013
                 Key: WFLY-7327
                 URL: https://issues.jboss.org/browse/WFLY-7327
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld
            Reporter: Gunnar Morling
            Assignee: Stuart Douglas
            Priority: Minor


I'm seeing this message:

{quote}
WFLYWELD0013: Deployment deployment "demo.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations)
{quote}

Apart from the repeated "deployment", the double negation makes it confusing, I reckon it should say something like that:

{quote}
WFLYWELD0013: Deployment "demo.war" contains CDI annotations but is not a bean archive (Found no beans.xml nor a class with bean defining annotations)
{quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 00:38:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 18 Oct 2016 00:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7328) Undertow subsystem is
 misleading about listener capabilities
In-Reply-To: <JIRA.12655393.1476765467000@Atlassian.JIRA>
References: <JIRA.12655393.1476765467000@Atlassian.JIRA>
	<JIRA.12655393.1476765467562@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655393.1476765467000.7291.1476765480127@Atlassian.JIRA>

Stuart Douglas created WFLY-7328:
------------------------------------

             Summary: Undertow subsystem is misleading about listener capabilities
                 Key: WFLY-7328
                 URL: https://issues.jboss.org/browse/WFLY-7328
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 10.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Stuart Douglas


ListenerResourceDefinition registers the LISTENER_CAPABILITY regardless of the value of the 'enabled' attribute. But the contract provided by that capability is only fulfilled if the attribute is 'true'.

Even worse, the attribute supports expressions, which can only be reliably resolved in Stage.RUNTIME, which is too late for recording a capability.

Fortunately, it's vault resolution that makes it necessary to resolve in RUNTIME and reality is people are highly unlikely to use the vault for this expression, so we can try and resolve and hope for the best.

This enabled stuff is just the worst. DON'T USE THIS CONCEPT IN YOUR MODEL!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 01:06:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 01:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-663) LDAP referrals does not work -
 dir-context.referral-mode is always ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.7347.1476767160111@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13307233#comment-13307233 ] 

Jan Kalina edited comment on ELY-663 at 10/18/16 1:05 AM:
----------------------------------------------------------

By discussion, -maybe- there will be need to add "filter" attribute to the ldap-realm, similar like in ldap-key-store already is to work with referrals:

{code:java}
(|(objectclass=referral)(uid={0}))
{code}


was (Author: honza889):
By discussion, maybe there will be need to add "filter" attribute to the ldap-realm, similar like in ldap-key-store already is to work with referrals:

{code:java}
(|(objectclass=referral)(uid={0}))
{code}

(will have to check yet if it helps, but by Ond?ej it is solved in Picketbox by this way)

> LDAP referrals does not work - dir-context.referral-mode is always ignored
> --------------------------------------------------------------------------
>
>                 Key: ELY-663
>                 URL: https://issues.jboss.org/browse/ELY-663
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 18 01:07:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 01:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-663) LDAP referrals does not work -
 dir-context.referral-mode is always ignored
In-Reply-To: <JIRA.12654915.1476446216000@Atlassian.JIRA>
References: <JIRA.12654915.1476446216000@Atlassian.JIRA>
	<JIRA.12654915.1476446216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654915.1476446216000.7351.1476767220144@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308155#comment-13308155 ] 

Jan Kalina commented on ELY-663:
--------------------------------

How is THROW referral mode handled in picketbox:
https://github.com/jbossas/redhat-picketbox/blob/master/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/auth/spi/LdapExtLoginModule.java#L533

> LDAP referrals does not work - dir-context.referral-mode is always ignored
> --------------------------------------------------------------------------
>
>                 Key: ELY-663
>                 URL: https://issues.jboss.org/browse/ELY-663
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Elytron dir-context is not able to follow/throw referrals in LDAP search. Value set in Elytron {{dir-context.referral-mode}} is ignored by Elytron. 
> InitialLdapContext {{java.naming.referral}} parameter is internally always set to value {{ignore}}. It is caused by ignoring {{ReferralMode}} parameter in {{obtainDirContext}} of {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory}} [1].
> We request blocker flag since this issue causes that referrals cannot be used for LDAP search with Elytron.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/SimpleDirContextFactoryBuilder.java#L222



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 01:13:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 01:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7302) Usernames started with
 rdn-identifier works incorrectly in Elytron ldap-realm
In-Reply-To: <JIRA.12654575.1476338734000@Atlassian.JIRA>
References: <JIRA.12654575.1476338734000@Atlassian.JIRA>
	<JIRA.12654575.1476338734000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654575.1476338734000.7375.1476767580383@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7302:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Usernames started with rdn-identifier works incorrectly in Elytron ldap-realm
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7302
>                 URL: https://issues.jboss.org/browse/WFLY-7302
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case username passed to {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity}} starts with the same string as is used in {{identityMapping.rdnIdentifier}} then authentication fails. It is caused by wrong condition in [1].
> Thrown exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-12) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "uidyllic" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:625)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.InvalidNameException: Invalid name: uidyllic
> 	at javax.naming.ldap.Rfc2253Parser.doParse(Rfc2253Parser.java:111)
> 	at javax.naming.ldap.Rfc2253Parser.parseDn(Rfc2253Parser.java:70)
> 	at javax.naming.ldap.LdapName.parse(LdapName.java:785)
> 	at javax.naming.ldap.LdapName.<init>(LdapName.java:123)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:571)
> 	... 45 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L570



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 01:25:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 01:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-671) Usernames started with
 rdn-identifier works incorrectly in Elytron ldap-realm
In-Reply-To: <JIRA.12654575.1476338734000@Atlassian.JIRA>
References: <JIRA.12654575.1476338734000@Atlassian.JIRA>
	<JIRA.12654575.1476338734000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654575.1476338734000.7401.1476768300143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7302 to ELY-671:
--------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-671  (was: WFLY-7302)
          Component/s: Realms
                           (was: Security)
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Usernames started with rdn-identifier works incorrectly in Elytron ldap-realm
> -----------------------------------------------------------------------------
>
>                 Key: ELY-671
>                 URL: https://issues.jboss.org/browse/ELY-671
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case username passed to {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity}} starts with the same string as is used in {{identityMapping.rdnIdentifier}} then authentication fails. It is caused by wrong condition in [1].
> Thrown exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-12) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "uidyllic" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:625)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.InvalidNameException: Invalid name: uidyllic
> 	at javax.naming.ldap.Rfc2253Parser.doParse(Rfc2253Parser.java:111)
> 	at javax.naming.ldap.Rfc2253Parser.parseDn(Rfc2253Parser.java:70)
> 	at javax.naming.ldap.LdapName.parse(LdapName.java:785)
> 	at javax.naming.ldap.LdapName.<init>(LdapName.java:123)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:571)
> 	... 45 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L570



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 01:46:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 18 Oct 2016 01:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7329) Setting elytron ssl-context
 on undertow without reload
In-Reply-To: <JIRA.12655397.1476769453000@Atlassian.JIRA>
References: <JIRA.12655397.1476769453000@Atlassian.JIRA>
	<JIRA.12655397.1476769453000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655397.1476769453000.7527.1476769560941@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6463 to WFLY-7329:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7329  (was: JBEAP-6463)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                       Web (Undertow)
                           (was: Security)
                           (was: Web (Undertow))
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Setting elytron ssl-context on undertow without reload
> ------------------------------------------------------
>
>                 Key: WFLY-7329
>                 URL: https://issues.jboss.org/browse/WFLY-7329
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Tomaz Cerar
>
> Please, allow setting of elytron ssl-context on undertow  without reload.
> {code}
> [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=server)
> {
> ????"outcome" => "success",
> ????"response-headers" => {
> ????????"operation-requires-reload" => true,
> ????????"process-state" => "reload-required"
> ????}
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 18 01:57:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 01:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-671) Usernames started with
 rdn-identifier works incorrectly in Elytron ldap-realm
In-Reply-To: <JIRA.12654575.1476338734000@Atlassian.JIRA>
References: <JIRA.12654575.1476338734000@Atlassian.JIRA>
	<JIRA.12654575.1476338734000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654575.1476338734000.7591.1476770220089@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308172#comment-13308172 ] 

Jan Kalina commented on ELY-671:
--------------------------------

The second problem is, the aministrator cannot restrict set of allowed users using search-dn, as user can override using DN...

> Usernames started with rdn-identifier works incorrectly in Elytron ldap-realm
> -----------------------------------------------------------------------------
>
>                 Key: ELY-671
>                 URL: https://issues.jboss.org/browse/ELY-671
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case username passed to {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity}} starts with the same string as is used in {{identityMapping.rdnIdentifier}} then authentication fails. It is caused by wrong condition in [1].
> Thrown exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-12) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "uidyllic" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:625)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.InvalidNameException: Invalid name: uidyllic
> 	at javax.naming.ldap.Rfc2253Parser.doParse(Rfc2253Parser.java:111)
> 	at javax.naming.ldap.Rfc2253Parser.parseDn(Rfc2253Parser.java:70)
> 	at javax.naming.ldap.LdapName.parse(LdapName.java:785)
> 	at javax.naming.ldap.LdapName.<init>(LdapName.java:123)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:571)
> 	... 45 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L570



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 02:04:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 02:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-671) Usernames started with
 rdn-identifier works incorrectly in Elytron ldap-realm
In-Reply-To: <JIRA.12654575.1476338734000@Atlassian.JIRA>
References: <JIRA.12654575.1476338734000@Atlassian.JIRA>
	<JIRA.12654575.1476338734000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654575.1476338734000.7594.1476770640138@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-671:
---------------------------
    Comment: was deleted

(was: The second problem is, the aministrator cannot restrict set of allowed users using search-dn, as user can override using DN...)


> Usernames started with rdn-identifier works incorrectly in Elytron ldap-realm
> -----------------------------------------------------------------------------
>
>                 Key: ELY-671
>                 URL: https://issues.jboss.org/browse/ELY-671
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case username passed to {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity}} starts with the same string as is used in {{identityMapping.rdnIdentifier}} then authentication fails. It is caused by wrong condition in [1].
> Thrown exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-12) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "uidyllic" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:625)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.InvalidNameException: Invalid name: uidyllic
> 	at javax.naming.ldap.Rfc2253Parser.doParse(Rfc2253Parser.java:111)
> 	at javax.naming.ldap.Rfc2253Parser.parseDn(Rfc2253Parser.java:70)
> 	at javax.naming.ldap.LdapName.parse(LdapName.java:785)
> 	at javax.naming.ldap.LdapName.<init>(LdapName.java:123)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:571)
> 	... 45 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L570



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 02:40:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Oct 2016 02:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2113) TP: support multiple entries
	in bind_addr
In-Reply-To: <JIRA.12655230.1476700587000@Atlassian.JIRA>
References: <JIRA.12655230.1476700587000@Atlassian.JIRA>
	<JIRA.12655230.1476700587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655230.1476700587000.7752.1476772800218@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2113.
----------------------------
    Resolution: Done


> TP: support multiple entries in bind_addr
> -----------------------------------------
>
>                 Key: JGRP-2113
>                 URL: https://issues.jboss.org/browse/JGRP-2113
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Add support for multiple entries in {{bind_addr}}, e.g.
> {code:xml}
>   bind_addr="match-interface:eth2,10.5.5.5,match-interface:en*,127.0.0.1"
> {code}
> This would try to bind to {{eth2}} first. If not found, then an interface with address {{10.5.5.5}} would be tried, then an interface starting with {{en}} would be tried. If still not found, we'd bind to {{127.0.0.1}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 02:43:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 02:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-671) Usernames started with
 rdn-identifier works incorrectly in Elytron ldap-realm
In-Reply-To: <JIRA.12654575.1476338734000@Atlassian.JIRA>
References: <JIRA.12654575.1476338734000@Atlassian.JIRA>
	<JIRA.12654575.1476338734000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654575.1476338734000.7759.1476772980087@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308186#comment-13308186 ] 

Jan Kalina commented on ELY-671:
--------------------------------

The second problem is search-dn, which is overrided by user when the DN is used... will have to add check too...

> Usernames started with rdn-identifier works incorrectly in Elytron ldap-realm
> -----------------------------------------------------------------------------
>
>                 Key: ELY-671
>                 URL: https://issues.jboss.org/browse/ELY-671
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case username passed to {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity}} starts with the same string as is used in {{identityMapping.rdnIdentifier}} then authentication fails. It is caused by wrong condition in [1].
> Thrown exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-12) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "uidyllic" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:625)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.InvalidNameException: Invalid name: uidyllic
> 	at javax.naming.ldap.Rfc2253Parser.doParse(Rfc2253Parser.java:111)
> 	at javax.naming.ldap.Rfc2253Parser.parseDn(Rfc2253Parser.java:70)
> 	at javax.naming.ldap.LdapName.parse(LdapName.java:785)
> 	at javax.naming.ldap.LdapName.<init>(LdapName.java:123)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:571)
> 	... 45 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/LdapSecurityRealm.java#L570



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 02:52:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Oct 2016 02:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2114) TP.setThreadPool() does not
 set thread pool in timer
In-Reply-To: <JIRA.12655400.1476773517000@Atlassian.JIRA>
References: <JIRA.12655400.1476773517000@Atlassian.JIRA>
	<JIRA.12655400.1476773517360@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655400.1476773517000.7798.1476773520516@Atlassian.JIRA>

Bela Ban created JGRP-2114:
------------------------------

             Summary: TP.setThreadPool() does not set thread pool in timer
                 Key: JGRP-2114
                 URL: https://issues.jboss.org/browse/JGRP-2114
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0


When setting a custom thread pool in TP via {{setThreadPool()}}, the thread pool used by the timer still has a ref to the old thread pool, which was shut down when setting the new thread pool.
Solution: make {{setThreadPool()}} also set the new pool in the timer.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 02:57:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Oct 2016 02:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2114) TP.setThreadPool() does not
 set thread pool in timer
In-Reply-To: <JIRA.12655400.1476773517000@Atlassian.JIRA>
References: <JIRA.12655400.1476773517000@Atlassian.JIRA>
	<JIRA.12655400.1476773517000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655400.1476773517000.7828.1476773820183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2114.
----------------------------
    Resolution: Done


> TP.setThreadPool() does not set thread pool in timer
> ----------------------------------------------------
>
>                 Key: JGRP-2114
>                 URL: https://issues.jboss.org/browse/JGRP-2114
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> When setting a custom thread pool in TP via {{setThreadPool()}}, the thread pool used by the timer still has a ref to the old thread pool, which was shut down when setting the new thread pool.
> Solution: make {{setThreadPool()}} also set the new pool in the timer.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 03:20:00 2016
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Kalman_=28JIRA=29?=)
Date: Tue, 18 Oct 2016 03:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.8015.1476775200685@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308209#comment-13308209 ] 

Ond?ej Kalman commented on WFLY-5213:
-------------------------------------

Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than EAP does. You can do workaround (if you want)  in naming subsystem to eliminate this problem, here is an example.

{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
            <bindings>
                <external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
                    <environment>
                        <property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
                        <property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
                       <property name="queue.testQueue" value="testQueue"/>
                    </environment>
                    <property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
                </external-context>
                <lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
           </bindings>
</subsystem>
{code}


> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 18 03:21:00 2016
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Kalman_=28JIRA=29?=)
Date: Tue, 18 Oct 2016 03:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.8027.1476775260899@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308209#comment-13308209 ] 

Ond?ej Kalman edited comment on WFLY-5213 at 10/18/16 3:20 AM:
---------------------------------------------------------------

Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than EAP does. You can do workaround (if you want)  in naming subsystem to eliminate this problem, here is an example.

{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
            <bindings>
                <external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
                    <environment>
                        <property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
                        <property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
                        <property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
                    </environment>
                </external-context>
                <lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
           </bindings>
</subsystem>
{code}



was (Author: okalman):
Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than EAP does. You can do workaround (if you want)  in naming subsystem to eliminate this problem, here is an example.

{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
            <bindings>
                <external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
                    <environment>
                        <property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
                        <property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
                       <property name="queue.testQueue" value="testQueue"/>
                    </environment>
                    <property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
                </external-context>
                <lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
           </bindings>
</subsystem>
{code}


> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 18 03:22:00 2016
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Kalman_=28JIRA=29?=)
Date: Tue, 18 Oct 2016 03:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.8033.1476775320685@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308209#comment-13308209 ] 

Ond?ej Kalman edited comment on WFLY-5213 at 10/18/16 3:21 AM:
---------------------------------------------------------------

Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than WildFly/EAP does. You can do workaround (if you want)  in naming subsystem to eliminate this problem, here is an example.

{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
            <bindings>
                <external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
                    <environment>
                        <property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
                        <property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
                        <property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
                    </environment>
                </external-context>
                <lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
           </bindings>
</subsystem>
{code}



was (Author: okalman):
Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than EAP does. You can do workaround (if you want)  in naming subsystem to eliminate this problem, here is an example.

{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
            <bindings>
                <external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
                    <environment>
                        <property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
                        <property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
                        <property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
                    </environment>
                </external-context>
                <lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
           </bindings>
</subsystem>
{code}


> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 18 03:44:00 2016
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 18 Oct 2016 03:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1845) Logging subsystem scans the
 CWD on server boot
In-Reply-To: <JIRA.12652897.1475276050000@Atlassian.JIRA>
References: <JIRA.12652897.1475276050000@Atlassian.JIRA>
	<JIRA.12652897.1475276050000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652897.1475276050000.8200.1476776640916@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308225#comment-13308225 ] 

Heiko Braun commented on WFCORE-1845:
-------------------------------------

[~jamezp] Can yo give me an estimate for this? I have a bunch of other WF Core fixes and wonder if it's worth waiting for this.

> Logging subsystem scans the CWD on server boot
> ----------------------------------------------
>
>                 Key: WFCORE-1845
>                 URL: https://issues.jboss.org/browse/WFCORE-1845
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 2.0.10.Final
>         Environment: OSX El Capitan, Oracle JDK 1.8.0_92 && 101, swarm 2016.8.1, WF 10.0.0.Final, WF-CORE 2.0.10.Final
>            Reporter: Brent Douglas
>            Assignee: James Perkins
>
> When booting the server from a directory where the subtree is large the server hangs for a long time. JStack shows that the logging subsystem is scanning the CWD.
> Booting the server from the root dir of a maven parent project containing 2 subprojects, a swarm project and a small NPM subproject added 33s to the server boot time compared to stepping into the swarm project and booting it.
> Stacktrace while the server is booting:
> {noformat}
> Thread 25859: (state = IN_NATIVE)
>  - sun.nio.fs.UnixNativeDispatcher.lstat0(long, sun.nio.fs.UnixFileAttributes) @bci=0 (Compiled frame; information may be imprecise)
>  - sun.nio.fs.UnixNativeDispatcher.lstat(sun.nio.fs.UnixPath, sun.nio.fs.UnixFileAttributes) @bci=10, line=300 (Compiled frame)
>  - sun.nio.fs.UnixFileAttributes.get(sun.nio.fs.UnixPath, boolean) @bci=22, line=72 (Compiled frame)
>  - sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes() @bci=15, line=52 (Compiled frame)
>  - sun.nio.fs.UnixFileSystemProvider.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=57, line=144 (Compiled frame)
>  - java.nio.file.Files.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=7, line=1737 (Compiled frame)
>  - java.nio.file.FileTreeWalker.getAttributes(java.nio.file.Path, boolean) @bci=56, line=219 (Compiled frame)
>  - java.nio.file.FileTreeWalker.visit(java.nio.file.Path, boolean, boolean) @bci=3, line=276 (Compiled frame)
>  - java.nio.file.FileTreeWalker.next() @bci=134, line=372 (Compiled frame)
>  - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.util.Set, int, java.nio.file.FileVisitor) @bci=256, line=2706 (Compiled frame)
>  - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.nio.file.FileVisitor) @bci=9, line=2742 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.findFiles(java.lang.String, org.jboss.dmr.ModelNode, boolean) @bci=47, line=251 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.getChildrenNames(java.lang.String) @bci=37, line=157 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.getChildren(java.lang.String) @bci=11, line=171 (Interpreted frame)
>  - org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(java.lang.String) @bci=5, line=362 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=99, line=289 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=189, line=291 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource) @bci=2, line=250 (Interpreted frame)
>  - org.jboss.as.controller.ModelControllerImpl.writeModel(org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl, java.util.Set) @bci=19, line=769 (Interpreted frame)
>  - org.jboss.as.controller.OperationContextImpl.createPersistenceResource() @bci=17, line=519 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.executeDoneStage(org.jboss.dmr.ModelNode) @bci=22, line=708 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.processStages() @bci=277, line=680 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.executeOperation() @bci=27, line=370 (Interpreted frame)
>  - org.jboss.as.controller.OperationContextImpl.executeOperation() @bci=20, line=1344 (Interpreted frame)
>  - org.jboss.as.controller.ModelControllerImpl.boot(java.util.List, org.jboss.as.controller.client.OperationMessageHandler, org.jboss.as.controller.ModelController$OperationTransactionControl, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider, boolean, boolean) @bci=410, line=485 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider) @bci=16, line=387 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean) @bci=7, line=349 (Interpreted frame)
>  - org.jboss.as.server.ServerService.boot(java.util.List, boolean) @bci=22, line=392 (Interpreted frame)
>  - org.jboss.as.server.ServerService.boot(org.jboss.as.controller.BootContext) @bci=907, line=365 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService$1.run() @bci=12, line=299 (Interpreted frame)
>  - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 03:56:00 2016
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 18 Oct 2016 03:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1786) SelfContainedContainer:
 Allow the ConfigurationPersisterFactory to be customised
In-Reply-To: <JIRA.12649954.1473768607000@Atlassian.JIRA>
References: <JIRA.12649954.1473768607000@Atlassian.JIRA>
	<JIRA.12649954.1473768607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649954.1473768607000.8248.1476777360899@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFCORE-1786:
--------------------------------
    Labels: backport_2.x  (was: )


> SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-1786
>                 URL: https://issues.jboss.org/browse/WFCORE-1786
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: backport_2.x
>             Fix For: 3.0.0.Alpha8
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 03:56:01 2016
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Tue, 18 Oct 2016 03:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1797) LaunchType.SELF_CONTAINED
 doesn't cleanup the temporary "wildfly-self-contained" directory
In-Reply-To: <JIRA.12650278.1473930935000@Atlassian.JIRA>
References: <JIRA.12650278.1473930935000@Atlassian.JIRA>
	<JIRA.12650278.1473930935000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650278.1473930935000.8257.1476777361354@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFCORE-1797:
--------------------------------
    Labels: backport_2.x  (was: )


> LaunchType.SELF_CONTAINED doesn't cleanup the temporary "wildfly-self-contained" directory
> ------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1797
>                 URL: https://issues.jboss.org/browse/WFCORE-1797
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: backport_2.x
>             Fix For: 3.0.0.Alpha9
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 04:23:01 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 18 Oct 2016 04:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7330) Colocated HA topology with
 HTTP connectors/acceptors
In-Reply-To: <JIRA.12655417.1476778910000@Atlassian.JIRA>
References: <JIRA.12655417.1476778910000@Atlassian.JIRA>
	<JIRA.12655417.1476778910000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655417.1476778910000.8429.1476778981608@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-6466 to WFLY-7330:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7330  (was: JBEAP-6466)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JMS
                           (was: JMS)
    Affects Version/s: 10.1.0.Final
                           (was: 7.0.0.GA)


> Colocated HA topology with HTTP connectors/acceptors
> ----------------------------------------------------
>
>                 Key: WFLY-7330
>                 URL: https://issues.jboss.org/browse/WFLY-7330
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Critical
>
> I try to configure colocated HA topology with HTTP connectors/acceptors but something goes wrong and I see repeated WARN message \[1\] on the first node and on the second I see the \[2\]. Maybe it is misconfiguration, but I have no idea what I do wrong. I attached XML configurations of both nodes, please review it.
> \[1\]
> {code}
> 12:55:47,789 WARN  [org.apache.activemq.artemis.core.client] (Thread-10 (ActiveMQ-client-global-threads-487873773)) AMQ212006: Waiting 2?000 milliseconds before next retry. RetryInterval=2?000 and multiplier=1
> {code}
> \[2\]
> {code}
> 12:56:39,054 WARN  [org.apache.activemq.artemis.core.client] (Thread-10 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 4766f9b3-516179796)) AMQ212006: Waiting 500 milliseconds before next retry. RetryInterval=500 and multiplier=1
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 18 05:36:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 05:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-672) Getting identity by DN in
 Elytron ldap-realm should be case insensitive
In-Reply-To: <JIRA.12654645.1476357070000@Atlassian.JIRA>
References: <JIRA.12654645.1476357070000@Atlassian.JIRA>
	<JIRA.12654645.1476357070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654645.1476357070000.9199.1476783360459@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7305 to ELY-672:
--------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-672  (was: WFLY-7305)
          Component/s: Realms
                           (was: Security)
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Getting identity by DN in Elytron ldap-realm should be case insensitive
> -----------------------------------------------------------------------
>
>                 Key: ELY-672
>                 URL: https://issues.jboss.org/browse/ELY-672
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail. 
> LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 05:40:01 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 18 Oct 2016 05:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.9222.1476783601166@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308326#comment-13308326 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

Hi Brian,

it doesn't seem that Jira sets my name as the default assignee for CLI 
issues. Any action on my side?

JF.






> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 06:12:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 18 Oct 2016 06:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7331) Add EAP 7.0.0 transformers
 tests for mod_cluster subsystem
In-Reply-To: <JIRA.12655435.1476785489000@Atlassian.JIRA>
References: <JIRA.12655435.1476785489000@Atlassian.JIRA>
	<JIRA.12655435.1476785489654@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655435.1476785489000.9427.1476785520213@Atlassian.JIRA>

Radoslav Husar created WFLY-7331:
------------------------------------

             Summary: Add EAP 7.0.0 transformers tests for mod_cluster subsystem
                 Key: WFLY-7331
                 URL: https://issues.jboss.org/browse/WFLY-7331
             Project: WildFly
          Issue Type: Task
          Components: mod_cluster
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


Needs to be added before any elytron integration work.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 06:16:02 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 18 Oct 2016 06:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7332) Infinispan transformation
 tests fail on backups resource for EAP 7.0.0
In-Reply-To: <JIRA.12655436.1476785721000@Atlassian.JIRA>
References: <JIRA.12655436.1476785721000@Atlassian.JIRA>
	<JIRA.12655436.1476785721885@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655436.1476785721000.9463.1476785762508@Atlassian.JIRA>

Radoslav Husar created WFLY-7332:
------------------------------------

             Summary: Infinispan transformation tests fail on backups resource for EAP 7.0.0
                 Key: WFLY-7332
                 URL: https://issues.jboss.org/browse/WFLY-7332
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


{noformat}
Failed tests:
  TransformersTestCase.testTransformerEAP700:162->testTransformation:191->AbstractSubsystemTest.checkSubsystemModelTransformation:292 cache-container/maximal/distributed-cache/dist/component/: {
    "expiration" => {
        "interval" => 10000L,
        "lifespan" => 10L,
        "max-idle" => 10L
    },
    "state-transfer" => {
        "chunk-size" => 10000,
        "enabled" => undefined,
        "timeout" => 60000L
    },
    "eviction" => {
        "max-entries" => 20000L,
        "strategy" => "UNORDERED"
    },
    "locking" => {
        "acquire-timeout" => 30000L,
        "concurrency-level" => 2000,
        "isolation" => "READ_COMMITTED",
        "striping" => true
    },
    "backups" => {},
    "transaction" => {
        "locking" => "OPTIMISTIC",
        "mode" => "FULL_XA",
        "stop-timeout" => 60000L
    },
    "backup-for" => {},
    "partition-handling" => {}
}
{
    "expiration" => {
        "max-idle" => 10L,
        "lifespan" => 10L,
        "interval" => 10000L
    },
    "state-transfer" => {
        "chunk-size" => 10000,
        "timeout" => 60000L,
        "enabled" => undefined
    },
    "eviction" => {
        "max-entries" => 20000L,
        "strategy" => "UNORDERED"
    },
    "locking" => {
        "striping" => true,
        "isolation" => "READ_COMMITTED",
        "acquire-timeout" => 30000L,
        "concurrency-level" => 2000
    },
    "backups" => undefined,
    "transaction" => {
        "mode" => "FULL_XA",
        "locking" => "OPTIMISTIC",
        "stop-timeout" => 60000L
    },
    "backup-for" => {},
    "partition-handling" => {}
} expected:<[backup-for, [backups, ]eviction, expiration...> but was:<[backup-for, []eviction, expiration...>



Tests run: 108, Failures: 1, Errors: 0, Skipped: 19
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 06:16:02 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 18 Oct 2016 06:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7332) Infinispan transformation
 tests fail on backups resource for EAP 7.0.0
In-Reply-To: <JIRA.12655436.1476785722000@Atlassian.JIRA>
References: <JIRA.12655436.1476785722000@Atlassian.JIRA>
	<JIRA.12655436.1476785722000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655436.1476785722000.9467.1476785762686@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7332:
---------------------------------
    Priority: Minor  (was: Major)


> Infinispan transformation tests fail on backups resource for EAP 7.0.0
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7332
>                 URL: https://issues.jboss.org/browse/WFLY-7332
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> {noformat}
> Failed tests:
>   TransformersTestCase.testTransformerEAP700:162->testTransformation:191->AbstractSubsystemTest.checkSubsystemModelTransformation:292 cache-container/maximal/distributed-cache/dist/component/: {
>     "expiration" => {
>         "interval" => 10000L,
>         "lifespan" => 10L,
>         "max-idle" => 10L
>     },
>     "state-transfer" => {
>         "chunk-size" => 10000,
>         "enabled" => undefined,
>         "timeout" => 60000L
>     },
>     "eviction" => {
>         "max-entries" => 20000L,
>         "strategy" => "UNORDERED"
>     },
>     "locking" => {
>         "acquire-timeout" => 30000L,
>         "concurrency-level" => 2000,
>         "isolation" => "READ_COMMITTED",
>         "striping" => true
>     },
>     "backups" => {},
>     "transaction" => {
>         "locking" => "OPTIMISTIC",
>         "mode" => "FULL_XA",
>         "stop-timeout" => 60000L
>     },
>     "backup-for" => {},
>     "partition-handling" => {}
> }
> {
>     "expiration" => {
>         "max-idle" => 10L,
>         "lifespan" => 10L,
>         "interval" => 10000L
>     },
>     "state-transfer" => {
>         "chunk-size" => 10000,
>         "timeout" => 60000L,
>         "enabled" => undefined
>     },
>     "eviction" => {
>         "max-entries" => 20000L,
>         "strategy" => "UNORDERED"
>     },
>     "locking" => {
>         "striping" => true,
>         "isolation" => "READ_COMMITTED",
>         "acquire-timeout" => 30000L,
>         "concurrency-level" => 2000
>     },
>     "backups" => undefined,
>     "transaction" => {
>         "mode" => "FULL_XA",
>         "locking" => "OPTIMISTIC",
>         "stop-timeout" => 60000L
>     },
>     "backup-for" => {},
>     "partition-handling" => {}
> } expected:<[backup-for, [backups, ]eviction, expiration...> but was:<[backup-for, []eviction, expiration...>
> Tests run: 108, Failures: 1, Errors: 0, Skipped: 19
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 06:23:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 06:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7289) Adding ldap-key-store
 requires accessible ldap server
In-Reply-To: <JIRA.12654219.1476189896000@Atlassian.JIRA>
References: <JIRA.12654219.1476189896000@Atlassian.JIRA>
	<JIRA.12654219.1476189896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654219.1476189896000.9817.1476786180565@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7289:
--------------------------------

    Assignee: Jan Kalina


> Adding ldap-key-store requires accessible ldap server
> -----------------------------------------------------
>
>                 Key: WFLY-7289
>                 URL: https://issues.jboss.org/browse/WFLY-7289
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Playing with ldap-key-store . What I consider very unconvenient is fact, that in moment of adding ldap-key-store, ldap server has to be running and accessible. Elytron ldap-realm does not need that. Doubt about legacy security realms. Is it possible to decouple that dependency and leave that check till first ldap-key-store usage?
> Steps to reproduce:
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=a:add()
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=a:add(dir-context=a, search-path="a")
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> {code}
> leads to exception in server log
> {code}
> 14:37:25,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
>     "address" => [
>         ("subsystem" => "elytron"),
>         ("ldap-key-store" => "a")
>     ],
>     "operation" => "add",
>     "search-path" => "a",
>     "dir-context" => "a",
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE"
>     }
> }]: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildTypes(AbstractModelResource.java:372)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:787)
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:520)
> 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:758)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:709)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: Cannot parse url: undefined [Root exception is java.net.MalformedURLException: Invalid URI: undefined]
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:92)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:163)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 39 more
> Caused by: java.net.MalformedURLException: Invalid URI: undefined
> 	at com.sun.jndi.toolkit.url.Uri.parse(Uri.java:199)
> 	at com.sun.jndi.toolkit.url.Uri.init(Uri.java:138)
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:82)
> 	... 56 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 06:33:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 06:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7290) Unable to remove elytron
	ldap-key-store
In-Reply-To: <JIRA.12654226.1476190726000@Atlassian.JIRA>
References: <JIRA.12654226.1476190726000@Atlassian.JIRA>
	<JIRA.12654226.1476190726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654226.1476190726000.9861.1476786780297@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7290:
--------------------------------

    Assignee: Jan Kalina


> Unable to remove elytron ldap-key-store
> ---------------------------------------
>
>                 Key: WFLY-7290
>                 URL: https://issues.jboss.org/browse/WFLY-7290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Once ldap-key-store is added it can't be removed.
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=b:add(url=ldap://localhost, principal="CN=user,DC=wildfly,DC=org", credential=password)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:add(dir-context=b,search-path="DC=wildfly,DC=org")
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:remove()
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
>     "rolled-back" => true
> }
> {code}
> which leads to error in server log
> {code}
> 14:55:41,841 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 12) WFLYCTL0013: Operation ("remove") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-key-store" => "b")
> ]): java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.AbstractRemoveStepHandler.execute(AbstractRemoveStepHandler.java:66)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 31 more
> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 06:36:00 2016
From: issues at jboss.org (Bartosz Andrzejewski (JIRA))
Date: Tue, 18 Oct 2016 06:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.9902.1476786960882@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308505#comment-13308505 ] 

Bartosz Andrzejewski commented on WFLY-5213:
--------------------------------------------

Hello [~okalman]

So I tried to do it your way, but still no success. Maybe I will post my configuration so you could see whats wrong with it.

Standalone artemis config:

{code:java}
<jms xmlns="urn:activemq:jms">
      <queue name="jms.queue.example.destination"/>
   </jms>
{code}

WildFly configuration:

{code:java}
//...
<outbound-socket-binding name="remote-artemis">
            <remote-destination host="192.168.56.10" port="61616"/>
        </outbound-socket-binding>
//...
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
            <server name="default">
                <security-setting name="#">
                    <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
                </security-setting>
                <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10"/>
                <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
                <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
                    <param name="batch-delay" value="50"/>
                </http-connector>
                <remote-connector name="remote-artemis" socket-binding="remote-artemis"/>
                <in-vm-connector name="in-vm" server-id="0"/>
                <http-acceptor name="http-acceptor" http-listener="default"/>
                <http-acceptor name="http-acceptor-throughput" http-listener="default">
                    <param name="batch-delay" value="50"/>
                    <param name="direct-deliver" value="false"/>
                </http-acceptor>
                <in-vm-acceptor name="in-vm" server-id="0"/>
                <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
                <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
                <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
                <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
                <pooled-connection-factory name="remote-artemis" entries="java:/jms/remoteCF" connectors="remote-artemis" user="user" password="password"/>
                <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>
            </server>
        </subsystem>
        <subsystem xmlns="urn:jboss:domain:naming:2.0">
            <bindings>
                <external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
                    <environment>
                        <property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
                        <property name="java.naming.provider.url" value="tcp://192.168.56.10:61616"/>
                        <property name="queue.jms.queue.example.destination" value="jms.queue.example.destination"/>
                    </environment>
                </external-context>
                <lookup name="java:/jms.queue.example.destination" lookup="java:global/remoteContext/jms.queue.example.destination"/>
            </bindings>
            <remote-naming/>
{code}

And I am trying to perform a test that way:

{code:java}
//Producer
public class MessageProductioner {

	@Inject
	@JMSConnectionFactory("java:/jms/remoteCF")
	@JMSPasswordCredential(userName = "user", password = "password")
	private JMSContext context;

	@Resource(lookup = "java:global/remoteContext/jms.queue.example.destination")
	private Queue queue;

	@Resource
	private TimerService timerService;

	@PostConstruct
	private void init() {
		timerService.createTimer(1000, null);
	}

	@Timeout
	public void hey() {
		context.createProducer().send(queue, "coming through");
	}

}
//Consumer
@MessageDriven(name = "MessageConsiumer", activationConfig = {
        @ActivationConfigProperty(propertyName = "connectionFactoryLookup", propertyValue = "java:/jms/remoteCF"),
        @ActivationConfigProperty(propertyName="user", propertyValue="user"),
        @ActivationConfigProperty(propertyName="password", propertyValue="password"),
        @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "java:global/remoteContext/jms.queue.example.destination"),
        @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
        @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
public class MessageConsiumer implements MessageListener {

	@Override
	public void onMessage(Message message) {
		try {
			TextMessage msg = (TextMessage) message;
			System.out.println(msg.getText());
		} catch (JMSException e) {
			e.printStackTrace();
		}
		
	}
}
{code}


> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 18 06:57:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 18 Oct 2016 06:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3884) Integrate mod_cluster
 subsystem with Elytron security subsystem for SSL configuration
In-Reply-To: <JIRA.12552985.1411396668000@Atlassian.JIRA>
References: <JIRA.12552985.1411396668000@Atlassian.JIRA>
	<JIRA.12552985.1411396668000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552985.1411396668000.10083.1476788220559@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-3884:
-----------------------------------
    Component/s: mod_cluster
                     (was: Clustering)


> Integrate mod_cluster subsystem with Elytron security subsystem for SSL configuration
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-3884
>                 URL: https://issues.jboss.org/browse/WFLY-3884
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: mod_cluster
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.CR1
>
>
> Currently, the SSL certificate configuration is embedded within the mod_cluster subsystem configuration.  Ideally, mod_cluster would reference this configuration from the security subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 07:08:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 07:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7175) Complex type
 server-ssl-context in Elytron subsystem
In-Reply-To: <JIRA.12651200.1474462474000@Atlassian.JIRA>
References: <JIRA.12651200.1474462474000@Atlassian.JIRA>
	<JIRA.12651200.1474462474000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651200.1474462474000.10179.1476788880572@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7175:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Complex type server-ssl-context in Elytron subsystem
> ----------------------------------------------------
>
>                 Key: WFLY-7175
>                 URL: https://issues.jboss.org/browse/WFLY-7175
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Elytron subsystem uses complex type in server-ssl-context resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 07:08:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 07:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7176) Review
 x500-attribute-principal-decoder resource in Elytron subsystem
In-Reply-To: <JIRA.12651202.1474462690000@Atlassian.JIRA>
References: <JIRA.12651202.1474462690000@Atlassian.JIRA>
	<JIRA.12651202.1474462690000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651202.1474462690000.10196.1476788881023@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7176:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Review x500-attribute-principal-decoder resource in Elytron subsystem
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7176
>                 URL: https://issues.jboss.org/browse/WFLY-7176
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> See description of JBEAP-6100 for more details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 07:15:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 07:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7317) Elytron ldap-key-store DMR
 XSD inconsistency
In-Reply-To: <JIRA.12654928.1476449660000@Atlassian.JIRA>
References: <JIRA.12654928.1476449660000@Atlassian.JIRA>
	<JIRA.12654928.1476449660000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654928.1476449660000.10264.1476789301148@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7317:
--------------------------------

    Assignee: Jan Kalina


> Elytron ldap-key-store DMR XSD inconsistency 
> ---------------------------------------------
>
>                 Key: WFLY-7317
>                 URL: https://issues.jboss.org/browse/WFLY-7317
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>
> * in XSD there are missing attributes {{key-attribute}} and {{key-type}}
> * in XSD {{value}} attribute of {{new-item-template}} is not a list type as in DMR
> * in DMR {{name}} in {{new-item-attributes}} is optional. In XSD it is marked as required. Should be required in DMR as well.
> * synchronize documenation of XSD and DMR. Documentation in XSD seems little bit detailed.
> * In {{certificate-type}} and {{certificate-attribute}} probably remove link to oracle java 8 documentation. I consider it usefull, but I see couple of maintaining issues. Link can change. Java 9 is comming and can have own enumaration. We also support IBM java. Just stating "For possible values see java documentation of CertificateFactory/CertPathEncodings" would be enough here



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 07:53:02 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 18 Oct 2016 07:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7333) EAP is unable to remove
 cloned full-ha profile
In-Reply-To: <JIRA.12655471.1476791547000@Atlassian.JIRA>
References: <JIRA.12655471.1476791547000@Atlassian.JIRA>
	<JIRA.12655471.1476791547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655471.1476791547000.10713.1476791582631@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-6472 to WFLY-7333:
------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-7333  (was: JBEAP-6472)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: JMS
                     (was: Clustering)
                     (was: Domain Management)
                     (was: JMS)


> EAP is unable to remove cloned full-ha profile
> ----------------------------------------------
>
>                 Key: WFLY-7333
>                 URL: https://issues.jboss.org/browse/WFLY-7333
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> *Description:*
> EAP is unable to remove cloned full-ha profile. This is regression against EAP 7.1.0.DR5. "clone" management operation was introduced in EAP7-35
> *Steps to reproduce:*
> # ./domain.sh
> # ./jboss-cli.sh -c
> # /profile=full-ha:clone(to-profile=cli-clone-profile-first-full-ha)
> # /profile=cli-clone-profile-first-full-ha:remove
> *Actual results:*
> {noformat}
> [mkopecky at dhcp-10-40-5-171 bin]$ ./jboss-cli.sh -c
> [domain at localhost:9990 /] /profile=full-ha:clone(to-profile=cli-clone-profile-first-full-ha)
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> [domain at localhost:9990 /] /profile=cli-clone-profile-first-full-ha:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0368: Cannot remove capability 'org.wildfly.clustering.jgroups.default-channel-factory' from context 'profile=cli-clone-profile-first-full-ha' as it is required by other capabilities:
> capability 'org.wildfly.messaging.activemq.broadcast-group.channel-factory.bg-group1' requires it for attribute 'jgroups-stack' at address '/profile=cli-clone-profile-first-full-ha/subsystem=messaging-activemq/server=default/broadcast-group=bg-group1'
> capability 'org.wildfly.messaging.activemq.discovery-group.channel-factory.dg-group1' requires it for attribute 'jgroups-stack' at address '/profile=cli-clone-profile-first-full-ha/subsystem=messaging-activemq/server=default/discovery-group=dg-group1'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 07:54:01 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 18 Oct 2016 07:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7333) messaging-activemq resources
 are not recursively removed.
In-Reply-To: <JIRA.12655471.1476791547000@Atlassian.JIRA>
References: <JIRA.12655471.1476791547000@Atlassian.JIRA>
	<JIRA.12655471.1476791547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655471.1476791547000.10730.1476791641043@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-7333:
------------------------------
    Summary: messaging-activemq resources are not recursively removed.  (was: EAP is unable to remove cloned full-ha profile)


> messaging-activemq resources are not recursively removed.
> ---------------------------------------------------------
>
>                 Key: WFLY-7333
>                 URL: https://issues.jboss.org/browse/WFLY-7333
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> *Description:*
> EAP is unable to remove cloned full-ha profile. This is regression against EAP 7.1.0.DR5. "clone" management operation was introduced in EAP7-35
> *Steps to reproduce:*
> # ./domain.sh
> # ./jboss-cli.sh -c
> # /profile=full-ha:clone(to-profile=cli-clone-profile-first-full-ha)
> # /profile=cli-clone-profile-first-full-ha:remove
> *Actual results:*
> {noformat}
> [mkopecky at dhcp-10-40-5-171 bin]$ ./jboss-cli.sh -c
> [domain at localhost:9990 /] /profile=full-ha:clone(to-profile=cli-clone-profile-first-full-ha)
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> [domain at localhost:9990 /] /profile=cli-clone-profile-first-full-ha:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0368: Cannot remove capability 'org.wildfly.clustering.jgroups.default-channel-factory' from context 'profile=cli-clone-profile-first-full-ha' as it is required by other capabilities:
> capability 'org.wildfly.messaging.activemq.broadcast-group.channel-factory.bg-group1' requires it for attribute 'jgroups-stack' at address '/profile=cli-clone-profile-first-full-ha/subsystem=messaging-activemq/server=default/broadcast-group=bg-group1'
> capability 'org.wildfly.messaging.activemq.discovery-group.channel-factory.dg-group1' requires it for attribute 'jgroups-stack' at address '/profile=cli-clone-profile-first-full-ha/subsystem=messaging-activemq/server=default/discovery-group=dg-group1'"},
>     "rolled-back" => true
> }
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 08:19:00 2016
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Kalman_=28JIRA=29?=)
Date: Tue, 18 Oct 2016 08:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.11009.1476793140460@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308581#comment-13308581 ] 

Ond?ej Kalman commented on WFLY-5213:
-------------------------------------

I checked your client and its fine, on MDB site you have to use @ResourceAdapter(value="remote-artemis")just above "public class MessageConsiumer implements MessageListener ". I think you can safely remove "connectionFactoryLookup"

> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 18 08:20:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 18 Oct 2016 08:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7100) Add JGroups-based
 SingletonServiceBuilderFactory implementation
In-Reply-To: <JIRA.12649923.1473765419000@Atlassian.JIRA>
References: <JIRA.12649923.1473765419000@Atlassian.JIRA>
	<JIRA.12649923.1473765419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649923.1473765419000.11022.1476793200513@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-7100:
-------------------------------
    Summary: Add JGroups-based SingletonServiceBuilderFactory implementation  (was: Reimplement Singleton services using JGroups instead of Infinispan)


> Add JGroups-based SingletonServiceBuilderFactory implementation
> ---------------------------------------------------------------
>
>                 Key: WFLY-7100
>                 URL: https://issues.jboss.org/browse/WFLY-7100
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> The singleton subsystem currently requires the Infinispan subsystem.  To minimize the requirements for using the singleton subsystem within the context of the host-controller, we should reimplement singleton service using JGroups directly, instead of requiring an Infinispan cache.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 08:26:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 18 Oct 2016 08:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1872) deploy/undeploy archive and
 attachments issue
In-Reply-To: <JIRA.12655476.1476793532000@Atlassian.JIRA>
References: <JIRA.12655476.1476793532000@Atlassian.JIRA>
	<JIRA.12655476.1476793532479@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655476.1476793532000.11083.1476793560376@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-1872:
--------------------------------------------

             Summary: deploy/undeploy archive and attachments issue
                 Key: WFCORE-1872
                 URL: https://issues.jboss.org/browse/WFCORE-1872
             Project: WildFly Core
          Issue Type: Bug
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


When an archive is used to deploy/undeploy, an internal batch is created. All commands/operations located in the CLI archive script file are then added to the batch. The attachments associated to this internal batch are not taken into account. 
When deploy/undeploy archive is executed, these attachments should be added to the executed operation.
When deploy/undeploy archive are added to a batch, the files attached by commands/operations located in the CLI script should be attached to the parent batch.

I also noticed that deploy <file> called in a batch context doesn't make use of attachment. It reads the file content and inline it in the request content. This does create a duplication of logic (execution and batch are handled differently). 

NB: Fixing this issue in current WildFly CLI would be quite complex. It has been fixed in the CLI.next project. Files are now all the time attached, deploy/undeploy archive attachments are properly handled.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 08:35:01 2016
From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Kalman_=28JIRA=29?=)
Date: Tue, 18 Oct 2016 08:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.11176.1476794101010@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308581#comment-13308581 ] 

Ond?ej Kalman edited comment on WFLY-5213 at 10/18/16 8:34 AM:
---------------------------------------------------------------

I checked your client and its fine, on MDB site you have to use @ResourceAdapter(value="remote-artemis")just above "public class MessageConsiumer implements MessageListener ". I think you can safely remove "connectionFactoryLookup"

If you want to use remote broker in all MDBs by default, change "resource-adapter-name" attribute in EJB3 subsystem in your standalone-full.xml


was (Author: okalman):
I checked your client and its fine, on MDB site you have to use @ResourceAdapter(value="remote-artemis")just above "public class MessageConsiumer implements MessageListener ". I think you can safely remove "connectionFactoryLookup"

> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 18 08:51:00 2016
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 18 Oct 2016 08:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1334) Kie service client should
 not allow null parameters
In-Reply-To: <JIRA.12655203.1476693924000@Atlassian.JIRA>
References: <JIRA.12655203.1476693924000@Atlassian.JIRA>
	<JIRA.12655203.1476693924000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655203.1476693924000.11313.1476795060828@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-1334:
-------------------------------------

    Assignee: Maciej Swiderski  (was: Edson Tirelli)


> Kie service client should not allow null parameters
> ---------------------------------------------------
>
>                 Key: DROOLS-1334
>                 URL: https://issues.jboss.org/browse/DROOLS-1334
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.4.0.Final
>            Reporter: Slavomir Krupa
>            Assignee: Maciej Swiderski
>
> This issue occurs when you are using a kie-server-client and want to query i.e. 
> {code:java}
> List<TaskSummary> findTasksByStatusByProcessInstanceId(Long processInstanceId, List<String> status, Integer page, Integer pageSize);
> {code}
> If you don't provide a processInstanceId it creates this URL:
> {noformat}
> http://localhost:8080/kie-server/services/rest/server/queries/tasks/instances/process/%7BpInstanceId%7D?status=Ready&page=0&pageSize=50
> {noformat}
> Result is a exception on the server, but I think it should be validated in a client and should not even query the server:
> {noformat}
> ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (http-127.0.0.1:8080-6) RESTEASY000100: Failed executing GET server/queries/tasks/instances/process/{pInstanceId}: org.jboss.resteasy.spi.BadRequestException: RESTEASY001720: Unable to extract parameter from http request: javax.ws.rs.PathParam("pInstanceId") value is {1} for public javax.ws.rs.core.Response org.kie.server.remote.rest.jbpm.RuntimeDataResource.getTasksByStatusByProcessInstanceId(javax.ws.rs.core.HttpHeaders,java.lang.Long,java.util.List,java.lang.Integer,java.lang.Integer,java.lang.String,boolean)
> 	at org.jboss.resteasy.core.StringParameterInjector.extractValue(StringParameterInjector.java:310) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.core.PathParamInjector.inject(PathParamInjector.java:117) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:137) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:160) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:560) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:130) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.10.Final-redhat-2.jar:7.5.10.Final-redhat-2]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.17.Final-redhat-1.jar:7.5.17.Final-redhat-1]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: java.lang.reflect.InvocationTargetException
> 	at sun.reflect.GeneratedConstructorAccessor154.newInstance(Unknown Source) [:1.8.0_65]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_65]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_65]
> 	at org.jboss.resteasy.core.StringParameterInjector.extractValue(StringParameterInjector.java:298) [resteasy-jaxrs-2.3.15.Final-redhat-1.jar:]
> 	... 28 more
> Caused by: java.lang.NumberFormatException: For input string: "{pInstanceId}"
> 	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_65]
> 	at java.lang.Long.parseLong(Long.java:589) [rt.jar:1.8.0_65]
> 	at java.lang.Long.<init>(Long.java:965) [rt.jar:1.8.0_65]
> 	... 32 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 08:56:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 18 Oct 2016 08:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.11434.1476795360877@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6476 to WFLY-7334:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7334  (was: JBEAP-6476)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Critical
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:01:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Oct 2016 09:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1672) Shared memory to send message
 between different processes on the same box
In-Reply-To: <JIRA.12498055.1375790267000@Atlassian.JIRA>
References: <JIRA.12498055.1375790267000@Atlassian.JIRA>
	<JIRA.12498055.1375790267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498055.1375790267000.11500.1476795660803@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308639#comment-13308639 ] 

Bela Ban commented on JGRP-1672:
--------------------------------

Any design of shared memory for exchanging must be faster than using an multicast (UDP) or N-1 unicasts (TCP). If this is not the case, we can scrap this issue.

Here's a possible design:

* Each sender (producer) sends a message that's to be received by all receivers (consumers) in the same cluster on the same box
* MPMC (multiple producers multiple consumers)
* Use a memory mapped file (or a direct ByteBuffer). I don't want to use Unsafe at this point, I'd rather wait and see what the replacement to it will be.
* A ring buffer is implemented in shared memory.
* There's a write pointer (WP) and a read pointer (RP)
* Producers advance the WP
* Consumers (essentially processes in the same cluster on the same box) register by adding their own TRP (thread read pointer) to shared memory (location TBD)
* A consumer reads messages by advancing their TRP until they hit the WP
* We know what the highest value for the RP will be by taking the min of all TRPs
* The RP is advanced as follows:
** The first writer to hit the RP advances the RP by setting it to the min of all TRPs

h4. Exclusive access and visibility
Producers need to make sure only one at a time advances the WP/RP and read/write from/to those values needs proper visibility, so other producers / consumers see the changes. Investigate if volatile read/writes can be used.

Investigate if \[1\] can be used as an MPSC queue.

\[1\] http://psy-lob-saw.blogspot.ch/

> Shared memory to send message between different processes on the same box
> -------------------------------------------------------------------------
>
>                 Key: JGRP-1672
>                 URL: https://issues.jboss.org/browse/JGRP-1672
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.1
>
>         Attachments: ShmTest.java
>
>
> Investigate whether it makes sense to use shared memory to pass messages between processes on the same box. Say if we have A, B and C on box-1 and X, Y, Z on box-2, when A multicasts a message, it could loop it back to itself, place it into shared memory for B and C to read and multicast it to X, Y, Z. The multicast socket could be non-loopback, so box-1 would not receive it.
> Problems:
> * Shared memory in Java can only be done via memory mapped (sequential or random access) files. To pass a lot of messages, something like a ring buffer would have to be created in shared memory
> * Unless we use FileLock, or polling/busy reading, there is no way to know when a producer has written a message into shared memory. We'd therefore have to use a signalling mechanism, probably a small JGroups message, to notify the consumer(s) of new messages.
> ** Alternatively, we could do busy waiting: the producer writes into a memory location when a message is ready to be consumed. Perhaps this memory location can be the number of messages ready to be read. The consumer could busy-wait, and decrement the number of messages read. This variable could be protected by a file lock, so after some amount of busy-waiting, the consumer could go back and do a real wait on the file lock, instead of burning CPU doing busy-waits.
> * For multicast messages, we'd have 1 producer but many consumers. A RingBuffer would not work here, as we don't know when all consumers have read a given message, ie. when to advance the read pointer
> ** As an alternative, we could have one shared memory buffer per member on the same host. This would also cater to unicast messages. However, then we'd use up a lot of memory.
> * How would this work for TCP ? We'd have to send the message to only members which are outside the local box. How do we identify those members ?
> * Message reception: a multicast message received and targetted to all members on the same box could also be placed into shared memory, so everyone on the same box receives it
> ** How would this work for TCP ? E.g. A sending a multicast message M would use shared memory to deliver M to B and C on box-1, but if it sends it to X, Y and Z, then that's unneeded work, as it could send it only to X, which could place it into shared memory for Y and Z to consume M.
> *** We'd have to include the knowledge of 'affinity' into an address



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:05:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 18 Oct 2016 09:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7332) Infinispan transformation
 tests fail on backups resource for EAP 7.0.0
In-Reply-To: <JIRA.12655436.1476785722000@Atlassian.JIRA>
References: <JIRA.12655436.1476785722000@Atlassian.JIRA>
	<JIRA.12655436.1476785722000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655436.1476785722000.11576.1476795900601@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308651#comment-13308651 ] 

Radoslav Husar commented on WFLY-7332:
--------------------------------------

I wonder if this wasn't introduced as side effect of https://github.com/wildfly/wildfly/pull/8432

> Infinispan transformation tests fail on backups resource for EAP 7.0.0
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7332
>                 URL: https://issues.jboss.org/browse/WFLY-7332
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> {noformat}
> Failed tests:
>   TransformersTestCase.testTransformerEAP700:162->testTransformation:191->AbstractSubsystemTest.checkSubsystemModelTransformation:292 cache-container/maximal/distributed-cache/dist/component/: {
>     "expiration" => {
>         "interval" => 10000L,
>         "lifespan" => 10L,
>         "max-idle" => 10L
>     },
>     "state-transfer" => {
>         "chunk-size" => 10000,
>         "enabled" => undefined,
>         "timeout" => 60000L
>     },
>     "eviction" => {
>         "max-entries" => 20000L,
>         "strategy" => "UNORDERED"
>     },
>     "locking" => {
>         "acquire-timeout" => 30000L,
>         "concurrency-level" => 2000,
>         "isolation" => "READ_COMMITTED",
>         "striping" => true
>     },
>     "backups" => {},
>     "transaction" => {
>         "locking" => "OPTIMISTIC",
>         "mode" => "FULL_XA",
>         "stop-timeout" => 60000L
>     },
>     "backup-for" => {},
>     "partition-handling" => {}
> }
> {
>     "expiration" => {
>         "max-idle" => 10L,
>         "lifespan" => 10L,
>         "interval" => 10000L
>     },
>     "state-transfer" => {
>         "chunk-size" => 10000,
>         "timeout" => 60000L,
>         "enabled" => undefined
>     },
>     "eviction" => {
>         "max-entries" => 20000L,
>         "strategy" => "UNORDERED"
>     },
>     "locking" => {
>         "striping" => true,
>         "isolation" => "READ_COMMITTED",
>         "acquire-timeout" => 30000L,
>         "concurrency-level" => 2000
>     },
>     "backups" => undefined,
>     "transaction" => {
>         "mode" => "FULL_XA",
>         "locking" => "OPTIMISTIC",
>         "stop-timeout" => 60000L
>     },
>     "backup-for" => {},
>     "partition-handling" => {}
> } expected:<[backup-for, [backups, ]eviction, expiration...> but was:<[backup-for, []eviction, expiration...>
> Tests run: 108, Failures: 1, Errors: 0, Skipped: 19
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:06:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 18 Oct 2016 09:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7335) Add EAP 7.0.0 transformers
 tests for jgroups subsystem
In-Reply-To: <JIRA.12655489.1476795907000@Atlassian.JIRA>
References: <JIRA.12655489.1476795907000@Atlassian.JIRA>
	<JIRA.12655489.1476795907625@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655489.1476795907000.11582.1476795960872@Atlassian.JIRA>

Radoslav Husar created WFLY-7335:
------------------------------------

             Summary: Add EAP 7.0.0 transformers tests for jgroups subsystem
                 Key: WFLY-7335
                 URL: https://issues.jboss.org/browse/WFLY-7335
             Project: WildFly
          Issue Type: Task
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


Needs to be added before any elytron integration work.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:09:01 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 18 Oct 2016 09:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-592) Add SecurityIdentity
 serialization/caching support to Elytron
In-Reply-To: <JIRA.12640158.1469120501000@Atlassian.JIRA>
References: <JIRA.12640158.1469120501000@Atlassian.JIRA>
	<JIRA.12640158.1469120501000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640158.1469120501000.11644.1476796141119@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated ELY-592:
----------------------------
    Summary: Add SecurityIdentity serialization/caching support to Elytron  (was: Add caching support to Elytron)


> Add SecurityIdentity serialization/caching support to Elytron
> -------------------------------------------------------------
>
>                 Key: ELY-592
>                 URL: https://issues.jboss.org/browse/ELY-592
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.1.0.Beta6
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:09:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 18 Oct 2016 09:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7336) Add EAP 7.0.0 transformers
 tests for infinispan subsystem
In-Reply-To: <JIRA.12655491.1476796113000@Atlassian.JIRA>
References: <JIRA.12655491.1476796113000@Atlassian.JIRA>
	<JIRA.12655491.1476796113306@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655491.1476796113000.11648.1476796141217@Atlassian.JIRA>

Radoslav Husar created WFLY-7336:
------------------------------------

             Summary: Add EAP 7.0.0 transformers tests for infinispan subsystem
                 Key: WFLY-7336
                 URL: https://issues.jboss.org/browse/WFLY-7336
             Project: WildFly
          Issue Type: Task
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


Needs to be added before any elytron integration work.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:11:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 18 Oct 2016 09:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1873) TEST
In-Reply-To: <JIRA.12655492.1476796208000@Atlassian.JIRA>
References: <JIRA.12655492.1476796208000@Atlassian.JIRA>
	<JIRA.12655492.1476796208105@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655492.1476796208000.11670.1476796260704@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-1873:
--------------------------------------------

             Summary: TEST
                 Key: WFCORE-1873
                 URL: https://issues.jboss.org/browse/WFCORE-1873
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:11:01 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 18 Oct 2016 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1873) TEST
In-Reply-To: <JIRA.12655492.1476796208000@Atlassian.JIRA>
References: <JIRA.12655492.1476796208000@Atlassian.JIRA>
	<JIRA.12655492.1476796208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655492.1476796208000.11694.1476796261857@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise closed WFCORE-1873.
----------------------------------------
    Resolution: Done


> TEST
> ----
>
>                 Key: WFCORE-1873
>                 URL: https://issues.jboss.org/browse/WFCORE-1873
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:13:02 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 09:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7306) Empty result of password
 search in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654658.1476358891000@Atlassian.JIRA>
References: <JIRA.12654658.1476358891000@Atlassian.JIRA>
	<JIRA.12654658.1476358891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654658.1476358891000.11753.1476796382708@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7306:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Empty result of password search in Elytron ldap-realm causes NPE
> ----------------------------------------------------------------
>
>                 Key: WFLY-7306
>                 URL: https://issues.jboss.org/browse/WFLY-7306
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> In case when Elytron ldap-realm is configured to return some attribute as password (i.e. direct verification is set to false) and LDAP search does not find this attribute, then NPE occurs.
> It is caused by missing null check for {{attribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.getCredential(UserPasswordCredentialLoader.java:130)
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.verifyEvidence(UserPasswordCredentialLoader.java:151)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:531)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/UserPasswordCredentialLoader.java#L129



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:15:07 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 09:15:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-673) Empty result of password search
 in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654658.1476358891000@Atlassian.JIRA>
References: <JIRA.12654658.1476358891000@Atlassian.JIRA>
	<JIRA.12654658.1476358891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654658.1476358891000.11855.1476796507442@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7306 to ELY-673:
--------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-673  (was: WFLY-7306)
          Component/s: Realms
                           (was: Security)
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Empty result of password search in Elytron ldap-realm causes NPE
> ----------------------------------------------------------------
>
>                 Key: ELY-673
>                 URL: https://issues.jboss.org/browse/ELY-673
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> In case when Elytron ldap-realm is configured to return some attribute as password (i.e. direct verification is set to false) and LDAP search does not find this attribute, then NPE occurs.
> It is caused by missing null check for {{attribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.getCredential(UserPasswordCredentialLoader.java:130)
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.verifyEvidence(UserPasswordCredentialLoader.java:151)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:531)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/UserPasswordCredentialLoader.java#L129



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:20:01 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 18 Oct 2016 09:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-673) Empty result of password search
 in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654658.1476358891000@Atlassian.JIRA>
References: <JIRA.12654658.1476358891000@Atlassian.JIRA>
	<JIRA.12654658.1476358891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654658.1476358891000.11946.1476796801548@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308676#comment-13308676 ] 

Ilia Vassilev commented on ELY-673:
-----------------------------------

@Jan Kalina: I was about to submit PR for this issue. Do you want me to submit it? 

> Empty result of password search in Elytron ldap-realm causes NPE
> ----------------------------------------------------------------
>
>                 Key: ELY-673
>                 URL: https://issues.jboss.org/browse/ELY-673
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> In case when Elytron ldap-realm is configured to return some attribute as password (i.e. direct verification is set to false) and LDAP search does not find this attribute, then NPE occurs.
> It is caused by missing null check for {{attribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.getCredential(UserPasswordCredentialLoader.java:130)
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.verifyEvidence(UserPasswordCredentialLoader.java:151)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:531)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/UserPasswordCredentialLoader.java#L129



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:23:02 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Tue, 18 Oct 2016 09:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7337) Introduce an authorization SPI
In-Reply-To: <JIRA.12654377.1476268211000@Atlassian.JIRA>
References: <JIRA.12654377.1476268211000@Atlassian.JIRA>
	<JIRA.12654377.1476268211000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654377.1476268211000.12018.1476796982251@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson moved JBTM-2772 to WFLY-7337:
-------------------------------------------

        Project: WildFly  (was: JBoss Transaction Manager)
            Key: WFLY-7337  (was: JBTM-2772)
    Component/s: Transactions
                     (was: Application Server Integration)
                     (was: SPI)


> Introduce an authorization SPI
> ------------------------------
>
>                 Key: WFLY-7337
>                 URL: https://issues.jboss.org/browse/WFLY-7337
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Transactions
>            Reporter: David Lloyd
>            Assignee: Amos Feng
>
> We need an SPI that can be invoked to authorize state changes in a transaction.  The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change.
> It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager.
> The operations that should provide authorization checks include, but are not limited to:
> * begin
> * rollback
> * prepare
> * forget
> * commit (one or two phase)
> * recover
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:32:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 18 Oct 2016 09:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-524) RealmIdentity data caching
 support in the LDAP realm
In-Reply-To: <JIRA.12618201.1462379575000@Atlassian.JIRA>
References: <JIRA.12618201.1462379575000@Atlassian.JIRA>
	<JIRA.12618201.1462379575000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618201.1462379575000.12272.1476797520917@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated ELY-524:
----------------------------
    Summary: RealmIdentity data caching support in the LDAP realm  (was: Caching support in the LDAP realm)


> RealmIdentity data caching support in the LDAP realm
> ----------------------------------------------------
>
>                 Key: ELY-524
>                 URL: https://issues.jboss.org/browse/ELY-524
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Realms
>            Reporter: David Lloyd
>            Assignee: Pedro Igor
>            Priority: Critical
>             Fix For: 1.1.0.Beta12
>
>
> The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic.
> The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these.  Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention.
> For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes.
> Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name.
> This is a complex design topic so discussion is welcome.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:33:00 2016
From: issues at jboss.org (Patrick Kleindienst (JIRA))
Date: Tue, 18 Oct 2016 09:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7338) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797523000@Atlassian.JIRA>
References: <JIRA.12655496.1476797523000@Atlassian.JIRA>
	<JIRA.12655496.1476797523586@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797523000.12277.1476797580573@Atlassian.JIRA>

Patrick Kleindienst created WFLY-7338:
-----------------------------------------

             Summary: Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
                 Key: WFLY-7338
                 URL: https://issues.jboss.org/browse/WFLY-7338
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 10.1.0.Final, 10.0.0.Final
            Reporter: Patrick Kleindienst
            Assignee: Jason Greene


I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:

{code:java}
LogManager error of type FLUSH_FAILURE: Error on flush
java.net.SocketException: Socket is closed
	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
	at org.jboss.logmanager.Logger.log(Logger.java:596)
	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
	at java.io.PrintStream.write(PrintStream.java:482)
	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
	at java.io.PrintStream.write(PrintStream.java:480)
	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
	at java.io.PrintStream.newLine(PrintStream.java:546)
	at java.io.PrintStream.println(PrintStream.java:696)
	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
	at org.jboss.logmanager.Logger.log(Logger.java:802)
	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
	at org.jboss.logging.Logger.logf(Logger.java:2398)
	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
{code}
    
On the Logstash side, the following error message appears in the logs:
{code}
:message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
{code}

Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:

* *** ClientHello, TLSv1.2
* *** ServerHello, TLSv1.2
* %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
* Found trusted certificate
* *** ECDH ServerKeyExchange
* *** ServerHelloDone
* *** ECDHClientKeyExchange
* SESSION KEYGEN:
* CONNECTION KEYGEN:
* *** Finished
   
When disabling SSL both on WildFly and Logstash side, everything works fine.







--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:34:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 09:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-673) Empty result of password search
 in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654658.1476358891000@Atlassian.JIRA>
References: <JIRA.12654658.1476358891000@Atlassian.JIRA>
	<JIRA.12654658.1476358891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654658.1476358891000.12315.1476797640862@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13308705#comment-13308705 ] 

Jan Kalina commented on ELY-673:
--------------------------------

no problem, if you are already working on it, I will assign it to you

> Empty result of password search in Elytron ldap-realm causes NPE
> ----------------------------------------------------------------
>
>                 Key: ELY-673
>                 URL: https://issues.jboss.org/browse/ELY-673
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> In case when Elytron ldap-realm is configured to return some attribute as password (i.e. direct verification is set to false) and LDAP search does not find this attribute, then NPE occurs.
> It is caused by missing null check for {{attribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.getCredential(UserPasswordCredentialLoader.java:130)
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.verifyEvidence(UserPasswordCredentialLoader.java:151)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:531)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/UserPasswordCredentialLoader.java#L129



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:35:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 09:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-673) Empty result of password search
 in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654658.1476358891000@Atlassian.JIRA>
References: <JIRA.12654658.1476358891000@Atlassian.JIRA>
	<JIRA.12654658.1476358891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654658.1476358891000.12322.1476797700558@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-673:
------------------------------

    Assignee: Ilia Vassilev  (was: Jan Kalina)


> Empty result of password search in Elytron ldap-realm causes NPE
> ----------------------------------------------------------------
>
>                 Key: ELY-673
>                 URL: https://issues.jboss.org/browse/ELY-673
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>
> In case when Elytron ldap-realm is configured to return some attribute as password (i.e. direct verification is set to false) and LDAP search does not find this attribute, then NPE occurs.
> It is caused by missing null check for {{attribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.getCredential(UserPasswordCredentialLoader.java:130)
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.verifyEvidence(UserPasswordCredentialLoader.java:151)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:531)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/UserPasswordCredentialLoader.java#L129



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:35:01 2016
From: issues at jboss.org (Patrick Kleindienst (JIRA))
Date: Tue, 18 Oct 2016 09:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7338) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.12335.1476797701458@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Kleindienst updated WFLY-7338:
--------------------------------------
    Steps to Reproduce: 
# Created self-signed Logstash cert with OpenSSL:
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
# Added truststore path as well as password to VM options:
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)

  was:
# Created self-signed Logstash cert with OpenSSL:
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365

# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}

# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 

# Added jboss-logmanager-ext to modules

# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>

# Added truststore path as well as password to VM options:
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"

# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)



> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7338
>                 URL: https://issues.jboss.org/browse/WFLY-7338
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Patrick Kleindienst
>            Assignee: Jason Greene
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:38:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 18 Oct 2016 09:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7338) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.12389.1476797880889@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-7338:
---------------------------------

    Assignee: James Perkins  (was: Jason Greene)


> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7338
>                 URL: https://issues.jboss.org/browse/WFLY-7338
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:46:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Tue, 18 Oct 2016 09:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7339) Add an option to delete
 messages from a jms queue.
In-Reply-To: <JIRA.12655501.1476798355000@Atlassian.JIRA>
References: <JIRA.12655501.1476798355000@Atlassian.JIRA>
	<JIRA.12655501.1476798355939@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655501.1476798355000.12511.1476798360953@Atlassian.JIRA>

Filippe Spolti created WFLY-7339:
------------------------------------

             Summary: Add an option to delete messages from a jms queue.
                 Key: WFLY-7339
                 URL: https://issues.jboss.org/browse/WFLY-7339
             Project: WildFly
          Issue Type: Enhancement
          Components: JMS
    Affects Versions: 10.1.0.Final
            Reporter: Filippe Spolti
            Assignee: Jeff Mesnil
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:47:01 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Tue, 18 Oct 2016 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7339) Add an option to delete
 messages from a jms queue.
In-Reply-To: <JIRA.12655501.1476798356000@Atlassian.JIRA>
References: <JIRA.12655501.1476798356000@Atlassian.JIRA>
	<JIRA.12655501.1476798356000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655501.1476798356000.12530.1476798421585@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti updated WFLY-7339:
---------------------------------
    Description: Actually there is no way to do this on admin console, only through CLI.


> Add an option to delete messages from a jms queue.
> --------------------------------------------------
>
>                 Key: WFLY-7339
>                 URL: https://issues.jboss.org/browse/WFLY-7339
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Filippe Spolti
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> Actually there is no way to do this on admin console, only through CLI.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:49:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 18 Oct 2016 09:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7340) Unable to configure
 Krb5LoginModule options in elytron kerberos implementation
In-Reply-To: <JIRA.12655504.1476798477000@Atlassian.JIRA>
References: <JIRA.12655504.1476798477000@Atlassian.JIRA>
	<JIRA.12655504.1476798477000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655504.1476798477000.12592.1476798540640@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6481 to WFLY-7340:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7340  (was: JBEAP-6481)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Unable to configure Krb5LoginModule options in elytron kerberos implementation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7340
>                 URL: https://issues.jboss.org/browse/WFLY-7340
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Blocker
>
> Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module
> {code:java}
>             if (debug) {
>                 options.put("debug", "true");
>             }
>             options.put("principal", principal);
>             final AppConfigurationEntry ace;
>             if (IS_IBM) {
>                 options.put("noAddress", "true");
>                 options.put("credsType", isServer ? "acceptor" : "initiator");
>                 options.put("useKeytab", keyTab.toURI().toURL().toString());
>                 ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
>             } else {
>                 options.put("storeKey", "true");
>                 options.put("useKeyTab", "true");
>                 options.put("keyTab", keyTab.getAbsolutePath());
>                 options.put("isInitiator", isServer ? "false" : "true");
>                 ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
>             }
> {code}
> * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
> * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:50:01 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Tue, 18 Oct 2016 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7339) Add an option to delete
 messages from a jms queue.
In-Reply-To: <JIRA.12655501.1476798356000@Atlassian.JIRA>
References: <JIRA.12655501.1476798356000@Atlassian.JIRA>
	<JIRA.12655501.1476798356000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655501.1476798356000.12621.1476798601242@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti updated WFLY-7339:
---------------------------------
    Component/s: Web Console
                     (was: JMS)


> Add an option to delete messages from a jms queue.
> --------------------------------------------------
>
>                 Key: WFLY-7339
>                 URL: https://issues.jboss.org/browse/WFLY-7339
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Console
>    Affects Versions: 10.1.0.Final
>            Reporter: Filippe Spolti
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> Actually there is no way to do this on admin console, only through CLI.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 09:53:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Tue, 18 Oct 2016 09:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7339) Add an option to delete
 messages from a jms queue.
In-Reply-To: <JIRA.12655501.1476798356000@Atlassian.JIRA>
References: <JIRA.12655501.1476798356000@Atlassian.JIRA>
	<JIRA.12655501.1476798356000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655501.1476798356000.12653.1476798780589@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFLY-7339:
--------------------------------

    Assignee: Harald Pehl  (was: Jeff Mesnil)


> Add an option to delete messages from a jms queue.
> --------------------------------------------------
>
>                 Key: WFLY-7339
>                 URL: https://issues.jboss.org/browse/WFLY-7339
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Console
>    Affects Versions: 10.1.0.Final
>            Reporter: Filippe Spolti
>            Assignee: Harald Pehl
>            Priority: Minor
>
> Actually there is no way to do this on admin console, only through CLI.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 10:08:00 2016
From: issues at jboss.org (Patrick Kleindienst (JIRA))
Date: Tue, 18 Oct 2016 10:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7338) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.12780.1476799680304@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Kleindienst updated WFLY-7338:
--------------------------------------
    Steps to Reproduce: 
# Created self-signed Logstash cert with OpenSSL:
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)

  was:
# Created self-signed Logstash cert with OpenSSL:
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
# Added truststore path as well as password to VM options:
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)



> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7338
>                 URL: https://issues.jboss.org/browse/WFLY-7338
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 10:09:01 2016
From: issues at jboss.org (Patrick Kleindienst (JIRA))
Date: Tue, 18 Oct 2016 10:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7338) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.12806.1476799741540@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Kleindienst updated WFLY-7338:
--------------------------------------
    Steps to Reproduce: 
# Created self-signed Logstash cert with OpenSSL:
{code}
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)

  was:
# Created self-signed Logstash cert with OpenSSL:
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)



> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7338
>                 URL: https://issues.jboss.org/browse/WFLY-7338
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 10:09:01 2016
From: issues at jboss.org (Patrick Kleindienst (JIRA))
Date: Tue, 18 Oct 2016 10:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7338) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.12813.1476799741744@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Kleindienst updated WFLY-7338:
--------------------------------------
    Steps to Reproduce: 
# Created self-signed Logstash cert with OpenSSL:
{code}
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)

  was:
# Created self-signed Logstash cert with OpenSSL:
{code}
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)



> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7338
>                 URL: https://issues.jboss.org/browse/WFLY-7338
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 10:10:00 2016
From: issues at jboss.org (Patrick Kleindienst (JIRA))
Date: Tue, 18 Oct 2016 10:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7338) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.12818.1476799800765@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Kleindienst updated WFLY-7338:
--------------------------------------
    Steps to Reproduce: 

# Created self-signed Logstash cert with OpenSSL:
{code}
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)

  was:
# Created self-signed Logstash cert with OpenSSL:
{code}
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)



> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7338
>                 URL: https://issues.jboss.org/browse/WFLY-7338
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 10:26:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 10:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7340) Unable to configure
 Krb5LoginModule options in elytron kerberos implementation
In-Reply-To: <JIRA.12655504.1476798477000@Atlassian.JIRA>
References: <JIRA.12655504.1476798477000@Atlassian.JIRA>
	<JIRA.12655504.1476798477000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655504.1476798477000.13017.1476800760644@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7340:
--------------------------------

    Assignee: Jan Kalina


> Unable to configure Krb5LoginModule options in elytron kerberos implementation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7340
>                 URL: https://issues.jboss.org/browse/WFLY-7340
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module
> {code:java}
>             if (debug) {
>                 options.put("debug", "true");
>             }
>             options.put("principal", principal);
>             final AppConfigurationEntry ace;
>             if (IS_IBM) {
>                 options.put("noAddress", "true");
>                 options.put("credsType", isServer ? "acceptor" : "initiator");
>                 options.put("useKeytab", keyTab.toURI().toURL().toString());
>                 ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
>             } else {
>                 options.put("storeKey", "true");
>                 options.put("useKeyTab", "true");
>                 options.put("keyTab", keyTab.getAbsolutePath());
>                 options.put("isInitiator", isServer ? "false" : "true");
>                 ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
>             }
> {code}
> * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
> * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 10:34:01 2016
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Tue, 18 Oct 2016 10:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6942) Add a forget operation to the
 transaction subsystem tooling
In-Reply-To: <JIRA.12642921.1470911576000@Atlassian.JIRA>
References: <JIRA.12642921.1470911576000@Atlassian.JIRA>
	<JIRA.12642921.1470911576000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642921.1470911576000.13082.1476801241107@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove reopened WFLY-6942:
------------------------------------


The CLI tooling is missing the delete operation so I am reopening the JIRA to get it added.

> Add a forget operation to the transaction subsystem tooling
> -----------------------------------------------------------
>
>                 Key: WFLY-6942
>                 URL: https://issues.jboss.org/browse/WFLY-6942
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>             Fix For: 11.0.0.Alpha1
>
>
> The CLI tooling provides two features for dealing with heuristic participants:
> * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed;
> * a delete operation if the admin thinks it safe to do so;
> In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 10:35:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Oct 2016 10:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2115) MERGE3: InfoSender takes too
 long to be stopped
In-Reply-To: <JIRA.12655517.1476801241000@Atlassian.JIRA>
References: <JIRA.12655517.1476801241000@Atlassian.JIRA>
	<JIRA.12655517.1476801241679@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655517.1476801241000.13085.1476801300841@Atlassian.JIRA>

Bela Ban created JGRP-2115:
------------------------------

             Summary: MERGE3: InfoSender takes too long to be stopped
                 Key: JGRP-2115
                 URL: https://issues.jboss.org/browse/JGRP-2115
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 4.0


When an InfoSender task is running in MERGE3, it blocks until it has all responses from the discovery protocol. This time can be a few seconds, and this is delaying the shutdown process.

Add a method that stops the InfoSender task immediately, e.g. by calling Responses.done() directly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 11:02:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 11:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7340) Unable to configure
 Krb5LoginModule options in elytron kerberos implementation
In-Reply-To: <JIRA.12655504.1476798477000@Atlassian.JIRA>
References: <JIRA.12655504.1476798477000@Atlassian.JIRA>
	<JIRA.12655504.1476798477000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655504.1476798477000.13463.1476802921980@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7340:
-----------------------------
    Description: 
Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module

{code:java}
            if (debug) {
                options.put("debug", "true");
            }
            options.put("principal", principal);

            final AppConfigurationEntry ace;
            if (IS_IBM) {
                options.put("noAddress", "true");
                options.put("credsType", isServer ? "acceptor" : "initiator");
                options.put("useKeytab", keyTab.toURI().toURL().toString());
                ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
            } else {
                options.put("storeKey", "true");
                options.put("useKeyTab", "true");
                options.put("keyTab", keyTab.getAbsolutePath());
                options.put("isInitiator", isServer ? "false" : "true");

                ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
            }
{code}
^ GSSCredentialSecurityFactory

* http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
* https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html

  was:
Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module

{code:java}
            if (debug) {
                options.put("debug", "true");
            }
            options.put("principal", principal);

            final AppConfigurationEntry ace;
            if (IS_IBM) {
                options.put("noAddress", "true");
                options.put("credsType", isServer ? "acceptor" : "initiator");
                options.put("useKeytab", keyTab.toURI().toURL().toString());
                ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
            } else {
                options.put("storeKey", "true");
                options.put("useKeyTab", "true");
                options.put("keyTab", keyTab.getAbsolutePath());
                options.put("isInitiator", isServer ? "false" : "true");

                ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
            }
{code}

* http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
* https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html



> Unable to configure Krb5LoginModule options in elytron kerberos implementation
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7340
>                 URL: https://issues.jboss.org/browse/WFLY-7340
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module
> {code:java}
>             if (debug) {
>                 options.put("debug", "true");
>             }
>             options.put("principal", principal);
>             final AppConfigurationEntry ace;
>             if (IS_IBM) {
>                 options.put("noAddress", "true");
>                 options.put("credsType", isServer ? "acceptor" : "initiator");
>                 options.put("useKeytab", keyTab.toURI().toURL().toString());
>                 ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
>             } else {
>                 options.put("storeKey", "true");
>                 options.put("useKeyTab", "true");
>                 options.put("keyTab", keyTab.getAbsolutePath());
>                 options.put("isInitiator", isServer ? "false" : "true");
>                 ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
>             }
> {code}
> ^ GSSCredentialSecurityFactory
> * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
> * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 11:24:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 11:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.13610.1476804240288@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7334:
--------------------------------

    Assignee: Jan Kalina


> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 11:42:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 18 Oct 2016 11:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7332) Infinispan transformation
 tests fail on 'backups' resource for EAP 7.0.0
In-Reply-To: <JIRA.12655436.1476785722000@Atlassian.JIRA>
References: <JIRA.12655436.1476785722000@Atlassian.JIRA>
	<JIRA.12655436.1476785722000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655436.1476785722000.13762.1476805320192@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7332:
---------------------------------
    Summary: Infinispan transformation tests fail on 'backups' resource for EAP 7.0.0  (was: Infinispan transformation tests fail on backups resource for EAP 7.0.0)


> Infinispan transformation tests fail on 'backups' resource for EAP 7.0.0
> ------------------------------------------------------------------------
>
>                 Key: WFLY-7332
>                 URL: https://issues.jboss.org/browse/WFLY-7332
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> {noformat}
> Failed tests:
>   TransformersTestCase.testTransformerEAP700:162->testTransformation:191->AbstractSubsystemTest.checkSubsystemModelTransformation:292 cache-container/maximal/distributed-cache/dist/component/: {
>     "expiration" => {
>         "interval" => 10000L,
>         "lifespan" => 10L,
>         "max-idle" => 10L
>     },
>     "state-transfer" => {
>         "chunk-size" => 10000,
>         "enabled" => undefined,
>         "timeout" => 60000L
>     },
>     "eviction" => {
>         "max-entries" => 20000L,
>         "strategy" => "UNORDERED"
>     },
>     "locking" => {
>         "acquire-timeout" => 30000L,
>         "concurrency-level" => 2000,
>         "isolation" => "READ_COMMITTED",
>         "striping" => true
>     },
>     "backups" => {},
>     "transaction" => {
>         "locking" => "OPTIMISTIC",
>         "mode" => "FULL_XA",
>         "stop-timeout" => 60000L
>     },
>     "backup-for" => {},
>     "partition-handling" => {}
> }
> {
>     "expiration" => {
>         "max-idle" => 10L,
>         "lifespan" => 10L,
>         "interval" => 10000L
>     },
>     "state-transfer" => {
>         "chunk-size" => 10000,
>         "timeout" => 60000L,
>         "enabled" => undefined
>     },
>     "eviction" => {
>         "max-entries" => 20000L,
>         "strategy" => "UNORDERED"
>     },
>     "locking" => {
>         "striping" => true,
>         "isolation" => "READ_COMMITTED",
>         "acquire-timeout" => 30000L,
>         "concurrency-level" => 2000
>     },
>     "backups" => undefined,
>     "transaction" => {
>         "mode" => "FULL_XA",
>         "locking" => "OPTIMISTIC",
>         "stop-timeout" => 60000L
>     },
>     "backup-for" => {},
>     "partition-handling" => {}
> } expected:<[backup-for, [backups, ]eviction, expiration...> but was:<[backup-for, []eviction, expiration...>
> Tests run: 108, Failures: 1, Errors: 0, Skipped: 19
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 12:13:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Oct 2016 12:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2116) MPING: restart doesn't work
In-Reply-To: <JIRA.12655544.1476807162000@Atlassian.JIRA>
References: <JIRA.12655544.1476807162000@Atlassian.JIRA>
	<JIRA.12655544.1476807162097@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655544.1476807162000.13874.1476807180156@Atlassian.JIRA>

Bela Ban created JGRP-2116:
------------------------------

             Summary: MPING: restart doesn't work
                 Key: JGRP-2116
                 URL: https://issues.jboss.org/browse/JGRP-2116
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0


MPING in a TCP stack doesn't pass a connect-disconnect-connect cycle, but the 2nd connect has 10 failed JOIN requests and then becomes a singleton



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 12:14:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Oct 2016 12:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2116) MPING: restart doesn't work
In-Reply-To: <JIRA.12655544.1476807162000@Atlassian.JIRA>
References: <JIRA.12655544.1476807162000@Atlassian.JIRA>
	<JIRA.12655544.1476807162000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655544.1476807162000.13876.1476807240108@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2116:
---------------------------
    Attachment: tcp.xml
                bla.java


> MPING: restart doesn't work
> ---------------------------
>
>                 Key: JGRP-2116
>                 URL: https://issues.jboss.org/browse/JGRP-2116
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>         Attachments: bla.java, tcp.xml
>
>
> MPING in a TCP stack doesn't pass a connect-disconnect-connect cycle, but the 2nd connect has 10 failed JOIN requests and then becomes a singleton



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 12:17:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 12:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7341) Unable to configure
 Krb5LoginModule options in elytron kerberos implementation
In-Reply-To: <JIRA.12655545.1476807360000@Atlassian.JIRA>
References: <JIRA.12655545.1476807360000@Atlassian.JIRA>
	<JIRA.12655545.1476807360733@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655545.1476807360000.13886.1476807420235@Atlassian.JIRA>

Jan Kalina created WFLY-7341:
--------------------------------

             Summary: Unable to configure Krb5LoginModule options in elytron kerberos implementation
                 Key: WFLY-7341
                 URL: https://issues.jboss.org/browse/WFLY-7341
             Project: WildFly
          Issue Type: Bug
          Components: Security
    Affects Versions: 11.0.0.Alpha1
            Reporter: Jan Kalina
            Assignee: Jan Kalina
            Priority: Blocker


Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module

{code:java}
            if (debug) {
                options.put("debug", "true");
            }
            options.put("principal", principal);

            final AppConfigurationEntry ace;
            if (IS_IBM) {
                options.put("noAddress", "true");
                options.put("credsType", isServer ? "acceptor" : "initiator");
                options.put("useKeytab", keyTab.toURI().toURL().toString());
                ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
            } else {
                options.put("storeKey", "true");
                options.put("useKeyTab", "true");
                options.put("keyTab", keyTab.getAbsolutePath());
                options.put("isInitiator", isServer ? "false" : "true");

                ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
            }
{code}
^ GSSCredentialSecurityFactory

* http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
* https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 12:17:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 18 Oct 2016 12:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-674) Unable to configure
 Krb5LoginModule options in elytron kerberos implementation
In-Reply-To: <JIRA.12655545.1476807361000@Atlassian.JIRA>
References: <JIRA.12655545.1476807361000@Atlassian.JIRA>
	<JIRA.12655545.1476807361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655545.1476807361000.13896.1476807420523@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7341 to ELY-674:
--------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-674  (was: WFLY-7341)
          Component/s: Authentication Mechanisms
                           (was: Security)
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Unable to configure Krb5LoginModule options in elytron kerberos implementation
> ------------------------------------------------------------------------------
>
>                 Key: ELY-674
>                 URL: https://issues.jboss.org/browse/ELY-674
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Mechanisms
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Krb5LoginModule options are not configurable. I mean there are some of them exposed (debug, keytab, acceptor/initiator), but not all. In my opinion, sooner or later customers will hunt us to provide all of them. Because there are various use-cases out there needing to tweak kerberos configuration somehow. Legacy KerberosLoginModule exposed these options https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0/login-module-reference/#kerberos_login_module
> {code:java}
>             if (debug) {
>                 options.put("debug", "true");
>             }
>             options.put("principal", principal);
>             final AppConfigurationEntry ace;
>             if (IS_IBM) {
>                 options.put("noAddress", "true");
>                 options.put("credsType", isServer ? "acceptor" : "initiator");
>                 options.put("useKeytab", keyTab.toURI().toURL().toString());
>                 ace = new AppConfigurationEntry(IBMKRB5LoginModule, REQUIRED, options);
>             } else {
>                 options.put("storeKey", "true");
>                 options.put("useKeyTab", "true");
>                 options.put("keyTab", keyTab.getAbsolutePath());
>                 options.put("isInitiator", isServer ? "false" : "true");
>                 ace = new AppConfigurationEntry(KRB5LoginModule, REQUIRED, options);
>             }
> {code}
> ^ GSSCredentialSecurityFactory
> * http://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
> * https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.api.doc/jgss/com/ibm/security/auth/module/Krb5LoginModule.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 12:36:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 18 Oct 2016 12:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2115) MERGE3: InfoSender takes too
 long to be stopped
In-Reply-To: <JIRA.12655517.1476801242000@Atlassian.JIRA>
References: <JIRA.12655517.1476801242000@Atlassian.JIRA>
	<JIRA.12655517.1476801242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655517.1476801242000.14026.1476808560272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2115.
----------------------------
    Resolution: Done


> MERGE3: InfoSender takes too long to be stopped
> -----------------------------------------------
>
>                 Key: JGRP-2115
>                 URL: https://issues.jboss.org/browse/JGRP-2115
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0
>
>
> When an InfoSender task is running in MERGE3, it blocks until it has all responses from the discovery protocol. This time can be a few seconds, and this is delaying the shutdown process.
> Add a method that stops the InfoSender task immediately, e.g. by calling Responses.done() directly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 14:05:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 18 Oct 2016 14:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5879) Some multinode tests fail
 with security manager
In-Reply-To: <JIRA.12597217.1450441124000@Atlassian.JIRA>
References: <JIRA.12597217.1450441124000@Atlassian.JIRA>
	<JIRA.12597217.1450441124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597217.1450441124000.14210.1476813900412@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-5879:
------------------------------------

    Assignee: Ingo Weiss  (was: Stuart Douglas)


I am pretty sure you can take this one, though on a very quick look it seems that the real fix needs to happen in H2 itself.

> Some multinode tests fail with security manager
> -----------------------------------------------
>
>                 Key: WFLY-5879
>                 URL: https://issues.jboss.org/browse/WFLY-5879
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Test Suite
>            Reporter: Ondrej Kotek
>            Assignee: Ingo Weiss
>             Fix For: 10.2.0.Final
>
>
> *org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase}}
> fails with:
> {noformat}
> javax.naming.NamingException: Failed to create proxy
> 	at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:873)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:222)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:230)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.getStatefulRemote(ClientEjb.java:60)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.testSameTransactionEachCall(ClientEjb.java:77)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb$$$view1.testSameTransactionEachCall(Unknown Source)
> 	at org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSameTransactionEachCall(TransactionInvocationTestCase.java:97)
> {noformat}
> *org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase}}
> fails with:
> {noformat}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-2) Failed: org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances: javax.naming.NameNotFoundException: StatefulBeanA!org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.doLookup(InitialContext.java:290)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances(DynamicJNDIContextEJBInvocationTestCase.java:116)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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)
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
> 	... 145 more
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.distributable.DistributableCache.create(DistributableCache.java:94)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$DefaultViewInstanceFactory.createViewInstance(ViewService.java:302)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> 	... 148 more
> Caused by: javax.naming.NamingException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null") [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null")]
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:137)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA.onConstruct(StatefulBeanA.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:117)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBCreateInterceptor.processInvocation(SFSBCreateInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 164 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at org.jboss.ejb.client.EJBClientContext.create(EJBClientContext.java:198)
> 	at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:90)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:256)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
> 	at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:133)
> 	... 223 more
> {noformat}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> fails with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy62.remoteCall(Unknown Source)
> 	at org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote(RemoteLocalCallProfileTestCase.java:185)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
> 	at java.lang.Class.getClassLoader(Class.java:683)
> 	at org.jboss.marshalling.reflect.SerializableClassRegistry.lookup(SerializableClassRegistry.java:70)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:916)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1255)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> 	at org.jboss.ejb.client.remoting.SessionOpenResponseHandler$SessionIDResultProducer.getResult(SessionOpenResponseHandler.java:94)
> 	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:454)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:227)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:204)
> 	... 226 more
> {code}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> Fail with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy65.remoteCall(Unknown Source)
> 	at 
> {code}
> *org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode}}
> Fails with:
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.security.AccessControlException: WFSM000001: Permission check failed (permission ""(""java.net.SocketPermission"" ""10.16.91.218:9092"" ""connect,resolve"")"" in code source ""(vfs:/content/testTimerServiceSimple.war/WEB-INF/classes <no signer certificates>)"" of ""null"")" [50000-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:160)
> 	at org.h2.message.DbException.convert(DbException.java:283)
> 	at org.h2.message.DbException.toSQLException(DbException.java:256)
> 	at org.h2.message.TraceObject.logAndConvert(TraceObject.java:368)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:119)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:90)
> 	at org.h2.Driver.connect(Driver.java:73)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:319)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:350)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:285)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1319)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:708)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:607)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> 	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> 	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:614)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:482)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:308)
> 	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.java:57)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 15:26:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 18 Oct 2016 15:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7342) Updating of elytron kerberos
 security factory requires reload
In-Reply-To: <JIRA.12655562.1476818691000@Atlassian.JIRA>
References: <JIRA.12655562.1476818691000@Atlassian.JIRA>
	<JIRA.12655562.1476818691000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655562.1476818691000.14535.1476818760329@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6491 to WFLY-7342:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7342  (was: JBEAP-6491)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Updating of elytron kerberos security factory requires reload
> -------------------------------------------------------------
>
>                 Key: WFLY-7342
>                 URL: https://issues.jboss.org/browse/WFLY-7342
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>
> Is it necessary? I mean adding kerberos-security-factory does not require reload. 
> It relates to all of attributes debug, minimum-remaining-lifetime  principal, request-lifetime, 
> mechanism-oids, path, relative-to, server. For example
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 16:25:01 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 18 Oct 2016 16:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7343) NPE in elytron SPNEGO
 implementation in exceptional states
In-Reply-To: <JIRA.12655576.1476822271000@Atlassian.JIRA>
References: <JIRA.12655576.1476822271000@Atlassian.JIRA>
	<JIRA.12655576.1476822271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655576.1476822271000.14900.1476822301928@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6493 to WFLY-7343:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7343  (was: JBEAP-6493)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> NPE in elytron SPNEGO implementation in exceptional states
> ----------------------------------------------------------
>
>                 Key: WFLY-7343
>                 URL: https://issues.jboss.org/browse/WFLY-7343
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Critical
>
> Http response code 500 + excpetion in server log:
> {code}
> 21:40:40,640 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /secured-webapp/secure/index.jsp: java.lang.NullPointerException
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.authorizeEstablishedContext(SpnegoAuthenticationMechanism.java:177)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:128)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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}
> I have hit this in two situations so far
> * accessing with kerberos ticket from another realm. E.g. application server is set for realm JBOSS.ORG, but client is jduke at REDHAT.COM
> 	** For this situation is http response code 500 disputable, as it could be viewed as problem of client. Client can change ticket and authentication can be performed just fine. 
> * misconfiguration e.g. wrong kdc in krb5.conf
> Provide some meaningful error message.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 16:34:02 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 18 Oct 2016 16:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7344) HTTP2 / ALPN does not work
 when using wildfly-openssl
In-Reply-To: <JIRA.12655577.1476822802000@Atlassian.JIRA>
References: <JIRA.12655577.1476822802000@Atlassian.JIRA>
	<JIRA.12655577.1476822802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655577.1476822802000.14942.1476822842564@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-6494 to WFLY-7344:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7344  (was: JBEAP-6494)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                       Server
                           (was: Security)
                           (was: Server)
    Affects Version/s:     (was: 7.1.0.DR6)


> HTTP2 / ALPN does not work when using wildfly-openssl
> -----------------------------------------------------
>
>                 Key: WFLY-7344
>                 URL: https://issues.jboss.org/browse/WFLY-7344
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Server
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>              Labels: wildfly-openssl
>
> wildfly-openssl version used: {{1.0.0.Alpha1}}.
> I have a problem to use HTTP2 on EAP when using OpenSSL implementation based on the wildfly-openssl project. When I use standard 'TLS' protocol, HTTP2 works just fine (using Chrome as a client). But when I switch to 'openssl.TLS', client uses HTTP/1.1 and never upgrade to HTTP2.
> What I do:
> # start EAP
> # perform request to: https://localhost:8443   ----- HTTP2 is used here
> # {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol,value=openssl.TLS)}}
> # reload
> # perform request to: https://localhost:8443   ----- HTTP/1.1 is used here
> I tried to check in Wireshark. When I compared Client and Server Hello packets, I can see that in both cases the Client Hello packets contains TLS ALPN extension part with offered protocols h2 and http/1.1. Although Server Hello packets differs. When 'TLS' is used, then Server Hello packet contains ALPN extension with chosen protocol of 'h2'. But when 'openssl.TLS' is used, I can see that appropriate Server Hello packet does not contain ALPN extension part at all, which I presume leads that HTTP/1.1 protocol is used for further communication.
> Not sure whether it is related somehow, I can also see that different types of ciphers are used - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in case of 'TLS' and TLS_RSA_WITH_AES_128_GCM_SHA256 in case of 'openssl.TLS'.
> My openssl version is: {{1.0.2j-fips}}
> Not sure whether there must be performed some extra configuration to make HTTP2/ALPN work when using openssl implementation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 16:37:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 18 Oct 2016 16:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1874) HTTP2 / ALPN does not work
 when using wildfly-openssl
In-Reply-To: <JIRA.12655577.1476822802000@Atlassian.JIRA>
References: <JIRA.12655577.1476822802000@Atlassian.JIRA>
	<JIRA.12655577.1476822802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655577.1476822802000.14968.1476823020479@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved WFLY-7344 to WFCORE-1874:
----------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-1874  (was: WFLY-7344)
    Component/s: Security
                 Server
                     (was: Security)
                     (was: Server)


> HTTP2 / ALPN does not work when using wildfly-openssl
> -----------------------------------------------------
>
>                 Key: WFCORE-1874
>                 URL: https://issues.jboss.org/browse/WFCORE-1874
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security, Server
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>              Labels: wildfly-openssl
>
> wildfly-openssl version used: {{1.0.0.Alpha1}}.
> I have a problem to use HTTP2 on EAP when using OpenSSL implementation based on the wildfly-openssl project. When I use standard 'TLS' protocol, HTTP2 works just fine (using Chrome as a client). But when I switch to 'openssl.TLS', client uses HTTP/1.1 and never upgrade to HTTP2.
> What I do:
> # start EAP
> # perform request to: https://localhost:8443   ----- HTTP2 is used here
> # {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol,value=openssl.TLS)}}
> # reload
> # perform request to: https://localhost:8443   ----- HTTP/1.1 is used here
> I tried to check in Wireshark. When I compared Client and Server Hello packets, I can see that in both cases the Client Hello packets contains TLS ALPN extension part with offered protocols h2 and http/1.1. Although Server Hello packets differs. When 'TLS' is used, then Server Hello packet contains ALPN extension with chosen protocol of 'h2'. But when 'openssl.TLS' is used, I can see that appropriate Server Hello packet does not contain ALPN extension part at all, which I presume leads that HTTP/1.1 protocol is used for further communication.
> Not sure whether it is related somehow, I can also see that different types of ciphers are used - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in case of 'TLS' and TLS_RSA_WITH_AES_128_GCM_SHA256 in case of 'openssl.TLS'.
> My openssl version is: {{1.0.2j-fips}}
> Not sure whether there must be performed some extra configuration to make HTTP2/ALPN work when using openssl implementation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 17:59:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 18 Oct 2016 17:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7338) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.15058.1476827940345@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7338:
------------------------------
    Component/s: Logging


> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7338
>                 URL: https://issues.jboss.org/browse/WFLY-7338
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 17:59:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 18 Oct 2016 17:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1875) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.15063.1476827940464@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved WFLY-7338 to WFCORE-1875:
-------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-1875  (was: WFLY-7338)
          Component/s: Logging
                           (was: Logging)
    Affects Version/s:     (was: 10.0.0.Final)
                           (was: 10.1.0.Final)


> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1875
>                 URL: https://issues.jboss.org/browse/WFCORE-1875
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 20:55:00 2016
From: issues at jboss.org (Leonardo Penczek (JIRA))
Date: Tue, 18 Oct 2016 20:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7345) Fix big jboss-beans.xml files
	truncation
In-Reply-To: <JIRA.12655589.1476838453000@Atlassian.JIRA>
References: <JIRA.12655589.1476838453000@Atlassian.JIRA>
	<JIRA.12655589.1476838453037@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655589.1476838453000.15245.1476838500164@Atlassian.JIRA>

Leonardo Penczek created WFLY-7345:
--------------------------------------

             Summary: Fix big jboss-beans.xml files truncation
                 Key: WFLY-7345
                 URL: https://issues.jboss.org/browse/WFLY-7345
             Project: WildFly
          Issue Type: Bug
          Components: POJO
    Affects Versions: 10.1.0.Final
            Reporter: Leonardo Penczek
            Assignee: Ales Justin


If the jboss-beans.xml file is big enough, the value of a property.may be truncated,

Fix for this problem:

In the org.jboss.as.pojo.KernelDeploymentParsingProcessor constructor, add this line of code:
inputFactory.setProperty("javax.xml.stream.isCoalescing", Boolean.valueOf(true));

It prevents the truncation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 18 21:17:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 18 Oct 2016 21:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7342) Updating of elytron kerberos
 security factory requires reload
In-Reply-To: <JIRA.12655562.1476818691000@Atlassian.JIRA>
References: <JIRA.12655562.1476818691000@Atlassian.JIRA>
	<JIRA.12655562.1476818691000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655562.1476818691000.15277.1476839820298@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7342:
-----------------------------------

    Assignee: Ilia Vassilev


> Updating of elytron kerberos security factory requires reload
> -------------------------------------------------------------
>
>                 Key: WFLY-7342
>                 URL: https://issues.jboss.org/browse/WFLY-7342
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Is it necessary? I mean adding kerberos-security-factory does not require reload. 
> It relates to all of attributes debug, minimum-remaining-lifetime  principal, request-lifetime, 
> mechanism-oids, path, relative-to, server. For example
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 00:36:00 2016
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Wed, 19 Oct 2016 00:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1876) Content completion does not
 work for deployment-info --headers
In-Reply-To: <JIRA.12655595.1476851738000@Atlassian.JIRA>
References: <JIRA.12655595.1476851738000@Atlassian.JIRA>
	<JIRA.12655595.1476851738965@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655595.1476851738000.15454.1476851760191@Atlassian.JIRA>

Bartosz Baranowski created WFCORE-1876:
------------------------------------------

             Summary: Content completion does not work for deployment-info --headers
                 Key: WFCORE-1876
                 URL: https://issues.jboss.org/browse/WFCORE-1876
             Project: WildFly Core
          Issue Type: Bug
            Reporter: Bartosz Baranowski
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 00:37:00 2016
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Wed, 19 Oct 2016 00:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1876) Content completion does not
 work for deployment-info --headers
In-Reply-To: <JIRA.12655595.1476851739000@Atlassian.JIRA>
References: <JIRA.12655595.1476851739000@Atlassian.JIRA>
	<JIRA.12655595.1476851739000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655595.1476851739000.15456.1476851820170@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski updated WFCORE-1876:
---------------------------------------
    Description: 
[standalone at localhost:9990 /] deployment-info --headers       
[standalone at localhost:9990 /] deployment-info --headers=<TAB><TAB>

this does not kick in, should be:
[standalone at localhost:9990 /] deployment-info --headers={ 
after first <TAB>


> Content completion does not work for deployment-info --headers
> --------------------------------------------------------------
>
>                 Key: WFCORE-1876
>                 URL: https://issues.jboss.org/browse/WFCORE-1876
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Bartosz Baranowski
>            Priority: Minor
>
> [standalone at localhost:9990 /] deployment-info --headers       
> [standalone at localhost:9990 /] deployment-info --headers=<TAB><TAB>
> this does not kick in, should be:
> [standalone at localhost:9990 /] deployment-info --headers={ 
> after first <TAB>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 00:37:00 2016
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Wed, 19 Oct 2016 00:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1876) Content completion does not
 work for deployment-info --headers
In-Reply-To: <JIRA.12655595.1476851739000@Atlassian.JIRA>
References: <JIRA.12655595.1476851739000@Atlassian.JIRA>
	<JIRA.12655595.1476851739000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655595.1476851739000.15460.1476851820307@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski updated WFCORE-1876:
---------------------------------------
    Component/s: CLI


> Content completion does not work for deployment-info --headers
> --------------------------------------------------------------
>
>                 Key: WFCORE-1876
>                 URL: https://issues.jboss.org/browse/WFCORE-1876
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Bartosz Baranowski
>            Priority: Minor
>
> [standalone at localhost:9990 /] deployment-info --headers       
> [standalone at localhost:9990 /] deployment-info --headers=<TAB><TAB>
> this does not kick in, should be:
> [standalone at localhost:9990 /] deployment-info --headers={ 
> after first <TAB>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 00:38:00 2016
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Wed, 19 Oct 2016 00:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1877) Content completion does not
 work for deployment-info --headers
In-Reply-To: <JIRA.12655596.1476851858000@Atlassian.JIRA>
References: <JIRA.12655596.1476851858000@Atlassian.JIRA>
	<JIRA.12655596.1476851858211@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655596.1476851858000.15465.1476851880496@Atlassian.JIRA>

Bartosz Baranowski created WFCORE-1877:
------------------------------------------

             Summary: Content completion does not work for deployment-info --headers
                 Key: WFCORE-1877
                 URL: https://issues.jboss.org/browse/WFCORE-1877
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Bartosz Baranowski
            Priority: Minor


[standalone at localhost:9990 /] deployment-info --headers       
[standalone at localhost:9990 /] deployment-info --headers=<TAB><TAB>

this does not kick in, should be:
[standalone at localhost:9990 /] deployment-info --headers={ 
after first <TAB>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 01:55:00 2016
From: issues at jboss.org (Bartosz Andrzejewski (JIRA))
Date: Wed, 19 Oct 2016 01:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.15581.1476856500332@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309047#comment-13309047 ] 

Bartosz Andrzejewski commented on WFLY-5213:
--------------------------------------------

It worked for MDB, thank you. 

But problem with JMSContext remain. There is still comp/TransactionSynchronizationRegistry naming exception - on first conext usage(when creating a message or a producer).

> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct 19 02:43:00 2016
From: issues at jboss.org (Giovanni Lovato (JIRA))
Date: Wed, 19 Oct 2016 02:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.15682.1476859380620@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309057#comment-13309057 ] 

Giovanni Lovato commented on WFLY-7275:
---------------------------------------

I'm experiencing this too, can you please link your PR? Thank you!

> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Stuart Douglas
>         Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 02:57:00 2016
From: issues at jboss.org (Bartosz Andrzejewski (JIRA))
Date: Wed, 19 Oct 2016 02:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5213) Injecting external context to
 Artemis fails
In-Reply-To: <JIRA.12582682.1440596409000@Atlassian.JIRA>
References: <JIRA.12582682.1440596409000@Atlassian.JIRA>
	<JIRA.12582682.1440596409000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582682.1440596409000.15733.1476860220219@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309047#comment-13309047 ] 

Bartosz Andrzejewski edited comment on WFLY-5213 at 10/19/16 2:56 AM:
----------------------------------------------------------------------

It worked for MDB, thank you. 

But problem with JMSContext remain. There is still comp/TransactionSynchronizationRegistry naming exception - on first context usage(when creating a message or a producer).


was (Author: drzeyan):
It worked for MDB, thank you. 

But problem with JMSContext remain. There is still comp/TransactionSynchronizationRegistry naming exception - on first conext usage(when creating a message or a producer).

> Injecting external context to Artemis fails
> -------------------------------------------
>
>                 Key: WFLY-5213
>                 URL: https://issues.jboss.org/browse/WFLY-5213
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Beta2
>            Reporter: Ond?ej Kalman
>            Assignee: Jeff Mesnil
>             Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct 19 03:01:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 19 Oct 2016 03:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7346) Ignore client messaging tests
 failing with a security manager
In-Reply-To: <JIRA.12655607.1476860458000@Atlassian.JIRA>
References: <JIRA.12655607.1476860458000@Atlassian.JIRA>
	<JIRA.12655607.1476860458231@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655607.1476860458000.15752.1476860460780@Atlassian.JIRA>

Jeff Mesnil created WFLY-7346:
---------------------------------

             Summary: Ignore client messaging tests failing with a security manager
                 Key: WFLY-7346
                 URL: https://issues.jboss.org/browse/WFLY-7346
             Project: WildFly
          Issue Type: Task
          Components: JMS
    Affects Versions: 10.1.0.Final
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil


The upgrade to Artemis 1.4.0 (WFLY-7245) introduced a regression for JMS clients running with a security manager.
The issue was fixed in Artemis master branch (https://issues.apache.org/jira/browse/ARTEMIS-808) and will be part of the next release after 1.4.0.

In the meantime, ignore the failing tests when the security manager is set.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 03:11:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 19 Oct 2016 03:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7347) No log messages comming from
 Elytron - kerberos
In-Reply-To: <JIRA.12655611.1476860981000@Atlassian.JIRA>
References: <JIRA.12655611.1476860981000@Atlassian.JIRA>
	<JIRA.12655611.1476860981000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655611.1476860981000.15835.1476861060429@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6499 to WFLY-7347:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7347  (was: JBEAP-6499)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> No log messages comming from Elytron - kerberos
> -----------------------------------------------
>
>                 Key: WFLY-7347
>                 URL: https://issues.jboss.org/browse/WFLY-7347
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Critical
>
> Elytron is missing log messages related to kerberos authentication. These log messages should be added. See JBEAP-6041 for more details.
> I consider to be useful to have TRACE log messages at least in:
> - SpnegoAuthenticationMechanism
> - GSSCredentialSecurityFactory
> If there are more classes involved in kerberos authnetication include them as well.
> Kerberos issues are very specific. So it is very important to have as much trace information as possible. Therefore raising priority to Critical.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 04:18:00 2016
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 19 Oct 2016 04:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5574)
 org.wildfly.test.extension.rts InboundBridgeTestCase failing when
 transaction uses JTS
In-Reply-To: <JIRA.12590336.1445848456000@Atlassian.JIRA>
References: <JIRA.12590336.1445848456000@Atlassian.JIRA>
	<JIRA.12590336.1445848456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12590336.1445848456000.16297.1476865080306@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondra Chaloupka closed WFLY-5574.
---------------------------------
    Resolution: Duplicate Issue


After moving WFLY-6921 from JBEAP space this one duplicates 

> org.wildfly.test.extension.rts InboundBridgeTestCase failing when transaction uses JTS
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5574
>                 URL: https://issues.jboss.org/browse/WFLY-5574
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite, Transactions
>    Affects Versions: 10.0.0.CR3
>            Reporter: Ondra Chaloupka
>            Assignee: Gytis Trikleris
>             Fix For: 11.0.0.CR1
>
>         Attachments: server.log
>
>
> There is failures in testcase org.wildfly.test.extension.rts.InboundBridgeTestCase when transaction uses JTS.
> Example of the failure
> {code}
> testCommit(org.wildfly.test.extension.rts.InboundBridgeTestCase)  Time elapsed: 2.54 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<4> but was:<5> 
> {code}
> The JBOSS_HOME distribution is change to transaction to be run with JTS: changing the {{docs/example/standalone-rts.xml}} to switch transactions parameter in iiop orb subsystem to {{full}} and adding {{jts}} element to transactions subsystem.
> When JBOSS_HOME is set then I've run the test in this way
> {{./integration-tests.sh clean install -Dts.noSmoke -Dts.rts -Djboss.dist=$JBOSS_HOME -Dtest=InboundBridgeTestCase}}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 04:22:00 2016
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 19 Oct 2016 04:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5574)
 org.wildfly.test.extension.rts InboundBridgeTestCase failing when
 transaction uses JTS
In-Reply-To: <JIRA.12590336.1445848456000@Atlassian.JIRA>
References: <JIRA.12590336.1445848456000@Atlassian.JIRA>
	<JIRA.12590336.1445848456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12590336.1445848456000.16314.1476865320327@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondra Chaloupka reopened WFLY-5574:
-----------------------------------


I'm sorry to making fuss here. This jira contains more discussions and relevant information thus reopening this one and closing as duplicate the other one (WFLY-6921)

> org.wildfly.test.extension.rts InboundBridgeTestCase failing when transaction uses JTS
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5574
>                 URL: https://issues.jboss.org/browse/WFLY-5574
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite, Transactions
>    Affects Versions: 10.0.0.CR3
>            Reporter: Ondra Chaloupka
>            Assignee: Gytis Trikleris
>             Fix For: 11.0.0.CR1
>
>         Attachments: server.log
>
>
> There is failures in testcase org.wildfly.test.extension.rts.InboundBridgeTestCase when transaction uses JTS.
> Example of the failure
> {code}
> testCommit(org.wildfly.test.extension.rts.InboundBridgeTestCase)  Time elapsed: 2.54 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<4> but was:<5> 
> {code}
> The JBOSS_HOME distribution is change to transaction to be run with JTS: changing the {{docs/example/standalone-rts.xml}} to switch transactions parameter in iiop orb subsystem to {{full}} and adding {{jts}} element to transactions subsystem.
> When JBOSS_HOME is set then I've run the test in this way
> {{./integration-tests.sh clean install -Dts.noSmoke -Dts.rts -Djboss.dist=$JBOSS_HOME -Dtest=InboundBridgeTestCase}}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 04:23:00 2016
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 19 Oct 2016 04:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6921)
 org.wildfly.test.extension.rts.InboundBridgeTestCase failing when
 transaction uses JTS
In-Reply-To: <JIRA.12590335.1445848435000@Atlassian.JIRA>
References: <JIRA.12590335.1445848435000@Atlassian.JIRA>
	<JIRA.12590335.1445848435000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12590335.1445848435000.16335.1476865380937@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondra Chaloupka closed WFLY-6921.
---------------------------------
    Resolution: Duplicate Issue


Duplicates the WFLY-5574 as this one was just moved from JBEAP space when agreed that the issue is not an issue of the product.

> org.wildfly.test.extension.rts.InboundBridgeTestCase failing when transaction uses JTS
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-6921
>                 URL: https://issues.jboss.org/browse/WFLY-6921
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Ondra Chaloupka
>            Assignee: Gytis Trikleris
>
> There is failures in testcase org.wildfly.test.extension.rts.InboundBridgeTestCase when transaction uses JTS.
> Example of the failure
> {code}
> testCommit(org.wildfly.test.extension.rts.InboundBridgeTestCase)  Time elapsed: 2.54 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<4> but was:<5> 
> {code}
> The JBOSS_HOME distribution is change to transaction to be run with JTS: changing the {{docs/example/standalone-rts.xml}} to switch transactions parameter in iiop orb subsystem to {{full}} and adding {{jts}} element to transactions subsystem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 05:08:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 19 Oct 2016 05:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2116) MPING: restart doesn't work
In-Reply-To: <JIRA.12655544.1476807162000@Atlassian.JIRA>
References: <JIRA.12655544.1476807162000@Atlassian.JIRA>
	<JIRA.12655544.1476807162000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655544.1476807162000.16736.1476868080348@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2116.
----------------------------
    Resolution: Done


Discarding discovery request from self

> MPING: restart doesn't work
> ---------------------------
>
>                 Key: JGRP-2116
>                 URL: https://issues.jboss.org/browse/JGRP-2116
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>         Attachments: bla.java, tcp.xml
>
>
> MPING in a TCP stack doesn't pass a connect-disconnect-connect cycle, but the 2nd connect has 10 failed JOIN requests and then becomes a singleton



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 05:46:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 19 Oct 2016 05:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2117) TP: messages to self are not
	batched
In-Reply-To: <JIRA.12655641.1476870301000@Atlassian.JIRA>
References: <JIRA.12655641.1476870301000@Atlassian.JIRA>
	<JIRA.12655641.1476870301375@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655641.1476870301000.16942.1476870360292@Atlassian.JIRA>

Bela Ban created JGRP-2117:
------------------------------

             Summary: TP: messages to self are not batched
                 Key: JGRP-2117
                 URL: https://issues.jboss.org/browse/JGRP-2117
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0


If A sends 100 multicast messages (or unicast messages to self), the messages to self are not batched but looped back individually, each using a separate thread from the thread pool.

So in the above case, A will receive its own 100 messages using 100 threads from the pool.

It would be more efficient to batch the 100 messages into a batch and then loop the batch back, taking up 1 thread instead of 100!

To do this, looping back has to be done _after_ the bundler, when the bundler is sending the message batch.





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 05:53:00 2016
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 19 Oct 2016 05:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7275) Wildfly eats the CPU up to
 100% and does not respond
In-Reply-To: <JIRA.12653856.1475861764000@Atlassian.JIRA>
References: <JIRA.12653856.1475861764000@Atlassian.JIRA>
	<JIRA.12653856.1475861764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653856.1475861764000.16985.1476870780303@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309187#comment-13309187 ] 

Marek Kopeck? commented on WFLY-7275:
-------------------------------------

PR is linked in XNIO-276: https://github.com/xnio/xnio/pull/97

> Wildfly eats the CPU up to 100% and does not respond
> ----------------------------------------------------
>
>                 Key: WFLY-7275
>                 URL: https://issues.jboss.org/browse/WFLY-7275
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>         Environment: Ubuntu 14.04, Linux 3.19, Oracle Java 8u91 64-bit
>            Reporter: Krisztian Kocsis
>            Assignee: Stuart Douglas
>         Attachments: Screen Shot 2016-10-07 at 20.18.27.png, Screen Shot 2016-10-07 at 20.18.31.png, wildfly-after-hang+1min.txt, wildfly-after-hang.txt, wildfly-hang-real-stacktrace.txt, wildfly-hang.txt
>
>
> Hi!
>  
> I have a JAX-RS application and after a lot of load, one thread eats up the CPU (100% usage) even when the load test app is terminated, and never drops down until I restart the app server.
> It causes me a lot of headeches because it totally makes the app server unusable until I restart, but the users unable to use the app in the meanwhile.
>  
> I'v attached the stack trace but I unfortunately don't see anything according to my knowledge.
> Please help me, I can provide more information if necessary.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct 19 05:55:01 2016
From: issues at jboss.org (Petr Jurak (JIRA))
Date: Wed, 19 Oct 2016 05:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-773)
 ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the
 thread pool executor
In-Reply-To: <JIRA.12575453.1434617524000@Atlassian.JIRA>
References: <JIRA.12575453.1434617524000@Atlassian.JIRA>
	<JIRA.12575453.1434617524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575453.1434617524000.17010.1476870901330@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Jurak reassigned WFCORE-773:
---------------------------------

    Assignee: Petr Jurak  (was: Enrique Gonz?lez Mart?nez)


>  ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-773
>                 URL: https://issues.jboss.org/browse/WFCORE-773
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Enrique Gonz?lez Mart?nez
>            Assignee: Petr Jurak
>
> BoundedQueueThreadPool does not support zero length queue setup.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct 19 05:56:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 19 Oct 2016 05:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2117) TP: messages to self are not
	batched
In-Reply-To: <JIRA.12655641.1476870301000@Atlassian.JIRA>
References: <JIRA.12655641.1476870301000@Atlassian.JIRA>
	<JIRA.12655641.1476870301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655641.1476870301000.17039.1476870960277@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309191#comment-13309191 ] 

Bela Ban commented on JGRP-2117:
--------------------------------

Hmm, the downside is that, whereas the current impl loops back message directly, using a bundler means that the messages would be marshalled and then unmarshalled.

We should create a MessageBatch for looped-back messages without having to marshal/unmarshal.

> TP: messages to self are not batched
> ------------------------------------
>
>                 Key: JGRP-2117
>                 URL: https://issues.jboss.org/browse/JGRP-2117
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> If A sends 100 multicast messages (or unicast messages to self), the messages to self are not batched but looped back individually, each using a separate thread from the thread pool.
> So in the above case, A will receive its own 100 messages using 100 threads from the pool.
> It would be more efficient to batch the 100 messages into a batch and then loop the batch back, taking up 1 thread instead of 100!
> To do this, looping back has to be done _after_ the bundler, when the bundler is sending the message batch.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 06:33:00 2016
From: issues at jboss.org (Chadi El Masri (JIRA))
Date: Wed, 19 Oct 2016 06:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1335) Classpath is not checked
 for Kie Module ReleaseId
In-Reply-To: <JIRA.12655648.1476873133000@Atlassian.JIRA>
References: <JIRA.12655648.1476873133000@Atlassian.JIRA>
	<JIRA.12655648.1476873133909@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655648.1476873133000.17253.1476873180125@Atlassian.JIRA>

Chadi El Masri created DROOLS-1335:
--------------------------------------

             Summary: Classpath is not checked for Kie Module ReleaseId
                 Key: DROOLS-1335
                 URL: https://issues.jboss.org/browse/DROOLS-1335
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 7.0.0.Beta2, 6.5.0.CR2, 6.4.0.Final
            Reporter: Chadi El Masri
            Assignee: Edson Tirelli
         Attachments: 0001-Implement-the-method-to-read-the-KieModule-from-clas.patch

Injecting a ksession annotated with a particular @KReleaseId is not able to read the passed release id from the classpath (the part that does that is not implemented).

The bug is here: https://github.com/droolsjbpm/drools/blob/6.4.0.Final/drools-compiler/src/main/java/org/drools/compiler/kie/builder/impl/KieRepositoryImpl.java#L123-L126

Patch attached.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 07:08:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 19 Oct 2016 07:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2118) TP: messages tagged with
 DONT_BUNDLE are not bundled
In-Reply-To: <JIRA.12655653.1476875227000@Atlassian.JIRA>
References: <JIRA.12655653.1476875227000@Atlassian.JIRA>
	<JIRA.12655653.1476875227952@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655653.1476875227000.17776.1476875280123@Atlassian.JIRA>

Bela Ban created JGRP-2118:
------------------------------

             Summary: TP: messages tagged with DONT_BUNDLE are not bundled
                 Key: JGRP-2118
                 URL: https://issues.jboss.org/browse/JGRP-2118
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0


Since 3.x (3.6?), *all* messages are bundled, even the ones tagged with DONT_BUNDLE. 

This is incorrect and a regression from 3.x.

Fix: bundle _all_ messages. The DONT_BUNDLE and OOB flags only come into play at the receiver side where messages tagged with these flags are removed from a batch and delivered individually (in separate threads).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 07:55:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 19 Oct 2016 07:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2118) TP: messages tagged with
 DONT_BUNDLE are not bundled
In-Reply-To: <JIRA.12655653.1476875228000@Atlassian.JIRA>
References: <JIRA.12655653.1476875228000@Atlassian.JIRA>
	<JIRA.12655653.1476875228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655653.1476875228000.18113.1476878100261@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2118.
----------------------------
    Resolution: Done


> TP: messages tagged with DONT_BUNDLE are not bundled
> ----------------------------------------------------
>
>                 Key: JGRP-2118
>                 URL: https://issues.jboss.org/browse/JGRP-2118
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Since 3.x (3.6?), *all* messages are bundled, even the ones tagged with DONT_BUNDLE. 
> This is incorrect and a regression from 3.x.
> Fix: bundle _all_ messages. The DONT_BUNDLE and OOB flags only come into play at the receiver side where messages tagged with these flags are removed from a batch and delivered individually (in separate threads).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 08:15:01 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 19 Oct 2016 08:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2119) Separate JMX objects
In-Reply-To: <JIRA.12655663.1476879269000@Atlassian.JIRA>
References: <JIRA.12655663.1476879269000@Atlassian.JIRA>
	<JIRA.12655663.1476879269108@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655663.1476879269000.18256.1476879301208@Atlassian.JIRA>

Bela Ban created JGRP-2119:
------------------------------

             Summary: Separate JMX objects
                 Key: JGRP-2119
                 URL: https://issues.jboss.org/browse/JGRP-2119
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0


Provide managed attributes or operations in separate classes, e.g. to be used for stats in TP. These could include num_msgs_sent, num_batches_received etc.

A protocol could implement an interface (e.g. AdditionalStats), which would return a list of objects whose attributes and operations should be exposed together with the protocol.

This would reduce code in TP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 08:49:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Wed, 19 Oct 2016 08:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881336000@Atlassian.JIRA>
References: <JIRA.12655671.1476881336000@Atlassian.JIRA>
	<JIRA.12655671.1476881336983@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881336000.18558.1476881340749@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-1878:
--------------------------------------------

             Summary: CLI should not rely on values that could conflict with shell operators
                 Key: WFCORE-1878
                 URL: https://issues.jboss.org/browse/WFCORE-1878
             Project: WildFly Core
          Issue Type: Feature Request
          Components: CLI
            Reporter: Jean-Francois Denise


If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt

Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 08:50:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Wed, 19 Oct 2016 08:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881337000@Atlassian.JIRA>
References: <JIRA.12655671.1476881337000@Atlassian.JIRA>
	<JIRA.12655671.1476881337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881337000.18561.1476881400156@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-1878:
--------------------------------------------

    Assignee: Jean-Francois Denise


> CLI should not rely on values that could conflict with shell operators
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1878
>                 URL: https://issues.jboss.org/browse/WFCORE-1878
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt
> Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 08:53:01 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 19 Oct 2016 08:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7348) Elytron deployment depends on
 org.jboss.security.negotiation
In-Reply-To: <JIRA.12655673.1476881553000@Atlassian.JIRA>
References: <JIRA.12655673.1476881553000@Atlassian.JIRA>
	<JIRA.12655673.1476881553000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655673.1476881553000.18614.1476881581772@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6510 to WFLY-7348:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7348  (was: JBEAP-6510)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Elytron deployment depends on org.jboss.security.negotiation
> ------------------------------------------------------------
>
>                 Key: WFLY-7348
>                 URL: https://issues.jboss.org/browse/WFLY-7348
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>
> Based on wildfly documentation deployment which is secured by SPNEGO have to depend on {{org.jboss.security.negotiation}} module
> Such configuration leads to WARN message beeing logged into server log 
> {code}
> 08:35:05,388 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-8) WFLYSRV0018: Deployment "deployment.secured-webapp.war" is using a private module ("org.jboss.security.negotiation:main") which may be changed or removed in future versions without notice.
> {code}
> [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:03:00 2016
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 19 Oct 2016 09:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1335) Classpath is not checked
 for Kie Module ReleaseId
In-Reply-To: <JIRA.12655648.1476873134000@Atlassian.JIRA>
References: <JIRA.12655648.1476873134000@Atlassian.JIRA>
	<JIRA.12655648.1476873134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655648.1476873134000.18740.1476882180272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-1335:
-------------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> Classpath is not checked for Kie Module ReleaseId
> -------------------------------------------------
>
>                 Key: DROOLS-1335
>                 URL: https://issues.jboss.org/browse/DROOLS-1335
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.4.0.Final, 6.5.0.CR2, 7.0.0.Beta2
>            Reporter: Chadi El Masri
>            Assignee: Mario Fusco
>         Attachments: 0001-Implement-the-method-to-read-the-KieModule-from-clas.patch
>
>
> Injecting a ksession annotated with a particular @KReleaseId is not able to read the passed release id from the classpath (the part that does that is not implemented).
> The bug is here: https://github.com/droolsjbpm/drools/blob/6.4.0.Final/drools-compiler/src/main/java/org/drools/compiler/kie/builder/impl/KieRepositoryImpl.java#L123-L126
> Patch attached.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:09:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 09:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1876) Content completion does not
 work for deployment-info --headers
In-Reply-To: <JIRA.12655595.1476851739000@Atlassian.JIRA>
References: <JIRA.12655595.1476851739000@Atlassian.JIRA>
	<JIRA.12655595.1476851739000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655595.1476851739000.18812.1476882540326@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1876:
----------------------------------------

    Assignee: Jean-Francois Denise


> Content completion does not work for deployment-info --headers
> --------------------------------------------------------------
>
>                 Key: WFCORE-1876
>                 URL: https://issues.jboss.org/browse/WFCORE-1876
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Bartosz Baranowski
>            Assignee: Jean-Francois Denise
>            Priority: Minor
>
> [standalone at localhost:9990 /] deployment-info --headers       
> [standalone at localhost:9990 /] deployment-info --headers=<TAB><TAB>
> this does not kick in, should be:
> [standalone at localhost:9990 /] deployment-info --headers={ 
> after first <TAB>



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:18:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 09:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881337000@Atlassian.JIRA>
References: <JIRA.12655671.1476881337000@Atlassian.JIRA>
	<JIRA.12655671.1476881337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881337000.18888.1476883080118@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309300#comment-13309300 ] 

Brian Stansberry commented on WFCORE-1878:
------------------------------------------

IIRC <ALL> is new and has never been in a .Final release, so if there is any concern about it let's change it now. You can increase the priority to Critical or Blocker and set a Fix Version if that's your plan. That will help ensure it doesn't get missed.

> CLI should not rely on values that could conflict with shell operators
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1878
>                 URL: https://issues.jboss.org/browse/WFCORE-1878
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt
> Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:26:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Wed, 19 Oct 2016 09:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881337000@Atlassian.JIRA>
References: <JIRA.12655671.1476881337000@Atlassian.JIRA>
	<JIRA.12655671.1476881337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881337000.18918.1476883560245@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309304#comment-13309304 ] 

Jean-Francois Denise commented on WFCORE-1878:
----------------------------------------------

Yes, that is the plan. I am wandering what is the impact on the original RFE: https://issues.jboss.org/browse/EAP7-515
Should I move it back to Analysis dev? Should be keep it as it and simply change the public community documentation?


> CLI should not rely on values that could conflict with shell operators
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1878
>                 URL: https://issues.jboss.org/browse/WFCORE-1878
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt
> Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:27:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Wed, 19 Oct 2016 09:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881337000@Atlassian.JIRA>
References: <JIRA.12655671.1476881337000@Atlassian.JIRA>
	<JIRA.12655671.1476881337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881337000.18923.1476883620190@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309304#comment-13309304 ] 

Jean-Francois Denise edited comment on WFCORE-1878 at 10/19/16 9:26 AM:
------------------------------------------------------------------------

Yes, that is the plan. I am wandering what is the impact on the original RFE: https://issues.jboss.org/browse/EAP7-515
Should I move it back to Analysis dev? Should we keep it as it is and simply change the public community documentation?



was (Author: jdenise):
Yes, that is the plan. I am wandering what is the impact on the original RFE: https://issues.jboss.org/browse/EAP7-515
Should I move it back to Analysis dev? Should be keep it as it and simply change the public community documentation?


> CLI should not rely on values that could conflict with shell operators
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1878
>                 URL: https://issues.jboss.org/browse/WFCORE-1878
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt
> Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:30:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Wed, 19 Oct 2016 09:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881337000@Atlassian.JIRA>
References: <JIRA.12655671.1476881337000@Atlassian.JIRA>
	<JIRA.12655671.1476881337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881337000.18942.1476883800557@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise updated WFCORE-1878:
-----------------------------------------
    Fix Version/s: 3.0.0.Alpha10
         Priority: Blocker  (was: Major)


> CLI should not rely on values that could conflict with shell operators
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1878
>                 URL: https://issues.jboss.org/browse/WFCORE-1878
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha10
>
>
> If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt
> Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:30:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Wed, 19 Oct 2016 09:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881337000@Atlassian.JIRA>
References: <JIRA.12655671.1476881337000@Atlassian.JIRA>
	<JIRA.12655671.1476881337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881337000.18957.1476883800936@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309311#comment-13309311 ] 

Jean-Francois Denise commented on WFCORE-1878:
----------------------------------------------

I am proposing to use the '*' character and make it clear in documentation tha tit is not a pattern but that it identifies "All disabled deployments".

> CLI should not rely on values that could conflict with shell operators
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1878
>                 URL: https://issues.jboss.org/browse/WFCORE-1878
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha10
>
>
> If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt
> Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:30:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 09:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881337000@Atlassian.JIRA>
References: <JIRA.12655671.1476881337000@Atlassian.JIRA>
	<JIRA.12655671.1476881337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881337000.18953.1476883800815@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309310#comment-13309310 ] 

Brian Stansberry commented on WFCORE-1878:
------------------------------------------

I recommend starting with pinging the QE Tester on the feature to get quick input on your plans. Then comment on EAP7-515, update the analysis doc, the code and the community docs.

> CLI should not rely on values that could conflict with shell operators
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1878
>                 URL: https://issues.jboss.org/browse/WFCORE-1878
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha10
>
>
> If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt
> Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:32:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Wed, 19 Oct 2016 09:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881337000@Atlassian.JIRA>
References: <JIRA.12655671.1476881337000@Atlassian.JIRA>
	<JIRA.12655671.1476881337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881337000.18978.1476883920820@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309314#comment-13309314 ] 

Jean-Francois Denise commented on WFCORE-1878:
----------------------------------------------

QE contact has already been contacted. Waiting for his feedback.


> CLI should not rely on values that could conflict with shell operators
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1878
>                 URL: https://issues.jboss.org/browse/WFCORE-1878
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha10
>
>
> If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt
> Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 09:32:01 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 19 Oct 2016 09:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-773)
 ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the
 thread pool executor
In-Reply-To: <JIRA.12575453.1434617524000@Atlassian.JIRA>
References: <JIRA.12575453.1434617524000@Atlassian.JIRA>
	<JIRA.12575453.1434617524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575453.1434617524000.18986.1476883921005@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309315#comment-13309315 ] 

RH Bugzilla Integration commented on WFCORE-773:
------------------------------------------------

Petr Jurak <pjurak at redhat.com> changed the Status of [bug 1231070|https://bugzilla.redhat.com/show_bug.cgi?id=1231070] from ASSIGNED to POST

>  ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-773
>                 URL: https://issues.jboss.org/browse/WFCORE-773
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Enrique Gonz?lez Mart?nez
>            Assignee: Petr Jurak
>
> BoundedQueueThreadPool does not support zero length queue setup.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct 19 10:43:00 2016
From: issues at jboss.org (Tomas David (JIRA))
Date: Wed, 19 Oct 2016 10:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1336) Globals variables are not
 present in Globals Data View
In-Reply-To: <JIRA.12655726.1476888140000@Atlassian.JIRA>
References: <JIRA.12655726.1476888140000@Atlassian.JIRA>
	<JIRA.12655726.1476888140064@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655726.1476888140000.19501.1476888180226@Atlassian.JIRA>

Tomas David created DROOLS-1336:
-----------------------------------

             Summary: Globals variables are not present in Globals Data View
                 Key: DROOLS-1336
                 URL: https://issues.jboss.org/browse/DROOLS-1336
             Project: Drools
          Issue Type: Bug
          Components: eclipse plugin
            Reporter: Tomas David
            Assignee: Robert (Bob) Brodt
         Attachments: globals.png

I just create this issue since this is problem which is present for very long time but I can't find 
corresponding issue in Bugzilla or Jira.

If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 10:43:00 2016
From: issues at jboss.org (Tomas David (JIRA))
Date: Wed, 19 Oct 2016 10:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1336) Globals variables are not
 present in Globals Data View
In-Reply-To: <JIRA.12655726.1476888140000@Atlassian.JIRA>
References: <JIRA.12655726.1476888140000@Atlassian.JIRA>
	<JIRA.12655726.1476888140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655726.1476888140000.19504.1476888180373@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas David updated DROOLS-1336:
--------------------------------
    Steps to Reproduce: 
# Create default Drools project with HelloWorld rule file
# Edit Sample.drl file, add lines:
global String stringVar
global Object objectVar
global List listVar
# Edit DroolsTest.java file, add lines:
kSession.setGlobal("listVar", java.util.Arrays.asList(1, 2, 3));
kSession.setGlobal("objectVar", new Object());
kSession.setGlobal("stringVar", "testStringValue");
# Debug the project
# Open Global Data View

  was:
# Create default Drools project with HelloWorld rule file
# Edit Sample.drl file, add lines:
{{global String stringVar
global Object objectVar
global List listVar}}
# Edit DroolsTest.java file, add lines:
{{kSession.setGlobal("listVar", java.util.Arrays.asList(1, 2, 3));
kSession.setGlobal("objectVar", new Object());
kSession.setGlobal("stringVar", "testStringValue");}}
# Debug the project
# Open Global Data View



> Globals variables are not present in Globals Data View
> ------------------------------------------------------
>
>                 Key: DROOLS-1336
>                 URL: https://issues.jboss.org/browse/DROOLS-1336
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>            Reporter: Tomas David
>            Assignee: Robert (Bob) Brodt
>              Labels: reported-by-qe
>         Attachments: globals.png
>
>
> I just create this issue since this is problem which is present for very long time but I can't find 
> corresponding issue in Bugzilla or Jira.
> If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 10:44:00 2016
From: issues at jboss.org (Tomas David (JIRA))
Date: Wed, 19 Oct 2016 10:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1336) Globals variables are not
 present in Globals Data View
In-Reply-To: <JIRA.12655726.1476888140000@Atlassian.JIRA>
References: <JIRA.12655726.1476888140000@Atlassian.JIRA>
	<JIRA.12655726.1476888140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655726.1476888140000.19511.1476888240348@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas David updated DROOLS-1336:
--------------------------------
    Description: 
I just create this issue since this is problem which is present for very long time but I can't find corresponding issue in Bugzilla or Jira.

If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.

  was:
I just create this issue since this is problem which is present for very long time but I can't find 
corresponding issue in Bugzilla or Jira.

If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.



> Globals variables are not present in Globals Data View
> ------------------------------------------------------
>
>                 Key: DROOLS-1336
>                 URL: https://issues.jboss.org/browse/DROOLS-1336
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>            Reporter: Tomas David
>            Assignee: Robert (Bob) Brodt
>              Labels: reported-by-qe
>         Attachments: globals.png
>
>
> I just create this issue since this is problem which is present for very long time but I can't find corresponding issue in Bugzilla or Jira.
> If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 10:56:00 2016
From: issues at jboss.org (Tomas David (JIRA))
Date: Wed, 19 Oct 2016 10:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1336) Globals variables are not
 present in Globals Data View
In-Reply-To: <JIRA.12655726.1476888140000@Atlassian.JIRA>
References: <JIRA.12655726.1476888140000@Atlassian.JIRA>
	<JIRA.12655726.1476888140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655726.1476888140000.19560.1476888960123@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas David updated DROOLS-1336:
--------------------------------
    Description: 
I just create this issue since this is problem which is present for very long time but I can't find the corresponding issue in Bugzilla or Jira.

If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.

  was:
I just create this issue since this is problem which is present for very long time but I can't find corresponding issue in Bugzilla or Jira.

If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.



> Globals variables are not present in Globals Data View
> ------------------------------------------------------
>
>                 Key: DROOLS-1336
>                 URL: https://issues.jboss.org/browse/DROOLS-1336
>             Project: Drools
>          Issue Type: Bug
>          Components: eclipse plugin
>            Reporter: Tomas David
>            Assignee: Robert (Bob) Brodt
>              Labels: reported-by-qe
>         Attachments: globals.png
>
>
> I just create this issue since this is problem which is present for very long time but I can't find the corresponding issue in Bugzilla or Jira.
> If global variables are used in drools project and it is debugged. No global variables are present in Global Data View.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 10:57:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Wed, 19 Oct 2016 10:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7304) Compensations subsystem
In-Reply-To: <JIRA.12654630.1476351823000@Atlassian.JIRA>
References: <JIRA.12654630.1476351823000@Atlassian.JIRA>
	<JIRA.12654630.1476351823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654630.1476351823000.19565.1476889020174@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309357#comment-13309357 ] 

Gytis Trikleris commented on WFLY-7304:
---------------------------------------

I doubt it, but not sure how to confirm it.
The only functionality for this was to add dependency on org.jboss.narayana.compensations module, if deployment had a certain annotation. It was a part of transactions subsystem, but it wasn't configurable in any way.

> Compensations subsystem
> -----------------------
>
>                 Key: WFLY-7304
>                 URL: https://issues.jboss.org/browse/WFLY-7304
>             Project: WildFly
>          Issue Type: Task
>          Components: Transactions
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 11:00:02 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 19 Oct 2016 11:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7349)
 configurable-sasl-server-factory cannot set mechanism information
In-Reply-To: <JIRA.12655730.1476889160000@Atlassian.JIRA>
References: <JIRA.12655730.1476889160000@Atlassian.JIRA>
	<JIRA.12655730.1476889160231@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655730.1476889160000.19579.1476889202560@Atlassian.JIRA>

Jan Kalina created WFLY-7349:
--------------------------------

             Summary: configurable-sasl-server-factory cannot set mechanism information
                 Key: WFLY-7349
                 URL: https://issues.jboss.org/browse/WFLY-7349
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Jan Kalina
            Assignee: Jan Kalina


sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.

The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.

The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 11:07:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 19 Oct 2016 11:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7349)
 configurable-sasl-server-factory cannot set mechanism information
In-Reply-To: <JIRA.12655730.1476889160000@Atlassian.JIRA>
References: <JIRA.12655730.1476889160000@Atlassian.JIRA>
	<JIRA.12655730.1476889160000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655730.1476889160000.19600.1476889620235@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7349:
-----------------------------
    Attachment: sasl-test.xml
                SaslTestCase.java


> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
>                 Key: WFLY-7349
>                 URL: https://issues.jboss.org/browse/WFLY-7349
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>         Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 11:10:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 19 Oct 2016 11:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7349)
 configurable-sasl-server-factory cannot set mechanism information
In-Reply-To: <JIRA.12655730.1476889160000@Atlassian.JIRA>
References: <JIRA.12655730.1476889160000@Atlassian.JIRA>
	<JIRA.12655730.1476889160000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655730.1476889160000.19611.1476889800427@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7349:
-----------------------------
    Description: 
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.

The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.

The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}

Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)

  was:
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.

The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.

The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}



> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
>                 Key: WFLY-7349
>                 URL: https://issues.jboss.org/browse/WFLY-7349
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>         Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
> Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 11:10:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 19 Oct 2016 11:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7349)
 configurable-sasl-server-factory cannot set mechanism information
In-Reply-To: <JIRA.12655730.1476889160000@Atlassian.JIRA>
References: <JIRA.12655730.1476889160000@Atlassian.JIRA>
	<JIRA.12655730.1476889160000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655730.1476889160000.19617.1476889800604@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7349:
-----------------------------
    Description: 
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.

*The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.

The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}

Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)

  was:
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.

The problem is, if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.

The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}

Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)



> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
>                 Key: WFLY-7349
>                 URL: https://issues.jboss.org/browse/WFLY-7349
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>         Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> *The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
> Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 11:11:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 19 Oct 2016 11:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7349)
 configurable-sasl-server-factory cannot set mechanism information
In-Reply-To: <JIRA.12655730.1476889160000@Atlassian.JIRA>
References: <JIRA.12655730.1476889160000@Atlassian.JIRA>
	<JIRA.12655730.1476889160000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655730.1476889160000.19623.1476889860261@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7349:
-----------------------------
    Description: 
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following factory in chain but with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.

*The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.

The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}

Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)

  was:
sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which only call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.

*The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.

The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}

Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)



> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
>                 Key: WFLY-7349
>                 URL: https://issues.jboss.org/browse/WFLY-7349
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>         Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following factory in chain but with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> *The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
> Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 11:57:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 19 Oct 2016 11:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7304) Compensations subsystem
In-Reply-To: <JIRA.12654630.1476351823000@Atlassian.JIRA>
References: <JIRA.12654630.1476351823000@Atlassian.JIRA>
	<JIRA.12654630.1476351823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654630.1476351823000.19856.1476892620328@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309374#comment-13309374 ] 

Tomaz Cerar commented on WFLY-7304:
-----------------------------------

Why whole new subsystem? having sub resource in transactions subsystem doesn't cut it?

> Compensations subsystem
> -----------------------
>
>                 Key: WFLY-7304
>                 URL: https://issues.jboss.org/browse/WFLY-7304
>             Project: WildFly
>          Issue Type: Task
>          Components: Transactions
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:26:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 12:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1879) Master HC should reject
 registration attempts by slaves that have any management API version
 greater than its own
In-Reply-To: <JIRA.12655749.1476894323000@Atlassian.JIRA>
References: <JIRA.12655749.1476894323000@Atlassian.JIRA>
	<JIRA.12655749.1476894323540@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655749.1476894323000.19991.1476894360609@Atlassian.JIRA>

Brian Stansberry created WFCORE-1879:
----------------------------------------

             Summary: Master HC should reject registration attempts by slaves that have any management API version greater than its own
                 Key: WFCORE-1879
                 URL: https://issues.jboss.org/browse/WFCORE-1879
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Ken Wills


(Note: It's possible we already do this, or that somehow we effectively do due to things blowing up if the rule is broken.)

We have always had a rule that the DC must be running the latest version of the software. If it isn't it can't reliably manage slaves as it cannot know how the slaves will interpret the operations it sends to them, and slaves will assume that the master is sending operations that are tailored to the management API versions it sent when it registered.

I do not believe the software actually enforces this requirement though. With the more complex use cases that WFCORE-338 will introduce we need to make this more formal.

When a slave first contacts a master it provides its kernel API version with the HostInfo data it sends over and then later in the registration process it provides the subsystem API versions for all the extensions the master provided. Both of these points provide an opportunity for version comparison.

When an HC rejects registration by a slave, we have a mechanism for propogating an error code to the slave to help it understand and report the problem (e.g. the remote HC is not master or it is running in admin-only mode.) We should try to expand that mechanism to include this case, rather than failing with a general unspecified error.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:32:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 12:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1880) Extension add operation
 handling should check that the slave HCs are not running later versions of
 the subsystem management API
In-Reply-To: <JIRA.12655751.1476894665000@Atlassian.JIRA>
References: <JIRA.12655751.1476894665000@Atlassian.JIRA>
	<JIRA.12655751.1476894665448@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655751.1476894665000.20051.1476894720259@Atlassian.JIRA>

Brian Stansberry created WFCORE-1880:
----------------------------------------

             Summary: Extension add operation handling should check that the slave HCs are not running later versions of the subsystem management API
                 Key: WFCORE-1880
                 URL: https://issues.jboss.org/browse/WFCORE-1880
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Ken Wills


Conceptually related to WFCORE-1879, but here the case is a slave that is already registered handling an /extension=foo:add operation sent by the master. It's theoretically possible that the slave might be running an earlier or equal version of all extensions that were configured when it registered, but for this new "foo" extension it has a newer version. If this happens the add operation should fail. The extension cannot be configured while the domain topology is like this.

Note if the slave is ignoring the extension add op, that is fine.

It's possible this is already somewhat handled. If an extension is added, for transformation to work properly the slave has to send back management API information that the master can use going forward. It's possible though that even that is not being done, which would be a bug.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:35:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 19 Oct 2016 12:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1337) A FQN inline cast followed
 by a method invocation causes an ArrayIndexOutOfBoundsException
In-Reply-To: <JIRA.12655753.1476894873000@Atlassian.JIRA>
References: <JIRA.12655753.1476894873000@Atlassian.JIRA>
	<JIRA.12655753.1476894873297@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655753.1476894873000.20071.1476894900349@Atlassian.JIRA>

Mario Fusco created DROOLS-1337:
-----------------------------------

             Summary: A FQN inline cast followed by a method invocation causes an ArrayIndexOutOfBoundsException
                 Key: DROOLS-1337
                 URL: https://issues.jboss.org/browse/DROOLS-1337
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco


An inline cast using a fully qualified name followed by a method invocation causes an ArrayIndexOutOfBoundsException as in the following test case:

{code}
    @Test
    public void testInlineCastWithFQNAndMethodInvocation() throws Exception {
        String str =
                "import org.drools.compiler.Person;\n" +
                "global java.util.List list;\n" +
                "rule R1 when\n" +
                "   Person( name == \"mark\", $x : address#org.drools.compiler.LongAddress.country.substring(1) )\n" +
                "then\n" +
                "   list.add($x);" +
                "end\n";

        KnowledgeBase kbase = loadKnowledgeBaseFromString(str);
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list", list );

        Person mark1 = new Person("mark");
        mark1.setAddress(new LongAddress("uk"));
        ksession.insert(mark1);

        assertEquals(1, ksession.fireAllRules());
        assertEquals(1, list.size());
        assertEquals("k", list.get(0));

        ksession.dispose();
    }
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:41:00 2016
From: issues at jboss.org (Eli Israel (JIRA))
Date: Wed, 19 Oct 2016 12:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1135) NullPointerExceptions when
 using multiple concurrent KieSessions
In-Reply-To: <JIRA.12616184.1461233727000@Atlassian.JIRA>
References: <JIRA.12616184.1461233727000@Atlassian.JIRA>
	<JIRA.12616184.1461233727000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616184.1461233727000.20099.1476895260532@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309396#comment-13309396 ] 

Eli Israel commented on DROOLS-1135:
------------------------------------

Any chance of a backport of this fix to 6.5.0 before it goes final? I know it's probably asking a lot, but I'm hitting this problem often and would rather not have do something ugly like a global lock around calls to rule engine execution.

I'm assuming that 7.0.0.Final is still some ways off and I'm looking for the safest, quickest way to fix this up for our production usage. Thanks for considering this.

> NullPointerExceptions when using multiple concurrent KieSessions
> ----------------------------------------------------------------
>
>                 Key: DROOLS-1135
>                 URL: https://issues.jboss.org/browse/DROOLS-1135
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 7.0.0.Beta1
>
>
> A number of worker threads is running simultaneously in a thread pool. Each thread is initialised with the same KieContainer from which they extract a KieBase using KieContainer.getKieBase("name"). Each worker thread obtains a KieSession from its KieBase, and then executes a simple loop, taking instructions from a queue, inserting and removing facts based on those instructions, and then firing all rules:
> {code}
> kieSession = kieBase.newKieSession();
> try {
>   while (true) {
>     work = getItemsFromQueue();
>     addAndRemoveFacts(kieSession, work);
>     kieSession.fireAllRules();
>   }
> } finally {
>   kieSession.dispose();
> }
> {code}
> This causes the following exceptions:
> {code}
> Exception in thread "Worker-1" java.lang.NullPointerException	at org.drools.core.reteoo.NodeTypeEnums.isLeftTupleSource(NodeTypeEnums.java:84)
> 	at org.drools.core.phreak.SegmentUtilities.updateRiaAndTerminalMemory(SegmentUtilities.java:380)
> 	at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:171)
> 	at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:205)
> 	at org.drools.core.phreak.SegmentUtilities.processQueryNode(SegmentUtilities.java:192)
> 	at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:115)
> 	at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:166)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> 	at com.X.processRequests(X.java:86)
> 	at com.X$$Lambda$104/975722152.run(Unknown Source)
> 	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}
> {code}
> Exception in thread "Worker-6" java.lang.NullPointerException	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> 	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> 	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> 	at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> 	at com.X.processRequests(X.java:86)
> 	at com.X$$Lambda$162/1410998625.run(Unknown Source)
> 	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}
> {code}
> Exception in thread "Worker-7" java.lang.NullPointerException	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> 	at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> 	at com.X.processRequests(X.java:86)
> 	at com.X$$Lambda$99/1591140286.run(Unknown Source)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:44:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 12:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1881) Add
 isCandidateDomainController() to LocalHostControllerInfo and use it where
 possible
In-Reply-To: <JIRA.12655759.1476895411000@Atlassian.JIRA>
References: <JIRA.12655759.1476895411000@Atlassian.JIRA>
	<JIRA.12655759.1476895411616@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655759.1476895411000.20116.1476895440320@Atlassian.JIRA>

Brian Stansberry created WFCORE-1881:
----------------------------------------

             Summary: Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
                 Key: WFCORE-1881
                 URL: https://issues.jboss.org/browse/WFCORE-1881
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Ken Wills


The WFCORE-338 work is going to add the notion of an HC being configured as a Candidate Domain Controller, which is a separate thing from being "master". There are a number of places where LocalHostControllerInfo.isMaster() is being called to make decisions that with WFCORE-338 should really depend on whether the HC is a CDC, not whether it is master. So, we want LHCI to expose whether the HC is a CDC.

I think initially we can have isCandidateDomainController() just return the result of isMaster(). We can add a setter to LocalHostControllerInfoImpl later when we actually make the CDC status independently configurable.

Places that should be updated as part of this task to use isCandidateDomainController() instead of isMaster():

1) ProfileCloneHandler
2) IgnoredDomainResourceRegistry



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:48:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 19 Oct 2016 12:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1135) NullPointerExceptions when
 using multiple concurrent KieSessions
In-Reply-To: <JIRA.12616184.1461233727000@Atlassian.JIRA>
References: <JIRA.12616184.1461233727000@Atlassian.JIRA>
	<JIRA.12616184.1461233727000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616184.1461233727000.20134.1476895680545@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309401#comment-13309401 ] 

Mario Fusco commented on DROOLS-1135:
-------------------------------------

[~eliasisrael] For what I can see that commit has been already cherry-picked to 6.5.x branch and then will be included in 6.5.0.Final https://github.com/droolsjbpm/drools/commit/88bee808d439276cc3fda808e8f95e248d09105e

> NullPointerExceptions when using multiple concurrent KieSessions
> ----------------------------------------------------------------
>
>                 Key: DROOLS-1135
>                 URL: https://issues.jboss.org/browse/DROOLS-1135
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 7.0.0.Beta1
>
>
> A number of worker threads is running simultaneously in a thread pool. Each thread is initialised with the same KieContainer from which they extract a KieBase using KieContainer.getKieBase("name"). Each worker thread obtains a KieSession from its KieBase, and then executes a simple loop, taking instructions from a queue, inserting and removing facts based on those instructions, and then firing all rules:
> {code}
> kieSession = kieBase.newKieSession();
> try {
>   while (true) {
>     work = getItemsFromQueue();
>     addAndRemoveFacts(kieSession, work);
>     kieSession.fireAllRules();
>   }
> } finally {
>   kieSession.dispose();
> }
> {code}
> This causes the following exceptions:
> {code}
> Exception in thread "Worker-1" java.lang.NullPointerException	at org.drools.core.reteoo.NodeTypeEnums.isLeftTupleSource(NodeTypeEnums.java:84)
> 	at org.drools.core.phreak.SegmentUtilities.updateRiaAndTerminalMemory(SegmentUtilities.java:380)
> 	at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:171)
> 	at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:205)
> 	at org.drools.core.phreak.SegmentUtilities.processQueryNode(SegmentUtilities.java:192)
> 	at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:115)
> 	at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:166)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> 	at com.X.processRequests(X.java:86)
> 	at com.X$$Lambda$104/975722152.run(Unknown Source)
> 	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}
> {code}
> Exception in thread "Worker-6" java.lang.NullPointerException	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> 	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> 	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> 	at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> 	at com.X.processRequests(X.java:86)
> 	at com.X$$Lambda$162/1410998625.run(Unknown Source)
> 	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}
> {code}
> Exception in thread "Worker-7" java.lang.NullPointerException	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> 	at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> 	at com.X.processRequests(X.java:86)
> 	at com.X$$Lambda$99/1591140286.run(Unknown Source)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:50:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 19 Oct 2016 12:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1845) Logging subsystem scans the
 CWD on server boot
In-Reply-To: <JIRA.12652897.1475276050000@Atlassian.JIRA>
References: <JIRA.12652897.1475276050000@Atlassian.JIRA>
	<JIRA.12652897.1475276050000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652897.1475276050000.20149.1476895800227@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309403#comment-13309403 ] 

James Perkins commented on WFCORE-1845:
---------------------------------------

[~heiko.braun] I looked at this a bit yesterday. I'll be talking to Brian more about it today. Hopefully by the end of the week or early next week we'll have something sorted out.

> Logging subsystem scans the CWD on server boot
> ----------------------------------------------
>
>                 Key: WFCORE-1845
>                 URL: https://issues.jboss.org/browse/WFCORE-1845
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 2.0.10.Final
>         Environment: OSX El Capitan, Oracle JDK 1.8.0_92 && 101, swarm 2016.8.1, WF 10.0.0.Final, WF-CORE 2.0.10.Final
>            Reporter: Brent Douglas
>            Assignee: James Perkins
>
> When booting the server from a directory where the subtree is large the server hangs for a long time. JStack shows that the logging subsystem is scanning the CWD.
> Booting the server from the root dir of a maven parent project containing 2 subprojects, a swarm project and a small NPM subproject added 33s to the server boot time compared to stepping into the swarm project and booting it.
> Stacktrace while the server is booting:
> {noformat}
> Thread 25859: (state = IN_NATIVE)
>  - sun.nio.fs.UnixNativeDispatcher.lstat0(long, sun.nio.fs.UnixFileAttributes) @bci=0 (Compiled frame; information may be imprecise)
>  - sun.nio.fs.UnixNativeDispatcher.lstat(sun.nio.fs.UnixPath, sun.nio.fs.UnixFileAttributes) @bci=10, line=300 (Compiled frame)
>  - sun.nio.fs.UnixFileAttributes.get(sun.nio.fs.UnixPath, boolean) @bci=22, line=72 (Compiled frame)
>  - sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes() @bci=15, line=52 (Compiled frame)
>  - sun.nio.fs.UnixFileSystemProvider.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=57, line=144 (Compiled frame)
>  - java.nio.file.Files.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=7, line=1737 (Compiled frame)
>  - java.nio.file.FileTreeWalker.getAttributes(java.nio.file.Path, boolean) @bci=56, line=219 (Compiled frame)
>  - java.nio.file.FileTreeWalker.visit(java.nio.file.Path, boolean, boolean) @bci=3, line=276 (Compiled frame)
>  - java.nio.file.FileTreeWalker.next() @bci=134, line=372 (Compiled frame)
>  - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.util.Set, int, java.nio.file.FileVisitor) @bci=256, line=2706 (Compiled frame)
>  - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.nio.file.FileVisitor) @bci=9, line=2742 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.findFiles(java.lang.String, org.jboss.dmr.ModelNode, boolean) @bci=47, line=251 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.getChildrenNames(java.lang.String) @bci=37, line=157 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.getChildren(java.lang.String) @bci=11, line=171 (Interpreted frame)
>  - org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(java.lang.String) @bci=5, line=362 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=99, line=289 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=189, line=291 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource) @bci=2, line=250 (Interpreted frame)
>  - org.jboss.as.controller.ModelControllerImpl.writeModel(org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl, java.util.Set) @bci=19, line=769 (Interpreted frame)
>  - org.jboss.as.controller.OperationContextImpl.createPersistenceResource() @bci=17, line=519 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.executeDoneStage(org.jboss.dmr.ModelNode) @bci=22, line=708 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.processStages() @bci=277, line=680 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.executeOperation() @bci=27, line=370 (Interpreted frame)
>  - org.jboss.as.controller.OperationContextImpl.executeOperation() @bci=20, line=1344 (Interpreted frame)
>  - org.jboss.as.controller.ModelControllerImpl.boot(java.util.List, org.jboss.as.controller.client.OperationMessageHandler, org.jboss.as.controller.ModelController$OperationTransactionControl, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider, boolean, boolean) @bci=410, line=485 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider) @bci=16, line=387 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean) @bci=7, line=349 (Interpreted frame)
>  - org.jboss.as.server.ServerService.boot(java.util.List, boolean) @bci=22, line=392 (Interpreted frame)
>  - org.jboss.as.server.ServerService.boot(org.jboss.as.controller.BootContext) @bci=907, line=365 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService$1.run() @bci=12, line=299 (Interpreted frame)
>  - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:52:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 12:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1882) Deal with WFCORE-1052
 functionality in the HA DC case
In-Reply-To: <JIRA.12655764.1476895893000@Atlassian.JIRA>
References: <JIRA.12655764.1476895893000@Atlassian.JIRA>
	<JIRA.12655764.1476895893397@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655764.1476895893000.20155.1476895920178@Atlassian.JIRA>

Brian Stansberry created WFCORE-1882:
----------------------------------------

             Summary: Deal with WFCORE-1052 functionality in the HA DC case
                 Key: WFCORE-1882
                 URL: https://issues.jboss.org/browse/WFCORE-1882
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry


WFCORE-1052 adds the ability to reload a process to a different config file from what it is currently running. That includes the domain-wide config file if the reloading process is a master HC.

I don't think we want to support this in a WFCORE-338 scenario, as it amounts to a mechanism to force a different domain-wide config into the domain. I think we should have a more specific, controlled mechanism for that.

Once WFCORE-1881 is implemented HostProcessReloadHandler can check LocalHostControllerInfo to see if its running in a CDC. Note that this issue may have implications on the design of WFCORE-1881. That is, it may not be the case that if LHCI.isMaster() is true then LHCI.isCandidateDomainController() is true. Perhaps an HC configured in the EAP 7.0 and earlier style could be a master but not a CDC. For such an HC the WFCORE-1052 functionality could be available. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:54:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 12:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1881) Add
 isCandidateDomainController() to LocalHostControllerInfo and use it where
 possible
In-Reply-To: <JIRA.12655759.1476895412000@Atlassian.JIRA>
References: <JIRA.12655759.1476895412000@Atlassian.JIRA>
	<JIRA.12655759.1476895412000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655759.1476895412000.20164.1476896040151@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309405#comment-13309405 ] 

Brian Stansberry commented on WFCORE-1881:
------------------------------------------

Note that the design of this needs to consider the issues raised in WFCORE-1882.

> Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
> --------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1881
>                 URL: https://issues.jboss.org/browse/WFCORE-1881
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Ken Wills
>
> The WFCORE-338 work is going to add the notion of an HC being configured as a Candidate Domain Controller, which is a separate thing from being "master". There are a number of places where LocalHostControllerInfo.isMaster() is being called to make decisions that with WFCORE-338 should really depend on whether the HC is a CDC, not whether it is master. So, we want LHCI to expose whether the HC is a CDC.
> I think initially we can have isCandidateDomainController() just return the result of isMaster(). We can add a setter to LocalHostControllerInfoImpl later when we actually make the CDC status independently configurable.
> Places that should be updated as part of this task to use isCandidateDomainController() instead of isMaster():
> 1) ProfileCloneHandler
> 2) IgnoredDomainResourceRegistry



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:57:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 12:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1883) Post-boot transition
 to/from acting as a master or slave HC must be done with management op
 execution locked out
In-Reply-To: <JIRA.12655770.1476896205000@Atlassian.JIRA>
References: <JIRA.12655770.1476896205000@Atlassian.JIRA>
	<JIRA.12655770.1476896205082@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655770.1476896205000.20170.1476896220424@Atlassian.JIRA>

Brian Stansberry created WFCORE-1883:
----------------------------------------

             Summary: Post-boot transition to/from acting as a master or slave HC must be done with management op execution locked out
                 Key: WFCORE-1883
                 URL: https://issues.jboss.org/browse/WFCORE-1883
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry


As part of WFCORE-338, a Candidate Domain Controller can shift between acting a master or acting as slave without requiring a reload or reboot.

However, after initial boot, a DCC can be handling management requests. Any transition between acting as a master or slave to the other role must ensure that in-process management requests are not disrupted and that no new management requests are able to access the management model or runtime services until the transition is complete. As a practical matter this likely means that the transition task(s) must acquire the exclusive management lock and hold it until the transition is complete.




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 12:59:00 2016
From: issues at jboss.org (Eli Israel (JIRA))
Date: Wed, 19 Oct 2016 12:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1135) NullPointerExceptions when
 using multiple concurrent KieSessions
In-Reply-To: <JIRA.12616184.1461233727000@Atlassian.JIRA>
References: <JIRA.12616184.1461233727000@Atlassian.JIRA>
	<JIRA.12616184.1461233727000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616184.1461233727000.20177.1476896340205@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309406#comment-13309406 ] 

Eli Israel commented on DROOLS-1135:
------------------------------------

Oh, thanks!

I missed that note in Github. Thanks for setting me straight. :)

> NullPointerExceptions when using multiple concurrent KieSessions
> ----------------------------------------------------------------
>
>                 Key: DROOLS-1135
>                 URL: https://issues.jboss.org/browse/DROOLS-1135
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 7.0.0.Beta1
>
>
> A number of worker threads is running simultaneously in a thread pool. Each thread is initialised with the same KieContainer from which they extract a KieBase using KieContainer.getKieBase("name"). Each worker thread obtains a KieSession from its KieBase, and then executes a simple loop, taking instructions from a queue, inserting and removing facts based on those instructions, and then firing all rules:
> {code}
> kieSession = kieBase.newKieSession();
> try {
>   while (true) {
>     work = getItemsFromQueue();
>     addAndRemoveFacts(kieSession, work);
>     kieSession.fireAllRules();
>   }
> } finally {
>   kieSession.dispose();
> }
> {code}
> This causes the following exceptions:
> {code}
> Exception in thread "Worker-1" java.lang.NullPointerException	at org.drools.core.reteoo.NodeTypeEnums.isLeftTupleSource(NodeTypeEnums.java:84)
> 	at org.drools.core.phreak.SegmentUtilities.updateRiaAndTerminalMemory(SegmentUtilities.java:380)
> 	at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:171)
> 	at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:205)
> 	at org.drools.core.phreak.SegmentUtilities.processQueryNode(SegmentUtilities.java:192)
> 	at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:115)
> 	at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:166)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> 	at com.X.processRequests(X.java:86)
> 	at com.X$$Lambda$104/975722152.run(Unknown Source)
> 	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}
> {code}
> Exception in thread "Worker-6" java.lang.NullPointerException	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> 	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> 	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> 	at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> 	at com.X.processRequests(X.java:86)
> 	at com.X$$Lambda$162/1410998625.run(Unknown Source)
> 	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}
> {code}
> Exception in thread "Worker-7" java.lang.NullPointerException	at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> 	at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> 	at com.X.processRequests(X.java:86)
> 	at com.X$$Lambda$99/1591140286.run(Unknown Source)
> 	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
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 13:20:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 19 Oct 2016 13:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7350) Frequent intermittent
 failures in coarse/fine web session passivation tests
In-Reply-To: <JIRA.12655772.1476897571000@Atlassian.JIRA>
References: <JIRA.12655772.1476897571000@Atlassian.JIRA>
	<JIRA.12655772.1476897571782@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655772.1476897571000.20232.1476897600593@Atlassian.JIRA>

Paul Ferraro created WFLY-7350:
----------------------------------

             Summary: Frequent intermittent failures in coarse/fine web session passivation tests
                 Key: WFLY-7350
                 URL: https://issues.jboss.org/browse/WFLY-7350
             Project: WildFly
          Issue Type: Bug
          Components: Clustering, Test Suite
    Affects Versions: 10.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 13:31:00 2016
From: issues at jboss.org (Edvin Syse (JIRA))
Date: Wed, 19 Oct 2016 13:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7351) JAX-RS Http Client does not
 support SNI even though underlying Apache HttpClient version supports it
In-Reply-To: <JIRA.12655773.1476898234000@Atlassian.JIRA>
References: <JIRA.12655773.1476898234000@Atlassian.JIRA>
	<JIRA.12655773.1476898234812@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655773.1476898234000.20301.1476898260415@Atlassian.JIRA>

Edvin Syse created WFLY-7351:
--------------------------------

             Summary: JAX-RS Http Client does not support SNI even though underlying Apache HttpClient version supports it
                 Key: WFLY-7351
                 URL: https://issues.jboss.org/browse/WFLY-7351
             Project: WildFly
          Issue Type: Bug
          Components: REST
    Affects Versions: 10.1.0.Final
         Environment: N/A
            Reporter: Edvin Syse
            Assignee: Stuart Douglas
         Attachments: httpclient-sni-bug.zip

When creating a JAX-RS client using ClientBuilder.newClient() and accessing an SSL resource configured with SNI, the request fails.

When the request is made you get the default certificate for the ip as it is configured on the web server instead of the certificate corresponding to the host name you entered.

Attached is a simple Maven project with a rest endpoint that will make a request to https://www.syse.no/, which is a host configured with SNI. If you access this host with a client that is not SNI capable, you will get the default certificate instead of the one corresponding to www.syse.no. (That cert is actually expired, so that is the underlying cause reported by the http client in this case. In other cases you will most probably just get a name mismatch type of error).

This effectively prevents the Http client from being used reliably against a rapidly growing number of SSL enabled sites, as SNI is the new standard "everywhere" SSL is configured these days.

The underlying Apache HttpClient version does indeed support SNI. I have tested the version of Apache HttpClient that is bundled with Wildfly 10.1 and it works correctly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 14:55:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 19 Oct 2016 14:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7351) JAX-RS Http Client does not
 support SNI even though underlying Apache HttpClient version supports it
In-Reply-To: <JIRA.12655773.1476898235000@Atlassian.JIRA>
References: <JIRA.12655773.1476898235000@Atlassian.JIRA>
	<JIRA.12655773.1476898235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655773.1476898235000.20623.1476903300381@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-7351:
---------------------------------

    Assignee: Alessio Soldano  (was: Stuart Douglas)


Could be that this is fixed in resteasy 3.1, but we need to check anyway.

> JAX-RS Http Client does not support SNI even though underlying Apache HttpClient version supports it
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7351
>                 URL: https://issues.jboss.org/browse/WFLY-7351
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 10.1.0.Final
>         Environment: N/A
>            Reporter: Edvin Syse
>            Assignee: Alessio Soldano
>              Labels: httpclient, https, jax-rs
>         Attachments: httpclient-sni-bug.zip
>
>
> When creating a JAX-RS client using ClientBuilder.newClient() and accessing an SSL resource configured with SNI, the request fails.
> When the request is made you get the default certificate for the ip as it is configured on the web server instead of the certificate corresponding to the host name you entered.
> Attached is a simple Maven project with a rest endpoint that will make a request to https://www.syse.no/, which is a host configured with SNI. If you access this host with a client that is not SNI capable, you will get the default certificate instead of the one corresponding to www.syse.no. (That cert is actually expired, so that is the underlying cause reported by the http client in this case. In other cases you will most probably just get a name mismatch type of error).
> This effectively prevents the Http client from being used reliably against a rapidly growing number of SSL enabled sites, as SNI is the new standard "everywhere" SSL is configured these days.
> The underlying Apache HttpClient version does indeed support SNI. I have tested the version of Apache HttpClient that is bundled with Wildfly 10.1 and it works correctly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 15:10:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 19 Oct 2016 15:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1884) Introduce discovery
	subsystem
In-Reply-To: <JIRA.12655787.1476904150000@Atlassian.JIRA>
References: <JIRA.12655787.1476904150000@Atlassian.JIRA>
	<JIRA.12655787.1476904150158@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655787.1476904150000.20667.1476904200299@Atlassian.JIRA>

David Lloyd created WFCORE-1884:
-----------------------------------

             Summary: Introduce discovery subsystem
                 Key: WFCORE-1884
                 URL: https://issues.jboss.org/browse/WFCORE-1884
             Project: WildFly Core
          Issue Type: Enhancement
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 3.0.0.Alpha10


Introduce discovery subsystem to be used by any other subsystem which can utilize discovery.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 15:27:00 2016
From: issues at jboss.org (Michael Peoples (JIRA))
Date: Wed, 19 Oct 2016 15:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.20705.1476905220156@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309460#comment-13309460 ] 

Michael Peoples commented on WFLY-6500:
---------------------------------------

We are experiencing similar behavior using WildFly 10.0.0 with Camunda BPM 7.5.3-ee.  I wish I could help with this, but I think the only resolution is to deploy using only one method and don't mix deployments place manually in the deployment directory with those deployed through the console GUI, command line interface, or management API interface.

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Jason Greene
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 15:32:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 19 Oct 2016 15:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.20731.1476905520238@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309463#comment-13309463 ] 

Tomaz Cerar commented on WFLY-6500:
-----------------------------------

Does this still happen on 10.1.0? As there was quite some fixes in this area


> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Jason Greene
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 16:01:00 2016
From: issues at jboss.org (Michael Peoples (JIRA))
Date: Wed, 19 Oct 2016 16:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.20915.1476907260549@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309474#comment-13309474 ] 

Michael Peoples commented on WFLY-6500:
---------------------------------------

I've no idea because we use a distribution of WildFly that is packaged with the Camunda distribution.  That said, there's probably nothing stopping us from using a separate WildFly distribution other than dependencies that Camunda resolves for us in the distribution package.  

I don't know if they're planning to bump the version.

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Jason Greene
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 16:02:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 19 Oct 2016 16:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-773)
 ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the
 thread pool executor
In-Reply-To: <JIRA.12575453.1434617524000@Atlassian.JIRA>
References: <JIRA.12575453.1434617524000@Atlassian.JIRA>
	<JIRA.12575453.1434617524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575453.1434617524000.20926.1476907320598@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309476#comment-13309476 ] 

Brian Stansberry commented on WFCORE-773:
-----------------------------------------

The linked PR fixing changes the management API description of the threads and jca subsystems. That's ok to do in a community major/EAP minor. We should bump the management API versions if the version has not been bumped already, but TBH I don't care that much. We don't actually use subsystem=threads any more.

>  ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-773
>                 URL: https://issues.jboss.org/browse/WFCORE-773
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Enrique Gonz?lez Mart?nez
>            Assignee: Petr Jurak
>
> BoundedQueueThreadPool does not support zero length queue setup.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Wed Oct 19 16:04:00 2016
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 19 Oct 2016 16:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-658) OAuth2 Resource Owner Password
 Credentials CallbackHandler
In-Reply-To: <JIRA.12654391.1476272184000@Atlassian.JIRA>
References: <JIRA.12654391.1476272184000@Atlassian.JIRA>
	<JIRA.12654391.1476272184000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654391.1476272184000.20940.1476907440749@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated ELY-658:
---------------------------
    Summary: OAuth2 Resource Owner Password Credentials CallbackHandler  (was: OAuth2 Resource Owner Password Credentials Callback)


> OAuth2 Resource Owner Password Credentials CallbackHandler
> ----------------------------------------------------------
>
>                 Key: ELY-658
>                 URL: https://issues.jboss.org/browse/ELY-658
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Callbacks
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with this grant type.
> This should also allow Elytron to support other grant types defined by OAuth2 in the future.
> Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].
> In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.
> [1] https://tools.ietf.org/html/rfc6749#page-9
> [2] https://openid.net/specs/openid-connect-discovery-1_0.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 16:05:00 2016
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 19 Oct 2016 16:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-658) OAuth2 Resource Owner Password
 Credentials CallbackHandler
In-Reply-To: <JIRA.12654391.1476272184000@Atlassian.JIRA>
References: <JIRA.12654391.1476272184000@Atlassian.JIRA>
	<JIRA.12654391.1476272184000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654391.1476272184000.20942.1476907500258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated ELY-658:
---------------------------
    Description: 
We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{CallbackHandler}} that could be used to handle all the necessary logic related with this grant type.

This should also allow Elytron to support other grant types defined by OAuth2 in the future.

Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].

In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.

[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html

  was:
We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with this grant type.

This should also allow Elytron to support other grant types defined by OAuth2 in the future.

Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].

In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.

[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html



> OAuth2 Resource Owner Password Credentials CallbackHandler
> ----------------------------------------------------------
>
>                 Key: ELY-658
>                 URL: https://issues.jboss.org/browse/ELY-658
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Callbacks
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{CallbackHandler}} that could be used to handle all the necessary logic related with this grant type.
> This should also allow Elytron to support other grant types defined by OAuth2 in the future.
> Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].
> In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.
> [1] https://tools.ietf.org/html/rfc6749#page-9
> [2] https://openid.net/specs/openid-connect-discovery-1_0.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 16:09:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 19 Oct 2016 16:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.20953.1476907740254@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309480#comment-13309480 ] 

Tomaz Cerar commented on WFLY-6500:
-----------------------------------

you can manually install camuda into 10.1, see docs on how to do that https://docs.camunda.org/manual/7.5/installation/full/jboss/manual/

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Jason Greene
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 16:24:00 2016
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 19 Oct 2016 16:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-675) OAuth2 Client Credentials
	CallbackHandler
In-Reply-To: <JIRA.12655793.1476908639000@Atlassian.JIRA>
References: <JIRA.12655793.1476908639000@Atlassian.JIRA>
	<JIRA.12655793.1476908639287@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655793.1476908639000.21071.1476908640059@Atlassian.JIRA>

Pedro Igor created ELY-675:
------------------------------

             Summary: OAuth2 Client Credentials CallbackHandler
                 Key: ELY-675
                 URL: https://issues.jboss.org/browse/ELY-675
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: Callbacks
    Affects Versions: 1.1.0.Beta11
            Reporter: Pedro Igor
            Assignee: Pedro Igor






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 16:25:00 2016
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Wed, 19 Oct 2016 16:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.21075.1476908700343@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309494#comment-13309494 ] 

Frank Langelage commented on WFLY-6500:
---------------------------------------

Next version of Camunda will we packaged with Wildfly 10.1. See https://app.camunda.com/jira/browse/CAM-6790.

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Jason Greene
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 16:25:00 2016
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 19 Oct 2016 16:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-658) OAuth2 Resource Owner Password
 Credentials CallbackHandler
In-Reply-To: <JIRA.12654391.1476272184000@Atlassian.JIRA>
References: <JIRA.12654391.1476272184000@Atlassian.JIRA>
	<JIRA.12654391.1476272184000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654391.1476272184000.21085.1476908700779@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated ELY-658:
---------------------------
    Description: 
We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{CallbackHandler}} that could be used to handle all the necessary logic related with this grant type.

This should also allow Elytron to support other grant types defined by OAuth2 in the future.

Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].

[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html

  was:
We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{CallbackHandler}} that could be used to handle all the necessary logic related with this grant type.

This should also allow Elytron to support other grant types defined by OAuth2 in the future.

Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].

In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.

[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html



> OAuth2 Resource Owner Password Credentials CallbackHandler
> ----------------------------------------------------------
>
>                 Key: ELY-658
>                 URL: https://issues.jboss.org/browse/ELY-658
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Callbacks
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{CallbackHandler}} that could be used to handle all the necessary logic related with this grant type.
> This should also allow Elytron to support other grant types defined by OAuth2 in the future.
> Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].
> [1] https://tools.ietf.org/html/rfc6749#page-9
> [2] https://openid.net/specs/openid-connect-discovery-1_0.html



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 16:36:00 2016
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Wed, 19 Oct 2016 16:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7351) JAX-RS Http Client does not
 support SNI even though underlying Apache HttpClient version supports it
In-Reply-To: <JIRA.12655773.1476898235000@Atlassian.JIRA>
References: <JIRA.12655773.1476898235000@Atlassian.JIRA>
	<JIRA.12655773.1476898235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655773.1476898235000.21103.1476909360341@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309497#comment-13309497 ] 

Alessio Soldano commented on WFLY-7351:
---------------------------------------

need to check, likely related to https://issues.jboss.org/browse/RESTEASY-1431 (which is in 3.1 only)

> JAX-RS Http Client does not support SNI even though underlying Apache HttpClient version supports it
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7351
>                 URL: https://issues.jboss.org/browse/WFLY-7351
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 10.1.0.Final
>         Environment: N/A
>            Reporter: Edvin Syse
>            Assignee: Alessio Soldano
>              Labels: httpclient, https, jax-rs
>         Attachments: httpclient-sni-bug.zip
>
>
> When creating a JAX-RS client using ClientBuilder.newClient() and accessing an SSL resource configured with SNI, the request fails.
> When the request is made you get the default certificate for the ip as it is configured on the web server instead of the certificate corresponding to the host name you entered.
> Attached is a simple Maven project with a rest endpoint that will make a request to https://www.syse.no/, which is a host configured with SNI. If you access this host with a client that is not SNI capable, you will get the default certificate instead of the one corresponding to www.syse.no. (That cert is actually expired, so that is the underlying cause reported by the http client in this case. In other cases you will most probably just get a name mismatch type of error).
> This effectively prevents the Http client from being used reliably against a rapidly growing number of SSL enabled sites, as SNI is the new standard "everywhere" SSL is configured these days.
> The underlying Apache HttpClient version does indeed support SNI. I have tested the version of Apache HttpClient that is bundled with Wildfly 10.1 and it works correctly.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Oct 19 17:16:02 2016
From: issues at jboss.org (Michael Peoples (JIRA))
Date: Wed, 19 Oct 2016 17:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.21192.1476911762225@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309508#comment-13309508 ] 

Michael Peoples commented on WFLY-6500:
---------------------------------------

The Camunda fix is for 7.6, which is still in Alpha testing.  I'll see about doing a manual setup. And get back to you.

I'm not sure this condition is consistently reproducible, unless someone has a specific sequence of steps to cause it.  Examination of the logs showed nothing more than the new deployment being rejected because a similar deployment was already registered.  Even switching version numbers didn't help.  However, I'm not sure what circumstances are required to reproduce the server crash.

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Jason Greene
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 01:28:00 2016
From: issues at jboss.org (Petr Jurak (JIRA))
Date: Thu, 20 Oct 2016 01:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-773)
 ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the
 thread pool executor
In-Reply-To: <JIRA.12575453.1434617524000@Atlassian.JIRA>
References: <JIRA.12575453.1434617524000@Atlassian.JIRA>
	<JIRA.12575453.1434617524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575453.1434617524000.21696.1476941280223@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309567#comment-13309567 ] 

Petr Jurak commented on WFCORE-773:
-----------------------------------

Yes, this legacy system is not used anymore. The intention was to make this change because the source code still contains the old code.

>  ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-773
>                 URL: https://issues.jboss.org/browse/WFCORE-773
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Enrique Gonz?lez Mart?nez
>            Assignee: Petr Jurak
>
> BoundedQueueThreadPool does not support zero length queue setup.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 01:47:00 2016
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Thu, 20 Oct 2016 01:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.21732.1476942420249@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309570#comment-13309570 ] 

jaikiran pai commented on WFLY-6500:
------------------------------------

{quote}
Examination of the logs showed nothing more than the new deployment being rejected because a similar deployment was already registered.
{quote}

Can you paste that log message(s) here? Or better still, upload the server.log file?


> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Jason Greene
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 03:24:00 2016
From: issues at jboss.org (Hiroko Miura (JIRA))
Date: Thu, 20 Oct 2016 03:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1338) NPE happens in
 TupleSetsImpl.setNextTuple()
In-Reply-To: <JIRA.12655819.1476948236000@Atlassian.JIRA>
References: <JIRA.12655819.1476948236000@Atlassian.JIRA>
	<JIRA.12655819.1476948236573@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655819.1476948236000.22071.1476948240859@Atlassian.JIRA>

Hiroko Miura created DROOLS-1338:
------------------------------------

             Summary: NPE happens in TupleSetsImpl.setNextTuple()
                 Key: DROOLS-1338
                 URL: https://issues.jboss.org/browse/DROOLS-1338
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.4.0.Final
            Reporter: Hiroko Miura
            Assignee: Mario Fusco
            Priority: Critical


In customer's performance test case, NPE happens in TupleSetsImpl.setNextTuple() with the following stack.

java.lang.NullPointerException
	at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:352)
	at org.drools.core.common.TupleSetsImpl.removeInsert(TupleSetsImpl.java:168)
	at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729)
	at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721)
	at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343)
	at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74)
	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341)
	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:692)
	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629)
	at org.drools.core.reteoo.NotNode.assertObject(NotNode.java:161)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304)
	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:132)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:82)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:72)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2053)
	at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:960)
	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1303)
	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1241)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1336)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1327)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1308)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 03:32:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 20 Oct 2016 03:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1338) NPE happens in
 TupleSetsImpl.setNextTuple()
In-Reply-To: <JIRA.12655819.1476948237000@Atlassian.JIRA>
References: <JIRA.12655819.1476948237000@Atlassian.JIRA>
	<JIRA.12655819.1476948237000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655819.1476948237000.22101.1476948720208@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309601#comment-13309601 ] 

Mario Fusco commented on DROOLS-1338:
-------------------------------------

[~hiroko] Where can I find a reproducer for this issue?

> NPE happens in TupleSetsImpl.setNextTuple()
> -------------------------------------------
>
>                 Key: DROOLS-1338
>                 URL: https://issues.jboss.org/browse/DROOLS-1338
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>            Reporter: Hiroko Miura
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: support
>
> In customer's performance test case, NPE happens in TupleSetsImpl.setNextTuple() with the following stack.
> java.lang.NullPointerException
> 	at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:352)
> 	at org.drools.core.common.TupleSetsImpl.removeInsert(TupleSetsImpl.java:168)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721)
> 	at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343)
> 	at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:692)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629)
> 	at org.drools.core.reteoo.NotNode.assertObject(NotNode.java:161)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:132)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:82)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:72)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2053)
> 	at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:960)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1303)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1241)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1336)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1327)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1308)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 03:32:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 20 Oct 2016 03:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1338) NPE happens in
 TupleSetsImpl.setNextTuple()
In-Reply-To: <JIRA.12655819.1476948237000@Atlassian.JIRA>
References: <JIRA.12655819.1476948237000@Atlassian.JIRA>
	<JIRA.12655819.1476948237000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655819.1476948237000.22104.1476948720296@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-1338:
--------------------------------
    Comment: was deleted

(was: [~hiroko] Where can I find a reproducer for this issue?)


> NPE happens in TupleSetsImpl.setNextTuple()
> -------------------------------------------
>
>                 Key: DROOLS-1338
>                 URL: https://issues.jboss.org/browse/DROOLS-1338
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>            Reporter: Hiroko Miura
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: support
>
> In customer's performance test case, NPE happens in TupleSetsImpl.setNextTuple() with the following stack.
> java.lang.NullPointerException
> 	at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:352)
> 	at org.drools.core.common.TupleSetsImpl.removeInsert(TupleSetsImpl.java:168)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721)
> 	at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343)
> 	at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:692)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629)
> 	at org.drools.core.reteoo.NotNode.assertObject(NotNode.java:161)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:132)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:82)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:72)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2053)
> 	at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:960)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1303)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1241)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1336)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1327)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1308)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 03:42:00 2016
From: issues at jboss.org (Hiroko Miura (JIRA))
Date: Thu, 20 Oct 2016 03:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1339) NPE happens in
 TupleSetsImpl.setNextTuple()
In-Reply-To: <JIRA.12655824.1476949288000@Atlassian.JIRA>
References: <JIRA.12655824.1476949288000@Atlassian.JIRA>
	<JIRA.12655824.1476949288657@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655824.1476949288000.22141.1476949320175@Atlassian.JIRA>

Hiroko Miura created DROOLS-1339:
------------------------------------

             Summary: NPE happens in TupleSetsImpl.setNextTuple()
                 Key: DROOLS-1339
                 URL: https://issues.jboss.org/browse/DROOLS-1339
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.4.0.Final
            Reporter: Hiroko Miura
            Assignee: Mario Fusco
            Priority: Critical


In customer's performance test case, NPE happens in TupleSetsImpl.setNextTuple() with the following stack.

java.lang.NullPointerException
	at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:352)
	at org.drools.core.common.TupleSetsImpl.removeInsert(TupleSetsImpl.java:168)
	at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:729)
	at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:721)
	at org.drools.core.phreak.PhreakNotNode.doRightUpdates(PhreakNotNode.java:343)
	at org.drools.core.phreak.PhreakNotNode.doNode(PhreakNotNode.java:74)
	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:524)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341)
	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:692)
	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:629)
	at org.drools.core.reteoo.NotNode.assertObject(NotNode.java:161)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:304)
	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:132)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:82)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:72)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2053)
	at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:960)
	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1303)
	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1241)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1336)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1327)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1308)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 04:03:00 2016
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Thu, 20 Oct 2016 04:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1340) IndexOutOfBoundsException
 when using query with 2 entry points
In-Reply-To: <JIRA.12655828.1476950543000@Atlassian.JIRA>
References: <JIRA.12655828.1476950543000@Atlassian.JIRA>
	<JIRA.12655828.1476950543515@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655828.1476950543000.22275.1476950580396@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-1340:
-------------------------------------

             Summary: IndexOutOfBoundsException when using query with 2 entry points
                 Key: DROOLS-1340
                 URL: https://issues.jboss.org/browse/DROOLS-1340
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Mario Fusco


Sometimes, when using query with 2 entry points along with fireUntilHalt, the method getQueryResults fails with IndexOutOfBoundsException. See stacktrace here [1]. This was observed first in Jenkins environment running existing test QueryCepFireUntilHaltTest.withResultTest from drools repository. I managed to reproduce it locally looping the test with this code: 

@Test
    public void testBla() {
        for (int i = 0; i < 10000; i++) {
            prepare();
            try {
                withResultTest();
            } finally {
                cleanup();
            }
        }
    }

[1] http://pastebin.com/BBPsGty9



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 04:04:00 2016
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 20 Oct 2016 04:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1837) manual module testoutput is a
 bit disturbing NPE and dependencies missing
In-Reply-To: <JIRA.12498051.1375789235000@Atlassian.JIRA>
References: <JIRA.12498051.1375789235000@Atlassian.JIRA>
	<JIRA.12498051.1375789235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498051.1375789235000.22282.1476950640430@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned WFLY-1837:
-----------------------------------

    Assignee: Carlo de Wolf  (was: JBoss SET)


> manual module testoutput is a bit disturbing NPE and dependencies missing
> -------------------------------------------------------------------------
>
>                 Key: WFLY-1837
>                 URL: https://issues.jboss.org/browse/WFLY-1837
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Bartosz Baranowski
>            Assignee: Carlo de Wolf
>
> Manual testmodule shows a lot of NPEs and dependency issues:
> {noformat}
> [org.jboss.as.ejb3] (EJB default - 2) JBAS014249: Error invoking method public abstract void org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch.testDone() on bean named LatchBean for appname  modulename dep1 distinctname : java.lang.NullPointerException
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	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)
> 13:06:07,613 ERROR [org.jboss.as.ejb3] (EJB default - 2) JBAS014250: Could not write method invocation failure for method public abstract void org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch.testDone() on bean named LatchBean for appname  modulename dep1 distinctname  due to: java.io.IOException: Stream is closed
> 	at org.xnio.streams.BufferPipeOutputStream.closed(BufferPipeOutputStream.java:58) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.xnio.streams.BufferPipeOutputStream.checkClosed(BufferPipeOutputStream.java:64) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.xnio.streams.BufferPipeOutputStream.write(BufferPipeOutputStream.java:90) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.jboss.remoting3.remote.OutboundMessage.write(OutboundMessage.java:252)
> 	at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_25]
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler$1.write(AbstractMessageHandler.java:217)
> 	at org.jboss.marshalling.OutputStreamByteOutput.write(OutputStreamByteOutput.java:56)
> 	at org.jboss.marshalling.SimpleDataOutput.shallowFlush(SimpleDataOutput.java:328)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeString(RiverMarshaller.java:1451)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeNewSerializableClass(RiverMarshaller.java:1362)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeSerializableClass(RiverMarshaller.java:1345)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:883)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverObjectOutputStream.defaultWriteObject(RiverObjectOutputStream.java:159)
> 	at java.lang.Throwable.writeObject(Throwable.java:984) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:180)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:112)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$400(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:213)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	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)
> Caused by: an exception which occurred:
> 	in field suppressedExceptions
> 	in object java.lang.NullPointerException at 18e5c476
> {noformat}
> {noformat}
> 13:01:23,032 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014612: Operation ("add") failed - address: ([
>     ("host" => "master"),
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.operations.HttpManagementAddHandler.installHttpManagementServices(HttpManagementAddHandler.java:137) [wildfly-host-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> 	at org.jboss.as.host.controller.operations.HttpManagementAddHandler.performRuntime(HttpManagementAddHandler.java:97) [wildfly-host-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> {noformat}
> {noformat}
> 13:01:23,493 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014613: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("management-interface" => "native-interface")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => [
>     "jboss.remoting.authentication_provider.management is missing [jboss.server.path.\"jboss.server.temp.dir\"]",
>     "jboss.remoting.endpoint.management.management.operation.handler is missing [jboss.as.server-controller]",
>     "jboss.remoting.endpoint.management.channel.management is missing [jboss.remoting.endpoint.management.shutdown.executor]",
>     "jboss.remoting.server.management is missing [jboss.binding.management-native, jboss.socket-binding-manager]"
> ]}
> 13:01:23,494 INFO  [org.jboss.as.controller] (pool-2-thread-1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.as.server-controller (missing) dependents: [service jboss.remoting.endpoint.management.management.operation.handler] 
>       service jboss.binding.management-native (missing) dependents: [service jboss.remoting.server.management] 
>       service jboss.remoting.endpoint.management.shutdown.executor (missing) dependents: [service jboss.remoting.endpoint.management.channel.management] 
>       service jboss.server.path."jboss.server.temp.dir" (missing) dependents: [service jboss.remoting.authentication_provider.management] 
>       service jboss.socket-binding-manager (missing) dependents: [service jboss.remoting.server.management] 
> 13:01:23,495 INFO  [org.jboss.as.server] (pool-2-thread-1) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:01:23,496 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.server.environment not found
> 	at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:1068) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 04:04:00 2016
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Thu, 20 Oct 2016 04:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1340) IndexOutOfBoundsException
 when using query with 2 entry points
In-Reply-To: <JIRA.12655828.1476950544000@Atlassian.JIRA>
References: <JIRA.12655828.1476950544000@Atlassian.JIRA>
	<JIRA.12655828.1476950544000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655828.1476950544000.22285.1476950640577@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tibor Zim?nyi updated DROOLS-1340:
----------------------------------
    Description: 
Sometimes, when using query with 2 entry points along with fireUntilHalt, the method getQueryResults fails with IndexOutOfBoundsException. See stacktrace here [1]. This was observed first in Jenkins environment running existing test QueryCepFireUntilHaltTest.withResultTest from drools repository. I managed to reproduce it locally looping the test with this code [2]. 

[1] http://pastebin.com/BBPsGty9
[2] http://pastebin.com/47y1dh1W

  was:
Sometimes, when using query with 2 entry points along with fireUntilHalt, the method getQueryResults fails with IndexOutOfBoundsException. See stacktrace here [1]. This was observed first in Jenkins environment running existing test QueryCepFireUntilHaltTest.withResultTest from drools repository. I managed to reproduce it locally looping the test with this code: 

@Test
    public void testBla() {
        for (int i = 0; i < 10000; i++) {
            prepare();
            try {
                withResultTest();
            } finally {
                cleanup();
            }
        }
    }

[1] http://pastebin.com/BBPsGty9



> IndexOutOfBoundsException when using query with 2 entry points
> --------------------------------------------------------------
>
>                 Key: DROOLS-1340
>                 URL: https://issues.jboss.org/browse/DROOLS-1340
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Mario Fusco
>              Labels: reported-by-qe
>
> Sometimes, when using query with 2 entry points along with fireUntilHalt, the method getQueryResults fails with IndexOutOfBoundsException. See stacktrace here [1]. This was observed first in Jenkins environment running existing test QueryCepFireUntilHaltTest.withResultTest from drools repository. I managed to reproduce it locally looping the test with this code [2]. 
> [1] http://pastebin.com/BBPsGty9
> [2] http://pastebin.com/47y1dh1W



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 04:05:00 2016
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 20 Oct 2016 04:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1837) manual module testoutput is a
 bit disturbing NPE and dependencies missing
In-Reply-To: <JIRA.12498051.1375789235000@Atlassian.JIRA>
References: <JIRA.12498051.1375789235000@Atlassian.JIRA>
	<JIRA.12498051.1375789235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498051.1375789235000.22298.1476950700798@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved WFLY-1837.
---------------------------------
    Resolution: Out of Date


This bug has been filed against a WildFly version that is no longer in use.

If you would still like to see this bug fixed and are able to reproduce it against the latest version of WildFly, you are encouraged change the 'version' and reopen the bug.

> manual module testoutput is a bit disturbing NPE and dependencies missing
> -------------------------------------------------------------------------
>
>                 Key: WFLY-1837
>                 URL: https://issues.jboss.org/browse/WFLY-1837
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Bartosz Baranowski
>            Assignee: Carlo de Wolf
>
> Manual testmodule shows a lot of NPEs and dependency issues:
> {noformat}
> [org.jboss.as.ejb3] (EJB default - 2) JBAS014249: Error invoking method public abstract void org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch.testDone() on bean named LatchBean for appname  modulename dep1 distinctname : java.lang.NullPointerException
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	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)
> 13:06:07,613 ERROR [org.jboss.as.ejb3] (EJB default - 2) JBAS014250: Could not write method invocation failure for method public abstract void org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch.testDone() on bean named LatchBean for appname  modulename dep1 distinctname  due to: java.io.IOException: Stream is closed
> 	at org.xnio.streams.BufferPipeOutputStream.closed(BufferPipeOutputStream.java:58) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.xnio.streams.BufferPipeOutputStream.checkClosed(BufferPipeOutputStream.java:64) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.xnio.streams.BufferPipeOutputStream.write(BufferPipeOutputStream.java:90) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.jboss.remoting3.remote.OutboundMessage.write(OutboundMessage.java:252)
> 	at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_25]
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler$1.write(AbstractMessageHandler.java:217)
> 	at org.jboss.marshalling.OutputStreamByteOutput.write(OutputStreamByteOutput.java:56)
> 	at org.jboss.marshalling.SimpleDataOutput.shallowFlush(SimpleDataOutput.java:328)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeString(RiverMarshaller.java:1451)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeNewSerializableClass(RiverMarshaller.java:1362)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeSerializableClass(RiverMarshaller.java:1345)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:883)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverObjectOutputStream.defaultWriteObject(RiverObjectOutputStream.java:159)
> 	at java.lang.Throwable.writeObject(Throwable.java:984) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:180)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:112)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$400(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:213)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	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)
> Caused by: an exception which occurred:
> 	in field suppressedExceptions
> 	in object java.lang.NullPointerException at 18e5c476
> {noformat}
> {noformat}
> 13:01:23,032 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014612: Operation ("add") failed - address: ([
>     ("host" => "master"),
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.operations.HttpManagementAddHandler.installHttpManagementServices(HttpManagementAddHandler.java:137) [wildfly-host-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> 	at org.jboss.as.host.controller.operations.HttpManagementAddHandler.performRuntime(HttpManagementAddHandler.java:97) [wildfly-host-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> {noformat}
> {noformat}
> 13:01:23,493 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014613: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("management-interface" => "native-interface")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => [
>     "jboss.remoting.authentication_provider.management is missing [jboss.server.path.\"jboss.server.temp.dir\"]",
>     "jboss.remoting.endpoint.management.management.operation.handler is missing [jboss.as.server-controller]",
>     "jboss.remoting.endpoint.management.channel.management is missing [jboss.remoting.endpoint.management.shutdown.executor]",
>     "jboss.remoting.server.management is missing [jboss.binding.management-native, jboss.socket-binding-manager]"
> ]}
> 13:01:23,494 INFO  [org.jboss.as.controller] (pool-2-thread-1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.as.server-controller (missing) dependents: [service jboss.remoting.endpoint.management.management.operation.handler] 
>       service jboss.binding.management-native (missing) dependents: [service jboss.remoting.server.management] 
>       service jboss.remoting.endpoint.management.shutdown.executor (missing) dependents: [service jboss.remoting.endpoint.management.channel.management] 
>       service jboss.server.path."jboss.server.temp.dir" (missing) dependents: [service jboss.remoting.authentication_provider.management] 
>       service jboss.socket-binding-manager (missing) dependents: [service jboss.remoting.server.management] 
> 13:01:23,495 INFO  [org.jboss.as.server] (pool-2-thread-1) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:01:23,496 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.server.environment not found
> 	at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:1068) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 04:06:01 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 20 Oct 2016 04:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7352) XNIO bridge for Artemis
 doesn't work with newer versions of Netty and Artemis.
In-Reply-To: <JIRA.12655834.1476950731000@Atlassian.JIRA>
References: <JIRA.12655834.1476950731000@Atlassian.JIRA>
	<JIRA.12655834.1476950731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655834.1476950731000.22325.1476950761026@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-6518 to WFLY-7352:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7352  (was: JBEAP-6518)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JMS
                           (was: ActiveMQ)
    Affects Version/s:     (was: 7.1.0.DR6)


> XNIO bridge for Artemis doesn't work with newer versions of Netty and Artemis.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7352
>                 URL: https://issues.jboss.org/browse/WFLY-7352
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> Test scenario:
> 1. Start server EAP 7.1.0.DR6 (with Artemis 1.4.0) with queue InQueue and OutQueue. Configure non-exclusive divert from InQueue to OutQueue.
> 2. Send large message to InQueue with scheduled delivery 10 seconds
> 3. Start consumer on OutQueue with receive timeout 1000ms and check that NO message was received
> 4. Start consumer on InQueue with receive timeout 1000ms and check that NO message was received
> 5. Start consumer on InQueue with receive timeout 11000ms and check that message is received
> 6. Start consumer on OutQueue with receive timeout 11000ms and check that message is received
> Result:
> Sometimes happens that consumer in step 3. receives a message. By checking trace logs, consumer in step 3. was receiving message 9664ms instead of ~1000ms.
> In attachment is trace log from client and server and test log with client thread dump during ~10s receive.
> Investigation:
> In the moment when client tries to receive a message there is send SessionForceConsumerDelivery packet by client:
> {code}
> 15:07:07,589 Thread-11 INFO  [org.jboss.qa.artemis.test.messages.JmsMessagesTestCase$ReceiveThread:474] Start message comsumption from original queue with receive timeout 1000ms
> 15:07:07,590 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:386] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}:: receive(1000)
> 15:07:07,590 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:191] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::receive(1000, false)
> 15:07:08,591 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:370] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::Returning null
> 15:07:08,591 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:392] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}:: receive(1000) -> null, trying again with receive(0)
> 15:07:08,591 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:191] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::receive(0, true)
> 15:07:08,592 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:301] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::Forcing delivery
> 15:07:08,593 Thread-11 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl:248] Sending packet nonblocking PACKET(SessionForceConsumerDelivery)[type=78, channelID=11, packetObject=SessionForceConsumerDelivery, consumerID=0, sequence=0] on channeID=11
> 15:07:08,604 Thread-11 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl:286] Writing buffer for channelID=11
> {code}
> Response from server comes ~10s later - it's packet SessionReceiveMessage:
> {code}
> 15:07:17,250 Thread-0 (ActiveMQ-client-netty-threads-1138697171) TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl:354] handling packet PACKET(SessionReceiveMessage)[type=75, chan
> nelID=11, packetObject=SessionReceiveMessage, message=ClientMessageImpl[messageID=44, durable=false, address=jms.queue.OutQueue,userID=null,properties=TypedProperties[_hornetq.forced.delivery.seq=0]], consumerID
> =0, deliveryCount=0]
> {code}
> in the mean time client is waiting on - ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:261):
> {noformat}
>  wait(Long.MAX_VALUE);
> {noformat}
> and is waiting for notify. From server log I can see that SessionReceiveMessage was send at:
> {code}
> 15:07:08,621 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 39cb2b3a-1512482465)) Sending packet nonblocking PACKET(SessionReceiveMessage)[type=75, channelID=11, packetObject=SessionReceiveMessage, message=ServerMessage[messageID=44,durable=false,userID=null,priority=0, bodySize=50, timestamp=0,expiration=0, durable=false, address=jms.queue.OutQueue,properties=TypedProperties[_hornetq.forced.delivery.seq=0]]@1525441837, consumerID=0, deliveryCount=0] on channeID=11
> 15:07:08,633 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 39cb2b3a-1512482465)) Writing buffer for channelID=11
> {code}
> but it wasn't flushed and for some reason is actually send ~10s later with the large message:
> {code}
> 15:07:17,236 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-27 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 39cb2b3a-1512482465)) Sending pa
> cket nonblocking PACKET(SessionReceiveLargeMessage)[type=76, channelID=11, packetObject=SessionReceiveLargeMessage, consumerID=0, deliveryCount=1, largeMessageSize=409605, message=LargeServerMessage[messageID=40
> ,durable=true,userID=1befe4c2-920f-11e6-9ae8-3ca9f4349bfc,priority=4, timestamp=Fri Oct 14 15:07:07 CEST 2016,expiration=0, durable=true, address=jms.queue.OutQueue,properties=TypedProperties[__AMQ_CID=1bdc35af-
> 920f-11e6-9ae8-3ca9f4349bfc,_AMQ_SCHED_DELIVERY=1476450437224,_AMQ_ORIG_ADDRESS=jms.queue.InQueue,_AMQ_ORIG_MESSAGE_ID=36,counter=0,_AMQ_DUPL_ID=16c2be09-573a-4e02-a369-6a36c2f32fbd,_AMQ_LARGE_SIZE=409605]]@1994
> 218683] on channeID=11
> 15:07:17,246 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-27 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 39cb2b3a-1512482465)) Writing bu
> ffer for channelID=11
> 15:07:17,247 TRACE [org.xnio.nio.selector] (default I/O-1) Selected on sun.nio.ch.EPollSelectorImpl at 61ea580a
> 15:07:17,247 TRACE [org.xnio.nio] (default I/O-1) Running task io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask at 5c93c5d7
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 04:54:01 2016
From: issues at jboss.org (Teresa Miyar (JIRA))
Date: Thu, 20 Oct 2016 04:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7353) CDI bean-discovery-mode does
 not default to "annotated"
In-Reply-To: <JIRA.12655839.1476952393000@Atlassian.JIRA>
References: <JIRA.12655839.1476952393000@Atlassian.JIRA>
	<JIRA.12655839.1476952393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655839.1476952393000.22522.1476953641256@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Teresa Miyar updated WFLY-7353:
-------------------------------
    Security:     (was: Security Issue)


> CDI bean-discovery-mode does not default to "annotated"
> -------------------------------------------------------
>
>                 Key: WFLY-7353
>                 URL: https://issues.jboss.org/browse/WFLY-7353
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final
>         Environment: EAP 7.0.2
>            Reporter: Teresa Miyar
>            Assignee: Stuart Douglas
>              Labels: support
>         Attachments: demo-war-2.zip
>
>
> bean-discovery-mode does not default to "annotated" when you have a beans.xml version 1.1 without setting the discovery mode. That means that the bean without annotation gets injected.
> To reproduce:
> Download attached war, run into EAP 7.0.2, point browser to demo-war/servlet, check logs
> result:
> I see the log from bean call
> expected result:
> either WFLYCTL0184:    New missing/unsatisfied dependencies on startup, or null pointer exception when accessing the servlet.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 05:06:02 2016
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Thu, 20 Oct 2016 05:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7354) Custom NameService by
 sun.net.spi.nameservice.provider.n doesn't work on WildFly
In-Reply-To: <JIRA.12655844.1476954323000@Atlassian.JIRA>
References: <JIRA.12655844.1476954323000@Atlassian.JIRA>
	<JIRA.12655844.1476954323285@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655844.1476954323000.22628.1476954362093@Atlassian.JIRA>

Osamu Nagano created WFLY-7354:
----------------------------------

             Summary: Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly
                 Key: WFLY-7354
                 URL: https://issues.jboss.org/browse/WFLY-7354
             Project: WildFly
          Issue Type: Bug
          Components: Class Loading
    Affects Versions: 10.1.0.Final
            Reporter: Osamu Nagano
            Assignee: David Lloyd
         Attachments: nameserviceProviderTest.zip

System property {{sun.net.spi.nameservice.provider.<n>}} allows a user to customize a NameService. It works on a standalone java, which is using JBoss Modules, if {{services="import"}} is added on sun.jdk module dependency and the sun.jdk module has the following additional dependencies.

{code}
                <path name="sun/net/spi/nameservice"/>
                <path name="sun/net/spi/nameservice/dns"/>
{code}

Though it doesn't work as a web application which has the same module path and the same dependency in jboss-deployment-structure.xml.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 05:07:01 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 20 Oct 2016 05:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7353) CDI bean-discovery-mode does
 not default to "annotated"
In-Reply-To: <JIRA.12655839.1476952393000@Atlassian.JIRA>
References: <JIRA.12655839.1476952393000@Atlassian.JIRA>
	<JIRA.12655839.1476952393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655839.1476952393000.22645.1476954421037@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reassigned WFLY-7353:
----------------------------------

    Assignee: Martin Kouba  (was: Stuart Douglas)


> CDI bean-discovery-mode does not default to "annotated"
> -------------------------------------------------------
>
>                 Key: WFLY-7353
>                 URL: https://issues.jboss.org/browse/WFLY-7353
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final
>         Environment: EAP 7.0.2
>            Reporter: Teresa Miyar
>            Assignee: Martin Kouba
>              Labels: support
>         Attachments: demo-war-2.zip
>
>
> bean-discovery-mode does not default to "annotated" when you have a beans.xml version 1.1 without setting the discovery mode. That means that the bean without annotation gets injected.
> To reproduce:
> Download attached war, run into EAP 7.0.2, point browser to demo-war/servlet, check logs
> result:
> I see the log from bean call
> expected result:
> either WFLYCTL0184:    New missing/unsatisfied dependencies on startup, or null pointer exception when accessing the servlet.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 05:13:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 20 Oct 2016 05:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7304) Compensations subsystem
In-Reply-To: <JIRA.12654630.1476351823000@Atlassian.JIRA>
References: <JIRA.12654630.1476351823000@Atlassian.JIRA>
	<JIRA.12654630.1476351823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654630.1476351823000.22667.1476954780280@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309655#comment-13309655 ] 

Gytis Trikleris commented on WFLY-7304:
---------------------------------------

I wasn't aware of such option. I thought that since it's more optional functionality and also enables two services from XTS, it shouldn't be in transactions subsystem.
Is there any documentation or wiki on how to implement the sub-resource?

> Compensations subsystem
> -----------------------
>
>                 Key: WFLY-7304
>                 URL: https://issues.jboss.org/browse/WFLY-7304
>             Project: WildFly
>          Issue Type: Task
>          Components: Transactions
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 05:16:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 20 Oct 2016 05:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7353) CDI bean-discovery-mode does
 not default to "annotated"
In-Reply-To: <JIRA.12655839.1476952393000@Atlassian.JIRA>
References: <JIRA.12655839.1476952393000@Atlassian.JIRA>
	<JIRA.12655839.1476952393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655839.1476952393000.22705.1476954960559@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-7353.
----------------------------------
    Resolution: Rejected


See section 2.5 of the CDI spec

> CDI bean-discovery-mode does not default to "annotated"
> -------------------------------------------------------
>
>                 Key: WFLY-7353
>                 URL: https://issues.jboss.org/browse/WFLY-7353
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final
>         Environment: EAP 7.0.2
>            Reporter: Teresa Miyar
>            Assignee: Martin Kouba
>              Labels: support
>         Attachments: demo-war-2.zip
>
>
> bean-discovery-mode does not default to "annotated" when you have a beans.xml version 1.1 without setting the discovery mode. That means that the bean without annotation gets injected.
> To reproduce:
> Download attached war, run into EAP 7.0.2, point browser to demo-war/servlet, check logs
> result:
> I see the log from bean call
> expected result:
> either WFLYCTL0184:    New missing/unsatisfied dependencies on startup, or null pointer exception when accessing the servlet.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 05:17:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 20 Oct 2016 05:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7355) Elytron subsystem requires
 user to input OIDs
In-Reply-To: <JIRA.12655847.1476954927000@Atlassian.JIRA>
References: <JIRA.12655847.1476954927000@Atlassian.JIRA>
	<JIRA.12655847.1476954927000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655847.1476954927000.22723.1476955020475@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6521 to WFLY-7355:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7355  (was: JBEAP-6521)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR6)


> Elytron subsystem requires user to input OIDs
> ---------------------------------------------
>
>                 Key: WFLY-7355
>                 URL: https://issues.jboss.org/browse/WFLY-7355
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>
> On couple of places in elytron subsystem  raw oids are expected from user input, e.g. 2.5.4.4 . Is there chance some aliasing could be introduced? So for example human readable "surname" can be used?
> * kerberos-security-factory 
> ** mechanism-oids
> * x500-principal-decoder
> ** oid
> ** required-oids 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 05:17:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 20 Oct 2016 05:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7355) Elytron subsystem requires
 user to input OIDs
In-Reply-To: <JIRA.12655847.1476954927000@Atlassian.JIRA>
References: <JIRA.12655847.1476954927000@Atlassian.JIRA>
	<JIRA.12655847.1476954927000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655847.1476954927000.22728.1476955020877@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-7355:
-------------------------------
    Description: 
On couple of places in elytron subsystem  raw oids are expected from user input, e.g. {{2.5.4.4}} . Is there chance some aliasing could be introduced? So for example human readable {{surname}} can be used?

* kerberos-security-factory 
** mechanism-oids
* x500-principal-decoder
** oid
** required-oids 

  was:
On couple of places in elytron subsystem  raw oids are expected from user input, e.g. 2.5.4.4 . Is there chance some aliasing could be introduced? So for example human readable "surname" can be used?

* kerberos-security-factory 
** mechanism-oids
* x500-principal-decoder
** oid
** required-oids 



> Elytron subsystem requires user to input OIDs
> ---------------------------------------------
>
>                 Key: WFLY-7355
>                 URL: https://issues.jboss.org/browse/WFLY-7355
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>
> On couple of places in elytron subsystem  raw oids are expected from user input, e.g. {{2.5.4.4}} . Is there chance some aliasing could be introduced? So for example human readable {{surname}} can be used?
> * kerberos-security-factory 
> ** mechanism-oids
> * x500-principal-decoder
> ** oid
> ** required-oids 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 05:27:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Thu, 20 Oct 2016 05:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.22849.1476955620268@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309672#comment-13309672 ] 

Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------

PR https://github.com/aeshell/aesh/pull/236

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 05:37:00 2016
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 20 Oct 2016 05:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7353) CDI bean-discovery-mode does
 not default to "annotated"
In-Reply-To: <JIRA.12655839.1476952393000@Atlassian.JIRA>
References: <JIRA.12655839.1476952393000@Atlassian.JIRA>
	<JIRA.12655839.1476952393000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655839.1476952393000.22994.1476956220476@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309676#comment-13309676 ] 

Martin Kouba commented on WFLY-7353:
------------------------------------

For the record, the CDI spec states in [12.1. Bean archives|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_archive]:
bq. A bean archive which contains a beans.xml file with version 1.1 (or later) must specify the bean-discovey-mode attribute.
Also the attribute is required in XSD.

> CDI bean-discovery-mode does not default to "annotated"
> -------------------------------------------------------
>
>                 Key: WFLY-7353
>                 URL: https://issues.jboss.org/browse/WFLY-7353
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final
>         Environment: EAP 7.0.2
>            Reporter: Teresa Miyar
>            Assignee: Martin Kouba
>              Labels: support
>         Attachments: demo-war-2.zip
>
>
> bean-discovery-mode does not default to "annotated" when you have a beans.xml version 1.1 without setting the discovery mode. That means that the bean without annotation gets injected.
> To reproduce:
> Download attached war, run into EAP 7.0.2, point browser to demo-war/servlet, check logs
> result:
> I see the log from bean call
> expected result:
> either WFLYCTL0184:    New missing/unsatisfied dependencies on startup, or null pointer exception when accessing the servlet.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 06:21:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 20 Oct 2016 06:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.23287.1476958860266@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309704#comment-13309704 ] 

Jan Kalina commented on WFLY-7334:
----------------------------------

Would you attach your standalone.xml to reproduce it faster? Thanks

> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 06:25:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 20 Oct 2016 06:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1302) OOPath ReactiveList remove
	cases
In-Reply-To: <JIRA.12651455.1474540627000@Atlassian.JIRA>
References: <JIRA.12651455.1474540627000@Atlassian.JIRA>
	<JIRA.12651455.1474540627000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651455.1474540627000.23302.1476959100413@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari reopened DROOLS-1302:
------------------------------------
      Assignee: Mario Fusco  (was: Matteo Mortari)


As discussed in presence the previous solution in ReactiveList :

{code:java}
    @Override
    public boolean add(T t) {
        boolean result = list.add(t);
        ReactiveObjectUtil.notifyModification(t, getLeftTuples(), ModificationType.ADD);
        if (t instanceof ReactiveObject) {
            for (Tuple lts : getLeftTuples()) {
                ((ReactiveObject) t).addLeftTuple(lts);
            }
        }
        return result;
    }
{code}

is not really ideal as this case fails by creating twice the match:

{code:java}
    @Test
    public void testMatteo2() {
        String drl =
                "import org.drools.compiler.xpath.*;\n" +
                "global java.util.List list\n" +
                "\n" +
                "rule R when\n" +
                "  Man( $usage: /wife/children{age > 10}/toys/usage{level > 10} )\n" +
                "then\n" +
                "  list.add( $usage );\n" +
                "end\n";

        KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL ).build();
        KieSession ksession = kbase.newKieSession();

        List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list", list );

        Woman alice = new Woman( "Alice", 38 );
        Man bob = new Man( "Bob", 40 );
        bob.setWife( alice );

        ksession.insert( bob );
        ksession.fireAllRules();
        
        list.clear();
        Child eleonor = new Child( "Eleonor", 10 );
        alice.addChild( eleonor );
        Toy toy = new Toy( "eleonor toy 1" );
        eleonor.addToy( toy );
        Usage usage = new Usage();
        toy.setUsage(usage);
        usage.setLevel(99);
        eleonor.setAge(11);
        ksession.fireAllRules();
        System.out.println(list);
        

        usage.setLevel(99);
        ksession.fireAllRules();
        System.out.println(list);
    }
{code}


> OOPath ReactiveList remove cases
> --------------------------------
>
>                 Key: DROOLS-1302
>                 URL: https://issues.jboss.org/browse/DROOLS-1302
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.CR2
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 7.0.0.Beta2
>
>
> * Removing element from ReactiveList is not covered
> * Ensure removing from 1 out of many ReactiveList does affect only the relevant lists when  issuing modification to a ReactiveObject



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 06:31:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 20 Oct 2016 06:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1302) OOPath ReactiveList remove
	cases
In-Reply-To: <JIRA.12651455.1474540627000@Atlassian.JIRA>
References: <JIRA.12651455.1474540627000@Atlassian.JIRA>
	<JIRA.12651455.1474540627000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651455.1474540627000.23321.1476959460252@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309706#comment-13309706 ] 

Matteo Mortari edited comment on DROOLS-1302 at 10/20/16 6:30 AM:
------------------------------------------------------------------

As discussed in presence the previous solution in ReactiveList :

{code:java}
    @Override
    public boolean add(T t) {
        boolean result = list.add(t);
        ReactiveObjectUtil.notifyModification(t, getLeftTuples(), ModificationType.ADD);
        if (t instanceof ReactiveObject) {
            for (Tuple lts : getLeftTuples()) {
                ((ReactiveObject) t).addLeftTuple(lts);
            }
        }
        return result;
    }
{code}

is not really ideal as this case fails by creating twice the match:

{code:java}
    @Test
    public void testMatteo2() {
        String drl =
                "import org.drools.compiler.xpath.*;\n" +
                "global java.util.List list\n" +
                "\n" +
                "rule R when\n" +
                "  Man( $usage: /wife/children{age > 10}/toys/usage{level > 10} )\n" +
                "then\n" +
                "  list.add( $usage );\n" +
                "end\n";

        KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL ).build();
        KieSession ksession = kbase.newKieSession();

        List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list", list );

        Woman alice = new Woman( "Alice", 38 );
        Man bob = new Man( "Bob", 40 );
        bob.setWife( alice );

        ksession.insert( bob );
        ksession.fireAllRules();
        
        list.clear();
        Child eleonor = new Child( "Eleonor", 10 );
        alice.addChild( eleonor );
        Toy toy = new Toy( "eleonor toy 1" );
        eleonor.addToy( toy );
        Usage usage = new Usage();
        toy.setUsage(usage);
        usage.setLevel(0);
        eleonor.setAge(11);
        ksession.fireAllRules();
        System.out.println(list);
        

        usage.setLevel(99);
        ksession.fireAllRules();
        System.out.println(list);
    }
{code}

(removing the first of the 3 fires, does not exhibit the issue, so as discussed this could be related with the fact the from node create the fh twice.)

(having the first setter to  usage.setLevel(99); instead of above  usage.setLevel(0); would exhibit the issue multiplied, at the 2/3 fired having 2 match, at the 3/3 fired having 4 match)



was (Author: tari_manga):
As discussed in presence the previous solution in ReactiveList :

{code:java}
    @Override
    public boolean add(T t) {
        boolean result = list.add(t);
        ReactiveObjectUtil.notifyModification(t, getLeftTuples(), ModificationType.ADD);
        if (t instanceof ReactiveObject) {
            for (Tuple lts : getLeftTuples()) {
                ((ReactiveObject) t).addLeftTuple(lts);
            }
        }
        return result;
    }
{code}

is not really ideal as this case fails by creating twice the match:

{code:java}
    @Test
    public void testMatteo2() {
        String drl =
                "import org.drools.compiler.xpath.*;\n" +
                "global java.util.List list\n" +
                "\n" +
                "rule R when\n" +
                "  Man( $usage: /wife/children{age > 10}/toys/usage{level > 10} )\n" +
                "then\n" +
                "  list.add( $usage );\n" +
                "end\n";

        KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL ).build();
        KieSession ksession = kbase.newKieSession();

        List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list", list );

        Woman alice = new Woman( "Alice", 38 );
        Man bob = new Man( "Bob", 40 );
        bob.setWife( alice );

        ksession.insert( bob );
        ksession.fireAllRules();
        
        list.clear();
        Child eleonor = new Child( "Eleonor", 10 );
        alice.addChild( eleonor );
        Toy toy = new Toy( "eleonor toy 1" );
        eleonor.addToy( toy );
        Usage usage = new Usage();
        toy.setUsage(usage);
        usage.setLevel(99);
        eleonor.setAge(11);
        ksession.fireAllRules();
        System.out.println(list);
        

        usage.setLevel(99);
        ksession.fireAllRules();
        System.out.println(list);
    }
{code}


> OOPath ReactiveList remove cases
> --------------------------------
>
>                 Key: DROOLS-1302
>                 URL: https://issues.jboss.org/browse/DROOLS-1302
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.CR2
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 7.0.0.Beta2
>
>
> * Removing element from ReactiveList is not covered
> * Ensure removing from 1 out of many ReactiveList does affect only the relevant lists when  issuing modification to a ReactiveObject



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 06:54:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 20 Oct 2016 06:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.23475.1476960840420@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-7334:
-------------------------------
    Attachment: standalone-elytron.xml


> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 06:59:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 20 Oct 2016 06:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.23509.1476961140826@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309723#comment-13309723 ] 

Martin Choma commented on WFLY-7334:
------------------------------------

I have attached {{standalone-elytron.xml}}, for which I don't see java kerberos debug messages, even if I start wildfly with {code}./standalone.sh -Djava.security.krb5.debug=true{code} . 

Only way I can get debug messages in log:

{code}
12:34:22,641 INFO  [stdout] (default task-1) Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt false ticketCache is null isInitiator false KeyTab is /home/mchoma/tasks/20161017_elytron_kerberos/jboss_server_base_dir_eap7/configuration/http.keytab refreshKrb5Config is false principal is HTTP/localhost.localdomain at JBOSS.ORG tryFirstPass is false useFirstPass is false storePass is false clearPass is false
12:34:22,643 INFO  [stdout] (default task-1) principal is HTTP/localhost.localdomain at JBOSS.ORG
12:34:22,643 INFO  [stdout] (default task-1) Will use keytab
12:34:22,644 INFO  [stdout] (default task-1) Commit Succeeded 
12:34:22,644 INFO  [stdout] (default task-1) 
{code}

is to set {{debug}} attribute of {{kerberos-security-factory}} to true 

> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 07:05:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 20 Oct 2016 07:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7347) No log messages comming from
 Elytron - kerberos
In-Reply-To: <JIRA.12655611.1476860981000@Atlassian.JIRA>
References: <JIRA.12655611.1476860981000@Atlassian.JIRA>
	<JIRA.12655611.1476860981000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655611.1476860981000.23570.1476961500906@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7347:
--------------------------------

    Assignee: Jan Kalina


> No log messages comming from Elytron - kerberos
> -----------------------------------------------
>
>                 Key: WFLY-7347
>                 URL: https://issues.jboss.org/browse/WFLY-7347
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Elytron is missing log messages related to kerberos authentication. These log messages should be added. See JBEAP-6041 for more details.
> I consider to be useful to have TRACE log messages at least in:
> - SpnegoAuthenticationMechanism
> - GSSCredentialSecurityFactory
> If there are more classes involved in kerberos authnetication include them as well.
> Kerberos issues are very specific. So it is very important to have as much trace information as possible. Therefore raising priority to Critical.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 07:09:00 2016
From: issues at jboss.org (Sande Gilda (JIRA))
Date: Thu, 20 Oct 2016 07:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7356) WELD-001303 error when
 executing thread-racing quickstart
In-Reply-To: <JIRA.12655864.1476961587000@Atlassian.JIRA>
References: <JIRA.12655864.1476961587000@Atlassian.JIRA>
	<JIRA.12655864.1476961587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655864.1476961587000.23612.1476961740196@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sande Gilda moved JBEAP-6526 to WFLY-7356:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7356  (was: JBEAP-6526)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s:     (was: Quickstarts)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR1)
                           (was: 7.1.0.DR2)
                           (was: 7.1.0.DR3)
                           (was: 7.1.0.DR4)
                           (was: 7.1.0.DR5)
                           (was: 7.1.0.DR6)
        Fix Version/s:     (was: 7.1.0.DR7)


> WELD-001303 error when executing thread-racing quickstart
> ---------------------------------------------------------
>
>                 Key: WFLY-7356
>                 URL: https://issues.jboss.org/browse/WFLY-7356
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Sande Gilda
>            Assignee: Jeff Mesnil
>              Labels: NEED_ASSISTANCE
>
> After pressing the {{INSERT COIN}} button in {{thread-racing}} quickstart, the following error is produced by EAP:
> {code}09:00:25,763 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> 09:00:25,764 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> 09:00:25,765 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.RequestedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTemporaryQueue(JMSContextWrapper.java:252)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.stage.jms.JMSRaceStage.run(JMSRaceStage.java:52)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer.runRaceStages(Racer.java:152)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer.access$100(Racer.java:39)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer$1.run(Racer.java:130)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at java.lang.Thread.run(Thread.java:745)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> {code}
> The application itself then shows the following output:
> {quote}
> Ready... Set... Go!
> Sebastien Throeb completed the Batch 1.0 stage.
> Michael Thrumacher completed the Batch 1.0 stage.
> Valentino Throssi completed the Batch 1.0 stage.
> Jimmie Thronson completed the Batch 1.0 stage.
> Sebastien Throeb completed the EE Concurrency 1.0 stage.
> Michael Thrumacher completed the EE Concurrency 1.0 stage.
> Valentino Throssi completed the EE Concurrency 1.0 stage.
> Jimmie Thronson completed the EE Concurrency 1.0 stage.
> Sebastien Throeb PIT STOP in 96ms
> Jimmie Thronson PIT STOP in 96ms
> Valentino Throssi PIT STOP in 96ms
> Michael Thrumacher PIT STOP in 96ms
> Sebastien Throeb completed the JAX-RS 2.0 stage.
> Jimmie Thronson completed the JAX-RS 2.0 stage.
> Valentino Throssi completed the JAX-RS 2.0 stage.
> Michael Thrumacher completed the JAX-RS 2.0 stage.
> Michael Thrumacher aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Valentino Throssi aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Jimmie Thronson aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Sebastien Throeb aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped{quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 07:12:01 2016
From: issues at jboss.org (Sande Gilda (JIRA))
Date: Thu, 20 Oct 2016 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7356) WELD-001303 error when
 executing thread-racing quickstart
In-Reply-To: <JIRA.12655864.1476961587000@Atlassian.JIRA>
References: <JIRA.12655864.1476961587000@Atlassian.JIRA>
	<JIRA.12655864.1476961587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655864.1476961587000.23662.1476961921107@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sande Gilda resolved WFLY-7356.
-------------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Done


Pull request: https://github.com/wildfly/quickstart/pull/113

Fixed with this commit: https://github.com/wildfly/quickstart/commit/f969520f90789216b51afb9438046f45719a54dc


> WELD-001303 error when executing thread-racing quickstart
> ---------------------------------------------------------
>
>                 Key: WFLY-7356
>                 URL: https://issues.jboss.org/browse/WFLY-7356
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Sande Gilda
>            Assignee: Jeff Mesnil
>              Labels: NEED_ASSISTANCE
>             Fix For: 11.0.0.Alpha1
>
>
> After pressing the {{INSERT COIN}} button in {{thread-racing}} quickstart, the following error is produced by EAP:
> {code}09:00:25,763 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> 09:00:25,764 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> 09:00:25,765 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.RequestedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTemporaryQueue(JMSContextWrapper.java:252)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.stage.jms.JMSRaceStage.run(JMSRaceStage.java:52)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer.runRaceStages(Racer.java:152)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer.access$100(Racer.java:39)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer$1.run(Racer.java:130)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at java.lang.Thread.run(Thread.java:745)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> {code}
> The application itself then shows the following output:
> {quote}
> Ready... Set... Go!
> Sebastien Throeb completed the Batch 1.0 stage.
> Michael Thrumacher completed the Batch 1.0 stage.
> Valentino Throssi completed the Batch 1.0 stage.
> Jimmie Thronson completed the Batch 1.0 stage.
> Sebastien Throeb completed the EE Concurrency 1.0 stage.
> Michael Thrumacher completed the EE Concurrency 1.0 stage.
> Valentino Throssi completed the EE Concurrency 1.0 stage.
> Jimmie Thronson completed the EE Concurrency 1.0 stage.
> Sebastien Throeb PIT STOP in 96ms
> Jimmie Thronson PIT STOP in 96ms
> Valentino Throssi PIT STOP in 96ms
> Michael Thrumacher PIT STOP in 96ms
> Sebastien Throeb completed the JAX-RS 2.0 stage.
> Jimmie Thronson completed the JAX-RS 2.0 stage.
> Valentino Throssi completed the JAX-RS 2.0 stage.
> Michael Thrumacher completed the JAX-RS 2.0 stage.
> Michael Thrumacher aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Valentino Throssi aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Jimmie Thronson aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Sebastien Throeb aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped{quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 07:13:00 2016
From: issues at jboss.org (Sande Gilda (JIRA))
Date: Thu, 20 Oct 2016 07:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7356) WELD-001303 error when
 executing thread-racing quickstart
In-Reply-To: <JIRA.12655864.1476961587000@Atlassian.JIRA>
References: <JIRA.12655864.1476961587000@Atlassian.JIRA>
	<JIRA.12655864.1476961587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655864.1476961587000.23665.1476961980162@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309733#comment-13309733 ] 

Sande Gilda commented on WFLY-7356:
-----------------------------------

See original JIRA for details: https://issues.jboss.org/browse/JBEAP-6058


> WELD-001303 error when executing thread-racing quickstart
> ---------------------------------------------------------
>
>                 Key: WFLY-7356
>                 URL: https://issues.jboss.org/browse/WFLY-7356
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Sande Gilda
>            Assignee: Jeff Mesnil
>              Labels: NEED_ASSISTANCE
>             Fix For: 11.0.0.Alpha1
>
>
> After pressing the {{INSERT COIN}} button in {{thread-racing}} quickstart, the following error is produced by EAP:
> {code}09:00:25,763 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> 09:00:25,764 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> 09:00:25,765 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.RequestedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTemporaryQueue(JMSContextWrapper.java:252)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.stage.jms.JMSRaceStage.run(JMSRaceStage.java:52)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer.runRaceStages(Racer.java:152)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer.access$100(Racer.java:39)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer$1.run(Racer.java:130)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at java.lang.Thread.run(Thread.java:745)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> {code}
> The application itself then shows the following output:
> {quote}
> Ready... Set... Go!
> Sebastien Throeb completed the Batch 1.0 stage.
> Michael Thrumacher completed the Batch 1.0 stage.
> Valentino Throssi completed the Batch 1.0 stage.
> Jimmie Thronson completed the Batch 1.0 stage.
> Sebastien Throeb completed the EE Concurrency 1.0 stage.
> Michael Thrumacher completed the EE Concurrency 1.0 stage.
> Valentino Throssi completed the EE Concurrency 1.0 stage.
> Jimmie Thronson completed the EE Concurrency 1.0 stage.
> Sebastien Throeb PIT STOP in 96ms
> Jimmie Thronson PIT STOP in 96ms
> Valentino Throssi PIT STOP in 96ms
> Michael Thrumacher PIT STOP in 96ms
> Sebastien Throeb completed the JAX-RS 2.0 stage.
> Jimmie Thronson completed the JAX-RS 2.0 stage.
> Valentino Throssi completed the JAX-RS 2.0 stage.
> Michael Thrumacher completed the JAX-RS 2.0 stage.
> Michael Thrumacher aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Valentino Throssi aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Jimmie Thronson aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Sebastien Throeb aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped{quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 07:20:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 20 Oct 2016 07:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7304) Compensations subsystem
In-Reply-To: <JIRA.12654630.1476351823000@Atlassian.JIRA>
References: <JIRA.12654630.1476351823000@Atlassian.JIRA>
	<JIRA.12654630.1476351823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654630.1476351823000.23702.1476962400343@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309739#comment-13309739 ] 

Tomaz Cerar commented on WFLY-7304:
-----------------------------------

Having it an optional functionality is just fine. That is an idea of sub resources.
stuff is only enabled if they are added.

transaction subsystem already uses sub resources such as log store.
just look at usages of ResourceDefinition 

> Compensations subsystem
> -----------------------
>
>                 Key: WFLY-7304
>                 URL: https://issues.jboss.org/browse/WFLY-7304
>             Project: WildFly
>          Issue Type: Task
>          Components: Transactions
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 07:44:00 2016
From: issues at jboss.org (=?UTF-8?Q?Vlastimil_Eli=C3=A1=C5=A1_=28JIRA=29?=)
Date: Thu, 20 Oct 2016 07:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1885) Test 2
In-Reply-To: <JIRA.12655874.1476963803000@Atlassian.JIRA>
References: <JIRA.12655874.1476963803000@Atlassian.JIRA>
	<JIRA.12655874.1476963803164@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655874.1476963803000.23888.1476963840462@Atlassian.JIRA>

Vlastimil Eli?? created WFCORE-1885:
---------------------------------------

             Summary: Test 2
                 Key: WFCORE-1885
                 URL: https://issues.jboss.org/browse/WFCORE-1885
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Vlastimil Eli??






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 07:44:00 2016
From: issues at jboss.org (=?UTF-8?Q?Vlastimil_Eli=C3=A1=C5=A1_=28JIRA=29?=)
Date: Thu, 20 Oct 2016 07:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1885) Test 2
In-Reply-To: <JIRA.12655874.1476963803000@Atlassian.JIRA>
References: <JIRA.12655874.1476963803000@Atlassian.JIRA>
	<JIRA.12655874.1476963803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655874.1476963803000.23890.1476963840495@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vlastimil Eli?? deleted WFCORE-1885:
------------------------------------


> Test 2
> ------
>
>                 Key: WFCORE-1885
>                 URL: https://issues.jboss.org/browse/WFCORE-1885
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Vlastimil Eli??
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 08:16:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 20 Oct 2016 08:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7356) WELD-001303 error when
 executing thread-racing quickstart
In-Reply-To: <JIRA.12655864.1476961587000@Atlassian.JIRA>
References: <JIRA.12655864.1476961587000@Atlassian.JIRA>
	<JIRA.12655864.1476961587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655864.1476961587000.24140.1476965760350@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7356:
------------------------------
    Component/s: Quickstarts


> WELD-001303 error when executing thread-racing quickstart
> ---------------------------------------------------------
>
>                 Key: WFLY-7356
>                 URL: https://issues.jboss.org/browse/WFLY-7356
>             Project: WildFly
>          Issue Type: Bug
>          Components: Quickstarts
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Sande Gilda
>            Assignee: Jeff Mesnil
>              Labels: NEED_ASSISTANCE
>             Fix For: 11.0.0.Alpha1
>
>
> After pressing the {{INSERT COIN}} button in {{thread-racing}} quickstart, the following error is produced by EAP:
> {code}09:00:25,763 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> 09:00:25,764 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> 09:00:25,765 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.RequestedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)
> 09:00:25,766 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTemporaryQueue(JMSContextWrapper.java:252)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.stage.jms.JMSRaceStage.run(JMSRaceStage.java:52)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer.runRaceStages(Racer.java:152)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer.access$100(Racer.java:39)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.jboss.as.quickstarts.threadracing.Racer$1.run(Racer.java:130)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at java.lang.Thread.run(Thread.java:745)
> 09:00:25,767 ERROR [stderr] (EE-ManagedThreadFactory-default-Thread-2) 	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> {code}
> The application itself then shows the following output:
> {quote}
> Ready... Set... Go!
> Sebastien Throeb completed the Batch 1.0 stage.
> Michael Thrumacher completed the Batch 1.0 stage.
> Valentino Throssi completed the Batch 1.0 stage.
> Jimmie Thronson completed the Batch 1.0 stage.
> Sebastien Throeb completed the EE Concurrency 1.0 stage.
> Michael Thrumacher completed the EE Concurrency 1.0 stage.
> Valentino Throssi completed the EE Concurrency 1.0 stage.
> Jimmie Thronson completed the EE Concurrency 1.0 stage.
> Sebastien Throeb PIT STOP in 96ms
> Jimmie Thronson PIT STOP in 96ms
> Valentino Throssi PIT STOP in 96ms
> Michael Thrumacher PIT STOP in 96ms
> Sebastien Throeb completed the JAX-RS 2.0 stage.
> Jimmie Thronson completed the JAX-RS 2.0 stage.
> Valentino Throssi completed the JAX-RS 2.0 stage.
> Michael Thrumacher completed the JAX-RS 2.0 stage.
> Michael Thrumacher aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Valentino Throssi aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Jimmie Thronson aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> Sebastien Throeb aborted the race... such a looser! Reason: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped{quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 08:22:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 08:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-773)
 ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the
 thread pool executor
In-Reply-To: <JIRA.12575453.1434617524000@Atlassian.JIRA>
References: <JIRA.12575453.1434617524000@Atlassian.JIRA>
	<JIRA.12575453.1434617524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575453.1434617524000.24204.1476966120608@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309810#comment-13309810 ] 

Brian Stansberry commented on WFCORE-773:
-----------------------------------------

It actually is still used though in subsystem=jca. The threads module now is primarily used as util code for other subsystems whose config includes thread pool configuration elements.

>  ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-773
>                 URL: https://issues.jboss.org/browse/WFCORE-773
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Enrique Gonz?lez Mart?nez
>            Assignee: Petr Jurak
>
> BoundedQueueThreadPool does not support zero length queue setup.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 09:14:00 2016
From: issues at jboss.org (Jan Stourac (JIRA))
Date: Thu, 20 Oct 2016 09:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7357) 'cipher' vs 'cypher' in
 Undertow attribute description
In-Reply-To: <JIRA.12655896.1476969167000@Atlassian.JIRA>
References: <JIRA.12655896.1476969167000@Atlassian.JIRA>
	<JIRA.12655896.1476969167000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655896.1476969167000.24610.1476969240888@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Stourac moved JBEAP-6531 to WFLY-7357:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7357  (was: JBEAP-6531)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Web (Undertow)
                           (was: Web (Undertow))
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR6)


> 'cipher' vs 'cypher' in Undertow attribute description
> ------------------------------------------------------
>
>                 Key: WFLY-7357
>                 URL: https://issues.jboss.org/browse/WFLY-7357
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: Jan Stourac
>            Assignee: Stuart Douglas
>            Priority: Trivial
>
> In Undertow https-listener, there is an attribute 'enabled-cipher-suites' witch description 'Configures Enabled SSL cyphers'. See that attribute contains 'cipher' and description 'cypher'. I believe we should keep those consistent.
> I have grepped source codebase of Undertow, Wildfly and EAP docs and it seems that except this (and related) we prefer 'cipher' spelling. Thus we should reword description of mentioned attribute too.
> Appropriate change needs to be done also in documentation, where https-listener attributes description is mentioned.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 09:25:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Thu, 20 Oct 2016 09:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-653) KeystorePasswordStore contains
 inconsistency about MODIFIABLE configuration attribute
In-Reply-To: <JIRA.12653362.1475667182000@Atlassian.JIRA>
References: <JIRA.12653362.1475667182000@Atlassian.JIRA>
	<JIRA.12653362.1475667182000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653362.1475667182000.24692.1476969900143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-653:
-----------------------------
    Component/s: Credential Store


> KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute
> -------------------------------------------------------------------------------------
>
>                 Key: ELY-653
>                 URL: https://issues.jboss.org/browse/ELY-653
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute.
> Here it is used MODIFIABLE attribute:
> https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L275
> But it is missing between supported configuration attributes:
> https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L222
> I cannot see any condition with isModifiable() in *store()* or *remove()* method:
> https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L317
> In my opinion MODIFIABLE attribute should be supported otherwise please remove code about MODIFIABLE from *initialize()* method.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 09:25:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Thu, 20 Oct 2016 09:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-652) There isn't possibility set
 entry-type for new entry in Credential Store.
In-Reply-To: <JIRA.12653326.1475656931000@Atlassian.JIRA>
References: <JIRA.12653326.1475656931000@Atlassian.JIRA>
	<JIRA.12653326.1475656931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653326.1475656931000.24695.1476969900272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-652:
-----------------------------
    Component/s: Credential Store


> There isn't possibility set entry-type for new entry in Credential Store.
> -------------------------------------------------------------------------
>
>                 Key: ELY-652
>                 URL: https://issues.jboss.org/browse/ELY-652
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> There isn't possibility set entry-type for new entry in Credential Store
> This CLI command
> {code}
> /subsystem=elytron/credential-store=testCS/alias=aliasEntryType:add(secret-value=secretVALUE, entry-type=org.wildfly.security.credential.PasswordCredential)
> {code}
> ends with
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'",
>     "rolled-back" => true
> }
> {code}
> *Server log:*
> {code}
> 10:30:39,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("credential-store" => "testCS"),
>     ("alias" => "aliasEntryType")
> ]): java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'
>         at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.performRuntime(CredentialStoreAliasDefinition.java:166)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
>         at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
>         at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.security.auth.Subject.doAs(Subject.java:422)
>         at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
>         at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
>         at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
>         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)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 09:30:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Thu, 20 Oct 2016 09:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-676) There isn't possible change
 value for given alias in Credential Store over CLI.
In-Reply-To: <JIRA.12655904.1476970184000@Atlassian.JIRA>
References: <JIRA.12655904.1476970184000@Atlassian.JIRA>
	<JIRA.12655904.1476970184592@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655904.1476970184000.24734.1476970200638@Atlassian.JIRA>

Hynek ?v?bek created ELY-676:
--------------------------------

             Summary: There isn't possible change value for given alias in Credential Store over CLI.
                 Key: ELY-676
                 URL: https://issues.jboss.org/browse/ELY-676
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
    Affects Versions: 1.1.0.Beta10
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek


There isn't possible change value for given alias in Credential Store over CLI.

I expected something like this
{code}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 09:33:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 20 Oct 2016 09:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1337) A FQN inline cast followed
 by a method invocation causes an ArrayIndexOutOfBoundsException
In-Reply-To: <JIRA.12655753.1476894873000@Atlassian.JIRA>
References: <JIRA.12655753.1476894873000@Atlassian.JIRA>
	<JIRA.12655753.1476894873000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655753.1476894873000.24748.1476970380264@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari reassigned DROOLS-1337:
--------------------------------------

    Assignee: Matteo Mortari  (was: Mario Fusco)


> A FQN inline cast followed by a method invocation causes an ArrayIndexOutOfBoundsException
> ------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1337
>                 URL: https://issues.jboss.org/browse/DROOLS-1337
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Matteo Mortari
>
> An inline cast using a fully qualified name followed by a method invocation causes an ArrayIndexOutOfBoundsException as in the following test case:
> {code}
>     @Test
>     public void testInlineCastWithFQNAndMethodInvocation() throws Exception {
>         String str =
>                 "import org.drools.compiler.Person;\n" +
>                 "global java.util.List list;\n" +
>                 "rule R1 when\n" +
>                 "   Person( name == \"mark\", $x : address#org.drools.compiler.LongAddress.country.substring(1) )\n" +
>                 "then\n" +
>                 "   list.add($x);" +
>                 "end\n";
>         KnowledgeBase kbase = loadKnowledgeBaseFromString(str);
>         StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal( "list", list );
>         Person mark1 = new Person("mark");
>         mark1.setAddress(new LongAddress("uk"));
>         ksession.insert(mark1);
>         assertEquals(1, ksession.fireAllRules());
>         assertEquals(1, list.size());
>         assertEquals("k", list.get(0));
>         ksession.dispose();
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 10:11:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 20 Oct 2016 10:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7358) Add EAP 7.0.0 transformers
 tests for singleton subsystem
In-Reply-To: <JIRA.12655924.1476972641000@Atlassian.JIRA>
References: <JIRA.12655924.1476972641000@Atlassian.JIRA>
	<JIRA.12655924.1476972641798@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655924.1476972641000.25228.1476972660383@Atlassian.JIRA>

Radoslav Husar created WFLY-7358:
------------------------------------

             Summary: Add EAP 7.0.0 transformers tests for singleton subsystem
                 Key: WFLY-7358
                 URL: https://issues.jboss.org/browse/WFLY-7358
             Project: WildFly
          Issue Type: Task
          Components: Clustering
    Affects Versions: 10.1.0.Final, 10.0.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 10:18:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 20 Oct 2016 10:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7359) Add EAP 7.0.0 transformers
 tests for singleton subsystem
In-Reply-To: <JIRA.12655928.1476973043000@Atlassian.JIRA>
References: <JIRA.12655928.1476973043000@Atlassian.JIRA>
	<JIRA.12655928.1476973043442@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655928.1476973043000.25308.1476973080852@Atlassian.JIRA>

Radoslav Husar created WFLY-7359:
------------------------------------

             Summary: Add EAP 7.0.0 transformers tests for singleton subsystem
                 Key: WFLY-7359
                 URL: https://issues.jboss.org/browse/WFLY-7359
             Project: WildFly
          Issue Type: Task
          Components: Clustering
    Affects Versions: 10.0.0.Final, 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 10:47:00 2016
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 20 Oct 2016 10:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7360) SECURITY-931 -
 PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access
In-Reply-To: <JIRA.12655938.1476974754000@Atlassian.JIRA>
References: <JIRA.12655938.1476974754000@Atlassian.JIRA>
	<JIRA.12655938.1476974754000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655938.1476974754000.25724.1476974820835@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell moved JBEAP-6545 to WFLY-7360:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7360  (was: JBEAP-6545)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s:     (was: 7.0.2.GA)
        Fix Version/s:     (was: 7.1.0.GA)


> SECURITY-931 - PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-7360
>                 URL: https://issues.jboss.org/browse/WFLY-7360
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>            Priority: Minor
>
> 'Acces denied: authorization failed' should be 'Access denied: authorization failed'



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 10:57:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 20 Oct 2016 10:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2120) Headers.resize() called
	unnecessarily
In-Reply-To: <JIRA.12655939.1476975373000@Atlassian.JIRA>
References: <JIRA.12655939.1476975373000@Atlassian.JIRA>
	<JIRA.12655939.1476975373206@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655939.1476975373000.25810.1476975420179@Atlassian.JIRA>

Bela Ban created JGRP-2120:
------------------------------

             Summary: Headers.resize() called unnecessarily
                 Key: JGRP-2120
                 URL: https://issues.jboss.org/browse/JGRP-2120
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 4.0


Each message has space for 4 headers. When a 5th header needs to be added, the array needs to be resized. This is something we want to avoid as much as possible.

However, the following scenario can lead to resizing:

* A bundler writes a message list with (say) 3 headers
* A message list always ignores the transport header, as it is only used to carry the cluster name, but that name is available in the batch header, too.
* Therefore, the size of the headers written is 2 and the transport header is not written
* On the receiver side, when reading the batch, we create and read 2 headers
** This is OK, as message batches are matched against the receiver's cluster name using the cluster name shipped in the batch itself and not in the message
** Message batches are therefore passed up without the individual messages carrying a transport header
* However, single messages need to carry a transport header as it will be used to do the cluster name matching
* Now, if a batch contains messages tagged as {{OOB|DONT_BUNDLE}}, they will be removed from the batch and sent up the stack as separate messages, each in a separate thread.
* To do this, each of these messages is added a transport header (created using the batch's cluster name).
* However, this necessitates a resizing as the headers array has a length of only 2, but we now need 3 headers

Note that we don't run into this in 4.0, as Infinispan 9 (which uses 4) doesn't use {{DONT_BUNDLE}} any longer. It is still an unnecessary memory allocation and needs to be optimized.

However, we should fix it in 3.6 as we still use {{DONT_BUNDLE}} in Infinispan 8.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:01:01 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Oct 2016 11:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-931)
 PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access
In-Reply-To: <JIRA.12597989.1451581482000@Atlassian.JIRA>
References: <JIRA.12597989.1451581482000@Atlassian.JIRA>
	<JIRA.12597989.1451581482000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597989.1451581482000.25880.1476975661646@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309946#comment-13309946 ] 

RH Bugzilla Integration commented on SECURITY-931:
--------------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1387278|https://bugzilla.redhat.com/show_bug.cgi?id=1387278] from NEW to POST

> PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access
> -----------------------------------------------------------------------
>
>                 Key: SECURITY-931
>                 URL: https://issues.jboss.org/browse/SECURITY-931
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: PicketBox
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>            Priority: Minor
>
> Acces should be Access in : 
> security-spi/common/src/main/java/org/jboss/security/PicketBoxMessages.java:    @Message(id = 17, value = "Acces denied: authorization failed")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:03:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 20 Oct 2016 11:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1865) Make the authentication
 configurable in the testsuite
In-Reply-To: <JIRA.12654788.1476392914000@Atlassian.JIRA>
References: <JIRA.12654788.1476392914000@Atlassian.JIRA>
	<JIRA.12654788.1476392914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654788.1476392914000.25949.1476975780898@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti updated WFCORE-1865:
-----------------------------------
    Summary: Make the authentication configurable in the testsuite  (was: Make the authentication configurable in the eap testsuite)


> Make the authentication configurable in the testsuite
> -----------------------------------------------------
>
>                 Key: WFCORE-1865
>                 URL: https://issues.jboss.org/browse/WFCORE-1865
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:03:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 20 Oct 2016 11:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7309) Make the authentication
 configurable in the testsuite
In-Reply-To: <JIRA.12654704.1476368089000@Atlassian.JIRA>
References: <JIRA.12654704.1476368089000@Atlassian.JIRA>
	<JIRA.12654704.1476368089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654704.1476368089000.25952.1476975780961@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti updated WFLY-7309:
---------------------------------
    Summary: Make the authentication configurable in the testsuite   (was: Make the authentication configurable in the eap testsuite )


> Make the authentication configurable in the testsuite 
> ------------------------------------------------------
>
>                 Key: WFLY-7309
>                 URL: https://issues.jboss.org/browse/WFLY-7309
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>
> Actually some tests cases fails when running against a remote eap instance. 
> In this specific case instances running on Openshift v3.
> In order to get those tests working we have to modify some classes to configure the authentication.
> Example: 
> org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
>         return connector.getMBeanServerConnection();
>     }
> {code}
> To:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
>         String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
>         propEnv.put(JMXConnector.CREDENTIALS, credentials);
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
>         return connector.getMBeanServerConnection();
>     }
> {code}
> Could these kind of authentication being configurable?
> It is important to us because this allows the tests to be executed against the docker images running in openshift.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:05:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 20 Oct 2016 11:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1865) Make the authentication
 configurable in the testsuite
In-Reply-To: <JIRA.12654788.1476392914000@Atlassian.JIRA>
References: <JIRA.12654788.1476392914000@Atlassian.JIRA>
	<JIRA.12654788.1476392914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654788.1476392914000.25969.1476975900184@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti updated WFCORE-1865:
-----------------------------------
    Description: 
Actually some tests cases fails when running against a remote eap instance.
In this specific case instances running on Openshift v3.
In order to get those tests working we have to modify some classes to configure the authentication.


> Make the authentication configurable in the testsuite
> -----------------------------------------------------
>
>                 Key: WFCORE-1865
>                 URL: https://issues.jboss.org/browse/WFCORE-1865
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>
> Actually some tests cases fails when running against a remote eap instance.
> In this specific case instances running on Openshift v3.
> In order to get those tests working we have to modify some classes to configure the authentication.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:06:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 11:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5227) Move security-manager
 subsystem from WildFly to WildFly Core
In-Reply-To: <JIRA.12583075.1440748335000@Atlassian.JIRA>
References: <JIRA.12583075.1440748335000@Atlassian.JIRA>
	<JIRA.12583075.1440748335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583075.1440748335000.25986.1476975960746@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-5227:
--------------------------------------

    Assignee: Ken Wills  (was: Stefan Guilhen)


As discussed in the Brno F2F, I agreed to assign someone to take responsibility for getting this done for WF 11 so [~sguilhen] can focus on elytron related work. So that will be Ken Wills. Stefan, Ken is looking into how you did your previous PRs on this; thanks for the explanations which seem simple enough. He'll coordinate with you and [~dlofthouse] to work out when making this move would be least disruptive to the elytron work.

> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
>                 Key: WFLY-5227
>                 URL: https://issues.jboss.org/browse/WFLY-5227
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security Manager
>            Reporter: Josef Cacek
>            Assignee: Ken Wills
>            Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html#4353] thread on {{wildfly-dev}} mailing list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:11:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Thu, 20 Oct 2016 11:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-677) Credential-reference should be
 resolved in time of request.
In-Reply-To: <JIRA.12655947.1476976242000@Atlassian.JIRA>
References: <JIRA.12655947.1476976242000@Atlassian.JIRA>
	<JIRA.12655947.1476976242326@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655947.1476976242000.26042.1476976260150@Atlassian.JIRA>

Hynek ?v?bek created ELY-677:
--------------------------------

             Summary: Credential-reference should be resolved in time of request.
                 Key: ELY-677
                 URL: https://issues.jboss.org/browse/ELY-677
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
    Affects Versions: 1.1.0.Beta10
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek
         Attachments: firefly.keystore

Credential-reference should be resolved in time of request.

When you added KeyStore to Elytron subsystem which have credential-reference to non-exists credential store then you can see this error message

{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("key-store" => "firefly")
]) - failure description: {
    "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.NonexistingCredentialStore"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.firefly is missing [org.wildfly.security.credential-store-client.NonexistingCredentialStore]"]
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 11:23:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 20 Oct 2016 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1865) Make the authentication
 configurable in the testsuite
In-Reply-To: <JIRA.12654788.1476392914000@Atlassian.JIRA>
References: <JIRA.12654788.1476392914000@Atlassian.JIRA>
	<JIRA.12654788.1476392914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654788.1476392914000.26132.1476976980114@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti updated WFCORE-1865:
-----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1868


> Make the authentication configurable in the testsuite
> -----------------------------------------------------
>
>                 Key: WFCORE-1865
>                 URL: https://issues.jboss.org/browse/WFCORE-1865
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>
> Actually some tests cases fails when running against a remote eap instance.
> In this specific case instances running on Openshift v3.
> In order to get those tests working we have to modify some classes to configure the authentication.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:44:01 2016
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 20 Oct 2016 11:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5227) Move security-manager
 subsystem from WildFly to WildFly Core
In-Reply-To: <JIRA.12583075.1440748335000@Atlassian.JIRA>
References: <JIRA.12583075.1440748335000@Atlassian.JIRA>
	<JIRA.12583075.1440748335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583075.1440748335000.26362.1476978241607@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309978#comment-13309978 ] 

Stefan Guilhen commented on WFLY-5227:
--------------------------------------

[~brian.stansberry] Great, thanks for the update. I just want to point out that it would be good to have https://issues.jboss.org/browse/WFLY-4882 resolved before moving the subsystem to avoid having to rework the fix. I've updated the PR on that jira a couple of weeks ago, fixing some points as suggested by Stuart and you. Just need another review to port the patch to EAP as well.

> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
>                 Key: WFLY-5227
>                 URL: https://issues.jboss.org/browse/WFLY-5227
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security Manager
>            Reporter: Josef Cacek
>            Assignee: Ken Wills
>            Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html#4353] thread on {{wildfly-dev}} mailing list.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:47:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 11:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1797) LaunchType.SELF_CONTAINED
 doesn't cleanup the temporary "wildfly-self-contained" directory
In-Reply-To: <JIRA.12650278.1473930935000@Atlassian.JIRA>
References: <JIRA.12650278.1473930935000@Atlassian.JIRA>
	<JIRA.12650278.1473930935000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650278.1473930935000.26405.1476978420154@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1797:
-------------------------------------
    Fix Version/s: 2.2.1.Final


> LaunchType.SELF_CONTAINED doesn't cleanup the temporary "wildfly-self-contained" directory
> ------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1797
>                 URL: https://issues.jboss.org/browse/WFCORE-1797
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: backport_2.x
>             Fix For: 3.0.0.Alpha9, 2.2.1.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:47:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 11:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1786) SelfContainedContainer:
 Allow the ConfigurationPersisterFactory to be customised
In-Reply-To: <JIRA.12649954.1473768607000@Atlassian.JIRA>
References: <JIRA.12649954.1473768607000@Atlassian.JIRA>
	<JIRA.12649954.1473768607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649954.1473768607000.26408.1476978420216@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1786:
-------------------------------------
    Fix Version/s: 2.2.1.Final


> SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-1786
>                 URL: https://issues.jboss.org/browse/WFCORE-1786
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: backport_2.x
>             Fix For: 3.0.0.Alpha8, 2.2.1.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:50:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Oct 2016 11:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6214) Change
 CMTTxInterceptor.endTransaction() handling of Status.ROLLING_BACK
In-Reply-To: <JIRA.12603962.1455551828000@Atlassian.JIRA>
References: <JIRA.12603962.1455551828000@Atlassian.JIRA>
	<JIRA.12603962.1455551828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603962.1455551828000.26419.1476978600337@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-6214:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1387319
        Bugzilla Update: Perform


> Change CMTTxInterceptor.endTransaction() handling of Status.ROLLING_BACK
> ------------------------------------------------------------------------
>
>                 Key: WFLY-6214
>                 URL: https://issues.jboss.org/browse/WFLY-6214
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Transactions
>            Reporter: Scott Marlow
>            Assignee: Tom Jenkinson
>            Priority: Blocker
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> See recent comment [https://developer.jboss.org/message/950898#950898]
> {quote}
> Status.STATUS_COMMITTING:
> Status.STATUS_COMMITTED:
> Status.STATUS_PREPARED:
> Status.STATUS_PREPARING:
> * Someone has called commit in parallel and the transaction is trying to commit so try to commit too: call tm.commit
> {quote}
> I think that TimerCMTTxInterceptor/LifecycleCMTTxInterceptor are using CMTTxInterceptor.endTransaction(), so they shouldn't need changes.
> Status.STATUS_ROLLING_BACK can happen if the reaper has started to rollback the transaction



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:52:00 2016
From: issues at jboss.org (Filippe Spolti (JIRA))
Date: Thu, 20 Oct 2016 11:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7309) Make the authentication
 configurable in the testsuite
In-Reply-To: <JIRA.12654704.1476368089000@Atlassian.JIRA>
References: <JIRA.12654704.1476368089000@Atlassian.JIRA>
	<JIRA.12654704.1476368089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654704.1476368089000.26426.1476978720335@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Filippe Spolti updated WFLY-7309:
---------------------------------
    Affects Version/s: 10.1.0.Final


> Make the authentication configurable in the testsuite 
> ------------------------------------------------------
>
>                 Key: WFLY-7309
>                 URL: https://issues.jboss.org/browse/WFLY-7309
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.1.0.Final
>            Reporter: Filippe Spolti
>            Assignee: Filippe Spolti
>            Priority: Optional
>
> Actually some tests cases fails when running against a remote eap instance. 
> In this specific case instances running on Openshift v3.
> In order to get those tests working we have to modify some classes to configure the authentication.
> Example: 
> org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address));
>         return connector.getMBeanServerConnection();
>     }
> {code}
> To:
> {code:java}
>     private MBeanServerConnection getMBeanServerConnection() throws IOException {
>         HashMap<String, String[]> propEnv = new HashMap<String, String[]>();
>         String[] credentials = {  System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") };
>         propEnv.put(JMXConnector.CREDENTIALS, credentials);
>         final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort();
>         connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv);
>         return connector.getMBeanServerConnection();
>     }
> {code}
> Could these kind of authentication being configurable?
> It is important to us because this allows the tests to be executed against the docker images running in openshift.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 11:54:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 20 Oct 2016 11:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7361) data-source attribute should
 not be an attribute of all JGroups protocols
In-Reply-To: <JIRA.12655965.1476978810000@Atlassian.JIRA>
References: <JIRA.12655965.1476978810000@Atlassian.JIRA>
	<JIRA.12655965.1476978810484@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655965.1476978810000.26436.1476978840346@Atlassian.JIRA>

Paul Ferraro created WFLY-7361:
----------------------------------

             Summary: data-source attribute should not be an attribute of all JGroups protocols
                 Key: WFLY-7361
                 URL: https://issues.jboss.org/browse/WFLY-7361
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 11.0.0.Alpha1


We should create a custom JDBCProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source attribute and capability reference.
This can be registered separately from the generic protocol resource definition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 12:08:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 20 Oct 2016 12:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7361) data-source,
 socket-binding attribute should not be an attribute of all JGroups
 protocols
In-Reply-To: <JIRA.12655965.1476978810000@Atlassian.JIRA>
References: <JIRA.12655965.1476978810000@Atlassian.JIRA>
	<JIRA.12655965.1476978810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655965.1476978810000.26518.1476979680165@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-7361:
-------------------------------
    Summary: data-source, socket-binding attribute should not be an attribute of all JGroups protocols  (was: data-source attribute should not be an attribute of all JGroups protocols)


> data-source, socket-binding attribute should not be an attribute of all JGroups protocols
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-7361
>                 URL: https://issues.jboss.org/browse/WFLY-7361
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> We should create a custom JDBCProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source attribute and capability reference.
> This can be registered separately from the generic protocol resource definition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 12:09:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 20 Oct 2016 12:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7361) data-source,
 socket-binding attribute should not be an attribute of all JGroups
 protocols
In-Reply-To: <JIRA.12655965.1476978810000@Atlassian.JIRA>
References: <JIRA.12655965.1476978810000@Atlassian.JIRA>
	<JIRA.12655965.1476978810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655965.1476978810000.26527.1476979740436@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-7361:
-------------------------------
    Description: 
We should create custom JDBCProtocolResourceDefinition and SocketProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source or socket-binding attribute and capability reference.
This can be registered separately from the generic protocol resource definition.

  was:
We should create a custom JDBCProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source attribute and capability reference.
This can be registered separately from the generic protocol resource definition.



> data-source, socket-binding attribute should not be an attribute of all JGroups protocols
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-7361
>                 URL: https://issues.jboss.org/browse/WFLY-7361
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> We should create custom JDBCProtocolResourceDefinition and SocketProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source or socket-binding attribute and capability reference.
> This can be registered separately from the generic protocol resource definition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 12:11:01 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 20 Oct 2016 12:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7361) data-source attribute should
 not be an attribute of all JGroups protocols
In-Reply-To: <JIRA.12655965.1476978810000@Atlassian.JIRA>
References: <JIRA.12655965.1476978810000@Atlassian.JIRA>
	<JIRA.12655965.1476978810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655965.1476978810000.26559.1476979861381@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-7361:
-------------------------------
    Summary: data-source attribute should not be an attribute of all JGroups protocols  (was: data-source, socket-binding attribute should not be an attribute of all JGroups protocols)


> data-source attribute should not be an attribute of all JGroups protocols
> -------------------------------------------------------------------------
>
>                 Key: WFLY-7361
>                 URL: https://issues.jboss.org/browse/WFLY-7361
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> We should create custom JDBCProtocolResourceDefinition and SocketProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source or socket-binding attribute and capability reference.
> This can be registered separately from the generic protocol resource definition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 12:11:01 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 20 Oct 2016 12:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7361) data-source attribute should
 not be an attribute of all JGroups protocols
In-Reply-To: <JIRA.12655965.1476978810000@Atlassian.JIRA>
References: <JIRA.12655965.1476978810000@Atlassian.JIRA>
	<JIRA.12655965.1476978810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655965.1476978810000.26563.1476979861492@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-7361:
-------------------------------
    Description: 
We should create a custom JDBCProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source attribute and capability reference.
This can be registered separately from the generic protocol resource definition.

  was:
We should create custom JDBCProtocolResourceDefinition and SocketProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source or socket-binding attribute and capability reference.
This can be registered separately from the generic protocol resource definition.



> data-source attribute should not be an attribute of all JGroups protocols
> -------------------------------------------------------------------------
>
>                 Key: WFLY-7361
>                 URL: https://issues.jboss.org/browse/WFLY-7361
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> We should create a custom JDBCProtocolResourceDefinition that extends ProtocolResourceDefinition that adds a data-source attribute and capability reference.
> This can be registered separately from the generic protocol resource definition.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 12:18:01 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 20 Oct 2016 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6426) ISE: Lock already released!
 after cluster-wide rebalance
In-Reply-To: <JIRA.12611888.1458821053000@Atlassian.JIRA>
References: <JIRA.12611888.1458821053000@Atlassian.JIRA>
	<JIRA.12611888.1458821053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611888.1458821053000.26673.1476980281800@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-6426.
------------------------------
    Resolution: Out of Date


> ISE: Lock already released! after cluster-wide rebalance
> --------------------------------------------------------
>
>                 Key: WFLY-6426
>                 URL: https://issues.jboss.org/browse/WFLY-6426
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Final
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>
> Seen in this scenario: failover-ejb-ejbremote-jvmkill-dist-sync
> After perf18 was killed, perf19 received new cluster view, started cluster-wide rebalance and then logged {{IllegalStateException: Lock already released!}}:
> {code:title=perf19}
> [JBossINF] [0m[31m08:33:22,291 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p5-t31) ISPN000136: Error executing command LockControlCommand, writing keys []: java.lang.IllegalStateException: Lock already released!
> [JBossINF] 	at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lock(InfinispanLock.java:324)
> [JBossINF] 	at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:234)
> [JBossINF] 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAllAndRecord(AbstractLockingInterceptor.java:199)
> [JBossINF] 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:199)
> [JBossINF] 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
> [JBossINF] 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:189)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> [JBossINF] 	at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> [JBossINF] 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:75)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:228)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:101)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.perform(LockControlCommand.java:122)
> [JBossINF] 	at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
> [JBossINF] 	at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Causing perf20 to log {{EJB Invocation failed}}:
> {code:title=perf20}
> [JBossINF] [0m[31m08:33:22,660 ERROR [org.jboss.as.ejb3.invocation] (default task-61) WFLYEJB0034: EJB Invocation failed on component RemoteStatefulSBImpl for method public abstract int org.jboss.test.clusterbench.common.ejb.CommonStatefulSB.getSerialAndIncrement(): javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from perf19, see cause for remote stack trace
> [JBossINF] 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> [JBossINF] 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> [JBossINF] 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> [JBossINF] 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> [JBossINF] 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> [JBossINF] 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> [JBossINF] 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> [JBossINF] 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> [JBossINF] 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> [JBossINF] 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from perf19, see cause for remote stack trace
> [JBossINF] 	at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:760)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$175(JGroupsTransport.java:612)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.RspListFuture.futureDone(RspListFuture.java:31)
> [JBossINF] 	at org.jgroups.blocks.Request.checkCompletion(Request.java:151)
> [JBossINF] 	at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:119)
> [JBossINF] 	at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:369)
> [JBossINF] 	at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:233)
> [JBossINF] 	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:695)
> [JBossINF] 	at org.jgroups.JChannel.up(JChannel.java:738)
> [JBossINF] 	at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:120)
> [JBossINF] 	at org.jgroups.stack.Protocol.up(Protocol.java:379)
> [JBossINF] 	at org.jgroups.protocols.FORK.up(FORK.java:114)
> [JBossINF] 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> [JBossINF] 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:392)
> [JBossINF] 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> [JBossINF] 	at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1043)
> [JBossINF] 	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> [JBossINF] 	at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064)
> [JBossINF] 	at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779)
> [JBossINF] 	at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> [JBossINF] 	at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645)
> [JBossINF] 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> [JBossINF] 	at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> [JBossINF] 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
> [JBossINF] 	at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
> [JBossINF] 	at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> [JBossINF] 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1567)
> [JBossINF] 	at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783)
> [JBossINF] 	... 3 more
> [JBossINF] Caused by: java.lang.IllegalStateException: Lock already released!
> [JBossINF] 	at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lock(InfinispanLock.java:324)
> [JBossINF] 	at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:234)
> [JBossINF] 	at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAllAndRecord(AbstractLockingInterceptor.java:199)
> [JBossINF] 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:199)
> [JBossINF] 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
> [JBossINF] 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:189)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> [JBossINF] 	at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> [JBossINF] 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:75)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:228)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:101)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] 	at org.infinispan.commands.control.LockControlCommand.perform(LockControlCommand.java:122)
> [JBossINF] 	at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
> [JBossINF] 	at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
> [JBossINF] 	... 3 more
> {code}
> Causing client to get:
> {code}
> 2016/03/22 08:33:22:679 EDT [ERROR][Runner - 1091] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from perf19, see cause for remote stack trace>
>         javax.ejb.EJBException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from perf19, see cause for remote stack trace
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:216)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 	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)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> 	at org.jboss.ejb.client.EJBClientInvocationContext$1.run(EJBClientInvocationContext.java:282)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:279)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> 	at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
> 	at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> 	at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> 	at java.lang.Thread.run(Thread.java:745)
> {code}
> Server links:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-jvmkill-dist-sync/19/console-perf19/
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-jvmkill-dist-sync/19/console-perf20/
> Client link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-jvmkill-dist-sync/19/console-perf17/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 14:10:01 2016
From: issues at jboss.org (Michael Peoples (JIRA))
Date: Thu, 20 Oct 2016 14:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.27363.1476987001005@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310068#comment-13310068 ] 

Michael Peoples commented on WFLY-6500:
---------------------------------------

I tried Camunda 7.6.0-alpha5-ee with the associated WildFly 10.1.0 instance.  Deployed my process and tested it.  I then incremented the version (0.0.2-SNAPSHOT) of the workflow (in the Maven pom file), built it, and then attempted to ADD it to the WildFly server as new deployment. 

If failed and corrupted the existing 0.0.1-SNAPSHOT version.  Only after removing the 0.0.1-SNAPSHOT (now corrupted) version of the process could I then deploy the 0.0.2-SNAPSHOT deployment.  I should note that I changed nothing except the version number in the Maven pom file.

This means that we cannot deploy an updated workflow

{{2016-10-20 17:54:57,764 INFO  [org.camunda.bpm.container.impl.jboss.deployment.processor.ProcessApplicationProcessor] (MSC service thread 1-8) Detected user-provided @ProcessApplication component with name 'com.att.gcs.bizops.cop.core.template.messagehandler.PrintCounterApplication'.
2016-10-20 17:54:57,942 INFO  [org.camunda.bpm.container.impl.jboss.service.ProcessApplicationDeploymentService] (ServerService Thread Pool -- 81) Deployment summary for process archive 'PrintCounter' of process application 'PrintCounter':

        printCounter1.bpmn
        printCounter1.png

2016-10-20 17:54:57,942 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: /PrintCounter-0.0.2-SNAPSHOT
2016-10-20 17:54:58,004 INFO  [org.camunda.bpm.application] (ServerService Thread Pool -- 81) ENGINE-07021 ProcessApplication 'PrintCounter' registered for DB deployments [f0da6a2a-96ed-11e6-8fed-0050568b3e38]. Will execute process definitions

        printCounter1[version: 1, id: printCounter1:1:f0ec6b8d-96ed-11e6-8fed-0050568b3e38]
Deployment does not provide any case definitions.
2016-10-20 17:54:58,007 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.camunda.bpm.platform.process-application-module."deployment.PrintCounter-0.0.2-SNAPSHOT.war:main".START: org.jboss.msc.service.StartException in service org.camunda.bpm.platform.process-application-module."deployment.PrintCounter-0.0.2-SNAPSHOT.war:main".START: org.jboss.msc.service.DuplicateServiceException: Service org.camunda.bpm.platform.process-application.PrintCounter is already registered
        at org.camunda.bpm.container.impl.jboss.service.ProcessApplicationStartService.start(ProcessApplicationStartService.java:162)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
        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)
Caused by: org.jboss.msc.service.DuplicateServiceException: Service org.camunda.bpm.platform.process-application.PrintCounter is already registered
        at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
        at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
        at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
        at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
        at org.camunda.bpm.container.impl.jboss.service.ProcessApplicationStartService.start(ProcessApplicationStartService.java:156)
        ... 5 more

2016-10-20 17:54:58,010 ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 7) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "PrintCounter-0.0.2-SNAPSHOT.war")]) - failure description: {
    "WFLYCTL0080: Failed services" => {"org.camunda.bpm.platform.process-application-module.\"deployment.PrintCounter-0.0.2-SNAPSHOT.war:main\".START" => "org.jboss.msc.service.StartException in service org.camunda.bpm.platform.process-application-module.\"deployment.PrintCounter-0.0.2-SNAPSHOT.war:main\".START: org.jboss.msc.service.DuplicateServiceException: Service org.camunda.bpm.platform.process-application.PrintCounter is already registered
    Caused by: org.jboss.msc.service.DuplicateServiceException: Service org.camunda.bpm.platform.process-application.PrintCounter is already registered"},
    "WFLYCTL0412: Required services that are not installed:" => ["org.camunda.bpm.platform.process-application-module.\"deployment.PrintCounter-0.0.2-SNAPSHOT.war:main\".START"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
2016-10-20 17:54:58,013 ERROR [org.jboss.as.server] (External Management Request Threads -- 7) WFLYSRV0021: Deploy of deployment "PrintCounter-0.0.2-SNAPSHOT.war" was rolled back with the following failure message:
{
    "WFLYCTL0080: Failed services" => {"org.camunda.bpm.platform.process-application-module.\"deployment.PrintCounter-0.0.2-SNAPSHOT.war:main\".START" => "org.jboss.msc.service.StartException in service org.camunda.bpm.platform.process-application-module.\"deployment.PrintCounter-0.0.2-SNAPSHOT.war:main\".START: org.jboss.msc.service.DuplicateServiceException: Service org.camunda.bpm.platform.process-application.PrintCounter is already registered
    Caused by: org.jboss.msc.service.DuplicateServiceException: Service org.camunda.bpm.platform.process-application.PrintCounter is already registered"},
    "WFLYCTL0412: Required services that are not installed:" => ["org.camunda.bpm.platform.process-application-module.\"deployment.PrintCounter-0.0.2-SNAPSHOT.war:main\".START"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
2016-10-20 17:54:58,025 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0022: Unregistered web context: /PrintCounter-0.0.2-SNAPSHOT
2016-10-20 17:54:58,073 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment PrintCounter-0.0.2-SNAPSHOT.war (runtime-name: PrintCounter-0.0.2-SNAPSHOT.war) in 59ms
2016-10-20 17:54:58,075 INFO  [org.jboss.as.controller] (External Management Request Threads -- 7) WFLYCTL0183: Service status report
WFLYCTL0186:   Services which failed to start:      service org.camunda.bpm.platform.process-application-module."deployment.PrintCounter-0.0.2-SNAPSHOT.war:main".START


*This is what an attempt to start the process after the failed deployment looked like:*

2016-10-20 17:59:04,510 ERROR [org.camunda.bpm.engine.context] (default task-142) ENGINE-16006 BPMN Stack Trace:
        ServiceTask_1 (activity-execute, ProcessInstance[e386486d-96ee-11e6-8fed-0050568b3e38])
        ServiceTask_1
          ^
          |
        StartEvent_1

2016-10-20 17:59:04,512 ERROR [org.camunda.bpm.engine.context] (default task-142) ENGINE-16004 Exception while closing command context: ENGINE-09008 Exception while instantiating class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': ENGINE-09017 Cannot load class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': com.att.gcs.bizops.cop.core.template.messagehandler.printCounter from [Module "deployment.camunda-engine-rest-7.6.0-alpha5-ee.war:main" from Service Module Loader]: org.camunda.bpm.engine.ProcessEngineException: ENGINE-09008 Exception while instantiating class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': ENGINE-09017 Cannot load class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': com.att.gcs.bizops.cop.core.template.messagehandler.printCounter from [Module "deployment.camunda-engine-rest-7.6.0-alpha5-ee.war:main" from Service Module Loader]
        at org.camunda.bpm.engine.impl.util.EngineUtilLogger.exceptionWhileInstantiatingClass(EngineUtilLogger.java:78)
        at org.camunda.bpm.engine.impl.util.ClassDelegateUtil.instantiateDelegate(ClassDelegateUtil.java:50)
        at org.camunda.bpm.engine.impl.bpmn.behavior.ClassDelegateActivityBehavior.getActivityBehaviorInstance(ClassDelegateActivityBehavior.java:109)
        at org.camunda.bpm.engine.impl.bpmn.behavior.ClassDelegateActivityBehavior$1.call(ClassDelegateActivityBehavior.java:65)
        at org.camunda.bpm.engine.impl.bpmn.behavior.ClassDelegateActivityBehavior$1.call(ClassDelegateActivityBehavior.java:62)
        at org.camunda.bpm.engine.impl.bpmn.behavior.AbstractBpmnActivityBehavior.executeWithErrorPropagation(AbstractBpmnActivityBehavior.java:107)
        at org.camunda.bpm.engine.impl.bpmn.behavior.ClassDelegateActivityBehavior.execute(ClassDelegateActivityBehavior.java:62)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityExecute.execute(PvmAtomicOperationActivityExecute.java:41)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityExecute.execute(PvmAtomicOperationActivityExecute.java:26)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:608)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:584)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationTransitionNotifyListenerStart.eventNotificationsCompleted(PvmAtomicOperationTransitionNotifyListenerStart.java:56)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationTransitionNotifyListenerStart.eventNotificationsCompleted(PvmAtomicOperationTransitionNotifyListenerStart.java:26)
        at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:65)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:69)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:619)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:594)
        at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:58)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:69)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:619)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:594)
        at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:58)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:69)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:619)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:594)
        at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:58)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:608)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:584)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationTransitionCreateScope.scopeCreated(PvmAtomicOperationTransitionCreateScope.java:34)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationCreateScope.execute(PvmAtomicOperationCreateScope.java:49)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationCreateScope.execute(PvmAtomicOperationCreateScope.java:23)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:112)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:608)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:584)
        at org.camunda.bpm.engine.impl.pvm.runtime.PvmExecutionImpl.start(PvmExecutionImpl.java:231)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.start(ExecutionEntity.java:433)
        at org.camunda.bpm.engine.impl.cmd.StartProcessInstanceCmd.execute(StartProcessInstanceCmd.java:55)
        at org.camunda.bpm.engine.impl.cmd.StartProcessInstanceCmd.execute(StartProcessInstanceCmd.java:31)
        at org.camunda.bpm.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:24)
        at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:104)
        at org.camunda.bpm.engine.impl.interceptor.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:58)
        at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:66)
        at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30)
        at org.camunda.bpm.engine.impl.ProcessInstantiationBuilderImpl.executeWithVariablesInReturn(ProcessInstantiationBuilderImpl.java:156)
        at org.camunda.bpm.engine.rest.sub.repository.impl.ProcessDefinitionResourceImpl.startProcessInstanceAtActivities(ProcessDefinitionResourceImpl.java:159)
        at org.camunda.bpm.engine.rest.sub.repository.impl.ProcessDefinitionResourceImpl.startProcessInstance(ProcessDefinitionResourceImpl.java:109)
        at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
        at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
        at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
        at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
        at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
        at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
        at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
        at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
        at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
        at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
        at org.camunda.bpm.engine.rest.filter.CacheControlFilter.doFilter(CacheControlFilter.java:41)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
        at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
        at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
        at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
        at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
        at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
        at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
        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)
Caused by: org.camunda.bpm.engine.ClassLoadingException: ENGINE-09017 Cannot load class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': com.att.gcs.bizops.cop.core.template.messagehandler.printCounter from [Module "deployment.camunda-engine-rest-7.6.0-alpha5-ee.war:main" from Service Module Loader]
        at org.camunda.bpm.engine.impl.util.EngineUtilLogger.classLoadingException(EngineUtilLogger.java:135)
        at org.camunda.bpm.engine.impl.util.ReflectUtil.loadClass(ReflectUtil.java:107)
        at org.camunda.bpm.engine.impl.util.ClassDelegateUtil.instantiateDelegate(ClassDelegateUtil.java:42)
        ... 125 more
Caused by: java.lang.ClassNotFoundException: com.att.gcs.bizops.cop.core.template.messagehandler.printCounter from [Module "deployment.camunda-engine-rest-7.6.0-alpha5-ee.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:348)
        at org.camunda.bpm.engine.impl.util.ReflectUtil.loadClass(ReflectUtil.java:84)
        ... 126 more

2016-10-20 17:59:04,524 WARNING [ExceptionHandler] (default task-142) org.camunda.bpm.engine.rest.exception.RestException: Cannot instantiate process definition printCounter1:1:f0ec6b8d-96ed-11e6-8fed-0050568b3e38: ENGINE-09008 Exception while instantiating class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': ENGINE-09017 Cannot load class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': com.att.gcs.bizops.cop.core.template.messagehandler.printCounter from [Module "deployment.camunda-engine-rest-7.6.0-alpha5-ee.war:main" from Service Module Loader]
        at org.camunda.bpm.engine.rest.sub.repository.impl.ProcessDefinitionResourceImpl.startProcessInstance(ProcessDefinitionResourceImpl.java:115)
        at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
        at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
        at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
        at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
        at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
        at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
        at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
        at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
        at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
        at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
        at org.camunda.bpm.engine.rest.filter.CacheControlFilter.doFilter(CacheControlFilter.java:41)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
        at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
        at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
        at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
        at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
        at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
        at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
        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)
Caused by: org.camunda.bpm.engine.ProcessEngineException: ENGINE-09008 Exception while instantiating class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': ENGINE-09017 Cannot load class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': com.att.gcs.bizops.cop.core.template.messagehandler.printCounter from [Module "deployment.camunda-engine-rest-7.6.0-alpha5-ee.war:main" from Service Module Loader]
        at org.camunda.bpm.engine.impl.util.EngineUtilLogger.exceptionWhileInstantiatingClass(EngineUtilLogger.java:78)
        at org.camunda.bpm.engine.impl.util.ClassDelegateUtil.instantiateDelegate(ClassDelegateUtil.java:50)
        at org.camunda.bpm.engine.impl.bpmn.behavior.ClassDelegateActivityBehavior.getActivityBehaviorInstance(ClassDelegateActivityBehavior.java:109)
        at org.camunda.bpm.engine.impl.bpmn.behavior.ClassDelegateActivityBehavior$1.call(ClassDelegateActivityBehavior.java:65)
        at org.camunda.bpm.engine.impl.bpmn.behavior.ClassDelegateActivityBehavior$1.call(ClassDelegateActivityBehavior.java:62)
        at org.camunda.bpm.engine.impl.bpmn.behavior.AbstractBpmnActivityBehavior.executeWithErrorPropagation(AbstractBpmnActivityBehavior.java:107)
        at org.camunda.bpm.engine.impl.bpmn.behavior.ClassDelegateActivityBehavior.execute(ClassDelegateActivityBehavior.java:62)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityExecute.execute(PvmAtomicOperationActivityExecute.java:41)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityExecute.execute(PvmAtomicOperationActivityExecute.java:26)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:608)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:584)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationTransitionNotifyListenerStart.eventNotificationsCompleted(PvmAtomicOperationTransitionNotifyListenerStart.java:56)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationTransitionNotifyListenerStart.eventNotificationsCompleted(PvmAtomicOperationTransitionNotifyListenerStart.java:26)
        at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:65)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:69)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:619)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:594)
        at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:58)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:69)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:619)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:594)
        at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:58)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:69)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:619)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:594)
        at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:58)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:104)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:608)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:584)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationTransitionCreateScope.scopeCreated(PvmAtomicOperationTransitionCreateScope.java:34)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationCreateScope.execute(PvmAtomicOperationCreateScope.java:49)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationCreateScope.execute(PvmAtomicOperationCreateScope.java:23)
        at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:88)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:125)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:112)
        at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:79)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:608)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperation(ExecutionEntity.java:584)
        at org.camunda.bpm.engine.impl.pvm.runtime.PvmExecutionImpl.start(PvmExecutionImpl.java:231)
        at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.start(ExecutionEntity.java:433)
        at org.camunda.bpm.engine.impl.cmd.StartProcessInstanceCmd.execute(StartProcessInstanceCmd.java:55)
        at org.camunda.bpm.engine.impl.cmd.StartProcessInstanceCmd.execute(StartProcessInstanceCmd.java:31)
        at org.camunda.bpm.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:24)
        at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:104)
        at org.camunda.bpm.engine.impl.interceptor.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:58)
        at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:66)
        at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30)
        at org.camunda.bpm.engine.impl.ProcessInstantiationBuilderImpl.executeWithVariablesInReturn(ProcessInstantiationBuilderImpl.java:156)
        at org.camunda.bpm.engine.rest.sub.repository.impl.ProcessDefinitionResourceImpl.startProcessInstanceAtActivities(ProcessDefinitionResourceImpl.java:159)
        at org.camunda.bpm.engine.rest.sub.repository.impl.ProcessDefinitionResourceImpl.startProcessInstance(ProcessDefinitionResourceImpl.java:109)
        ... 58 more
Caused by: org.camunda.bpm.engine.ClassLoadingException: ENGINE-09017 Cannot load class 'com.att.gcs.bizops.cop.core.template.messagehandler.printCounter': com.att.gcs.bizops.cop.core.template.messagehandler.printCounter from [Module "deployment.camunda-engine-rest-7.6.0-alpha5-ee.war:main" from Service Module Loader]
        at org.camunda.bpm.engine.impl.util.EngineUtilLogger.classLoadingException(EngineUtilLogger.java:135)
        at org.camunda.bpm.engine.impl.util.ReflectUtil.loadClass(ReflectUtil.java:107)
        at org.camunda.bpm.engine.impl.util.ClassDelegateUtil.instantiateDelegate(ClassDelegateUtil.java:42)
        ... 125 more
Caused by: java.lang.ClassNotFoundException: com.att.gcs.bizops.cop.core.template.messagehandler.printCounter from [Module "deployment.camunda-engine-rest-7.6.0-alpha5-ee.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:348)
        at org.camunda.bpm.engine.impl.util.ReflectUtil.loadClass(ReflectUtil.java:84)
        ... 126 more

}}

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Jason Greene
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 14:24:02 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 20 Oct 2016 14:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-931)
 PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access
In-Reply-To: <JIRA.12597989.1451581482000@Atlassian.JIRA>
References: <JIRA.12597989.1451581482000@Atlassian.JIRA>
	<JIRA.12597989.1451581482000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597989.1451581482000.27456.1476987842388@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-931:
---------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1387278
        Bugzilla Update: Perform


> PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access
> -----------------------------------------------------------------------
>
>                 Key: SECURITY-931
>                 URL: https://issues.jboss.org/browse/SECURITY-931
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: PicketBox
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>            Priority: Minor
>
> Acces should be Access in : 
> security-spi/common/src/main/java/org/jboss/security/PicketBoxMessages.java:    @Message(id = 17, value = "Acces denied: authorization failed")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 15:38:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 20 Oct 2016 15:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.27619.1476992280202@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310099#comment-13310099 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

Hi,
using latest WFCore jboss-cli, I can't reproduce this issue.
Do you agree that the issue should occur with :

[standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")


My latest changes is:
commit 7e5f9200ce0b57aa8c17d2b3bdf4579653158430
Author: Jean-Francois Denise <jfdenise at gmail.com>
Date:   Thu Oct 20 09:52:34 2016 +0200

    Fix for WFCORE-1878. Use * to identify all disabled deployments.


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:02 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1884) Introduce discovery
	subsystem
In-Reply-To: <JIRA.12655787.1476904150000@Atlassian.JIRA>
References: <JIRA.12655787.1476904150000@Atlassian.JIRA>
	<JIRA.12655787.1476904150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655787.1476904150000.27794.1476994262896@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1884:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Introduce discovery subsystem
> -----------------------------
>
>                 Key: WFCORE-1884
>                 URL: https://issues.jboss.org/browse/WFCORE-1884
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 3.0.0.Alpha11
>
>
> Introduce discovery subsystem to be used by any other subsystem which can utilize discovery.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1878) CLI should not rely on
 values that could conflict with shell operators
In-Reply-To: <JIRA.12655671.1476881337000@Atlassian.JIRA>
References: <JIRA.12655671.1476881337000@Atlassian.JIRA>
	<JIRA.12655671.1476881337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655671.1476881337000.27801.1476994263075@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1878:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> CLI should not rely on values that could conflict with shell operators
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1878
>                 URL: https://issues.jboss.org/browse/WFCORE-1878
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha11
>
>
> If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt
> Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1834) Unexpected attribute error
 message doesn't list 'name' attribute.
In-Reply-To: <JIRA.12652286.1474992629000@Atlassian.JIRA>
References: <JIRA.12652286.1474992629000@Atlassian.JIRA>
	<JIRA.12652286.1474992629000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652286.1474992629000.27805.1476994263274@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1834:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Unexpected attribute error message doesn't list 'name' attribute.
> -----------------------------------------------------------------
>
>                 Key: WFCORE-1834
>                 URL: https://issues.jboss.org/browse/WFCORE-1834
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>             Fix For: 3.0.0.Alpha11
>
>
> I have recently updated one of our resource definitions and missed updating one of the subsystem templates so currently have the following error reported: -
> {noformat}
> Message: WFLYCTL0376: Unexpected attribute 'security-domain' encountered. Valid attributes are: 'http-authentication-factory, override-deployment-config'
> [Host Controller] 	at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)
> {noformat}
> Previously my resource has been using the 'security-domain' attribute for it's name but now has been reverted to using 'name' for the name - in the above error message 'name' should have been listed as one of the valid attributes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1822) Address thread safety of
 CredentialReference
In-Reply-To: <JIRA.12651861.1474815467000@Atlassian.JIRA>
References: <JIRA.12651861.1474815467000@Atlassian.JIRA>
	<JIRA.12651861.1474815467000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651861.1474815467000.27813.1476994263488@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1822:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Address thread safety of CredentialReference
> --------------------------------------------
>
>                 Key: WFCORE-1822
>                 URL: https://issues.jboss.org/browse/WFCORE-1822
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Peter Skopek
>             Fix For: 3.0.0.Alpha11
>
>
> Following on from the comments in this pull requests some minor follow up is required regarding thread safety of CredentialReference: -
> https://github.com/wildfly/wildfly-core/pull/1816



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.27819.1476994263622@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1802:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Integrate OpenSSL Provider registration with Elytron
> ----------------------------------------------------
>
>                 Key: WFCORE-1802
>                 URL: https://issues.jboss.org/browse/WFCORE-1802
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Stuart Douglas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha11
>
>
> We need to remove the following block from SecurityRealmResourceDefinition: -
> {code}
>     static {
>         //register the Openssl Provider, if possible
>         //not really sure if this is the best place for it
>         try {
>             OpenSSLProvider.register();
>             DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider();
>         } catch (Throwable t){
>             DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider");
>         }
>     }
> {code}
> Registration will then be possible within the Elytron subsystem configuration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1701) In-VM Identity
	Representation
In-Reply-To: <JIRA.12642592.1470745276000@Atlassian.JIRA>
References: <JIRA.12642592.1470745276000@Atlassian.JIRA>
	<JIRA.12642592.1470745276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642592.1470745276000.27826.1476994263808@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1701:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> In-VM Identity Representation
> -----------------------------
>
>                 Key: WFCORE-1701
>                 URL: https://issues.jboss.org/browse/WFCORE-1701
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>
> If Elytron has no current SecurityIdentity then an anonymous identity is used.  The issue however is that this anonymous identity could be because the current user does not have access to be inflowed to the SecurityDomain being used for management or it could be because it is an in-vm call and no identity is established.
> We need a solution to safely represent an in-vm call and differentiate it from a user with no appropriate identity,



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1694) Upgrade to WildFly Client
 Config 1.0.0.Beta1
In-Reply-To: <JIRA.12641806.1470240820000@Atlassian.JIRA>
References: <JIRA.12641806.1470240820000@Atlassian.JIRA>
	<JIRA.12641806.1470240820000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641806.1470240820000.27829.1476994263902@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1694:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Upgrade to WildFly Client Config 1.0.0.Beta1
> --------------------------------------------
>
>                 Key: WFCORE-1694
>                 URL: https://issues.jboss.org/browse/WFCORE-1694
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1693) Upgrade to JBoss Remoting
	5.0.0.Beta4
In-Reply-To: <JIRA.12641805.1470240600000@Atlassian.JIRA>
References: <JIRA.12641805.1470240600000@Atlassian.JIRA>
	<JIRA.12641805.1470240600000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641805.1470240600000.27833.1476994263984@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1693:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Upgrade to JBoss Remoting 5.0.0.Beta4
> -------------------------------------
>
>                 Key: WFCORE-1693
>                 URL: https://issues.jboss.org/browse/WFCORE-1693
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1691) Upgrade to Remoting JMX
	3.0.0.Alpha1
In-Reply-To: <JIRA.12641802.1470238411000@Atlassian.JIRA>
References: <JIRA.12641802.1470238411000@Atlassian.JIRA>
	<JIRA.12641802.1470238411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641802.1470238411000.27836.1476994264047@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1691:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Upgrade to Remoting JMX 3.0.0.Alpha1
> ------------------------------------
>
>                 Key: WFCORE-1691
>                 URL: https://issues.jboss.org/browse/WFCORE-1691
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: JMX
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1602) Elytron integration with JMX
In-Reply-To: <JIRA.12633500.1466178398000@Atlassian.JIRA>
References: <JIRA.12633500.1466178398000@Atlassian.JIRA>
	<JIRA.12633500.1466178398000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633500.1466178398000.27839.1476994264107@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1602:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Elytron integration with JMX
> ----------------------------
>
>                 Key: WFCORE-1602
>                 URL: https://issues.jboss.org/browse/WFCORE-1602
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: JMX
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1600) Update the legacy security
 realms to add factory methods to obtain SaslAuthenticationFactory and
 HttpAuthenticationFactory instances.
In-Reply-To: <JIRA.12633492.1466175366000@Atlassian.JIRA>
References: <JIRA.12633492.1466175366000@Atlassian.JIRA>
	<JIRA.12633492.1466175366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633492.1466175366000.27846.1476994264233@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1600:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances.
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1600
>                 URL: https://issues.jboss.org/browse/WFCORE-1600
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>
> These are for use when security realms are directly referenced, although Elytron types these should not be advertised as capabilities as these are for specific backwards compatibility requirements and not to increase their use as Elytron capabilities.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1598) Conversion of Elytron
 SecurityIdentity to Subject for communication with older hosts.
In-Reply-To: <JIRA.12633268.1466074901000@Atlassian.JIRA>
References: <JIRA.12633268.1466074901000@Atlassian.JIRA>
	<JIRA.12633268.1466074901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633268.1466074901000.27853.1476994264417@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1598:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
> -------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1598
>                 URL: https://issues.jboss.org/browse/WFCORE-1598
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>
> In the domain hierarchy clients trust the server they communicate with so this server currently sends a serialized representation of the Subject containing information about the user initiating the request.
> For Elytron we will use the new identity propagation features however for older slaves we will need to convert to a Subject representation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1533) Integrate Management Access
 Control permission assignment with Elytron
In-Reply-To: <JIRA.12618464.1462530450000@Atlassian.JIRA>
References: <JIRA.12618464.1462530450000@Atlassian.JIRA>
	<JIRA.12618464.1462530450000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618464.1462530450000.27860.1476994264882@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1533:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Integrate Management Access Control permission assignment with Elytron
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1533
>                 URL: https://issues.jboss.org/browse/WFCORE-1533
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 3.0.0.Alpha11
>
>
> A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role.
> Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection.
> This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron.  
> After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based.
> _Note:  As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:05 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1438) Elytron integration with
 logging subsystem
In-Reply-To: <JIRA.12610886.1458208350000@Atlassian.JIRA>
References: <JIRA.12610886.1458208350000@Atlassian.JIRA>
	<JIRA.12610886.1458208350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610886.1458208350000.27864.1476994265181@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1438:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Elytron integration with logging subsystem
> ------------------------------------------
>
>                 Key: WFCORE-1438
>                 URL: https://issues.jboss.org/browse/WFCORE-1438
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>
> This is primarily an investigation task to start with, Logging can use syslog, Syslog access can be protected with TLS, Elytron is providing unified SSL configuration - do we need to bring these together.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:05 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1400) Update management
 interfaces to obtain the SSLContext using the new
 'org.wildfly.security.ssl-context' capability
In-Reply-To: <JIRA.12604817.1455822462000@Atlassian.JIRA>
References: <JIRA.12604817.1455822462000@Atlassian.JIRA>
	<JIRA.12604817.1455822462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12604817.1455822462000.27871.1476994265491@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1400:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1400
>                 URL: https://issues.jboss.org/browse/WFCORE-1400
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:05 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and
 Marshalling modules are required for Remoting to run with security manager
In-Reply-To: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.27882.1476994265806@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1351:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1351
>                 URL: https://issues.jboss.org/browse/WFCORE-1351
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Remoting, Security
>            Reporter: Ondrej Kotek
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 3.0.0.Alpha11
>
>         Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of  _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1282) Unable to create HTTPS
 connection using *ECDH_RSA* cipher suites / kECDHr cipher string
In-Reply-To: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.27891.1476994266052@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1282:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1282
>                 URL: https://issues.jboss.org/browse/WFCORE-1282
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 1.0.2.Final
>         Environment: Oracle Java
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Alpha11
>
>         Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. 
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). 
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1157) Managmement and JMX
 notifications when ControlledProcessState changes
In-Reply-To: <JIRA.12593860.1448317498000@Atlassian.JIRA>
References: <JIRA.12593860.1448317498000@Atlassian.JIRA>
	<JIRA.12593860.1448317498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593860.1448317498000.27900.1476994266245@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1157:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Managmement and JMX notifications when ControlledProcessState changes
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-1157
>                 URL: https://issues.jboss.org/browse/WFCORE-1157
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, JMX
>            Reporter: Brian Stansberry
>            Assignee: Kabir Khan
>             Fix For: 3.0.0.Alpha11
>
>
> When Jeff Mesnil added the core management notification stuff an obvious thing to do was to emit notifications around ControlledProcessState changes. But I forgot. :( So lets do it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.27905.1476994266337@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1145:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
>                 Key: WFCORE-1145
>                 URL: https://issues.jboss.org/browse/WFCORE-1145
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 3.0.0.Alpha11
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1006) Upgrade to PicketBox 5
In-Reply-To: <JIRA.12585975.1443100813000@Atlassian.JIRA>
References: <JIRA.12585975.1443100813000@Atlassian.JIRA>
	<JIRA.12585975.1443100813000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585975.1443100813000.27917.1476994266682@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1006:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Upgrade to PicketBox 5
> ----------------------
>
>                 Key: WFCORE-1006
>                 URL: https://issues.jboss.org/browse/WFCORE-1006
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Stefan Guilhen
>             Fix For: 3.0.0.Alpha11
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.27909.1476994266444@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1059:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> RestartParentResourceAdd/RemoveHandler should handle capability registration
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-1059
>                 URL: https://issues.jboss.org/browse/WFCORE-1059
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR6
>            Reporter: Paul Ferraro
>            Assignee: Tomaz Cerar
>             Fix For: 3.0.0.Alpha11
>
>
> RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:07 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-311) Better error message if
 authentication is required to connect to the master but no realm is
 associated on the slave
In-Reply-To: <JIRA.12533525.1393517943000@Atlassian.JIRA>
References: <JIRA.12533525.1393517943000@Atlassian.JIRA>
	<JIRA.12533525.1393517943000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533525.1393517943000.27941.1476994267279@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-311:
------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Better error message if authentication is required to connect to the master but no realm is associated on the slave
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-311
>                 URL: https://issues.jboss.org/browse/WFCORE-311
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>         Environment: RH EL 6.3 - JBoss EAP 6.2
>            Reporter: Riccardo Benvenuti
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 3.0.0.Alpha11
>
>
> In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below
> <domain-controller>
>    <remote host="10.123.137.200" port="9999"/>
> </domain-controller>
> we get the following error:
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /opt/jboss7/jboss-eap-6.2
>   JAVA: /usr/java/jdk1.7.0_51/bin/java
>   JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
> [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
> [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
> [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999
> [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
> [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm]
> [Host Controller]
> [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management]
> [Host Controller]
> [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014776: Newly corrected services:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required)
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required)
> [Host Controller]
> [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms
> 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting
> Adding the realm everything works correctly 
> <domain-controller>
>    <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/>
> </domain-controller>
> Maybe a warning message could be useful to find the problem.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:07 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-610) Integrate Elytron for
 management security.
In-Reply-To: <JIRA.12566595.1427107186000@Atlassian.JIRA>
References: <JIRA.12566595.1427107186000@Atlassian.JIRA>
	<JIRA.12566595.1427107186000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566595.1427107186000.27934.1476994267102@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-610:
------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Integrate Elytron for management security.
> ------------------------------------------
>
>                 Key: WFCORE-610
>                 URL: https://issues.jboss.org/browse/WFCORE-610
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha11
>
>
> This is a top level container task for the integration of Elytron for domain management security.
> Do note however that the purpose of Elytron is a single unified security solution across the whole of the application server so many tasks here will be groundwork for the remainder of the integration.
> At the moment the Elytron subsystem is being developed outside of wildfly-core, this will need to change in the future due to dependency issues (i.e. to write a subsystem you need to depend on core and core will need to include the subsystem (I think.)).  However this will make it easier for now to ensure that the subsystem is 100% with no WildFly code accessing the subsystem - and also verify that we can create a distribtion with out the subsystem and still have a functional server.
> Overall if someone came up with an alternative subsystem that provided the same capabilities it should be possible to drop it in.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:07 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-363)
 ManagementResourceRegistration.getOverrideModel never returns null
In-Reply-To: <JIRA.12531538.1391919140000@Atlassian.JIRA>
References: <JIRA.12531538.1391919140000@Atlassian.JIRA>
	<JIRA.12531538.1391919140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531538.1391919140000.27937.1476994267206@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-363:
------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
>                 Key: WFCORE-363
>                 URL: https://issues.jboss.org/browse/WFCORE-363
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Alpha11
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-673) Elytron Integration with Core
In-Reply-To: <JIRA.12570704.1430821554000@Atlassian.JIRA>
References: <JIRA.12570704.1430821554000@Atlassian.JIRA>
	<JIRA.12570704.1430821554000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570704.1430821554000.27925.1476994266893@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-673:
------------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> Elytron Integration with Core
> -----------------------------
>
>                 Key: WFCORE-673
>                 URL: https://issues.jboss.org/browse/WFCORE-673
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha11
>
>
> This is the top level tracking task for Elytron integration within core.  The tasks for the changes actually being made will either be linked or added as sub-tasks.
> In addition to this general issues that affect the Elytron integration are being labelled with 'affects_elytron' and can be queried using the following query: -
> https://issues.jboss.org/issues/?filter=12323574
> The label is a general catch-all for issues that are of interest to us but are not automatically blockers for our progress.
> The general criteria for the resolution of this issue will be: -
>  - Inclusion of the Elytron Subsystem in core
>  - All network entry points in core to be securable using Elytron
>  - All SSL artefacts to be obtainable from Elytron.
> Note:  The legacy modes will become better defined as we progress but whilst it must be possible to use Elytron it's use may still be optional to a certain degree.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:11:07 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 16:11:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.27946.1476994267448@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-13:
-----------------------------------
    Fix Version/s: 3.0.0.Alpha11
                       (was: 3.0.0.Alpha10)


> End users can call non-published management API operations
> ----------------------------------------------------------
>
>                 Key: WFCORE-13
>                 URL: https://issues.jboss.org/browse/WFCORE-13
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>              Labels: EAP
>             Fix For: 3.0.0.Alpha11
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:33:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 20 Oct 2016 16:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7362) Fix and enable
 org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase#testRejectionsEAP620
In-Reply-To: <JIRA.12656007.1476995576000@Atlassian.JIRA>
References: <JIRA.12656007.1476995576000@Atlassian.JIRA>
	<JIRA.12656007.1476995576035@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656007.1476995576000.27981.1476995580085@Atlassian.JIRA>

Radoslav Husar created WFLY-7362:
------------------------------------

             Summary: Fix and enable org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase#testRejectionsEAP620
                 Key: WFLY-7362
                 URL: https://issues.jboss.org/browse/WFLY-7362
             Project: WildFly
          Issue Type: Task
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


We need to make use of chained transformers to handle 2 attributes at the same path in different operations.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 16:40:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 20 Oct 2016 16:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7363) Fix and enable
 org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase#testRejectionsEAP620
In-Reply-To: <JIRA.12656008.1476995983000@Atlassian.JIRA>
References: <JIRA.12656008.1476995983000@Atlassian.JIRA>
	<JIRA.12656008.1476995983467@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656008.1476995983000.27984.1476996000309@Atlassian.JIRA>

Radoslav Husar created WFLY-7363:
------------------------------------

             Summary: Fix and enable org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase#testRejectionsEAP620
                 Key: WFLY-7363
                 URL: https://issues.jboss.org/browse/WFLY-7363
             Project: WildFly
          Issue Type: Task
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


We need to make use of chained transformers to handle 2 attributes at the same path in different operations.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 17:09:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 17:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1886) Adding ldap-realm in
 Elytron sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.28039.1476997740625@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1886:
-------------------------------------
    Priority: Critical  (was: Major)


> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1886
>                 URL: https://issues.jboss.org/browse/WFCORE-1886
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> 	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> 	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> 	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 17:09:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 17:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1886) Adding ldap-realm in
 Elytron sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.28033.1476997740500@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-7273 to WFCORE-1886:
------------------------------------------------

          Project: WildFly Core  (was: WildFly)
              Key: WFCORE-1886  (was: WFLY-7273)
      Component/s: Domain Management
                   Security
                       (was: Domain Management)
                       (was: Security)
    Fix Version/s:     (was: 11.0.0.Alpha1)


> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1886
>                 URL: https://issues.jboss.org/browse/WFCORE-1886
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> 	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> 	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> 	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 17:26:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 17:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1886) Adding ldap-realm in
 Elytron sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.28089.1476998760236@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310124#comment-13310124 ] 

Brian Stansberry commented on WFCORE-1886:
------------------------------------------

[~ctomc] This sounds like the thing [~ehugonnet] was talking about on HipChat a few days ago, where he observed the deployment scanner background task triggering incorrect publication of capability changes. I figure the reason the delay is important in the reproducer steps above is because the scanner runs during that time.

Did you guys figure out anything about this?

> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1886
>                 URL: https://issues.jboss.org/browse/WFCORE-1886
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> 	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> 	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> 	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 17:29:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 20 Oct 2016 17:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1836) Rejection-style transformer
 tests assume each operation generated by parser has distinct PathAddress
In-Reply-To: <JIRA.12634897.1466714467000@Atlassian.JIRA>
References: <JIRA.12634897.1466714467000@Atlassian.JIRA>
	<JIRA.12634897.1466714467000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12634897.1466714467000.28094.1476998940235@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar resolved WFCORE-1836.
------------------------------------
    Resolution: Rejected


We can use chained config for this use case, opened WFLY-7362  to reenable the test case.

> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1836
>                 URL: https://issues.jboss.org/browse/WFCORE-1836
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Paul Ferraro
>            Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress.  This is fine when the subsystem's parser only generates add operations.  However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address.  If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 17:34:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 20 Oct 2016 17:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7358) Add EAP 7.0.0 transformers
 tests for singleton subsystem
In-Reply-To: <JIRA.12655924.1476972642000@Atlassian.JIRA>
References: <JIRA.12655924.1476972642000@Atlassian.JIRA>
	<JIRA.12655924.1476972642000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655924.1476972642000.28101.1476999240240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7358:
---------------------------------
    Description: There are currently no tests, so we need to start by adding the whole test case.


> Add EAP 7.0.0 transformers tests for singleton subsystem
> --------------------------------------------------------
>
>                 Key: WFLY-7358
>                 URL: https://issues.jboss.org/browse/WFLY-7358
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> There are currently no tests, so we need to start by adding the whole test case.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 17:35:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 20 Oct 2016 17:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7358) Add EAP 7.0.0 transformers
 tests for singleton subsystem
In-Reply-To: <JIRA.12655924.1476972642000@Atlassian.JIRA>
References: <JIRA.12655924.1476972642000@Atlassian.JIRA>
	<JIRA.12655924.1476972642000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655924.1476972642000.28107.1476999300186@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7358:
---------------------------------
    Description: There are currently no transformation tests since this is a new subsystem since EAP 7.  (was: There are currently no tests, so we need to start by adding the whole test case.)


> Add EAP 7.0.0 transformers tests for singleton subsystem
> --------------------------------------------------------
>
>                 Key: WFLY-7358
>                 URL: https://issues.jboss.org/browse/WFLY-7358
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> There are currently no transformation tests since this is a new subsystem since EAP 7.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 17:58:00 2016
From: issues at jboss.org (william teskey (JIRA))
Date: Thu, 20 Oct 2016 17:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7364)
 java.lang.IllegalArgumentException: UT000068: Servlet path match failed
In-Reply-To: <JIRA.12656014.1477000674000@Atlassian.JIRA>
References: <JIRA.12656014.1477000674000@Atlassian.JIRA>
	<JIRA.12656014.1477000674213@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656014.1477000674000.28249.1477000680627@Atlassian.JIRA>

william teskey created WFLY-7364:
------------------------------------

             Summary: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
                 Key: WFLY-7364
                 URL: https://issues.jboss.org/browse/WFLY-7364
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 10.1.0.Final
            Reporter: william teskey
            Assignee: Jason Greene
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 18:00:01 2016
From: issues at jboss.org (william teskey (JIRA))
Date: Thu, 20 Oct 2016 18:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7364)
 java.lang.IllegalArgumentException: UT000068: Servlet path match failed
In-Reply-To: <JIRA.12656014.1477000674000@Atlassian.JIRA>
References: <JIRA.12656014.1477000674000@Atlassian.JIRA>
	<JIRA.12656014.1477000674000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656014.1477000674000.28255.1477000801289@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

william teskey updated WFLY-7364:
---------------------------------
    Description: 
[0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
	at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
	at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
	at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
	at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
	at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
	at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
	at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)


> java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7364
>                 URL: https://issues.jboss.org/browse/WFLY-7364
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.1.0.Final
>            Reporter: william teskey
>            Assignee: Jason Greene
>            Priority: Minor
>
> [0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> 	at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
> 	at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
> 	at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
> 	at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Thu Oct 20 20:37:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 20 Oct 2016 20:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1886) Adding ldap-realm in
 Elytron sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.28382.1477010220213@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310150#comment-13310150 ] 

Brian Stansberry commented on WFCORE-1886:
------------------------------------------

I think https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCORE-1886 is probably the solution to this.

I don't think the reproducer steps work any more though. I don't see why that op would even get to the point of registering a capability since the attribute validation should fail before then.

In any case the fix for this needs a multi-threaded reproducer test in CapabilityRegistryTestCase.

> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1886
>                 URL: https://issues.jboss.org/browse/WFCORE-1886
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> 	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> 	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> 	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 21:31:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Thu, 20 Oct 2016 21:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.28420.1477013460469@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hisanobu Okuda updated WFCORE-1868:
-----------------------------------
    Steps to Reproduce: Run cli command {code}/system-property=foo4:add(value="vvv\\"){code} in jboss-cli.  (was: Run cli command `/system-property=foo4:add(value="vvv\\")` in jboss-cli.)


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Oct 20 23:17:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Thu, 20 Oct 2016 23:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.28513.1477019820269@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310167#comment-13310167 ] 

Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------

As I mentioned in my PR comment, 
---
@jfdenise I confirmed the issue is not reproduced in wildfly-core 3.0.0.x of https://github.com/jfdenise/wildfly-core/tree/WFCORE-1878. However, I'd like to merge this, because:

*    EAP7.0.x is still based on wildfly-core 2.0.x and not guaranteed to move to wildfly-core 3.0.
*    this fix is good for other aesh application.
*    this is harmless to wildfly-core 3.0.

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 00:17:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 21 Oct 2016 00:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as
 children of the subsystem
In-Reply-To: <JIRA.12651855.1474723043000@Atlassian.JIRA>
References: <JIRA.12651855.1474723043000@Atlassian.JIRA>
	<JIRA.12651855.1474723043000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651855.1474723043000.28549.1477023420238@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-7210:
------------------------------------

    Assignee: Lin Gao  (was: Stuart Douglas)


> Expose JAX-RS resources as children of the subsystem
> ----------------------------------------------------
>
>                 Key: WFLY-7210
>                 URL: https://issues.jboss.org/browse/WFLY-7210
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>    Affects Versions: 10.1.0.Final
>            Reporter: Guillermo Gonz?lez de Ag?ero
>            Assignee: Lin Gao
>         Attachments: hal-jaxrs.png
>
>
> Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment: 
> [standalone at localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean)
> This makes it specially easy to navigate trough the web console (attached screenshot).
> To read JAX-RS resources, the command would be:
> [standalone at localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources()
> I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 21 00:18:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 21 Oct 2016 00:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as
 children of the subsystem
In-Reply-To: <JIRA.12651855.1474723043000@Atlassian.JIRA>
References: <JIRA.12651855.1474723043000@Atlassian.JIRA>
	<JIRA.12651855.1474723043000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651855.1474723043000.28555.1477023480240@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310175#comment-13310175 ] 

Stuart Douglas commented on WFLY-7210:
--------------------------------------

Assigning to Lin as he is responsible for WFLY-7024 as well

> Expose JAX-RS resources as children of the subsystem
> ----------------------------------------------------
>
>                 Key: WFLY-7210
>                 URL: https://issues.jboss.org/browse/WFLY-7210
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>    Affects Versions: 10.1.0.Final
>            Reporter: Guillermo Gonz?lez de Ag?ero
>            Assignee: Lin Gao
>         Attachments: hal-jaxrs.png
>
>
> Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment: 
> [standalone at localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean)
> This makes it specially easy to navigate trough the web console (attached screenshot).
> To read JAX-RS resources, the command would be:
> [standalone at localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources()
> I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 21 01:45:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Fri, 21 Oct 2016 01:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1887) [GSS](7.0.z) wrong parse of
 double quote in `\\"`
In-Reply-To: <JIRA.12656034.1477028675000@Atlassian.JIRA>
References: <JIRA.12656034.1477028675000@Atlassian.JIRA>
	<JIRA.12656034.1477028675702@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656034.1477028675000.28638.1477028700298@Atlassian.JIRA>

Hisanobu Okuda created WFCORE-1887:
--------------------------------------

             Summary: [GSS](7.0.z) wrong parse of double quote in `\\"` 
                 Key: WFCORE-1887
                 URL: https://issues.jboss.org/browse/WFCORE-1887
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
         Environment: JBoss EAP 7.0.0
            Reporter: Hisanobu Okuda
            Assignee: Jean-Francois Denise


jboss-cli does not parse command line if command line contains {code}\\"{code}

When a command is 
{code}/system-property=foo4:add(value="vvv\\"){code}
it shows the sub-prompt '> ' like:

{code}
[standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> 
{code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 01:48:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Fri, 21 Oct 2016 01:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1887) [GSS](7.0.z) wrong parse of
 double quote in `\\"`
In-Reply-To: <JIRA.12656034.1477028676000@Atlassian.JIRA>
References: <JIRA.12656034.1477028676000@Atlassian.JIRA>
	<JIRA.12656034.1477028676000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656034.1477028676000.28643.1477028880240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hisanobu Okuda closed WFCORE-1887.
----------------------------------
    Resolution: Done


> [GSS](7.0.z) wrong parse of double quote in `\\"` 
> --------------------------------------------------
>
>                 Key: WFCORE-1887
>                 URL: https://issues.jboss.org/browse/WFCORE-1887
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 03:56:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 21 Oct 2016 03:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.28940.1477036560661@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310214#comment-13310214 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

Hi,
your fix is in aesh. In order for 2.0.x to benefit from this fix you will need to upgrade 2.0.x to latest Aesh release. is it something that you plan to do? What is the ash release bundled with WFCore 2.0.x?



> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 04:28:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 21 Oct 2016 04:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.29089.1477038480848@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310230#comment-13310230 ] 

Tomaz Cerar commented on WFLY-6500:
-----------------------------------

Well, this stacktrace doesn't point to problem in WildFly deployment code but more into camuda integration with wildfly

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Jason Greene
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 04:30:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 21 Oct 2016 04:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.29095.1477038600638@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-6500.
-----------------------------
    Fix Version/s: 10.1.0.Final
         Assignee: Tomaz Cerar  (was: Jason Greene)
       Resolution: Out of Date


Evaluation of the issue points to external components.
Problem that existed in 10.0 appears that it is fixed in 10.1.
I am closing this issue as out of date

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Tomaz Cerar
>             Fix For: 10.1.0.Final
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 04:48:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Fri, 21 Oct 2016 04:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.29180.1477039680352@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310243#comment-13310243 ] 

Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------

Jean-Francios, EAP7.0.2 uses Aesh 0.66.4. I will request to upgrade it to >0.66.10 in the next CP.

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 04:51:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 21 Oct 2016 04:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.29192.1477039860475@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310244#comment-13310244 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

Hi, so you should perhaps try (perhaps you already did it?) with 0.66.11 today and see if the problem is still there. Some fixes have been added to Aesh since 0.66.4.


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:11:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Fri, 21 Oct 2016 05:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.29250.1477041060383@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310249#comment-13310249 ] 

Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------

Jean-Francois, EAP 7.0.2 replacing aesh jar with the fix (in the branch 0.66.+.double_backslash of https://github.com/hokuda/aesh) resolves the issue.

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:18:00 2016
From: issues at jboss.org (Vlado Pakan (JIRA))
Date: Fri, 21 Oct 2016 05:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT erro message
 "key server is currently not set" should be loged with debug level
In-Reply-To: <JIRA.12656068.1477041425000@Atlassian.JIRA>
References: <JIRA.12656068.1477041425000@Atlassian.JIRA>
	<JIRA.12656068.1477041425896@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656068.1477041425000.29376.1477041480470@Atlassian.JIRA>

Vlado Pakan created JGRP-2121:
---------------------------------

             Summary: ASYM_ENCRYPT erro message "key server is currently not set" should be loged 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: Bela Ban






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:18:00 2016
From: issues at jboss.org (Vlado Pakan (JIRA))
Date: Fri, 21 Oct 2016 05:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT erro message
 "key server is currently not set" should be loged with debug level
In-Reply-To: <JIRA.12656068.1477041426000@Atlassian.JIRA>
References: <JIRA.12656068.1477041426000@Atlassian.JIRA>
	<JIRA.12656068.1477041426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656068.1477041426000.29382.1477041480681@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vlado Pakan reassigned JGRP-2121:
---------------------------------

    Assignee: Vlado Pakan  (was: Bela Ban)


> ASYM_ENCRYPT erro message "key server is currently not set" should be loged 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:19:00 2016
From: issues at jboss.org (Vlado Pakan (JIRA))
Date: Fri, 21 Oct 2016 05:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT error message
 "key server is currently not set" should be loged with debug level
In-Reply-To: <JIRA.12656068.1477041426000@Atlassian.JIRA>
References: <JIRA.12656068.1477041426000@Atlassian.JIRA>
	<JIRA.12656068.1477041426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656068.1477041426000.29397.1477041540447@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vlado Pakan updated JGRP-2121:
------------------------------
    Summary: ASYM_ENCRYPT error message "key server is currently not set" should be loged with debug level  (was: ASYM_ENCRYPT erro message "key server is currently not set" should be loged with debug level)


> ASYM_ENCRYPT error message "key server is currently not set" should be loged 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:19:00 2016
From: issues at jboss.org (Vlado Pakan (JIRA))
Date: Fri, 21 Oct 2016 05:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT error message
 "key server is currently not set" should be logged with debug level
In-Reply-To: <JIRA.12656068.1477041426000@Atlassian.JIRA>
References: <JIRA.12656068.1477041426000@Atlassian.JIRA>
	<JIRA.12656068.1477041426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656068.1477041426000.29401.1477041540635@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vlado Pakan updated JGRP-2121:
------------------------------
    Summary: ASYM_ENCRYPT error message "key server is currently not set" should be logged with debug level  (was: ASYM_ENCRYPT error message "key server is currently not set" should be loged with debug level)


> 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
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:21:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Oct 2016 05:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT error message
 "key server is currently not set" should be logged with debug level
In-Reply-To: <JIRA.12656068.1477041426000@Atlassian.JIRA>
References: <JIRA.12656068.1477041426000@Atlassian.JIRA>
	<JIRA.12656068.1477041426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656068.1477041426000.29404.1477041660296@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2121:
---------------------------
    Fix Version/s: 4.0
         Priority: Trivial  (was: Major)


> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:34:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Oct 2016 05:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT error message
 "key server is currently not set" should be logged with debug level
In-Reply-To: <JIRA.12656068.1477041426000@Atlassian.JIRA>
References: <JIRA.12656068.1477041426000@Atlassian.JIRA>
	<JIRA.12656068.1477041426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656068.1477041426000.29417.1477042440313@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2121.
----------------------------
    Resolution: Done


> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:35:00 2016
From: issues at jboss.org (Vlado Pakan (JIRA))
Date: Fri, 21 Oct 2016 05:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT error message
 "key server is currently not set" should be logged with debug level
In-Reply-To: <JIRA.12656068.1477041426000@Atlassian.JIRA>
References: <JIRA.12656068.1477041426000@Atlassian.JIRA>
	<JIRA.12656068.1477041426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656068.1477041426000.29423.1477042500077@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310258#comment-13310258 ] 

Vlado Pakan commented on JGRP-2121:
-----------------------------------

PR: https://github.com/belaban/JGroups/pull/327

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:36:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 21 Oct 2016 05:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.29428.1477042560265@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310259#comment-13310259 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

And without the fix, just upgrade to 0.66.+ branch?


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:39:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Fri, 21 Oct 2016 05:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.29443.1477042740283@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310261#comment-13310261 ] 

Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------

The issue was reproduced.

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 05:40:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 21 Oct 2016 05:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.29457.1477042800513@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310263#comment-13310263 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

So something is hiding the problem in latest wf-core. That is strange.

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 06:01:05 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 21 Oct 2016 06:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-677) Credential-reference should be
 resolved in time of request.
In-Reply-To: <JIRA.12655947.1476976242000@Atlassian.JIRA>
References: <JIRA.12655947.1476976242000@Atlassian.JIRA>
	<JIRA.12655947.1476976242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655947.1476976242000.29574.1477044065390@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek reassigned ELY-677:
--------------------------------

    Assignee: Hynek ?v?bek  (was: Peter Skopek)


> Credential-reference should be resolved in time of request.
> -----------------------------------------------------------
>
>                 Key: ELY-677
>                 URL: https://issues.jboss.org/browse/ELY-677
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Hynek ?v?bek
>            Assignee: Hynek ?v?bek
>         Attachments: firefly.keystore
>
>
> Credential-reference should be resolved in time of request.
> When you added KeyStore to Elytron subsystem which have credential-reference to non-exists credential store then you can see this error message
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("key-store" => "firefly")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.NonexistingCredentialStore"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.firefly is missing [org.wildfly.security.credential-store-client.NonexistingCredentialStore]"]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 21 06:01:05 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 21 Oct 2016 06:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-677) Credential-reference should be
 resolved in time of request.
In-Reply-To: <JIRA.12655947.1476976242000@Atlassian.JIRA>
References: <JIRA.12655947.1476976242000@Atlassian.JIRA>
	<JIRA.12655947.1476976242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655947.1476976242000.29576.1477044065510@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-677:
-----------------------------
    Steps to Reproduce: 
* copy to firefly.keystore which is attached.
* run EAP server
./bin/standalone.sh
* run CLI
./bin/jboss-cli.sh -c
if applicaple add Elytron extension and Elytron subsystem and reload server
/extension=org.wildfly.extension.elytron:add()
/subsystem=elytron:add()
reload

* /subsystem=elytron/key-store=firefly:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference={store=NonexistingCredentialStore,alias=ff})


 



  was:
* copy to firefly.keystore which are attached.
* run EAP server
./bin/standalone.sh
* run CLI
./bin/jboss-cli.sh -c
if applicaple add Elytron extension and Elytron subsystem and reload server
/extension=org.wildfly.extension.elytron:add()
/subsystem=elytron:add()
reload

* /subsystem=elytron/key-store=firefly:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference={store=NonexistingCredentialStore,alias=ff})


 





> Credential-reference should be resolved in time of request.
> -----------------------------------------------------------
>
>                 Key: ELY-677
>                 URL: https://issues.jboss.org/browse/ELY-677
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Hynek ?v?bek
>            Assignee: Hynek ?v?bek
>         Attachments: firefly.keystore
>
>
> Credential-reference should be resolved in time of request.
> When you added KeyStore to Elytron subsystem which have credential-reference to non-exists credential store then you can see this error message
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("key-store" => "firefly")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.NonexistingCredentialStore"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.firefly is missing [org.wildfly.security.credential-store-client.NonexistingCredentialStore]"]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 21 06:02:14 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 21 Oct 2016 06:02:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-677) Credential-reference should be
 resolved in time of request.
In-Reply-To: <JIRA.12655947.1476976242000@Atlassian.JIRA>
References: <JIRA.12655947.1476976242000@Atlassian.JIRA>
	<JIRA.12655947.1476976242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655947.1476976242000.29810.1477044134442@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-677:
-----------------------------
    Steps to Reproduce: 
* firefly.keystore which is attached copy to eap_home/standalone/data/cs.
* run EAP server
./bin/standalone.sh
* run CLI
./bin/jboss-cli.sh -c
if applicaple add Elytron extension and Elytron subsystem and reload server
/extension=org.wildfly.extension.elytron:add()
/subsystem=elytron:add()
reload

* /subsystem=elytron/key-store=firefly:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference={store=NonexistingCredentialStore,alias=ff})


 



  was:
* copy to firefly.keystore which is attached.
* run EAP server
./bin/standalone.sh
* run CLI
./bin/jboss-cli.sh -c
if applicaple add Elytron extension and Elytron subsystem and reload server
/extension=org.wildfly.extension.elytron:add()
/subsystem=elytron:add()
reload

* /subsystem=elytron/key-store=firefly:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference={store=NonexistingCredentialStore,alias=ff})


 





> Credential-reference should be resolved in time of request.
> -----------------------------------------------------------
>
>                 Key: ELY-677
>                 URL: https://issues.jboss.org/browse/ELY-677
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Hynek ?v?bek
>            Assignee: Hynek ?v?bek
>         Attachments: firefly.keystore
>
>
> Credential-reference should be resolved in time of request.
> When you added KeyStore to Elytron subsystem which have credential-reference to non-exists credential store then you can see this error message
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("key-store" => "firefly")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.NonexistingCredentialStore"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.firefly is missing [org.wildfly.security.credential-store-client.NonexistingCredentialStore]"]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 21 06:18:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 21 Oct 2016 06:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-678) Credential-reference(alias=)
 should be resolved in time of request.
In-Reply-To: <JIRA.12656085.1477045077000@Atlassian.JIRA>
References: <JIRA.12656085.1477045077000@Atlassian.JIRA>
	<JIRA.12656085.1477045077210@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656085.1477045077000.30191.1477045080341@Atlassian.JIRA>

Hynek ?v?bek created ELY-678:
--------------------------------

             Summary: Credential-reference(alias=) should be resolved in time of request.
                 Key: ELY-678
                 URL: https://issues.jboss.org/browse/ELY-678
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
    Affects Versions: 1.1.0.Beta10
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek
         Attachments: credentialstore.jceks, firefly.keystore

Credential-reference should be resolved in time of request - in this case the alias which contains wrong password in CredentialStore (we can change it later to right password...).

If I add credential reference with alias which contains wrong password then I get this error:
{code}
{
        "outcome" => "failed",                                                                                           
        "failure-description" => {                                                                                       
            "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fireflyWrong" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fireflyWrong: WFLYELY00004: Unable to start the service.      
        Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect                            
        Caused by: java.security.UnrecoverableKeyException: Password verification failed"},                              
            "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fireflyWrong"], 
            "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined                                   
        },                                                                                                               
        "rolled-back" => true                                                                                            
    }
{code}

*When I reload server then same command pass!*
But I nowhere got information about reload-required
{code}
/subsystem=elytron/key-store=fireflyWrong:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=credStore2,alias=ffWithWrongPass})
{code}





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 21 06:19:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 21 Oct 2016 06:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-677) Credential-reference(store=)
 should be resolved in time of request.
In-Reply-To: <JIRA.12655947.1476976242000@Atlassian.JIRA>
References: <JIRA.12655947.1476976242000@Atlassian.JIRA>
	<JIRA.12655947.1476976242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655947.1476976242000.30193.1477045140179@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-677:
-----------------------------
    Summary: Credential-reference(store=) should be resolved in time of request.  (was: Credential-reference should be resolved in time of request.)


> Credential-reference(store=) should be resolved in time of request.
> -------------------------------------------------------------------
>
>                 Key: ELY-677
>                 URL: https://issues.jboss.org/browse/ELY-677
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Hynek ?v?bek
>            Assignee: Hynek ?v?bek
>         Attachments: firefly.keystore
>
>
> Credential-reference should be resolved in time of request.
> When you added KeyStore to Elytron subsystem which have credential-reference to non-exists credential store then you can see this error message
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("key-store" => "firefly")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.NonexistingCredentialStore"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.firefly is missing [org.wildfly.security.credential-store-client.NonexistingCredentialStore]"]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 21 06:19:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 21 Oct 2016 06:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-677) Credential-reference(store=...)
 should be resolved in time of request.
In-Reply-To: <JIRA.12655947.1476976242000@Atlassian.JIRA>
References: <JIRA.12655947.1476976242000@Atlassian.JIRA>
	<JIRA.12655947.1476976242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655947.1476976242000.30195.1477045140228@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-677:
-----------------------------
    Summary: Credential-reference(store=...) should be resolved in time of request.  (was: Credential-reference(store=) should be resolved in time of request.)


> Credential-reference(store=...) should be resolved in time of request.
> ----------------------------------------------------------------------
>
>                 Key: ELY-677
>                 URL: https://issues.jboss.org/browse/ELY-677
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Hynek ?v?bek
>            Assignee: Hynek ?v?bek
>         Attachments: firefly.keystore
>
>
> Credential-reference should be resolved in time of request.
> When you added KeyStore to Elytron subsystem which have credential-reference to non-exists credential store then you can see this error message
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("key-store" => "firefly")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.NonexistingCredentialStore"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.firefly is missing [org.wildfly.security.credential-store-client.NonexistingCredentialStore]"]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 21 06:29:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 21 Oct 2016 06:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-677) Credential-reference(store=...)
 should be resolved in time of request.
In-Reply-To: <JIRA.12655947.1476976242000@Atlassian.JIRA>
References: <JIRA.12655947.1476976242000@Atlassian.JIRA>
	<JIRA.12655947.1476976242000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655947.1476976242000.30319.1477045740336@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek reassigned ELY-677:
--------------------------------

    Assignee: Peter Skopek  (was: Hynek ?v?bek)


> Credential-reference(store=...) should be resolved in time of request.
> ----------------------------------------------------------------------
>
>                 Key: ELY-677
>                 URL: https://issues.jboss.org/browse/ELY-677
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>         Attachments: firefly.keystore
>
>
> Credential-reference should be resolved in time of request.
> When you added KeyStore to Elytron subsystem which have credential-reference to non-exists credential store then you can see this error message
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("key-store" => "firefly")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.NonexistingCredentialStore"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.firefly is missing [org.wildfly.security.credential-store-client.NonexistingCredentialStore]"]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Fri Oct 21 07:58:01 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Fri, 21 Oct 2016 07:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.30662.1477051081130@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310326#comment-13310326 ] 

Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------

Jean-Francois, I found that the latest wildfly-core 3.0.x blows it off to find open quote setting false to org.jboss.aesh.parser.Parser.setParsingQuotes().

{code}
[hokuda at dhcp-193-78 01719672_eap7_jboss-cli]$ rljdb -attach localhost:8787
/usr/local/bin/rlwrap -H ./rljdb.history -l ./rljdb.log -w 10 -pRED -C jdbxxx -b ' .' -z /home/hokuda/bin/rljdb_filter jdb -attach localhost:8787
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
> 
VM Started: No frames on the current call stack

Found ./rljdb.breakpoint
main[1] run
> Set deferred breakpoint org.jboss.aesh.parser.Parser.setParsingQuotes(boolean)
Set deferred breakpoint org.jboss.aesh.parser.Parser.doesStringContainOpenQuote(java.lang.String)

Breakpoint hit: "thread=main", org.jboss.aesh.parser.Parser.setParsingQuotes(), line=790 bci=0

main[1] where
  [1] org.jboss.aesh.parser.Parser.setParsingQuotes (Parser.java:790)
  [2] org.jboss.aesh.console.Console.init (Console.java:162)
  [3] org.jboss.aesh.console.Console.<init> (Console.java:118)
  [4] org.jboss.as.cli.impl.Console$Factory.getConsole (Console.java:123)
  [5] org.jboss.as.cli.impl.Console$Factory.getConsole (Console.java:116)
  [6] org.jboss.as.cli.impl.CommandContextImpl.initBasicConsole (CommandContextImpl.java:413)
  [7] org.jboss.as.cli.impl.CommandContextImpl.<init> (CommandContextImpl.java:381)
  [8] org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext (CommandContextFactoryImpl.java:157)
  [9] org.jboss.as.cli.impl.CliLauncher.initCommandContext (CliLauncher.java:305)
  [10] org.jboss.as.cli.impl.CliLauncher.main (CliLauncher.java:285)
  [11] org.jboss.as.cli.CommandLineMain.main (CommandLineMain.java:45)
  [12] sun.reflect.NativeMethodAccessorImpl.invoke0 (native method)
  [13] sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
  [14] sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
  [15] java.lang.reflect.Method.invoke (Method.java:498)
  [16] org.jboss.modules.Module.run (Module.java:336)
  [17] org.jboss.modules.Main.main (Main.java:520)
main[1] locals
Method arguments:
parsingQuotes = false
Local variables:
{code}

If parsingQuotes == false, org.jboss.aesh.parser.Parser.doesStringContainOpenQuote() does nothing.

{code}
  public static boolean doesStringContainOpenQuote(String text)
  {
    if (!parsingQuotes) {
      return false;
    }
{code}

[https://github.com/wildfly/wildfly-core/commit/027bfe959988b25e45771491e494ca61c19a986b#diff-c929deeb25b1e0886f6c256907ea7c44] introduced disabling parsing quotes in cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java:

{code}
+        settings.parsingQuotes(false);
{code}

The above line should be removed, and the fix should be applied.

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 08:06:00 2016
From: issues at jboss.org (Michael Peoples (JIRA))
Date: Fri, 21 Oct 2016 08:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.30756.1477051560360@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310332#comment-13310332 ] 

Michael Peoples commented on WFLY-6500:
---------------------------------------

You may be correct here.  We've been trying multiple versions of WildFly and Camunda.  The problem appears in all combinations, though I cannot say this definitively as we have not conducted a formalized series of tests.  We may be forced to spend a day or more doing these tests to prove there is, in fact, an issue.

Thank you for taking the time to review these posts.

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Tomaz Cerar
>             Fix For: 10.1.0.Final
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 08:19:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 21 Oct 2016 08:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.30813.1477052340213@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310339#comment-13310339 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

Yes, we have disabled quotes parsing due to https://issues.jboss.org/browse/WFCORE-1804
It was breaking some 6.4 scripts redirected to the console.
These scripts contains comments without escaped single quote. So Aesh had a wrong behaviour,


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 08:34:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Oct 2016 08:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT error message
 "key server is currently not set" should be logged with debug level
In-Reply-To: <JIRA.12656068.1477041426000@Atlassian.JIRA>
References: <JIRA.12656068.1477041426000@Atlassian.JIRA>
	<JIRA.12656068.1477041426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656068.1477041426000.30938.1477053240499@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310347#comment-13310347 ] 

RH Bugzilla Integration commented on JGRP-2121:
-----------------------------------------------

Vlado Pakan <vpakan at redhat.com> changed the Status of [bug 1380657|https://bugzilla.redhat.com/show_bug.cgi?id=1380657] from ASSIGNED to POST

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 09:11:00 2016
From: issues at jboss.org (Patrick Kleindienst (JIRA))
Date: Fri, 21 Oct 2016 09:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1875) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.31163.1477055460195@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Kleindienst updated WFCORE-1875:
----------------------------------------
    Steps to Reproduce: 
# Created self-signed Logstash cert with OpenSSL:
{code}
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
{code}
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
{code}
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)

  was:

# Created self-signed Logstash cert with OpenSSL:
{code}
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)



> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1875
>                 URL: https://issues.jboss.org/browse/WFCORE-1875
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 09:12:00 2016
From: issues at jboss.org (Patrick Kleindienst (JIRA))
Date: Fri, 21 Oct 2016 09:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1875) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.31177.1477055520985@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Kleindienst updated WFCORE-1875:
----------------------------------------
    Steps to Reproduce: 
# Created self-signed Logstash cert with OpenSSL:
{code}
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
{code}
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
{code}
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		  <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
                 <property name="hostname" value="192.168.144.101"/>
		 <property name="port" value="12202"/>
		 <property name="protocol" value="SSL_TCP"/>
	      </properties>
      </custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)

  was:
# Created self-signed Logstash cert with OpenSSL:
{code}
   openssl req -x509 -newkey rsa:4096 -keyout logstash_ssl.key -out logstash_ssl.crt -nodes -days 365
{code}
# Configured Logstash TCP input to use generated cert and key:
{code}
input {
  tcp {
    port => 12202
    codec => "json"
    ssl_enable => true
    ssl_cert => "/path/to/logstash_ssl.crt"
    ssl_key => "/path/to/logstash_ssl.key"
    ssl_verify => false 
  }
}
{code}
# Imported cert into a new truststore:
{code}
   keytool -import -alias mycert -file mycert.cer -keystore logstashTruststore 
{code}
# Added jboss-logmanager-ext to modules
# Configured SocketHandler in standalone.xml as follows (formatter config is omitted):
{code}
    <custom-handler name="LOGSTASH" class="org.jboss.logmanager.ext.handlers.SocketHandler" module="log.logmanager-ext">
	   <level name="DEBUG"/>
	   <formatter>
		      <named-formatter name="LOGSTASH-FORMATTER"/>
	   </formatter>
	    <properties>
			<property name="hostname" value="192.168.144.101"/>
			<property name="port" value="12202"/>
			<property name="protocol" value="SSL_TCP"/>
	      </properties>
	</custom-handler>
{code}
# Added truststore path as well as password to VM options:
{code}
   -Djavax.net.ssl.trustStore=/path/to/logstashTruststore
   -Djavax.net.ssl.trustStorePassword="mypassword"
{code}
# related versions:
   * JDK 1.8.0_11 and 1.8.0_101
   * WildFly 10.1.0 and 10.0.0
   * Logstash 2.1.3 (same behavior with latest Logstash 5.0)



> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1875
>                 URL: https://issues.jboss.org/browse/WFCORE-1875
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 09:13:01 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 21 Oct 2016 09:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1157) Managmement and JMX
 notifications when ControlledProcessState changes
In-Reply-To: <JIRA.12593860.1448317498000@Atlassian.JIRA>
References: <JIRA.12593860.1448317498000@Atlassian.JIRA>
	<JIRA.12593860.1448317498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593860.1448317498000.31195.1477055581059@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1157:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Kabir Khan)


> Managmement and JMX notifications when ControlledProcessState changes
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-1157
>                 URL: https://issues.jboss.org/browse/WFCORE-1157
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, JMX
>            Reporter: Brian Stansberry
>            Assignee: Jeff Mesnil
>             Fix For: 3.0.0.Alpha11
>
>
> When Jeff Mesnil added the core management notification stuff an obvious thing to do was to emit notifications around ControlledProcessState changes. But I forgot. :( So lets do it.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 09:23:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Oct 2016 09:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2119) Separate JMX objects
In-Reply-To: <JIRA.12655663.1476879269000@Atlassian.JIRA>
References: <JIRA.12655663.1476879269000@Atlassian.JIRA>
	<JIRA.12655663.1476879269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655663.1476879269000.31294.1477056180441@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310391#comment-13310391 ] 

Bela Ban commented on JGRP-2119:
--------------------------------

Done. Any object implementing AdditionalJmxObjects can return a number of instances which expose attributes (get and set) or operations by simply annotating them with {{@ManagedAttribute}} or {{@ManagedOperation}}.

For an example, see MsgStats used by TP to maintain various counters on msgs sent, received etc

> Separate JMX objects
> --------------------
>
>                 Key: JGRP-2119
>                 URL: https://issues.jboss.org/browse/JGRP-2119
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Provide managed attributes or operations in separate classes, e.g. to be used for stats in TP. These could include num_msgs_sent, num_batches_received etc.
> A protocol could implement an interface (e.g. AdditionalStats), which would return a list of objects whose attributes and operations should be exposed together with the protocol.
> This would reduce code in TP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 09:23:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 21 Oct 2016 09:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2119) Separate JMX objects
In-Reply-To: <JIRA.12655663.1476879269000@Atlassian.JIRA>
References: <JIRA.12655663.1476879269000@Atlassian.JIRA>
	<JIRA.12655663.1476879269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655663.1476879269000.31298.1477056180555@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2119.
----------------------------
    Resolution: Done


> Separate JMX objects
> --------------------
>
>                 Key: JGRP-2119
>                 URL: https://issues.jboss.org/browse/JGRP-2119
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Provide managed attributes or operations in separate classes, e.g. to be used for stats in TP. These could include num_msgs_sent, num_batches_received etc.
> A protocol could implement an interface (e.g. AdditionalStats), which would return a list of objects whose attributes and operations should be exposed together with the protocol.
> This would reduce code in TP.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 09:24:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 21 Oct 2016 09:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1886) Adding ldap-realm in
 Elytron sometimes register capability even if add operation failed
In-Reply-To: <JIRA.12653713.1475821914000@Atlassian.JIRA>
References: <JIRA.12653713.1475821914000@Atlassian.JIRA>
	<JIRA.12653713.1475821914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653713.1475821914000.31306.1477056240356@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310392#comment-13310392 ] 

Tomaz Cerar commented on WFCORE-1886:
-------------------------------------

[~brian.stansberry] Your fix looks good, it is something similar I had in mind for fixing it.
To have the whole chain concurrent not just few parts as we have now.

Test itself might be bit trickier to write.

> Adding ldap-realm in Elytron sometimes register capability even if add operation failed
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1886
>                 URL: https://issues.jboss.org/browse/WFCORE-1886
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> In case when adding Elytron ldap-realm capability through CLI takes some time (e.g. 5 seconds) then this capability is registered in context even if command failed (e.g. because some required attribute is missing). Then when command is fixed it cannot be added since capability was already registered. Server has to be reloaded to unregister this non-exist capability. See 'Steps to Reproduce' for more detail.
> I am able to simulate this behavior with ldap-realm from Elytron. However I am not sure whether this issue can be related to whole Elytron subsystem or whole Domain Model.
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-realm" => "ldap")
> ]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.security-realm.ldap' is already registered in context 'global'.
> 	at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:158)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1449)
> 	at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1441)
> 	at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> 	at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 09:41:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Oct 2016 09:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6214) Change
 CMTTxInterceptor.endTransaction() handling of Status.ROLLING_BACK
In-Reply-To: <JIRA.12603962.1455551828000@Atlassian.JIRA>
References: <JIRA.12603962.1455551828000@Atlassian.JIRA>
	<JIRA.12603962.1455551828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603962.1455551828000.31372.1477057260417@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310400#comment-13310400 ] 

RH Bugzilla Integration commented on WFLY-6214:
-----------------------------------------------

Fedor Gavrilov <fgavrilo at redhat.com> changed the Status of [bug 1387319|https://bugzilla.redhat.com/show_bug.cgi?id=1387319] from ASSIGNED to POST

> Change CMTTxInterceptor.endTransaction() handling of Status.ROLLING_BACK
> ------------------------------------------------------------------------
>
>                 Key: WFLY-6214
>                 URL: https://issues.jboss.org/browse/WFLY-6214
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Transactions
>            Reporter: Scott Marlow
>            Assignee: Tom Jenkinson
>            Priority: Blocker
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> See recent comment [https://developer.jboss.org/message/950898#950898]
> {quote}
> Status.STATUS_COMMITTING:
> Status.STATUS_COMMITTED:
> Status.STATUS_PREPARED:
> Status.STATUS_PREPARING:
> * Someone has called commit in parallel and the transaction is trying to commit so try to commit too: call tm.commit
> {quote}
> I think that TimerCMTTxInterceptor/LifecycleCMTTxInterceptor are using CMTTxInterceptor.endTransaction(), so they shouldn't need changes.
> Status.STATUS_ROLLING_BACK can happen if the reaper has started to rollback the transaction



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 09:45:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Fri, 21 Oct 2016 09:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.31387.1477057500303@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310403#comment-13310403 ] 

Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------

Does quotes parsing stay disabled for future?

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 10:03:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 21 Oct 2016 10:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.31494.1477058580868@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310422#comment-13310422 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

In the current CLI, we should have the control on what is or is not parsed (operators, escaping). If we delegate this parsing to Aesh we can encounter regressions (that WFCORE-1804 has shown).
So I would say so. 

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 10:11:00 2016
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 21 Oct 2016 10:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7365) Upgrade HAL to 2.9.0.Alpha4
In-Reply-To: <JIRA.12656143.1477059020000@Atlassian.JIRA>
References: <JIRA.12656143.1477059020000@Atlassian.JIRA>
	<JIRA.12656143.1477059020000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656143.1477059020000.31549.1477059060523@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl updated WFLY-7365:
------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/9233)


> Upgrade HAL to 2.9.0.Alpha4
> ---------------------------
>
>                 Key: WFLY-7365
>                 URL: https://issues.jboss.org/browse/WFLY-7365
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 10:11:00 2016
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 21 Oct 2016 10:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7365) Upgrade HAL to 2.9.0.Alpha4
In-Reply-To: <JIRA.12656143.1477059020000@Atlassian.JIRA>
References: <JIRA.12656143.1477059020000@Atlassian.JIRA>
	<JIRA.12656143.1477059020157@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656143.1477059020000.31547.1477059060437@Atlassian.JIRA>

Harald Pehl created WFLY-7365:
---------------------------------

             Summary: Upgrade HAL to 2.9.0.Alpha4
                 Key: WFLY-7365
                 URL: https://issues.jboss.org/browse/WFLY-7365
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Harald Pehl
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 10:59:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 21 Oct 2016 10:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7308) JspELTestCase fails with
	security manager
In-Reply-To: <JIRA.12654667.1476360442000@Atlassian.JIRA>
References: <JIRA.12654667.1476360442000@Atlassian.JIRA>
	<JIRA.12654667.1476360442000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654667.1476360442000.32021.1477061940105@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFLY-7308:
--------------------------------

    Assignee: Ingo Weiss  (was: Jan Tymel)


> JspELTestCase fails with security manager
> -----------------------------------------
>
>                 Key: WFLY-7308
>                 URL: https://issues.jboss.org/browse/WFLY-7308
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ingo Weiss
>
> *org.wildfly.test.integration.jsp.JspELTestCase#testJavaLangImplicitClassELEvaluation*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=JspELTestCase -Dsecurity.manager}}
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /d0ead681-8b75-48ba-8af6-7f08323da424/index.jsp: org.apache.jasper.JasperException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/d0ead681-8b75-48ba-8af6-7f08323da424.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader at 14183b28")
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 	at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/d0ead681-8b75-48ba-8af6-7f08323da424.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader at 14183b28")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1440)
> 	at javax.el.ImportHandler.getClassFor(ImportHandler.java:176)
> 	at javax.el.ImportHandler.resolveClassFor(ImportHandler.java:165)
> 	at javax.el.ImportHandler.resolveClass(ImportHandler.java:128)
> 	at org.wildfly.extension.undertow.ImportedClassELResolver.getValue(ImportedClassELResolver.java:58)
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:96)
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116)
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:150)
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:199)
> 	at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
> 	at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:917)
> 	at org.apache.jsp.index_jsp._jspService(index_jsp.java:100)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 11:08:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 21 Oct 2016 11:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7308) JspELTestCase fails with
	security manager
In-Reply-To: <JIRA.12654667.1476360442000@Atlassian.JIRA>
References: <JIRA.12654667.1476360442000@Atlassian.JIRA>
	<JIRA.12654667.1476360442000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654667.1476360442000.32072.1477062480125@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss updated WFLY-7308:
-----------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9284


> JspELTestCase fails with security manager
> -----------------------------------------
>
>                 Key: WFLY-7308
>                 URL: https://issues.jboss.org/browse/WFLY-7308
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ingo Weiss
>
> *org.wildfly.test.integration.jsp.JspELTestCase#testJavaLangImplicitClassELEvaluation*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=JspELTestCase -Dsecurity.manager}}
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /d0ead681-8b75-48ba-8af6-7f08323da424/index.jsp: org.apache.jasper.JasperException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/d0ead681-8b75-48ba-8af6-7f08323da424.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader at 14183b28")
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402)
> 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 	at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/d0ead681-8b75-48ba-8af6-7f08323da424.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader at 14183b28")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> 	at java.lang.Thread.getContextClassLoader(Thread.java:1440)
> 	at javax.el.ImportHandler.getClassFor(ImportHandler.java:176)
> 	at javax.el.ImportHandler.resolveClassFor(ImportHandler.java:165)
> 	at javax.el.ImportHandler.resolveClass(ImportHandler.java:128)
> 	at org.wildfly.extension.undertow.ImportedClassELResolver.getValue(ImportedClassELResolver.java:58)
> 	at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:96)
> 	at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116)
> 	at com.sun.el.parser.AstValue.getBase(AstValue.java:150)
> 	at com.sun.el.parser.AstValue.getValue(AstValue.java:199)
> 	at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
> 	at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:917)
> 	at org.apache.jsp.index_jsp._jspService(index_jsp.java:100)
> 	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 11:13:01 2016
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 21 Oct 2016 11:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-679) AggregateSecurityRealm not
 overriding method RealmIdentity.getRealmIdentityPrincipal
In-Reply-To: <JIRA.12656156.1477062761000@Atlassian.JIRA>
References: <JIRA.12656156.1477062761000@Atlassian.JIRA>
	<JIRA.12656156.1477062761081@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656156.1477062761000.32135.1477062781263@Atlassian.JIRA>

Pedro Igor created ELY-679:
------------------------------

             Summary: AggregateSecurityRealm not overriding method RealmIdentity.getRealmIdentityPrincipal
                 Key: ELY-679
                 URL: https://issues.jboss.org/browse/ELY-679
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: Realms
    Affects Versions: 1.1.0.Beta11
            Reporter: Pedro Igor
            Assignee: Pedro Igor






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 11:18:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 21 Oct 2016 11:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7307) Some XTS tests fail with
	security manager
In-Reply-To: <JIRA.12654662.1476359866000@Atlassian.JIRA>
References: <JIRA.12654662.1476359866000@Atlassian.JIRA>
	<JIRA.12654662.1476359866000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654662.1476359866000.32216.1477063080334@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310469#comment-13310469 ] 

Ingo Weiss commented on WFLY-7307:
----------------------------------

I'm not seeing these on the latest version of {{master}}.

> Some XTS tests fail with security manager
> -----------------------------------------
>
>                 Key: WFLY-7307
>                 URL: https://issues.jboss.org/browse/WFLY-7307
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Jan Tymel
>
> *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorApplicationException*
> *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorCannotComplete*
> *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorClientCancel*
> *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorCompletionFailToComplete*
> *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSimple*
> *org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSingle*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=BACoordinatorCompletionTestCase -Dsecurity.manager}}
> {code}
> 13:49:00,854 ERROR [stderr] (default task-1) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/wsba-coordinatorcompletition-test.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.wsba-coordinatorcompletition-test.war:main" from Service Module Loader")
> 13:49:00,856 ERROR [stderr] (default task-1) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 13:49:00,857 ERROR [stderr] (default task-1) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 13:49:00,859 ERROR [stderr] (default task-1) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
> 13:49:00,872 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
> 13:49:00,873 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
> 13:49:00,874 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
> 13:49:00,874 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
> 13:49:00,886 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
> 13:49:00,890 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
> 13:49:00,891 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
> 13:49:00,894 ERROR [stderr] (default task-1) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
> 13:49:00,895 ERROR [stderr] (default task-1) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 13:49:00,898 ERROR [stderr] (default task-1) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 13:49:00,899 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 13:49:00,900 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 13:49:00,901 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 13:49:00,908 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 13:49:00,909 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:49:00,910 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 13:49:00,911 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 13:49:00,911 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:49:00,916 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 13:49:00,917 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 13:49:00,918 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 13:49:00,920 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 13:49:00,923 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 13:49:00,924 ERROR [stderr] (default task-1) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 13:49:00,925 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:49:00,927 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 13:49:00,928 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:49:00,929 ERROR [stderr] (default task-1) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:49:00,930 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 13:49:00,931 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 13:49:00,933 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 13:49:00,934 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 13:49:00,935 ERROR [stderr] (default task-1) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 13:49:00,935 ERROR [stderr] (default task-1) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 13:49:00,939 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 13:49:00,940 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:49:00,941 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:49:00,942 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:49:00,943 ERROR [stderr] (default task-1) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:49:00,944 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 13:49:00,944 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 13:49:00,945 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> 13:49:00,946 ERROR [stderr] (default task-1) 	at java.security.AccessController.doPrivileged(Native Method)
> 13:49:00,947 ERROR [stderr] (default task-1) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> 13:49:00,948 ERROR [stderr] (default task-1) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 13:49:00,952 ERROR [stderr] (default task-1) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 13:49:00,953 ERROR [stderr] (default task-1) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 13:49:00,955 ERROR [stderr] (default task-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 13:49:00,956 ERROR [stderr] (default task-1) 	at java.lang.Thread.run(Thread.java:745)
> {code}
> *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATApplicationException*
> *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATApplicationExceptionCommit*
> *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATClientRollback*
> *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATRollbackOnly*
> *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATSimple*
> *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATSingleSimple*
> *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteReadOnly*
> *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteRollback*
> *org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteRollbackPrePrepare*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=ATTestCase -Dsecurity.manager}}
> {code}
> 13:52:13,655 ERROR [stderr] (default task-2) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/wsat-test.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.wsat-test.war:main" from Service Module Loader")
> 13:52:13,656 ERROR [stderr] (default task-2) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 13:52:13,657 ERROR [stderr] (default task-2) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 13:52:13,658 ERROR [stderr] (default task-2) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
> 13:52:13,658 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
> 13:52:13,659 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
> 13:52:13,660 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
> 13:52:13,660 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
> 13:52:13,661 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
> 13:52:13,662 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
> 13:52:13,662 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
> 13:52:13,663 ERROR [stderr] (default task-2) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
> 13:52:13,664 ERROR [stderr] (default task-2) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 13:52:13,664 ERROR [stderr] (default task-2) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 13:52:13,665 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 13:52:13,666 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 13:52:13,666 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 13:52:13,667 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 13:52:13,668 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:52:13,668 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 13:52:13,669 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 13:52:13,669 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:52:13,670 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 13:52:13,671 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 13:52:13,671 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 13:52:13,672 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 13:52:13,673 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 13:52:13,673 ERROR [stderr] (default task-2) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 13:52:13,674 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:52:13,677 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 13:52:13,678 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:52:13,679 ERROR [stderr] (default task-2) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:52:13,680 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 13:52:13,681 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 13:52:13,682 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 13:52:13,683 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 13:52:13,684 ERROR [stderr] (default task-2) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 13:52:13,685 ERROR [stderr] (default task-2) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 13:52:13,685 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 13:52:13,686 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:52:13,687 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:52:13,689 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:52:13,690 ERROR [stderr] (default task-2) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:52:13,691 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 13:52:13,692 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 13:52:13,693 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> 13:52:13,694 ERROR [stderr] (default task-2) 	at java.security.AccessController.doPrivileged(Native Method)
> 13:52:13,695 ERROR [stderr] (default task-2) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> 13:52:13,696 ERROR [stderr] (default task-2) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 13:52:13,696 ERROR [stderr] (default task-2) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 13:52:13,698 ERROR [stderr] (default task-2) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 13:52:13,699 ERROR [stderr] (default task-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 13:52:13,699 ERROR [stderr] (default task-2) 	at java.lang.Thread.run(Thread.java:745)
> {code}
> *org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testActiveTransaction*
> *org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testNoTransaction*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=TransactionalTestCase -Dsecurity.manager}}
> {code}
> 13:53:42,849 ERROR [stderr] (default task-6) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/transactional-test.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.transactional-test.war:main" from Service Module Loader")
> 13:53:42,854 ERROR [stderr] (default task-6) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 13:53:42,855 ERROR [stderr] (default task-6) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 13:53:42,855 ERROR [stderr] (default task-6) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
> 13:53:42,856 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
> 13:53:42,858 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
> 13:53:42,859 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
> 13:53:42,859 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
> 13:53:42,860 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
> 13:53:42,861 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
> 13:53:42,861 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
> 13:53:42,862 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
> 13:53:42,863 ERROR [stderr] (default task-6) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 13:53:42,863 ERROR [stderr] (default task-6) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 13:53:42,864 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 13:53:42,865 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 13:53:42,865 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 13:53:42,866 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 13:53:42,866 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:53:42,867 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 13:53:42,867 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 13:53:42,868 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:53:42,868 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 13:53:42,869 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 13:53:42,869 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 13:53:42,870 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 13:53:42,870 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 13:53:42,871 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 13:53:42,871 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:53:42,872 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 13:53:42,872 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:53:42,873 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:53:42,873 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 13:53:42,874 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 13:53:42,874 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 13:53:42,875 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 13:53:42,875 ERROR [stderr] (default task-6) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 13:53:42,875 ERROR [stderr] (default task-6) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 13:53:42,876 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 13:53:42,878 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:53:42,880 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:53:42,881 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:53:42,882 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:53:42,882 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 13:53:42,883 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 13:53:42,883 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> 13:53:42,884 ERROR [stderr] (default task-6) 	at java.security.AccessController.doPrivileged(Native Method)
> 13:53:42,885 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> 13:53:42,885 ERROR [stderr] (default task-6) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 13:53:42,886 ERROR [stderr] (default task-6) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 13:53:42,886 ERROR [stderr] (default task-6) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 13:53:42,887 ERROR [stderr] (default task-6) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 13:53:42,887 ERROR [stderr] (default task-6) 	at java.lang.Thread.run(Thread.java:745)
> {code}
> *org.jboss.as.test.xts.annotation.client.CompensatableTestCase#testActiveTransaction*
> *org.jboss.as.test.xts.annotation.client.CompensatableTestCase#testNoTransaction*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.xts -Dtest=CompensatableTestCase -Dsecurity.manager}}
> {code}
> 13:55:03,742 ERROR [stderr] (default task-6) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.reflect.ReflectPermission" "suppressAccessChecks")" in code source "(vfs:/content/compensatable-test.war/WEB-INF/lib/arquillian-core.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.compensatable-test.war:main" from Service Module Loader")
> 13:55:03,743 ERROR [stderr] (default task-6) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 13:55:03,744 ERROR [stderr] (default task-6) 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 13:55:03,745 ERROR [stderr] (default task-6) 	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
> 13:55:03,745 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.createInstance(ServiceLoader.java:220)
> 13:55:03,746 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.reload(ServiceLoader.java:181)
> 13:55:03,747 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.ServiceLoader.getProviders(ServiceLoader.java:286)
> 13:55:03,747 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:57)
> 13:55:03,748 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
> 13:55:03,749 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:169)
> 13:55:03,749 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:135)
> 13:55:03,750 ERROR [stderr] (default task-6) 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:98)
> 13:55:03,750 ERROR [stderr] (default task-6) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> 13:55:03,751 ERROR [stderr] (default task-6) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 13:55:03,752 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 13:55:03,752 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 13:55:03,753 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 13:55:03,753 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 13:55:03,757 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:55:03,758 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 13:55:03,758 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 13:55:03,759 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:55:03,759 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 13:55:03,760 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 13:55:03,760 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 13:55:03,761 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 13:55:03,762 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 13:55:03,762 ERROR [stderr] (default task-6) 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 13:55:03,763 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:55:03,763 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 13:55:03,764 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:55:03,765 ERROR [stderr] (default task-6) 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 13:55:03,766 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 13:55:03,766 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 13:55:03,767 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 13:55:03,769 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 13:55:03,774 ERROR [stderr] (default task-6) 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 13:55:03,775 ERROR [stderr] (default task-6) 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 13:55:03,776 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 13:55:03,776 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:55:03,777 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:55:03,777 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:55:03,778 ERROR [stderr] (default task-6) 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 13:55:03,779 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 13:55:03,779 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 13:55:03,780 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> 13:55:03,781 ERROR [stderr] (default task-6) 	at java.security.AccessController.doPrivileged(Native Method)
> 13:55:03,782 ERROR [stderr] (default task-6) 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> 13:55:03,783 ERROR [stderr] (default task-6) 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 13:55:03,783 ERROR [stderr] (default task-6) 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 13:55:03,784 ERROR [stderr] (default task-6) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 13:55:03,785 ERROR [stderr] (default task-6) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 13:55:03,786 ERROR [stderr] (default task-6) 	at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 11:45:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 21 Oct 2016 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7366) Remove PicketLink
In-Reply-To: <JIRA.12656167.1477064618000@Atlassian.JIRA>
References: <JIRA.12656167.1477064618000@Atlassian.JIRA>
	<JIRA.12656167.1477064618000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656167.1477064618000.32328.1477064701426@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved JBEAP-6571 to WFLY-7366:
------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-7366  (was: JBEAP-6571)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Security
                     (was: Security)


> Remove PicketLink
> -----------------
>
>                 Key: WFLY-7366
>                 URL: https://issues.jboss.org/browse/WFLY-7366
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> Subsystem should be removed in same way we did it with all legacy subsystems like web, messaging, cmp and others.
> This way it would still be possible to manage EAP6.4 hosts with EAP 7.1 domain controller that use picketlink.
> PicketLink subsystem was never supported in EAP, it was added in EAP 6.3 but as unsupported feature.
> in 6.4 it was also deprecated and marked for removal, as such it stayed also in 7.0.
> It was never officially supported in any of EAP releases and it would make sense to remove it in 7.1 as KeyCloak / RH SSO took over as main project/product for single sign on



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 11:46:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 21 Oct 2016 11:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7366) Remove PicketLink
In-Reply-To: <JIRA.12656167.1477064618000@Atlassian.JIRA>
References: <JIRA.12656167.1477064618000@Atlassian.JIRA>
	<JIRA.12656167.1477064618000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656167.1477064618000.32341.1477064760493@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7366:
------------------------------
    Forum Reference: http://wildfly-development.1055759.n5.nabble.com/Re-Remove-PL-from-WFLY-td5717415.html


> Remove PicketLink
> -----------------
>
>                 Key: WFLY-7366
>                 URL: https://issues.jboss.org/browse/WFLY-7366
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> Subsystem should be removed in same way we did it with all legacy subsystems like web, messaging, cmp and others.
> This way it would still be possible to manage EAP6.4 hosts with EAP 7.1 domain controller that use picketlink.
> PicketLink subsystem was never supported in EAP, it was added in EAP 6.3 but as unsupported feature.
> in 6.4 it was also deprecated and marked for removal, as such it stayed also in 7.0.
> It was never officially supported in any of EAP releases and it would make sense to remove it in 7.1 as KeyCloak / RH SSO took over as main project/product for single sign on



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 12:13:00 2016
From: issues at jboss.org (Jason Morgan (JIRA))
Date: Fri, 21 Oct 2016 12:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.32497.1477066380501@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310502#comment-13310502 ] 

Jason Morgan commented on WFLY-6500:
------------------------------------

I've just tested this with wildfly10.1.0, the issue still crashes but at least you get logs this time.  I do not use camuda and apparently this ticket was hijacked by people that do.  My issue comes from using wildfly only, with a war.  

Reproduce the steps to see the issue.

Here is a paste of the error in the logs that 10.1.0 shows (and 10.0.0 didn't), this is AFTER "replacing" the war through the webconsole and then rebooting the server.

11:09:26,144 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "landscape-1609.1.1.war")]) - failure description: "WFLYCTL0212: Duplicate resource [(\"deployment\" => \"landscape-1609.1.1.war\")]"
11:09:26,150 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.



> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Tomaz Cerar
>             Fix For: 10.1.0.Final
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 12:14:00 2016
From: issues at jboss.org (Jason Morgan (JIRA))
Date: Fri, 21 Oct 2016 12:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.32503.1477066440322@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310503#comment-13310503 ] 

Jason Morgan commented on WFLY-6500:
------------------------------------

To clarify, I'm replacing a war that was FIRST loaded through the deployment directory.  The steps to reproduce are listed

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Tomaz Cerar
>             Fix For: 10.1.0.Final
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 12:17:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 21 Oct 2016 12:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7367) add per PU cache of the new
 temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12656172.1477066573000@Atlassian.JIRA>
References: <JIRA.12656172.1477066573000@Atlassian.JIRA>
	<JIRA.12656172.1477066573194@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656172.1477066573000.32506.1477066620211@Atlassian.JIRA>

Scott Marlow created WFLY-7367:
----------------------------------

             Summary: add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
                 Key: WFLY-7367
                 URL: https://issues.jboss.org/browse/WFLY-7367
             Project: WildFly
          Issue Type: Enhancement
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow


Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 12:17:00 2016
From: issues at jboss.org (Jason Morgan (JIRA))
Date: Fri, 21 Oct 2016 12:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.32517.1477066620488@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310505#comment-13310505 ] 

Jason Morgan commented on WFLY-6500:
------------------------------------

Removing the war from the deployment directory after a crash does let the server start back up.  The problem is that wildfly thinks it has 2 versions of the same war loaded, one through deployment and one through the web console (which gets saved to a hashed directory).  Replacing the war through the webconsole reports success but really doesn't work on reboot.  Instead, this either shouldn't be an option for a war deployed through the deployment directory or it should actually remove the war in the deployment.

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Tomaz Cerar
>             Fix For: 10.1.0.Final
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 12:31:00 2016
From: issues at jboss.org (Michael Peoples (JIRA))
Date: Fri, 21 Oct 2016 12:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.32642.1477067460285@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310519#comment-13310519 ] 

Michael Peoples commented on WFLY-6500:
---------------------------------------

Jason,

My apologies for hijacking this issue.  I hope it does not interfere with you getting the answers you need.

Michael

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Tomaz Cerar
>             Fix For: 10.1.0.Final
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 12:36:00 2016
From: issues at jboss.org (Jason Morgan (JIRA))
Date: Fri, 21 Oct 2016 12:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.32657.1477067760245@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310523#comment-13310523 ] 

Jason Morgan commented on WFLY-6500:
------------------------------------

No apology needed.  I didn't mean to make that sound like I was upset in any way.  I just wanted [~ctomc] to know that the problem is with wildfly itself and not anything else.  

And no, I know what the problem is and I have disabled the deployment directory for my servers so that it doesn't happen on accident.  It is something that needs to be addressed so that someone else doesn't experience the problem

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Tomaz Cerar
>             Fix For: 10.1.0.Final
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 14:23:00 2016
From: issues at jboss.org (Jason Morgan (JIRA))
Date: Fri, 21 Oct 2016 14:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.32988.1477074180911@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Morgan reopened WFLY-6500:
--------------------------------


> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 10.0.0.Final
>            Reporter: Jason Morgan
>            Assignee: Tomaz Cerar
>             Fix For: 10.1.0.Final
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 14:38:00 2016
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 21 Oct 2016 14:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6417)
 ArrayIndexOutOfBoundsException in EJB client in 2-clusters EJB invocation
 graceful shutdown tests
In-Reply-To: <JIRA.12611537.1458657540000@Atlassian.JIRA>
References: <JIRA.12611537.1458657540000@Atlassian.JIRA>
	<JIRA.12611537.1458657540000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611537.1458657540000.33034.1477075080151@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310572#comment-13310572 ] 

Richard Achmatowicz commented on WFLY-6417:
-------------------------------------------

This test now passes for 7.0.0.GA: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering/view/EAP7-Clustering-LODH/job/eap-7x-clustering-lodh-windows/30/
I did not see any instances of "ArrayIndexOutOfBounds" in the logs nor "getResult() called during wrong phase"


> ArrayIndexOutOfBoundsException in EJB client in 2-clusters EJB invocation graceful shutdown tests
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6417
>                 URL: https://issues.jboss.org/browse/WFLY-6417
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>            Reporter: Ladislav Thon
>            Assignee: Richard Achmatowicz
>
> I have tests that start 2 clusters and a standalone EJB client and do remote EJB invocations like this: standalone EJB client -> cluster 1 (forwarder) -> cluster 2 (target) -> back to cluster 1 -> back to standalone client.
> During a graceful shutdown variant of such tests, where the nodes of the clusters are repeatedly shut down and then brough back up to life, one node at a time, I've seen an {{ArrayIndexOutOfBoundsException}} in EJB client on one of the forwarder nodes:
> {code}
> 2016-03-21 14:26:59,050 ERROR [org.jboss.as.ejb3.invocation] (default task-110) WFLYEJB0034: EJB Invocation failed on component ForwardingBeanImpl for method public abstract java.lang.String org.jboss.qa.eap.clustering.[redacted].testApps.june2013.Bean.test(java.lang.String,long): javax.ejb.EJBException: java.lang.ArrayIndexOutOfBoundsException: 5
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 	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)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 5
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy63.test(Unknown Source)
> 	at org.jboss.qa.eap.clustering.[redacted].testApps.june2013.ForwardingBeanImpl.test(ForwardingBeanImpl.java:30)
> 	at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 44 more
> {code}
> In the log, this exception is preceded by warnings about failed invocations and "No EJBReceiver available" which I don't understand -- at the time, all nodes should be up and running and seeing each other (which seems to be confirmed by the logs).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 15:01:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 21 Oct 2016 15:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7367) add per PU cache of the new
 temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12656172.1477066573000@Atlassian.JIRA>
References: <JIRA.12656172.1477066573000@Atlassian.JIRA>
	<JIRA.12656172.1477066573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656172.1477066573000.33079.1477076460092@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-7367:
-------------------------------
    Description: 
Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.

Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
{quote}
ClassLoader getNewTempClassLoader()

Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.

Returns:
    temporary ClassLoader with same visibility as current loader 
{quote}

  was:Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.



> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7367
>                 URL: https://issues.jboss.org/browse/WFLY-7367
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
>     temporary ClassLoader with same visibility as current loader 
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 15:06:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 21 Oct 2016 15:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7367) add per PU cache of the new
 temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12656172.1477066573000@Atlassian.JIRA>
References: <JIRA.12656172.1477066573000@Atlassian.JIRA>
	<JIRA.12656172.1477066573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656172.1477066573000.33090.1477076760500@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-7367:
-------------------------------
    Description: 
The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.

Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.

Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
{quote}
ClassLoader getNewTempClassLoader()

Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.

Returns:
    temporary ClassLoader with same visibility as current loader 
{quote}

  was:
Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.

Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
{quote}
ClassLoader getNewTempClassLoader()

Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.

Returns:
    temporary ClassLoader with same visibility as current loader 
{quote}



> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7367
>                 URL: https://issues.jboss.org/browse/WFLY-7367
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.
> Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
>     temporary ClassLoader with same visibility as current loader 
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 16:44:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 21 Oct 2016 16:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2121) ASYM_ENCRYPT error message
 "key server is currently not set" should be logged with debug level
In-Reply-To: <JIRA.12656068.1477041426000@Atlassian.JIRA>
References: <JIRA.12656068.1477041426000@Atlassian.JIRA>
	<JIRA.12656068.1477041426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656068.1477041426000.33297.1477082640179@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310604#comment-13310604 ] 

RH Bugzilla Integration commented on JGRP-2121:
-----------------------------------------------

Vlado Pakan <vpakan at redhat.com> changed the Status of [bug 1380657|https://bugzilla.redhat.com/show_bug.cgi?id=1380657] from POST to MODIFIED

> 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
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 17:00:01 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 21 Oct 2016 17:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1888) HTTP management response
 caching is broken
In-Reply-To: <JIRA.12656228.1477083568000@Atlassian.JIRA>
References: <JIRA.12656228.1477083568000@Atlassian.JIRA>
	<JIRA.12656228.1477083568127@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656228.1477083568000.33323.1477083601620@Atlassian.JIRA>

Brian Stansberry created WFCORE-1888:
----------------------------------------

             Summary: HTTP management response caching is broken
                 Key: WFCORE-1888
                 URL: https://issues.jboss.org/browse/WFCORE-1888
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


The HTTP handling for the management API supports caching of read-resource-description and read-operation-description responses. But the ETag calculation used in support of this is broken. It was written to calculate an MD5 hash of the toString() representation of a DMR response but the object being hashed got changed to an OperationResponse. The toString() representation of that is unique for each request.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 19:06:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 21 Oct 2016 19:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.33421.1477091161270@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310617#comment-13310617 ] 

Jan Kalina commented on WFLY-7334:
----------------------------------

About *java.security.krb5.conf* property: setting *refreshKrb5Config* option to "true" is currently required to do Config loading.

> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Oct 21 19:06:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 21 Oct 2016 19:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.33427.1477091161445@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310617#comment-13310617 ] 

Jan Kalina edited comment on WFLY-7334 at 10/21/16 7:05 PM:
------------------------------------------------------------

Note: About *java.security.krb5.conf* property: setting *refreshKrb5Config* option to "true" is currently required to do Config loading.


was (Author: honza889):
About *java.security.krb5.conf* property: setting *refreshKrb5Config* option to "true" is currently required to do Config loading.

> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sat Oct 22 21:01:03 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sat, 22 Oct 2016 21:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7368) Relative ordering of
 webfragments causes an IllegalStateException
In-Reply-To: <JIRA.12656242.1477184405000@Atlassian.JIRA>
References: <JIRA.12656242.1477184405000@Atlassian.JIRA>
	<JIRA.12656242.1477184405539@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656242.1477184405000.33616.1477184463943@Atlassian.JIRA>

Stuart Douglas created WFLY-7368:
------------------------------------

             Summary: Relative ordering of webfragments causes an IllegalStateException
                 Key: WFLY-7368
                 URL: https://issues.jboss.org/browse/WFLY-7368
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 9.0.2.Final, 11.0.0.Alpha1
         Environment: Issue found on 9.0.2; testcase made against master (11.0.0.Alpha1-SNAPSHOT)
            Reporter: Sverre Boschman
            Assignee: Stuart Douglas
            Priority: Minor


Caused by: java.lang.IllegalStateException: WFLYUT0047: Relative ordering conflict with JAR: <jarname>.jar
       at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.resolveOrder(WarMetaDataProcessor.java:717)
       at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:212)
       ... 6 more



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 23 06:14:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 23 Oct 2016 06:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2112) Sticky site masters
In-Reply-To: <JIRA.12655119.1476607610000@Atlassian.JIRA>
References: <JIRA.12655119.1476607610000@Atlassian.JIRA>
	<JIRA.12655119.1476607610000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655119.1476607610000.33821.1477217640225@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310648#comment-13310648 ] 

Bela Ban commented on JGRP-2112:
--------------------------------

Provide a unit test which sets up 2 sites with 4 members each and send fom one member in site A to members in site B. The payload is a seqno: verify that all seqnos are received in monotonically increasing order.

> Sticky site masters
> -------------------
>
>                 Key: JGRP-2112
>                 URL: https://issues.jboss.org/browse/JGRP-2112
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.12, 4.0
>
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
> h4. Design
> * When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller
> * Note that this only applies when we have more than one site master.
> * The callback passes the address of the original caller and the list of available site masters, and needs to return a site master
> h5. Transactions
> * Transactions by different originators with overlapping key sets cannot be reliably ordered
> * Transactional support therefore requires single site masters
> * This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Sun Oct 23 07:27:00 2016
From: issues at jboss.org (Bogdan Mart (JIRA))
Date: Sun, 23 Oct 2016 07:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-96) Static & default interface
 methods in Logger interface require annotation
In-Reply-To: <JIRA.12599653.1452862505000@Atlassian.JIRA>
References: <JIRA.12599653.1452862505000@Atlassian.JIRA>
	<JIRA.12599653.1452862505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599653.1452862505000.33965.1477222020401@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310650#comment-13310650 ] 

Bogdan Mart commented on LOGTOOL-96:
------------------------------------

Hello, so this is ging into release 2.1.0?
I really like this issue to be fixed, any estimations, when 2.1.0 would be released?

> Static & default interface methods in Logger interface require annotation
> -------------------------------------------------------------------------
>
>                 Key: LOGTOOL-96
>                 URL: https://issues.jboss.org/browse/LOGTOOL-96
>             Project: Log Tool
>          Issue Type: Bug
>            Reporter: Radim Vansa
>            Assignee: James Perkins
>             Fix For: 2.1.0.Alpha1
>
>
> When I want to add a static helper method to the interface used for message logger, I get an error about requiring the @Message annotation. I think that this should not be required for static methods.
> My usecase:
> {code}
> @MessageLogger(projectCode = "FOO")
> public interface FooMessageLogger extends BasicLogger {
>    static FooMessageLogger getLog(Class clazz) {
>       return Logger.getMessageLogger(FooMessageLogger.class, clazz.getName());
>    }
>    /* regular annotated logging methods */
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 01:07:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 24 Oct 2016 01:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.34212.1477285620243@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310679#comment-13310679 ] 

Martin Choma commented on WFLY-7334:
------------------------------------

Setting {{refreshKrb5Config}} will be possible once WFLY-7340 will be resolved, right?

> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 02:12:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 24 Oct 2016 02:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7369) Elytron Properties realm
 parses password with "=" incorrectly
In-Reply-To: <JIRA.12656257.1477289469000@Atlassian.JIRA>
References: <JIRA.12656257.1477289469000@Atlassian.JIRA>
	<JIRA.12656257.1477289469075@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656257.1477289469000.34284.1477289520171@Atlassian.JIRA>

Ondrej Lukas created WFLY-7369:
----------------------------------

             Summary: Elytron Properties realm parses password with "=" incorrectly
                 Key: WFLY-7369
                 URL: https://issues.jboss.org/browse/WFLY-7369
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


In case when Elytron properties-realm uses plain-text properties file and password includes {{=}} sign then username/password is parsing incorrectly. In case when properties file contains line as {{A=B=C}} then Elytron parses it as user {{A=B}} with password {{C}}. Correct behavior should be user {{A}} with password {{B=C}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 02:29:00 2016
From: issues at jboss.org (=?UTF-8?Q?St=C3=A9phane_Jacquemain_=28JIRA=29?=)
Date: Mon, 24 Oct 2016 02:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7370) web proxy scanners causing
	undertow errors
In-Reply-To: <JIRA.12656258.1477290502000@Atlassian.JIRA>
References: <JIRA.12656258.1477290502000@Atlassian.JIRA>
	<JIRA.12656258.1477290502414@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656258.1477290502000.34354.1477290540183@Atlassian.JIRA>

St?phane Jacquemain created WFLY-7370:
-----------------------------------------

             Summary: web proxy scanners causing undertow errors
                 Key: WFLY-7370
                 URL: https://issues.jboss.org/browse/WFLY-7370
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 10.1.0.Final
            Reporter: St?phane Jacquemain
            Assignee: Stuart Douglas


I think it's same issue has UNDERTOW-592, but i cannot re-open it and nobody responds to my comment.
450+ crash in one day...

My Undertown modules = undertow-core-1.3.15.Final, undertow-servlet-1.3.15.Final, undertow-websockets-jsr-1.3.15.Final

Exemples:

2016-10-22 09:23:00,764 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phppma/


        at java.net.URI.checkPath(URI.java:1823)
        at java.net.URI.<init>(URI.java:672)
        at io.undertow.security.handlers.SinglePortConfidentialityHandler.getRedirectURI(SinglePortConfidentialityHandler.java:51)
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:83)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49)
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
        at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
        at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
        at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
        at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
        at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
        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)

2016-10-22 09:23:00,593 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phpmy/
...

2016-10-22 09:23:00,423 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/2phpmyadmin/
...

2016-10-22 09:23:00,423 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/2phpmyadmin/
...

2016-10-22 09:23:00,253 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phpmyadmin4/
...

2016-10-22 09:23:00,083 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phpmyadmin3/
...

2016-10-22 09:22:59,573 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phpMyAdmin/
...

2016-10-22 09:22:59,062 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/mysql/mysqlmanager/
...





--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 24 03:00:01 2016
From: issues at jboss.org (=?UTF-8?Q?St=C3=A9phane_Jacquemain_=28JIRA=29?=)
Date: Mon, 24 Oct 2016 03:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7370) web proxy scanners causing
	undertow errors
In-Reply-To: <JIRA.12656258.1477290502000@Atlassian.JIRA>
References: <JIRA.12656258.1477290502000@Atlassian.JIRA>
	<JIRA.12656258.1477290502000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656258.1477290502000.34461.1477292401494@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

St?phane Jacquemain updated WFLY-7370:
--------------------------------------
    Description: 
I think it's same issue has UNDERTOW-592, but i cannot re-open it and nobody responds to my comment.
450+ crash in one day...

My Undertown modules = undertow-core-1.3.15.Final, undertow-servlet-1.3.15.Final, undertow-websockets-jsr-1.3.15.Final

Exemples:

2016-10-22 09:23:00,764 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phppma/


        at java.net.URI.checkPath(URI.java:1823)
        at java.net.URI.<init>(URI.java:672)
        at io.undertow.security.handlers.SinglePortConfidentialityHandler.getRedirectURI(SinglePortConfidentialityHandler.java:51)
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:83)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49)
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
        at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
        at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
        at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
        at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
        at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
        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)

2016-10-22 09:23:00,593 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phpmy/
...

2016-10-22 09:23:00,423 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/2phpmyadmin/
...

2016-10-22 09:23:00,423 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/2phpmyadmin/
...

2016-10-22 09:23:00,253 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phpmyadmin4/
...

2016-10-22 09:23:00,083 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phpmyadmin3/
...

2016-10-22 09:22:59,573 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phpMyAdmin/
...

2016-10-22 09:22:59,062 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/mysql/mysqlmanager/
...



  was:
I think it's same issue has UNDERTOW-592, but i cannot re-open it and nobody responds to my comment.
450+ crash in one day...

My Undertown modules = undertow-core-1.3.15.Final, undertow-servlet-1.3.15.Final, undertow-websockets-jsr-1.3.15.Final

Exemples:

2016-10-22 09:23:00,764 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phppma/


        at java.net.URI.checkPath(URI.java:1823)
        at java.net.URI.<init>(URI.java:672)
        at io.undertow.security.handlers.SinglePortConfidentialityHandler.getRedirectURI(SinglePortConfidentialityHandler.java:51)
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:83)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49)
        at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
        at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
        at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
        at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
        at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
        at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
        at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
        at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
        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)

2016-10-22 09:23:00,593 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phpmy/
...

2016-10-22 09:23:00,423 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/2phpmyadmin/
...

2016-10-22 09:23:00,423 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/2phpmyadmin/
...

2016-10-22 09:23:00,253 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phpmyadmin4/
...

2016-10-22 09:23:00,083 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phpmyadmin3/
...

2016-10-22 09:22:59,573 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/phpMyAdmin/
...

2016-10-22 09:22:59,062 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://137.74.169.156:443http://137.74.169.156:80/mysql/mysqlmanager/
...





> web proxy scanners causing undertow errors
> ------------------------------------------
>
>                 Key: WFLY-7370
>                 URL: https://issues.jboss.org/browse/WFLY-7370
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: St?phane Jacquemain
>            Assignee: Stuart Douglas
>
> I think it's same issue has UNDERTOW-592, but i cannot re-open it and nobody responds to my comment.
> 450+ crash in one day...
> My Undertown modules = undertow-core-1.3.15.Final, undertow-servlet-1.3.15.Final, undertow-websockets-jsr-1.3.15.Final
> Exemples:
> 2016-10-22 09:23:00,764 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phppma/
>         at java.net.URI.checkPath(URI.java:1823)
>         at java.net.URI.<init>(URI.java:672)
>         at io.undertow.security.handlers.SinglePortConfidentialityHandler.getRedirectURI(SinglePortConfidentialityHandler.java:51)
>         at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:83)
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49)
>         at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>         at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>         at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>         at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>         at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
>         at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
>         at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
>         at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
>         at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
>         at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
>         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)
> 2016-10-22 09:23:00,593 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phpmy/
> ...
> 2016-10-22 09:23:00,423 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/2phpmyadmin/
> ...
> 2016-10-22 09:23:00,423 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/2phpmyadmin/
> ...
> 2016-10-22 09:23:00,253 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phpmyadmin4/
> ...
> 2016-10-22 09:23:00,083 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phpmyadmin3/
> ...
> 2016-10-22 09:22:59,573 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/phpMyAdmin/
> ...
> 2016-10-22 09:22:59,062 ERROR [io.undertow.request] UT005001: An exception occurred processing the request: java.net.URISyntaxException: Relative path in absolute URI: https://X.X.X.X:443http://X.X.X.X:80/mysql/mysqlmanager/
> ...



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 24 03:48:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 24 Oct 2016 03:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.34574.1477295280516@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310716#comment-13310716 ] 

Jan Kalina commented on WFLY-7334:
----------------------------------

Yes.

> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 06:00:01 2016
From: issues at jboss.org (Ales Justin (JIRA))
Date: Mon, 24 Oct 2016 06:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7345) Fix big jboss-beans.xml files
	truncation
In-Reply-To: <JIRA.12655589.1476838453000@Atlassian.JIRA>
References: <JIRA.12655589.1476838453000@Atlassian.JIRA>
	<JIRA.12655589.1476838453000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655589.1476838453000.35165.1477303201075@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310776#comment-13310776 ] 

Ales Justin commented on WFLY-7345:
-----------------------------------

[~penczek] can you please attach such "big enough" -beans.xml file, so I can also add a test for this. Tnx.


> Fix big jboss-beans.xml files truncation
> ----------------------------------------
>
>                 Key: WFLY-7345
>                 URL: https://issues.jboss.org/browse/WFLY-7345
>             Project: WildFly
>          Issue Type: Bug
>          Components: POJO
>    Affects Versions: 10.1.0.Final
>            Reporter: Leonardo Penczek
>            Assignee: Ales Justin
>
> If the jboss-beans.xml file is big enough, the value of a property.may be truncated,
> Fix for this problem:
> In the org.jboss.as.pojo.KernelDeploymentParsingProcessor constructor, add this line of code:
> inputFactory.setProperty("javax.xml.stream.isCoalescing", Boolean.valueOf(true));
> It prevents the truncation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 06:05:01 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 24 Oct 2016 06:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1889) Upgrade xnio from 3.4.0 to
	3.4.1
In-Reply-To: <JIRA.12656302.1477303469000@Atlassian.JIRA>
References: <JIRA.12656302.1477303469000@Atlassian.JIRA>
	<JIRA.12656302.1477303469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656302.1477303469000.35195.1477303501630@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan moved JBEAP-6583 to WFCORE-1889:
-------------------------------------------

        Project: WildFly Core  (was: JBoss Enterprise Application Platform)
            Key: WFCORE-1889  (was: JBEAP-6583)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Remoting
                     (was: Remoting)
                     (was: Web (Undertow))


> Upgrade xnio from 3.4.0 to 3.4.1
> --------------------------------
>
>                 Key: WFCORE-1889
>                 URL: https://issues.jboss.org/browse/WFCORE-1889
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Remoting
>            Reporter: Brad Maxwell
>            Assignee: Petr Saka?
>            Priority: Blocker
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 24 06:06:00 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 24 Oct 2016 06:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1889) Upgrade xnio from 3.4.0 to
	3.4.1
In-Reply-To: <JIRA.12656302.1477303469000@Atlassian.JIRA>
References: <JIRA.12656302.1477303469000@Atlassian.JIRA>
	<JIRA.12656302.1477303469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656302.1477303469000.35208.1477303560815@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1889:
-------------------------------
    Fix Version/s: 3.0.0.Alpha11


> Upgrade xnio from 3.4.0 to 3.4.1
> --------------------------------
>
>                 Key: WFCORE-1889
>                 URL: https://issues.jboss.org/browse/WFCORE-1889
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Remoting
>            Reporter: Brad Maxwell
>            Assignee: Petr Saka?
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha11
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 24 06:06:00 2016
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 24 Oct 2016 06:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7369) Elytron Properties realm
 parses password with "=" incorrectly
In-Reply-To: <JIRA.12656257.1477289469000@Atlassian.JIRA>
References: <JIRA.12656257.1477289469000@Atlassian.JIRA>
	<JIRA.12656257.1477289469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656257.1477289469000.35202.1477303560650@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitrii Tikhomirov reassigned WFLY-7369:
----------------------------------------

    Assignee: Dmitrii Tikhomirov  (was: Darran Lofthouse)


> Elytron Properties realm parses password with "=" incorrectly
> -------------------------------------------------------------
>
>                 Key: WFLY-7369
>                 URL: https://issues.jboss.org/browse/WFLY-7369
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Dmitrii Tikhomirov
>
> In case when Elytron properties-realm uses plain-text properties file and password includes {{=}} sign then username/password is parsing incorrectly. In case when properties file contains line as {{A=B=C}} then Elytron parses it as user {{A=B}} with password {{C}}. Correct behavior should be user {{A}} with password {{B=C}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 06:07:00 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 24 Oct 2016 06:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1889) Upgrade xnio from 3.4.0 to
	3.4.1
In-Reply-To: <JIRA.12656302.1477303469000@Atlassian.JIRA>
References: <JIRA.12656302.1477303469000@Atlassian.JIRA>
	<JIRA.12656302.1477303469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656302.1477303469000.35220.1477303620386@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFCORE-1889:
----------------------------------

    Assignee: David Lloyd  (was: Petr Saka?)


> Upgrade xnio from 3.4.0 to 3.4.1
> --------------------------------
>
>                 Key: WFCORE-1889
>                 URL: https://issues.jboss.org/browse/WFCORE-1889
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Remoting
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha11
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 24 06:17:00 2016
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Mon, 24 Oct 2016 06:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1326) Stateful working memory
 regression OCT-2016: nurserostering long_hint01.xml
In-Reply-To: <JIRA.12654578.1476342273000@Atlassian.JIRA>
References: <JIRA.12654578.1476342273000@Atlassian.JIRA>
	<JIRA.12654578.1476342273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654578.1476342273000.35292.1477304220972@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310784#comment-13310784 ] 

Jiri Locker commented on DROOLS-1326:
-------------------------------------

https://github.com/yurloc/drools-reproducer/tree/drools-1326-1

The repository contains a test reproducing the score calculation issue uncovered by OptaPlanner's Nurse Rostering Example. I believe the reproducer could be simplified before it's ready to be added to Drools test suite. Additionally, it still depends on optaplanner-core because it uses ScoreHolder in one of the rules RHS. The score holder helped me make sure the original problem is reproducible but can be removed.

[~mfusco] I included comments explaining the problem but feel free to contact me for more details.

> Stateful working memory regression OCT-2016: nurserostering long_hint01.xml
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-1326
>                 URL: https://issues.jboss.org/browse/DROOLS-1326
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Something regressed in Drools master between 27-SEP and 11-OCT.
> See:
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/optaplanner-turtleTests/org.optaplanner$optaplanner-examples/73/testReport/junit/org.optaplanner.examples.nurserostering.app/NurseRosteringSolveAllTurtleTest/runFastAndFullAssert_2__data_nurserostering_unsolved_long_hint01_xml_/
> I 'll ask [~jlocker] to isolate.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 08:05:00 2016
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 24 Oct 2016 08:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7288) Elytron - inconsistency
 between DMR and XSD representation of ldap-realm
In-Reply-To: <JIRA.12654214.1476188470000@Atlassian.JIRA>
References: <JIRA.12654214.1476188470000@Atlassian.JIRA>
	<JIRA.12654214.1476188470000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654214.1476188470000.35826.1477310700507@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7288:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Elytron - inconsistency between DMR and XSD representation of ldap-realm
> ------------------------------------------------------------------------
>
>                 Key: WFLY-7288
>                 URL: https://issues.jboss.org/browse/WFLY-7288
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>            Priority: Optional
>
> There are inconsistencies between DMR and XSD representation of ldap-realm.
> * According to XSD [1] {{from}} attribute from user-password-mapper is required in ldap-realm. According to DMR {{from}} attribute is {{"nillable" => true}}.
> * According to XSD [2] every attribute ({{algorithm-from}}, {{hash-from}}, {{seed-from}}, {{sequence-from}}) from otp-credential-mapper is required in ldap-realm. According to DMR all these attributes are {{"nillable" => true}}.
> * According to XSD [3] {{name}} of {{attribute}} from new-identity-attributes is required in ldap-realm. According to DMR {{name}} of {{attribute}} is {{"nillable" => true}}.
> These inconsistencies should be unified.
> [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1008
> [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1031
> [3] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c87db71d84b79475ddab5193f904/src/main/resources/schema/wildfly-elytron_1_0.xsd#L1079



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 08:05:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 24 Oct 2016 08:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-680) No log messages comming from
 Elytron - kerberos
In-Reply-To: <JIRA.12655611.1476860981000@Atlassian.JIRA>
References: <JIRA.12655611.1476860981000@Atlassian.JIRA>
	<JIRA.12655611.1476860981000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655611.1476860981000.35837.1477310700828@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7347 to ELY-680:
--------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-680  (was: WFLY-7347)
          Component/s: Authentication Mechanisms
                           (was: Security)
    Affects Version/s:     (was: 11.0.0.Alpha1)


> No log messages comming from Elytron - kerberos
> -----------------------------------------------
>
>                 Key: ELY-680
>                 URL: https://issues.jboss.org/browse/ELY-680
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Mechanisms
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Elytron is missing log messages related to kerberos authentication. These log messages should be added. See JBEAP-6041 for more details.
> I consider to be useful to have TRACE log messages at least in:
> - SpnegoAuthenticationMechanism
> - GSSCredentialSecurityFactory
> If there are more classes involved in kerberos authnetication include them as well.
> Kerberos issues are very specific. So it is very important to have as much trace information as possible. Therefore raising priority to Critical.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 08:12:00 2016
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Mon, 24 Oct 2016 08:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-960) Release JBoss Negotiation
	2.3.12.Final
In-Reply-To: <JIRA.12656321.1477311108000@Atlassian.JIRA>
References: <JIRA.12656321.1477311108000@Atlassian.JIRA>
	<JIRA.12656321.1477311108307@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656321.1477311108000.35885.1477311120300@Atlassian.JIRA>

Peter Skopek created SECURITY-960:
-------------------------------------

             Summary: Release JBoss Negotiation 2.3.12.Final
                 Key: SECURITY-960
                 URL: https://issues.jboss.org/browse/SECURITY-960
             Project: PicketBox 
          Issue Type: Release
          Components: Negotiation
            Reporter: Peter Skopek
            Assignee: Peter Skopek






--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 08:26:00 2016
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Mon, 24 Oct 2016 08:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-960) Release JBoss Negotiation
	2.3.12.Final
In-Reply-To: <JIRA.12656321.1477311108000@Atlassian.JIRA>
References: <JIRA.12656321.1477311108000@Atlassian.JIRA>
	<JIRA.12656321.1477311108000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656321.1477311108000.35939.1477311960594@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek resolved SECURITY-960.
-----------------------------------
    Resolution: Done


[~dlofthouse] tag created, but I didn't release jars yet.

> Release JBoss Negotiation 2.3.12.Final
> --------------------------------------
>
>                 Key: SECURITY-960
>                 URL: https://issues.jboss.org/browse/SECURITY-960
>             Project: PicketBox 
>          Issue Type: Release
>          Components: Negotiation
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 09:29:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Mon, 24 Oct 2016 09:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.36314.1477315740225@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310875#comment-13310875 ] 

Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------

Jean-Francois, Could you please clarify what is wrong in the fix?

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 09:35:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 24 Oct 2016 09:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.36507.1477316100388@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310879#comment-13310879 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

Hi Hisanobu,
I wanted to understand why we had no issue with the latest upstream project. If Stale (he is the owner of Aesh) accept your fix, I have no problem with it.
JF


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 10:21:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Mon, 24 Oct 2016 10:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5879) Some multinode tests fail
 with security manager
In-Reply-To: <JIRA.12597217.1450441124000@Atlassian.JIRA>
References: <JIRA.12597217.1450441124000@Atlassian.JIRA>
	<JIRA.12597217.1450441124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597217.1450441124000.37066.1477318860560@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310907#comment-13310907 ] 

Ingo Weiss commented on WFLY-5879:
----------------------------------

I see what you mean now, having fixed another test, but it is my understanding, on this case, that since we are starting the H2 server inside the test then the test itself needs the permissions manually? I say that because I wouldn't expect a customer application to start an H2 server instance instead using a proper datasource.

Either that or I'm getting my wires crossed.

> Some multinode tests fail with security manager
> -----------------------------------------------
>
>                 Key: WFLY-5879
>                 URL: https://issues.jboss.org/browse/WFLY-5879
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Test Suite
>            Reporter: Ondrej Kotek
>            Assignee: Ingo Weiss
>             Fix For: 10.2.0.Final
>
>
> *org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase}}
> fails with:
> {noformat}
> javax.naming.NamingException: Failed to create proxy
> 	at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:873)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:222)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:230)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.getStatefulRemote(ClientEjb.java:60)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.testSameTransactionEachCall(ClientEjb.java:77)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb$$$view1.testSameTransactionEachCall(Unknown Source)
> 	at org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSameTransactionEachCall(TransactionInvocationTestCase.java:97)
> {noformat}
> *org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase}}
> fails with:
> {noformat}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-2) Failed: org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances: javax.naming.NameNotFoundException: StatefulBeanA!org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.doLookup(InitialContext.java:290)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances(DynamicJNDIContextEJBInvocationTestCase.java:116)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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)
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
> 	... 145 more
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.distributable.DistributableCache.create(DistributableCache.java:94)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$DefaultViewInstanceFactory.createViewInstance(ViewService.java:302)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> 	... 148 more
> Caused by: javax.naming.NamingException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null") [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null")]
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:137)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA.onConstruct(StatefulBeanA.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:117)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBCreateInterceptor.processInvocation(SFSBCreateInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 164 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at org.jboss.ejb.client.EJBClientContext.create(EJBClientContext.java:198)
> 	at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:90)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:256)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
> 	at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:133)
> 	... 223 more
> {noformat}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> fails with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy62.remoteCall(Unknown Source)
> 	at org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote(RemoteLocalCallProfileTestCase.java:185)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
> 	at java.lang.Class.getClassLoader(Class.java:683)
> 	at org.jboss.marshalling.reflect.SerializableClassRegistry.lookup(SerializableClassRegistry.java:70)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:916)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1255)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> 	at org.jboss.ejb.client.remoting.SessionOpenResponseHandler$SessionIDResultProducer.getResult(SessionOpenResponseHandler.java:94)
> 	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:454)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:227)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:204)
> 	... 226 more
> {code}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> Fail with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:568)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy65.remoteCall(Unknown Source)
> 	at 
> {code}
> *org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode}}
> Fails with:
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.security.AccessControlException: WFSM000001: Permission check failed (permission ""(""java.net.SocketPermission"" ""10.16.91.218:9092"" ""connect,resolve"")"" in code source ""(vfs:/content/testTimerServiceSimple.war/WEB-INF/classes <no signer certificates>)"" of ""null"")" [50000-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:160)
> 	at org.h2.message.DbException.convert(DbException.java:283)
> 	at org.h2.message.DbException.toSQLException(DbException.java:256)
> 	at org.h2.message.TraceObject.logAndConvert(TraceObject.java:368)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:119)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:90)
> 	at org.h2.Driver.connect(Driver.java:73)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:319)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:350)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:285)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1319)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:708)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:607)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> 	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> 	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:614)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:482)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:308)
> 	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.java:57)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 10:33:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 24 Oct 2016 10:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7290) Unable to remove elytron
	ldap-key-store
In-Reply-To: <JIRA.12654226.1476190726000@Atlassian.JIRA>
References: <JIRA.12654226.1476190726000@Atlassian.JIRA>
	<JIRA.12654226.1476190726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654226.1476190726000.37098.1477319580386@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed WFLY-7290.
----------------------------
    Resolution: Duplicate Issue


> Unable to remove elytron ldap-key-store
> ---------------------------------------
>
>                 Key: WFLY-7290
>                 URL: https://issues.jboss.org/browse/WFLY-7290
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Once ldap-key-store is added it can't be removed.
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=b:add(url=ldap://localhost, principal="CN=user,DC=wildfly,DC=org", credential=password)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:add(dir-context=b,search-path="DC=wildfly,DC=org")
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=b:remove()
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext",
>     "rolled-back" => true
> }
> {code}
> which leads to error in server log
> {code}
> 14:55:41,841 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 12) WFLYCTL0013: Operation ("remove") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("ldap-key-store" => "b")
> ]): java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.AbstractRemoveStepHandler.execute(AbstractRemoveStepHandler.java:66)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]]
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 31 more
> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules,/home/mchoma/workspace/eap-versions/7.1.0.DR6/jboss-eap-7.1/modules/system/layers/base))]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:348)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 10:34:00 2016
From: issues at jboss.org (Emmanuel Bernard (JIRA))
Date: Mon, 24 Oct 2016 10:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.2
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.37112.1477319640512@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310912#comment-13310912 ] 

Emmanuel Bernard commented on WFLY-6854:
----------------------------------------

We're talking about classes being enhanced at runtime here at each deployment. So there is no backward compatible concern.

> Upgrade Hibernate ORM to 5.1.2
> ------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 10:39:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 24 Oct 2016 10:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7295) Wrong HTTP error code for
 Elytron authentication when LDAP server is unreachable
In-Reply-To: <JIRA.12654402.1476273683000@Atlassian.JIRA>
References: <JIRA.12654402.1476273683000@Atlassian.JIRA>
	<JIRA.12654402.1476273683000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654402.1476273683000.37137.1477319940696@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7295:
-----------------------------
    Summary: Wrong HTTP error code for Elytron authentication when LDAP server is unreachable  (was: Internal server error is returned for Elytron authentication when LDAP server is unreachable)


> Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-7295
>                 URL: https://issues.jboss.org/browse/WFLY-7295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> 	... 45 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:589)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> 	... 67 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 10:51:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Mon, 24 Oct 2016 10:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6936) RebindTestCase fails with
	security manager
In-Reply-To: <JIRA.12642677.1470808871000@Atlassian.JIRA>
References: <JIRA.12642677.1470808871000@Atlassian.JIRA>
	<JIRA.12642677.1470808871000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642677.1470808871000.37223.1477320660092@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310922#comment-13310922 ] 

Ingo Weiss commented on WFLY-6936:
----------------------------------

After discussing some of these fixes with [~kabirkhan] and reassessing this issue, I believe this will depend on the security manager to be integrated into WildFly Core. I will leave this on reopened until it happens.

> RebindTestCase fails with security manager
> ------------------------------------------
>
>                 Key: WFLY-6936
>                 URL: https://issues.jboss.org/browse/WFLY-6936
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ingo Weiss
>             Fix For: 11.0.0.Alpha1
>
>
> *org.jboss.as.test.integration.naming.RebindTestCase#testRebinding*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.naming.RebindTestCase#testRebinding -Dsecurity.manager}}
> Fails with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/RebindTestCase.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:85)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:120)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:64)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:139)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:114)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> 	... 145 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 10:53:00 2016
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Mon, 24 Oct 2016 10:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6936) RebindTestCase fails with
	security manager
In-Reply-To: <JIRA.12642677.1470808871000@Atlassian.JIRA>
References: <JIRA.12642677.1470808871000@Atlassian.JIRA>
	<JIRA.12642677.1470808871000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642677.1470808871000.37227.1477320780276@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reopened WFLY-6936:
------------------------------


> RebindTestCase fails with security manager
> ------------------------------------------
>
>                 Key: WFLY-6936
>                 URL: https://issues.jboss.org/browse/WFLY-6936
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ingo Weiss
>             Fix For: 11.0.0.Alpha1
>
>
> *org.jboss.as.test.integration.naming.RebindTestCase#testRebinding*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.naming.RebindTestCase#testRebinding -Dsecurity.manager}}
> Fails with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/RebindTestCase.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:85)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:120)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:64)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:139)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:114)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> 	... 145 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 10:55:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 24 Oct 2016 10:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.37245.1477320900716@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-6500:
---------------------------------

    Assignee: ehsavoie Hugonnet  (was: Tomaz Cerar)


> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFLY-6500
>                 URL: https://issues.jboss.org/browse/WFLY-6500
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 2.2.0.Final
>            Reporter: Jason Morgan
>            Assignee: ehsavoie Hugonnet
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 10:55:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 24 Oct 2016 10:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1890) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.37258.1477320901182@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved WFLY-6500 to WFCORE-1890:
-------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-1890  (was: WFLY-6500)
    Affects Version/s: 2.2.0.Final
                           (was: 10.0.0.Final)
        Fix Version/s:     (was: 10.1.0.Final)


> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFCORE-1890
>                 URL: https://issues.jboss.org/browse/WFCORE-1890
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 2.2.0.Final
>            Reporter: Jason Morgan
>            Assignee: ehsavoie Hugonnet
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 10:55:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 24 Oct 2016 10:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1890) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.37268.1477320901466@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-1890:
--------------------------------
    Component/s: Deployment Scanner


> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFCORE-1890
>                 URL: https://issues.jboss.org/browse/WFCORE-1890
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Deployment Scanner
>    Affects Versions: 2.2.0.Final
>            Reporter: Jason Morgan
>            Assignee: ehsavoie Hugonnet
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 11:10:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 24 Oct 2016 11:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-636) No log messages comming from
 Elytron - principal mapping
In-Reply-To: <JIRA.12651441.1474536133000@Atlassian.JIRA>
References: <JIRA.12651441.1474536133000@Atlassian.JIRA>
	<JIRA.12651441.1474536133000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651441.1474536133000.37439.1477321800888@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-636:
------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> No log messages comming from Elytron - principal mapping
> --------------------------------------------------------
>
>                 Key: ELY-636
>                 URL: https://issues.jboss.org/browse/ELY-636
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta9
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> Elytron is missing any log messages related to principal mapping. These log messages should be added. See JBEAP-6041 for more details.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 11:15:01 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 24 Oct 2016 11:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-96) Static & default interface
 methods in Logger interface require annotation
In-Reply-To: <JIRA.12599653.1452862505000@Atlassian.JIRA>
References: <JIRA.12599653.1452862505000@Atlassian.JIRA>
	<JIRA.12599653.1452862505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599653.1452862505000.37471.1477322101433@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310945#comment-13310945 ] 

James Perkins commented on LOGTOOL-96:
--------------------------------------

I'll make sure to do a release soon. Hopefully I can get to it this week as it has been a while.

> Static & default interface methods in Logger interface require annotation
> -------------------------------------------------------------------------
>
>                 Key: LOGTOOL-96
>                 URL: https://issues.jboss.org/browse/LOGTOOL-96
>             Project: Log Tool
>          Issue Type: Bug
>            Reporter: Radim Vansa
>            Assignee: James Perkins
>             Fix For: 2.1.0.Alpha1
>
>
> When I want to add a static helper method to the interface used for message logger, I get an error about requiring the @Message annotation. I think that this should not be required for static methods.
> My usecase:
> {code}
> @MessageLogger(projectCode = "FOO")
> public interface FooMessageLogger extends BasicLogger {
>    static FooMessageLogger getLog(Class clazz) {
>       return Logger.getMessageLogger(FooMessageLogger.class, clazz.getName());
>    }
>    /* regular annotated logging methods */
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 11:41:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 24 Oct 2016 11:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-927) Option roleRecursion does
 not work in LdapRolesMappingProvider
In-Reply-To: <JIRA.12588128.1444298035000@Atlassian.JIRA>
References: <JIRA.12588128.1444298035000@Atlassian.JIRA>
	<JIRA.12588128.1444298035000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588128.1444298035000.37724.1477323660244@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310972#comment-13310972 ] 

RH Bugzilla Integration commented on SECURITY-927:
--------------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1269826|https://bugzilla.redhat.com/show_bug.cgi?id=1269826] from POST to MODIFIED

> Option roleRecursion does not work in LdapRolesMappingProvider
> --------------------------------------------------------------
>
>                 Key: SECURITY-927
>                 URL: https://issues.jboss.org/browse/SECURITY-927
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX
>    Affects Versions: PicketBox_5_0_0.Alpha2
>            Reporter: Ondrej Lukas
>            Assignee: Ryan Emerson
>
> Option roleRecursion does not work in org.jboss.security.mapping.providers.role.LdapRolesMappingProvider. Only entries without recursion are found. No recursive search is done by LdapRolesMappingProvider since LdapRolesMappingProvider.rolesSearch method tries to make a recursive search with same parameters.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 12:51:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 24 Oct 2016 12:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1836) Rejection-style transformer
 tests assume each operation generated by parser has distinct PathAddress
In-Reply-To: <JIRA.12634897.1466714467000@Atlassian.JIRA>
References: <JIRA.12634897.1466714467000@Atlassian.JIRA>
	<JIRA.12634897.1466714467000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12634897.1466714467000.38010.1477327860230@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reopened WFCORE-1836:
------------------------------------


> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1836
>                 URL: https://issues.jboss.org/browse/WFCORE-1836
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Paul Ferraro
>            Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress.  This is fine when the subsystem's parser only generates add operations.  However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address.  If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 12:52:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 24 Oct 2016 12:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1836) Rejection-style transformer
 tests assume each operation generated by parser has distinct PathAddress
In-Reply-To: <JIRA.12634897.1466714467000@Atlassian.JIRA>
References: <JIRA.12634897.1466714467000@Atlassian.JIRA>
	<JIRA.12634897.1466714467000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12634897.1466714467000.38015.1477327920152@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310999#comment-13310999 ] 

Radoslav Husar commented on WFCORE-1836:
----------------------------------------

Actually, the issue still holds. What we need is different set of attribute checkers for the same path but different operations since there is and add and write-attribute ops at the same address. What I am doing in  WFLY-7362 still a workaround.

> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1836
>                 URL: https://issues.jboss.org/browse/WFCORE-1836
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Paul Ferraro
>            Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress.  This is fine when the subsystem's parser only generates add operations.  However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address.  If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 14:09:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 24 Oct 2016 14:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1875) Logstash TCP-Input throws
 "Bad record MAC" when trying to connect with WildFly over SSL/TLS
In-Reply-To: <JIRA.12655496.1476797524000@Atlassian.JIRA>
References: <JIRA.12655496.1476797524000@Atlassian.JIRA>
	<JIRA.12655496.1476797524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655496.1476797524000.38151.1477332540198@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311018#comment-13311018 ] 

James Perkins commented on WFCORE-1875:
---------------------------------------

This is more than likely an issue with the {{SocketHandler}} in the log manager. I'll leave this issue open here for now until I get have a more detailed look at it.

> Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1875
>                 URL: https://issues.jboss.org/browse/WFCORE-1875
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Patrick Kleindienst
>            Assignee: James Perkins
>              Labels: jboss, logging, ssl
>
> I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown:
> {code:java}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.net.SocketException: Socket is closed
> 	at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:596)
> 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143)
> 	at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164)
> 	at java.io.PrintStream.write(PrintStream.java:482)
> 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264)
> 	at java.io.PrintStream.write(PrintStream.java:480)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> 	at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> 	at java.io.PrintStream.newLine(PrintStream.java:546)
> 	at java.io.PrintStream.println(PrintStream.java:696)
> 	at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116)
> 	at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297)
> 	at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306)
> 	at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264)
> 	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> 	at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84)
> 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> 	at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> 	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> 	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> 	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169)
> 	at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104)
> 	at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> 	at org.jboss.logmanager.Logger.log(Logger.java:802)
> 	at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> 	at org.jboss.logging.Logger.logf(Logger.java:2398)
> 	at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65)
> 	at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93)
> 	at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214)
> {code}
>     
> On the Logstash side, the following error message appears in the logs:
> {code}
> :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC>
> {code}
> Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases:
> * *** ClientHello, TLSv1.2
> * *** ServerHello, TLSv1.2
> * %% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
> * Found trusted certificate
> * *** ECDH ServerKeyExchange
> * *** ServerHelloDone
> * *** ECDHClientKeyExchange
> * SESSION KEYGEN:
> * CONNECTION KEYGEN:
> * *** Finished
>    
> When disabling SSL both on WildFly and Logstash side, everything works fine.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 14:26:00 2016
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Mon, 24 Oct 2016 14:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1335) Add protection in
 RaXmlDeployer to prevent from loading xml resource
In-Reply-To: <JIRA.12652842.1475249080000@Atlassian.JIRA>
References: <JIRA.12652842.1475249080000@Atlassian.JIRA>
	<JIRA.12652842.1475249080000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652842.1475249080000.38217.1477333560334@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell resolved JBJCA-1335.
---------------------------------
    Resolution: Done


merged https://github.com/ironjacamar/ironjacamar/commit/5bb9b2dd7b276f6960772b0c8c032260dc4541e9

> Add protection in RaXmlDeployer to prevent from loading xml resource
> --------------------------------------------------------------------
>
>                 Key: JBJCA-1335
>                 URL: https://issues.jboss.org/browse/JBJCA-1335
>             Project: IronJacamar
>          Issue Type: Enhancement
>          Components: Deployer
>    Affects Versions: 1.2.7.Final
>            Reporter: COLLIGNON Thomas
>            Priority: Minor
>             Fix For: 1.2.8.Final
>
>
> If we place a -ra.xml in jar file, the class RaXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
> The goal of this issue is prevent for loading jar file in RaXmlDeployer .
> The second goal is to provide ability of overring RaXmlDeployer in custom deployer who extends this class.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 14:33:01 2016
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Mon, 24 Oct 2016 14:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-931)
 PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access
In-Reply-To: <JIRA.12597989.1451581482000@Atlassian.JIRA>
References: <JIRA.12597989.1451581482000@Atlassian.JIRA>
	<JIRA.12597989.1451581482000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597989.1451581482000.38247.1477333981052@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek resolved SECURITY-931.
-----------------------------------
    Resolution: Done


https://github.com/picketbox/picketbox/pull/66

> PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access
> -----------------------------------------------------------------------
>
>                 Key: SECURITY-931
>                 URL: https://issues.jboss.org/browse/SECURITY-931
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: PicketBox
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>            Priority: Minor
>
> Acces should be Access in : 
> security-spi/common/src/main/java/org/jboss/security/PicketBoxMessages.java:    @Message(id = 17, value = "Acces denied: authorization failed")



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 14:43:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 24 Oct 2016 14:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6390) Elytron integration with
	Batch / JBeret
In-Reply-To: <JIRA.12610887.1458208442000@Atlassian.JIRA>
References: <JIRA.12610887.1458208442000@Atlassian.JIRA>
	<JIRA.12610887.1458208442000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610887.1458208442000.38269.1477334580246@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned WFLY-6390:
-----------------------------------

    Assignee: James Perkins  (was: Darran Lofthouse)


> Elytron integration with Batch / JBeret 
> ----------------------------------------
>
>                 Key: WFLY-6390
>                 URL: https://issues.jboss.org/browse/WFLY-6390
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Batch
>            Reporter: Darran Lofthouse
>            Assignee: James Perkins
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 15:57:00 2016
From: issues at jboss.org (Gail Badner (JIRA))
Date: Mon, 24 Oct 2016 15:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.2
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.38589.1477339020640@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311067#comment-13311067 ] 

Gail Badner commented on WFLY-6854:
-----------------------------------

I'm changing the description to upgrade to 5.1.3, because 5.1.2 contains HHH-11155.

The reason for branching Hibernate 5.1 was to allow "fetch groups". In 5.0 and earlier, if any lazy property was initialized, then all lazy properties would automatically get initialized. 5.1 allows different combinations of lazy properties to be put into a "fetch group". The idea is that if any lazy property is a group is explicitly initialized, then Hibernate will initialized all properties in the fetch group. Any lazy properties that are not in the fetch group are unaffected. 

HHH-11155 is a bug where an update does not happen unless all lazy properties, regardless of fetch group, are initialized. This bug should be fixed before upgrading to 5.1.

> Upgrade Hibernate ORM to 5.1.2
> ------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 15:57:01 2016
From: issues at jboss.org (Gail Badner (JIRA))
Date: Mon, 24 Oct 2016 15:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.38602.1477339021062@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gail Badner updated WFLY-6854:
------------------------------
    Summary: Upgrade Hibernate ORM to 5.1.3  (was: Upgrade Hibernate ORM to 5.1.2)


> Upgrade Hibernate ORM to 5.1.3
> ------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 15:57:01 2016
From: issues at jboss.org (Gail Badner (JIRA))
Date: Mon, 24 Oct 2016 15:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.38610.1477339021366@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gail Badner updated WFLY-6854:
------------------------------
    Summary: Upgrade Hibernate ORM to 5.1.3   (was: Upgrade Hibernate ORM to 5.1.3)


> Upgrade Hibernate ORM to 5.1.3 
> -------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 17:02:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 24 Oct 2016 17:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1742) Allow registering a custom
 handler for management interface
In-Reply-To: <JIRA.12644557.1472031503000@Atlassian.JIRA>
References: <JIRA.12644557.1472031503000@Atlassian.JIRA>
	<JIRA.12644557.1472031503000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644557.1472031503000.38832.1477342920550@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1742:
-------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1872  (was: https://issues.jboss.org/browse/WFCORE-1742)


> Allow registering a custom handler for management interface
> -----------------------------------------------------------
>
>                 Key: WFCORE-1742
>                 URL: https://issues.jboss.org/browse/WFCORE-1742
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Sebastian ?askawiec
>
> When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users):
> {noformat}
> curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-container/clustered/health/HEALTH?operation=resource&include-runtime=true&json.pretty=1" --header "Content-Type: application/json" -u ispnadmin:ispnadmin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> HTTP/1.1 200 OK
> Connection: keep-alive
> Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 1927
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> {
>     "cache-health" : "GREEN",
>     "cluster-health" : ["test"],
>     "cluster-name" : "clustered",
>     "free-memory" : 96778,
>     "log-tail" : [
>         "2016-08-10 11:54:14,706 INFO  [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
>         "2016-08-10 11:54:14,706 INFO  [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
>         "2016-08-10 11:54:14,785 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
>         "2016-08-10 11:54:14,800 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
>         "2016-08-10 11:54:15,159 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
>         "2016-08-10 11:54:15,210 INFO  [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
>         "2016-08-10 11:54:15,210 INFO  [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
>         "2016-08-10 11:54:15,306 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
>         "2016-08-10 11:54:15,307 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
>         "2016-08-10 11:54:15,307 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
>     ],
>     "number-of-cpus" : 8,
>     "number-of-nodes" : 1,
>     "total-memory" : 235520
> }%
> {noformat}
> It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Mon Oct 24 18:17:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 24 Oct 2016 18:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7367) add per PU cache of the new
 temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12656172.1477066573000@Atlassian.JIRA>
References: <JIRA.12656172.1477066573000@Atlassian.JIRA>
	<JIRA.12656172.1477066573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656172.1477066573000.39137.1477347420083@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311106#comment-13311106 ] 

Stuart Douglas commented on WFLY-7367:
--------------------------------------

I don't think undeploy time is the right time to clear this. As I understand it these resources are only really used during deployment time (and are basically a way for the JPA provider to examine the class path without forcing classes to actually be loaded). If these were cached till undeploy then these deployment time resources will be held for much longer than what is required.

If this is going to be cached IMHO the correct time to clear the cache is after PU service start.

> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7367
>                 URL: https://issues.jboss.org/browse/WFLY-7367
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.
> Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
>     temporary ClassLoader with same visibility as current loader 
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 19:49:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 24 Oct 2016 19:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7367) add per PU cache of the new
 temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12656172.1477066573000@Atlassian.JIRA>
References: <JIRA.12656172.1477066573000@Atlassian.JIRA>
	<JIRA.12656172.1477066573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656172.1477066573000.39344.1477352940310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-7367:
-------------------------------
    Description: 
The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.

Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns.

Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
{quote}
ClassLoader getNewTempClassLoader()

Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.

Returns:
    temporary ClassLoader with same visibility as current loader 
{quote}

  was:
The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.

Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.

Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
{quote}
ClassLoader getNewTempClassLoader()

Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.

Returns:
    temporary ClassLoader with same visibility as current loader 
{quote}



> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7367
>                 URL: https://issues.jboss.org/browse/WFLY-7367
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.
> Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
>     temporary ClassLoader with same visibility as current loader 
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 19:58:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 24 Oct 2016 19:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7367) add per PU cache of the new
 temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12656172.1477066573000@Atlassian.JIRA>
References: <JIRA.12656172.1477066573000@Atlassian.JIRA>
	<JIRA.12656172.1477066573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656172.1477066573000.39399.1477353480297@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311128#comment-13311128 ] 

Scott Marlow commented on WFLY-7367:
------------------------------------

Good point [~swd847], thanks for the feedback.  I updated the description to reflect your suggestion.  My local testing of [https://github.com/scottmarlow/wildfly/commit/e63a5ac75f2ca764dac9fda776e4e0077b2de305] was successful so far.  If we keep this change, we should also have a persistence unit hint for disabling the caching.

An alternative might be for Hibernate ORM to do the caching of the getNewTempClassLoader() result, which might also help reduce permgen use for applications with a large number of entities.

> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7367
>                 URL: https://issues.jboss.org/browse/WFLY-7367
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.
> Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
>     temporary ClassLoader with same visibility as current loader 
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Oct 24 22:33:00 2016
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Mon, 24 Oct 2016 22:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.39707.1477362780282@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311158#comment-13311158 ] 

Hisanobu Okuda commented on WFCORE-1868:
----------------------------------------

Jean-Francois, could you please ask Stale to review my pr?

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 25 02:47:00 2016
From: issues at jboss.org (Jan Hrcek (JIRA))
Date: Tue, 25 Oct 2016 02:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1335) Classpath is not checked
 for Kie Module ReleaseId
In-Reply-To: <JIRA.12655648.1476873134000@Atlassian.JIRA>
References: <JIRA.12655648.1476873134000@Atlassian.JIRA>
	<JIRA.12655648.1476873134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655648.1476873134000.40095.1477378020238@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311183#comment-13311183 ] 

Jan Hrcek commented on DROOLS-1335:
-----------------------------------

Hi [~mfusco],
the change introduced in your commit is now causing errors when building & deploying containers to kie-server.
To be specific I see the following stacktrace from kie-server when trying to build&deploy simplest project.

Not sure if this requires fixing on drools-compiler or on kie-server side, so feel free to reassign this..


{noformat}
08:29:29,338 ERROR [org.kie.server.services.impl.KieServerImpl] (default task-11) Error creating container 'abn_1.0' for module 'demo:abn:1.0': java.lang.ClassCastException: org.kie.server.api.model.ReleaseId cannot be cast to org.drools.compiler.kproject.ReleaseIdImpl
	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.checkClasspathForKieModule(KieRepositoryImpl.java:156)
	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:136)
	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:119)
	at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:184)
	at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:176)
	at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:245)
{noformat}


> Classpath is not checked for Kie Module ReleaseId
> -------------------------------------------------
>
>                 Key: DROOLS-1335
>                 URL: https://issues.jboss.org/browse/DROOLS-1335
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.4.0.Final, 6.5.0.CR2, 7.0.0.Beta2
>            Reporter: Chadi El Masri
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.Beta3
>
>         Attachments: 0001-Implement-the-method-to-read-the-KieModule-from-clas.patch
>
>
> Injecting a ksession annotated with a particular @KReleaseId is not able to read the passed release id from the classpath (the part that does that is not implemented).
> The bug is here: https://github.com/droolsjbpm/drools/blob/6.4.0.Final/drools-compiler/src/main/java/org/drools/compiler/kie/builder/impl/KieRepositoryImpl.java#L123-L126
> Patch attached.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 25 02:48:00 2016
From: issues at jboss.org (Jan Hrcek (JIRA))
Date: Tue, 25 Oct 2016 02:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1335) Classpath is not checked
 for Kie Module ReleaseId
In-Reply-To: <JIRA.12655648.1476873134000@Atlassian.JIRA>
References: <JIRA.12655648.1476873134000@Atlassian.JIRA>
	<JIRA.12655648.1476873134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655648.1476873134000.40103.1477378080648@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Hrcek reopened DROOLS-1335:
-------------------------------


> Classpath is not checked for Kie Module ReleaseId
> -------------------------------------------------
>
>                 Key: DROOLS-1335
>                 URL: https://issues.jboss.org/browse/DROOLS-1335
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.4.0.Final, 6.5.0.CR2, 7.0.0.Beta2
>            Reporter: Chadi El Masri
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.Beta3
>
>         Attachments: 0001-Implement-the-method-to-read-the-KieModule-from-clas.patch
>
>
> Injecting a ksession annotated with a particular @KReleaseId is not able to read the passed release id from the classpath (the part that does that is not implemented).
> The bug is here: https://github.com/droolsjbpm/drools/blob/6.4.0.Final/drools-compiler/src/main/java/org/drools/compiler/kie/builder/impl/KieRepositoryImpl.java#L123-L126
> Patch attached.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 25 03:55:00 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 25 Oct 2016 03:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7371) JAXRS endpoint - CDI
 injection to constructor doesn't work
In-Reply-To: <JIRA.12656473.1477382051000@Atlassian.JIRA>
References: <JIRA.12656473.1477382051000@Atlassian.JIRA>
	<JIRA.12656473.1477382051480@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656473.1477382051000.40570.1477382100301@Atlassian.JIRA>

Tomas Remes created WFLY-7371:
---------------------------------

             Summary: JAXRS endpoint - CDI injection to constructor doesn't work
                 Key: WFLY-7371
                 URL: https://issues.jboss.org/browse/WFLY-7371
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld, REST
    Affects Versions: 10.1.0.Final
            Reporter: Tomas Remes
            Assignee: Stuart Douglas


Deploying app with following JAXRS endpoint 
{code}

@Path("/test")
public class MyTimeResource {

    private final LocalDateTime dateTime;

    @Inject
    public MyTimeResource(LocalDateTime dateTime){
        this.dateTime = dateTime;
    };

}
{code}
is failing with following stack trace:
{noformat}
Caused by: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.example.microprofile.MyTimeResource
	at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:692)
	at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:42)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:194)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:180)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:157)
	at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:76)
	at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:409)
	at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:250)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
	at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250)
	at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133)
	at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:546)
	at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:517)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
	at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:559)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
	... 6 more
{noformat}
Note that app contains beans.xml so the JAXRS resource should be really managed by CDI.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 25 04:12:01 2016
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 25 Oct 2016 04:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7371) JAXRS endpoint - CDI
 injection to constructor doesn't work
In-Reply-To: <JIRA.12656473.1477382051000@Atlassian.JIRA>
References: <JIRA.12656473.1477382051000@Atlassian.JIRA>
	<JIRA.12656473.1477382051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656473.1477382051000.40659.1477383121090@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311230#comment-13311230 ] 

Tomas Remes commented on WFLY-7371:
-----------------------------------

I think this is a RESTEasy issue.

> JAXRS endpoint - CDI injection to constructor doesn't work
> ----------------------------------------------------------
>
>                 Key: WFLY-7371
>                 URL: https://issues.jboss.org/browse/WFLY-7371
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, REST
>    Affects Versions: 10.1.0.Final
>            Reporter: Tomas Remes
>            Assignee: Stuart Douglas
>
> Deploying app with following JAXRS endpoint 
> {code}
> @Path("/test")
> public class MyTimeResource {
>     private final LocalDateTime dateTime;
>     @Inject
>     public MyTimeResource(LocalDateTime dateTime){
>         this.dateTime = dateTime;
>     };
> }
> {code}
> is failing with following stack trace:
> {noformat}
> Caused by: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.example.microprofile.MyTimeResource
> 	at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:692)
> 	at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:42)
> 	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208)
> 	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:194)
> 	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:180)
> 	at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:157)
> 	at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:76)
> 	at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:409)
> 	at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:250)
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> 	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> 	at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> 	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250)
> 	at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:546)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:517)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 	at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:559)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> {noformat}
> Note that app contains beans.xml so the JAXRS resource should be really managed by CDI.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 25 06:32:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 25 Oct 2016 06:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1891) Split WildFly Elytron into
 two modules with a public / private split.
In-Reply-To: <JIRA.12656506.1477391493000@Atlassian.JIRA>
References: <JIRA.12656506.1477391493000@Atlassian.JIRA>
	<JIRA.12656506.1477391493063@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656506.1477391493000.41286.1477391520223@Atlassian.JIRA>

Darran Lofthouse created WFCORE-1891:
----------------------------------------

             Summary: Split WildFly Elytron into two modules with a public / private split.
                 Key: WFCORE-1891
                 URL: https://issues.jboss.org/browse/WFCORE-1891
             Project: WildFly Core
          Issue Type: Task
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 3.0.0.Alpha11


The Elytron jar will be contained within a private module, possibly 'elytron-private' then a module 'elytron' will depend on this and make the public packages visible.

The following packages have been identified as being private: -

org.wildfly.security._private
org.wildfly.security.asn1
org.wildfly.security.auth.realm
org.wildfly.security.auth.realm.*
org.wildfly.security.authz.jacc
org.wildfly.security.credential.store.impl
org.wildfly.security.security.digest
org.wildfly.security.http.impl
org.wildfly.security.security.keystore
org.wildfly.security.mechanism.oauth2
org.wildfly.security.mechanism.scram
org.wildfly.security.password.impl
org.wildfly.security.password.util
org.wildfly.security.pem
org.wildfly.security.sasl
org.wildfly.security.sasl.* (Except util)
org.wildfly.security.util
org.wildfly.security.util_private
org.wildfly.security.x500
org.wildfly.security.x500.cert




--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 25 06:44:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 25 Oct 2016 06:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-681) Hide private packages from
 generated javadoc.
In-Reply-To: <JIRA.12656512.1477392202000@Atlassian.JIRA>
References: <JIRA.12656512.1477392202000@Atlassian.JIRA>
	<JIRA.12656512.1477392202624@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656512.1477392202000.41360.1477392240352@Atlassian.JIRA>

Darran Lofthouse created ELY-681:
------------------------------------

             Summary: Hide private packages from generated javadoc.
                 Key: ELY-681
                 URL: https://issues.jboss.org/browse/ELY-681
             Project: WildFly Elytron
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Priority: Critical
             Fix For: 1.1.0.Beta12


We may want two profiles so we can generate a full javadoc and a 'public' javadoc.

The 'public' javadoc should be the default one generated and should exclude the following packages: -

org.wildfly.security._private
org.wildfly.security.asn1
org.wildfly.security.auth.realm
org.wildfly.security.auth.realm.*
org.wildfly.security.authz.jacc
org.wildfly.security.credential.store.impl
org.wildfly.security.security.digest
org.wildfly.security.http.impl
org.wildfly.security.security.keystore
org.wildfly.security.mechanism.oauth2
org.wildfly.security.mechanism.scram
org.wildfly.security.password.impl
org.wildfly.security.password.util
org.wildfly.security.pem
org.wildfly.security.sasl
org.wildfly.security.sasl.* (Except util)
org.wildfly.security.util
org.wildfly.security.util_private
org.wildfly.security.x500
org.wildfly.security.x500.cert



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 25 06:51:00 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 25 Oct 2016 06:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2112) Sticky site masters
In-Reply-To: <JIRA.12655119.1476607610000@Atlassian.JIRA>
References: <JIRA.12655119.1476607610000@Atlassian.JIRA>
	<JIRA.12655119.1476607610000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655119.1476607610000.41402.1477392660199@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311288#comment-13311288 ] 

Bela Ban commented on JGRP-2112:
--------------------------------

Unit test: Relay2Test.testSenderOrderWithMultipleSiteMasters()

> Sticky site masters
> -------------------
>
>                 Key: JGRP-2112
>                 URL: https://issues.jboss.org/browse/JGRP-2112
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.12, 4.0
>
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
> h4. Design
> * When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller
> * Note that this only applies when we have more than one site master.
> * The callback passes the address of the original caller and the list of available site masters, and needs to return a site master
> h5. Transactions
> * Transactions by different originators with overlapping key sets cannot be reliably ordered
> * Transactional support therefore requires single site masters
> * This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Oct 25 07:21:01 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 25 Oct 2016 07:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1052) Add server-config parameter
 to :reload op
In-Reply-To: <JIRA.12588893.1444737333000@Atlassian.JIRA>
References: <JIRA.12588893.1444737333000@Atlassian.JIRA>
	<JIRA.12588893.1444737333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588893.1444737333000.41798.1477394461305@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311315#comment-13311315 ] 

Martin Choma commented on WFCORE-1052:
--------------------------------------

[~kabirkhan], what are valid values for --server-config attribute? Relative files to {{standalone/configuration}} dir and {{standalone/configuration/standalone_xml_history/snapshot}} dir ? If that can't be change to accept absolute paths, could that be somehow documented?


> Add server-config parameter to :reload op
> -----------------------------------------
>
>                 Key: WFCORE-1052
>                 URL: https://issues.jboss.org/browse/WFCORE-1052
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 3.0.0.Alpha1
>
>
> {code}
> [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml
 looks for that file in the snapshots directory
> [13:48] Kabir Khan: 
> [standalone at localhost:9990 /] :list-snapshots
> 		{
>     "outcome" => "success",
>     "result" => {
>         "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot",
>         "names" => [
>             "20151013-134523280standalone.xml",
>             "20151013-134726769standalone.xml"
>         ]
>     }
> 		}
> 		Show less
> [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation
> {code}
> Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail. 
> For a domain server, we should not have the server-config parameter.
> We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Oct 25 09:21:05 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 25 Oct 2016 09:21:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7367) add per PU cache of the new
 temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12656172.1477066573000@Atlassian.JIRA>
References: <JIRA.12656172.1477066573000@Atlassian.JIRA>
	<JIRA.12656172.1477066573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656172.1477066573000.857.1477401665574@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311516#comment-13311516 ] 

Scott Marlow commented on WFLY-7367:
------------------------------------

potential implementation is pushed to https://github.com/scottmarlow/wildfly/commits/WFLY-7367_cachetempclassloader.  We would want to add a persistence unit hint check as well before merging.  I'm going to address the entity class leak differently as Hibernate only seems to call getNewTempClassLoader once per persistence unit, its our ORM Scanner implementation code that needs to cache the new temp class loader instead (class leak is mostly from change for AS7-3085).

> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7367
>                 URL: https://issues.jboss.org/browse/WFLY-7367
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.
> Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
>     temporary ClassLoader with same visibility as current loader 
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 09:21:06 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 25 Oct 2016 09:21:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7367) add per PU cache of the new
 temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12656172.1477066573000@Atlassian.JIRA>
References: <JIRA.12656172.1477066573000@Atlassian.JIRA>
	<JIRA.12656172.1477066573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656172.1477066573000.869.1477401666307@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-7367.
------------------------------
    Resolution: Won't Do


> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7367
>                 URL: https://issues.jboss.org/browse/WFLY-7367
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.
> Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
>     temporary ClassLoader with same visibility as current loader 
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 09:26:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 25 Oct 2016 09:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7372) Hibernate Scanner
 implementation class shouldn't leak application entity classes
In-Reply-To: <JIRA.12656712.1477401925000@Atlassian.JIRA>
References: <JIRA.12656712.1477401925000@Atlassian.JIRA>
	<JIRA.12656712.1477401925370@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656712.1477401925000.919.1477401960258@Atlassian.JIRA>

Scott Marlow created WFLY-7372:
----------------------------------

             Summary: Hibernate Scanner implementation class shouldn't leak application entity classes
                 Key: WFLY-7372
                 URL: https://issues.jboss.org/browse/WFLY-7372
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 09:28:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 25 Oct 2016 09:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7372) Hibernate Scanner
 implementation class shouldn't leak application entity classes
In-Reply-To: <JIRA.12656712.1477401925000@Atlassian.JIRA>
References: <JIRA.12656712.1477401925000@Atlassian.JIRA>
	<JIRA.12656712.1477401925000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656712.1477401925000.922.1477402080327@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-7372:
-------------------------------
    Affects Version/s: 10.1.0.Final
                       JBoss AS7 7.2.0.Final


> Hibernate Scanner implementation class shouldn't leak application entity classes
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-7372
>                 URL: https://issues.jboss.org/browse/WFLY-7372
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: JBoss AS7 7.2.0.Final, 10.1.0.Final
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 09:30:01 2016
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Tue, 25 Oct 2016 09:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1341) "unable to resolve method
 using strict-mode" MVEL exception when using function definitions in DRL
In-Reply-To: <JIRA.12656713.1477402162000@Atlassian.JIRA>
References: <JIRA.12656713.1477402162000@Atlassian.JIRA>
	<JIRA.12656713.1477402162031@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656713.1477402162000.929.1477402201897@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-1341:
-------------------------------------

             Summary: "unable to resolve method using strict-mode" MVEL exception when using function definitions in DRL
                 Key: DROOLS-1341
                 URL: https://issues.jboss.org/browse/DROOLS-1341
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Mario Fusco


The test Misc2Test.testFunctionInvokingFunction() occasionally fails with following stacktrace [1]. It is probably some race condition, because the test runs multiple threads with different KieSessions accessing the same KieBase. 

[1] http://pastebin.com/8WWwYscQ



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 09:31:06 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 25 Oct 2016 09:31:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1052) Add server-config parameter
 to :reload op
In-Reply-To: <JIRA.12588893.1444737333000@Atlassian.JIRA>
References: <JIRA.12588893.1444737333000@Atlassian.JIRA>
	<JIRA.12588893.1444737333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588893.1444737333000.964.1477402266708@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311523#comment-13311523 ] 

Kabir Khan commented on WFCORE-1052:
------------------------------------

It should be the same as the --server-config command line option, i.e. https://docs.jboss.org/author/display/WFLY10/Command+line+parameters. I *believe* that we turned off the possibility to use absolute paths a long time ago due to the task of keeping the history directory up to date. 

The --server-config command line option is mentioned at the end of https://docs.jboss.org/author/display/WFLY10/Configuration+file+history, and in https://docs.jboss.org/author/display/WFLY10/Command+line+parameters.

I could probably append onto the end of the operation parameter something like "This parameter will be resolved the same as the --server-config command line option used when starting the server"

> Add server-config parameter to :reload op
> -----------------------------------------
>
>                 Key: WFCORE-1052
>                 URL: https://issues.jboss.org/browse/WFCORE-1052
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 3.0.0.Alpha1
>
>
> {code}
> [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml
 looks for that file in the snapshots directory
> [13:48] Kabir Khan: 
> [standalone at localhost:9990 /] :list-snapshots
> 		{
>     "outcome" => "success",
>     "result" => {
>         "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot",
>         "names" => [
>             "20151013-134523280standalone.xml",
>             "20151013-134726769standalone.xml"
>         ]
>     }
> 		}
> 		Show less
> [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation
> {code}
> Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail. 
> For a domain server, we should not have the server-config parameter.
> We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 09:35:02 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 25 Oct 2016 09:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7372) Hibernate Scanner
 implementation class shouldn't leak application entity classes
In-Reply-To: <JIRA.12656712.1477401925000@Atlassian.JIRA>
References: <JIRA.12656712.1477401925000@Atlassian.JIRA>
	<JIRA.12656712.1477401925000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656712.1477401925000.994.1477402502766@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311525#comment-13311525 ] 

Scott Marlow commented on WFLY-7372:
------------------------------------

This doesn't impact our Hibernate ORM 4.3 or greater integrations, since the Scanner api is not implemented by our integration code in the higher versions.

> Hibernate Scanner implementation class shouldn't leak application entity classes
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-7372
>                 URL: https://issues.jboss.org/browse/WFLY-7372
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: JBoss AS7 7.2.0.Final, 10.1.0.Final
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 09:35:02 2016
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 25 Oct 2016 09:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2112) Sticky site masters
In-Reply-To: <JIRA.12655119.1476607610000@Atlassian.JIRA>
References: <JIRA.12655119.1476607610000@Atlassian.JIRA>
	<JIRA.12655119.1476607610000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655119.1476607610000.998.1477402502885@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2112.
----------------------------
    Resolution: Done


> Sticky site masters
> -------------------
>
>                 Key: JGRP-2112
>                 URL: https://issues.jboss.org/browse/JGRP-2112
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.6.12, 4.0
>
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
> h4. Design
> * When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller
> * Note that this only applies when we have more than one site master.
> * The callback passes the address of the original caller and the list of available site masters, and needs to return a site master
> h5. Transactions
> * Transactions by different originators with overlapping key sets cannot be reliably ordered
> * Transactional support therefore requires single site masters
> * This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 10:35:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Tue, 25 Oct 2016 10:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-682) There isn't possibility set
 entry-type for new entry in Credential Store.
In-Reply-To: <JIRA.12656733.1477406044000@Atlassian.JIRA>
References: <JIRA.12656733.1477406044000@Atlassian.JIRA>
	<JIRA.12656733.1477406044361@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656733.1477406044000.1734.1477406100766@Atlassian.JIRA>

Hynek ?v?bek created ELY-682:
--------------------------------

             Summary: There isn't possibility set entry-type for new entry in Credential Store.
                 Key: ELY-682
                 URL: https://issues.jboss.org/browse/ELY-682
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek


There isn't possibility set entry-type for new entry in Credential Store

This CLI command
{code}
/subsystem=elytron/credential-store=testCS/alias=aliasEntryType:add(secret-value=secretVALUE, entry-type=org.wildfly.security.credential.PasswordCredential)
{code}
ends with
{code}
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'",
    "rolled-back" => true
}
{code}

*Server log:*
{code}
10:30:39,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("credential-store" => "testCS"),
    ("alias" => "aliasEntryType")
]): java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'
        at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.performRuntime(CredentialStoreAliasDefinition.java:166)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
        at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
        at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:422)
        at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
        at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
        at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
        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)
        at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}





--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 10:40:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Tue, 25 Oct 2016 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-683) Add error message with
 information that is not allowed to read secret-value and entry-type from
 Credential Store
In-Reply-To: <JIRA.12656735.1477406351000@Atlassian.JIRA>
References: <JIRA.12656735.1477406351000@Atlassian.JIRA>
	<JIRA.12656735.1477406351449@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656735.1477406351000.1805.1477406400730@Atlassian.JIRA>

Hynek ?v?bek created ELY-683:
--------------------------------

             Summary: Add error message with information that is not allowed to read secret-value and entry-type from Credential Store
                 Key: ELY-683
                 URL: https://issues.jboss.org/browse/ELY-683
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek
            Priority: Minor


Add error message with information that is not allowed to read secret-value and entry-type from Credential Store over CLI.

This CLI commands
{code}
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=secret-value)
/subsystem=elytron/credential-store=testCS/alias=someAlias:read-attribute(name=entry-type)
{code}
end with success result.
{code}
{
    "outcome" => "success",
    "result" => undefined
}
{code}




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 10:43:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Tue, 25 Oct 2016 10:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-684) KeystorePasswordStore contains
 inconsistency about MODIFIABLE configuration attribute
In-Reply-To: <JIRA.12656737.1477406524000@Atlassian.JIRA>
References: <JIRA.12656737.1477406524000@Atlassian.JIRA>
	<JIRA.12656737.1477406524554@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656737.1477406524000.1851.1477406580814@Atlassian.JIRA>

Hynek ?v?bek created ELY-684:
--------------------------------

             Summary: KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute
                 Key: ELY-684
                 URL: https://issues.jboss.org/browse/ELY-684
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek


KeystorePasswordStore contains inconsistency about MODIFIABLE configuration attribute.

Here it is used MODIFIABLE attribute:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L275

But it is missing between supported configuration attributes:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L222

I cannot see any condition with isModifiable() in *store()* or *remove()* method:
https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta10/src/main/java/org/wildfly/security/credential/store/impl/KeystorePasswordStore.java#L317

In my opinion MODIFIABLE attribute should be supported otherwise please remove code about MODIFIABLE from *initialize()* method.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 10:45:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Tue, 25 Oct 2016 10:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-685) Credential-reference(alias=)
 should be resolved in time of request.
In-Reply-To: <JIRA.12656739.1477406694000@Atlassian.JIRA>
References: <JIRA.12656739.1477406694000@Atlassian.JIRA>
	<JIRA.12656739.1477406694627@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656739.1477406694000.1911.1477406700829@Atlassian.JIRA>

Hynek ?v?bek created ELY-685:
--------------------------------

             Summary: Credential-reference(alias=) should be resolved in time of request.
                 Key: ELY-685
                 URL: https://issues.jboss.org/browse/ELY-685
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
    Affects Versions: 1.1.0.Beta10
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek


Credential-reference should be resolved in time of request - in this case the alias which contains wrong password in CredentialStore (we can change it later to right password...).

If I add credential reference with alias which contains wrong password then I get this error:
{code}
{
        "outcome" => "failed",                                                                                           
        "failure-description" => {                                                                                       
            "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fireflyWrong" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fireflyWrong: WFLYELY00004: Unable to start the service.      
        Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect                            
        Caused by: java.security.UnrecoverableKeyException: Password verification failed"},                              
            "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fireflyWrong"], 
            "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined                                   
        },                                                                                                               
        "rolled-back" => true                                                                                            
    }
{code}

*When I reload server then same command pass!*
But I nowhere got information about reload-required
{code}
/subsystem=elytron/key-store=fireflyWrong:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=credStore2,alias=ffWithWrongPass})
{code}





--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 10:47:00 2016
From: issues at jboss.org (Farah Juma (JIRA))
Date: Tue, 25 Oct 2016 10:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7373) Revisit the
 "jboss.naming.client.ejb.context" property and its use in the
 DatabaseTimerServiceMultiNode*TestCases
In-Reply-To: <JIRA.12656740.1477406774000@Atlassian.JIRA>
References: <JIRA.12656740.1477406774000@Atlassian.JIRA>
	<JIRA.12656740.1477406774178@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656740.1477406774000.1956.1477406820477@Atlassian.JIRA>

Farah Juma created WFLY-7373:
--------------------------------

             Summary: Revisit the "jboss.naming.client.ejb.context" property and its use in the DatabaseTimerServiceMultiNode*TestCases
                 Key: WFLY-7373
                 URL: https://issues.jboss.org/browse/WFLY-7373
             Project: WildFly
          Issue Type: Bug
            Reporter: Farah Juma
            Assignee: Farah Juma


Both {{DatabaseTimerServiceMultiNodeExecutionDisabledTestCase}} and {{DatabaseTimerServiceMultiNodeTestCase}} rely on specifying the {{jboss.naming.client.ejb.context}} property during {{InitialContext}} creation in order to ensure that an {{EJBClientContext}} will get set up properly with an appropriate {{EJBReceiver}}. Since the new WildFly naming client doesn't currently handle this property, we need to manually set the {{EJBClientConfiguration}} in this test for now. We need to revisit this modification when the new WildFly naming client and EJB client are being integrated. Note that without this modification, the tests fail with the following error:

{code}
java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:testTimerServiceSimple, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext at 6548bb7d
	at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:774)
	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:128)
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
	at com.sun.proxy.$Proxy24.scheduleTimer(Unknown Source)
	at org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeExecutionDisabledTestCase.testEjbTimeoutOnOtherNode(DatabaseTimerServiceMultiNodeExecutionDisabledTestCase.java:197)
{code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 10:48:00 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 25 Oct 2016 10:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1052) Add server-config parameter
 to :reload op
In-Reply-To: <JIRA.12588893.1444737333000@Atlassian.JIRA>
References: <JIRA.12588893.1444737333000@Atlassian.JIRA>
	<JIRA.12588893.1444737333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588893.1444737333000.1967.1477406880450@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311580#comment-13311580 ] 

Kabir Khan commented on WFCORE-1052:
------------------------------------

I have added the better strings in https://github.com/wildfly/wildfly-core/pull/1876

> Add server-config parameter to :reload op
> -----------------------------------------
>
>                 Key: WFCORE-1052
>                 URL: https://issues.jboss.org/browse/WFCORE-1052
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 3.0.0.Alpha1
>
>
> {code}
> [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml
 looks for that file in the snapshots directory
> [13:48] Kabir Khan: 
> [standalone at localhost:9990 /] :list-snapshots
> 		{
>     "outcome" => "success",
>     "result" => {
>         "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot",
>         "names" => [
>             "20151013-134523280standalone.xml",
>             "20151013-134726769standalone.xml"
>         ]
>     }
> 		}
> 		Show less
> [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation
> {code}
> Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail. 
> For a domain server, we should not have the server-config parameter.
> We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 10:50:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Tue, 25 Oct 2016 10:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-686) Credential-reference(store=...)
 should be resolved in time of request.
In-Reply-To: <JIRA.12656741.1477406993000@Atlassian.JIRA>
References: <JIRA.12656741.1477406993000@Atlassian.JIRA>
	<JIRA.12656741.1477406993235@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656741.1477406993000.1975.1477407000358@Atlassian.JIRA>

Hynek ?v?bek created ELY-686:
--------------------------------

             Summary: Credential-reference(store=...) should be resolved in time of request.
                 Key: ELY-686
                 URL: https://issues.jboss.org/browse/ELY-686
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
    Affects Versions: 1.1.0.Beta10
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek
         Attachments: firefly.keystore

Credential-reference should be resolved in time of request.

When you added KeyStore to Elytron subsystem which have credential-reference to non-exists credential store then you can see this error message

{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("key-store" => "firefly")
]) - failure description: {
    "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.NonexistingCredentialStore"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.firefly is missing [org.wildfly.security.credential-store-client.NonexistingCredentialStore]"]
}
{code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 10:50:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 25 Oct 2016 10:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-22) Upgrade jandex to 2.0.x
In-Reply-To: <JIRA.12656742.1477406995000@Atlassian.JIRA>
References: <JIRA.12656742.1477406995000@Atlassian.JIRA>
	<JIRA.12656742.1477406995398@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656742.1477406995000.1979.1477407000559@Atlassian.JIRA>

Tomaz Cerar created WFBUILD-22:
----------------------------------

             Summary: Upgrade jandex to 2.0.x
                 Key: WFBUILD-22
                 URL: https://issues.jboss.org/browse/WFBUILD-22
             Project: WildFly Build Tools
          Issue Type: Component Upgrade
    Affects Versions: 1.1.6.Final
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Currently build tools still uses jandex 1.2.x but should rather use 2.0.x to be in line with WildFly



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 10:57:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Tue, 25 Oct 2016 10:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-687) There isn't possible change
 value for given alias in Credential Store over CLI.
In-Reply-To: <JIRA.12656744.1477407404000@Atlassian.JIRA>
References: <JIRA.12656744.1477407404000@Atlassian.JIRA>
	<JIRA.12656744.1477407404978@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656744.1477407404000.2065.1477407420207@Atlassian.JIRA>

Hynek ?v?bek created ELY-687:
--------------------------------

             Summary: There isn't possible change value for given alias in Credential Store over CLI.
                 Key: ELY-687
                 URL: https://issues.jboss.org/browse/ELY-687
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
    Affects Versions: 1.1.0.Beta10
            Reporter: Hynek ?v?bek
            Assignee: Peter Skopek


There isn't possible change value for given alias in Credential Store over CLI.

I expected something like this
{code}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
{code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 11:07:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 25 Oct 2016 11:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7372) Hibernate Scanner
 implementation class shouldn't leak application entity classes
In-Reply-To: <JIRA.12656712.1477401925000@Atlassian.JIRA>
References: <JIRA.12656712.1477401925000@Atlassian.JIRA>
	<JIRA.12656712.1477401925000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656712.1477401925000.2117.1477408020460@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311589#comment-13311589 ] 

Scott Marlow commented on WFLY-7372:
------------------------------------

potential fix pushed to https://github.com/scottmarlow/wildfly/tree/WFLY-7372_scannerclassleak

> Hibernate Scanner implementation class shouldn't leak application entity classes
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-7372
>                 URL: https://issues.jboss.org/browse/WFLY-7372
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: JBoss AS7 7.2.0.Final, 10.1.0.Final
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 11:14:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 25 Oct 2016 11:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1258) Powershell scripts should
	be signed
In-Reply-To: <JIRA.12598065.1451919348000@Atlassian.JIRA>
References: <JIRA.12598065.1451919348000@Atlassian.JIRA>
	<JIRA.12598065.1451919348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12598065.1451919348000.2236.1477408440299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFCORE-1258:
-----------------------------------

    Assignee:     (was: Tomaz Cerar)


> Powershell scripts should be signed
> -----------------------------------
>
>                 Key: WFCORE-1258
>                 URL: https://issues.jboss.org/browse/WFCORE-1258
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Scripts
>    Affects Versions: 2.0.5.Final
>            Reporter: Tomaz Cerar
>
> *.ps1 scripts should be signed otherwise uses would need to run in unsigned execution mode to make it work.
> Scripts should work OOTB with RemoteSigned powershell execution policy



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 11:22:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 25 Oct 2016 11:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7369) Elytron Properties realm
 parses password with "=" incorrectly
In-Reply-To: <JIRA.12656257.1477289469000@Atlassian.JIRA>
References: <JIRA.12656257.1477289469000@Atlassian.JIRA>
	<JIRA.12656257.1477289469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656257.1477289469000.2362.1477408920273@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311599#comment-13311599 ] 

Darran Lofthouse commented on WFLY-7369:
----------------------------------------

As this issue is within the core Elytron code base I think you can move this issue over into the ELY project directly and we don't need a WFLY issue.

> Elytron Properties realm parses password with "=" incorrectly
> -------------------------------------------------------------
>
>                 Key: WFLY-7369
>                 URL: https://issues.jboss.org/browse/WFLY-7369
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Dmitrii Tikhomirov
>
> In case when Elytron properties-realm uses plain-text properties file and password includes {{=}} sign then username/password is parsing incorrectly. In case when properties file contains line as {{A=B=C}} then Elytron parses it as user {{A=B}} with password {{C}}. Correct behavior should be user {{A}} with password {{B=C}}.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 11:37:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 25 Oct 2016 11:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1342) IndexOutOfBoundsException
 when using query with 2 entry points
In-Reply-To: <JIRA.12656779.1477409789000@Atlassian.JIRA>
References: <JIRA.12656779.1477409789000@Atlassian.JIRA>
	<JIRA.12656779.1477409789538@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656779.1477409789000.2501.1477409820623@Atlassian.JIRA>

Mario Fusco created DROOLS-1342:
-----------------------------------

             Summary: IndexOutOfBoundsException when using query with 2 entry points
                 Key: DROOLS-1342
                 URL: https://issues.jboss.org/browse/DROOLS-1342
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Mario Fusco
             Fix For: 7.0.0.Beta3


Sometimes, when using query with 2 entry points along with fireUntilHalt, the method getQueryResults fails with IndexOutOfBoundsException. See stacktrace here [1]. This was observed first in Jenkins environment running existing test QueryCepFireUntilHaltTest.withResultTest from drools repository. I managed to reproduce it locally looping the test with this code [2]. 

[1] http://pastebin.com/BBPsGty9
[2] http://pastebin.com/47y1dh1W



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 11:39:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 25 Oct 2016 11:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-676) There isn't possible change
 value for given alias in Credential Store over CLI.
In-Reply-To: <JIRA.12655904.1476970185000@Atlassian.JIRA>
References: <JIRA.12655904.1476970185000@Atlassian.JIRA>
	<JIRA.12655904.1476970185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655904.1476970185000.2548.1477409940535@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311615#comment-13311615 ] 

Tomaz Cerar commented on ELY-676:
---------------------------------

does
{noformat}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:write-attribute(name="secret-value" value="newSecretValue")
{noformat}
work?

> There isn't possible change value for given alias in Credential Store over CLI.
> -------------------------------------------------------------------------------
>
>                 Key: ELY-676
>                 URL: https://issues.jboss.org/browse/ELY-676
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> There isn't possible change value for given alias in Credential Store over CLI.
> I expected something like this
> {code}
> /subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 11:47:02 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 25 Oct 2016 11:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7349)
 configurable-sasl-server-factory cannot set mechanism information
In-Reply-To: <JIRA.12655730.1476889160000@Atlassian.JIRA>
References: <JIRA.12655730.1476889160000@Atlassian.JIRA>
	<JIRA.12655730.1476889160000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655730.1476889160000.2653.1477410422584@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311624#comment-13311624 ] 

Jan Kalina commented on WFLY-7349:
----------------------------------

TODO: Just allow multiple using of SetMechanismInformationSSF.

> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
>                 Key: WFLY-7349
>                 URL: https://issues.jboss.org/browse/WFLY-7349
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>         Attachments: sasl-test.xml, SaslTestCase.java
>
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following factory in chain but with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> *The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
> Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 11:50:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 25 Oct 2016 11:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1791) Strange operation-id
 handling in domain server reload execution
In-Reply-To: <JIRA.12650054.1473797538000@Atlassian.JIRA>
References: <JIRA.12650054.1473797538000@Atlassian.JIRA>
	<JIRA.12650054.1473797538000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650054.1473797538000.2674.1477410600089@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311625#comment-13311625 ] 

Brian Stansberry commented on WFCORE-1791:
------------------------------------------

Thanks, Yeray!

The bit I wasn't seeing is that ServerStartTask, which is only run once per server process and isn't re-run in a reload, passes the DomainServerCommunicationServices into the Bootstrap.bootstap method (via the List<ServiceActivator> param, which in turn passes it to ApplicationServerService. That means that when the reload triggers a new start() of ApplicationServerService, DomainServerCommunicationServices.activate gets run again and the new initialOperationId value is used.

I mistakenly thought DomainServerCommunicationServices.activate was only called once in the lifetime of a server process.

> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
>                 Key: WFCORE-1791
>                 URL: https://issues.jboss.org/browse/WFCORE-1791
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Yeray Santana Borges
>            Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don?t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df15c88cc89ffd90 is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete. 
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then 
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Tue Oct 25 11:53:01 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 25 Oct 2016 11:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7374) WildFfly openssl requires
 glibc 2.14 resulting in failure when starting on RHEL 6
In-Reply-To: <JIRA.12656785.1477410763000@Atlassian.JIRA>
References: <JIRA.12656785.1477410763000@Atlassian.JIRA>
	<JIRA.12656785.1477410763154@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656785.1477410763000.2724.1477410781021@Atlassian.JIRA>

Radim Hatlapatka created WFLY-7374:
--------------------------------------

             Summary: WildFfly openssl requires glibc 2.14 resulting in failure when starting on RHEL 6
                 Key: WFLY-7374
                 URL: https://issues.jboss.org/browse/WFLY-7374
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow), Server, Security
            Reporter: Radim Hatlapatka
            Assignee: Stuart Douglas
            Priority: Blocker


When starting EAP on RHEL 6 it shows ERROR messages when loading openssl \[1\]. This is caused by the wrapper requiring glibc 2.14 or newer but on RHEL 6.7 there is only glibc 2.12.

As there should be no ERROR messages during EAP start with default configuration, marking as blocker.

\[1\]
{noformat}
11:20:42,474 ERROR [stderr] (MSC service thread 1-3) java.lang.reflect.InvocationTargetException
11:20:42,476 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:20:42,479 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:20:42,481 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:20:42,494 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Method.invoke(Method.java:498)
11:20:42,495 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.init(SSL.java:73)
11:20:42,496 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName0(Native Method)
11:20:42,498 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName(Class.java:348)
11:20:42,499 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
11:20:42,505 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
11:20:42,508 ERROR [stderr] (MSC service thread 1-3) 	at java.security.AccessController.doPrivileged(Native Method)
11:20:42,516 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
11:20:42,517 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
11:20:42,524 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
11:20:42,525 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
11:20:42,539 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
11:20:42,540 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.newInstance(Class.java:442)
11:20:42,541 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
11:20:42,543 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
11:20:42,548 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
11:20:42,550 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
11:20:42,551 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
11:20:42,552 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
11:20:42,553 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
11:20:42,557 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
11:20:42,572 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
11:20:42,581 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
11:20:42,582 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
11:20:42,590 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
11:20:42,591 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
11:20:42,593 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Thread.run(Thread.java:745)
11:20:42,595 ERROR [stderr] (MSC service thread 1-3) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-2717760086872143296openssl/libwfssl.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/tmp-2717760086872143296openssl/libwfssl.so)
11:20:42,596 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
11:20:42,597 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
11:20:42,598 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1837)
11:20:42,610 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
11:20:42,611 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.System.loadLibrary(System.java:1122)
11:20:42,619 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
11:20:42,620 ERROR [stderr] (MSC service thread 1-3) 	... 34 more

{noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 11:54:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 25 Oct 2016 11:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7374) WildFfly openssl requires
 glibc 2.14 resulting in failure when starting on RHEL 6
In-Reply-To: <JIRA.12656785.1477410763000@Atlassian.JIRA>
References: <JIRA.12656785.1477410763000@Atlassian.JIRA>
	<JIRA.12656785.1477410763000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656785.1477410763000.2735.1477410840279@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-7374:
-----------------------------------
    Labels: wildfly-openssl  (was: )


> WildFfly openssl requires glibc 2.14 resulting in failure when starting on RHEL 6
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-7374
>                 URL: https://issues.jboss.org/browse/WFLY-7374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Server, Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Blocker
>              Labels: wildfly-openssl
>
> When starting EAP on RHEL 6 it shows ERROR messages when loading openssl \[1\]. This is caused by the wrapper requiring glibc 2.14 or newer but on RHEL 6.7 there is only glibc 2.12.
> As there should be no ERROR messages during EAP start with default configuration, marking as blocker.
> \[1\]
> {noformat}
> 11:20:42,474 ERROR [stderr] (MSC service thread 1-3) java.lang.reflect.InvocationTargetException
> 11:20:42,476 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:20:42,479 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:20:42,481 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:20:42,494 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Method.invoke(Method.java:498)
> 11:20:42,495 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.init(SSL.java:73)
> 11:20:42,496 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName0(Native Method)
> 11:20:42,498 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName(Class.java:348)
> 11:20:42,499 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
> 11:20:42,505 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
> 11:20:42,508 ERROR [stderr] (MSC service thread 1-3) 	at java.security.AccessController.doPrivileged(Native Method)
> 11:20:42,516 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
> 11:20:42,517 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:20:42,524 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:20:42,525 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:20:42,539 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> 11:20:42,540 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.newInstance(Class.java:442)
> 11:20:42,541 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> 11:20:42,543 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
> 11:20:42,548 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
> 11:20:42,550 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
> 11:20:42,551 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
> 11:20:42,552 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
> 11:20:42,553 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
> 11:20:42,557 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
> 11:20:42,572 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
> 11:20:42,581 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> 11:20:42,582 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 11:20:42,590 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:20:42,591 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:20:42,593 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Thread.run(Thread.java:745)
> 11:20:42,595 ERROR [stderr] (MSC service thread 1-3) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-2717760086872143296openssl/libwfssl.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/tmp-2717760086872143296openssl/libwfssl.so)
> 11:20:42,596 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> 11:20:42,597 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
> 11:20:42,598 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1837)
> 11:20:42,610 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> 11:20:42,611 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.System.loadLibrary(System.java:1122)
> 11:20:42,619 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
> 11:20:42,620 ERROR [stderr] (MSC service thread 1-3) 	... 34 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 11:55:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 25 Oct 2016 11:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7374) WildFfly openssl requires
 glibc 2.14 resulting in failure when starting on RHEL 6
In-Reply-To: <JIRA.12656785.1477410763000@Atlassian.JIRA>
References: <JIRA.12656785.1477410763000@Atlassian.JIRA>
	<JIRA.12656785.1477410763000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656785.1477410763000.2742.1477410900416@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-7374:
-----------------------------------
    Description: 
When starting EAP on RHEL 6 it shows ERROR messages when loading openssl \[1\]. This is caused by the wrapper requiring glibc 2.14 or newer but on RHEL 6 (RHEL 6.7) there is only glibc 2.12.

As there should be no ERROR messages during EAP start with default configuration, marking as blocker.

\[1\]
{noformat}
11:20:42,474 ERROR [stderr] (MSC service thread 1-3) java.lang.reflect.InvocationTargetException
11:20:42,476 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:20:42,479 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:20:42,481 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:20:42,494 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Method.invoke(Method.java:498)
11:20:42,495 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.init(SSL.java:73)
11:20:42,496 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName0(Native Method)
11:20:42,498 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName(Class.java:348)
11:20:42,499 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
11:20:42,505 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
11:20:42,508 ERROR [stderr] (MSC service thread 1-3) 	at java.security.AccessController.doPrivileged(Native Method)
11:20:42,516 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
11:20:42,517 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
11:20:42,524 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
11:20:42,525 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
11:20:42,539 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
11:20:42,540 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.newInstance(Class.java:442)
11:20:42,541 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
11:20:42,543 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
11:20:42,548 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
11:20:42,550 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
11:20:42,551 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
11:20:42,552 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
11:20:42,553 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
11:20:42,557 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
11:20:42,572 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
11:20:42,581 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
11:20:42,582 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
11:20:42,590 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
11:20:42,591 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
11:20:42,593 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Thread.run(Thread.java:745)
11:20:42,595 ERROR [stderr] (MSC service thread 1-3) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-2717760086872143296openssl/libwfssl.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/tmp-2717760086872143296openssl/libwfssl.so)
11:20:42,596 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
11:20:42,597 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
11:20:42,598 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1837)
11:20:42,610 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
11:20:42,611 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.System.loadLibrary(System.java:1122)
11:20:42,619 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
11:20:42,620 ERROR [stderr] (MSC service thread 1-3) 	... 34 more

{noformat}

  was:
When starting EAP on RHEL 6 it shows ERROR messages when loading openssl \[1\]. This is caused by the wrapper requiring glibc 2.14 or newer but on RHEL 6.7 there is only glibc 2.12.

As there should be no ERROR messages during EAP start with default configuration, marking as blocker.

\[1\]
{noformat}
11:20:42,474 ERROR [stderr] (MSC service thread 1-3) java.lang.reflect.InvocationTargetException
11:20:42,476 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:20:42,479 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:20:42,481 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:20:42,494 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Method.invoke(Method.java:498)
11:20:42,495 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.init(SSL.java:73)
11:20:42,496 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName0(Native Method)
11:20:42,498 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName(Class.java:348)
11:20:42,499 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
11:20:42,505 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
11:20:42,508 ERROR [stderr] (MSC service thread 1-3) 	at java.security.AccessController.doPrivileged(Native Method)
11:20:42,516 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
11:20:42,517 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
11:20:42,524 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
11:20:42,525 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
11:20:42,539 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
11:20:42,540 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.newInstance(Class.java:442)
11:20:42,541 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
11:20:42,543 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
11:20:42,548 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
11:20:42,550 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
11:20:42,551 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
11:20:42,552 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
11:20:42,553 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
11:20:42,557 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
11:20:42,572 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
11:20:42,581 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
11:20:42,582 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
11:20:42,590 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
11:20:42,591 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
11:20:42,593 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Thread.run(Thread.java:745)
11:20:42,595 ERROR [stderr] (MSC service thread 1-3) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-2717760086872143296openssl/libwfssl.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/tmp-2717760086872143296openssl/libwfssl.so)
11:20:42,596 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
11:20:42,597 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
11:20:42,598 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1837)
11:20:42,610 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
11:20:42,611 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.System.loadLibrary(System.java:1122)
11:20:42,619 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
11:20:42,620 ERROR [stderr] (MSC service thread 1-3) 	... 34 more

{noformat}



> WildFfly openssl requires glibc 2.14 resulting in failure when starting on RHEL 6
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-7374
>                 URL: https://issues.jboss.org/browse/WFLY-7374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Server, Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Blocker
>              Labels: wildfly-openssl
>
> When starting EAP on RHEL 6 it shows ERROR messages when loading openssl \[1\]. This is caused by the wrapper requiring glibc 2.14 or newer but on RHEL 6 (RHEL 6.7) there is only glibc 2.12.
> As there should be no ERROR messages during EAP start with default configuration, marking as blocker.
> \[1\]
> {noformat}
> 11:20:42,474 ERROR [stderr] (MSC service thread 1-3) java.lang.reflect.InvocationTargetException
> 11:20:42,476 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:20:42,479 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:20:42,481 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:20:42,494 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Method.invoke(Method.java:498)
> 11:20:42,495 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.init(SSL.java:73)
> 11:20:42,496 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName0(Native Method)
> 11:20:42,498 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName(Class.java:348)
> 11:20:42,499 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
> 11:20:42,505 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
> 11:20:42,508 ERROR [stderr] (MSC service thread 1-3) 	at java.security.AccessController.doPrivileged(Native Method)
> 11:20:42,516 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
> 11:20:42,517 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:20:42,524 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:20:42,525 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:20:42,539 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> 11:20:42,540 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.newInstance(Class.java:442)
> 11:20:42,541 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> 11:20:42,543 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
> 11:20:42,548 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
> 11:20:42,550 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
> 11:20:42,551 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
> 11:20:42,552 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
> 11:20:42,553 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
> 11:20:42,557 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
> 11:20:42,572 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
> 11:20:42,581 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> 11:20:42,582 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 11:20:42,590 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:20:42,591 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:20:42,593 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Thread.run(Thread.java:745)
> 11:20:42,595 ERROR [stderr] (MSC service thread 1-3) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-2717760086872143296openssl/libwfssl.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/tmp-2717760086872143296openssl/libwfssl.so)
> 11:20:42,596 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> 11:20:42,597 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
> 11:20:42,598 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1837)
> 11:20:42,610 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> 11:20:42,611 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.System.loadLibrary(System.java:1122)
> 11:20:42,619 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
> 11:20:42,620 ERROR [stderr] (MSC service thread 1-3) 	... 34 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 12:05:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 25 Oct 2016 12:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4576) JCE jar file inside a
 deployment fails the signature check
In-Reply-To: <JIRA.12570510.1430488400000@Atlassian.JIRA>
References: <JIRA.12570510.1430488400000@Atlassian.JIRA>
	<JIRA.12570510.1430488400000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570510.1430488400000.2806.1477411500459@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-4576:
------------------------------
    Workaround Description: 
- deploy as a module and use a dependency
- register in the JDK as any other JCE library

or add jboss-deployment-structure.xml
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<resources>
<resource-root path="WEB-INF/lib/bcprov-jdk15on-1.51.jar" use-physical-code-source="true"/>
</resources>
</deployment>
</jboss-deployment-structure>
{code}

  was:
- deploy as a module and use a dependency
- register in the JDK as any other JCE library

However: this means extra configuration, while shipping inside the war file requires none at all.



>  JCE jar file inside a deployment fails the signature check 
> ------------------------------------------------------------
>
>                 Key: WFLY-4576
>                 URL: https://issues.jboss.org/browse/WFLY-4576
>             Project: WildFly
>          Issue Type: Bug
>          Components: VFS
>    Affects Versions: 9.0.0.Beta2
>         Environment: Wildfly build from master on April 22, 2015
>            Reporter: Tom Fonteyne
>            Assignee: Tomaz Cerar
>         Attachments: bouncycastle.zip
>
>
> deploy a war file which contains the bouncycastle (or any other JCE) signed jar file. Initialise and try to use a cipher results in a failure due to VFS not being able to read and verify the file



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 12:05:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 25 Oct 2016 12:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4576) JCE jar file inside a
 deployment fails the signature check
In-Reply-To: <JIRA.12570510.1430488400000@Atlassian.JIRA>
References: <JIRA.12570510.1430488400000@Atlassian.JIRA>
	<JIRA.12570510.1430488400000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570510.1430488400000.2814.1477411500854@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-4576:
---------------------------------

    Assignee:     (was: Tomaz Cerar)


>  JCE jar file inside a deployment fails the signature check 
> ------------------------------------------------------------
>
>                 Key: WFLY-4576
>                 URL: https://issues.jboss.org/browse/WFLY-4576
>             Project: WildFly
>          Issue Type: Bug
>          Components: VFS
>    Affects Versions: 9.0.0.Beta2
>         Environment: Wildfly build from master on April 22, 2015
>            Reporter: Tom Fonteyne
>         Attachments: bouncycastle.zip
>
>
> deploy a war file which contains the bouncycastle (or any other JCE) signed jar file. Initialise and try to use a cipher results in a failure due to VFS not being able to read and verify the file



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 12:14:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 25 Oct 2016 12:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1695) Echo tab completion
 suggests variables without $ prefix
In-Reply-To: <JIRA.12641871.1470301165000@Atlassian.JIRA>
References: <JIRA.12641871.1470301165000@Atlassian.JIRA>
	<JIRA.12641871.1470301165000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641871.1470301165000.2900.1477412040218@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-1695:
--------------------------------------------

    Assignee: Jean-Francois Denise  (was: Alexey Loubyansky)


> Echo tab completion suggests variables without $ prefix
> -------------------------------------------------------
>
>                 Key: WFCORE-1695
>                 URL: https://issues.jboss.org/browse/WFCORE-1695
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Martin Schvarcbacher
>            Assignee: Jean-Francois Denise
>            Priority: Minor
>
> *Description:*
> echo command prints all variables in tab auto-complete even without typing $ prefix
> This duplicates functionality of 'set' with no arguments. 
> *Steps to reproduce*
> {code:bash}
> [disconnected /] set myvar1=value1
> [disconnected /] set myvar2=value2
> [disconnected /] set
> myvar1=value1
> myvar2=value2
> {code}
> *Actual*
> {code:bash}
> [disconnected /] echo <TAB>
> --help  myvar1  myvar2   #should not suggest variables
> [disconnected /] echo $<TAB>myvar<TAB> #expected, auto-completes with $prefix
> myvar1  myvar2  
> [disconnected /] echo myvar<TAB> #autocompletes variable without $prefix
> myvar1  myvar2  
> {code}
> *Expected*
> {code:bash}
> [disconnected /] echo <TAB>
> --help
> [disconnected /] echo $<TAB>myvar<TAB>
> myvar1  myvar2  
> [disconnected /] echo myvar<TAB> #does not suggest anything
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 12:30:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 25 Oct 2016 12:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1892) Support rejection-style
 testing for capabilities-enabled subsystem in test framework
In-Reply-To: <JIRA.12656791.1477412942000@Atlassian.JIRA>
References: <JIRA.12656791.1477412942000@Atlassian.JIRA>
	<JIRA.12656791.1477412942548@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656791.1477412942000.3060.1477413000486@Atlassian.JIRA>

Radoslav Husar created WFCORE-1892:
--------------------------------------

             Summary: Support rejection-style testing for capabilities-enabled subsystem in test framework
                 Key: WFCORE-1892
                 URL: https://issues.jboss.org/browse/WFCORE-1892
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Test Suite
    Affects Versions: 3.0.0.Alpha10
            Reporter: Radoslav Husar
            Assignee: Tomaz Cerar


Rejection-style transformer tests assumes each operation generated by parser can be executed on its own, outside of a batch This has been generally the case until introduction of capabilities. If a subsystem add operation references a capability introduced by subsequent add operations the rejection test cannot be bent over to pass. This is an issue of the test framework, during normal boot the operations are batched and this is not a problem.

An example of this can be found in the singleton subsystem:

/subsystem=singleton:add(default=mypolicy) 
/subsystem=singleton/singleton-policy=mypolicy:add(...)

I assume this will be more of a problem when testing EAP 7.2 to 7.1 transformations since there aren't many subsystems supporting capabilities in 7.0 apart from the singleton subsystem.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 12:30:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 25 Oct 2016 12:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1892) Support rejection-style
 testing for capabilities-enabled subsystem in test framework
In-Reply-To: <JIRA.12656791.1477412943000@Atlassian.JIRA>
References: <JIRA.12656791.1477412943000@Atlassian.JIRA>
	<JIRA.12656791.1477412943000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656791.1477412943000.3064.1477413000610@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFCORE-1892:
--------------------------------------

    Assignee: Kabir Khan  (was: Tomaz Cerar)


> Support rejection-style testing for capabilities-enabled subsystem in test framework
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1892
>                 URL: https://issues.jboss.org/browse/WFCORE-1892
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Radoslav Husar
>            Assignee: Kabir Khan
>
> Rejection-style transformer tests assumes each operation generated by parser can be executed on its own, outside of a batch This has been generally the case until introduction of capabilities. If a subsystem add operation references a capability introduced by subsequent add operations the rejection test cannot be bent over to pass. This is an issue of the test framework, during normal boot the operations are batched and this is not a problem.
> An example of this can be found in the singleton subsystem:
> /subsystem=singleton:add(default=mypolicy) 
> /subsystem=singleton/singleton-policy=mypolicy:add(...)
> I assume this will be more of a problem when testing EAP 7.2 to 7.1 transformations since there aren't many subsystems supporting capabilities in 7.0 apart from the singleton subsystem.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 12:36:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 25 Oct 2016 12:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7289) Adding ldap-key-store
 requires accessible ldap server
In-Reply-To: <JIRA.12654219.1476189896000@Atlassian.JIRA>
References: <JIRA.12654219.1476189896000@Atlassian.JIRA>
	<JIRA.12654219.1476189896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654219.1476189896000.3114.1477413360257@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311660#comment-13311660 ] 

Darran Lofthouse commented on WFLY-7289:
----------------------------------------

I have merged the pull request as it adds additional logging but there is still the problem that the server should be able to come up even if the LDAP server is unavailable.

> Adding ldap-key-store requires accessible ldap server
> -----------------------------------------------------
>
>                 Key: WFLY-7289
>                 URL: https://issues.jboss.org/browse/WFLY-7289
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Playing with ldap-key-store . What I consider very unconvenient is fact, that in moment of adding ldap-key-store, ldap server has to be running and accessible. Elytron ldap-realm does not need that. Doubt about legacy security realms. Is it possible to decouple that dependency and leave that check till first ldap-key-store usage?
> Steps to reproduce:
> {code}
> [standalone at localhost:9990 /] /subsystem=elytron/dir-context=a:add()
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=elytron/ldap-key-store=a:add(dir-context=a, search-path="a")
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> {code}
> leads to exception in server log
> {code}
> 14:37:25,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
>     "address" => [
>         ("subsystem" => "elytron"),
>         ("ldap-key-store" => "a")
>     ],
>     "operation" => "add",
>     "search-path" => "a",
>     "dir-context" => "a",
>     "operation-headers" => {
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE"
>     }
> }]: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> 	at java.security.KeyStore.size(KeyStore.java:1271)
> 	at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> 	at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> 	at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildTypes(AbstractModelResource.java:372)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> 	at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> 	at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:787)
> 	at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:520)
> 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:758)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:709)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> 	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 	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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: Cannot parse url: undefined [Root exception is java.net.MalformedURLException: Invalid URI: undefined]
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:92)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:163)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> 	at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> 	at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> 	at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> 	at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> 	at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> 	... 39 more
> Caused by: java.net.MalformedURLException: Invalid URI: undefined
> 	at com.sun.jndi.toolkit.url.Uri.parse(Uri.java:199)
> 	at com.sun.jndi.toolkit.url.Uri.init(Uri.java:138)
> 	at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:82)
> 	... 56 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 12:44:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 25 Oct 2016 12:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1583) Enhance a CLI logging
In-Reply-To: <JIRA.12630174.1465394384000@Atlassian.JIRA>
References: <JIRA.12630174.1465394384000@Atlassian.JIRA>
	<JIRA.12630174.1465394384000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12630174.1465394384000.3177.1477413840591@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-1583:
--------------------------------------------

    Assignee: Jean-Francois Denise


> Enhance a CLI logging
> ---------------------
>
>                 Key: WFCORE-1583
>                 URL: https://issues.jboss.org/browse/WFCORE-1583
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Jean-Francois Denise
>            Priority: Minor
>
> We should improve a logging capabilities of CLI. CLI logging is disabled by default, but it can be enabled by altering the jboss-cli-logging.properties.
> Here is my test scenario.
> {noformat}
> [pkremens at localhost bin]$ ./jboss-cli.sh -c
> [standalone at localhost:9990 /] /system-property=foo:add(value=bar bar)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] shutdown 
> {noformat}
> Set CLI logger level to ALL (logger.org.jboss.as.cli.level=ALL) to see all logs produced by CLI
> actual content of jboss-cli.log - only server response is logged
> {noformat}
> 13:45:48,041 DEBUG [org.jboss.as.cli.CommandContext] connecting to localhost:9990 as null
> 13:46:04,033 INFO  [org.jboss.as.cli.CommandContext] {"outcome" => "success"}
> {noformat}
> I can imagine content like following could be helpful for troubleshooting
> {noformat}
> ...
> <TIME> <LEVEL>  [org.jboss.as.cli.CommandContext] /system-property=foo:add(value=bar bar)
> {
>     "address" => [("system-property" => "foo")],
>     "operation" => "add",
>     "value" => "barbar"
> }
> <TIME> <LEVEL>  [org.jboss.as.cli.CommandContext] {"outcome" => "success"}
> {noformat}
> AFAICT the only possibility to get the actual CLI requests in raw form is to map the content of $HOME/.jboss-cli-history file with configuration history or audit log now.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 13:20:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 25 Oct 2016 13:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-790) CLI Does Not Log History
 With "--file" and "--command(s)" args
In-Reply-To: <JIRA.12576881.1435835622000@Atlassian.JIRA>
References: <JIRA.12576881.1435835622000@Atlassian.JIRA>
	<JIRA.12576881.1435835622000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576881.1435835622000.3287.1477416000677@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-790:
-------------------------------------------

    Assignee: Jean-Francois Denise  (was: Alexey Loubyansky)


>  CLI Does Not Log History With "--file" and "--command(s)" args
> ---------------------------------------------------------------
>
>                 Key: WFCORE-790
>                 URL: https://issues.jboss.org/browse/WFCORE-790
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha5
>            Reporter: Petr Kremensky
>            Assignee: Jean-Francois Denise
>
> Cli doesn't log commands passed by  "\-\-file" and "\-\-command(s)" arguments.
> https://bugzilla.redhat.com/show_bug.cgi?id=1232890



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 13:27:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 25 Oct 2016 13:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-790) CLI Does Not Log History
 With "--file" and "--command(s)" args
In-Reply-To: <JIRA.12576881.1435835622000@Atlassian.JIRA>
References: <JIRA.12576881.1435835622000@Atlassian.JIRA>
	<JIRA.12576881.1435835622000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576881.1435835622000.3299.1477416420271@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311680#comment-13311680 ] 

Jean-Francois Denise commented on WFCORE-790:
---------------------------------------------

Whatever the Aesh/CLI design issue, I think that history means interactive. If we want it for non interactive, a user should have to tweak his script to enable it. 
We could imagine that a script containing the command history --enable would force the history to be updated.

>  CLI Does Not Log History With "--file" and "--command(s)" args
> ---------------------------------------------------------------
>
>                 Key: WFCORE-790
>                 URL: https://issues.jboss.org/browse/WFCORE-790
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 2.0.0.Alpha5
>            Reporter: Petr Kremensky
>            Assignee: Jean-Francois Denise
>
> Cli doesn't log commands passed by  "\-\-file" and "\-\-command(s)" arguments.
> https://bugzilla.redhat.com/show_bug.cgi?id=1232890



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 13:31:00 2016
From: issues at jboss.org (Tobias Stadler (JIRA))
Date: Tue, 25 Oct 2016 13:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7375) Upgrade Netty to 4.0.42.FINAL
In-Reply-To: <JIRA.12656796.1477416604000@Atlassian.JIRA>
References: <JIRA.12656796.1477416604000@Atlassian.JIRA>
	<JIRA.12656796.1477416604749@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656796.1477416604000.3317.1477416660178@Atlassian.JIRA>

Tobias Stadler created WFLY-7375:
------------------------------------

             Summary: Upgrade Netty to 4.0.42.FINAL
                 Key: WFLY-7375
                 URL: https://issues.jboss.org/browse/WFLY-7375
             Project: WildFly
          Issue Type: Component Upgrade
          Components: JMS
    Affects Versions: 10.1.0.Final
            Reporter: Tobias Stadler
            Assignee: Jeff Mesnil


Upgrade Netty to 4.0.42.FINAL,



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 13:40:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 25 Oct 2016 13:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.3352.1477417200271@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311686#comment-13311686 ] 

Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------

Hi Hisanobu,
I have commented on your PR saying that we had understood the issue and that I was Ok with this fix being merged.
Regards.
JF


> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 13:58:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 25 Oct 2016 13:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7367) add per PU cache of the new
 temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12656172.1477066573000@Atlassian.JIRA>
References: <JIRA.12656172.1477066573000@Atlassian.JIRA>
	<JIRA.12656172.1477066573000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656172.1477066573000.3408.1477418280163@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311695#comment-13311695 ] 

Scott Marlow commented on WFLY-7367:
------------------------------------

[https://java.net/projects/jpa-spec/lists/users/archive/2016-10/message/1] proposes a change to allow the new temp classloader to be cached per persistence unit (for the scope of the createContainerEntityManagerFactory() call).

> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7367
>                 URL: https://issues.jboss.org/browse/WFLY-7367
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.
> Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
>     temporary ClassLoader with same visibility as current loader 
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 16:43:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 16:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7376) The ServletResourceManager
 hard codes the safe symlink paths as '/'
In-Reply-To: <JIRA.12656806.1477428126000@Atlassian.JIRA>
References: <JIRA.12656806.1477428126000@Atlassian.JIRA>
	<JIRA.12656806.1477428126366@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656806.1477428126000.3640.1477428180255@Atlassian.JIRA>

Stuart Douglas created WFLY-7376:
------------------------------------

             Summary: The ServletResourceManager hard codes the safe symlink paths as '/'
                 Key: WFLY-7376
                 URL: https://issues.jboss.org/browse/WFLY-7376
             Project: WildFly
          Issue Type: Bug
            Reporter: Stuart Douglas
            Assignee: Jason Greene


This causes problems on windows



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 16:43:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 16:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7377) The ServletResourceManager
 hard codes the safe symlink paths as '/'
In-Reply-To: <JIRA.12656807.1477428137000@Atlassian.JIRA>
References: <JIRA.12656807.1477428137000@Atlassian.JIRA>
	<JIRA.12656807.1477428137994@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656807.1477428137000.3643.1477428180349@Atlassian.JIRA>

Stuart Douglas created WFLY-7377:
------------------------------------

             Summary: The ServletResourceManager hard codes the safe symlink paths as '/'
                 Key: WFLY-7377
                 URL: https://issues.jboss.org/browse/WFLY-7377
             Project: WildFly
          Issue Type: Bug
            Reporter: Stuart Douglas
            Assignee: Jason Greene


This causes problems on windows



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 16:43:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 16:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7377) The ServletResourceManager
 hard codes the safe symlink paths as '/'
In-Reply-To: <JIRA.12656807.1477428138000@Atlassian.JIRA>
References: <JIRA.12656807.1477428138000@Atlassian.JIRA>
	<JIRA.12656807.1477428138000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656807.1477428138000.3647.1477428180486@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-7377:
------------------------------------

    Component/s: Web (Undertow)
       Assignee: Stuart Douglas  (was: Jason Greene)


> The ServletResourceManager hard codes the safe symlink paths as '/'
> -------------------------------------------------------------------
>
>                 Key: WFLY-7377
>                 URL: https://issues.jboss.org/browse/WFLY-7377
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This causes problems on windows



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 16:43:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 16:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7376) The ServletResourceManager
 hard codes the safe symlink paths as '/'
In-Reply-To: <JIRA.12656806.1477428126000@Atlassian.JIRA>
References: <JIRA.12656806.1477428126000@Atlassian.JIRA>
	<JIRA.12656806.1477428126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656806.1477428126000.3651.1477428180550@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-7376:
------------------------------------

    Component/s: Web (Undertow)
       Assignee: Stuart Douglas  (was: Jason Greene)


> The ServletResourceManager hard codes the safe symlink paths as '/'
> -------------------------------------------------------------------
>
>                 Key: WFLY-7376
>                 URL: https://issues.jboss.org/browse/WFLY-7376
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This causes problems on windows



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 19:59:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 19:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7378) HTTP/2 is still enabled even
 if JCE is not installed
In-Reply-To: <JIRA.12656816.1477439902000@Atlassian.JIRA>
References: <JIRA.12656816.1477439902000@Atlassian.JIRA>
	<JIRA.12656816.1477439902716@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656816.1477439902000.3858.1477439940221@Atlassian.JIRA>

Stuart Douglas created WFLY-7378:
------------------------------------

             Summary: HTTP/2 is still enabled even if JCE is not installed
                 Key: WFLY-7378
                 URL: https://issues.jboss.org/browse/WFLY-7378
             Project: WildFly
          Issue Type: Bug
            Reporter: Stuart Douglas
            Assignee: Jason Greene


This results in connection errors when using h2 as no strong ciphers are installed



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 19:59:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 19:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7378) HTTP/2 is still enabled even
 if JCE is not installed
In-Reply-To: <JIRA.12656816.1477439903000@Atlassian.JIRA>
References: <JIRA.12656816.1477439903000@Atlassian.JIRA>
	<JIRA.12656816.1477439903000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656816.1477439903000.3862.1477439940322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-7378:
---------------------------------
    Component/s: Web (Undertow)


> HTTP/2 is still enabled even if JCE is not installed
> ----------------------------------------------------
>
>                 Key: WFLY-7378
>                 URL: https://issues.jboss.org/browse/WFLY-7378
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Jason Greene
>
> This results in connection errors when using h2 as no strong ciphers are installed



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 19:59:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 19:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7378) HTTP/2 is still enabled even
 if JCE is not installed
In-Reply-To: <JIRA.12656816.1477439903000@Atlassian.JIRA>
References: <JIRA.12656816.1477439903000@Atlassian.JIRA>
	<JIRA.12656816.1477439903000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656816.1477439903000.3866.1477439940401@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-7378:
------------------------------------

    Assignee: Stuart Douglas  (was: Jason Greene)


> HTTP/2 is still enabled even if JCE is not installed
> ----------------------------------------------------
>
>                 Key: WFLY-7378
>                 URL: https://issues.jboss.org/browse/WFLY-7378
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This results in connection errors when using h2 as no strong ciphers are installed



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 20:26:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 20:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7379) HTTP/2 is still enabled even
 if JCE is not installed
In-Reply-To: <JIRA.12656818.1477441525000@Atlassian.JIRA>
References: <JIRA.12656818.1477441525000@Atlassian.JIRA>
	<JIRA.12656818.1477441525433@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656818.1477441525000.3870.1477441560233@Atlassian.JIRA>

Stuart Douglas created WFLY-7379:
------------------------------------

             Summary: HTTP/2 is still enabled even if JCE is not installed
                 Key: WFLY-7379
                 URL: https://issues.jboss.org/browse/WFLY-7379
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


This results in connection errors when using h2 as no strong ciphers are installed



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 20:52:00 2016
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Tue, 25 Oct 2016 20:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7380) windows service (service.bat)
 failed to install if the value of /serviceuser has a white space inside
In-Reply-To: <JIRA.12656819.1477443070000@Atlassian.JIRA>
References: <JIRA.12656819.1477443070000@Atlassian.JIRA>
	<JIRA.12656819.1477443070099@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656819.1477443070000.3888.1477443120217@Atlassian.JIRA>

Brad Maxwell created WFLY-7380:
----------------------------------

             Summary: windows service (service.bat) failed to install if the value of /serviceuser has a white space inside
                 Key: WFLY-7380
                 URL: https://issues.jboss.org/browse/WFLY-7380
             Project: WildFly
          Issue Type: Bug
          Components: Scripts
    Affects Versions: 10.1.0.Final
            Reporter: Brad Maxwell
            Assignee: Tomaz Cerar
            Priority: Minor


When using "service.bat install /serviceuser ..." command to install window service, if the account name behind /serviceuser has a whit space inside like ".\JBoss User", it will failed to install windows service.

Run command: service.bat install /serviceuser ".\JBoss User" /servicepass "change it" /startup /debug

When starting it, an error window poped up:
{code}
Windows could not start the JBossEAP6 on Local Computer.
For more information, review the System Event Log. 
If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1.
{code}

Additional info:
Possible fix is editing "service.bat" and add double quotation marks on %SERVICE_USER% 

>From 
{code}
set RUNAS=--ServiceUser=%SERVICE_USER% --ServicePassword=%SERVICE_PASS%
{code}

to
{code}
set RUNAS=--ServiceUser="%SERVICE_USER%" --ServicePassword="%SERVICE_PASS%"
{code}




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 20:53:00 2016
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Tue, 25 Oct 2016 20:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7381) [GSS](7.1.0) windows service
 (service.bat) failed to install if the value of /serviceuser has a white
 space inside
In-Reply-To: <JIRA.12656820.1477443121000@Atlassian.JIRA>
References: <JIRA.12656820.1477443121000@Atlassian.JIRA>
	<JIRA.12656820.1477443121628@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656820.1477443121000.3891.1477443180378@Atlassian.JIRA>

Brad Maxwell created WFLY-7381:
----------------------------------

             Summary: [GSS](7.1.0) windows service (service.bat) failed to install if the value of /serviceuser has a white space inside
                 Key: WFLY-7381
                 URL: https://issues.jboss.org/browse/WFLY-7381
             Project: WildFly
          Issue Type: Bug
          Components: Scripts
    Affects Versions: 10.1.0.Final
            Reporter: Brad Maxwell
            Assignee: Tomaz Cerar
            Priority: Minor


When using "service.bat install /serviceuser ..." command to install window service, if the account name behind /serviceuser has a whit space inside like ".\JBoss User", it will failed to install windows service.

Run command: service.bat install /serviceuser ".\JBoss User" /servicepass "change it" /startup /debug

When starting it, an error window poped up:
{code}
Windows could not start the JBossEAP6 on Local Computer.
For more information, review the System Event Log. 
If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1.
{code}

Additional info:
Possible fix is editing "service.bat" and add double quotation marks on %SERVICE_USER% 

>From 
{code}
set RUNAS=--ServiceUser=%SERVICE_USER% --ServicePassword=%SERVICE_PASS%
{code}

to
{code}
set RUNAS=--ServiceUser="%SERVICE_USER%" --ServicePassword="%SERVICE_PASS%"
{code}




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 23:50:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 23:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1893) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657010.1477453793000@Atlassian.JIRA>
References: <JIRA.12657010.1477453793000@Atlassian.JIRA>
	<JIRA.12657010.1477453793770@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657010.1477453793000.1.1477453800739@Atlassian.JIRA>

Stuart Douglas created WFCORE-1893:
--------------------------------------

             Summary: Build tools 1.1.7.Final
                 Key: WFCORE-1893
                 URL: https://issues.jboss.org/browse/WFCORE-1893
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 23:51:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 23:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1893) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657010.1477453794000@Atlassian.JIRA>
References: <JIRA.12657010.1477453794000@Atlassian.JIRA>
	<JIRA.12657010.1477453794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657010.1477453794000.3.1477453860165@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFCORE-1893:
--------------------------------------

    Assignee: Stuart Douglas


> Build tools 1.1.7.Final
> -----------------------
>
>                 Key: WFCORE-1893
>                 URL: https://issues.jboss.org/browse/WFCORE-1893
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 23:52:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 23:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1894) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657011.1477453897000@Atlassian.JIRA>
References: <JIRA.12657011.1477453897000@Atlassian.JIRA>
	<JIRA.12657011.1477453897909@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657011.1477453897000.5.1477453920093@Atlassian.JIRA>

Stuart Douglas created WFCORE-1894:
--------------------------------------

             Summary: Build tools 1.1.7.Final
                 Key: WFCORE-1894
                 URL: https://issues.jboss.org/browse/WFCORE-1894
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 23:53:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 23:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7382) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657011.1477453898000@Atlassian.JIRA>
References: <JIRA.12657011.1477453898000@Atlassian.JIRA>
	<JIRA.12657011.1477453898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657011.1477453898000.7.1477453980094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved WFCORE-1894 to WFLY-7382:
----------------------------------------------

    Project: WildFly  (was: WildFly Core)
        Key: WFLY-7382  (was: WFCORE-1894)


> Build tools 1.1.7.Final
> -----------------------
>
>                 Key: WFLY-7382
>                 URL: https://issues.jboss.org/browse/WFLY-7382
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Tue Oct 25 23:54:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 25 Oct 2016 23:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7383) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657012.1477454002000@Atlassian.JIRA>
References: <JIRA.12657012.1477454002000@Atlassian.JIRA>
	<JIRA.12657012.1477454002476@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657012.1477454002000.9.1477454040164@Atlassian.JIRA>

Stuart Douglas created WFLY-7383:
------------------------------------

             Summary: Build tools 1.1.7.Final
                 Key: WFLY-7383
                 URL: https://issues.jboss.org/browse/WFLY-7383
             Project: WildFly
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 00:34:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Oct 2016 00:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1895) Undertow 1.4.4.Final
In-Reply-To: <JIRA.12657014.1477456397000@Atlassian.JIRA>
References: <JIRA.12657014.1477456397000@Atlassian.JIRA>
	<JIRA.12657014.1477456397147@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657014.1477456397000.29.1477456440532@Atlassian.JIRA>

Stuart Douglas created WFCORE-1895:
--------------------------------------

             Summary: Undertow 1.4.4.Final
                 Key: WFCORE-1895
                 URL: https://issues.jboss.org/browse/WFCORE-1895
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 00:34:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Oct 2016 00:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1895) Undertow 1.4.4.Final
In-Reply-To: <JIRA.12657014.1477456397000@Atlassian.JIRA>
References: <JIRA.12657014.1477456397000@Atlassian.JIRA>
	<JIRA.12657014.1477456397000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657014.1477456397000.32.1477456440650@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFCORE-1895:
--------------------------------------

    Assignee: Stuart Douglas


> Undertow 1.4.4.Final
> --------------------
>
>                 Key: WFCORE-1895
>                 URL: https://issues.jboss.org/browse/WFCORE-1895
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 01:13:00 2016
From: issues at jboss.org (Chao Wang (JIRA))
Date: Wed, 26 Oct 2016 01:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1333) Add protection in
 DsXmlDeployer to prevent from loading xml resource
In-Reply-To: <JIRA.12651995.1474902143000@Atlassian.JIRA>
References: <JIRA.12651995.1474902143000@Atlassian.JIRA>
	<JIRA.12651995.1474902143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651995.1474902143000.85.1477458780258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated JBJCA-1333:
-----------------------------
    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/576, https://github.com/ironjacamar/ironjacamar/pull/580  (was: https://github.com/ironjacamar/ironjacamar/pull/576)


> Add protection in DsXmlDeployer to prevent from loading xml resource
> --------------------------------------------------------------------
>
>                 Key: JBJCA-1333
>                 URL: https://issues.jboss.org/browse/JBJCA-1333
>             Project: IronJacamar
>          Issue Type: Enhancement
>          Components: Deployer
>    Affects Versions: 1.2.7.Final
>            Reporter: COLLIGNON Thomas
>            Assignee: Stefano Maestri
>            Priority: Minor
>             Fix For: 1.2.8.Final
>
>
> If we place a datasource.xml in a jar file, the class DsXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
> The goal of this issue is prevent for loading jar file in DsXmlDeployer.
> The second goal is to provide ability of overring DsXmlDeployer in custom deployer who extends this class.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 01:14:00 2016
From: issues at jboss.org (Chao Wang (JIRA))
Date: Wed, 26 Oct 2016 01:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1333) Add protection in
 DsXmlDeployer to prevent from loading xml resource
In-Reply-To: <JIRA.12651995.1474902143000@Atlassian.JIRA>
References: <JIRA.12651995.1474902143000@Atlassian.JIRA>
	<JIRA.12651995.1474902143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651995.1474902143000.90.1477458840345@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated JBJCA-1333:
-----------------------------
    Fix Version/s: WildFly/IronJacamar 1.3.5.Final


> Add protection in DsXmlDeployer to prevent from loading xml resource
> --------------------------------------------------------------------
>
>                 Key: JBJCA-1333
>                 URL: https://issues.jboss.org/browse/JBJCA-1333
>             Project: IronJacamar
>          Issue Type: Enhancement
>          Components: Deployer
>    Affects Versions: 1.2.7.Final
>            Reporter: COLLIGNON Thomas
>            Assignee: Stefano Maestri
>            Priority: Minor
>             Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> If we place a datasource.xml in a jar file, the class DsXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
> The goal of this issue is prevent for loading jar file in DsXmlDeployer.
> The second goal is to provide ability of overring DsXmlDeployer in custom deployer who extends this class.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 01:19:00 2016
From: issues at jboss.org (Chao Wang (JIRA))
Date: Wed, 26 Oct 2016 01:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1335) Add protection in
 RaXmlDeployer to prevent from loading xml resource
In-Reply-To: <JIRA.12652842.1475249080000@Atlassian.JIRA>
References: <JIRA.12652842.1475249080000@Atlassian.JIRA>
	<JIRA.12652842.1475249080000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652842.1475249080000.96.1477459140310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated JBJCA-1335:
-----------------------------
    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/584, https://github.com/ironjacamar/ironjacamar/pull/583  (was: https://github.com/ironjacamar/ironjacamar/pull/584)


> Add protection in RaXmlDeployer to prevent from loading xml resource
> --------------------------------------------------------------------
>
>                 Key: JBJCA-1335
>                 URL: https://issues.jboss.org/browse/JBJCA-1335
>             Project: IronJacamar
>          Issue Type: Enhancement
>          Components: Deployer
>    Affects Versions: 1.2.7.Final
>            Reporter: COLLIGNON Thomas
>            Priority: Minor
>             Fix For: 1.2.8.Final
>
>
> If we place a -ra.xml in jar file, the class RaXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
> The goal of this issue is prevent for loading jar file in RaXmlDeployer .
> The second goal is to provide ability of overring RaXmlDeployer in custom deployer who extends this class.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 02:21:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 26 Oct 2016 02:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-688) Elytron Properties realm parses
 password with "=" incorrectly
In-Reply-To: <JIRA.12656257.1477289469000@Atlassian.JIRA>
References: <JIRA.12656257.1477289469000@Atlassian.JIRA>
	<JIRA.12656257.1477289469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656257.1477289469000.202.1477462860257@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas moved WFLY-7369 to ELY-688:
----------------------------------------

        Project: WildFly Elytron  (was: WildFly)
            Key: ELY-688  (was: WFLY-7369)
    Component/s: Realms
                     (was: Security)


> Elytron Properties realm parses password with "=" incorrectly
> -------------------------------------------------------------
>
>                 Key: ELY-688
>                 URL: https://issues.jboss.org/browse/ELY-688
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Dmitrii Tikhomirov
>
> In case when Elytron properties-realm uses plain-text properties file and password includes {{=}} sign then username/password is parsing incorrectly. In case when properties file contains line as {{A=B=C}} then Elytron parses it as user {{A=B}} with password {{C}}. Correct behavior should be user {{A}} with password {{B=C}}.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 02:22:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 26 Oct 2016 02:22:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-688) Elytron Properties realm parses
 password with "=" incorrectly
In-Reply-To: <JIRA.12656257.1477289469000@Atlassian.JIRA>
References: <JIRA.12656257.1477289469000@Atlassian.JIRA>
	<JIRA.12656257.1477289469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656257.1477289469000.207.1477462920233@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-688:
-----------------------------
    Affects Version/s: 1.1.0.Beta11


> Elytron Properties realm parses password with "=" incorrectly
> -------------------------------------------------------------
>
>                 Key: ELY-688
>                 URL: https://issues.jboss.org/browse/ELY-688
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Dmitrii Tikhomirov
>
> In case when Elytron properties-realm uses plain-text properties file and password includes {{=}} sign then username/password is parsing incorrectly. In case when properties file contains line as {{A=B=C}} then Elytron parses it as user {{A=B}} with password {{C}}. Correct behavior should be user {{A}} with password {{B=C}}.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 02:38:00 2016
From: issues at jboss.org (Emmanuel Bernard (JIRA))
Date: Wed, 26 Oct 2016 02:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.256.1477463880447@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311934#comment-13311934 ] 

Emmanuel Bernard commented on WFLY-6854:
----------------------------------------

Do we have a go?

BTW these requirement documents are nice when you start thinking about the feature but here Hibernate works differently, we do things much more iteratively and retro explaining everything would be a waste of energy. EAP7-582 explains very well our main reasons I think.

> Upgrade Hibernate ORM to 5.1.3 
> -------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 02:48:00 2016
From: issues at jboss.org (Chao Wang (JIRA))
Date: Wed, 26 Oct 2016 02:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1335) Add protection in
 RaXmlDeployer to prevent from loading xml resource
In-Reply-To: <JIRA.12652842.1475249080000@Atlassian.JIRA>
References: <JIRA.12652842.1475249080000@Atlassian.JIRA>
	<JIRA.12652842.1475249080000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652842.1475249080000.287.1477464480341@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated JBJCA-1335:
-----------------------------
    Fix Version/s: WildFly/IronJacamar 1.3.5.Final


> Add protection in RaXmlDeployer to prevent from loading xml resource
> --------------------------------------------------------------------
>
>                 Key: JBJCA-1335
>                 URL: https://issues.jboss.org/browse/JBJCA-1335
>             Project: IronJacamar
>          Issue Type: Enhancement
>          Components: Deployer
>    Affects Versions: 1.2.7.Final
>            Reporter: COLLIGNON Thomas
>            Priority: Minor
>             Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> If we place a -ra.xml in jar file, the class RaXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
> The goal of this issue is prevent for loading jar file in RaXmlDeployer .
> The second goal is to provide ability of overring RaXmlDeployer in custom deployer who extends this class.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 03:49:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 26 Oct 2016 03:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7384) Removal of
 messaging-activemq's server stops Infinispan services
In-Reply-To: <JIRA.12657028.1477468104000@Atlassian.JIRA>
References: <JIRA.12657028.1477468104000@Atlassian.JIRA>
	<JIRA.12657028.1477468104360@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657028.1477468104000.524.1477468140167@Atlassian.JIRA>

Jeff Mesnil created WFLY-7384:
---------------------------------

             Summary: Removal of messaging-activemq's server stops Infinispan services
                 Key: WFLY-7384
                 URL: https://issues.jboss.org/browse/WFLY-7384
             Project: WildFly
          Issue Type: Bug
          Components: Clustering, JMS
            Reporter: Jeff Mesnil
            Assignee: Paul Ferraro


This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.

When I run the command to remove the server:

/subsystem=messaging-activemq/server=default:remove

I see logs in the app server about Infinispan services being stopped:

{noformat}
09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
09:28:46,381 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
{noformat}

There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
However both messaging-activemq and infinispan resources depends on JGroups resources.

I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:

{noformat}
Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
{noformat}

The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:

{noformat}
Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
{noformat}

After removing the messaging server, this service is in the state:

{noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
{noformat}

I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 03:51:01 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 26 Oct 2016 03:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7384) Removal of
 messaging-activemq's server stops Infinispan services
In-Reply-To: <JIRA.12657028.1477468104000@Atlassian.JIRA>
References: <JIRA.12657028.1477468104000@Atlassian.JIRA>
	<JIRA.12657028.1477468104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657028.1477468104000.553.1477468261335@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-7384:
------------------------------
    Attachment: WFLY-7384.diff


> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
>                 Key: WFLY-7384
>                 URL: https://issues.jboss.org/browse/WFLY-7384
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Paul Ferraro
>         Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 03:51:02 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 26 Oct 2016 03:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7384) Removal of
 messaging-activemq's server stops Infinispan services
In-Reply-To: <JIRA.12657028.1477468104000@Atlassian.JIRA>
References: <JIRA.12657028.1477468104000@Atlassian.JIRA>
	<JIRA.12657028.1477468104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657028.1477468104000.569.1477468262335@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311965#comment-13311965 ] 

Jeff Mesnil commented on WFLY-7384:
-----------------------------------

This issue occurs after I fixed WFLY-7333 (not merged in master branch yet)

> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
>                 Key: WFLY-7384
>                 URL: https://issues.jboss.org/browse/WFLY-7384
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Paul Ferraro
>         Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 03:54:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 26 Oct 2016 03:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7384) Removal of
 messaging-activemq's server stops Infinispan services
In-Reply-To: <JIRA.12657028.1477468104000@Atlassian.JIRA>
References: <JIRA.12657028.1477468104000@Atlassian.JIRA>
	<JIRA.12657028.1477468104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657028.1477468104000.583.1477468440399@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311967#comment-13311967 ] 

Jeff Mesnil commented on WFLY-7384:
-----------------------------------

[~pferraro] I am not sure where this issue is coming from. I don't think it's in the messaging subsystem (after I cleanly remove its resources and stop its services). But I don't know if that's an issue with the MSC or with the states of Infinispan/JGroups services. Could you have a look, please?

> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
>                 Key: WFLY-7384
>                 URL: https://issues.jboss.org/browse/WFLY-7384
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Paul Ferraro
>         Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 03:59:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 26 Oct 2016 03:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-676) There isn't possible change
 value for given alias in Credential Store over CLI.
In-Reply-To: <JIRA.12655904.1476970185000@Atlassian.JIRA>
References: <JIRA.12655904.1476970185000@Atlassian.JIRA>
	<JIRA.12655904.1476970185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655904.1476970185000.591.1477468740179@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13311970#comment-13311970 ] 

Hynek ?v?bek commented on ELY-676:
----------------------------------

[~ctomc] No, it doesn't work too. CLI command passed but credentialstore.jceks isn't updated.

> There isn't possible change value for given alias in Credential Store over CLI.
> -------------------------------------------------------------------------------
>
>                 Key: ELY-676
>                 URL: https://issues.jboss.org/browse/ELY-676
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> There isn't possible change value for given alias in Credential Store over CLI.
> I expected something like this
> {code}
> /subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Wed Oct 26 05:05:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 26 Oct 2016 05:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-689) CLI - between operations REMOVE
 and ADD CredentialStore alias is needed reload
In-Reply-To: <JIRA.12657040.1477472637000@Atlassian.JIRA>
References: <JIRA.12657040.1477472637000@Atlassian.JIRA>
	<JIRA.12657040.1477472637000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657040.1477472637000.992.1477472700143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek moved JBEAP-6631 to ELY-689:
-----------------------------------------

              Project: WildFly Elytron  (was: JBoss Enterprise Application Platform)
                  Key: ELY-689  (was: JBEAP-6631)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Credential Store
                           (was: Security)
    Affects Version/s: 1.1.0.Beta11
                           (was: 7.1.0.DR7)


> CLI - between operations REMOVE and ADD CredentialStore alias is needed reload
> ------------------------------------------------------------------------------
>
>                 Key: ELY-689
>                 URL: https://issues.jboss.org/browse/ELY-689
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> If I want remove entry from credential store and immediately I try to add new entry with same alias then I get error message
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource csAlias001",
>     "rolled-back" => true
> }
> {code}
> In case of reload after remove operation then adding entry with same alias passes.
> I cannot see any information about reload-required after executing remove operation. 
> {code}
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> {code}
> My suggestions
> # add there information about reload-required
> OR
> # fix it so it will not be necessary reload
> In my opinion second option is better.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Wed Oct 26 05:46:00 2016
From: issues at jboss.org (Michal Jurc (JIRA))
Date: Wed, 26 Oct 2016 05:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1896) Deployment operation
 browse-content(archive=true) does not return archives in archived
 deployments
In-Reply-To: <JIRA.12657045.1477475091000@Atlassian.JIRA>
References: <JIRA.12657045.1477475091000@Atlassian.JIRA>
	<JIRA.12657045.1477475091000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657045.1477475091000.1255.1477475160211@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Jurc moved JBEAP-6633 to WFCORE-1896:
--------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-1896  (was: JBEAP-6633)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s: 3.0.0.Alpha10
                           (was: 7.1.0.DR6)
                           (was: 7.1.0.DR7)


> Deployment operation browse-content(archive=true) does not return archives in archived deployments
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1896
>                 URL: https://issues.jboss.org/browse/WFCORE-1896
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Michal Jurc
>            Assignee: ehsavoie Hugonnet
>
> Deployment operation browse-content(archive=true) does not return archives in archived deployments:
> {code}[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content()
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/maven/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         }
>     ]
> }
> [standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         }
>     ]
> }
> {code}
> It works correctly with exploded deployments:
> {code}[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         }
>     ]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 05:47:00 2016
From: issues at jboss.org (Michal Jurc (JIRA))
Date: Wed, 26 Oct 2016 05:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1896) Deployment operation
 browse-content(archive=true) does not return archives in archived
 deployments
In-Reply-To: <JIRA.12657045.1477475091000@Atlassian.JIRA>
References: <JIRA.12657045.1477475091000@Atlassian.JIRA>
	<JIRA.12657045.1477475091000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657045.1477475091000.1258.1477475220646@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Jurc updated WFCORE-1896:
--------------------------------
    Description: 
Deployment operation browse-content(archive=true) does not return archives in archived deployments:
{code}[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content()
{
    "outcome" => "success",
    "result" => [
        {
            "path" => "jboss-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63190L
        },
        {
            "path" => "jboss-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12256L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
            "directory" => false,
            "file-size" => 5582L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
            "directory" => false,
            "file-size" => 143L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/",
            "directory" => true
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/",
            "directory" => true
        },
        {
            "path" => "META-INF/maven/",
            "directory" => true
        },
        {
            "path" => "META-INF/MANIFEST.MF",
            "directory" => false,
            "file-size" => 130L
        },
        {
            "path" => "META-INF/application.xml",
            "directory" => false,
            "file-size" => 802L
        },
        {
            "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
            "directory" => false,
            "file-size" => 1955L
        },
        {
            "path" => "META-INF/",
            "directory" => true
        }
    ]
}
[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
{"outcome" => "success"}
{code}
It works correctly with exploded deployments:
{code}[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
{"outcome" => "success"}
[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
{"outcome" => "success"}
[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
{"outcome" => "success"}
[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
{
    "outcome" => "success",
    "result" => [
        {
            "path" => "jboss-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63190L
        },
        {
            "path" => "jboss-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12256L
        }
    ]
}
{code}

  was:
Deployment operation browse-content(archive=true) does not return archives in archived deployments:
{code}[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content()
{
    "outcome" => "success",
    "result" => [
        {
            "path" => "jboss-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63190L
        },
        {
            "path" => "jboss-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12256L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
            "directory" => false,
            "file-size" => 5582L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
            "directory" => false,
            "file-size" => 143L
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/",
            "directory" => true
        },
        {
            "path" => "META-INF/maven/org.jboss.quickstarts.eap/",
            "directory" => true
        },
        {
            "path" => "META-INF/maven/",
            "directory" => true
        },
        {
            "path" => "META-INF/MANIFEST.MF",
            "directory" => false,
            "file-size" => 130L
        },
        {
            "path" => "META-INF/application.xml",
            "directory" => false,
            "file-size" => 802L
        },
        {
            "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
            "directory" => false,
            "file-size" => 1955L
        },
        {
            "path" => "META-INF/",
            "directory" => true
        }
    ]
}
[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
{
    "outcome" => "success",
    "result" => [
        {
            "path" => "jboss-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63190L
        },
        {
            "path" => "jboss-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12256L
        }
    ]
}
{code}
It works correctly with exploded deployments:
{code}[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
{"outcome" => "success"}
[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
{"outcome" => "success"}
[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
{"outcome" => "success"}
[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
{
    "outcome" => "success",
    "result" => [
        {
            "path" => "jboss-kitchensink-ear-web.war",
            "directory" => false,
            "file-size" => 63190L
        },
        {
            "path" => "jboss-kitchensink-ear-ejb.jar",
            "directory" => false,
            "file-size" => 12256L
        }
    ]
}
{code}



> Deployment operation browse-content(archive=true) does not return archives in archived deployments
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1896
>                 URL: https://issues.jboss.org/browse/WFCORE-1896
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Michal Jurc
>            Assignee: ehsavoie Hugonnet
>
> Deployment operation browse-content(archive=true) does not return archives in archived deployments:
> {code}[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content()
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml",
>             "directory" => false,
>             "file-size" => 5582L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties",
>             "directory" => false,
>             "file-size" => 143L
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/maven/org.jboss.quickstarts.eap/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/maven/",
>             "directory" => true
>         },
>         {
>             "path" => "META-INF/MANIFEST.MF",
>             "directory" => false,
>             "file-size" => 130L
>         },
>         {
>             "path" => "META-INF/application.xml",
>             "directory" => false,
>             "file-size" => 802L
>         },
>         {
>             "path" => "META-INF/kitchensink-ear-quickstart-ds.xml",
>             "directory" => false,
>             "file-size" => 1955L
>         },
>         {
>             "path" => "META-INF/",
>             "directory" => true
>         }
>     ]
> }
> [standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
> {"outcome" => "success"}
> {code}
> It works correctly with exploded deployments:
> {code}[standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:browse-content(archive=true)
> {
>     "outcome" => "success",
>     "result" => [
>         {
>             "path" => "jboss-kitchensink-ear-web.war",
>             "directory" => false,
>             "file-size" => 63190L
>         },
>         {
>             "path" => "jboss-kitchensink-ear-ejb.jar",
>             "directory" => false,
>             "file-size" => 12256L
>         }
>     ]
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 05:47:01 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 26 Oct 2016 05:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-676) There isn't possible change
 value for given alias in Credential Store over CLI.
In-Reply-To: <JIRA.12655904.1476970185000@Atlassian.JIRA>
References: <JIRA.12655904.1476970185000@Atlassian.JIRA>
	<JIRA.12655904.1476970185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655904.1476970185000.1268.1477475221073@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-676:
-----------------------------
    Description: 
There isn't possible change value for given alias in Credential Store over CLI.

I expected something like this
{code}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
{code}

Write-attribute operation doesn't work too. Operation pass but any changes are not propagated to Credential Store.
{code}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:write-attribute(name="secret-value" value="newSecretValue")
{code}

  was:
There isn't possible change value for given alias in Credential Store over CLI.

I expected something like this
{code}
/subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
{code}



> There isn't possible change value for given alias in Credential Store over CLI.
> -------------------------------------------------------------------------------
>
>                 Key: ELY-676
>                 URL: https://issues.jboss.org/browse/ELY-676
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> There isn't possible change value for given alias in Credential Store over CLI.
> I expected something like this
> {code}
> /subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
> {code}
> Write-attribute operation doesn't work too. Operation pass but any changes are not propagated to Credential Store.
> {code}
> /subsystem=elytron/credential-store=credStore/alias=entryAlias:write-attribute(name="secret-value" value="newSecretValue")
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Wed Oct 26 06:01:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 26 Oct 2016 06:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476024000@Atlassian.JIRA>
References: <JIRA.12657047.1477476024000@Atlassian.JIRA>
	<JIRA.12657047.1477476024990@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476024000.1319.1477476060199@Atlassian.JIRA>

Darran Lofthouse created WFCORE-1897:
----------------------------------------

             Summary: Follow up WFCORE-296 once migrated to Remoting 5
                 Key: WFCORE-1897
                 URL: https://issues.jboss.org/browse/WFCORE-1897
             Project: WildFly Core
          Issue Type: Task
          Components: Remoting
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Blocker
             Fix For: 3.0.0.Alpha11


WFCORE-296 adds support for the schemes remote:// remote_http:// and remote+https:// - once we switch to centralised Endpoints we need to ensure this new set is still supported along with the previous set.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 06:19:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Wed, 26 Oct 2016 06:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7385) Defining protocol of ssl
 config in security realm to incorrect value results in broken https
In-Reply-To: <JIRA.12657049.1477477086000@Atlassian.JIRA>
References: <JIRA.12657049.1477477086000@Atlassian.JIRA>
	<JIRA.12657049.1477477086397@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657049.1477477086000.1366.1477477140224@Atlassian.JIRA>

Radim Hatlapatka created WFLY-7385:
--------------------------------------

             Summary: Defining protocol of ssl config in security realm to incorrect value results in broken https
                 Key: WFLY-7385
                 URL: https://issues.jboss.org/browse/WFLY-7385
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Radim Hatlapatka
            Assignee: Brian Stansberry


If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available.

It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided.

E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start

It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided.








--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 06:19:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Wed, 26 Oct 2016 06:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7385) Defining protocol of ssl
 config in security realm to incorrect value results in broken https
In-Reply-To: <JIRA.12657049.1477477086000@Atlassian.JIRA>
References: <JIRA.12657049.1477477086000@Atlassian.JIRA>
	<JIRA.12657049.1477477086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657049.1477477086000.1369.1477477140326@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-7385:
-----------------------------------
    Affects Version/s: 10.1.0.Final


> Defining protocol of ssl config in security realm to incorrect value results in broken https
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7385
>                 URL: https://issues.jboss.org/browse/WFLY-7385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 10.1.0.Final
>            Reporter: Radim Hatlapatka
>            Assignee: Brian Stansberry
>              Labels: user_experience
>
> If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available.
> It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided.
> E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start
> It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 06:19:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Wed, 26 Oct 2016 06:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7385) Defining protocol of ssl
 config in security realm to incorrect value results in broken https
In-Reply-To: <JIRA.12657049.1477477086000@Atlassian.JIRA>
References: <JIRA.12657049.1477477086000@Atlassian.JIRA>
	<JIRA.12657049.1477477086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657049.1477477086000.1372.1477477140382@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Hatlapatka updated WFLY-7385:
-----------------------------------
    Labels: user_experience  (was: )


> Defining protocol of ssl config in security realm to incorrect value results in broken https
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7385
>                 URL: https://issues.jboss.org/browse/WFLY-7385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 10.1.0.Final
>            Reporter: Radim Hatlapatka
>            Assignee: Brian Stansberry
>              Labels: user_experience
>
> If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available.
> It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided.
> E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start
> It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 06:41:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 26 Oct 2016 06:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1898) Defining protocol of ssl
 config in security realm to incorrect value results in broken https
In-Reply-To: <JIRA.12657049.1477477086000@Atlassian.JIRA>
References: <JIRA.12657049.1477477086000@Atlassian.JIRA>
	<JIRA.12657049.1477477086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657049.1477477086000.1501.1477478460856@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFLY-7385 to WFCORE-1898:
------------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-1898  (was: WFLY-7385)
          Component/s: Domain Management
                       Security
                           (was: Domain Management)
    Affects Version/s: 3.0.0.Alpha10
                           (was: 10.1.0.Final)


> Defining protocol of ssl config in security realm to incorrect value results in broken https
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1898
>                 URL: https://issues.jboss.org/browse/WFCORE-1898
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Radim Hatlapatka
>            Assignee: Brian Stansberry
>              Labels: user_experience
>
> If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available.
> It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided.
> E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start
> It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 06:45:01 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 26 Oct 2016 06:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1898) Defining protocol of ssl
 config in security realm to incorrect value results in broken https
In-Reply-To: <JIRA.12657049.1477477086000@Atlassian.JIRA>
References: <JIRA.12657049.1477477086000@Atlassian.JIRA>
	<JIRA.12657049.1477477086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657049.1477477086000.1569.1477478701291@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312054#comment-13312054 ] 

Darran Lofthouse commented on WFCORE-1898:
------------------------------------------

[~rhatlapa] FYI any issues relating to the legacy security realms should be created under the WFCORE project instead of WFLY.

> Defining protocol of ssl config in security realm to incorrect value results in broken https
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1898
>                 URL: https://issues.jboss.org/browse/WFCORE-1898
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Radim Hatlapatka
>            Assignee: Brian Stansberry
>              Labels: user_experience
>
> If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available.
> It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided.
> E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start
> It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 07:00:00 2016
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Wed, 26 Oct 2016 07:00:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1898) Defining protocol of ssl
 config in security realm to incorrect value results in broken https
In-Reply-To: <JIRA.12657049.1477477086000@Atlassian.JIRA>
References: <JIRA.12657049.1477477086000@Atlassian.JIRA>
	<JIRA.12657049.1477477086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657049.1477477086000.1747.1477479600619@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312064#comment-13312064 ] 

Radim Hatlapatka commented on WFCORE-1898:
------------------------------------------

[~dlofthouse] thanks, I will remember that.

> Defining protocol of ssl config in security realm to incorrect value results in broken https
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1898
>                 URL: https://issues.jboss.org/browse/WFCORE-1898
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Radim Hatlapatka
>            Assignee: Brian Stansberry
>              Labels: user_experience
>
> If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available.
> It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided.
> E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start
> It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 07:20:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 26 Oct 2016 07:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7343) NPE in elytron SPNEGO
 implementation in exceptional states
In-Reply-To: <JIRA.12655576.1476822271000@Atlassian.JIRA>
References: <JIRA.12655576.1476822271000@Atlassian.JIRA>
	<JIRA.12655576.1476822271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655576.1476822271000.1925.1477480800236@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7343:
--------------------------------

    Assignee: Jan Kalina


> NPE in elytron SPNEGO implementation in exceptional states
> ----------------------------------------------------------
>
>                 Key: WFLY-7343
>                 URL: https://issues.jboss.org/browse/WFLY-7343
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Http response code 500 + excpetion in server log:
> {code}
> 21:40:40,640 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /secured-webapp/secure/index.jsp: java.lang.NullPointerException
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.authorizeEstablishedContext(SpnegoAuthenticationMechanism.java:177)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:128)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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}
> I have hit this in two situations so far
> * accessing with kerberos ticket from another realm. E.g. application server is set for realm JBOSS.ORG, but client is jduke at REDHAT.COM
> 	** For this situation is http response code 500 disputable, as it could be viewed as problem of client. Client can change ticket and authentication can be performed just fine. 
> * misconfiguration e.g. wrong kdc in krb5.conf
> Provide some meaningful error message.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 07:57:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 26 Oct 2016 07:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7386) JGroups channels should only
 use JMX if the associated capability is available.
In-Reply-To: <JIRA.12657083.1477482985000@Atlassian.JIRA>
References: <JIRA.12657083.1477482985000@Atlassian.JIRA>
	<JIRA.12657083.1477482985704@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657083.1477482985000.2250.1477483020427@Atlassian.JIRA>

Paul Ferraro created WFLY-7386:
----------------------------------

             Summary: JGroups channels should only use JMX if the associated capability is available.
                 Key: WFLY-7386
                 URL: https://issues.jboss.org/browse/WFLY-7386
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 07:57:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 26 Oct 2016 07:57:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7387) Infinispan cache containers
 should only use JMX if the associated capability is available.
In-Reply-To: <JIRA.12657084.1477483019000@Atlassian.JIRA>
References: <JIRA.12657084.1477483019000@Atlassian.JIRA>
	<JIRA.12657084.1477483019567@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657084.1477483019000.2254.1477483020511@Atlassian.JIRA>

Paul Ferraro created WFLY-7387:
----------------------------------

             Summary: Infinispan cache containers should only use JMX if the associated capability is available.
                 Key: WFLY-7387
                 URL: https://issues.jboss.org/browse/WFLY-7387
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 08:01:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 26 Oct 2016 08:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7382) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657011.1477453898000@Atlassian.JIRA>
References: <JIRA.12657011.1477453898000@Atlassian.JIRA>
	<JIRA.12657011.1477453898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657011.1477453898000.2320.1477483260490@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7382:
------------------------------
    Description: This is required to remove jandex 


> Build tools 1.1.7.Final
> -----------------------
>
>                 Key: WFLY-7382
>                 URL: https://issues.jboss.org/browse/WFLY-7382
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This is required to remove jandex 



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 08:01:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 26 Oct 2016 08:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7382) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657011.1477453898000@Atlassian.JIRA>
References: <JIRA.12657011.1477453898000@Atlassian.JIRA>
	<JIRA.12657011.1477453898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657011.1477453898000.2323.1477483260590@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7382:
------------------------------
    Description: This is required to remove jandex from full  (was: This is required to remove jandex )


> Build tools 1.1.7.Final
> -----------------------
>
>                 Key: WFLY-7382
>                 URL: https://issues.jboss.org/browse/WFLY-7382
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This is required to remove jandex from full



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 08:01:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 26 Oct 2016 08:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7382) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657011.1477453898000@Atlassian.JIRA>
References: <JIRA.12657011.1477453898000@Atlassian.JIRA>
	<JIRA.12657011.1477453898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657011.1477453898000.2328.1477483260718@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-7382:
---------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)


> Build tools 1.1.7.Final
> -----------------------
>
>                 Key: WFLY-7382
>                 URL: https://issues.jboss.org/browse/WFLY-7382
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Tomaz Cerar
>
> This is required to remove jandex from full



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 08:02:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 26 Oct 2016 08:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7382) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657011.1477453898000@Atlassian.JIRA>
References: <JIRA.12657011.1477453898000@Atlassian.JIRA>
	<JIRA.12657011.1477453898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657011.1477453898000.2331.1477483320532@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7382:
------------------------------
    Component/s: Build System


> Build tools 1.1.7.Final
> -----------------------
>
>                 Key: WFLY-7382
>                 URL: https://issues.jboss.org/browse/WFLY-7382
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Build System
>    Affects Versions: 10.1.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Tomaz Cerar
>
> This is required to remove jandex from full



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 08:02:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 26 Oct 2016 08:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7382) Build tools 1.1.7.Final
In-Reply-To: <JIRA.12657011.1477453898000@Atlassian.JIRA>
References: <JIRA.12657011.1477453898000@Atlassian.JIRA>
	<JIRA.12657011.1477453898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657011.1477453898000.2335.1477483320605@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-7382:
------------------------------
    Affects Version/s: 10.1.0.Final


> Build tools 1.1.7.Final
> -----------------------
>
>                 Key: WFLY-7382
>                 URL: https://issues.jboss.org/browse/WFLY-7382
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Build System
>    Affects Versions: 10.1.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Tomaz Cerar
>
> This is required to remove jandex from full



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 08:07:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 26 Oct 2016 08:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-690) NPE in elytron SPNEGO
 implementation in exceptional states
In-Reply-To: <JIRA.12655576.1476822271000@Atlassian.JIRA>
References: <JIRA.12655576.1476822271000@Atlassian.JIRA>
	<JIRA.12655576.1476822271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655576.1476822271000.2379.1477483621048@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7343 to ELY-690:
--------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-690  (was: WFLY-7343)
          Component/s: Authentication Mechanisms
                           (was: Security)
    Affects Version/s:     (was: 11.0.0.Alpha1)


> NPE in elytron SPNEGO implementation in exceptional states
> ----------------------------------------------------------
>
>                 Key: ELY-690
>                 URL: https://issues.jboss.org/browse/ELY-690
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Mechanisms
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Http response code 500 + excpetion in server log:
> {code}
> 21:40:40,640 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /secured-webapp/secure/index.jsp: java.lang.NullPointerException
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.authorizeEstablishedContext(SpnegoAuthenticationMechanism.java:177)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:128)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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}
> I have hit this in two situations so far
> * accessing with kerberos ticket from another realm. E.g. application server is set for realm JBOSS.ORG, but client is jduke at REDHAT.COM
> 	** For this situation is http response code 500 disputable, as it could be viewed as problem of client. Client can change ticket and authentication can be performed just fine. 
> * misconfiguration e.g. wrong kdc in krb5.conf
> Provide some meaningful error message.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 08:08:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 26 Oct 2016 08:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-691) Elytron properties-realm is not
 compatible with legacy user property files
In-Reply-To: <JIRA.12657090.1477483629000@Atlassian.JIRA>
References: <JIRA.12657090.1477483629000@Atlassian.JIRA>
	<JIRA.12657090.1477483629847@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657090.1477483629000.2394.1477483680410@Atlassian.JIRA>

Ondrej Lukas created ELY-691:
--------------------------------

             Summary: Elytron properties-realm is not compatible with legacy user property files
                 Key: ELY-691
                 URL: https://issues.jboss.org/browse/ELY-691
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Critical


When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.

Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
{code}
elytron:password                            // results to username elytron with password password
elytronumlaut???=password                   // results to username elytronumlaut??? with password password
elytron??=password                        // results to username elytron?? with password password
backslash\\=password                        // results to username backslash\ with password password
backslash\\inthemiddle=password             // results to username backslash\inthemiddle with password password
dn\=elytron,dc\=wildfly,dc\=org=password    // results to username dn=elytron,dc=wildfly,dc=org with password password
elytron1=pass=word                          // results to username elytron1 with password pass=word - covered by JBEAP-6581
elytron2=password\\                         // results to username elytron2 with password password\
elytron3=pass\\word                         // results to username elytron3 with password pass\word
elytron4=passwordWithumlaut???              // results to username elytron4 with password passwordWithumlaut???
elytron5=??                               // results to username elytron5 with password ??
{code}

Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Wed Oct 26 08:08:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 26 Oct 2016 08:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-691) Elytron properties-realm is not
 compatible with legacy user property files
In-Reply-To: <JIRA.12657090.1477483630000@Atlassian.JIRA>
References: <JIRA.12657090.1477483630000@Atlassian.JIRA>
	<JIRA.12657090.1477483630000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657090.1477483630000.2399.1477483680576@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-691:
-----------------------------
    Affects Version/s: 1.1.0.Beta11


> Elytron properties-realm is not compatible with legacy user property files
> --------------------------------------------------------------------------
>
>                 Key: ELY-691
>                 URL: https://issues.jboss.org/browse/ELY-691
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.
> Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
> {code}
> elytron:password                            // results to username elytron with password password
> elytronumlaut???=password                   // results to username elytronumlaut??? with password password
> elytron??=password                        // results to username elytron?? with password password
> backslash\\=password                        // results to username backslash\ with password password
> backslash\\inthemiddle=password             // results to username backslash\inthemiddle with password password
> dn\=elytron,dc\=wildfly,dc\=org=password    // results to username dn=elytron,dc=wildfly,dc=org with password password
> elytron1=pass=word                          // results to username elytron1 with password pass=word - covered by JBEAP-6581
> elytron2=password\\                         // results to username elytron2 with password password\
> elytron3=pass\\word                         // results to username elytron3 with password pass\word
> elytron4=passwordWithumlaut???              // results to username elytron4 with password passwordWithumlaut???
> elytron5=??                               // results to username elytron5 with password ??
> {code}
> Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Wed Oct 26 08:56:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 26 Oct 2016 08:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-692) Add tests for special chars in
 LegacyPropertiesSecurityRealm
In-Reply-To: <JIRA.12657100.1477486534000@Atlassian.JIRA>
References: <JIRA.12657100.1477486534000@Atlassian.JIRA>
	<JIRA.12657100.1477486534451@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657100.1477486534000.2716.1477486560062@Atlassian.JIRA>

Ondrej Lukas created ELY-692:
--------------------------------

             Summary: Add tests for special chars in LegacyPropertiesSecurityRealm
                 Key: ELY-692
                 URL: https://issues.jboss.org/browse/ELY-692
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Realms, Testsuite
    Affects Versions: 1.1.0.Beta11
            Reporter: Ondrej Lukas
            Assignee: Ondrej Lukas


Add tests for issue https://issues.jboss.org/browse/ELY-688 and https://issues.jboss.org/browse/ELY-691



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 09:03:01 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 26 Oct 2016 09:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-691) Elytron properties-realm is not
 compatible with legacy user property files
In-Reply-To: <JIRA.12657090.1477483630000@Atlassian.JIRA>
References: <JIRA.12657090.1477483630000@Atlassian.JIRA>
	<JIRA.12657090.1477483630000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657090.1477483630000.2830.1477486981174@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-691:
-----------------------------
    Steps to Reproduce: 
For trying how it works in legacy security solution: 
1) add following to {{$SERVER_HOME/standalone/configuration/mgmt-users.properties}}:
{code}
elytron:password
!elytron=password
elytronumlaut???=password
elytron??=password
backslash\\=password
backslash\\inthemiddle=password
dn\=elytron,dc\=wildfly,dc\=org=password
elytron1=pass=word
elytron2=password\\
elytron3=pass\\word
elytron4=passwordWithumlaut???
elytron5=??
{code}

2) configure ManagementRealm to use plain-text password:
{code}
/core-service=management/security-realm=ManagementRealm/authentication=properties:write-attribute(name=plain-text,value=true)
{code}

3) remove local authentication:
{code}
/core-service=management/security-realm=ManagementRealm/authentication=local:remove()
{code}

4) Try to login to jboss-cli with users mentioned in this JIRA description -> all pass (except {{!elytron/password}} which correctly fail)


For reproduction this issue in Elytron, use related tests from {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealmTest}} in Elytron unit tests.

  was:
For trying how it works in legacy security solution: 
1) add following to {{$SERVER_HOME/standalone/configuration/mgmt-users.properties}}:
{code}
elytron:password
!elytron=password
elytronumlaut???=password
elytron??=password
backslash\\=password
backslash\\inthemiddle=password
dn\=elytron,dc\=wildfly,dc\=org=password
elytron1=pass=word
elytron2=password\\
elytron3=pass\\word
elytron4=passwordWithumlaut???
elytron5=??
{code}

2) configure ManagementRealm to use plain-text password:
{code}
/core-service=management/security-realm=ManagementRealm/authentication=properties:write-attribute(name=plain-text,value=true)
{code}

3) remove local authentication:
{code}
/core-service=management/security-realm=ManagementRealm/authentication=local:remove()
{code}

4) Try to login to jboss-cli with users mentioned in this JIRA description -> all pass (except {{!elytron/password}} which correctly fail)



> Elytron properties-realm is not compatible with legacy user property files
> --------------------------------------------------------------------------
>
>                 Key: ELY-691
>                 URL: https://issues.jboss.org/browse/ELY-691
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.
> Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
> {code}
> elytron:password                            // results to username elytron with password password
> elytronumlaut???=password                   // results to username elytronumlaut??? with password password
> elytron??=password                        // results to username elytron?? with password password
> backslash\\=password                        // results to username backslash\ with password password
> backslash\\inthemiddle=password             // results to username backslash\inthemiddle with password password
> dn\=elytron,dc\=wildfly,dc\=org=password    // results to username dn=elytron,dc=wildfly,dc=org with password password
> elytron1=pass=word                          // results to username elytron1 with password pass=word - covered by JBEAP-6581
> elytron2=password\\                         // results to username elytron2 with password password\
> elytron3=pass\\word                         // results to username elytron3 with password pass\word
> elytron4=passwordWithumlaut???              // results to username elytron4 with password passwordWithumlaut???
> elytron5=??                               // results to username elytron5 with password ??
> {code}
> Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Wed Oct 26 09:14:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 26 Oct 2016 09:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-693) Elytron SPNEGO "continuation
 required" situation
In-Reply-To: <JIRA.12657104.1477487549000@Atlassian.JIRA>
References: <JIRA.12657104.1477487549000@Atlassian.JIRA>
	<JIRA.12657104.1477487549000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657104.1477487549000.2895.1477487640076@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved JBEAP-6645 to ELY-693:
---------------------------------------

              Project: WildFly Elytron  (was: JBoss Enterprise Application Platform)
                  Key: ELY-693  (was: JBEAP-6645)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Authentication Mechanisms
                           (was: Security)
    Affects Version/s:     (was: 7.1.0.DR7)


> Elytron SPNEGO "continuation required" situation
> ------------------------------------------------
>
>                 Key: ELY-693
>                 URL: https://issues.jboss.org/browse/ELY-693
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Mechanisms
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>
> I have problem to achieve this scenario with elytron:
> # Client sends non kerberos OID mechanism as most preferred with non kerberos ticket
> # Server response with "continuation required"
> # Client sends kerberos ticket 
> # Server response with 401 instead of 200
> Actually, it is scenario tested in [1]. It worked correctly in EAP 7.0 . Also works with elytron when client sends non-kerberos OID mechanism with kerberos ticket.
> Problem as I see is that SpnegoAuthenticationMechanism: 
> # Creates {{gssContext}} with first provided ticket (non-kerberos) and sends "continuation required"
> # Client provide proper kerberos ticket, but that anyway leads to 401 bare challenge, because {{gssContext}} was already created in first step and is not tried to make again.
> Setting to critical as it behaves differently compared to EAP 7.0 and IMHO it doesn't comply to spec [2]. Similar error was resolved in EAP 7.0 (JBEAP-3709) as blocker because customer case existed for that.
> [1] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13db50ff43/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/negotiation/SPNEGOLoginModuleTestCase.java#L344
> [2] https://tools.ietf.org/html/rfc4178



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 09:58:00 2016
From: issues at jboss.org (Ken Wills (JIRA))
Date: Wed, 26 Oct 2016 09:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1882) Deal with WFCORE-1052
 functionality in the HA DC case
In-Reply-To: <JIRA.12655764.1476895893000@Atlassian.JIRA>
References: <JIRA.12655764.1476895893000@Atlassian.JIRA>
	<JIRA.12655764.1476895893000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655764.1476895893000.3245.1477490280356@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills reassigned WFCORE-1882:
---------------------------------

    Assignee: Ken Wills


> Deal with WFCORE-1052 functionality in the HA DC case
> -----------------------------------------------------
>
>                 Key: WFCORE-1882
>                 URL: https://issues.jboss.org/browse/WFCORE-1882
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Ken Wills
>
> WFCORE-1052 adds the ability to reload a process to a different config file from what it is currently running. That includes the domain-wide config file if the reloading process is a master HC.
> I don't think we want to support this in a WFCORE-338 scenario, as it amounts to a mechanism to force a different domain-wide config into the domain. I think we should have a more specific, controlled mechanism for that.
> Once WFCORE-1881 is implemented HostProcessReloadHandler can check LocalHostControllerInfo to see if its running in a CDC. Note that this issue may have implications on the design of WFCORE-1881. That is, it may not be the case that if LHCI.isMaster() is true then LHCI.isCandidateDomainController() is true. Perhaps an HC configured in the EAP 7.0 and earlier style could be a master but not a CDC. For such an HC the WFCORE-1052 functionality could be available. 



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 10:38:00 2016
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 26 Oct 2016 10:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1343) Add governance page to
 drools.org and jbpm.org
In-Reply-To: <JIRA.12657139.1477492672000@Atlassian.JIRA>
References: <JIRA.12657139.1477492672000@Atlassian.JIRA>
	<JIRA.12657139.1477492672545@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657139.1477492672000.3457.1477492680128@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-1343:
----------------------------------------

             Summary: Add governance page to drools.org and jbpm.org
                 Key: DROOLS-1343
                 URL: https://issues.jboss.org/browse/DROOLS-1343
             Project: Drools
          Issue Type: Task
            Reporter: Geoffrey De Smet
            Assignee: Michael Biarnes Kiefer


copy paste this commit (replace "optaplanner" in the text):
https://github.com/droolsjbpm/optaplanner-website/commit/65509675e



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 11:26:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 26 Oct 2016 11:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-694) CLIENT-CERT mechanism is
 incorrectly called CLIENT_CERT
In-Reply-To: <JIRA.12657148.1477495537000@Atlassian.JIRA>
References: <JIRA.12657148.1477495537000@Atlassian.JIRA>
	<JIRA.12657148.1477495537682@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657148.1477495537000.3662.1477495560202@Atlassian.JIRA>

Darran Lofthouse created ELY-694:
------------------------------------

             Summary: CLIENT-CERT mechanism is incorrectly called CLIENT_CERT
                 Key: ELY-694
                 URL: https://issues.jboss.org/browse/ELY-694
             Project: WildFly Elytron
          Issue Type: Bug
          Components: HTTP
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta12






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 11:27:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 26 Oct 2016 11:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-694) CLIENT-CERT mechanism is
 incorrectly called CLIENT_CERT
In-Reply-To: <JIRA.12657148.1477495538000@Atlassian.JIRA>
References: <JIRA.12657148.1477495538000@Atlassian.JIRA>
	<JIRA.12657148.1477495538000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657148.1477495538000.3668.1477495620132@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312228#comment-13312228 ] 

Darran Lofthouse commented on ELY-694:
--------------------------------------

[~zrhoads] FYI

> CLIENT-CERT mechanism is incorrectly called CLIENT_CERT
> -------------------------------------------------------
>
>                 Key: ELY-694
>                 URL: https://issues.jboss.org/browse/ELY-694
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 12:01:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 26 Oct 2016 12:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1552) Slaves should report the
 master's version in the domain model
In-Reply-To: <JIRA.12619639.1463151440000@Atlassian.JIRA>
References: <JIRA.12619639.1463151440000@Atlassian.JIRA>
	<JIRA.12619639.1463151440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12619639.1463151440000.3911.1477497660168@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1552:
----------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Kabir Khan)


> Slaves should report the master's version in the domain model
> -------------------------------------------------------------
>
>                 Key: WFCORE-1552
>                 URL: https://issues.jboss.org/browse/WFCORE-1552
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.2.0.CR2
>            Reporter: Kabir Khan
>            Assignee: ehsavoie Hugonnet
>
> Setting up the mixed domain tests for an EAP7 slave, I get the following error :
> {code}
>   SimpleMixedDomain700TestCase>SimpleMixedDomainTest.test00002_Versioning:139 expected:<{
>     "management-major-version" => 4,
>     "management-micro-version" => 0,
>     "management-minor-version" => 1,
>     "name" => "Unnamed Domain",
>     "namespaces" => [],
>     "product-name" => "WildFly Full",
>     "product-version" => "10.1.0.Final-SNAPSHOT",
>     "release-codename" => "Kenny",
>     "release-version" => "2.2.0.CR2",
>     "schema-locations" => []
> }> but was:<{
>     "management-major-version" => 4,
>     "management-micro-version" => 0,
>     "management-minor-version" => 1,
>     "name" => "Unnamed Domain",
>     "namespaces" => [],
>     "product-name" => "JBoss EAP",
>     "product-version" => "7.0.0.GA",
>     "release-codename" => "Kenny",
>     "release-version" => "2.1.2.Final-redhat-1",
>     "schema-locations" => []
> }>
> {code}
> The 'expected' is the WildFly master values, while the 'actual' are the slave values. product-name, product-version, release-codename and release-version on the slave should be the same as the master values. Once we upgrade to Wildfly Core 3.0.0 we should also check that the management-[major/minor/micro]-version attributes on the slave are the same as the DC's values as well (i.e 5.0.0 rather than 4.0.1) This is similar to WFLY-3228 back in the day.
> This is probably caused by the SyncXXX handlers for pushing the domain config as operations (WFCORE-401)



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 12:10:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 26 Oct 2016 12:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1606) Server reload is needed for
 modified security-realm even if {allow-resource-service-restart=true} is
 used
In-Reply-To: <JIRA.12633460.1466166240000@Atlassian.JIRA>
References: <JIRA.12633460.1466166240000@Atlassian.JIRA>
	<JIRA.12633460.1466166240000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633460.1466166240000.3929.1477498200481@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1606:
----------------------------------------

    Assignee: ehsavoie Hugonnet


Emmanuel, please have a look at this, starting off with discussing a bit with [~dlofthouse]. I'm quite fine with fixing this by simply correcting the metadata, and not actual supporting allow-resource-service-restart=true. We should only go beyond that if:

1) The elytron replacements for these legacy security-realm resources will support allow-resource-service-restart=true *in core 3.0.0  / WF 11*.

2) Darran is up for reviewing a patch to add the support.

Otherwise let's just fix the metadata.

> Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1606
>                 URL: https://issues.jboss.org/browse/WFCORE-1606
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 2.0.10.Final
>            Reporter: Ondrej Lukas
>            Assignee: ehsavoie Hugonnet
>             Fix For: 3.0.0.Beta1
>
>
> When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 12:42:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 26 Oct 2016 12:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7388) NullPointerException Adding
 FileSystemRealm with identities in a batch.
In-Reply-To: <JIRA.12657169.1477500071000@Atlassian.JIRA>
References: <JIRA.12657169.1477500071000@Atlassian.JIRA>
	<JIRA.12657169.1477500071337@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657169.1477500071000.4082.1477500120831@Atlassian.JIRA>

Darran Lofthouse created WFLY-7388:
--------------------------------------

             Summary: NullPointerException Adding FileSystemRealm with identities in a batch.
                 Key: WFLY-7388
                 URL: https://issues.jboss.org/browse/WFLY-7388
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 11.0.0.Alpha1


{{/subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
/subsystem=elytron/filesystem-realm=exampleFsRealm/identity=jduke at JBOSS.ORG:add()
/subsystem=elytron/filesystem-realm=exampleFsRealm/identity=jduke at JBOSS.ORG:add-attribute(name=Roles, value=["Admin","Guest"])
/subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
/subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper)}}

{noformat}
Step 21 : RUN /opt/jboss/wildfly/dist/target/wildfly-11.0.0.Alpha1-SNAPSHOT/bin/jboss-cli.sh --commands=embed-server\ --server-config=standalone-elytron.xml,run-batch\ --file=/opt/jboss/commands.txt,stop-embedded-server
---> Running in fb3e83746136
The batch failed with the following error: : {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException"}}
{noformat}

NullPointerException experienced randomly, initially this sounds like the service is not fully up by the time the first command completes.




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 12:50:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 26 Oct 2016 12:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1883) Post-boot transition
 to/from acting as a master or slave HC must be done with management op
 execution locked out
In-Reply-To: <JIRA.12655770.1476896205000@Atlassian.JIRA>
References: <JIRA.12655770.1476896205000@Atlassian.JIRA>
	<JIRA.12655770.1476896205000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655770.1476896205000.4139.1477500600422@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1883:
----------------------------------------

    Assignee: Brian Stansberry


> Post-boot transition to/from acting as a master or slave HC must be done with management op execution locked out
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1883
>                 URL: https://issues.jboss.org/browse/WFCORE-1883
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> As part of WFCORE-338, a Candidate Domain Controller can shift between acting a master or acting as slave without requiring a reload or reboot.
> However, after initial boot, a DCC can be handling management requests. Any transition between acting as a master or slave to the other role must ensure that in-process management requests are not disrupted and that no new management requests are able to access the management model or runtime services until the transition is complete. As a practical matter this likely means that the transition task(s) must acquire the exclusive management lock and hold it until the transition is complete.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 13:24:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 26 Oct 2016 13:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7389) Improve
 statistics-enabled="false" testing in infinispan subsystem for EAP 6.2
In-Reply-To: <JIRA.12657184.1477502614000@Atlassian.JIRA>
References: <JIRA.12657184.1477502614000@Atlassian.JIRA>
	<JIRA.12657184.1477502614834@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657184.1477502614000.4272.1477502640219@Atlassian.JIRA>

Radoslav Husar created WFLY-7389:
------------------------------------

             Summary: Improve statistics-enabled="false" testing in infinispan subsystem for EAP 6.2
                 Key: WFLY-7389
                 URL: https://issues.jboss.org/browse/WFLY-7389
             Project: WildFly
          Issue Type: Task
          Components: Clustering
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
            Priority: Minor


The test file clustering/infinispan/extension/src/test/resources/org/jboss/as/clustering/infinispan/subsystem/infinispan-transformer-reject.xml specifies {code}statistics-enabled="false"{code} for all caches and cache-containers thus the situation when its undefined is never tested.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 13:28:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 26 Oct 2016 13:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7389) Improve undefined
 statistics-enabled attribute testing in infnispan subsystem for EAP 6.2
In-Reply-To: <JIRA.12657184.1477502615000@Atlassian.JIRA>
References: <JIRA.12657184.1477502615000@Atlassian.JIRA>
	<JIRA.12657184.1477502615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657184.1477502615000.4278.1477502880214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7389:
---------------------------------
    Summary: Improve undefined statistics-enabled attribute testing in infnispan subsystem for EAP 6.2  (was: Improve statistics-enabled="false" testing in infinispan subsystem for EAP 6.2)


> Improve undefined statistics-enabled attribute testing in infnispan subsystem for EAP 6.2
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-7389
>                 URL: https://issues.jboss.org/browse/WFLY-7389
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> The test file clustering/infinispan/extension/src/test/resources/org/jboss/as/clustering/infinispan/subsystem/infinispan-transformer-reject.xml specifies {code}statistics-enabled="false"{code} for all caches and cache-containers thus the situation when its undefined is never tested.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 13:32:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 26 Oct 2016 13:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7388) NullPointerException Adding
 FileSystemRealm with identities in a batch.
In-Reply-To: <JIRA.12657169.1477500071000@Atlassian.JIRA>
References: <JIRA.12657169.1477500071000@Atlassian.JIRA>
	<JIRA.12657169.1477500071000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657169.1477500071000.4293.1477503120314@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312287#comment-13312287 ] 

Brian Stansberry commented on WFLY-7388:
----------------------------------------

This may be irrelevant but that "--commands" string looks odd as it has a "run-batch" with no preceding "batch".

> NullPointerException Adding FileSystemRealm with identities in a batch.
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7388
>                 URL: https://issues.jboss.org/browse/WFLY-7388
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> {{/subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=jduke at JBOSS.ORG:add()
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=jduke at JBOSS.ORG:add-attribute(name=Roles, value=["Admin","Guest"])
> /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
> /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper)}}
> {noformat}
> Step 21 : RUN /opt/jboss/wildfly/dist/target/wildfly-11.0.0.Alpha1-SNAPSHOT/bin/jboss-cli.sh --commands=embed-server\ --server-config=standalone-elytron.xml,run-batch\ --file=/opt/jboss/commands.txt,stop-embedded-server
> ---> Running in fb3e83746136
> The batch failed with the following error: : {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException"}}
> {noformat}
> NullPointerException experienced randomly, initially this sounds like the service is not fully up by the time the first command completes.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 14:49:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 26 Oct 2016 14:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7384) Removal of
 messaging-activemq's server stops Infinispan services
In-Reply-To: <JIRA.12657028.1477468104000@Atlassian.JIRA>
References: <JIRA.12657028.1477468104000@Atlassian.JIRA>
	<JIRA.12657028.1477468104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657028.1477468104000.4388.1477507740398@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312299#comment-13312299 ] 

Paul Ferraro commented on WFLY-7384:
------------------------------------

[~jmesnil] Sure - I'll have a look.

> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
>                 Key: WFLY-7384
>                 URL: https://issues.jboss.org/browse/WFLY-7384
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Paul Ferraro
>         Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 15:01:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 26 Oct 2016 15:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7384) Removal of
 messaging-activemq's server stops Infinispan services
In-Reply-To: <JIRA.12657028.1477468104000@Atlassian.JIRA>
References: <JIRA.12657028.1477468104000@Atlassian.JIRA>
	<JIRA.12657028.1477468104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657028.1477468104000.4402.1477508460222@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312301#comment-13312301 ] 

Paul Ferraro commented on WFLY-7384:
------------------------------------

[~jmesnil] This is expected.
Infinispan cache-containers are installed as PASSIVE, which means that they will automatically start after their underlying transport starts.  If the channel used by the transport is the same as used by messaging, then starting messaging (which starts the default channel) will trigger these cache containers to automatically start.  After messaging is removed, and no other services are started that depend on these cache containers (e.g. a distributed web app, EJB deployment, JPA deployment, etc), then these services will automatically stop.
You can close this.

> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
>                 Key: WFLY-7384
>                 URL: https://issues.jboss.org/browse/WFLY-7384
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Paul Ferraro
>         Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 16:14:00 2016
From: issues at jboss.org (Daniel Soukhov (JIRA))
Date: Wed, 26 Oct 2016 16:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1352) Embedded logged leaving
 filehandles open after stop
In-Reply-To: <JIRA.12602268.1454434666000@Atlassian.JIRA>
References: <JIRA.12602268.1454434666000@Atlassian.JIRA>
	<JIRA.12602268.1454434666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12602268.1454434666000.4636.1477512840882@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Soukhov reopened WFCORE-1352:
------------------------------------


This issue still persists in eap 7.1.0DR7. 

> Embedded logged leaving filehandles open after stop
> ---------------------------------------------------
>
>                 Key: WFCORE-1352
>                 URL: https://issues.jboss.org/browse/WFCORE-1352
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>         Environment: Windows
>            Reporter: Ken Wills
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> After stop-embedded-server or stop-embedded-host-controller commands, logs in standalone/logs/ or domain/logs/ are still held open.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 16:17:00 2016
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 26 Oct 2016 16:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-893) Second security vault
 warning is displayed even if only one vault definition is present in the
 server configuration
In-Reply-To: <JIRA.12574614.1434011672000@Atlassian.JIRA>
References: <JIRA.12574614.1434011672000@Atlassian.JIRA>
	<JIRA.12574614.1434011672000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574614.1434011672000.4642.1477513020278@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky resolved SECURITY-893.
------------------------------------
    Resolution: Done


> Second security vault warning is displayed even if only one vault definition is present in the server configuration
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-893
>                 URL: https://issues.jboss.org/browse/SECURITY-893
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>    Affects Versions: PicketBox_4_1_0.Beta2
>            Reporter: Ivo Studensky
>            Assignee: Peter Skopek
>
> The BZ's description:
> I have only one vault configured in the standalone.xml but I see following warning message in the server log file after login attempt (bindCredentials login module option uses a vaulted password):
> {noformat}
> 09:10:58,854 WARN  [org.jboss.security] (http-/127.0.0.1:8080-1) PBOX000378: Attempt to create the second Security Vault [org.picketbox.plugins.vault.PicketBoxSecurityVault] is invalid. Only one Security Vault is supported. Change your configuration, please.
> {noformat}
> This issue is related to the previous fix for bz1055577, \[1\]. The problem needs to be fixed on EAP side in time of Security Subsystem configuration processing. Fix will be provided by bz1181457 \[2\].
> \[1\] https://bugzilla.redhat.com/show_bug.cgi?id=1055577
> \[2\] https://bugzilla.redhat.com/show_bug.cgi?id=1181457



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 16:34:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 26 Oct 2016 16:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1352) Embedded logged leaving
 filehandles open after stop
In-Reply-To: <JIRA.12602268.1454434666000@Atlassian.JIRA>
References: <JIRA.12602268.1454434666000@Atlassian.JIRA>
	<JIRA.12602268.1454434666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12602268.1454434666000.4721.1477514040425@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312347#comment-13312347 ] 

Brian Stansberry commented on WFCORE-1352:
------------------------------------------

If this isn't broken in WildFly Core 2.2.0.Final (used in WildFly 10.1) then please file a separate issue.

> Embedded logged leaving filehandles open after stop
> ---------------------------------------------------
>
>                 Key: WFCORE-1352
>                 URL: https://issues.jboss.org/browse/WFCORE-1352
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>         Environment: Windows
>            Reporter: Ken Wills
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> After stop-embedded-server or stop-embedded-host-controller commands, logs in standalone/logs/ or domain/logs/ are still held open.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 16:40:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 26 Oct 2016 16:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1352) Embedded logged leaving
 filehandles open after stop
In-Reply-To: <JIRA.12602268.1454434666000@Atlassian.JIRA>
References: <JIRA.12602268.1454434666000@Atlassian.JIRA>
	<JIRA.12602268.1454434666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12602268.1454434666000.4772.1477514400892@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFCORE-1352:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1435, https://github.com/wildfly/wildfly-core/pull/1880  (was: https://github.com/wildfly/wildfly-core/pull/1435)


> Embedded logged leaving filehandles open after stop
> ---------------------------------------------------
>
>                 Key: WFCORE-1352
>                 URL: https://issues.jboss.org/browse/WFCORE-1352
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>         Environment: Windows
>            Reporter: Ken Wills
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> After stop-embedded-server or stop-embedded-host-controller commands, logs in standalone/logs/ or domain/logs/ are still held open.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 16:40:01 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 26 Oct 2016 16:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1352) Embedded logged leaving
 filehandles open after stop
In-Reply-To: <JIRA.12602268.1454434666000@Atlassian.JIRA>
References: <JIRA.12602268.1454434666000@Atlassian.JIRA>
	<JIRA.12602268.1454434666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12602268.1454434666000.4784.1477514401494@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFCORE-1352:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1435  (was: https://github.com/wildfly/wildfly-core/pull/1435, https://github.com/wildfly/wildfly-core/pull/1880)


> Embedded logged leaving filehandles open after stop
> ---------------------------------------------------
>
>                 Key: WFCORE-1352
>                 URL: https://issues.jboss.org/browse/WFCORE-1352
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>         Environment: Windows
>            Reporter: Ken Wills
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> After stop-embedded-server or stop-embedded-host-controller commands, logs in standalone/logs/ or domain/logs/ are still held open.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 16:41:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 26 Oct 2016 16:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1845) Logging subsystem scans the
 CWD on server boot
In-Reply-To: <JIRA.12652897.1475276050000@Atlassian.JIRA>
References: <JIRA.12652897.1475276050000@Atlassian.JIRA>
	<JIRA.12652897.1475276050000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652897.1475276050000.4796.1477514460595@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFCORE-1845:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1870, https://github.com/wildfly/wildfly-core/pull/1880  (was: https://github.com/wildfly/wildfly-core/pull/1870)


> Logging subsystem scans the CWD on server boot
> ----------------------------------------------
>
>                 Key: WFCORE-1845
>                 URL: https://issues.jboss.org/browse/WFCORE-1845
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 2.0.10.Final
>         Environment: OSX El Capitan, Oracle JDK 1.8.0_92 && 101, swarm 2016.8.1, WF 10.0.0.Final, WF-CORE 2.0.10.Final
>            Reporter: Brent Douglas
>            Assignee: James Perkins
>             Fix For: 3.0.0.Alpha11
>
>
> When booting the server from a directory where the subtree is large the server hangs for a long time. JStack shows that the logging subsystem is scanning the CWD.
> Booting the server from the root dir of a maven parent project containing 2 subprojects, a swarm project and a small NPM subproject added 33s to the server boot time compared to stepping into the swarm project and booting it.
> Stacktrace while the server is booting:
> {noformat}
> Thread 25859: (state = IN_NATIVE)
>  - sun.nio.fs.UnixNativeDispatcher.lstat0(long, sun.nio.fs.UnixFileAttributes) @bci=0 (Compiled frame; information may be imprecise)
>  - sun.nio.fs.UnixNativeDispatcher.lstat(sun.nio.fs.UnixPath, sun.nio.fs.UnixFileAttributes) @bci=10, line=300 (Compiled frame)
>  - sun.nio.fs.UnixFileAttributes.get(sun.nio.fs.UnixPath, boolean) @bci=22, line=72 (Compiled frame)
>  - sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes() @bci=15, line=52 (Compiled frame)
>  - sun.nio.fs.UnixFileSystemProvider.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=57, line=144 (Compiled frame)
>  - java.nio.file.Files.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=7, line=1737 (Compiled frame)
>  - java.nio.file.FileTreeWalker.getAttributes(java.nio.file.Path, boolean) @bci=56, line=219 (Compiled frame)
>  - java.nio.file.FileTreeWalker.visit(java.nio.file.Path, boolean, boolean) @bci=3, line=276 (Compiled frame)
>  - java.nio.file.FileTreeWalker.next() @bci=134, line=372 (Compiled frame)
>  - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.util.Set, int, java.nio.file.FileVisitor) @bci=256, line=2706 (Compiled frame)
>  - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.nio.file.FileVisitor) @bci=9, line=2742 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.findFiles(java.lang.String, org.jboss.dmr.ModelNode, boolean) @bci=47, line=251 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.getChildrenNames(java.lang.String) @bci=37, line=157 (Interpreted frame)
>  - org.jboss.as.logging.LoggingResource.getChildren(java.lang.String) @bci=11, line=171 (Interpreted frame)
>  - org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(java.lang.String) @bci=5, line=362 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=99, line=289 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=189, line=291 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
>  - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource) @bci=2, line=250 (Interpreted frame)
>  - org.jboss.as.controller.ModelControllerImpl.writeModel(org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl, java.util.Set) @bci=19, line=769 (Interpreted frame)
>  - org.jboss.as.controller.OperationContextImpl.createPersistenceResource() @bci=17, line=519 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.executeDoneStage(org.jboss.dmr.ModelNode) @bci=22, line=708 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.processStages() @bci=277, line=680 (Interpreted frame)
>  - org.jboss.as.controller.AbstractOperationContext.executeOperation() @bci=27, line=370 (Interpreted frame)
>  - org.jboss.as.controller.OperationContextImpl.executeOperation() @bci=20, line=1344 (Interpreted frame)
>  - org.jboss.as.controller.ModelControllerImpl.boot(java.util.List, org.jboss.as.controller.client.OperationMessageHandler, org.jboss.as.controller.ModelController$OperationTransactionControl, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider, boolean, boolean) @bci=410, line=485 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider) @bci=16, line=387 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean) @bci=7, line=349 (Interpreted frame)
>  - org.jboss.as.server.ServerService.boot(java.util.List, boolean) @bci=22, line=392 (Interpreted frame)
>  - org.jboss.as.server.ServerService.boot(org.jboss.as.controller.BootContext) @bci=907, line=365 (Interpreted frame)
>  - org.jboss.as.controller.AbstractControllerService$1.run() @bci=12, line=299 (Interpreted frame)
>  - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 17:53:00 2016
From: issues at jboss.org (Daniel Soukhov (JIRA))
Date: Wed, 26 Oct 2016 17:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1352) Embedded logged leaving
 filehandles open after stop
In-Reply-To: <JIRA.12602268.1454434666000@Atlassian.JIRA>
References: <JIRA.12602268.1454434666000@Atlassian.JIRA>
	<JIRA.12602268.1454434666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12602268.1454434666000.5029.1477518780729@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Soukhov resolved WFCORE-1352.
------------------------------------
    Resolution: Done


> Embedded logged leaving filehandles open after stop
> ---------------------------------------------------
>
>                 Key: WFCORE-1352
>                 URL: https://issues.jboss.org/browse/WFCORE-1352
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Logging
>         Environment: Windows
>            Reporter: Ken Wills
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 3.0.0.Alpha1, 2.2.0.CR1
>
>
> After stop-embedded-server or stop-embedded-host-controller commands, logs in standalone/logs/ or domain/logs/ are still held open.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 18:18:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Oct 2016 18:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7390) Demote the ERROR message
 about unavailable HTTP/2 on IBM JDK
In-Reply-To: <JIRA.12657203.1477520238000@Atlassian.JIRA>
References: <JIRA.12657203.1477520238000@Atlassian.JIRA>
	<JIRA.12657203.1477520238000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657203.1477520238000.5062.1477520280544@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-6654 to WFLY-7390:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7390  (was: JBEAP-6654)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Web (Undertow)
                           (was: Web (Undertow))
    Affects Version/s:     (was: 7.1.0.DR1)


> Demote the ERROR message about unavailable HTTP/2 on IBM JDK
> ------------------------------------------------------------
>
>                 Key: WFLY-7390
>                 URL: https://issues.jboss.org/browse/WFLY-7390
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> After discussing this in the QE team, we believe that this error message
> bq. 2016-07-21 05:33:00,363 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0071: Jetty ALPN not found. HTTP2 and SPDY are not available. Please make sure Jetty ALPN is on the boot class path.
>  
> should be demoted to WARN to not cause too much panic with every server start. 
> Also, maybe we could enhance it to contain some instructions how to explicitly disable HTTP/2 in order to get rid of this message completely?



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 20:02:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Oct 2016 20:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6271) SFSB methods can still be
 invoked after a calling transaction has rollbacked
In-Reply-To: <JIRA.12607549.1456323191000@Atlassian.JIRA>
References: <JIRA.12607549.1456323191000@Atlassian.JIRA>
	<JIRA.12607549.1456323191000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12607549.1456323191000.68.1477526520190@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312418#comment-13312418 ] 

Stuart Douglas commented on WFLY-6271:
--------------------------------------

Is this still an issue?

> SFSB methods can still be invoked after a calling transaction has rollbacked
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-6271
>                 URL: https://issues.jboss.org/browse/WFLY-6271
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 20:32:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Oct 2016 20:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6212) Wrong behaviour of
 transaction synchronization when txn is timeouted
In-Reply-To: <JIRA.12603895.1455543631000@Atlassian.JIRA>
References: <JIRA.12603895.1455543631000@Atlassian.JIRA>
	<JIRA.12603895.1455543631000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603895.1455543631000.78.1477528320112@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312420#comment-13312420 ] 

Stuart Douglas commented on WFLY-6212:
--------------------------------------

Is this still an issue after the most recent changes to the SFSB synchronization interceptor?

> Wrong behaviour of transaction synchronization when txn is timeouted
> --------------------------------------------------------------------
>
>                 Key: WFLY-6212
>                 URL: https://issues.jboss.org/browse/WFLY-6212
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Stuart Douglas
>
> There is wrong (or maybe strange) behavior of EJB when transaction timeout happens. There are several strange things happen but I'm creating only one jira that it seems that everything is based on one cause. Symptoms are following:
> When timeout occurs server log contains exception [1] (found out that have been reported at WFLY-5319).
> Second point is that it seems that in some cases {{javax.ejb.EJBException}} is thrown from the EJB method (no synchronization) and {{javax.ejb.EJBTransactionRolledbackException}} when {{javax.transaction.Synchronization}} is used. At least I have this impression. I think that behavior should be consistent and probably {{javax.ejb.EJBException}} should be used (feeling taken based of _spec EJB3.1, 14.3.7:  Exceptions from Other Container-invoked Callbacks_).
> Third point is that rollback timeout exception does not remove stateful bean (spec EJB3.1, 4.6 Stateful session bean state diagram). Such bean is available and instead of throwing {{NoSuchEJBException}} there is thrown {{javax.ejb.ConcurrentAccessTimeoutException}}.
> The fourth and probably the most critical thing is that when transaction timeout happens then {{@AfterCompletion}} is not called. This is strangely not true when {{TransactionSynchronizationRegistry}} or {{javax.transaction.Synchronization}} is used. At such cases the after transaction synchronization method is invoked.
> I have created test cases under my repo and the code could be consulted and tested with from the branch here:
> https://github.com/ochaloup/jboss-as/tree/transaction-timeout-tests
> The testcase {{org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.StatefulTimeoutTestCase}} contains cases that when being run show the troubles described in this jira.
> [1]
> {code}
> 2016-02-15 13:55:12,084 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a2805ab:-141e1320:56c1caa9:c in state  RUN
> 2016-02-15 13:55:12,088 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffff0a2805ab:-141e1320:56c1caa9:c invoked while multiple threads active within it.
> 2016-02-15 13:55:12,092 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012381: Action id 0:ffff0a2805ab:-141e1320:56c1caa9:c completed with multiple threads - thread pool-3-thread-1 was in progress with java.lang.Thread.sleep(Native Method)
> org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.TxTestUtil.waitForTimeout(TxTestUtil.java:71)
> org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.StatefulBean.testTransactionTimeout(StatefulBean.java:58)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.StatefulBean$$$view3.testTransactionTimeout(Unknown Source)
> org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.StatefulTimeoutTestCase.timeout(StatefulTimeoutTestCase.java:123)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:497)
> sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> java.security.AccessController.doPrivileged(Native Method)
> javax.security.auth.Subject.doAs(Subject.java:422)
> org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 2016-02-15 13:55:12,093 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffff0a2805ab:-141e1320:56c1caa9:c aborting with 1 threads active!
> 2016-02-15 13:55:12,103 INFO  [org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.TestXAResource] (Transaction Reaper Worker 0) end xid:[< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a2805ab:-141e1320:56c1caa9:c, node_name=1, branch_uid=0:ffff0a2805ab:-141e1320:56c1caa9:e, subordinatenodename=null, eis_name=unknown eis name >], flag: 536870912
> 2016-02-15 13:55:12,104 INFO  [org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.TestXAResource] (Transaction Reaper Worker 0) rollback xid: [< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a2805ab:-141e1320:56c1caa9:c, node_name=1, branch_uid=0:ffff0a2805ab:-141e1320:56c1caa9:e, subordinatenodename=null, eis_name=unknown eis name >]
> 2016-02-15 13:55:12,116 INFO  [org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.TestXAResource] (Transaction Reaper Worker 0) end xid:[< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a2805ab:-141e1320:56c1caa9:c, node_name=1, branch_uid=0:ffff0a2805ab:-141e1320:56c1caa9:12, subordinatenodename=null, eis_name=unknown eis name >], flag: 536870912
> 2016-02-15 13:55:12,117 INFO  [org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.TestXAResource] (Transaction Reaper Worker 0) rollback xid: [< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a2805ab:-141e1320:56c1caa9:c, node_name=1, branch_uid=0:ffff0a2805ab:-141e1320:56c1caa9:12, subordinatenodename=null, eis_name=unknown eis name >]
> 2016-02-15 13:55:12,118 WARN  [org.jboss.as.txn] (Transaction Reaper Worker 0) WFLYTX0027: The pre-jca synchronization org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization at 368a2392 associated with tx TransactionImple < ac, BasicAction: 0:ffff0a2805ab:-141e1320:56c1caa9:c status: ActionStatus.ABORTED > failed during after completion: java.lang.IllegalMonitorStateException
> 	at org.jboss.as.ejb3.tx.OwnableReentrantLock.unlock(OwnableReentrantLock.java:120)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseLock(StatefulSessionSynchronizationInterceptor.java:181)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:173)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization.afterCompletion(StatefulSessionSynchronizationInterceptor.java:250)
> 	at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.afterCompletion(JCAOrderedLastSynchronizationList.java:147)
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:545)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:476)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:130)
> 	at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:215)
> 	at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:381)
> 	at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:78)
> 2016-02-15 13:55:12,119 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff0a2805ab:-141e1320:56c1caa9:c
> 2016-02-15 13:55:12,118 ERROR [org.jboss.as.ejb3.invocation] (pool-3-thread-1) WFLYEJB0034: EJB Invocation failed on component StatefulBean for method public void org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.StatefulBean.testTransactionTimeout() throws javax.transaction.SystemException,java.lang.InterruptedException: javax.ejb.EJBException: WFLYEJB0448: Transaction 'TransactionImple < ac, BasicAction: 0:ffff0a2805ab:-141e1320:56c1caa9:c status: ActionStatus.ABORTED >' is in unexpected state (STATUS_ROLLING_BACK)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:114)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.StatefulBean$$$view3.testTransactionTimeout(Unknown Source)
> 	at org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.StatefulTimeoutTestCase.timeout(StatefulTimeoutTestCase.java:123)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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)
> 2016-02-15 13:55:12,130 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.StatefulTimeoutTestCase.timeout: java.lang.AssertionError: Expecting rollback happened and transaction rollback exception being thrown expected:<class javax.ejb.EJBTransactionRolledbackException> but was:<class javax.ejb.EJBException>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotEquals(Assert.java:834)
> 	at org.junit.Assert.assertEquals(Assert.java:118)
> 	at org.jboss.as.test.integration.ejb.transaction.cmt.timeout.xa.StatefulTimeoutTestCase.timeout(StatefulTimeoutTestCase.java:127)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> 	at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> 	at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> 	at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> 	at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:247)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 	at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 	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.2#72004)

From issues at jboss.org  Wed Oct 26 21:33:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Oct 2016 21:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7374) WildFfly openssl requires
 glibc 2.14 resulting in failure when starting on RHEL 6
In-Reply-To: <JIRA.12656785.1477410763000@Atlassian.JIRA>
References: <JIRA.12656785.1477410763000@Atlassian.JIRA>
	<JIRA.12656785.1477410763000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656785.1477410763000.7.1477531980551@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312510#comment-13312510 ] 

Stuart Douglas commented on WFLY-7374:
--------------------------------------

I have removed all references to memcpy and replaced them with memmove which should solve the versioning issue.

Apparently in glibc 2.14 memcpy was changes to be an alias of memmove anyway.

> WildFfly openssl requires glibc 2.14 resulting in failure when starting on RHEL 6
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-7374
>                 URL: https://issues.jboss.org/browse/WFLY-7374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Server, Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Blocker
>              Labels: wildfly-openssl
>
> When starting EAP on RHEL 6 it shows ERROR messages when loading openssl \[1\]. This is caused by the wrapper requiring glibc 2.14 or newer but on RHEL 6 (RHEL 6.7) there is only glibc 2.12.
> As there should be no ERROR messages during EAP start with default configuration, marking as blocker.
> \[1\]
> {noformat}
> 11:20:42,474 ERROR [stderr] (MSC service thread 1-3) java.lang.reflect.InvocationTargetException
> 11:20:42,476 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:20:42,479 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:20:42,481 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:20:42,494 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Method.invoke(Method.java:498)
> 11:20:42,495 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.init(SSL.java:73)
> 11:20:42,496 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName0(Native Method)
> 11:20:42,498 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName(Class.java:348)
> 11:20:42,499 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
> 11:20:42,505 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
> 11:20:42,508 ERROR [stderr] (MSC service thread 1-3) 	at java.security.AccessController.doPrivileged(Native Method)
> 11:20:42,516 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
> 11:20:42,517 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:20:42,524 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:20:42,525 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:20:42,539 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> 11:20:42,540 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.newInstance(Class.java:442)
> 11:20:42,541 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> 11:20:42,543 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
> 11:20:42,548 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
> 11:20:42,550 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
> 11:20:42,551 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
> 11:20:42,552 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
> 11:20:42,553 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
> 11:20:42,557 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
> 11:20:42,572 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
> 11:20:42,581 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> 11:20:42,582 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 11:20:42,590 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:20:42,591 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:20:42,593 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Thread.run(Thread.java:745)
> 11:20:42,595 ERROR [stderr] (MSC service thread 1-3) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-2717760086872143296openssl/libwfssl.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/tmp-2717760086872143296openssl/libwfssl.so)
> 11:20:42,596 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> 11:20:42,597 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
> 11:20:42,598 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1837)
> 11:20:42,610 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> 11:20:42,611 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.System.loadLibrary(System.java:1122)
> 11:20:42,619 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
> 11:20:42,620 ERROR [stderr] (MSC service thread 1-3) 	... 34 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 22:35:00 2016
From: issues at jboss.org (Chao Wang (JIRA))
Date: Wed, 26 Oct 2016 22:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7391) There is no validation of
 some of messaging server attributes
In-Reply-To: <JIRA.12657310.1477535642000@Atlassian.JIRA>
References: <JIRA.12657310.1477535642000@Atlassian.JIRA>
	<JIRA.12657310.1477535642038@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657310.1477535642000.42.1477535700119@Atlassian.JIRA>

Chao Wang created WFLY-7391:
-------------------------------

             Summary: There is no validation of some of messaging server attributes
                 Key: WFLY-7391
                 URL: https://issues.jboss.org/browse/WFLY-7391
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 10.0.0.Final
            Reporter: Chao Wang
            Assignee: Chao Wang


There is no validation of some attributes of messaging provider. Setting of these attributes to non valid value causes an error during next reload. Some of these attributes are: {{journal-file-size}} or {{journal-compact-percentage}}.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 23:29:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Oct 2016 23:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1900) Wildfly OpenSSL 1.0.0.Alpha3
In-Reply-To: <JIRA.12657410.1477538887000@Atlassian.JIRA>
References: <JIRA.12657410.1477538887000@Atlassian.JIRA>
	<JIRA.12657410.1477538887167@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657410.1477538887000.31.1477538940110@Atlassian.JIRA>

Stuart Douglas created WFCORE-1900:
--------------------------------------

             Summary: Wildfly OpenSSL 1.0.0.Alpha3
                 Key: WFCORE-1900
                 URL: https://issues.jboss.org/browse/WFCORE-1900
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Wed Oct 26 23:42:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 26 Oct 2016 23:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7392) Add max-retries to Undertow
	reverse proxy
In-Reply-To: <JIRA.12657411.1477539686000@Atlassian.JIRA>
References: <JIRA.12657411.1477539686000@Atlassian.JIRA>
	<JIRA.12657411.1477539686171@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657411.1477539686000.50.1477539720102@Atlassian.JIRA>

Stuart Douglas created WFLY-7392:
------------------------------------

             Summary: Add max-retries to Undertow reverse proxy
                 Key: WFLY-7392
                 URL: https://issues.jboss.org/browse/WFLY-7392
             Project: WildFly
          Issue Type: Enhancement
          Components: Web (Undertow)
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 00:13:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 27 Oct 2016 00:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7364)
 java.lang.IllegalArgumentException: UT000068: Servlet path match failed
In-Reply-To: <JIRA.12656014.1477000674000@Atlassian.JIRA>
References: <JIRA.12656014.1477000674000@Atlassian.JIRA>
	<JIRA.12656014.1477000674000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656014.1477000674000.61.1477541580290@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-7364:
------------------------------------

    Component/s: Web (Undertow)
       Assignee: Stuart Douglas  (was: Jason Greene)


> java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7364
>                 URL: https://issues.jboss.org/browse/WFLY-7364
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: william teskey
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> [0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> 	at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
> 	at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
> 	at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
> 	at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 00:14:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 27 Oct 2016 00:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7364)
 java.lang.IllegalArgumentException: UT000068: Servlet path match failed
In-Reply-To: <JIRA.12656014.1477000674000@Atlassian.JIRA>
References: <JIRA.12656014.1477000674000@Atlassian.JIRA>
	<JIRA.12656014.1477000674000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656014.1477000674000.65.1477541640147@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312712#comment-13312712 ] 

Stuart Douglas commented on WFLY-7364:
--------------------------------------

Have you somehow removed the default servlet? You get this exception if there is no default servlet and a request does not match a mapped servlet.

> java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7364
>                 URL: https://issues.jboss.org/browse/WFLY-7364
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: william teskey
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> [0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> 	at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
> 	at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
> 	at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
> 	at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 01:04:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 27 Oct 2016 01:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-691) Elytron properties-realm is not
 compatible with legacy user property files
In-Reply-To: <JIRA.12657090.1477483630000@Atlassian.JIRA>
References: <JIRA.12657090.1477483630000@Atlassian.JIRA>
	<JIRA.12657090.1477483630000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657090.1477483630000.97.1477544640274@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312715#comment-13312715 ] 

Ondrej Lukas commented on ELY-691:
----------------------------------

After discussion with Darran we raise this jira to blocker. Issues related to special chars in username are reproducible by add-user utility which breaks backward compatibility with legacy property files.

> Elytron properties-realm is not compatible with legacy user property files
> --------------------------------------------------------------------------
>
>                 Key: ELY-691
>                 URL: https://issues.jboss.org/browse/ELY-691
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.
> Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
> {code}
> elytron:password                            // results to username elytron with password password
> elytronumlaut???=password                   // results to username elytronumlaut??? with password password
> elytron??=password                        // results to username elytron?? with password password
> backslash\\=password                        // results to username backslash\ with password password
> backslash\\inthemiddle=password             // results to username backslash\inthemiddle with password password
> dn\=elytron,dc\=wildfly,dc\=org=password    // results to username dn=elytron,dc=wildfly,dc=org with password password
> elytron1=pass=word                          // results to username elytron1 with password pass=word - covered by JBEAP-6581
> elytron2=password\\                         // results to username elytron2 with password password\
> elytron3=pass\\word                         // results to username elytron3 with password pass\word
> elytron4=passwordWithumlaut???              // results to username elytron4 with password passwordWithumlaut???
> elytron5=??                               // results to username elytron5 with password ??
> {code}
> Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 01:04:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 27 Oct 2016 01:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-691) Elytron properties-realm is not
 compatible with legacy user property files
In-Reply-To: <JIRA.12657090.1477483630000@Atlassian.JIRA>
References: <JIRA.12657090.1477483630000@Atlassian.JIRA>
	<JIRA.12657090.1477483630000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657090.1477483630000.101.1477544640426@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-691:
-----------------------------
    Priority: Blocker  (was: Critical)


> Elytron properties-realm is not compatible with legacy user property files
> --------------------------------------------------------------------------
>
>                 Key: ELY-691
>                 URL: https://issues.jboss.org/browse/ELY-691
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.
> Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
> {code}
> elytron:password                            // results to username elytron with password password
> elytronumlaut???=password                   // results to username elytronumlaut??? with password password
> elytron??=password                        // results to username elytron?? with password password
> backslash\\=password                        // results to username backslash\ with password password
> backslash\\inthemiddle=password             // results to username backslash\inthemiddle with password password
> dn\=elytron,dc\=wildfly,dc\=org=password    // results to username dn=elytron,dc=wildfly,dc=org with password password
> elytron1=pass=word                          // results to username elytron1 with password pass=word - covered by JBEAP-6581
> elytron2=password\\                         // results to username elytron2 with password password\
> elytron3=pass\\word                         // results to username elytron3 with password pass\word
> elytron4=passwordWithumlaut???              // results to username elytron4 with password passwordWithumlaut???
> elytron5=??                               // results to username elytron5 with password ??
> {code}
> Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 01:07:00 2016
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 27 Oct 2016 01:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-688) Elytron Properties realm parses
 password with "=" incorrectly
In-Reply-To: <JIRA.12656257.1477289469000@Atlassian.JIRA>
References: <JIRA.12656257.1477289469000@Atlassian.JIRA>
	<JIRA.12656257.1477289469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656257.1477289469000.114.1477544820299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas closed ELY-688.
----------------------------
    Resolution: Duplicate Issue


Closing as duplicate of ELY-691. This issue is subset of that jira.

> Elytron Properties realm parses password with "=" incorrectly
> -------------------------------------------------------------
>
>                 Key: ELY-688
>                 URL: https://issues.jboss.org/browse/ELY-688
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Dmitrii Tikhomirov
>
> In case when Elytron properties-realm uses plain-text properties file and password includes {{=}} sign then username/password is parsing incorrectly. In case when properties file contains line as {{A=B=C}} then Elytron parses it as user {{A=B}} with password {{C}}. Correct behavior should be user {{A}} with password {{B=C}}.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 02:24:01 2016
From: issues at jboss.org (David Maes (JIRA))
Date: Thu, 27 Oct 2016 02:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after
	undeployment
In-Reply-To: <JIRA.12603477.1455161695000@Atlassian.JIRA>
References: <JIRA.12603477.1455161695000@Atlassian.JIRA>
	<JIRA.12603477.1455161695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603477.1455161695000.246.1477549441185@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Maes updated WFLY-6173:
-----------------------------
    Attachment: Screen Shot 2016-10-27 at 08.04.12.png


> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 02:25:01 2016
From: issues at jboss.org (David Maes (JIRA))
Date: Thu, 27 Oct 2016 02:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after
	undeployment
In-Reply-To: <JIRA.12603477.1455161695000@Atlassian.JIRA>
References: <JIRA.12603477.1455161695000@Atlassian.JIRA>
	<JIRA.12603477.1455161695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603477.1455161695000.271.1477549501760@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312730#comment-13312730 ] 

David Maes commented on WFLY-6173:
----------------------------------

Hey [~mkouba],

I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.

 !Screen Shot 2016-10-27 at 08.04.12.png|thumbnail!  !Screen Shot 2016-10-27 at 08.15.27.png|thumbnail! 

> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 02:25:02 2016
From: issues at jboss.org (David Maes (JIRA))
Date: Thu, 27 Oct 2016 02:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after
	undeployment
In-Reply-To: <JIRA.12603477.1455161695000@Atlassian.JIRA>
References: <JIRA.12603477.1455161695000@Atlassian.JIRA>
	<JIRA.12603477.1455161695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603477.1455161695000.289.1477549502403@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Maes updated WFLY-6173:
-----------------------------
    Attachment: Screen Shot 2016-10-27 at 08.15.27.png


> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png, Screen Shot 2016-10-27 at 08.15.27.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 02:26:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 27 Oct 2016 02:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7393) Elytron Http status code for
 missing LoginPermission
In-Reply-To: <JIRA.12657417.1477549473000@Atlassian.JIRA>
References: <JIRA.12657417.1477549473000@Atlassian.JIRA>
	<JIRA.12657417.1477549473000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657417.1477549473000.314.1477549560282@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6657 to WFLY-7393:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7393  (was: JBEAP-6657)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR7)


> Elytron Http status code for missing LoginPermission
> ----------------------------------------------------
>
>                 Key: WFLY-7393
>                 URL: https://issues.jboss.org/browse/WFLY-7393
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Optional
>
> Lack of {{LoginPermission}} leads to 401 http code. Which could IMO indicate user can try to login again with different password. However it won't help in this case. I wonder, wouldn't 403 Forbidden be more suitable here? Indicating user authentication passed, but user is missing some permission.
> Setting with low priority as in DR7 in default configuration LoginPermission is added by default.
> David: "I think you may be right @MartinChoma - 401 is called "unauthorized" but really it should say "authentication required" 403 is the correct response for an authorization error"



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 02:28:00 2016
From: issues at jboss.org (David Maes (JIRA))
Date: Thu, 27 Oct 2016 02:28:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after
	undeployment
In-Reply-To: <JIRA.12603477.1455161695000@Atlassian.JIRA>
References: <JIRA.12603477.1455161695000@Atlassian.JIRA>
	<JIRA.12603477.1455161695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603477.1455161695000.326.1477549680763@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312730#comment-13312730 ] 

David Maes edited comment on WFLY-6173 at 10/27/16 2:27 AM:
------------------------------------------------------------

Hey [~mkouba],

I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.

 !Screen Shot 2016-10-27 at 08.04.12.png|thumbnail! 


was (Author: davidmaes):
Hey [~mkouba],

I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.

 !Screen Shot 2016-10-27 at 08.04.12.png|thumbnail!  !Screen Shot 2016-10-27 at 08.15.27.png|thumbnail! 

> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png, Screen Shot 2016-10-27 at 08.15.27.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 02:28:01 2016
From: issues at jboss.org (David Maes (JIRA))
Date: Thu, 27 Oct 2016 02:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after
	undeployment
In-Reply-To: <JIRA.12603477.1455161695000@Atlassian.JIRA>
References: <JIRA.12603477.1455161695000@Atlassian.JIRA>
	<JIRA.12603477.1455161695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603477.1455161695000.338.1477549681117@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312730#comment-13312730 ] 

David Maes edited comment on WFLY-6173 at 10/27/16 2:27 AM:
------------------------------------------------------------

Hey [~mkouba],

I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.

 !Screen Shot 2016-10-27 at 08.04.12.png|thumbnail!  !Screen Shot 2016-10-27 at 08.15.27.png|thumbnail! 


was (Author: davidmaes):
Hey [~mkouba],

I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.

 !Screen Shot 2016-10-27 at 08.04.12.png|thumbnail! 

> Classes not unloaded after undeployment
> ---------------------------------------
>
>                 Key: WFLY-6173
>                 URL: https://issues.jboss.org/browse/WFLY-6173
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>            Reporter: Joey Wang
>            Assignee: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png, Screen Shot 2016-10-27 at 08.15.27.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded. 
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 03:42:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 27 Oct 2016 03:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7384) Removal of
 messaging-activemq's server stops Infinispan services
In-Reply-To: <JIRA.12657028.1477468104000@Atlassian.JIRA>
References: <JIRA.12657028.1477468104000@Atlassian.JIRA>
	<JIRA.12657028.1477468104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657028.1477468104000.620.1477554120737@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312754#comment-13312754 ] 

Jeff Mesnil commented on WFLY-7384:
-----------------------------------

[~pferraro] thanks for looking at it

> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
>                 Key: WFLY-7384
>                 URL: https://issues.jboss.org/browse/WFLY-7384
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Paul Ferraro
>         Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 03:43:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 27 Oct 2016 03:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7384) Removal of
 messaging-activemq's server stops Infinispan services
In-Reply-To: <JIRA.12657028.1477468104000@Atlassian.JIRA>
References: <JIRA.12657028.1477468104000@Atlassian.JIRA>
	<JIRA.12657028.1477468104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657028.1477468104000.627.1477554180455@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil resolved WFLY-7384.
-------------------------------
    Resolution: Rejected


> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
>                 Key: WFLY-7384
>                 URL: https://issues.jboss.org/browse/WFLY-7384
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Paul Ferraro
>         Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 04:26:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 27 Oct 2016 04:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1868) wrong parse of double quote
	in `\\"`
In-Reply-To: <JIRA.12655227.1476700310000@Atlassian.JIRA>
References: <JIRA.12655227.1476700310000@Atlassian.JIRA>
	<JIRA.12655227.1476700310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655227.1476700310000.823.1477556760502@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise closed WFCORE-1868.
----------------------------------------
    Resolution: Done


The issue has been fixed in Aesh 0.66.+ branch, 0.66.12-SNAPSHOT.

> wrong parse of double quote in `\\"` 
> -------------------------------------
>
>                 Key: WFCORE-1868
>                 URL: https://issues.jboss.org/browse/WFCORE-1868
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>         Environment: JBoss EAP 7.0.0
>            Reporter: Hisanobu Okuda
>            Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is 
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone at localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> > 
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 04:45:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 27 Oct 2016 04:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1344) Add documentation for
 Aries-Blueprint integration
In-Reply-To: <JIRA.12657445.1477557846000@Atlassian.JIRA>
References: <JIRA.12657445.1477557846000@Atlassian.JIRA>
	<JIRA.12657445.1477557846693@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657445.1477557846000.895.1477557900114@Atlassian.JIRA>

Mario Fusco created DROOLS-1344:
-----------------------------------

             Summary: Add documentation for Aries-Blueprint integration
                 Key: DROOLS-1344
                 URL: https://issues.jboss.org/browse/DROOLS-1344
             Project: Drools
          Issue Type: Task
          Components: docs
            Reporter: Mario Fusco
            Assignee: Mario Fusco
            Priority: Critical






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 04:56:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 04:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7208) Integration of Web-Services
 with transactions during the graceful shutdown
In-Reply-To: <JIRA.12651813.1474642960000@Atlassian.JIRA>
References: <JIRA.12651813.1474642960000@Atlassian.JIRA>
	<JIRA.12651813.1474642960000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651813.1474642960000.947.1477558560707@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-7208:
--------------------------------
    Summary: Integration of Web-Services with transactions during the graceful shutdown  (was: Integration with transactions during the graceful shutdown)


> Integration of Web-Services with transactions during the graceful shutdown
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7208
>                 URL: https://issues.jboss.org/browse/WFLY-7208
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Services
>            Reporter: Gytis Trikleris
>            Assignee: Alessio Soldano
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> During the graceful shutdown Web Services subsystem should consult XTS subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of WS-AT or WS-BA transaction and return the outcome.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 04:56:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 04:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7207) Integration of EJB with
 transactions during the graceful shutdown
In-Reply-To: <JIRA.12651810.1474642765000@Atlassian.JIRA>
References: <JIRA.12651810.1474642765000@Atlassian.JIRA>
	<JIRA.12651810.1474642765000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651810.1474642765000.951.1477558560922@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-7207:
--------------------------------
    Summary: Integration of EJB with transactions during the graceful shutdown  (was: Integration with transactions during the graceful shutdown)


> Integration of EJB with transactions during the graceful shutdown
> -----------------------------------------------------------------
>
>                 Key: WFLY-7207
>                 URL: https://issues.jboss.org/browse/WFLY-7207
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Gytis Trikleris
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 05:24:00 2016
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Thu, 27 Oct 2016 05:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6271) SFSB methods can still be
 invoked after a calling transaction has rollbacked
In-Reply-To: <JIRA.12607549.1456323191000@Atlassian.JIRA>
References: <JIRA.12607549.1456323191000@Atlassian.JIRA>
	<JIRA.12607549.1456323191000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12607549.1456323191000.1223.1477560240342@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312808#comment-13312808 ] 

Ryan Emerson commented on WFLY-6271:
------------------------------------

[~swd847] I haven't been working on wildfly for a while now, so I'm not sure if this was resolved as part of your solution to WFLY-6215. I'm not currently able to dedicate any time to this issue, so I have unassigned myself.

> SFSB methods can still be invoked after a calling transaction has rollbacked
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-6271
>                 URL: https://issues.jboss.org/browse/WFLY-6271
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 05:24:00 2016
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Thu, 27 Oct 2016 05:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6271) SFSB methods can still be
 invoked after a calling transaction has rollbacked
In-Reply-To: <JIRA.12607549.1456323191000@Atlassian.JIRA>
References: <JIRA.12607549.1456323191000@Atlassian.JIRA>
	<JIRA.12607549.1456323191000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12607549.1456323191000.1227.1477560240499@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Emerson reassigned WFLY-6271:
----------------------------------

    Assignee:     (was: Ryan Emerson)


> SFSB methods can still be invoked after a calling transaction has rollbacked
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-6271
>                 URL: https://issues.jboss.org/browse/WFLY-6271
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Ryan Emerson
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 05:41:00 2016
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 27 Oct 2016 05:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1817) upgrade Xerces to 2.11.0.SP5
In-Reply-To: <JIRA.12651825.1474646665000@Atlassian.JIRA>
References: <JIRA.12651825.1474646665000@Atlassian.JIRA>
	<JIRA.12651825.1474646665000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651825.1474646665000.1461.1477561260529@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312826#comment-13312826 ] 

Carlo de Wolf commented on WFCORE-1817:
---------------------------------------

https://github.com/jboss/xerces/tree/jboss-2.11.0.SP5

> upgrade Xerces to 2.11.0.SP5
> ----------------------------
>
>                 Key: WFCORE-1817
>                 URL: https://issues.jboss.org/browse/WFCORE-1817
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 3.0.0.Alpha9, 2.2.1.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 05:50:00 2016
From: issues at jboss.org (Marek Czernek (JIRA))
Date: Thu, 27 Oct 2016 05:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1344) Add documentation for
 Aries-Blueprint integration
In-Reply-To: <JIRA.12657445.1477557847000@Atlassian.JIRA>
References: <JIRA.12657445.1477557847000@Atlassian.JIRA>
	<JIRA.12657445.1477557847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657445.1477557847000.1562.1477561800210@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312833#comment-13312833 ] 

Marek Czernek commented on DROOLS-1344:
---------------------------------------

[~kdwivedi], I have talked to Mario about this issue (docs jira linked). We do not have any Aries BP docs in our current guides (upstream nor downstream). If this issue blocks our release, as suggested by [~rsynek], this should be addressed (and incorporated in the downstream docs) by 6.4 release. I am not sure whether Mario has the time to finish this jira on time, maybe prioritization is in order? WDYT? 

> Add documentation for Aries-Blueprint integration
> -------------------------------------------------
>
>                 Key: DROOLS-1344
>                 URL: https://issues.jboss.org/browse/DROOLS-1344
>             Project: Drools
>          Issue Type: Task
>          Components: docs
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>            Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:07:01 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 27 Oct 2016 06:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1901) Fail in finally block
 overrides the fail in catch block
In-Reply-To: <JIRA.12657482.1477562786000@Atlassian.JIRA>
References: <JIRA.12657482.1477562786000@Atlassian.JIRA>
	<JIRA.12657482.1477562786530@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657482.1477562786000.1717.1477562821087@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-1901:
--------------------------------------------

             Summary: Fail in finally block overrides the fail in catch block
                 Key: WFCORE-1901
                 URL: https://issues.jboss.org/browse/WFCORE-1901
             Project: WildFly Core
          Issue Type: Feature Request
          Components: CLI
            Reporter: Jean-Francois Denise


Information of the thrown exception is thrown.




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:08:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 27 Oct 2016 06:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1901) Fail in finally block
 overrides the fail in catch block
In-Reply-To: <JIRA.12657482.1477562787000@Atlassian.JIRA>
References: <JIRA.12657482.1477562787000@Atlassian.JIRA>
	<JIRA.12657482.1477562787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657482.1477562787000.1734.1477562880564@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-1901:
--------------------------------------------

    Assignee: Jean-Francois Denise


> Fail in finally block overrides the fail in catch block
> -------------------------------------------------------
>
>                 Key: WFCORE-1901
>                 URL: https://issues.jboss.org/browse/WFCORE-1901
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> Information of the thrown exception is thrown.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:21:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 27 Oct 2016 06:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7334) Elytron kerberos
 implementation ignore java.security.krb5.* system properties
In-Reply-To: <JIRA.12655486.1476795296000@Atlassian.JIRA>
References: <JIRA.12655486.1476795296000@Atlassian.JIRA>
	<JIRA.12655486.1476795296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655486.1476795296000.1805.1477563660301@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312853#comment-13312853 ] 

Jan Kalina commented on WFLY-7334:
----------------------------------

[~mchoma] Sorry, I has mistaken, the correct krb5.conf works correctly even without *refreshKrb5Config* option - no need to set it.

> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-7334
>                 URL: https://issues.jboss.org/browse/WFLY-7334
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code} 
> -Djava.security.krb5.conf=/unreal/path  -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
>         <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
>         <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
>         <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
>         <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:26:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 06:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1119) Assign an unique NodeID
	automatically
In-Reply-To: <JIRA.12465660.1336061692000@Atlassian.JIRA>
References: <JIRA.12465660.1336061692000@Atlassian.JIRA>
	<JIRA.12465660.1336061692000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465660.1336061692000.1887.1477563960575@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson closed WFLY-1119.
-------------------------------
    Resolution: Rejected


> Assign an unique NodeID automatically
> -------------------------------------
>
>                 Key: WFLY-1119
>                 URL: https://issues.jboss.org/browse/WFLY-1119
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Transactions
>            Reporter: Clebert Suconic
>            Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:26:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 06:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1119) Assign an unique NodeID
	automatically
In-Reply-To: <JIRA.12465660.1336061692000@Atlassian.JIRA>
References: <JIRA.12465660.1336061692000@Atlassian.JIRA>
	<JIRA.12465660.1336061692000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465660.1336061692000.1902.1477563960912@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312859#comment-13312859 ] 

Tom Jenkinson commented on WFLY-1119:
-------------------------------------

For me, the user should be forced to do this because it carries risk.

> Assign an unique NodeID automatically
> -------------------------------------
>
>                 Key: WFLY-1119
>                 URL: https://issues.jboss.org/browse/WFLY-1119
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Transactions
>            Reporter: Clebert Suconic
>            Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:27:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 06:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5703) Add an IBM ORB configuration
	to WildFly
In-Reply-To: <JIRA.12589554.1445251334000@Atlassian.JIRA>
References: <JIRA.12589554.1445251334000@Atlassian.JIRA>
	<JIRA.12589554.1445251334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589554.1445251334000.1910.1477564020626@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson closed WFLY-5703.
-------------------------------
    Resolution: Deferred


Wait till the ORB is supported

> Add an IBM ORB configuration to WildFly
> ---------------------------------------
>
>                 Key: WFLY-5703
>                 URL: https://issues.jboss.org/browse/WFLY-5703
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: IIOP, Transactions
>            Reporter: Tom Jenkinson
>            Priority: Optional
>
> Placeholder to be moved to WFLY
> I guess it finally caught us after an .m2 wipe?
> http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-ibm-jdk/139/console



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:28:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1033) Enhance XTS AS7 configuration
In-Reply-To: <JIRA.12442503.1311587320000@Atlassian.JIRA>
References: <JIRA.12442503.1311587320000@Atlassian.JIRA>
	<JIRA.12442503.1311587320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442503.1311587320000.1941.1477564081175@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson closed WFLY-1033.
-------------------------------
    Resolution: Deferred


Although this would be possible we do not have customer/user requests for it

> Enhance XTS AS7 configuration
> -----------------------------
>
>                 Key: WFLY-1033
>                 URL: https://issues.jboss.org/browse/WFLY-1033
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: XTS
>            Reporter: Andrew Dinn
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:29:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 06:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6290) XTS does not work with
 jbossws.undefined.host in WS config
In-Reply-To: <JIRA.12607919.1456488654000@Atlassian.JIRA>
References: <JIRA.12607919.1456488654000@Atlassian.JIRA>
	<JIRA.12607919.1456488654000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12607919.1456488654000.1959.1477564141043@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson reassigned WFLY-6290:
-----------------------------------

    Assignee: Ivo Studensky  (was: Gytis Trikleris)


> XTS does not work with jbossws.undefined.host in WS config
> ----------------------------------------------------------
>
>                 Key: WFLY-6290
>                 URL: https://issues.jboss.org/browse/WFLY-6290
>             Project: WildFly
>          Issue Type: Bug
>          Components: XTS
>            Reporter: Gytis Trikleris
>            Assignee: Ivo Studensky
>             Fix For: 10.2.0.Final
>
>
> XTS uses ServerConfig to initialise it's configuration. However, we should rely on jboss.bind.address instead, because wsdl-host could take "jbossws.undefined.host" as a value.
> "jbossws.undefined.host" will cause UnknownHostException, because address rewriting is not executed in XTS.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:30:00 2016
From: issues at jboss.org (Martin Letenay (JIRA))
Date: Thu, 27 Oct 2016 06:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-864) NameNotFoundException due
 to policyRegistration -- service
 jboss.naming.context.java.policyRegistration
In-Reply-To: <JIRA.12555624.1413874116000@Atlassian.JIRA>
References: <JIRA.12555624.1413874116000@Atlassian.JIRA>
	<JIRA.12555624.1413874116000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555624.1413874116000.1973.1477564200503@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312864#comment-13312864 ] 

Martin Letenay commented on SECURITY-864:
-----------------------------------------

We have faced this problem after upgrade from JBoss 7.1 to Wildfly 9.
However, it is not only cosmetic but has severe negative performance implications.
Our application is EJB invocation intensive (invokes various EJB calls tens or hundreds times) and the performance after switch from 7.1 to 9.0 was 10 times slower !

>From the picketbox code inspection it seems the {{EJBAuthorizationHelper}} is trying to pass the {{PolicyRegistration}} instance into the underlying {{AuthorizationModuleDelegate}} during every EJB method invocation authorization phase.
However, the {{PolicyRegistration}} seems to be relevant only for XACML security configurations.
For plain Delegate or JACC authorization modules the {{PolicyRegistration}} is never used (and never created).

When e.g. JACC authorization is used, the (unsuccessful) JNDI lookup is performed for each and every (secured) EJB invocation and it results in unnecessary performance degradation.

We couldn't find anywhere in the documentation or the code where the PolicyRegistration si being put into the JNDI tree.
Since we're using custom LoginModule implementation, we have developed a temporary workaround that during initialization of JAAS LoginModule we check the existence of the {{java:/policyRegistration}} JNDI resource and if it is missing (actually always), we instantiate the {{org.jboss.security.plugins.JBossPolicyRegistration}} and bind it into JNDI tree.
After this workaround, the performance of our application went back to normal times as of JBoss 7.1, i.e. nearly 10 times faster.

It would be really nice to have this issue resolved properly (e.g. by storing negative JNDI lookup or registering the policy also for Delegate/JACC modules).


> NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
> -------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-864
>                 URL: https://issues.jboss.org/browse/SECURITY-864
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: PicketBox
>            Reporter: Chao Wang
>            Assignee: Stefan Guilhen
>
> "NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level: 
> {noformat}
>             <logger category="org.jboss.as.security">
>                 <level name="TRACE"/>
>             </logger>
>             <logger category="org.jboss.security">
>                 <level name="TRACE"/>
>             </logger>
> {noformat}
> See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134]
> I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException"



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:30:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 06:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6966) FatalError on Transaction
 Expired Entry Monitor during server shutdown
In-Reply-To: <JIRA.12643661.1471423266000@Atlassian.JIRA>
References: <JIRA.12643661.1471423266000@Atlassian.JIRA>
	<JIRA.12643661.1471423266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643661.1471423266000.1982.1477564200811@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson closed WFLY-6966.
-------------------------------
    Resolution: Rejected


I don't believe it is specified in WFLY that there will be no errors so I propose to close this unless it is reopened as a system wide policy

> FatalError on Transaction Expired Entry Monitor during server shutdown
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6966
>                 URL: https://issues.jboss.org/browse/WFLY-6966
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: IIOP, Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Minor
>
> I do experience intermittent errors being shown in server log during server shutdown. It happens time to time for server configured to use {{JTS}} transaction that {{Transaction Expired Entry Monitor}} shows {{FatalError}} during container shutdown.
> I do experience this failure when jdbc object store is used.
> The shutdown log looks
> {code}
> 2016-08-16 07:07:46,900 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment wmq.jmsra.rar (runtime-name: wmq.jmsra.rar) in 132ms
> 2016-08-16 07:07:46,914 INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 2016-08-16 07:07:46,914 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2016-08-16 07:07:46,915 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 2016-08-16 07:07:46,921 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2016-08-16 07:07:46,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment crashrecovery-jms-stateless-cmt.jar (runtime-name: crashrecovery-jms-stateless-cmt.jar) in 156ms
> 2016-08-16 07:07:46,947 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2016-08-16 07:07:46,952 TRACE [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) InputObjectState::InputObjectState(0:ffff7f000001:55f44a88:57b2ec0b:8, Recovery/FactoryContact)
> 2016-08-16 07:07:46,959 INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 32) AMQ151003: resource adaptor stopped
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) ORB::shutdown ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) OA::destroyRootPOA ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) RootOA::shutdownObject (Servant)
> 2016-08-16 07:07:46,962 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032018: Destroying TransactionManagerService
> 2016-08-16 07:07:46,963 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032014: Stopping transaction recovery manager
> 2016-08-16 07:07:47,000 FATAL [com.arjuna.ats.jts] (Transaction Expired Entry Monitor) ARJUNA022006: The ORB has not been initialized yet
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) Exception in thread "Transaction Expired Entry Monitor" com.arjuna.ats.arjuna.exceptions.FatalError
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.ORBManager.getORB(ORBManager.java:56)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restore_state(FactoryContactItem.java:264)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restoreMe(FactoryContactItem.java:320)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.recreate(FactoryContactItem.java:100)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner.scan(ExpiredContactScanner.java:99)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171)
> 2016-08-16 07:07:47,001 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: Mode <== TERMINATED
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown waiting for scan to end
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan TERMINATED at phase 1
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown scan wait complete
> 2016-08-16 07:07:47,003 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0010: Unbound data source [java:jboss/datasources/jdbc-store]
> 2016-08-16 07:07:47,006 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = module_postgresql-9.4.1207.jar
> 2016-08-16 07:07:47,012 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 32) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0.SP16-redhat-1 [023d1e88-638c-11e6-927a-a180c25082cf] stopped
> 2016-08-16 07:07:47,012 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 2016-08-16 07:07:47,018 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 250ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:33:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 06:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5574)
 org.wildfly.test.extension.rts InboundBridgeTestCase failing when
 transaction uses JTS
In-Reply-To: <JIRA.12590336.1445848456000@Atlassian.JIRA>
References: <JIRA.12590336.1445848456000@Atlassian.JIRA>
	<JIRA.12590336.1445848456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12590336.1445848456000.2013.1477564380545@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5574:
--------------------------------
    Priority: Minor  (was: Major)


> org.wildfly.test.extension.rts InboundBridgeTestCase failing when transaction uses JTS
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5574
>                 URL: https://issues.jboss.org/browse/WFLY-5574
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite, Transactions
>    Affects Versions: 10.0.0.CR3
>            Reporter: Ondra Chaloupka
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 11.0.0.CR1
>
>         Attachments: server.log
>
>
> There is failures in testcase org.wildfly.test.extension.rts.InboundBridgeTestCase when transaction uses JTS.
> Example of the failure
> {code}
> testCommit(org.wildfly.test.extension.rts.InboundBridgeTestCase)  Time elapsed: 2.54 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<4> but was:<5> 
> {code}
> The JBOSS_HOME distribution is change to transaction to be run with JTS: changing the {{docs/example/standalone-rts.xml}} to switch transactions parameter in iiop orb subsystem to {{full}} and adding {{jts}} element to transactions subsystem.
> When JBOSS_HOME is set then I've run the test in this way
> {{./integration-tests.sh clean install -Dts.noSmoke -Dts.rts -Djboss.dist=$JBOSS_HOME -Dtest=InboundBridgeTestCase}}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:35:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 06:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5522) split artemis journal in its
	own module
In-Reply-To: <JIRA.12588882.1444735181000@Atlassian.JIRA>
References: <JIRA.12588882.1444735181000@Atlassian.JIRA>
	<JIRA.12588882.1444735181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588882.1444735181000.2039.1477564500730@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5522:
--------------------------------
    Component/s:     (was: Transactions)


> split artemis journal in its own module
> ---------------------------------------
>
>                 Key: WFLY-5522
>                 URL: https://issues.jboss.org/browse/WFLY-5522
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.0.0.CR2
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> The org.jboss.jts is depending on the org.apache.activemq.artemis only for its journal functionality but get all the module dependencies (including messaging stuff) that is not used at all.
> The org.apache.activemq.artemis should be split with a separate module for its journal containing the journal jar + commons jar + native lib required for libAIO.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:37:00 2016
From: issues at jboss.org (Marek Czernek (JIRA))
Date: Thu, 27 Oct 2016 06:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1344) Add documentation for
 Aries-Blueprint integration
In-Reply-To: <JIRA.12657445.1477557847000@Atlassian.JIRA>
References: <JIRA.12657445.1477557847000@Atlassian.JIRA>
	<JIRA.12657445.1477557847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657445.1477557847000.2069.1477564620526@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312872#comment-13312872 ] 

Marek Czernek commented on DROOLS-1344:
---------------------------------------

Amazingly fast work from Mario... I'll incorporate the [PR|https://github.com/droolsjbpm/kie-docs/pull/183/commits/9e045146a014402fba5e25833a6382a3583a588d] myself.

> Add documentation for Aries-Blueprint integration
> -------------------------------------------------
>
>                 Key: DROOLS-1344
>                 URL: https://issues.jboss.org/browse/DROOLS-1344
>             Project: Drools
>          Issue Type: Task
>          Components: docs
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>            Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 06:39:00 2016
From: issues at jboss.org (=?UTF-8?Q?Bj=C3=B6rn_Kautler_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 06:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-78) Invalid manifest section in
	jboss-sasl JAR
In-Reply-To: <JIRA.12657494.1477564710000@Atlassian.JIRA>
References: <JIRA.12657494.1477564710000@Atlassian.JIRA>
	<JIRA.12657494.1477564710979@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657494.1477564710000.2086.1477564740548@Atlassian.JIRA>

Bj?rn Kautler created SASL-78:
---------------------------------

             Summary: Invalid manifest section in jboss-sasl JAR
                 Key: SASL-78
                 URL: https://issues.jboss.org/browse/SASL-78
             Project: SASL Provider
          Issue Type: Bug
          Components: Build
    Affects Versions: 1.0.5.Final, 1.0.4.Final
            Reporter: Bj?rn Kautler
            Assignee: Darran Lofthouse


In the {{MANIFEST.MF}} of your {{jboss-sasl}} JAR you have a section {{Build-Information}}.
This violates that JAR specification.
A section in the manifest always refers to an entry in the JAR.
If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest.
Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. (You are still using jboss-parent 7, if you upgrade to 8 or newer, the problem will be gone)

----

In my concrete use-case this happened with other JARs with invalid manifest entries:

- I have signed those JARs and included them in a WebStart application
- I started the application with 8u102 32-bit {{javaws}}
- The JARs were downloaded and their entries signatures verified
- As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed

This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse:

- The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM
- The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again
- Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between
- If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution

Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections.




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 06:55:31 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 27 Oct 2016 06:55:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-78) Invalid manifest section in
	jboss-sasl JAR
In-Reply-To: <JIRA.12657494.1477564711000@Atlassian.JIRA>
References: <JIRA.12657494.1477564711000@Atlassian.JIRA>
	<JIRA.12657494.1477564711000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657494.1477564711000.2216.1477565731543@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SASL-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312889#comment-13312889 ] 

Darran Lofthouse commented on SASL-78:
--------------------------------------

This project has now been superseded by the WildFly Elytron project - in what context is this being used?  Are you using it when communicating with JBoss / WildFly?

> Invalid manifest section in jboss-sasl JAR
> ------------------------------------------
>
>                 Key: SASL-78
>                 URL: https://issues.jboss.org/browse/SASL-78
>             Project: SASL Provider
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.4.Final, 1.0.5.Final
>            Reporter: Bj?rn Kautler
>            Assignee: Darran Lofthouse
>
> In the {{MANIFEST.MF}} of your {{jboss-sasl}} JAR you have a section {{Build-Information}}.
> This violates that JAR specification.
> A section in the manifest always refers to an entry in the JAR.
> If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest.
> Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. (You are still using jboss-parent 7, if you upgrade to 8 or newer, the problem will be gone)
> ----
> In my concrete use-case this happened with other JARs with invalid manifest entries:
> - I have signed those JARs and included them in a WebStart application
> - I started the application with 8u102 32-bit {{javaws}}
> - The JARs were downloaded and their entries signatures verified
> - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed
> This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse:
> - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM
> - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again
> - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between
> - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution
> Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 07:13:00 2016
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 07:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1345) Drop support for JSR94
	integration?
In-Reply-To: <JIRA.12657501.1477566740000@Atlassian.JIRA>
References: <JIRA.12657501.1477566740000@Atlassian.JIRA>
	<JIRA.12657501.1477566740746@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657501.1477566740000.2338.1477566780184@Atlassian.JIRA>

Petr ?irok? created DROOLS-1345:
-----------------------------------

             Summary: Drop support for JSR94 integration?
                 Key: DROOLS-1345
                 URL: https://issues.jboss.org/browse/DROOLS-1345
             Project: Drools
          Issue Type: Task
          Components: core engine
    Affects Versions: 7.0.0.Beta2
            Reporter: Petr ?irok?
            Assignee: Petr ?irok?


Drools JSR94 integration seems to be unused and unmaintained. Could we remote it for 7.x?



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 07:20:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Oct 2016 07:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-893) Second security vault
 warning is displayed even if only one vault definition is present in the
 server configuration
In-Reply-To: <JIRA.12574614.1434011672000@Atlassian.JIRA>
References: <JIRA.12574614.1434011672000@Atlassian.JIRA>
	<JIRA.12574614.1434011672000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574614.1434011672000.2350.1477567200440@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312903#comment-13312903 ] 

RH Bugzilla Integration commented on SECURITY-893:
--------------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1389201|https://bugzilla.redhat.com/show_bug.cgi?id=1389201] from ASSIGNED to POST

> Second security vault warning is displayed even if only one vault definition is present in the server configuration
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-893
>                 URL: https://issues.jboss.org/browse/SECURITY-893
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>    Affects Versions: PicketBox_4_1_0.Beta2
>            Reporter: Ivo Studensky
>            Assignee: Peter Skopek
>
> The BZ's description:
> I have only one vault configured in the standalone.xml but I see following warning message in the server log file after login attempt (bindCredentials login module option uses a vaulted password):
> {noformat}
> 09:10:58,854 WARN  [org.jboss.security] (http-/127.0.0.1:8080-1) PBOX000378: Attempt to create the second Security Vault [org.picketbox.plugins.vault.PicketBoxSecurityVault] is invalid. Only one Security Vault is supported. Change your configuration, please.
> {noformat}
> This issue is related to the previous fix for bz1055577, \[1\]. The problem needs to be fixed on EAP side in time of Security Subsystem configuration processing. Fix will be provided by bz1181457 \[2\].
> \[1\] https://bugzilla.redhat.com/show_bug.cgi?id=1055577
> \[2\] https://bugzilla.redhat.com/show_bug.cgi?id=1181457



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 07:22:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 27 Oct 2016 07:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-691) Elytron properties-realm is not
 compatible with legacy user property files
In-Reply-To: <JIRA.12657090.1477483630000@Atlassian.JIRA>
References: <JIRA.12657090.1477483630000@Atlassian.JIRA>
	<JIRA.12657090.1477483630000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657090.1477483630000.2381.1477567321110@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-691:
------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Elytron properties-realm is not compatible with legacy user property files
> --------------------------------------------------------------------------
>
>                 Key: ELY-691
>                 URL: https://issues.jboss.org/browse/ELY-691
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.
> Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
> {code}
> elytron:password                            // results to username elytron with password password
> elytronumlaut???=password                   // results to username elytronumlaut??? with password password
> elytron??=password                        // results to username elytron?? with password password
> backslash\\=password                        // results to username backslash\ with password password
> backslash\\inthemiddle=password             // results to username backslash\inthemiddle with password password
> dn\=elytron,dc\=wildfly,dc\=org=password    // results to username dn=elytron,dc=wildfly,dc=org with password password
> elytron1=pass=word                          // results to username elytron1 with password pass=word - covered by JBEAP-6581
> elytron2=password\\                         // results to username elytron2 with password password\
> elytron3=pass\\word                         // results to username elytron3 with password pass\word
> elytron4=passwordWithumlaut???              // results to username elytron4 with password passwordWithumlaut???
> elytron5=??                               // results to username elytron5 with password ??
> {code}
> Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 07:31:00 2016
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 07:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1902) Error messages from CLI
 batch should be more informative
In-Reply-To: <JIRA.12657504.1477567805000@Atlassian.JIRA>
References: <JIRA.12657504.1477567805000@Atlassian.JIRA>
	<JIRA.12657504.1477567805294@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657504.1477567805000.2513.1477567860153@Atlassian.JIRA>

Marek Kopeck? created WFCORE-1902:
-------------------------------------

             Summary: Error messages from CLI batch should be more informative
                 Key: WFCORE-1902
                 URL: https://issues.jboss.org/browse/WFCORE-1902
             Project: WildFly Core
          Issue Type: Feature Request
          Components: CLI
    Affects Versions: 3.0.0.Alpha10
            Reporter: Marek Kopeck?


*Description of problem:*
Error messages from CLI batch should be more informative

*Steps to Reproduce:*
{noformat}
cat <<EOF >a
batch
:read-attribute(name=product-version)
:read-attribute(name=product-name)
:read-attribute(name=nonsence)
:read-attribute(name=product-name)
run-batch
EOF
./jboss-cli.sh -c --file=a
{noformat}

*Actual results:*
{noformat}
The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
{noformat}

*Expected results:*
I can imagine content like following could be helpful for troubleshooting:
{noformat}
{
   "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
      "Operation step-3" => {
         "line number" => 4
         "operation" => ":read-attribute(name=nonsence)"
         "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
   }
}
{noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 07:34:05 2016
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 07:34:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1902) Error messages from CLI
 batch should be more informative
In-Reply-To: <JIRA.12657504.1477567805000@Atlassian.JIRA>
References: <JIRA.12657504.1477567805000@Atlassian.JIRA>
	<JIRA.12657504.1477567805000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657504.1477567805000.2521.1477568045214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? reassigned WFCORE-1902:
-------------------------------------

    Assignee: Jean-Francois Denise


> Error messages from CLI batch should be more informative
> --------------------------------------------------------
>
>                 Key: WFCORE-1902
>                 URL: https://issues.jboss.org/browse/WFCORE-1902
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Error messages from CLI batch should be more informative
> *Steps to Reproduce:*
> {noformat}
> cat <<EOF >a
> batch
> :read-attribute(name=product-version)
> :read-attribute(name=product-name)
> :read-attribute(name=nonsence)
> :read-attribute(name=product-name)
> run-batch
> EOF
> ./jboss-cli.sh -c --file=a
> {noformat}
> *Actual results:*
> {noformat}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
> {noformat}
> *Expected results:*
> I can imagine content like following could be helpful for troubleshooting:
> {noformat}
> {
>    "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
>       "Operation step-3" => {
>          "line number" => 4
>          "operation" => ":read-attribute(name=nonsence)"
>          "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
>    }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 07:47:00 2016
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 07:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1902) Error messages from CLI
 batch should be more informative
In-Reply-To: <JIRA.12657504.1477567805000@Atlassian.JIRA>
References: <JIRA.12657504.1477567805000@Atlassian.JIRA>
	<JIRA.12657504.1477567805000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657504.1477567805000.2628.1477568820151@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312923#comment-13312923 ] 

Marek Kopeck? commented on WFCORE-1902:
---------------------------------------

[~jdenise]: WDYT about this feature request in current CLI? What about CLI next and this feature?

> Error messages from CLI batch should be more informative
> --------------------------------------------------------
>
>                 Key: WFCORE-1902
>                 URL: https://issues.jboss.org/browse/WFCORE-1902
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Error messages from CLI batch should be more informative
> *Steps to Reproduce:*
> {noformat}
> cat <<EOF >a
> batch
> :read-attribute(name=product-version)
> :read-attribute(name=product-name)
> :read-attribute(name=nonsence)
> :read-attribute(name=product-name)
> run-batch
> EOF
> ./jboss-cli.sh -c --file=a
> {noformat}
> *Actual results:*
> {noformat}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
> {noformat}
> *Expected results:*
> I can imagine content like following could be helpful for troubleshooting:
> {noformat}
> {
>    "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
>       "Operation step-3" => {
>          "line number" => 4
>          "operation" => ":read-attribute(name=nonsence)"
>          "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
>    }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 08:00:01 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 27 Oct 2016 08:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6966) FatalError on Transaction
 Expired Entry Monitor during server shutdown
In-Reply-To: <JIRA.12643661.1471423266000@Atlassian.JIRA>
References: <JIRA.12643661.1471423266000@Atlassian.JIRA>
	<JIRA.12643661.1471423266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643661.1471423266000.2702.1477569601226@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reopened WFLY-6966:
-------------------------------


AFAIK it has always been a policy that there are no errors on shutdown, since day one.  In any event, community issues should not be closed unless they are either done, or it is determined that they _should not_ be done.  Otherwise leave them open for community contributors (maybe unassign them if you don't intend to work this issue).

> FatalError on Transaction Expired Entry Monitor during server shutdown
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6966
>                 URL: https://issues.jboss.org/browse/WFLY-6966
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: IIOP, Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Minor
>
> I do experience intermittent errors being shown in server log during server shutdown. It happens time to time for server configured to use {{JTS}} transaction that {{Transaction Expired Entry Monitor}} shows {{FatalError}} during container shutdown.
> I do experience this failure when jdbc object store is used.
> The shutdown log looks
> {code}
> 2016-08-16 07:07:46,900 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment wmq.jmsra.rar (runtime-name: wmq.jmsra.rar) in 132ms
> 2016-08-16 07:07:46,914 INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 2016-08-16 07:07:46,914 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2016-08-16 07:07:46,915 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 2016-08-16 07:07:46,921 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2016-08-16 07:07:46,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment crashrecovery-jms-stateless-cmt.jar (runtime-name: crashrecovery-jms-stateless-cmt.jar) in 156ms
> 2016-08-16 07:07:46,947 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2016-08-16 07:07:46,952 TRACE [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) InputObjectState::InputObjectState(0:ffff7f000001:55f44a88:57b2ec0b:8, Recovery/FactoryContact)
> 2016-08-16 07:07:46,959 INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 32) AMQ151003: resource adaptor stopped
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) ORB::shutdown ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) OA::destroyRootPOA ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) RootOA::shutdownObject (Servant)
> 2016-08-16 07:07:46,962 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032018: Destroying TransactionManagerService
> 2016-08-16 07:07:46,963 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032014: Stopping transaction recovery manager
> 2016-08-16 07:07:47,000 FATAL [com.arjuna.ats.jts] (Transaction Expired Entry Monitor) ARJUNA022006: The ORB has not been initialized yet
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) Exception in thread "Transaction Expired Entry Monitor" com.arjuna.ats.arjuna.exceptions.FatalError
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.ORBManager.getORB(ORBManager.java:56)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restore_state(FactoryContactItem.java:264)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restoreMe(FactoryContactItem.java:320)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.recreate(FactoryContactItem.java:100)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner.scan(ExpiredContactScanner.java:99)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171)
> 2016-08-16 07:07:47,001 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: Mode <== TERMINATED
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown waiting for scan to end
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan TERMINATED at phase 1
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown scan wait complete
> 2016-08-16 07:07:47,003 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0010: Unbound data source [java:jboss/datasources/jdbc-store]
> 2016-08-16 07:07:47,006 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = module_postgresql-9.4.1207.jar
> 2016-08-16 07:07:47,012 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 32) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0.SP16-redhat-1 [023d1e88-638c-11e6-927a-a180c25082cf] stopped
> 2016-08-16 07:07:47,012 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 2016-08-16 07:07:47,018 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 250ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:05:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 27 Oct 2016 08:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1033) Enhance XTS AS7 configuration
In-Reply-To: <JIRA.12442503.1311587320000@Atlassian.JIRA>
References: <JIRA.12442503.1311587320000@Atlassian.JIRA>
	<JIRA.12442503.1311587320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442503.1311587320000.2715.1477569900778@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reopened WFLY-1033:
-------------------------------
      Assignee:     (was: Gytis Trikleris)


If there is no intention to work this issue, it should be left open but unassigned, in case a community member wants to pick it up - unless it is determined that this should never be done for some reason.

> Enhance XTS AS7 configuration
> -----------------------------
>
>                 Key: WFLY-1033
>                 URL: https://issues.jboss.org/browse/WFLY-1033
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: XTS
>            Reporter: Andrew Dinn
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:07:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 27 Oct 2016 08:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5703) Add an IBM ORB configuration
	to WildFly
In-Reply-To: <JIRA.12589554.1445251334000@Atlassian.JIRA>
References: <JIRA.12589554.1445251334000@Atlassian.JIRA>
	<JIRA.12589554.1445251334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589554.1445251334000.2724.1477570020209@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312931#comment-13312931 ] 

David Lloyd commented on WFLY-5703:
-----------------------------------

If there is no intention to work this issue, it should be left open but unassigned, in case a community member wants to pick it up - unless it is determined that this should never be done for some reason.  In this case it's up to you if you think it should ever be done (not clear from comment trail).

> Add an IBM ORB configuration to WildFly
> ---------------------------------------
>
>                 Key: WFLY-5703
>                 URL: https://issues.jboss.org/browse/WFLY-5703
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: IIOP, Transactions
>            Reporter: Tom Jenkinson
>            Priority: Optional
>
> Placeholder to be moved to WFLY
> I guess it finally caught us after an .m2 wipe?
> http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-ibm-jdk/139/console



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:24:00 2016
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 27 Oct 2016 08:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.2875.1477571040223@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312944#comment-13312944 ] 

Sanne Grinovero commented on WFLY-6854:
---------------------------------------

Hibernate ORM {{5.1.4.Final}} should be the target now.

> Upgrade Hibernate ORM to 5.1.3 
> -------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:32:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 08:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1033) Enhance XTS AS7 configuration
In-Reply-To: <JIRA.12442503.1311587320000@Atlassian.JIRA>
References: <JIRA.12442503.1311587320000@Atlassian.JIRA>
	<JIRA.12442503.1311587320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442503.1311587320000.2920.1477571520609@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312951#comment-13312951 ] 

Tom Jenkinson commented on WFLY-1033:
-------------------------------------

There are things that could be done and I would note that Paul moved it from its original issues tracker (JBTM) based on my direction.

> Enhance XTS AS7 configuration
> -----------------------------
>
>                 Key: WFLY-1033
>                 URL: https://issues.jboss.org/browse/WFLY-1033
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: XTS
>            Reporter: Andrew Dinn
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:33:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 08:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6966) FatalError on Transaction
 Expired Entry Monitor during server shutdown
In-Reply-To: <JIRA.12643661.1471423266000@Atlassian.JIRA>
References: <JIRA.12643661.1471423266000@Atlassian.JIRA>
	<JIRA.12643661.1471423266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643661.1471423266000.2930.1477571580378@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312952#comment-13312952 ] 

Tom Jenkinson commented on WFLY-6966:
-------------------------------------

It is not a consistent error. Unless something special is done in WFLY with the logger I expect other components could be coerced to emit a warn/error during shutdown.

> FatalError on Transaction Expired Entry Monitor during server shutdown
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6966
>                 URL: https://issues.jboss.org/browse/WFLY-6966
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: IIOP, Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Minor
>
> I do experience intermittent errors being shown in server log during server shutdown. It happens time to time for server configured to use {{JTS}} transaction that {{Transaction Expired Entry Monitor}} shows {{FatalError}} during container shutdown.
> I do experience this failure when jdbc object store is used.
> The shutdown log looks
> {code}
> 2016-08-16 07:07:46,900 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment wmq.jmsra.rar (runtime-name: wmq.jmsra.rar) in 132ms
> 2016-08-16 07:07:46,914 INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 2016-08-16 07:07:46,914 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2016-08-16 07:07:46,915 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 2016-08-16 07:07:46,921 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2016-08-16 07:07:46,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment crashrecovery-jms-stateless-cmt.jar (runtime-name: crashrecovery-jms-stateless-cmt.jar) in 156ms
> 2016-08-16 07:07:46,947 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2016-08-16 07:07:46,952 TRACE [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) InputObjectState::InputObjectState(0:ffff7f000001:55f44a88:57b2ec0b:8, Recovery/FactoryContact)
> 2016-08-16 07:07:46,959 INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 32) AMQ151003: resource adaptor stopped
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) ORB::shutdown ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) OA::destroyRootPOA ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) RootOA::shutdownObject (Servant)
> 2016-08-16 07:07:46,962 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032018: Destroying TransactionManagerService
> 2016-08-16 07:07:46,963 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032014: Stopping transaction recovery manager
> 2016-08-16 07:07:47,000 FATAL [com.arjuna.ats.jts] (Transaction Expired Entry Monitor) ARJUNA022006: The ORB has not been initialized yet
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) Exception in thread "Transaction Expired Entry Monitor" com.arjuna.ats.arjuna.exceptions.FatalError
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.ORBManager.getORB(ORBManager.java:56)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restore_state(FactoryContactItem.java:264)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restoreMe(FactoryContactItem.java:320)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.recreate(FactoryContactItem.java:100)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner.scan(ExpiredContactScanner.java:99)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171)
> 2016-08-16 07:07:47,001 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: Mode <== TERMINATED
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown waiting for scan to end
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan TERMINATED at phase 1
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown scan wait complete
> 2016-08-16 07:07:47,003 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0010: Unbound data source [java:jboss/datasources/jdbc-store]
> 2016-08-16 07:07:47,006 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = module_postgresql-9.4.1207.jar
> 2016-08-16 07:07:47,012 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 32) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0.SP16-redhat-1 [023d1e88-638c-11e6-927a-a180c25082cf] stopped
> 2016-08-16 07:07:47,012 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 2016-08-16 07:07:47,018 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 250ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:34:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 08:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5703) Add an IBM ORB configuration
	to WildFly
In-Reply-To: <JIRA.12589554.1445251334000@Atlassian.JIRA>
References: <JIRA.12589554.1445251334000@Atlassian.JIRA>
	<JIRA.12589554.1445251334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589554.1445251334000.2948.1477571641350@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312953#comment-13312953 ] 

Tom Jenkinson commented on WFLY-5703:
-------------------------------------

Sorry, you are right. I will remove the Transactions component.

Note I am the original reporter.

> Add an IBM ORB configuration to WildFly
> ---------------------------------------
>
>                 Key: WFLY-5703
>                 URL: https://issues.jboss.org/browse/WFLY-5703
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: IIOP, Transactions
>            Reporter: Tom Jenkinson
>            Priority: Optional
>
> Placeholder to be moved to WFLY
> I guess it finally caught us after an .m2 wipe?
> http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-ibm-jdk/139/console



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:34:01 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 08:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5703) Add an IBM ORB configuration
	to WildFly
In-Reply-To: <JIRA.12589554.1445251334000@Atlassian.JIRA>
References: <JIRA.12589554.1445251334000@Atlassian.JIRA>
	<JIRA.12589554.1445251334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589554.1445251334000.2965.1477571641995@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson reopened WFLY-5703:
---------------------------------


> Add an IBM ORB configuration to WildFly
> ---------------------------------------
>
>                 Key: WFLY-5703
>                 URL: https://issues.jboss.org/browse/WFLY-5703
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: IIOP, Transactions
>            Reporter: Tom Jenkinson
>            Priority: Optional
>
> Placeholder to be moved to WFLY
> I guess it finally caught us after an .m2 wipe?
> http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-ibm-jdk/139/console



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:34:02 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 08:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5703) Add an IBM ORB configuration
	to WildFly
In-Reply-To: <JIRA.12589554.1445251334000@Atlassian.JIRA>
References: <JIRA.12589554.1445251334000@Atlassian.JIRA>
	<JIRA.12589554.1445251334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589554.1445251334000.2971.1477571642170@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5703:
--------------------------------
    Component/s:     (was: Transactions)


> Add an IBM ORB configuration to WildFly
> ---------------------------------------
>
>                 Key: WFLY-5703
>                 URL: https://issues.jboss.org/browse/WFLY-5703
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: IIOP
>            Reporter: Tom Jenkinson
>            Priority: Optional
>
> Placeholder to be moved to WFLY
> I guess it finally caught us after an .m2 wipe?
> http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-ibm-jdk/139/console



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:36:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 08:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5703) Add an IBM ORB configuration
	to WildFly
In-Reply-To: <JIRA.12589554.1445251334000@Atlassian.JIRA>
References: <JIRA.12589554.1445251334000@Atlassian.JIRA>
	<JIRA.12589554.1445251334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589554.1445251334000.2983.1477571760284@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312955#comment-13312955 ] 

Tom Jenkinson commented on WFLY-5703:
-------------------------------------

When I originally raised it it was specifically about transactions but I remember now I reshaped it to be about the ORB in its entirety.

> Add an IBM ORB configuration to WildFly
> ---------------------------------------
>
>                 Key: WFLY-5703
>                 URL: https://issues.jboss.org/browse/WFLY-5703
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: IIOP
>            Reporter: Tom Jenkinson
>            Priority: Optional
>
> Placeholder to be moved to WFLY
> I guess it finally caught us after an .m2 wipe?
> http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-ibm-jdk/139/console



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:45:03 2016
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 27 Oct 2016 08:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7394) Redeploy deployment if all
 missing dependencies for deployment are corrected
In-Reply-To: <JIRA.12657519.1477572268000@Atlassian.JIRA>
References: <JIRA.12657519.1477572268000@Atlassian.JIRA>
	<JIRA.12657519.1477572268975@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657519.1477572268000.3089.1477572303007@Atlassian.JIRA>

Miroslav Novak created WFLY-7394:
------------------------------------

             Summary: Redeploy deployment if all missing dependencies for deployment are corrected 
                 Key: WFLY-7394
                 URL: https://issues.jboss.org/browse/WFLY-7394
             Project: WildFly
          Issue Type: Enhancement
          Components: Server
    Affects Versions: 10.1.0.Final
            Reporter: Miroslav Novak
            Assignee: Jason Greene


If deployment failed to deploy and later all missing dependencies for deployment are corrected then deployment would redeploy automatically. This behavior could be configurable. 

For example if you deploy EJB which injects queue like:
{code}
@Resource(mappedName = "java:/jms/queue/OutQueue")
private Queue outQueue;
{code}

and administrator deploys queue later then EJB would automatically get redeployed. 





--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:50:00 2016
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 27 Oct 2016 08:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7395) Allow to provide deployment
 dependency to JNDI resource
In-Reply-To: <JIRA.12657520.1477572596000@Atlassian.JIRA>
References: <JIRA.12657520.1477572596000@Atlassian.JIRA>
	<JIRA.12657520.1477572596022@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657520.1477572596000.3125.1477572600257@Atlassian.JIRA>

Miroslav Novak created WFLY-7395:
------------------------------------

             Summary: Allow to provide deployment dependency to JNDI resource
                 Key: WFLY-7395
                 URL: https://issues.jboss.org/browse/WFLY-7395
             Project: WildFly
          Issue Type: Feature Request
          Components: Server
    Affects Versions: 10.1.0.Final
            Reporter: Miroslav Novak
            Assignee: Jason Greene


For JBoss AS 6 there was ejb annotation @org.jboss.annotation.ejb.Depends which allowed to set dependency to JNDI resource. Currently there seems to be no replacement in Wildfly 10.x

For example if EJB contains dependency to queue registered in JNDI:
{code}
@Resource(mappedName = "java:/jms/queue/OutQueue")
private Queue outQueue;
{code}

then it would not get deployed when OutQueue is not present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:52:00 2016
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 27 Oct 2016 08:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7395) Allow to provide deployment
 dependency to JNDI resource
In-Reply-To: <JIRA.12657520.1477572596000@Atlassian.JIRA>
References: <JIRA.12657520.1477572596000@Atlassian.JIRA>
	<JIRA.12657520.1477572596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657520.1477572596000.3139.1477572720962@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-7395:
---------------------------------
    Description: 
For JBoss AS 6 there was ejb annotation @org.jboss.annotation.ejb.Depends which allowed to set dependency to JNDI resource. Currently there seems to be no replacement in Wildfly 10.x

For example if EJB contains dependency to queue registered in JNDI:
{code}
@Resource(mappedName = "java:/jms/queue/OutQueue")
private Queue outQueue;
{code}

then it would not get deployed when OutQueue is not present. Purpose of this feature request is to add possibility to provide such dependency in the way as @org.jboss.annotation.ejb.Depends did.

  was:
For JBoss AS 6 there was ejb annotation @org.jboss.annotation.ejb.Depends which allowed to set dependency to JNDI resource. Currently there seems to be no replacement in Wildfly 10.x

For example if EJB contains dependency to queue registered in JNDI:
{code}
@Resource(mappedName = "java:/jms/queue/OutQueue")
private Queue outQueue;
{code}

then it would not get deployed when OutQueue is not present.



> Allow to provide deployment dependency to JNDI resource
> -------------------------------------------------------
>
>                 Key: WFLY-7395
>                 URL: https://issues.jboss.org/browse/WFLY-7395
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>    Affects Versions: 10.1.0.Final
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>
> For JBoss AS 6 there was ejb annotation @org.jboss.annotation.ejb.Depends which allowed to set dependency to JNDI resource. Currently there seems to be no replacement in Wildfly 10.x
> For example if EJB contains dependency to queue registered in JNDI:
> {code}
> @Resource(mappedName = "java:/jms/queue/OutQueue")
> private Queue outQueue;
> {code}
> then it would not get deployed when OutQueue is not present. Purpose of this feature request is to add possibility to provide such dependency in the way as @org.jboss.annotation.ejb.Depends did.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 08:54:00 2016
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 27 Oct 2016 08:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7395) Allow to provide deployment
 dependency to JNDI resource
In-Reply-To: <JIRA.12657520.1477572596000@Atlassian.JIRA>
References: <JIRA.12657520.1477572596000@Atlassian.JIRA>
	<JIRA.12657520.1477572596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657520.1477572596000.3146.1477572840422@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak updated WFLY-7395:
---------------------------------
    Forum Reference: https://developer.jboss.org/message/964459


> Allow to provide deployment dependency to JNDI resource
> -------------------------------------------------------
>
>                 Key: WFLY-7395
>                 URL: https://issues.jboss.org/browse/WFLY-7395
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>    Affects Versions: 10.1.0.Final
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>
> For JBoss AS 6 there was ejb annotation @org.jboss.annotation.ejb.Depends which allowed to set dependency to JNDI resource. Currently there seems to be no replacement in Wildfly 10.x
> For example if EJB contains dependency to queue registered in JNDI:
> {code}
> @Resource(mappedName = "java:/jms/queue/OutQueue")
> private Queue outQueue;
> {code}
> then it would not get deployed when OutQueue is not present. Purpose of this feature request is to add possibility to provide such dependency in the way as @org.jboss.annotation.ejb.Depends did.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 09:03:00 2016
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 09:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1345) Drop support for JSR94
	integration?
In-Reply-To: <JIRA.12657501.1477566741000@Atlassian.JIRA>
References: <JIRA.12657501.1477566741000@Atlassian.JIRA>
	<JIRA.12657501.1477566741000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657501.1477566741000.3213.1477573380677@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? updated DROOLS-1345:
--------------------------------
    Description: Drools JSR94 integration seems to be unused and unmaintained. We should at least consider removing it for 7.x  (was: Drools JSR94 integration seems to be unused and unmaintained. Could we remote it for 7.x?)


> Drop support for JSR94 integration?
> -----------------------------------
>
>                 Key: DROOLS-1345
>                 URL: https://issues.jboss.org/browse/DROOLS-1345
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Petr ?irok?
>            Assignee: Petr ?irok?
>
> Drools JSR94 integration seems to be unused and unmaintained. We should at least consider removing it for 7.x



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 09:03:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 27 Oct 2016 09:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6966) FatalError on Transaction
 Expired Entry Monitor during server shutdown
In-Reply-To: <JIRA.12643661.1471423266000@Atlassian.JIRA>
References: <JIRA.12643661.1471423266000@Atlassian.JIRA>
	<JIRA.12643661.1471423266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643661.1471423266000.3220.1477573380844@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312976#comment-13312976 ] 

David Lloyd commented on WFLY-6966:
-----------------------------------

That doesn't make it not be a bug though: in this case there is a clear dependency/ordering problem (which is why it's sporadic).

> FatalError on Transaction Expired Entry Monitor during server shutdown
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6966
>                 URL: https://issues.jboss.org/browse/WFLY-6966
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: IIOP, Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Minor
>
> I do experience intermittent errors being shown in server log during server shutdown. It happens time to time for server configured to use {{JTS}} transaction that {{Transaction Expired Entry Monitor}} shows {{FatalError}} during container shutdown.
> I do experience this failure when jdbc object store is used.
> The shutdown log looks
> {code}
> 2016-08-16 07:07:46,900 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment wmq.jmsra.rar (runtime-name: wmq.jmsra.rar) in 132ms
> 2016-08-16 07:07:46,914 INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 2016-08-16 07:07:46,914 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2016-08-16 07:07:46,915 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 2016-08-16 07:07:46,921 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2016-08-16 07:07:46,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment crashrecovery-jms-stateless-cmt.jar (runtime-name: crashrecovery-jms-stateless-cmt.jar) in 156ms
> 2016-08-16 07:07:46,947 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2016-08-16 07:07:46,952 TRACE [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) InputObjectState::InputObjectState(0:ffff7f000001:55f44a88:57b2ec0b:8, Recovery/FactoryContact)
> 2016-08-16 07:07:46,959 INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 32) AMQ151003: resource adaptor stopped
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) ORB::shutdown ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) OA::destroyRootPOA ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) RootOA::shutdownObject (Servant)
> 2016-08-16 07:07:46,962 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032018: Destroying TransactionManagerService
> 2016-08-16 07:07:46,963 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032014: Stopping transaction recovery manager
> 2016-08-16 07:07:47,000 FATAL [com.arjuna.ats.jts] (Transaction Expired Entry Monitor) ARJUNA022006: The ORB has not been initialized yet
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) Exception in thread "Transaction Expired Entry Monitor" com.arjuna.ats.arjuna.exceptions.FatalError
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.ORBManager.getORB(ORBManager.java:56)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restore_state(FactoryContactItem.java:264)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restoreMe(FactoryContactItem.java:320)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.recreate(FactoryContactItem.java:100)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner.scan(ExpiredContactScanner.java:99)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171)
> 2016-08-16 07:07:47,001 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: Mode <== TERMINATED
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown waiting for scan to end
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan TERMINATED at phase 1
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown scan wait complete
> 2016-08-16 07:07:47,003 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0010: Unbound data source [java:jboss/datasources/jdbc-store]
> 2016-08-16 07:07:47,006 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = module_postgresql-9.4.1207.jar
> 2016-08-16 07:07:47,012 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 32) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0.SP16-redhat-1 [023d1e88-638c-11e6-927a-a180c25082cf] stopped
> 2016-08-16 07:07:47,012 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 2016-08-16 07:07:47,018 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 250ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 09:12:00 2016
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 09:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1345) Drop support for JSR94
	integration?
In-Reply-To: <JIRA.12657501.1477566741000@Atlassian.JIRA>
References: <JIRA.12657501.1477566741000@Atlassian.JIRA>
	<JIRA.12657501.1477566741000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657501.1477566741000.3271.1477573920138@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312980#comment-13312980 ] 

Petr ?irok? commented on DROOLS-1345:
-------------------------------------

One major issue here is that the {jsr94:jsr94} is _not_ in Maven central and we don't know where the sources are (assuming they are somewhere publicly accessible).

> Drop support for JSR94 integration?
> -----------------------------------
>
>                 Key: DROOLS-1345
>                 URL: https://issues.jboss.org/browse/DROOLS-1345
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Petr ?irok?
>            Assignee: Petr ?irok?
>
> Drools JSR94 integration seems to be unused and unmaintained. We should at least consider removing it for 7.x



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 09:21:00 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 27 Oct 2016 09:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7207) Integration of EJB with
 transactions during the graceful shutdown
In-Reply-To: <JIRA.12651810.1474642765000@Atlassian.JIRA>
References: <JIRA.12651810.1474642765000@Atlassian.JIRA>
	<JIRA.12651810.1474642765000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651810.1474642765000.3308.1477574460431@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312988#comment-13312988 ] 

Gytis Trikleris commented on WFLY-7207:
---------------------------------------

I've raised a pull request to WildFly master with the service exposing ExtendedJBossXATerminator: https://github.com/wildfly/wildfly/pull/9300. 

> Integration of EJB with transactions during the graceful shutdown
> -----------------------------------------------------------------
>
>                 Key: WFLY-7207
>                 URL: https://issues.jboss.org/browse/WFLY-7207
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Gytis Trikleris
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 09:26:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 27 Oct 2016 09:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7396) No log messages comming from
 Elytron - exception handling
In-Reply-To: <JIRA.12657528.1477574680000@Atlassian.JIRA>
References: <JIRA.12657528.1477574680000@Atlassian.JIRA>
	<JIRA.12657528.1477574680000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657528.1477574680000.3397.1477574760403@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6678 to WFLY-7396:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7396  (was: JBEAP-6678)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR7)


> No log messages comming from Elytron - exception handling
> ---------------------------------------------------------
>
>                 Key: WFLY-7396
>                 URL: https://issues.jboss.org/browse/WFLY-7396
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Critical
>
> Log error messages from exceptions into log, where it can be useful. See https://issues.jboss.org/browse/JBEAP-6041 for more details.
> It happened to me twice elytron doesn't log exceptions into log, which would be useful for me, but instead just ignore it. I get to them, once I was debugging code. 
> * https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L810
> * https://github.com/wildfly-security/wildfly-elytron/blob/7666231fa76b95c3c97eed0d16968a5f77a7de22/src/main/java/org/wildfly/security/http/impl/SpnegoAuthenticationMechanism.java#L144
>     ** exceptin which was ignored here "java.security.PrivilegedActionException: GSSException: Unsupported mechanism requested: 1.2.840.48018.1.2.2"
> Please review also other exception handling places, if exceptions are handled correctly. 



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 09:32:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 09:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6966) FatalError on Transaction
 Expired Entry Monitor during server shutdown
In-Reply-To: <JIRA.12643661.1471423266000@Atlassian.JIRA>
References: <JIRA.12643661.1471423266000@Atlassian.JIRA>
	<JIRA.12643661.1471423266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643661.1471423266000.3493.1477575120918@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson reassigned WFLY-6966:
-----------------------------------

    Assignee: Tom Jenkinson  (was: Tomasz Adamski)


> FatalError on Transaction Expired Entry Monitor during server shutdown
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6966
>                 URL: https://issues.jboss.org/browse/WFLY-6966
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: IIOP, Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Tom Jenkinson
>            Priority: Minor
>
> I do experience intermittent errors being shown in server log during server shutdown. It happens time to time for server configured to use {{JTS}} transaction that {{Transaction Expired Entry Monitor}} shows {{FatalError}} during container shutdown.
> I do experience this failure when jdbc object store is used.
> The shutdown log looks
> {code}
> 2016-08-16 07:07:46,900 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment wmq.jmsra.rar (runtime-name: wmq.jmsra.rar) in 132ms
> 2016-08-16 07:07:46,914 INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 2016-08-16 07:07:46,914 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2016-08-16 07:07:46,915 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 2016-08-16 07:07:46,921 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2016-08-16 07:07:46,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment crashrecovery-jms-stateless-cmt.jar (runtime-name: crashrecovery-jms-stateless-cmt.jar) in 156ms
> 2016-08-16 07:07:46,947 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2016-08-16 07:07:46,952 TRACE [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) InputObjectState::InputObjectState(0:ffff7f000001:55f44a88:57b2ec0b:8, Recovery/FactoryContact)
> 2016-08-16 07:07:46,959 INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 32) AMQ151003: resource adaptor stopped
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) ORB::shutdown ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) OA::destroyRootPOA ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) RootOA::shutdownObject (Servant)
> 2016-08-16 07:07:46,962 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032018: Destroying TransactionManagerService
> 2016-08-16 07:07:46,963 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032014: Stopping transaction recovery manager
> 2016-08-16 07:07:47,000 FATAL [com.arjuna.ats.jts] (Transaction Expired Entry Monitor) ARJUNA022006: The ORB has not been initialized yet
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) Exception in thread "Transaction Expired Entry Monitor" com.arjuna.ats.arjuna.exceptions.FatalError
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.ORBManager.getORB(ORBManager.java:56)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restore_state(FactoryContactItem.java:264)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restoreMe(FactoryContactItem.java:320)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.recreate(FactoryContactItem.java:100)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner.scan(ExpiredContactScanner.java:99)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171)
> 2016-08-16 07:07:47,001 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: Mode <== TERMINATED
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown waiting for scan to end
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan TERMINATED at phase 1
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown scan wait complete
> 2016-08-16 07:07:47,003 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0010: Unbound data source [java:jboss/datasources/jdbc-store]
> 2016-08-16 07:07:47,006 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = module_postgresql-9.4.1207.jar
> 2016-08-16 07:07:47,012 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 32) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0.SP16-redhat-1 [023d1e88-638c-11e6-927a-a180c25082cf] stopped
> 2016-08-16 07:07:47,012 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 2016-08-16 07:07:47,018 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 250ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 09:36:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 27 Oct 2016 09:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6966) FatalError on Transaction
 Expired Entry Monitor during server shutdown
In-Reply-To: <JIRA.12643661.1471423266000@Atlassian.JIRA>
References: <JIRA.12643661.1471423266000@Atlassian.JIRA>
	<JIRA.12643661.1471423266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643661.1471423266000.3528.1477575360660@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-6966:
--------------------------------
    Component/s:     (was: IIOP)


> FatalError on Transaction Expired Entry Monitor during server shutdown
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6966
>                 URL: https://issues.jboss.org/browse/WFLY-6966
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Tom Jenkinson
>            Priority: Minor
>
> I do experience intermittent errors being shown in server log during server shutdown. It happens time to time for server configured to use {{JTS}} transaction that {{Transaction Expired Entry Monitor}} shows {{FatalError}} during container shutdown.
> I do experience this failure when jdbc object store is used.
> The shutdown log looks
> {code}
> 2016-08-16 07:07:46,900 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment wmq.jmsra.rar (runtime-name: wmq.jmsra.rar) in 132ms
> 2016-08-16 07:07:46,914 INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 2016-08-16 07:07:46,914 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2016-08-16 07:07:46,915 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 2016-08-16 07:07:46,921 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2016-08-16 07:07:46,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment crashrecovery-jms-stateless-cmt.jar (runtime-name: crashrecovery-jms-stateless-cmt.jar) in 156ms
> 2016-08-16 07:07:46,947 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2016-08-16 07:07:46,952 TRACE [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) InputObjectState::InputObjectState(0:ffff7f000001:55f44a88:57b2ec0b:8, Recovery/FactoryContact)
> 2016-08-16 07:07:46,959 INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 32) AMQ151003: resource adaptor stopped
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) ORB::shutdown ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) OA::destroyRootPOA ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) RootOA::shutdownObject (Servant)
> 2016-08-16 07:07:46,962 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032018: Destroying TransactionManagerService
> 2016-08-16 07:07:46,963 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032014: Stopping transaction recovery manager
> 2016-08-16 07:07:47,000 FATAL [com.arjuna.ats.jts] (Transaction Expired Entry Monitor) ARJUNA022006: The ORB has not been initialized yet
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) Exception in thread "Transaction Expired Entry Monitor" com.arjuna.ats.arjuna.exceptions.FatalError
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.ORBManager.getORB(ORBManager.java:56)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restore_state(FactoryContactItem.java:264)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restoreMe(FactoryContactItem.java:320)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.recreate(FactoryContactItem.java:100)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner.scan(ExpiredContactScanner.java:99)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171)
> 2016-08-16 07:07:47,001 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: Mode <== TERMINATED
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown waiting for scan to end
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan TERMINATED at phase 1
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown scan wait complete
> 2016-08-16 07:07:47,003 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0010: Unbound data source [java:jboss/datasources/jdbc-store]
> 2016-08-16 07:07:47,006 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = module_postgresql-9.4.1207.jar
> 2016-08-16 07:07:47,012 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 32) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0.SP16-redhat-1 [023d1e88-638c-11e6-927a-a180c25082cf] stopped
> 2016-08-16 07:07:47,012 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 2016-08-16 07:07:47,018 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 250ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 09:38:00 2016
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 27 Oct 2016 09:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7397) Elytron SPNEGO: missing
 negstat field in the first reply
In-Reply-To: <JIRA.12657537.1477575381000@Atlassian.JIRA>
References: <JIRA.12657537.1477575381000@Atlassian.JIRA>
	<JIRA.12657537.1477575381000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657537.1477575381000.3578.1477575480830@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma moved JBEAP-6680 to WFLY-7397:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7397  (was: JBEAP-6680)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR7)


> Elytron SPNEGO: missing negstat field in the first reply
> --------------------------------------------------------
>
>                 Key: WFLY-7397
>                 URL: https://issues.jboss.org/browse/WFLY-7397
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>
> Basically Elytron clone of JBEAP-4114.
> When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}.
> As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply:
> {code:borderStyle=dashed}
> negState
> ...
>       This field is REQUIRED in the first reply from the target, and is
>       OPTIONAL thereafter.  When negState is absent, the actual state
>       should be inferred from the state of the negotiated mechanism
>       context.
> {code}
> https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13db50ff43/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/negotiation/SPNEGOLoginModuleTestCase.java testInvalidKerberosSpnegoWorkflow.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 09:41:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 27 Oct 2016 09:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1777) Use separate resources for
 GET requests involving useStreamAsResponse
In-Reply-To: <JIRA.12649505.1473438511000@Atlassian.JIRA>
References: <JIRA.12649505.1473438511000@Atlassian.JIRA>
	<JIRA.12649505.1473438511000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649505.1473438511000.3621.1477575660864@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1777:
-------------------------------------
    Security Sensitive Issue: This issue is security relevant


> Use separate resources for GET requests involving useStreamAsResponse
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-1777
>                 URL: https://issues.jboss.org/browse/WFCORE-1777
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.CR1
>
>
> A request for streamed content can potentially involve a large amount of content, e.g. a very large log file. We should limit the amount of resources (e.g. threads) available for handling such HTTP requests over the /management context, particularly in the case of GET requests where we don't do the cross-origin checks that  we do with POST.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 09:50:00 2016
From: issues at jboss.org (Sande Gilda (JIRA))
Date: Thu, 27 Oct 2016 09:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7217) Adapt servlet-security
 example to use Elytron
In-Reply-To: <JIRA.12651924.1474888769000@Atlassian.JIRA>
References: <JIRA.12651924.1474888769000@Atlassian.JIRA>
	<JIRA.12651924.1474888769000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651924.1474888769000.3728.1477576200403@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sande Gilda reassigned WFLY-7217:
---------------------------------

    Assignee: Tomaz Cerar  (was: Sande Gilda)


> Adapt servlet-security example to use Elytron
> ---------------------------------------------
>
>                 Key: WFLY-7217
>                 URL: https://issues.jboss.org/browse/WFLY-7217
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation
>            Reporter: Ingo Weiss
>            Assignee: Tomaz Cerar
>            Priority: Minor
>   Original Estimate: 2 hours
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 09:53:00 2016
From: issues at jboss.org (=?UTF-8?Q?Bj=C3=B6rn_Kautler_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 09:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-78) Invalid manifest section in
	jboss-sasl JAR
In-Reply-To: <JIRA.12657494.1477564711000@Atlassian.JIRA>
References: <JIRA.12657494.1477564711000@Atlassian.JIRA>
	<JIRA.12657494.1477564711000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657494.1477564711000.3745.1477576380391@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SASL-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313036#comment-13313036 ] 

Bj?rn Kautler commented on SASL-78:
-----------------------------------

Actually I did not have the problem with jboss-sasl as we don't use it in our WebStart application. I had the problem with other libs and then checked all libs that we have in our local Ivy repository for JARs with invalid manifest entries. If this project is EOL and replaced by a new project that does not have this problem, I guess it is fine and you can close the issue as wont-fix. :-)

> Invalid manifest section in jboss-sasl JAR
> ------------------------------------------
>
>                 Key: SASL-78
>                 URL: https://issues.jboss.org/browse/SASL-78
>             Project: SASL Provider
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.4.Final, 1.0.5.Final
>            Reporter: Bj?rn Kautler
>            Assignee: Darran Lofthouse
>
> In the {{MANIFEST.MF}} of your {{jboss-sasl}} JAR you have a section {{Build-Information}}.
> This violates that JAR specification.
> A section in the manifest always refers to an entry in the JAR.
> If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest.
> Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. (You are still using jboss-parent 7, if you upgrade to 8 or newer, the problem will be gone)
> ----
> In my concrete use-case this happened with other JARs with invalid manifest entries:
> - I have signed those JARs and included them in a WebStart application
> - I started the application with 8u102 32-bit {{javaws}}
> - The JARs were downloaded and their entries signatures verified
> - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed
> This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse:
> - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM
> - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again
> - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between
> - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution
> Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 09:56:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 27 Oct 2016 09:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1902) Error messages from CLI
 batch should be more informative
In-Reply-To: <JIRA.12657504.1477567805000@Atlassian.JIRA>
References: <JIRA.12657504.1477567805000@Atlassian.JIRA>
	<JIRA.12657504.1477567805000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657504.1477567805000.3782.1477576560797@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313040#comment-13313040 ] 

Jean-Francois Denise commented on WFCORE-1902:
----------------------------------------------

Hi Marek,
helping user to identify the source of an error is definitely helpful.
I guess that you want to help user mainly when a batch is located inside script.

- Adding the command (or operation) that was failing in addition to the step number could be helpful. This could be helpful both in interactive and inside a script.

- Script line number. There is no support for script line number today. To match a script line to its output, you can use the --echo-command option. Every command will be printed prior to be executed. That should already help user with large scripts.

Step line inside a script are not that easy to retrieve due to multi-line support. For example:
batch
:read-attribute(\
name=name)
:read-attribute(\
name=nonsence)
run-batch

Line of failing run-batch is 6, what is the line of failing step-2?

This could be implemented in the CLI today and/or in the CLI.next. I personally like the idea. I am surprised that no customer already required it.

> Error messages from CLI batch should be more informative
> --------------------------------------------------------
>
>                 Key: WFCORE-1902
>                 URL: https://issues.jboss.org/browse/WFCORE-1902
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Error messages from CLI batch should be more informative
> *Steps to Reproduce:*
> {noformat}
> cat <<EOF >a
> batch
> :read-attribute(name=product-version)
> :read-attribute(name=product-name)
> :read-attribute(name=nonsence)
> :read-attribute(name=product-name)
> run-batch
> EOF
> ./jboss-cli.sh -c --file=a
> {noformat}
> *Actual results:*
> {noformat}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
> {noformat}
> *Expected results:*
> I can imagine content like following could be helpful for troubleshooting:
> {noformat}
> {
>    "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
>       "Operation step-3" => {
>          "line number" => 4
>          "operation" => ":read-attribute(name=nonsence)"
>          "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
>    }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 10:00:01 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-695) Is impossible remove whole
 Elytron subsystem when Elytron resource depends on another Elytron
 resource.
In-Reply-To: <JIRA.12657545.1477576793000@Atlassian.JIRA>
References: <JIRA.12657545.1477576793000@Atlassian.JIRA>
	<JIRA.12657545.1477576793693@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657545.1477576793000.3867.1477576801471@Atlassian.JIRA>

Hynek ?v?bek created ELY-695:
--------------------------------

             Summary: Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource.
                 Key: ELY-695
                 URL: https://issues.jboss.org/browse/ELY-695
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Hynek ?v?bek
            Assignee: Darran Lofthouse


Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource.

*Scenario:*
* I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore
* I want to delete whole Elytron subsystem
* I execute this CLI command */subsystem=elytron:remove()* and get error
{code}
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly",
    "rolled-back" => true
}
{code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 10:01:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 10:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-695) Is impossible remove whole
 Elytron subsystem when Elytron resource depends on another Elytron
 resource.
In-Reply-To: <JIRA.12657545.1477576794000@Atlassian.JIRA>
References: <JIRA.12657545.1477576794000@Atlassian.JIRA>
	<JIRA.12657545.1477576794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657545.1477576794000.3870.1477576860177@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-695:
-----------------------------
    Component/s: Credential Store
                 KeyStores


> Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-695
>                 URL: https://issues.jboss.org/browse/ELY-695
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store, KeyStores
>            Reporter: Hynek ?v?bek
>            Assignee: Darran Lofthouse
>
> Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource.
> *Scenario:*
> * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore
> * I want to delete whole Elytron subsystem
> * I execute this CLI command */subsystem=elytron:remove()* and get error
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly",
>     "rolled-back" => true
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 10:01:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Thu, 27 Oct 2016 10:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-695) Is impossible remove whole
 Elytron subsystem when Elytron resource depends on another Elytron
 resource.
In-Reply-To: <JIRA.12657545.1477576794000@Atlassian.JIRA>
References: <JIRA.12657545.1477576794000@Atlassian.JIRA>
	<JIRA.12657545.1477576794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657545.1477576794000.3873.1477576860287@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-695:
-----------------------------
    Steps to Reproduce: 
*    firefly.keystore which is attached copy to eap_home/standalone/data/cs.
*    run EAP server
    ./bin/standalone.sh
*    run CLI
    ./bin/jboss-cli.sh -c
    if applicaple add Elytron extension and Elytron subsystem and reload server
    /extension=org.wildfly.extension.elytron:add()
    /subsystem=elytron:add()
    reload

*  /subsystem=elytron/credential-store=credStore:add(uri="cr-store://test/cs/scratchSC.jceks?create.storage=true;store.password=pass123"
*  /subsystem=elytron/credential-store=credStore/alias=ff:add(secret-value=Elytron)
*  /subsystem=elytron/key-store=firefly:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=credStore,alias=ff})
* /subsystem=elytron:remove()

  was:
*    firefly.keystore which is attached copy to eap_home/standalone/data/cs.
*    run EAP server
    ./bin/standalone.sh
*    run CLI
    ./bin/jboss-cli.sh -c
    if applicaple add Elytron extension and Elytron subsystem and reload server
    /extension=org.wildfly.extension.elytron:add()
    /subsystem=elytron:add()
    reload

*  /subsystem=elytron/credential-store=credStore:add(uri="cr-store://test/cs/scratchSC.jceks?create.storage=true;store.password=pass123"
*  /subsystem=elytron/credential-store=credStore/alias=ff:add(secret-value=Elytron)
*  /subsystem=elytron/key-store=firefly:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {store=credStore,alias=ff})
* /subsystem=elytron/credential-store=credStore:remove()



> Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-695
>                 URL: https://issues.jboss.org/browse/ELY-695
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store, KeyStores
>            Reporter: Hynek ?v?bek
>            Assignee: Darran Lofthouse
>
> Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource.
> *Scenario:*
> * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore
> * I want to delete whole Elytron subsystem
> * I execute this CLI command */subsystem=elytron:remove()* and get error
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly",
>     "rolled-back" => true
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Thu Oct 27 10:17:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 27 Oct 2016 10:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7398) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764426@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.4056.1477577820686@Atlassian.JIRA>

David Lloyd created WFLY-7398:
---------------------------------

             Summary: Tab completion causes NUL characters ('\0') to be injected...sometimes
                 Key: WFLY-7398
                 URL: https://issues.jboss.org/browse/WFLY-7398
             Project: WildFly
          Issue Type: Bug
          Components: CLI
            Reporter: David Lloyd
            Assignee: Jason Greene
            Priority: Critical


I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.

My "less" output of .jboss-cli-history looks something like this:
{noformat}
embed-server --std-out=echo
cd subsystem=discovery
./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
{noformat}

In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 10:30:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 27 Oct 2016 10:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7399) Silence "ISPN000152:
 Passivation configured without an eviction policy being selected. Only
 manually evicted entities will be passivated."
In-Reply-To: <JIRA.12657554.1477578599000@Atlassian.JIRA>
References: <JIRA.12657554.1477578599000@Atlassian.JIRA>
	<JIRA.12657554.1477578599853@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657554.1477578599000.4200.1477578601124@Atlassian.JIRA>

Radoslav Husar created WFLY-7399:
------------------------------------

             Summary: Silence "ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated."
                 Key: WFLY-7399
                 URL: https://issues.jboss.org/browse/WFLY-7399
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.Final
            Reporter: Radoslav Husar
            Assignee: Paul Ferraro


Integrate MANUAL eviction strategy introduced in ISPN-6911.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 12:20:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 27 Oct 2016 12:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-696) Elytron Client needs to support
 RealmCallback where realm not set in advance
In-Reply-To: <JIRA.12657580.1477585158000@Atlassian.JIRA>
References: <JIRA.12657580.1477585158000@Atlassian.JIRA>
	<JIRA.12657580.1477585158105@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657580.1477585158000.4821.1477585200245@Atlassian.JIRA>

Darran Lofthouse created ELY-696:
------------------------------------

             Summary: Elytron Client needs to support RealmCallback where realm not set in advance
                 Key: ELY-696
                 URL: https://issues.jboss.org/browse/ELY-696
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Authentication Client
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 1.1.0.Beta12






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 12:41:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 27 Oct 2016 12:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7400) JGroups channels should only
 use JMX if the associated capability is available.
In-Reply-To: <JIRA.12657584.1477586423000@Atlassian.JIRA>
References: <JIRA.12657584.1477586423000@Atlassian.JIRA>
	<JIRA.12657584.1477586423947@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657584.1477586423000.4900.1477586460263@Atlassian.JIRA>

Paul Ferraro created WFLY-7400:
----------------------------------

             Summary: JGroups channels should only use JMX if the associated capability is available.
                 Key: WFLY-7400
                 URL: https://issues.jboss.org/browse/WFLY-7400
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 12:42:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 27 Oct 2016 12:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7401) Infinispan cache containers
 should only use JMX if the associated capability is available.
In-Reply-To: <JIRA.12657585.1477586461000@Atlassian.JIRA>
References: <JIRA.12657585.1477586461000@Atlassian.JIRA>
	<JIRA.12657585.1477586461348@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657585.1477586461000.4916.1477586520297@Atlassian.JIRA>

Paul Ferraro created WFLY-7401:
----------------------------------

             Summary: Infinispan cache containers should only use JMX if the associated capability is available.
                 Key: WFLY-7401
                 URL: https://issues.jboss.org/browse/WFLY-7401
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 13:10:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 27 Oct 2016 13:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1346) Unwanted firing modifying
 an event over a window:time
In-Reply-To: <JIRA.12657587.1477588186000@Atlassian.JIRA>
References: <JIRA.12657587.1477588186000@Atlassian.JIRA>
	<JIRA.12657587.1477588186780@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657587.1477588186000.5061.1477588200077@Atlassian.JIRA>

Mario Fusco created DROOLS-1346:
-----------------------------------

             Summary: Unwanted firing modifying an event over a window:time
                 Key: DROOLS-1346
                 URL: https://issues.jboss.org/browse/DROOLS-1346
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco


Steps to reproduce:

1. In a first rule pattern match on an event over window:time
2. In the consequence of the rule change the value of a field of that event
3. Have a second rule that shouldn't match the value of the field changed by the former rule
4. This second rule fires even if it shouldn't




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 13:11:01 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 27 Oct 2016 13:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1346) Unwanted firing modifying
 an event over a window:time
In-Reply-To: <JIRA.12657587.1477588187000@Atlassian.JIRA>
References: <JIRA.12657587.1477588187000@Atlassian.JIRA>
	<JIRA.12657587.1477588187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657587.1477588187000.5073.1477588261611@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313164#comment-13313164 ] 

Matteo Mortari commented on DROOLS-1346:
----------------------------------------


{code:java}
@Test(timeout=10000)
    public void test01724123() {
        // 01724123
        String drl =
                "package " + MutableEvent.class.getPackage().getName() + "\n" +
                "declare " + MutableEvent.class.getCanonicalName() + "\n" +
                "   @role( event ) \n" +
                "end\n" +
                "rule \"Delete old fact\"\n" + 
                "    when\n" + 
                "        $event : MutableEvent(!condition)\n" + 
                "        String()\n" + 
                "    then\n" + 
                "        retract($event);\n" + 
                "end\n" + 
                "\n" + 
                "rule \"Generate new fail\"\n" + 
                "    when\n" + 
                "        $lineFail : MutableEvent() over window:time ( 10h )\n" + 
                "        not String()\n" + 
                "    then\n" + 
                "        modify($lineFail) {\n" + 
                "            setCondition(true)\n" + 
                "        }\n" + 
                "        insert(\"check\");\n" + 
                "end";

        KieHelper helper = new KieHelper();
        helper.addContent( drl, ResourceType.DRL );
        KieBase kbase = helper.build( EventProcessingOption.STREAM );
        KieSession ksession = kbase.newKieSession();
        
        ksession.addEventListener(new DefaultAgendaEventListener() {
            @Override
            public void afterMatchFired(AfterMatchFiredEvent event) {
                super.afterMatchFired(event);
                System.out.println(event);
            }
        });

        ksession.insert(new MutableEvent());
        int fired = ksession.fireAllRules();

        assertEquals(1, fired);
    }
    
    public static class MutableEvent implements Serializable {

        private boolean condition = false;

        public boolean isCondition() {
            return condition;
        }

        public void setCondition(boolean condition) {
            this.condition = condition;
        }

        @Override
        public String toString() {
            StringBuilder builder = new StringBuilder();
            builder.append("MutableEvent [condition=").append(condition).append("]");
            return builder.toString();
        }
    }
{code}


> Unwanted firing modifying an event over a window:time
> -----------------------------------------------------
>
>                 Key: DROOLS-1346
>                 URL: https://issues.jboss.org/browse/DROOLS-1346
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> Steps to reproduce:
> 1. In a first rule pattern match on an event over window:time
> 2. In the consequence of the rule change the value of a field of that event
> 3. Have a second rule that shouldn't match the value of the field changed by the former rule
> 4. This second rule fires even if it shouldn't



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 13:23:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 27 Oct 2016 13:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7398) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.5090.1477588980346@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-7398:
---------------------------------

    Assignee: Jean-Francois Denise  (was: Jason Greene)


> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7398
>                 URL: https://issues.jboss.org/browse/WFLY-7398
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 14:56:00 2016
From: issues at jboss.org (Gail Badner (JIRA))
Date: Thu, 27 Oct 2016 14:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.5456.1477594560387@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313195#comment-13313195 ] 

Gail Badner commented on WFLY-6854:
-----------------------------------

[~sannegrinovero], 5.1.3 hasn't been released yet. Why should 5.1.4.Final be the new target?

> Upgrade Hibernate ORM to 5.1.3 
> -------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 15:21:00 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 27 Oct 2016 15:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.5514.1477596060456@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313199#comment-13313199 ] 

Kabir Khan commented on WFLY-6854:
----------------------------------

I think the important thing is to get something in sooner rather than later. 

> Upgrade Hibernate ORM to 5.1.3 
> -------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 15:30:00 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 27 Oct 2016 15:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.5529.1477596600270@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313201#comment-13313201 ] 

Kabir Khan commented on WFLY-6854:
----------------------------------

I see there is a PR for 5.1.2 for WildFly, however note that nothing gets merged to WF at the moment without a corresponding EAP7 PR. So until you open an EAP7 PR, we are stuck waiting.

> Upgrade Hibernate ORM to 5.1.3 
> -------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 15:43:00 2016
From: issues at jboss.org (Gail Badner (JIRA))
Date: Thu, 27 Oct 2016 15:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.5541.1477597380294@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313203#comment-13313203 ] 

Gail Badner commented on WFLY-6854:
-----------------------------------

[~kabirkhan], there is https://issues.jboss.org/browse/EAP7-582.

> Upgrade Hibernate ORM to 5.1.3 
> -------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 18:59:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 27 Oct 2016 18:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7402) NoClassDefFoundError
 exception is thrown if jsr310 fasterxml module is used
In-Reply-To: <JIRA.12657606.1477609098000@Atlassian.JIRA>
References: <JIRA.12657606.1477609098000@Atlassian.JIRA>
	<JIRA.12657606.1477609098000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657606.1477609098000.6029.1477609140619@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-6690 to WFLY-7402:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7402  (was: JBEAP-6690)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: REST
                           (was: REST)
    Affects Version/s:     (was: 7.1.0.DR7)


> NoClassDefFoundError exception is thrown if jsr310 fasterxml module is used
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-7402
>                 URL: https://issues.jboss.org/browse/WFLY-7402
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>            Priority: Critical
>
> *Description of problem:*
> NoClassDefFoundError exception is thrown if jsr310 fasterxml module is used. This is regression against EAP 7.1.0.DR6 and it is probably caused by Jackson upgrade: JBEAP-6290
> *Possible solution:*
> Add this dependency to ./modules/system/layers/base/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/main/module.xml :
> {code:xml}
> <module name="com.fasterxml.jackson.core.jackson-annotations"/>
> {code}
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # Implement custom ContextResolver in deployment. This code enables jsr310 and jdk8 fasterxml functionality. Example:
> {code:java}
> @Provider
> @Produces( MediaType.APPLICATION_JSON )
> public class JacksonProducer implements ContextResolver<ObjectMapper> {
>     private final ObjectMapper json;
>     public JacksonProducer() throws Exception {
>         this.json = new ObjectMapper()
>                         .findAndRegisterModules()
>                         .configure( SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false )
>                         .configure( DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false );
>     }
>     @Override
>     public ObjectMapper getContext( Class<?> objectType ) {
>         return json;
>     }
> }
> {code}
> # Http request to REST end-point
> *Actual results:*
> {noformat}
> 17:36:40,881 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /jaxrs-wf/a/sample/entity/get/json: java.lang.NoClassDefFoundError: com/fasterxml/jackson/annotation/JsonFormat$Value
> 	at com.fasterxml.jackson.datatype.jsr310.ser.JSR310FormattedSerializerBase.createContextual(JSR310FormattedSerializerBase.java:97)
> 	at com.fasterxml.jackson.datatype.jsr310.ser.DurationSerializer.createContextual(DurationSerializer.java:40)
> 	at com.fasterxml.jackson.databind.SerializerProvider.handleSecondaryContextualization(SerializerProvider.java:966)
> 	at com.fasterxml.jackson.databind.SerializerProvider.findValueSerializer(SerializerProvider.java:546)
> 	at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.resolve(BeanSerializerBase.java:332)
> 	at com.fasterxml.jackson.databind.ser.SerializerCache.addAndResolveNonTypedSerializer(SerializerCache.java:197)
> 	at com.fasterxml.jackson.databind.SerializerProvider._createAndCacheUntypedSerializer(SerializerProvider.java:1269)
> 	at com.fasterxml.jackson.databind.SerializerProvider.findValueSerializer(SerializerProvider.java:500)
> 	at com.fasterxml.jackson.databind.SerializerProvider.findTypedValueSerializer(SerializerProvider.java:698)
> 	at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:270)
> 	at com.fasterxml.jackson.databind.ObjectWriter$Prefetch.serialize(ObjectWriter.java:1419)
> 	at com.fasterxml.jackson.databind.ObjectWriter.writeValue(ObjectWriter.java:940)
> 	at org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.writeTo(ResteasyJackson2Provider.java:207)
> 	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:131)
> 	at org.jboss.resteasy.core.interception.ServerWriterInterceptorContext.writeTo(ServerWriterInterceptorContext.java:60)
> 	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:120)
> 	at org.jboss.resteasy.security.doseta.DigitalSigningInterceptor.aroundWriteTo(DigitalSigningInterceptor.java:145)
> 	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
> 	at org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100)
> 	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
> 	at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:98)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:473)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:422)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 	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)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 19:44:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 27 Oct 2016 19:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7403) Jsr310 and jdk8 fasterxml
 modules are not available from deployment without specific
 jboss-deployment-structure.xml
In-Reply-To: <JIRA.12657608.1477611811000@Atlassian.JIRA>
References: <JIRA.12657608.1477611811000@Atlassian.JIRA>
	<JIRA.12657608.1477611811000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657608.1477611811000.6076.1477611840537@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-6691 to WFLY-7403:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7403  (was: JBEAP-6691)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: REST
                           (was: REST)
    Affects Version/s:     (was: 7.1.0.DR7)


> Jsr310 and jdk8 fasterxml modules are not available from deployment without specific jboss-deployment-structure.xml
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7403
>                 URL: https://issues.jboss.org/browse/WFLY-7403
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> *Description of problem:*
> Jsr310 and jdk8 fasterxml modules are not available from deployment without specific jboss-deployment-structure.xml
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> * This can be tested if "<module name="com.fasterxml.jackson.core.jackson-annotations"/>" is added to  ./modules/system/layers/base/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/main/module.xml (see JBEAP-6673)
> # Create end-point with data types and special jdk8 types and allows 
> {code:java}
>     @GET
>     @Path("entity/get/json")
>     @Produces(MediaType.APPLICATION_JSON)
>     public DatatypeObject getJson() {
>         DatatypeObject per = new DatatypeObject();
>         per.setString("someString");
>         per.setDate(new Date());
>         per.setDuration(Duration.ofSeconds(5, 6));
>         per.setDayOfWeek(DayOfWeek.FRIDAY);
>         per.setOptionalString1(Optional.of("info at example.com"));
>         per.setOptionalString2(Optional.<String>empty());
>         return per;
>     }
> {code}
> # Implement custom ContextResolver in deployment. This code enables jsr310 and jdk8 fasterxml functionality. Example:
> {code:java}
> @Provider
> @Produces( MediaType.APPLICATION_JSON )
> public class JacksonProducer implements ContextResolver<ObjectMapper> {
>     private final ObjectMapper json;
>     public JacksonProducer() throws Exception {
>         this.json = new ObjectMapper()
>                         .findAndRegisterModules()
>                         .configure( SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false )
>                         .configure( DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false );
>     }
>     @Override
>     public ObjectMapper getContext( Class<?> objectType ) {
>         return json;
>     }
> }
> {code}
> # Http request to REST end-point
> *Actual results:*
> {noformat}
> {"string":"someString","optionalString1":{"present":true},"optionalString2":{"present":false},"duration":{"seconds":5,"zero":false,"negative":false,"units":["SECONDS","NANOS"],"nano":6},"date":"2016-10-27T13:02:11.991+0000"}
> {noformat}
> *Expected results:*
> {noformat}{"string":"someString","optionalString1":"info at example.com","optionalString2":null,"duration":"PT5.000000006S","date":"2016-10-27T13:01:03.923+0000"}
> {noformat}
> *Workaround:*
> Expected results is returned if specific jboss-deployment-structure.xml file is used:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
>     <deployment>
>         <dependencies>
>             <module name="com.fasterxml.jackson.datatype.jackson-datatype-jdk8" services="import"/>
>             <module name="com.fasterxml.jackson.datatype.jackson-datatype-jsr310" services="import"/>
>         </dependencies>
>     </deployment>
> </jboss-deployment-structure>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Thu Oct 27 20:58:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 27 Oct 2016 20:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1407) Test coverage for syslog
	reconnection
In-Reply-To: <JIRA.12607486.1456303088000@Atlassian.JIRA>
References: <JIRA.12607486.1456303088000@Atlassian.JIRA>
	<JIRA.12607486.1456303088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12607486.1456303088000.6162.1477616280474@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFCORE-1407:
--------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1311440
        Bugzilla Update: Perform


> Test coverage for syslog reconnection
> -------------------------------------
>
>                 Key: WFCORE-1407
>                 URL: https://issues.jboss.org/browse/WFCORE-1407
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 2.1.0.CR2
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Lukas
>             Fix For: 3.0.0.Alpha1
>
>
> Added test coverage for syslog reconnection issues - https://issues.jboss.org/browse/LOGMGR-123.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 04:41:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 28 Oct 2016 04:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7398) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.469.1477644060301@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313350#comment-13313350 ] 

Jean-Francois Denise commented on WFLY-7398:
--------------------------------------------

David,
is completion proposing you something for the uri property value? It would help to know the completion sequence.
I guess that the services argument is ruled by a value type and the completion adds automatically for you =[{
Then you are proposed a the list of properties of services, you type part of uri, then TAB "=" is added automatically then you press TAB multiple time (twice it seems).

Is that the steps you have followed?

Thanks.
JF

> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7398
>                 URL: https://issues.jboss.org/browse/WFLY-7398
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 05:18:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 28 Oct 2016 05:18:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7398) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.585.1477646280868@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313357#comment-13313357 ] 

Jean-Francois Denise commented on WFLY-7398:
--------------------------------------------

It would also help to have a dump of the services valueType:
./static-provider=test::read-operation-description(name=add


> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7398
>                 URL: https://issues.jboss.org/browse/WFLY-7398
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 05:19:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 28 Oct 2016 05:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7398) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.592.1477646340286@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313357#comment-13313357 ] 

Jean-Francois Denise edited comment on WFLY-7398 at 10/28/16 5:18 AM:
----------------------------------------------------------------------

It would also help to have a dump of the services valueType:
./static-provider=test:read-operation-description(name=add



was (Author: jdenise):
It would also help to have a dump of the services valueType:
./static-provider=test::read-operation-description(name=add


> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7398
>                 URL: https://issues.jboss.org/browse/WFLY-7398
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 05:20:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 28 Oct 2016 05:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7404) Upgrade Generic JMS RA to
	2.0.0.Alpha1
In-Reply-To: <JIRA.12657726.1477646328000@Atlassian.JIRA>
References: <JIRA.12657726.1477646328000@Atlassian.JIRA>
	<JIRA.12657726.1477646328000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657726.1477646328000.608.1477646400773@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-6697 to WFLY-7404:
------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-7404  (was: JBEAP-6697)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: JMS
                     (was: JMS)


> Upgrade Generic JMS RA to 2.0.0.Alpha1
> --------------------------------------
>
>                 Key: WFLY-7404
>                 URL: https://issues.jboss.org/browse/WFLY-7404
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> Upgrade Generic JMS RA to 2.0.0.Alpha1 to support JMS 2.0.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 05:47:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 28 Oct 2016 05:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-649) Make the exists and create
 methods on HttpScope default
In-Reply-To: <JIRA.12652555.1475150598000@Atlassian.JIRA>
References: <JIRA.12652555.1475150598000@Atlassian.JIRA>
	<JIRA.12652555.1475150598000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652555.1475150598000.668.1477648020202@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-649.
----------------------------------
    Fix Version/s: 1.1.0.Beta10
                       (was: 1.1.0.Beta12)
       Resolution: Done


> Make the exists and create methods on HttpScope default
> -------------------------------------------------------
>
>                 Key: ELY-649
>                 URL: https://issues.jboss.org/browse/ELY-649
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI, HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta10
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 06:03:00 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 28 Oct 2016 06:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.751.1477648980362@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-6854:
--------------------------------

    Assignee: Kabir Khan  (was: Scott Marlow)


> Upgrade Hibernate ORM to 5.1.3 
> -------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Kabir Khan
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 06:04:00 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 28 Oct 2016 06:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
In-Reply-To: <JIRA.12639724.1469004783000@Atlassian.JIRA>
References: <JIRA.12639724.1469004783000@Atlassian.JIRA>
	<JIRA.12639724.1469004783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639724.1469004783000.760.1477649040568@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-6854:
--------------------------------

    Assignee: Scott Marlow  (was: Kabir Khan)


> Upgrade Hibernate ORM to 5.1.3 
> -------------------------------
>
>                 Key: WFLY-6854
>                 URL: https://issues.jboss.org/browse/WFLY-6854
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Emmanuel Bernard
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 06:16:00 2016
From: issues at jboss.org (Thibault Daoulas (JIRA))
Date: Fri, 28 Oct 2016 06:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649743000@Atlassian.JIRA>
References: <JIRA.12657738.1477649743000@Atlassian.JIRA>
	<JIRA.12657738.1477649743694@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649743000.799.1477649760268@Atlassian.JIRA>

Thibault Daoulas created DROOLS-1347:
----------------------------------------

             Summary: Explicit expiration of event not effective - regression from 6.4 to 6.5
                 Key: DROOLS-1347
                 URL: https://issues.jboss.org/browse/DROOLS-1347
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 6.5.0.Final
            Reporter: Thibault Daoulas
            Assignee: Mario Fusco


I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 07:06:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 28 Oct 2016 07:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-694) CLIENT-CERT mechanism is
 incorrectly called CLIENT_CERT
In-Reply-To: <JIRA.12657148.1477495538000@Atlassian.JIRA>
References: <JIRA.12657148.1477495538000@Atlassian.JIRA>
	<JIRA.12657148.1477495538000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657148.1477495538000.880.1477652760149@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-694:
---------------------------------
    Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/525, https://github.com/wildfly-security/elytron-web/pull/40  (was: https://github.com/wildfly-security/wildfly-elytron/pull/525)


> CLIENT-CERT mechanism is incorrectly called CLIENT_CERT
> -------------------------------------------------------
>
>                 Key: ELY-694
>                 URL: https://issues.jboss.org/browse/ELY-694
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 07:52:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 28 Oct 2016 07:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1346) Unwanted firing modifying
 an event over a window:time
In-Reply-To: <JIRA.12657587.1477588187000@Atlassian.JIRA>
References: <JIRA.12657587.1477588187000@Atlassian.JIRA>
	<JIRA.12657587.1477588187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657587.1477588187000.1008.1477655520457@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1346.
---------------------------------
    Fix Version/s: 7.0.0.Beta3
       Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/06f5244dfb9be520e8767571f116b91612be7384

> Unwanted firing modifying an event over a window:time
> -----------------------------------------------------
>
>                 Key: DROOLS-1346
>                 URL: https://issues.jboss.org/browse/DROOLS-1346
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.Beta3
>
>
> Steps to reproduce:
> 1. In a first rule pattern match on an event over window:time
> 2. In the consequence of the rule change the value of a field of that event
> 3. Have a second rule that shouldn't match the value of the field changed by the former rule
> 4. This second rule fires even if it shouldn't



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 07:53:00 2016
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 28 Oct 2016 07:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1348) Unwanted firing modifying
 an event over a window:time
In-Reply-To: <JIRA.12657750.1477655577000@Atlassian.JIRA>
References: <JIRA.12657750.1477655577000@Atlassian.JIRA>
	<JIRA.12657750.1477655577819@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657750.1477655577000.1014.1477655580060@Atlassian.JIRA>

Mario Fusco created DROOLS-1348:
-----------------------------------

             Summary: Unwanted firing modifying an event over a window:time
                 Key: DROOLS-1348
                 URL: https://issues.jboss.org/browse/DROOLS-1348
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco
             Fix For: 7.0.0.Beta3


Steps to reproduce:

1. In a first rule pattern match on an event over window:time
2. In the consequence of the rule change the value of a field of that event
3. Have a second rule that shouldn't match the value of the field changed by the former rule
4. This second rule fires even if it shouldn't




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 08:06:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 08:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7398) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.1054.1477656360268@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313393#comment-13313393 ] 

David Lloyd commented on WFLY-7398:
-----------------------------------

Honestly I just tab without even thinking about it so I'm not sure what the exact sequence is but I think I had done:
* Type ...add(
* Tab
* Tab gives ...add(services=[{
* Tab
* Tab gives ...add(services=[{uri=
* Tab
* Tab
* Tab... etc.

> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7398
>                 URL: https://issues.jboss.org/browse/WFLY-7398
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 08:23:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 28 Oct 2016 08:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7398) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.1100.1477657380313@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313398#comment-13313398 ] 

Jean-Francois Denise commented on WFLY-7398:
--------------------------------------------

Thank you for your time,
in case you have some more free cycles,...
As soon as you use tab you get the '\0' right? Whatever the operation?
What about /deployment=toto:add(content=[{url=<TAB>

Any chance to get the services value-type? Perhaps we have strange values there.

Thanks.
JF

> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7398
>                 URL: https://issues.jboss.org/browse/WFLY-7398
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 08:30:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 08:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-697) Add client authentication
 method to authenticate a TLS peer using a security domain
In-Reply-To: <JIRA.12657757.1477657792000@Atlassian.JIRA>
References: <JIRA.12657757.1477657792000@Atlassian.JIRA>
	<JIRA.12657757.1477657792803@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657757.1477657792000.1114.1477657800104@Atlassian.JIRA>

David Lloyd created ELY-697:
-------------------------------

             Summary: Add client authentication method to authenticate a TLS peer using a security domain
                 Key: ELY-697
                 URL: https://issues.jboss.org/browse/ELY-697
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: Authentication Client
            Reporter: David Lloyd
            Priority: Minor


When a client connects to a remote peer, the authentication protocol in use may support true mutual authentication, where the remote peer (server) has to authenticate itself to the client.  Specifically, in the TLS case the client may want to perform client-cert-style authentication with the server certificate, acquiring a SecurityIdentity in return.

The client authentication API should have a way to specify that TLS certificate authentication should happen against a specific security domain.  It should provide a means to acquire the SecurityIdentity from the SSL session (the same way as a server does, if possible).

A server authenticating to a client does not require LoginPermission.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 08:53:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 08:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7398) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.1162.1477659180282@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313402#comment-13313402 ] 

David Lloyd commented on WFLY-7398:
-----------------------------------

I'm not certain when the invalid characters actually appear.  I assume it must be after I tab, but that's really a guess (there's no visual on-screen indicator that the character is there, at least not on my terminal).

> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7398
>                 URL: https://issues.jboss.org/browse/WFLY-7398
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 08:54:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 08:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7398) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.1171.1477659240215@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313404#comment-13313404 ] 

David Lloyd commented on WFLY-7398:
-----------------------------------

Here's all the service code at the time that I hit the issue:

https://github.com/wildfly/wildfly-core/pull/1866/commits/9c648ddae228082b36fe6bbb56e55209cf141a91

> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7398
>                 URL: https://issues.jboss.org/browse/WFLY-7398
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:09:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 09:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1382) AS fails to start with
	colon in path
In-Reply-To: <JIRA.12466427.1337040822000@Atlassian.JIRA>
References: <JIRA.12466427.1337040822000@Atlassian.JIRA>
	<JIRA.12466427.1337040822000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466427.1337040822000.1234.1477660140641@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-1382:
--------------------------------
    Component/s: Modules
                     (was: Scripts)


> AS fails to start with colon in path
> ------------------------------------
>
>                 Key: WFCORE-1382
>                 URL: https://issues.jboss.org/browse/WFCORE-1382
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules
>            Reporter: James Livingston
>
> standalone.sh and domain.sh create the module path passed to JBoss Modules -mp option with:
>   JBOSS_MODULEPATH="$JBOSS_HOME/modules"
> The value passed to -mp is a File.pathSeparator (colon on Linux and semicolon on Windows) delimited list of paths, not a single path, so this does not work correctly when JBOSS_HOME contains a colon on Linux, which is a legal but rare character to use in a path.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:09:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 09:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1382) AS fails to start with
	colon in path
In-Reply-To: <JIRA.12466427.1337040822000@Atlassian.JIRA>
References: <JIRA.12466427.1337040822000@Atlassian.JIRA>
	<JIRA.12466427.1337040822000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466427.1337040822000.1239.1477660140763@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-1382:
--------------------------------
    Priority: Optional  (was: Major)


> AS fails to start with colon in path
> ------------------------------------
>
>                 Key: WFCORE-1382
>                 URL: https://issues.jboss.org/browse/WFCORE-1382
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules
>            Reporter: James Livingston
>            Priority: Optional
>
> standalone.sh and domain.sh create the module path passed to JBoss Modules -mp option with:
>   JBOSS_MODULEPATH="$JBOSS_HOME/modules"
> The value passed to -mp is a File.pathSeparator (colon on Linux and semicolon on Windows) delimited list of paths, not a single path, so this does not work correctly when JBOSS_HOME contains a colon on Linux, which is a legal but rare character to use in a path.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:17:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 28 Oct 2016 09:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7405) Message counters doesn't work
 correctly without server reload after enabling statistics
In-Reply-To: <JIRA.12657779.1477660482000@Atlassian.JIRA>
References: <JIRA.12657779.1477660482000@Atlassian.JIRA>
	<JIRA.12657779.1477660482000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657779.1477660482000.1328.1477660620242@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-6700 to WFLY-7405:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7405  (was: JBEAP-6700)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JMS
                           (was: JMS)
                           (was: User Experience)
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR7)


> Message counters doesn't work correctly without server reload after enabling statistics
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-7405
>                 URL: https://issues.jboss.org/browse/WFLY-7405
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> Server is started with queue deployed. Attribute {{statistics-enabled}} is then set to true in messaging server. This operation doesn't require reload. Start sending messages and look at outputs of operation {{list-message-counter-as-json}} or {{list-message-counter-as-html}} at queue you are using to send messages. ({{message-counter-sample-period}} is set to 10s by default, so give it some time).
> {code:title=list-message-counter-as-json output}
> [standalone at localhost:9990 jms-queue=q] :list-message-counter-as-json
> {
>     "outcome" => "success",
>     "result" => "{\"destinationName\":\"q\",\"destinationSubscription\":null,\"destinationDurable\":true,\"count\":0,\"countDelta\":0,\"messageCount\":47064,\"messageCountDelta\":809,\"lastAddTimestamp\":\"1/1/70 1:00:00 AM\",\"updateTimestamp\":\"1/1/70 1:00:00 AM\"}"
> }
> {code}
> Only attributes {{messageCount}}, {{messageCountDelta}} contain updated values . Other attributes are either null, 0 or default timestamp.
> Output of {{list-message-counter-history-as-json}} is also not correctly updated
> {code:title=list-message-counter-history-as-json output}
> [standalone at localhost:9990 jms-queue=q] :list-message-counter-history-as-json
> {
>     "outcome" => "success",
>     "result" => "{\"dayCounters\":[{\"date\":\"10/27/16\",\"counters\":[-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1]}]}"
> }
> {code}
> After server {{reload}}, output of operations updates and starts working as expected.
> {code:title=Output after reload}
> [standalone at localhost:9990 jms-queue=q] :list-message-counter-history-as-json
> {
>     "outcome" => "success",
>     "result" => "{\"dayCounters\":[{\"date\":\"10/27/16\",\"counters\":[-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,60015,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1]}]}"
> }
> [standalone at localhost:9990 jms-queue=q] :list-message-counter-as-json
> {
>     "outcome" => "success",
>     "result" => "{\"destinationName\":\"q\",\"destinationSubscription\":null,\"destinationDurable\":true,\"count\":60015,\"countDelta\":60015,\"messageCount\":60015,\"messageCountDelta\":60015,\"lastAddTimestamp\":\"10/27/16 11:34:39 AM\",\"updateTimestamp\":\"10/27/16 11:35:29 AM\"}"
> }
> {code}
> Values are also correctly updated when new messages are sent now.
> As administrator, I would like to be able to turn on/off statistics also without server reload. Although it is possible with messaging subsystem, it is not working correctly until reload.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:36:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 09:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1389) Align domain.sh and
 standalone.sh logic about adding -server
In-Reply-To: <JIRA.12471617.1343861745000@Atlassian.JIRA>
References: <JIRA.12471617.1343861745000@Atlassian.JIRA>
	<JIRA.12471617.1343861745000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471617.1343861745000.1371.1477661760333@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFCORE-1389.
-------------------------------
    Fix Version/s: 2.2.0.Final
       Resolution: Out of Date


> Align domain.sh and standalone.sh logic about adding -server
> ------------------------------------------------------------
>
>                 Key: WFCORE-1389
>                 URL: https://issues.jboss.org/browse/WFCORE-1389
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Scripts
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 2.2.0.Final
>
>
> The domain.sh script has a number of JVM vendor checks it uses to decide whether to add -server to the jvm launch command. In standalone.sh it's simpler; it simply checks for OSX.
> I can't see any reason this logic should be significantly different between the two cases, either the JVM vendor checks are needed in both or they aren't needed in either.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:36:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 28 Oct 2016 09:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5773) Remove ASM from Hibernate
 module as its no longer needed
In-Reply-To: <JIRA.12595235.1449160542000@Atlassian.JIRA>
References: <JIRA.12595235.1449160542000@Atlassian.JIRA>
	<JIRA.12595235.1449160542000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12595235.1449160542000.1377.1477661760474@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reassigned WFLY-5773:
----------------------------------

    Assignee: Scott Marlow  (was: Gail Badner)


> Remove ASM from Hibernate module as its no longer needed
> --------------------------------------------------------
>
>                 Key: WFLY-5773
>                 URL: https://issues.jboss.org/browse/WFLY-5773
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 10.0.0.CR4
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> cglib was removed (see [http://in.relation.to/2010/08/19/deprecated-cglib-support]) from Hibernate, so we no longer the <module name="asm.asm"/> dependency in:
> {quote}
> modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml
> modules/system/layers/base/org/hibernate/4.1/module.xml
> modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/module.xml
> modules/system/layers/base/org/hibernate/4.3/module.xml
> modules/system/layers/base/org/hibernate/main/module.xml
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:37:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 28 Oct 2016 09:37:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5773) Remove ASM from Hibernate
 module as its no longer needed
In-Reply-To: <JIRA.12595235.1449160542000@Atlassian.JIRA>
References: <JIRA.12595235.1449160542000@Atlassian.JIRA>
	<JIRA.12595235.1449160542000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12595235.1449160542000.1382.1477661820680@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313424#comment-13313424 ] 

Scott Marlow commented on WFLY-5773:
------------------------------------

taking this back so I can create a pr.

> Remove ASM from Hibernate module as its no longer needed
> --------------------------------------------------------
>
>                 Key: WFLY-5773
>                 URL: https://issues.jboss.org/browse/WFLY-5773
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 10.0.0.CR4
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> cglib was removed (see [http://in.relation.to/2010/08/19/deprecated-cglib-support]) from Hibernate, so we no longer the <module name="asm.asm"/> dependency in:
> {quote}
> modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml
> modules/system/layers/base/org/hibernate/4.1/module.xml
> modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/module.xml
> modules/system/layers/base/org/hibernate/4.3/module.xml
> modules/system/layers/base/org/hibernate/main/module.xml
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:37:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-643) On Windows,
 setting the JAVA_OPTS variable is not
In-Reply-To: <JIRA.12568519.1429117668000@Atlassian.JIRA>
References: <JIRA.12568519.1429117668000@Atlassian.JIRA>
	<JIRA.12568519.1429117668000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568519.1429117668000.1395.1477661821173@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFCORE-643.
------------------------------
    Fix Version/s: 2.2.0.Final
       Resolution: Out of Date


> On Windows, setting the JAVA_OPTS variable is not
> -------------------------------------------------
>
>                 Key: WFCORE-643
>                 URL: https://issues.jboss.org/browse/WFCORE-643
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 1.0.0.Beta4
>         Environment: Windows 7 x64, JRE was bundled with JDK 8 u40 x64.
> Hardware specs:
> CPU: Intel Core i7-3720QM CPU @ 2.60 GHz
> RAM: 16.0 GB
> GPU: NVIDIA Quadro K1000M
> Others upon request.
>            Reporter: Tom Kelley
>            Priority: Minor
>             Fix For: 2.2.0.Final
>
>
> {warn} This issue was copy/pasted from a github issue [here|https://github.com/wildfly/wildfly/issues/7352]. I apologize for 1) the issue duplication, 2) the length of the issue, 3) any poor communication that the transcription caused. {warn}
> My company uses JBoss AS, and I have a copy on my local machine. In setting it up, I wrote a small script that lives in the bin directory and looks something like this:
> {code}
> @rem Delete current log file
> del /F /Q ..\standalone\log\server.log
> @rem Set Java Opts because I want to
> set JAVA_OPTS="-XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms1303M -Xmx1303M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -agentlib:jdwp=transport=dt_socket,server=y,suspend=n"
> @rem Set the new Java Home
> set JAVA_HOME=C:\bin\java\jdk8_u40_64\jre
> @rem Run Jboss
> standalone.bat -c=standalone-full.xml --debug
> {code}
> I noticed when I was starting the server that the JAVA_OPTS in the debug text were not what I was passing in. I figured I could get to the bottom of what was going on, so I started digging in. My investigation led me to standalone.conf.bat, which looks like this:
> {code}
> rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
> rem set PRESERVE_JAVA_OPTS=true
> if not "x%JAVA_OPTS%" == "x" (
>   echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
>   goto JAVA_OPTS_SET
> )
> {code}
> This is very interesting. This snippet of code appears to be a bug. As someone who has worked with batch files, I believe that the correct code should look like this:
> {code}
> rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
> rem set PRESERVE_JAVA_OPTS=true
> if not "x"%JAVA_OPTS% == "x" (
>   echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
>   goto JAVA_OPTS_SET
> )
> {code}
> You must be thinking, "if you know how to do this, why don't you just make the change yourself? It seems trivial." I would, but I'm not able to find the batch file in the source tree. It appears (to me) that the batch file is generated, and I don't know what to start looking for in order to fix this issue on my own.
> As such, I've created a test batch file (meant to be run on Windows) that I've attached to this Issue. When the issue is fixed, it should output something like this:
> {code}
> Calling "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT\bin\standalone.conf.bat"
> "JAVA_OPTS already set in environment; overriding default settings with values: "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
> Setting JAVA property to "C:\bin\java\jdk8_u40_64\jre\bin\java"
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT"
>   JAVA: "C:\bin\java\jdk8_u40_64\jre\bin\java"
>   JAVA_OPTS: "-Dprogram.name=standalone.bat "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
> ===============================================================================
> Error: Could not find or load main class Look at me. LOOK AT ME. I am the JAVA_OPTS now.
> {code}
> The batch file can be acquired [here|https://cloud.githubusercontent.com/assets/2186874/7147925/844bc00c-e2b3-11e4-8320-571fb732bc9f.jpg], just save the link as a batch file, or save it and change the extension (the same way that we get around email filters that don't let us send *.exe's). The way that I ran this was to put the batch file at the root of the Wildfly directory and then call it using window's CMD. The test case does several things:
> 1. Maven clean
> 2. Call build.bat
> 3. Set a JAVA_OPTS system variable
> 4. Call the standalone.bat in the new version of Wildfly that was created in step 2 (as long as the target dir is still wildfly-9.0.0.CR1-SNAPSHOT).
> I would love to take lead on fixing this, but I'm not sure where to start. If someone could give me a point in the right direction, that would be great. Thanks.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:37:01 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 28 Oct 2016 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5773) Remove ASM (and few other
 unneeded dependencies) from JPA module as its no longer needed
In-Reply-To: <JIRA.12595235.1449160542000@Atlassian.JIRA>
References: <JIRA.12595235.1449160542000@Atlassian.JIRA>
	<JIRA.12595235.1449160542000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12595235.1449160542000.1400.1477661821462@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-5773:
-------------------------------
    Summary: Remove ASM (and few other unneeded dependencies) from JPA module as its no longer needed  (was: Remove ASM from Hibernate module as its no longer needed)


> Remove ASM (and few other unneeded dependencies) from JPA module as its no longer needed
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5773
>                 URL: https://issues.jboss.org/browse/WFLY-5773
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 10.0.0.CR4
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> cglib was removed (see [http://in.relation.to/2010/08/19/deprecated-cglib-support]) from Hibernate, so we no longer the <module name="asm.asm"/> dependency in:
> {quote}
> modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml
> modules/system/layers/base/org/hibernate/4.1/module.xml
> modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/module.xml
> modules/system/layers/base/org/hibernate/4.3/module.xml
> modules/system/layers/base/org/hibernate/main/module.xml
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:39:00 2016
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 28 Oct 2016 09:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5773) Remove ASM (and few other
 unneeded dependencies) from JPA module as its no longer needed
In-Reply-To: <JIRA.12595235.1449160542000@Atlassian.JIRA>
References: <JIRA.12595235.1449160542000@Atlassian.JIRA>
	<JIRA.12595235.1449160542000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12595235.1449160542000.1418.1477661940210@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-5773:
-------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Remove ASM (and few other unneeded dependencies) from JPA module as its no longer needed
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-5773
>                 URL: https://issues.jboss.org/browse/WFLY-5773
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 10.0.0.CR4
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>
> cglib was removed (see [http://in.relation.to/2010/08/19/deprecated-cglib-support]) from Hibernate, so we no longer the <module name="asm.asm"/> dependency in:
> {quote}
> modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml
> modules/system/layers/base/org/hibernate/4.1/module.xml
> modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/module.xml
> modules/system/layers/base/org/hibernate/4.3/module.xml
> modules/system/layers/base/org/hibernate/main/module.xml
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:40:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 09:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1010) standalone.sh hard codes
	boot log
In-Reply-To: <JIRA.12586032.1443118216000@Atlassian.JIRA>
References: <JIRA.12586032.1443118216000@Atlassian.JIRA>
	<JIRA.12586032.1443118216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586032.1443118216000.1422.1477662000232@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFCORE-1010.
-------------------------------
    Fix Version/s: 2.2.0.Final
       Resolution: Out of Date


> standalone.sh hard codes boot log
> ---------------------------------
>
>                 Key: WFCORE-1010
>                 URL: https://issues.jboss.org/browse/WFCORE-1010
>             Project: WildFly Core
>          Issue Type: Patch
>          Components: Scripts
>            Reporter: Philippe Marschall
>            Assignee: James Perkins
>             Fix For: 2.2.0.Final
>
>
> The {{standalone.sh}} file hard codes the {{org.jboss.boot.log.file}} property to {{server.log}}. This is inconvenient because it overrides the dynamic configuration in {{logging.properties}} which is set to ${org.jboss.boot.log.file:boot.log}. Maybe the value in logging.properties should instead default to {{server.log}}.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:46:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 09:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-306) Update add-user to use AESH
 or move it into the CLI
In-Reply-To: <JIRA.12539089.1398430273000@Atlassian.JIRA>
References: <JIRA.12539089.1398430273000@Atlassian.JIRA>
	<JIRA.12539089.1398430273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539089.1398430273000.1452.1477662361216@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFCORE-306:
----------------------------------

    Assignee: Jean-Francois Denise  (was: Darran Lofthouse)


> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
>                 Key: WFCORE-306
>                 URL: https://issues.jboss.org/browse/WFCORE-306
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Jean-Francois Denise
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:46:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 09:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-306) Update add-user to use AESH
 or move it into the CLI
In-Reply-To: <JIRA.12539089.1398430273000@Atlassian.JIRA>
References: <JIRA.12539089.1398430273000@Atlassian.JIRA>
	<JIRA.12539089.1398430273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539089.1398430273000.1470.1477662361667@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313430#comment-13313430 ] 

Tomaz Cerar commented on WFCORE-306:
------------------------------------

Assigning to [~jdenise] as he has reworked CLI to be more plugalabe by custom commands.

> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
>                 Key: WFCORE-306
>                 URL: https://issues.jboss.org/browse/WFCORE-306
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Jean-Francois Denise
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:56:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 28 Oct 2016 09:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-306) Update add-user to use AESH
 or move it into the CLI
In-Reply-To: <JIRA.12539089.1398430273000@Atlassian.JIRA>
References: <JIRA.12539089.1398430273000@Atlassian.JIRA>
	<JIRA.12539089.1398430273000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539089.1398430273000.1538.1477662960594@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313437#comment-13313437 ] 

Darran Lofthouse commented on WFCORE-306:
-----------------------------------------

This task should wait until we switch to the new file system security realm by default - once we switch to that realm updates can be performed using management operations so it will make more sense to be a part of the CLI especially where we can embed the server in the CLI.

> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
>                 Key: WFCORE-306
>                 URL: https://issues.jboss.org/browse/WFCORE-306
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Jean-Francois Denise
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 09:59:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 28 Oct 2016 09:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649744000@Atlassian.JIRA>
References: <JIRA.12657738.1477649744000@Atlassian.JIRA>
	<JIRA.12657738.1477649744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649744000.1572.1477663140183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari reassigned DROOLS-1347:
--------------------------------------

    Assignee: Matteo Mortari  (was: Mario Fusco)


> Explicit expiration of event not effective - regression from 6.4 to 6.5
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1347
>                 URL: https://issues.jboss.org/browse/DROOLS-1347
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Thibault Daoulas
>            Assignee: Matteo Mortari
>
> I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:06:00 2016
From: issues at jboss.org (Ken Wills (JIRA))
Date: Fri, 28 Oct 2016 10:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1903) Slaves receiving an
 exception during registration hang and don't exit
In-Reply-To: <JIRA.12657786.1477663502000@Atlassian.JIRA>
References: <JIRA.12657786.1477663502000@Atlassian.JIRA>
	<JIRA.12657786.1477663502274@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657786.1477663502000.1696.1477663560469@Atlassian.JIRA>

Ken Wills created WFCORE-1903:
---------------------------------

             Summary: Slaves receiving an exception during registration hang and don't exit
                 Key: WFCORE-1903
                 URL: https://issues.jboss.org/browse/WFCORE-1903
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Ken Wills
            Assignee: Ken Wills


Existing PR here: https://github.com/wildfly/wildfly-core/pull/1881



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:06:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 28 Oct 2016 10:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7406) Cleanup HornetQ xsd files in
 "docs/schema" directory
In-Reply-To: <JIRA.12657787.1477663538000@Atlassian.JIRA>
References: <JIRA.12657787.1477663538000@Atlassian.JIRA>
	<JIRA.12657787.1477663538391@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657787.1477663538000.1705.1477663560895@Atlassian.JIRA>

Jeff Mesnil created WFLY-7406:
---------------------------------

             Summary: Cleanup HornetQ xsd files in "docs/schema" directory
                 Key: WFLY-7406
                 URL: https://issues.jboss.org/browse/WFLY-7406
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 10.0.0.CR4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
            Priority: Minor


The download zip for WildFly 10.0CR4 contains the xsd files for HornetQ messaging configurations in "docs/schema". Those are obsoleted by ActiveMQ and should be removed.

-jboss-as-messaging-deployment_1_0.xsd  (deployment of a "-jms.xml" file according to this old schema will fail with an error anyway), replaced by "wildfly-messaging-activemq-deployment_1_0.xsd")
-jboss-as-messaging_x_y.xsd (server configuration files, replaced by "wildfly-messaging-activemq_1_0.xsd").



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:13:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 10:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1904) Enviroment variable
 DEBUG_PORT doesn't work with standalone.bat
In-Reply-To: <JIRA.12657788.1477663947000@Atlassian.JIRA>
References: <JIRA.12657788.1477663947000@Atlassian.JIRA>
	<JIRA.12657788.1477663947844@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657788.1477663947000.1800.1477663980611@Atlassian.JIRA>

Tomaz Cerar created WFCORE-1904:
-----------------------------------

             Summary: Enviroment variable DEBUG_PORT doesn't work with standalone.bat
                 Key: WFCORE-1904
                 URL: https://issues.jboss.org/browse/WFCORE-1904
             Project: WildFly Core
          Issue Type: Bug
          Components: Scripts
         Environment: windows
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar
             Fix For: 3.0.0.Alpha11


This issue is blocked by JBEAP-5551 in 7.1.0.DR2. But I fixed standalone.conf.bat locally (I used fix from PR from JBEAP-5551) and port still can't be changed by env variable, see this example:
{noformat}
set DEBUG=true
set DEBUG_PORT=7878

C:\Users\Administrator\playground\7.1.0.DR2\jboss-eap-7.1\bin>standalone.bat
Calling "C:\Users\Administrator\playground\7.1.0.DR2\jboss-eap-7.1\bin\standalone.conf.bat"
Setting JAVA property to "C:\jdk1.8.0_45\bin\java"

===============================================================================
  JBoss Bootstrap Environment
  JBOSS_HOME: "C:\Users\Administrator\playground\7.1.0.DR2\jboss-eap-7.1"
  JAVA: "C:\jdk1.8.0_45\bin\java"
  JAVA_OPTS: "-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogF

ileSize=3M -Xloggc: -XX:-TraceClassUnloading -Dprogram.name=standalone.bat -Xms1G -Xmx1G -XX:MetaspaceSize=96M -XX:MaxMetaspaceSiz

e=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -agentlib:jdwp=transport=dt_socket,address=87

87,server=y,suspend=n"
===============================================================================
Listening for transport dt_socket at address: 8787
{noformat}
8787 port is used. 7878 port should be used in this example.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:13:01 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 28 Oct 2016 10:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7407) split artemis journal in its
	own module
In-Reply-To: <JIRA.12657789.1477663971000@Atlassian.JIRA>
References: <JIRA.12657789.1477663971000@Atlassian.JIRA>
	<JIRA.12657789.1477663971967@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657789.1477663971000.1809.1477663981022@Atlassian.JIRA>

Jeff Mesnil created WFLY-7407:
---------------------------------

             Summary: split artemis journal in its own module
                 Key: WFLY-7407
                 URL: https://issues.jboss.org/browse/WFLY-7407
             Project: WildFly
          Issue Type: Enhancement
          Components: JMS
    Affects Versions: 10.0.0.CR2
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
            Priority: Minor
             Fix For: 11.0.0.Alpha1


The org.jboss.jts is depending on the org.apache.activemq.artemis only for its journal functionality but get all the module dependencies (including messaging stuff) that is not used at all.

The org.apache.activemq.artemis should be split with a separate module for its journal containing the journal jar + commons jar + native lib required for libAIO.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:15:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 10:15:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1904) Enviroment variable
 DEBUG_PORT doesn't work with standalone.bat
In-Reply-To: <JIRA.12657788.1477663948000@Atlassian.JIRA>
References: <JIRA.12657788.1477663948000@Atlassian.JIRA>
	<JIRA.12657788.1477663948000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657788.1477663948000.1843.1477664100836@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar deleted WFCORE-1904:
--------------------------------


> Enviroment variable DEBUG_PORT doesn't work with standalone.bat
> ---------------------------------------------------------------
>
>                 Key: WFCORE-1904
>                 URL: https://issues.jboss.org/browse/WFCORE-1904
>             Project: WildFly Core
>          Issue Type: Bug
>         Environment: windows
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> This issue is blocked by JBEAP-5551 in 7.1.0.DR2. But I fixed standalone.conf.bat locally (I used fix from PR from JBEAP-5551) and port still can't be changed by env variable, see this example:
> {noformat}
> set DEBUG=true
> set DEBUG_PORT=7878
> C:\Users\Administrator\playground\7.1.0.DR2\jboss-eap-7.1\bin>standalone.bat
> Calling "C:\Users\Administrator\playground\7.1.0.DR2\jboss-eap-7.1\bin\standalone.conf.bat"
> Setting JAVA property to "C:\jdk1.8.0_45\bin\java"
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: "C:\Users\Administrator\playground\7.1.0.DR2\jboss-eap-7.1"
>   JAVA: "C:\jdk1.8.0_45\bin\java"
>   JAVA_OPTS: "-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogF
> ileSize=3M -Xloggc: -XX:-TraceClassUnloading -Dprogram.name=standalone.bat -Xms1G -Xmx1G -XX:MetaspaceSize=96M -XX:MaxMetaspaceSiz
> e=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -agentlib:jdwp=transport=dt_socket,address=87
> 87,server=y,suspend=n"
> ===============================================================================
> Listening for transport dt_socket at address: 8787
> {noformat}
> 8787 port is used. 7878 port should be used in this example.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:15:01 2016
From: issues at jboss.org (Ken Wills (JIRA))
Date: Fri, 28 Oct 2016 10:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1903) Slaves receiving an
 exception during registration hang and don't exit
In-Reply-To: <JIRA.12657786.1477663502000@Atlassian.JIRA>
References: <JIRA.12657786.1477663502000@Atlassian.JIRA>
	<JIRA.12657786.1477663502000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657786.1477663502000.1863.1477664101316@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills closed WFCORE-1903.
-----------------------------
    Resolution: Cannot Reproduce Bug


> Slaves receiving an exception during registration hang and don't exit
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-1903
>                 URL: https://issues.jboss.org/browse/WFCORE-1903
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> Existing PR here: https://github.com/wildfly/wildfly-core/pull/1881



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:16:01 2016
From: issues at jboss.org (Ken Wills (JIRA))
Date: Fri, 28 Oct 2016 10:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1903) Slaves receiving an
 exception during registration hang and don't exit
In-Reply-To: <JIRA.12657786.1477663502000@Atlassian.JIRA>
References: <JIRA.12657786.1477663502000@Atlassian.JIRA>
	<JIRA.12657786.1477663502000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657786.1477663502000.1887.1477664161340@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313457#comment-13313457 ] 

Ken Wills commented on WFCORE-1903:
-----------------------------------

Accidently tested against wrong branch, so not really a bug. 

> Slaves receiving an exception during registration hang and don't exit
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-1903
>                 URL: https://issues.jboss.org/browse/WFCORE-1903
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> Existing PR here: https://github.com/wildfly/wildfly-core/pull/1881



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:19:00 2016
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Fri, 28 Oct 2016 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1349) Eager evaluation with
 no-loop causes endless loop
In-Reply-To: <JIRA.12657791.1477664293000@Atlassian.JIRA>
References: <JIRA.12657791.1477664293000@Atlassian.JIRA>
	<JIRA.12657791.1477664293278@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657791.1477664293000.1911.1477664340566@Atlassian.JIRA>

Petr ?irok? created DROOLS-1349:
-----------------------------------

             Summary: Eager evaluation with no-loop causes endless loop
                 Key: DROOLS-1349
                 URL: https://issues.jboss.org/browse/DROOLS-1349
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Petr ?irok?
            Assignee: Mario Fusco


Using {{no-loop}} with eager evaluation does not work as expected. The {{no-loop}} rule keeps firing in endless loop.

This test case in jBPM reproduces the issue https://github.com/droolsjbpm/jbpm/blob/master/jbpm-bpmn2/src/test/java/org/jbpm/bpmn2/ActivityTest.java#L1294 (testBusinessRuleTaskDynamic).



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Fri Oct 28 10:19:00 2016
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Fri, 28 Oct 2016 10:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1349) Eager evaluation with
 no-loop causes endless loop
In-Reply-To: <JIRA.12657791.1477664293000@Atlassian.JIRA>
References: <JIRA.12657791.1477664293000@Atlassian.JIRA>
	<JIRA.12657791.1477664293000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657791.1477664293000.1916.1477664340768@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? updated DROOLS-1349:
--------------------------------
    Description: 
Using {{no-loop}} with eager evaluation does not work as expected. The {{no-loop}} rule keeps firing in endless loop.

This test case in jBPM reproduces the issue https://github.com/droolsjbpm/jbpm/blob/6.5.x/jbpm-bpmn2/src/test/java/org/jbpm/bpmn2/ActivityTest.java#L1294 (testBusinessRuleTaskDynamic).

  was:
Using {{no-loop}} with eager evaluation does not work as expected. The {{no-loop}} rule keeps firing in endless loop.

This test case in jBPM reproduces the issue https://github.com/droolsjbpm/jbpm/blob/master/jbpm-bpmn2/src/test/java/org/jbpm/bpmn2/ActivityTest.java#L1294 (testBusinessRuleTaskDynamic).



> Eager evaluation with no-loop causes endless loop
> -------------------------------------------------
>
>                 Key: DROOLS-1349
>                 URL: https://issues.jboss.org/browse/DROOLS-1349
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Petr ?irok?
>            Assignee: Mario Fusco
>
> Using {{no-loop}} with eager evaluation does not work as expected. The {{no-loop}} rule keeps firing in endless loop.
> This test case in jBPM reproduces the issue https://github.com/droolsjbpm/jbpm/blob/6.5.x/jbpm-bpmn2/src/test/java/org/jbpm/bpmn2/ActivityTest.java#L1294 (testBusinessRuleTaskDynamic).



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Fri Oct 28 10:24:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 10:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-350) Domain reflects
 jboss.server.xy properties
In-Reply-To: <JIRA.12447180.1316175858000@Atlassian.JIRA>
References: <JIRA.12447180.1316175858000@Atlassian.JIRA>
	<JIRA.12447180.1316175858000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447180.1316175858000.1966.1477664640209@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-350:
-------------------------------
    Component/s:     (was: Scripts)


> Domain reflects jboss.server.xy properties
> ------------------------------------------
>
>                 Key: WFCORE-350
>                 URL: https://issues.jboss.org/browse/WFCORE-350
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Rostislav Svoboda
>            Priority: Minor
>
> Domain reflects jboss.server.xy properties, tested with jboss.server.log.dir property.
> The same server.log file is used for both server-one and server-two. Only file boot.log is created in  domain/servers/server-one/log and domain/servers/server-two/log directory. In my case file server.log contains log only for server-one, there is no log for server-two.
> I think jboss.server.xy properties shouldn't be reflected in domain instances.
> Even structure of https://docs.jboss.org/author/display/AS71/Command+line+parameters implies that jboss.server.xy properties are used for Standalone.
> Reproducer of my steps:
> {code}
>  rm -rf domain/servers
>  bin/domain.sh -Djboss.server.log.dir=/tmp/
>  ls -aR domain/servers/server-one/log
>  ls -aR domain/servers/server-two/log
>  ls -l /tmp/server*
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:28:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 10:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1905) windows service
 (service.bat) failed to install if the value of /serviceuser has a white
 space inside
In-Reply-To: <JIRA.12656819.1477443070000@Atlassian.JIRA>
References: <JIRA.12656819.1477443070000@Atlassian.JIRA>
	<JIRA.12656819.1477443070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656819.1477443070000.2046.1477664881116@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved WFLY-7380 to WFCORE-1905:
-------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-1905  (was: WFLY-7380)
          Component/s: Scripts
                           (was: Scripts)
    Affects Version/s:     (was: 10.1.0.Final)


> windows service (service.bat) failed to install if the value of /serviceuser has a white space inside
> -----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1905
>                 URL: https://issues.jboss.org/browse/WFCORE-1905
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>            Reporter: Brad Maxwell
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> When using "service.bat install /serviceuser ..." command to install window service, if the account name behind /serviceuser has a whit space inside like ".\JBoss User", it will failed to install windows service.
> Run command: service.bat install /serviceuser ".\JBoss User" /servicepass "change it" /startup /debug
> When starting it, an error window poped up:
> {code}
> Windows could not start the JBossEAP6 on Local Computer.
> For more information, review the System Event Log. 
> If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1.
> {code}
> Additional info:
> Possible fix is editing "service.bat" and add double quotation marks on %SERVICE_USER% 
> From 
> {code}
> set RUNAS=--ServiceUser=%SERVICE_USER% --ServicePassword=%SERVICE_PASS%
> {code}
> to
> {code}
> set RUNAS=--ServiceUser="%SERVICE_USER%" --ServicePassword="%SERVICE_PASS%"
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:33:01 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 10:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1906) standalone.bat is unable to
 start from directory "jboss(eap)" on Windows
In-Reply-To: <JIRA.12657794.1477665127000@Atlassian.JIRA>
References: <JIRA.12657794.1477665127000@Atlassian.JIRA>
	<JIRA.12657794.1477665127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657794.1477665127000.2137.1477665181694@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved JBEAP-6703 to WFCORE-1906:
--------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-1906  (was: JBEAP-6703)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Scripts
                           (was: Scripts)
    Affects Version/s: 3.0.0.Alpha10
                           (was: 7.1.0.DR4)
      Affects Testing:   (was: Regression)


> standalone.bat is unable to start from directory "jboss(eap)" on Windows
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-1906
>                 URL: https://issues.jboss.org/browse/WFCORE-1906
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Critical
>
> standalone.bat is unable to start from directory "jboss(eap)" on Windows
> This is regression against EAP 7.1.0.DR3.
> Actual results:
> {noformat}
> C:\Users\Administrator\playground\7.1.0.DR5\jboss(eap)\bin>standalone.bat
> Calling "C:\Users\Administrator\playground\7.1.0.DR5\jboss(eap)\bin\standalone.conf.bat"
> "JAVA_OPTS already set in environment; overriding default settings with values: -Dprogram.name=standalone.bat -Xms1G -Xmx1G -XX:Me
> taspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman"
> "GC_LOG set in environment to true"
> Setting JAVA property to "C:\jdk1.8.0_45\bin\java"
> \standalone\log\gc.log" -XX:-TraceClassUnloading -Dprogram.name=standalone.bat -Dprogram.name=standalone.bat -Xms1G -Xmx1G -XX:Met
> aspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman" was unexpe
> cted at this time.
> C:\Users\Administrator\playground\7.1.0.DR5\jboss(eap)\bin>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:51:02 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 10:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1907) Win Service Script: Revise
 help for /host
In-Reply-To: <JIRA.12657796.1477666217000@Atlassian.JIRA>
References: <JIRA.12657796.1477666217000@Atlassian.JIRA>
	<JIRA.12657796.1477666217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657796.1477666217000.2469.1477666262294@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved JBEAP-6704 to WFCORE-1907:
--------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-1907  (was: JBEAP-6704)
           Issue Type: Enhancement  (was: Bug)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Scripts
                           (was: Scripts)
    Affects Version/s:     (was: 7.0.0.GA)


> Win Service Script: Revise help for /host
> -----------------------------------------
>
>                 Key: WFCORE-1907
>                 URL: https://issues.jboss.org/browse/WFCORE-1907
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Scripts
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> The help text for the /host parameter is misleading.
> The current help text for the /host parameter is:
> {quote}/host [^<domainhost^>] : Indicates that domain mode is to be used with an optional domain controller name.{quote}
> A better description would be:
> bq. Indicates that domain mode is to be used, with an optional domain/host controller name.
> 6.4 Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1375439
> Customer support case: 01676698



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:54:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 28 Oct 2016 10:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649744000@Atlassian.JIRA>
References: <JIRA.12657738.1477649744000@Atlassian.JIRA>
	<JIRA.12657738.1477649744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649744000.2485.1477666440168@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313496#comment-13313496 ] 

Matteo Mortari commented on DROOLS-1347:
----------------------------------------

Simplified reproducer with assertions, aligned with OP's case:

{code:java}
public class RuleTest {
    static final Logger LOG = LoggerFactory.getLogger(RuleTest.class);

    @Test
    public void test() throws InstantiationException, IllegalAccessException {
        KieServices kieServices = KieServices.Factory.get();

        KieContainer kContainer = kieServices.getKieClasspathContainer();
        Results verifyResults = kContainer.verify();
        for (Message m : verifyResults.getMessages()) {
            LOG.info("{}", m);
        }

        LOG.info("Creating kieBase with STREAM option");
        KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
        kieBaseConf.setOption( EventProcessingOption.STREAM );
        KieBase kieBase = kContainer.newKieBase(kieBaseConf);

        LOG.info("There should be rules: ");
        for ( KiePackage kp : kieBase.getKiePackages() ) {
            for (Rule rule : kp.getRules()) {
                LOG.info("kp " + kp + " rule " + rule.getName());
            }
        }

        LOG.info("Creating kieSession");
        KieSessionConfiguration config = kieServices.newKieSessionConfiguration();
        config.setOption( ClockTypeOption.get("pseudo") );
        KieSession session = kieBase.newKieSession(config, null);
        SessionPseudoClock clock = session.getSessionClock();
        
        session.addEventListener(new DebugRuleRuntimeEventListener() {
            @Override
            public void objectDeleted(ObjectDeletedEvent event) {
                System.out.println(event.getOldObject() + " " + "x");
            }

            @Override
            public void objectInserted(ObjectInsertedEvent event) {
                System.out.println("x" + " " + event.getObject());
            }

            @Override
            public void objectUpdated(ObjectUpdatedEvent event) {
                System.out.println(event.getOldObject() + " " + event.getObject());
            }
        });
        session.addEventListener(new DefaultAgendaEventListener() {
            @Override
            public void afterMatchFired(AfterMatchFiredEvent event) {
                System.out.println("fired: "+event.getMatch().getRule());
            }
        });
        
        LOG.info("Populating globals");
        List<String> check = new ArrayList<String>();
        session.setGlobal("list", check);
        
        LOG.info("Now running data");
        
        System.out.println("---a---");
        clock.advanceTime(1000L, TimeUnit.MILLISECONDS);
        session.insert( new Character('a') );
        session.fireAllRules();
        print(session);
        assertTrue(check.contains("Rexpected"));
        assertFalse(check.contains("Ravoid"));
        
        System.out.println("---b---");
        clock.advanceTime(3600000L, TimeUnit.MILLISECONDS);
        session.insert( new Character('b') );
        session.fireAllRules();
        print(session);
        assertTrue(check.contains("Rexpected"));
        assertFalse(check.contains("Ravoid"));
        
        
    }

    private void print(KieSession session) {
        System.out.println("Session facts:");
        for ( FactHandle fh : session.getFactHandles() ) {
            InternalFactHandle ifh = (InternalFactHandle) fh;
            System.out.println(" > "+ifh.getObject()+" ["+ifh.getObjectClassName()+"] FH: "+fh);
        }
    }
}
{code}

And rules:

{code:java}
package org.drools.DROOLS_1347;

global java.util.List list;

declare Character
@role( event )
@expires( 1s )
end

declare String
@role( event )
@expires( 10m )
end

rule "Rexpected"
when
    $t : Character() over window:length(1) 
    not String() 
then
    insert("good");
    list.add("Rexpected");
end

rule "Ravoid"
when
    $t : Character() over window:length(1) 
    exists String(this before $t)
    not String(this coincides $t)
then
    insert("bad");
    list.add("Ravoid");
end
{code}


> Explicit expiration of event not effective - regression from 6.4 to 6.5
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1347
>                 URL: https://issues.jboss.org/browse/DROOLS-1347
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Thibault Daoulas
>            Assignee: Matteo Mortari
>
> I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 10:56:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 28 Oct 2016 10:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649744000@Atlassian.JIRA>
References: <JIRA.12657738.1477649744000@Atlassian.JIRA>
	<JIRA.12657738.1477649744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649744000.2494.1477666560488@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313497#comment-13313497 ] 

Matteo Mortari commented on DROOLS-1347:
----------------------------------------

Linking JIRA case [DROOLS-311] which provided the fix for the expected expiration behavior.

> Explicit expiration of event not effective - regression from 6.4 to 6.5
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1347
>                 URL: https://issues.jboss.org/browse/DROOLS-1347
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Thibault Daoulas
>            Assignee: Matteo Mortari
>
> I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:01:01 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 28 Oct 2016 11:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649744000@Atlassian.JIRA>
References: <JIRA.12657738.1477649744000@Atlassian.JIRA>
	<JIRA.12657738.1477649744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649744000.2565.1477666861108@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313504#comment-13313504 ] 

Matteo Mortari commented on DROOLS-1347:
----------------------------------------

With reference to [DROOLS-311].

This issue [DROOLS-1347] is assuming the previous behavior of expiration, which has now been fixed to align with design requirements
{quote}
1. Expired events does not cancel rule activations
{quote}

Hence, with [DROOLS-311] now fixed, when the clock is advanced a second time, the expired event is still given the chance to match (as required by design).

Not a bug. Not a regression.

> Explicit expiration of event not effective - regression from 6.4 to 6.5
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1347
>                 URL: https://issues.jboss.org/browse/DROOLS-1347
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Thibault Daoulas
>            Assignee: Matteo Mortari
>
> I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:02:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 28 Oct 2016 11:02:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649744000@Atlassian.JIRA>
References: <JIRA.12657738.1477649744000@Atlassian.JIRA>
	<JIRA.12657738.1477649744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649744000.2606.1477666920206@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313504#comment-13313504 ] 

Matteo Mortari edited comment on DROOLS-1347 at 10/28/16 11:01 AM:
-------------------------------------------------------------------

With reference to [DROOLS-311].

This issue [DROOLS-1347] is assuming the previous behavior of expiration (as behaving before 6.5.0.Final), which has now been fixed to align with design requirements
{quote}
1. Expired events does not cancel rule activations
{quote}

Hence, with [DROOLS-311] now fixed (from 6.5.0.Final), when the clock is advanced a second time, the expired event is still given the chance to match (as required by design).

Not a bug. Not a regression.


was (Author: tari_manga):
With reference to [DROOLS-311].

This issue [DROOLS-1347] is assuming the previous behavior of expiration, which has now been fixed to align with design requirements
{quote}
1. Expired events does not cancel rule activations
{quote}

Hence, with [DROOLS-311] now fixed, when the clock is advanced a second time, the expired event is still given the chance to match (as required by design).

Not a bug. Not a regression.

> Explicit expiration of event not effective - regression from 6.4 to 6.5
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1347
>                 URL: https://issues.jboss.org/browse/DROOLS-1347
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Thibault Daoulas
>            Assignee: Matteo Mortari
>
> I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:04:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 28 Oct 2016 11:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649744000@Atlassian.JIRA>
References: <JIRA.12657738.1477649744000@Atlassian.JIRA>
	<JIRA.12657738.1477649744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649744000.2647.1477667040177@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313496#comment-13313496 ] 

Matteo Mortari edited comment on DROOLS-1347 at 10/28/16 11:03 AM:
-------------------------------------------------------------------

Simplified reproducer with assertions, aligned with OP's case:

{code:java}
public class RuleTest {
    static final Logger LOG = LoggerFactory.getLogger(RuleTest.class);

    @Test
    public void test() throws InstantiationException, IllegalAccessException {
        KieServices kieServices = KieServices.Factory.get();

        KieContainer kContainer = kieServices.getKieClasspathContainer();
        Results verifyResults = kContainer.verify();
        for (Message m : verifyResults.getMessages()) {
            LOG.info("{}", m);
        }

        LOG.info("Creating kieBase with STREAM option");
        KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
        kieBaseConf.setOption( EventProcessingOption.STREAM );
        KieBase kieBase = kContainer.newKieBase(kieBaseConf);

        LOG.info("There should be rules: ");
        for ( KiePackage kp : kieBase.getKiePackages() ) {
            for (Rule rule : kp.getRules()) {
                LOG.info("kp " + kp + " rule " + rule.getName());
            }
        }

        LOG.info("Creating kieSession");
        KieSessionConfiguration config = kieServices.newKieSessionConfiguration();
        config.setOption( ClockTypeOption.get("pseudo") );
        KieSession session = kieBase.newKieSession(config, null);
        SessionPseudoClock clock = session.getSessionClock();
        
        session.addEventListener(new DebugRuleRuntimeEventListener() {
            @Override
            public void objectDeleted(ObjectDeletedEvent event) {
                System.out.println(event.getOldObject() + " " + "x");
            }

            @Override
            public void objectInserted(ObjectInsertedEvent event) {
                System.out.println("x" + " " + event.getObject());
            }

            @Override
            public void objectUpdated(ObjectUpdatedEvent event) {
                System.out.println(event.getOldObject() + " " + event.getObject());
            }
        });
        session.addEventListener(new DefaultAgendaEventListener() {
            @Override
            public void afterMatchFired(AfterMatchFiredEvent event) {
                System.out.println("fired: "+event.getMatch().getRule());
            }
        });
        
        LOG.info("Populating globals");
        List<String> check = new ArrayList<String>();
        session.setGlobal("list", check);
        
        LOG.info("Now running data");
        
        System.out.println("---a---");
        clock.advanceTime(1000L, TimeUnit.MILLISECONDS);
        session.insert( new Character('a') );
        session.fireAllRules();
        print(session);
        assertTrue(check.contains("Rexpected"));
        assertFalse(check.contains("Ravoid"));
        
        System.out.println("---b---");
        clock.advanceTime(3600000L, TimeUnit.MILLISECONDS);
        session.insert( new Character('b') );
        session.fireAllRules();
        print(session);
        assertTrue(check.contains("Rexpected"));
        assertFalse(check.contains("Ravoid"));
        
        
    }

    private void print(KieSession session) {
        System.out.println("Session facts:");
        for ( FactHandle fh : session.getFactHandles() ) {
            InternalFactHandle ifh = (InternalFactHandle) fh;
            System.out.println(" > "+ifh.getObject()+" ["+ifh.getObjectClassName()+"] FH: "+fh);
        }
    }
}
{code}

And rules:

{code:java}
package org.drools.DROOLS_1347;

global java.util.List list;

declare Character
@role( event )
@expires( 1s )
end

declare String
@role( event )
@expires( 10m )
end

rule "Rexpected"
when
    $t : Character() over window:length(1) 
    not String() 
then
    insert("good");
    list.add("Rexpected");
end

rule "Ravoid"
when
    $t : Character() over window:length(1) 
    exists String(this before $t)
    not String(this coincides $t)
then
    insert("bad");
    list.add("Ravoid");
end
{code}

and output:

{code}
2016-10-28 17:01:57,314 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Found kmodule: file:/home/mmortari/git/DROOLS-1347/target/classes/META-INF/kmodule.xml
2016-10-28 17:01:57,527 WARN  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Unable to find pom.properties in /home/mmortari/git/DROOLS-1347/target/classes
2016-10-28 17:01:57,536 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Recursed up folders, found and used pom.xml /home/mmortari/git/DROOLS-1347/pom.xml
2016-10-28 17:01:57,543 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule was added: FileKieModule[releaseId=org.drools:DROOLS-1347:0.0.1-SNAPSHOT,file=/home/mmortari/git/DROOLS-1347/target/classes]
2016-10-28 17:01:58,390 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Creating kieBase with STREAM option
2016-10-28 17:01:58,454 INFO  [org.drools.DROOLS_1347.RuleTest] (main) There should be rules: 
2016-10-28 17:01:58,454 INFO  [org.drools.DROOLS_1347.RuleTest] (main) kp [Package name=org.drools.DROOLS_1347] rule Rexpected
2016-10-28 17:01:58,454 INFO  [org.drools.DROOLS_1347.RuleTest] (main) kp [Package name=org.drools.DROOLS_1347] rule Ravoid
2016-10-28 17:01:58,454 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Creating kieSession
2016-10-28 17:01:58,499 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Populating globals
2016-10-28 17:01:58,500 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Now running data
---a---
x a
x good
fired: [Rule name=Rexpected, agendaGroup=MAIN, salience=0, no-loop=false]
Session facts:
 > a [java.lang.Character] FH: 5:1:504858437:97:1:DEFAULT:NON_TRAIT:java.lang.Character
 > good [java.lang.String] FH: 5:2:775386112:3178685:2:DEFAULT:NON_TRAIT:java.lang.String
---b---
x b
x bad
fired: [Rule name=Ravoid, agendaGroup=MAIN, salience=0, no-loop=false]
Session facts:
 > b [java.lang.Character] FH: 5:3:391630194:98:3:DEFAULT:NON_TRAIT:java.lang.Character
 > bad [java.lang.String] FH: 5:4:1146825051:97285:4:DEFAULT:NON_TRAIT:java.lang.String
{code}

Please notice despite the assertion fails, no expired events are present in the session anyway after all the rules have been fired and fireAllRules() has returned.


was (Author: tari_manga):
Simplified reproducer with assertions, aligned with OP's case:

{code:java}
public class RuleTest {
    static final Logger LOG = LoggerFactory.getLogger(RuleTest.class);

    @Test
    public void test() throws InstantiationException, IllegalAccessException {
        KieServices kieServices = KieServices.Factory.get();

        KieContainer kContainer = kieServices.getKieClasspathContainer();
        Results verifyResults = kContainer.verify();
        for (Message m : verifyResults.getMessages()) {
            LOG.info("{}", m);
        }

        LOG.info("Creating kieBase with STREAM option");
        KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
        kieBaseConf.setOption( EventProcessingOption.STREAM );
        KieBase kieBase = kContainer.newKieBase(kieBaseConf);

        LOG.info("There should be rules: ");
        for ( KiePackage kp : kieBase.getKiePackages() ) {
            for (Rule rule : kp.getRules()) {
                LOG.info("kp " + kp + " rule " + rule.getName());
            }
        }

        LOG.info("Creating kieSession");
        KieSessionConfiguration config = kieServices.newKieSessionConfiguration();
        config.setOption( ClockTypeOption.get("pseudo") );
        KieSession session = kieBase.newKieSession(config, null);
        SessionPseudoClock clock = session.getSessionClock();
        
        session.addEventListener(new DebugRuleRuntimeEventListener() {
            @Override
            public void objectDeleted(ObjectDeletedEvent event) {
                System.out.println(event.getOldObject() + " " + "x");
            }

            @Override
            public void objectInserted(ObjectInsertedEvent event) {
                System.out.println("x" + " " + event.getObject());
            }

            @Override
            public void objectUpdated(ObjectUpdatedEvent event) {
                System.out.println(event.getOldObject() + " " + event.getObject());
            }
        });
        session.addEventListener(new DefaultAgendaEventListener() {
            @Override
            public void afterMatchFired(AfterMatchFiredEvent event) {
                System.out.println("fired: "+event.getMatch().getRule());
            }
        });
        
        LOG.info("Populating globals");
        List<String> check = new ArrayList<String>();
        session.setGlobal("list", check);
        
        LOG.info("Now running data");
        
        System.out.println("---a---");
        clock.advanceTime(1000L, TimeUnit.MILLISECONDS);
        session.insert( new Character('a') );
        session.fireAllRules();
        print(session);
        assertTrue(check.contains("Rexpected"));
        assertFalse(check.contains("Ravoid"));
        
        System.out.println("---b---");
        clock.advanceTime(3600000L, TimeUnit.MILLISECONDS);
        session.insert( new Character('b') );
        session.fireAllRules();
        print(session);
        assertTrue(check.contains("Rexpected"));
        assertFalse(check.contains("Ravoid"));
        
        
    }

    private void print(KieSession session) {
        System.out.println("Session facts:");
        for ( FactHandle fh : session.getFactHandles() ) {
            InternalFactHandle ifh = (InternalFactHandle) fh;
            System.out.println(" > "+ifh.getObject()+" ["+ifh.getObjectClassName()+"] FH: "+fh);
        }
    }
}
{code}

And rules:

{code:java}
package org.drools.DROOLS_1347;

global java.util.List list;

declare Character
@role( event )
@expires( 1s )
end

declare String
@role( event )
@expires( 10m )
end

rule "Rexpected"
when
    $t : Character() over window:length(1) 
    not String() 
then
    insert("good");
    list.add("Rexpected");
end

rule "Ravoid"
when
    $t : Character() over window:length(1) 
    exists String(this before $t)
    not String(this coincides $t)
then
    insert("bad");
    list.add("Ravoid");
end
{code}


> Explicit expiration of event not effective - regression from 6.4 to 6.5
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1347
>                 URL: https://issues.jboss.org/browse/DROOLS-1347
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Thibault Daoulas
>            Assignee: Matteo Mortari
>
> I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:08:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 28 Oct 2016 11:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649744000@Atlassian.JIRA>
References: <JIRA.12657738.1477649744000@Atlassian.JIRA>
	<JIRA.12657738.1477649744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649744000.2681.1477667280358@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313518#comment-13313518 ] 

Matteo Mortari commented on DROOLS-1347:
----------------------------------------

Rule definition advice.
In this case, the problem is the rule "Rexpected" is assuming the previous behavior of expiration (as behaving before 6.5.0.Final). In this case, the rule can be defined more correclty and aligned with the current behavior (from 6.5.0.Final) by rewriting it as:

{code:java}
rule "Rexpected"
when
    $t : Character() over window:length(1) 
    not String(this coincides $t) 
then
    insert("good");
    list.add("Rexpected");
end
{code}

with output:

{code}
2016-10-28 17:06:21,275 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Found kmodule: file:/home/mmortari/git/DROOLS-1347/target/classes/META-INF/kmodule.xml
2016-10-28 17:06:21,462 WARN  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Unable to find pom.properties in /home/mmortari/git/DROOLS-1347/target/classes
2016-10-28 17:06:21,472 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Recursed up folders, found and used pom.xml /home/mmortari/git/DROOLS-1347/pom.xml
2016-10-28 17:06:21,478 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule was added: FileKieModule[releaseId=org.drools:DROOLS-1347:0.0.1-SNAPSHOT,file=/home/mmortari/git/DROOLS-1347/target/classes]
2016-10-28 17:06:22,314 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Creating kieBase with STREAM option
2016-10-28 17:06:22,380 INFO  [org.drools.DROOLS_1347.RuleTest] (main) There should be rules: 
2016-10-28 17:06:22,381 INFO  [org.drools.DROOLS_1347.RuleTest] (main) kp [Package name=org.drools.DROOLS_1347] rule Rexpected
2016-10-28 17:06:22,381 INFO  [org.drools.DROOLS_1347.RuleTest] (main) kp [Package name=org.drools.DROOLS_1347] rule Ravoid
2016-10-28 17:06:22,381 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Creating kieSession
2016-10-28 17:06:22,427 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Populating globals
2016-10-28 17:06:22,427 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Now running data
---a---
x a
x good
fired: [Rule name=Rexpected, agendaGroup=MAIN, salience=0, no-loop=false]
Session facts:
 > a [java.lang.Character] FH: 5:1:649329985:97:1:DEFAULT:NON_TRAIT:java.lang.Character
 > good [java.lang.String] FH: 5:2:1146825051:3178685:2:DEFAULT:NON_TRAIT:java.lang.String
---b---
x b
x good
fired: [Rule name=Rexpected, agendaGroup=MAIN, salience=0, no-loop=false]
Session facts:
 > b [java.lang.Character] FH: 5:3:1239807799:98:3:DEFAULT:NON_TRAIT:java.lang.Character
 > good [java.lang.String] FH: 5:4:1146825051:3178685:4:DEFAULT:NON_TRAIT:java.lang.String
{code}

and all assertions passes (/) (y)

> Explicit expiration of event not effective - regression from 6.4 to 6.5
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1347
>                 URL: https://issues.jboss.org/browse/DROOLS-1347
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Thibault Daoulas
>            Assignee: Matteo Mortari
>
> I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:09:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 28 Oct 2016 11:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-696) Elytron Client needs to support
 RealmCallback where realm not set in advance
In-Reply-To: <JIRA.12657580.1477585158000@Atlassian.JIRA>
References: <JIRA.12657580.1477585158000@Atlassian.JIRA>
	<JIRA.12657580.1477585158000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657580.1477585158000.2689.1477667340204@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-696:
---------------------------------
    Issue Type: Enhancement  (was: Bug)


> Elytron Client needs to support RealmCallback where realm not set in advance
> ----------------------------------------------------------------------------
>
>                 Key: ELY-696
>                 URL: https://issues.jboss.org/browse/ELY-696
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:09:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 11:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7408) Look into automating
 generation of README html files from .md
In-Reply-To: <JIRA.12657797.1477667333000@Atlassian.JIRA>
References: <JIRA.12657797.1477667333000@Atlassian.JIRA>
	<JIRA.12657797.1477667333940@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657797.1477667333000.2692.1477667340307@Atlassian.JIRA>

Tomaz Cerar created WFLY-7408:
---------------------------------

             Summary: Look into automating generation of README html files from .md
                 Key: WFLY-7408
                 URL: https://issues.jboss.org/browse/WFLY-7408
             Project: WildFly
          Issue Type: Task
          Components: Quickstarts
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Currently we need to manually run 
dist/release-utils -m
and have setup of ruby and all its gems.

Look into possibly automating this by some maven plugin if possible.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:19:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 28 Oct 2016 11:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649744000@Atlassian.JIRA>
References: <JIRA.12657738.1477649744000@Atlassian.JIRA>
	<JIRA.12657738.1477649744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649744000.2798.1477667940806@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari resolved DROOLS-1347.
------------------------------------
    Resolution: Rejected


I'm resolving this ticket as this is not a bug, and this is not a regression. 

The system is behaving as expected, especially to what concerning the *expiration* behavior. 

I have added some comments for further details in the ticket log. 

Specifically to the rule base originally reported, in my perspective the culprit is the rule "Expiring event init". To have it aligned with the expected expiration behavior, I believe it should be rewritten as: 

{code:java}
rule "Expiring event init"
when
    $t : time_Var($now : Value != null) over window:length(1) from entry-point "time_Ep"
    not ExpiringEvent_Var(this coincides $t) from entry-point "ExpiringEvent_Ep"
then
    ...
{code}

This is however a limited view on the complete rule base, so further alignments may be necessary.

P.s.: I also seize the chance to highlight having to manually manage a Pojo/wrapper for the value of the session's pseudo-clock is not a best practice and should be avoided where possible..

> Explicit expiration of event not effective - regression from 6.4 to 6.5
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1347
>                 URL: https://issues.jboss.org/browse/DROOLS-1347
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Thibault Daoulas
>            Assignee: Matteo Mortari
>
> I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:20:00 2016
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 28 Oct 2016 11:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1347) Explicit expiration of
 event not effective - regression from 6.4 to 6.5
In-Reply-To: <JIRA.12657738.1477649744000@Atlassian.JIRA>
References: <JIRA.12657738.1477649744000@Atlassian.JIRA>
	<JIRA.12657738.1477649744000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657738.1477649744000.2808.1477668000211@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313518#comment-13313518 ] 

Matteo Mortari edited comment on DROOLS-1347 at 10/28/16 11:19 AM:
-------------------------------------------------------------------

Rule definition advice.
In this case, the problem is the rule "Rexpected" is assuming the previous behavior of expiration (as behaving before 6.5.0.Final). In this case, the rule can be defined more correclty and aligned with the current behavior (from 6.5.0.Final) by rewriting it as:

{code:java}
rule "Rexpected"
when
    $t : Character() over window:length(1) 
    not String(this coincides $t) 
then
    insert("good");
    list.add("Rexpected");
end
{code}

with output:

{code}
2016-10-28 17:06:21,275 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Found kmodule: file:/home/mmortari/git/DROOLS-1347/target/classes/META-INF/kmodule.xml
2016-10-28 17:06:21,462 WARN  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Unable to find pom.properties in /home/mmortari/git/DROOLS-1347/target/classes
2016-10-28 17:06:21,472 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Recursed up folders, found and used pom.xml /home/mmortari/git/DROOLS-1347/pom.xml
2016-10-28 17:06:21,478 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule was added: FileKieModule[releaseId=org.drools:DROOLS-1347:0.0.1-SNAPSHOT,file=/home/mmortari/git/DROOLS-1347/target/classes]
2016-10-28 17:06:22,314 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Creating kieBase with STREAM option
2016-10-28 17:06:22,380 INFO  [org.drools.DROOLS_1347.RuleTest] (main) There should be rules: 
2016-10-28 17:06:22,381 INFO  [org.drools.DROOLS_1347.RuleTest] (main) kp [Package name=org.drools.DROOLS_1347] rule Rexpected
2016-10-28 17:06:22,381 INFO  [org.drools.DROOLS_1347.RuleTest] (main) kp [Package name=org.drools.DROOLS_1347] rule Ravoid
2016-10-28 17:06:22,381 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Creating kieSession
2016-10-28 17:06:22,427 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Populating globals
2016-10-28 17:06:22,427 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Now running data
---a---
x a
x good
fired: [Rule name=Rexpected, agendaGroup=MAIN, salience=0, no-loop=false]
Session facts:
 > a [java.lang.Character] FH: 5:1:649329985:97:1:DEFAULT:NON_TRAIT:java.lang.Character
 > good [java.lang.String] FH: 5:2:1146825051:3178685:2:DEFAULT:NON_TRAIT:java.lang.String
---b---
x b
x good
fired: [Rule name=Rexpected, agendaGroup=MAIN, salience=0, no-loop=false]
Session facts:
 > b [java.lang.Character] FH: 5:3:1239807799:98:3:DEFAULT:NON_TRAIT:java.lang.Character
 > good [java.lang.String] FH: 5:4:1146825051:3178685:4:DEFAULT:NON_TRAIT:java.lang.String
{code}

and all assertions passes (/) 


was (Author: tari_manga):
Rule definition advice.
In this case, the problem is the rule "Rexpected" is assuming the previous behavior of expiration (as behaving before 6.5.0.Final). In this case, the rule can be defined more correclty and aligned with the current behavior (from 6.5.0.Final) by rewriting it as:

{code:java}
rule "Rexpected"
when
    $t : Character() over window:length(1) 
    not String(this coincides $t) 
then
    insert("good");
    list.add("Rexpected");
end
{code}

with output:

{code}
2016-10-28 17:06:21,275 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Found kmodule: file:/home/mmortari/git/DROOLS-1347/target/classes/META-INF/kmodule.xml
2016-10-28 17:06:21,462 WARN  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Unable to find pom.properties in /home/mmortari/git/DROOLS-1347/target/classes
2016-10-28 17:06:21,472 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (main) Recursed up folders, found and used pom.xml /home/mmortari/git/DROOLS-1347/pom.xml
2016-10-28 17:06:21,478 INFO  [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (main) KieModule was added: FileKieModule[releaseId=org.drools:DROOLS-1347:0.0.1-SNAPSHOT,file=/home/mmortari/git/DROOLS-1347/target/classes]
2016-10-28 17:06:22,314 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Creating kieBase with STREAM option
2016-10-28 17:06:22,380 INFO  [org.drools.DROOLS_1347.RuleTest] (main) There should be rules: 
2016-10-28 17:06:22,381 INFO  [org.drools.DROOLS_1347.RuleTest] (main) kp [Package name=org.drools.DROOLS_1347] rule Rexpected
2016-10-28 17:06:22,381 INFO  [org.drools.DROOLS_1347.RuleTest] (main) kp [Package name=org.drools.DROOLS_1347] rule Ravoid
2016-10-28 17:06:22,381 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Creating kieSession
2016-10-28 17:06:22,427 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Populating globals
2016-10-28 17:06:22,427 INFO  [org.drools.DROOLS_1347.RuleTest] (main) Now running data
---a---
x a
x good
fired: [Rule name=Rexpected, agendaGroup=MAIN, salience=0, no-loop=false]
Session facts:
 > a [java.lang.Character] FH: 5:1:649329985:97:1:DEFAULT:NON_TRAIT:java.lang.Character
 > good [java.lang.String] FH: 5:2:1146825051:3178685:2:DEFAULT:NON_TRAIT:java.lang.String
---b---
x b
x good
fired: [Rule name=Rexpected, agendaGroup=MAIN, salience=0, no-loop=false]
Session facts:
 > b [java.lang.Character] FH: 5:3:1239807799:98:3:DEFAULT:NON_TRAIT:java.lang.Character
 > good [java.lang.String] FH: 5:4:1146825051:3178685:4:DEFAULT:NON_TRAIT:java.lang.String
{code}

and all assertions passes (/) (y)

> Explicit expiration of event not effective - regression from 6.4 to 6.5
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1347
>                 URL: https://issues.jboss.org/browse/DROOLS-1347
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Thibault Daoulas
>            Assignee: Matteo Mortari
>
> I just ugraded my project from Drools 6.4.0.Final to 6.5.0.Final and have now quite a few tests on rules that fail, all have in common that they test the expiration of events, where an event that should have been removed from the working memory is still present.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:46:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 28 Oct 2016 11:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6966) FatalError on Transaction
 Expired Entry Monitor during server shutdown
In-Reply-To: <JIRA.12643661.1471423266000@Atlassian.JIRA>
References: <JIRA.12643661.1471423266000@Atlassian.JIRA>
	<JIRA.12643661.1471423266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643661.1471423266000.2929.1477669560788@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313558#comment-13313558 ] 

Tom Jenkinson commented on WFLY-6966:
-------------------------------------

I have a fixed merged upstream in Narayana now - will be available with the next release.

> FatalError on Transaction Expired Entry Monitor during server shutdown
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6966
>                 URL: https://issues.jboss.org/browse/WFLY-6966
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Transactions
>    Affects Versions: 10.1.0.CR1
>            Reporter: Ondra Chaloupka
>            Assignee: Tom Jenkinson
>            Priority: Minor
>
> I do experience intermittent errors being shown in server log during server shutdown. It happens time to time for server configured to use {{JTS}} transaction that {{Transaction Expired Entry Monitor}} shows {{FatalError}} during container shutdown.
> I do experience this failure when jdbc object store is used.
> The shutdown log looks
> {code}
> 2016-08-16 07:07:46,900 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment wmq.jmsra.rar (runtime-name: wmq.jmsra.rar) in 132ms
> 2016-08-16 07:07:46,914 INFO  [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 2016-08-16 07:07:46,914 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2016-08-16 07:07:46,915 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 2016-08-16 07:07:46,921 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2016-08-16 07:07:46,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment crashrecovery-jms-stateless-cmt.jar (runtime-name: crashrecovery-jms-stateless-cmt.jar) in 156ms
> 2016-08-16 07:07:46,947 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2016-08-16 07:07:46,952 TRACE [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) InputObjectState::InputObjectState(0:ffff7f000001:55f44a88:57b2ec0b:8, Recovery/FactoryContact)
> 2016-08-16 07:07:46,959 INFO  [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 32) AMQ151003: resource adaptor stopped
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) ORB::shutdown ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) OA::destroyRootPOA ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) RootOA::shutdownObject (Servant)
> 2016-08-16 07:07:46,962 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032018: Destroying TransactionManagerService
> 2016-08-16 07:07:46,963 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032014: Stopping transaction recovery manager
> 2016-08-16 07:07:47,000 FATAL [com.arjuna.ats.jts] (Transaction Expired Entry Monitor) ARJUNA022006: The ORB has not been initialized yet
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) Exception in thread "Transaction Expired Entry Monitor" com.arjuna.ats.arjuna.exceptions.FatalError
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.ORBManager.getORB(ORBManager.java:56)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restore_state(FactoryContactItem.java:264)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restoreMe(FactoryContactItem.java:320)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.recreate(FactoryContactItem.java:100)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner.scan(ExpiredContactScanner.java:99)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) 	at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171)
> 2016-08-16 07:07:47,001 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: Mode <== TERMINATED
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown waiting for scan to end
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan TERMINATED at phase 1
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown scan wait complete
> 2016-08-16 07:07:47,003 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0010: Unbound data source [java:jboss/datasources/jdbc-store]
> 2016-08-16 07:07:47,006 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = module_postgresql-9.4.1207.jar
> 2016-08-16 07:07:47,012 INFO  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 32) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0.SP16-redhat-1 [023d1e88-638c-11e6-927a-a180c25082cf] stopped
> 2016-08-16 07:07:47,012 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2016-08-16 07:07:47,013 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 2016-08-16 07:07:47,018 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 250ms
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 11:56:01 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 28 Oct 2016 11:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-773)
 ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the
 thread pool executor
In-Reply-To: <JIRA.12575453.1434617524000@Atlassian.JIRA>
References: <JIRA.12575453.1434617524000@Atlassian.JIRA>
	<JIRA.12575453.1434617524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12575453.1434617524000.3008.1477670161175@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313564#comment-13313564 ] 

RH Bugzilla Integration commented on WFCORE-773:
------------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1231070|https://bugzilla.redhat.com/show_bug.cgi?id=1231070] from POST to CLOSED

>  ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-773
>                 URL: https://issues.jboss.org/browse/WFCORE-773
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Enrique Gonz?lez Mart?nez
>            Assignee: Petr Jurak
>             Fix For: 3.0.0.Alpha10
>
>
> BoundedQueueThreadPool does not support zero length queue setup.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Fri Oct 28 11:59:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 11:59:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7409) BanTransitiveDependencies for
 Full Feature Pack module on IBM jdk
In-Reply-To: <JIRA.12657807.1477670303000@Atlassian.JIRA>
References: <JIRA.12657807.1477670303000@Atlassian.JIRA>
	<JIRA.12657807.1477670303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657807.1477670303000.3057.1477670340394@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved JBEAP-6706 to WFLY-7409:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7409  (was: JBEAP-6706)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Build System
                           (was: Build System)
            Fix Build:   (was: DR7)
    Affects Version/s:     (was: 7.1.0.DR6)


> BanTransitiveDependencies for Full Feature Pack module on IBM jdk
> -----------------------------------------------------------------
>
>                 Key: WFLY-7409
>                 URL: https://issues.jboss.org/browse/WFLY-7409
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>         Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp10-20160720_02(SR3fp10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160719_312156 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160719_1144_B312156
> JIT  - tr.r14.java_20160629_120284.01
> GC   - R28_Java8_SR3_20160719_1144_B312156_CMPRSS
> J9CL - 20160719_312156)
> JCL - 20160719_01 based on Oracle jdk8u101-b13
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> Building wildfly-feature-pack:7.1.0.Alpha1-redhat-4 fails on IBM jdk.
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4:enforce (ban-transitive-deps) @ wildfly-feature-pack ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with message:
> org.jboss.eap:wildfly-feature-pack:pom:7.1.0.Alpha1-redhat-4
>    org.apache.cxf:cxf-rt-features-clustering:jar:3.1.6.redhat-1:compile has transitive dependencies:
>       xalan:xalan:jar:2.7.1.redhat-11:compile
>          xalan:serializer:jar:2.7.1.redhat-11:compile
> {noformat}
> full log http://pastebin.test.redhat.com/406421
> Same worked with 7.1.0.DR2 bits (7.1.0.Alpha1-redhat-2). The issue is preventing us from running the EAP unit tests on IBM jdk - see https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-test-unit-rhel/37/.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 12:10:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 12:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-369) SecurityIdentity-based
	self-service
In-Reply-To: <JIRA.12592604.1447342963000@Atlassian.JIRA>
References: <JIRA.12592604.1447342963000@Atlassian.JIRA>
	<JIRA.12592604.1447342963000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12592604.1447342963000.3114.1477671000122@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313577#comment-13313577 ] 

David Lloyd commented on ELY-369:
---------------------------------

For this to work, realms (modifiable or non-modifiable) need to return a modifiable authorization identity which includes credential update methods - _or_ alternatively a modifiable realm needs to return an authorization identity which knows how to re-create the (necessarily modifiable) realm identity to perform the credential update.

The latter option is probably better because an AuthorizationIdentity deliberately releases all possible resources; there's no dispose() to call after the change is complete.  Therefore if the AuthorizationIdentity gets back the ModifiableRealmIdentity, that realm identity can be used to perform the update and then be disposed (to release the database or LDAP connection for example).

Re-finding the RealmIdentity is a non-starter because only the realm can make the guarantee that you are either finding the original identity or that you cannot perform the update.  If this guarantee isn't made, there is a risk of updating credentials that the caller does not actually own, which at worst could cause an access breach.

> SecurityIdentity-based self-service
> -----------------------------------
>
>                 Key: ELY-369
>                 URL: https://issues.jboss.org/browse/ELY-369
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI
>            Reporter: David Lloyd
>
> We may need to provide the ability to allow users to manage their accounts in various ways.
> * Password reset



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 12:24:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 12:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-698) Rework the constructor
 exclusion logic for authentication rules and configurations
In-Reply-To: <JIRA.12657810.1477671802000@Atlassian.JIRA>
References: <JIRA.12657810.1477671802000@Atlassian.JIRA>
	<JIRA.12657810.1477671802235@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657810.1477671802000.3201.1477671840298@Atlassian.JIRA>

David Lloyd created ELY-698:
-------------------------------

             Summary: Rework the constructor exclusion logic for authentication rules and configurations
                 Key: ELY-698
                 URL: https://issues.jboss.org/browse/ELY-698
             Project: WildFly Elytron
          Issue Type: Task
          Components: Authentication Client
            Reporter: David Lloyd
            Priority: Minor


The current authentication rule and configuration classes are designed to ensure that mutually incompatible rules and configurations cannot coexist.  However the implementation is applied a bit erratically.  There may be problems with commutatively applying checks.  Some checks may be missing or extraneous.

We need a new approach where the mutual exclusion set is somehow enforced centrally.  One option is to have literal sets, and each class that is a member of one or more sets must remove all other handlers that are also within the set(s).  A predicate could be used to make this efficient by only sweeping the list one time, in contrast to the current mechanism which sweeps the list once per exclusive type.

Another option is to have a marker interface for each capability, and to remove all peers with the same capability.  A predicate can also be used in this case.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 12:25:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Oct 2016 12:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7410)
 CommandDispatcher.submitOnCluster() futures can throw NPEs
In-Reply-To: <JIRA.12657811.1477671855000@Atlassian.JIRA>
References: <JIRA.12657811.1477671855000@Atlassian.JIRA>
	<JIRA.12657811.1477671855242@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657811.1477671855000.3210.1477671900127@Atlassian.JIRA>

Paul Ferraro created WFLY-7410:
----------------------------------

             Summary: CommandDispatcher.submitOnCluster() futures can throw NPEs
                 Key: WFLY-7410
                 URL: https://issues.jboss.org/browse/WFLY-7410
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 12:30:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Oct 2016 12:30:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7410)
 CommandDispatcher.submitOnCluster() futures throw NPEs
In-Reply-To: <JIRA.12657811.1477671855000@Atlassian.JIRA>
References: <JIRA.12657811.1477671855000@Atlassian.JIRA>
	<JIRA.12657811.1477671855000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657811.1477671855000.3226.1477672200325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-7410:
-------------------------------
    Summary: CommandDispatcher.submitOnCluster() futures throw NPEs  (was: CommandDispatcher.submitOnCluster() futures can throw NPEs)


> CommandDispatcher.submitOnCluster() futures throw NPEs
> ------------------------------------------------------
>
>                 Key: WFLY-7410
>                 URL: https://issues.jboss.org/browse/WFLY-7410
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 12:32:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Oct 2016 12:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7410)
 CommandDispatcher.submitOnCluster() futures throw NPEs
In-Reply-To: <JIRA.12657811.1477671855000@Atlassian.JIRA>
References: <JIRA.12657811.1477671855000@Atlassian.JIRA>
	<JIRA.12657811.1477671855000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657811.1477671855000.3232.1477672320465@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-7410:
-------------------------------
    Description: 
Calling Future.get() on a response from CommandDispatcher.submitOnCluster(...) will always throw an NPE.
We also need to handle the case where the response from a node was filtered.


> CommandDispatcher.submitOnCluster() futures throw NPEs
> ------------------------------------------------------
>
>                 Key: WFLY-7410
>                 URL: https://issues.jboss.org/browse/WFLY-7410
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> Calling Future.get() on a response from CommandDispatcher.submitOnCluster(...) will always throw an NPE.
> We also need to handle the case where the response from a node was filtered.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 12:32:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Oct 2016 12:32:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7411)
 CommandDispatcher.submitOnCluster() futures throw NPEs
In-Reply-To: <JIRA.12657812.1477672268000@Atlassian.JIRA>
References: <JIRA.12657812.1477672268000@Atlassian.JIRA>
	<JIRA.12657812.1477672268676@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657812.1477672268000.3234.1477672320522@Atlassian.JIRA>

Paul Ferraro created WFLY-7411:
----------------------------------

             Summary: CommandDispatcher.submitOnCluster() futures throw NPEs
                 Key: WFLY-7411
                 URL: https://issues.jboss.org/browse/WFLY-7411
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 11.0.0.Alpha1


Calling Future.get() on a response from CommandDispatcher.submitOnCluster(...) will always throw an NPE.
We also need to handle the case where the response from a node was filtered.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 12:32:01 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 12:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-698) Rework the constructor
 exclusion logic for authentication rules and configurations
In-Reply-To: <JIRA.12657810.1477671802000@Atlassian.JIRA>
References: <JIRA.12657810.1477671802000@Atlassian.JIRA>
	<JIRA.12657810.1477671802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657810.1477671802000.3251.1477672321086@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313582#comment-13313582 ] 

David Lloyd commented on ELY-698:
---------------------------------

The present requirements for an AuthenticationConfiguration are:

* Ordering is insignificant for non-overlapping configurations.  For example, if A then B are added into a configuration, and A and B do not logically overlap, the result will be identical to adding B then A.
* Equals/hashCode must respect the ordering rule.  In the previous example, both configurations must have the same hash code and be equal to one another.
* In order to meet this rule, two logically overlapping configurations may not coexist on a configuration.  For example, two different configurations that both logically establish a cleartext password will be exclusive, such that whichever one is added last is retained and the other one is dropped.

I suppose these rules really should be on the JavaDoc.

> Rework the constructor exclusion logic for authentication rules and configurations
> ----------------------------------------------------------------------------------
>
>                 Key: ELY-698
>                 URL: https://issues.jboss.org/browse/ELY-698
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Priority: Minor
>
> The current authentication rule and configuration classes are designed to ensure that mutually incompatible rules and configurations cannot coexist.  However the implementation is applied a bit erratically.  There may be problems with commutatively applying checks.  Some checks may be missing or extraneous.
> We need a new approach where the mutual exclusion set is somehow enforced centrally.  One option is to have literal sets, and each class that is a member of one or more sets must remove all other handlers that are also within the set(s).  A predicate could be used to make this efficient by only sweeping the list one time, in contrast to the current mechanism which sweeps the list once per exclusive type.
> Another option is to have a marker interface for each capability, and to remove all peers with the same capability.  A predicate can also be used in this case.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 13:03:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 28 Oct 2016 13:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-119) Where a username and
 credential are supplied accept the default realm
In-Reply-To: <JIRA.12657815.1477674129000@Atlassian.JIRA>
References: <JIRA.12657815.1477674129000@Atlassian.JIRA>
	<JIRA.12657815.1477674129091@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657815.1477674129000.3315.1477674180135@Atlassian.JIRA>

Darran Lofthouse created REMJMX-119:
---------------------------------------

             Summary: Where a username and credential are supplied accept the default realm
                 Key: REMJMX-119
                 URL: https://issues.jboss.org/browse/REMJMX-119
             Project: Remoting JMX
          Issue Type: Enhancement
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha3






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 13:19:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 13:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-699) Client authentication should
 default to using the URI userInfo if present
In-Reply-To: <JIRA.12657821.1477675102000@Atlassian.JIRA>
References: <JIRA.12657821.1477675102000@Atlassian.JIRA>
	<JIRA.12657821.1477675102758@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657821.1477675102000.3349.1477675140243@Atlassian.JIRA>

David Lloyd created ELY-699:
-------------------------------

             Summary: Client authentication should default to using the URI userInfo if present
                 Key: ELY-699
                 URL: https://issues.jboss.org/browse/ELY-699
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Authentication Client
            Reporter: David Lloyd


The client should be using the userInfo from the connection URI in preference to anonymous authentication if that information is present.  The challenge is that the API does not presently require a URI to be given when getting the authentication principal.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 13:23:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 13:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-699) Client authentication should
 default to using the URI userInfo if present
In-Reply-To: <JIRA.12657821.1477675103000@Atlassian.JIRA>
References: <JIRA.12657821.1477675103000@Atlassian.JIRA>
	<JIRA.12657821.1477675103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657821.1477675103000.3370.1477675380085@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313601#comment-13313601 ] 

David Lloyd commented on ELY-699:
---------------------------------

Rather than changing the API to require a URI to be given to org.wildfly.security.auth.client.AuthenticationConfiguration#getPrincipal, which would be fairly complex, a better approach might be to modify org.wildfly.security.auth.client.AuthenticationContextConfigurationClient#getAuthenticationConfiguration() to automatically add information from the URI in to the configuration before returning it, like this:
* If auth is anonymous, check for userInfo; if present, add it as a setName
* If no SetHost*Configuration is set, add the URI host (if any) as setHost
* Same for port #

Then we can add methods on AuthenticationContextConfigurationClient which do not require a URI to be given, and deprecate those old ones.

> Client authentication should default to using the URI userInfo if present
> -------------------------------------------------------------------------
>
>                 Key: ELY-699
>                 URL: https://issues.jboss.org/browse/ELY-699
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: David Lloyd
>
> The client should be using the userInfo from the connection URI in preference to anonymous authentication if that information is present.  The challenge is that the API does not presently require a URI to be given when getting the authentication principal.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 13:26:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 28 Oct 2016 13:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-120) Enable All Security Tests
 Backed By Elytron
In-Reply-To: <JIRA.12657823.1477675514000@Atlassian.JIRA>
References: <JIRA.12657823.1477675514000@Atlassian.JIRA>
	<JIRA.12657823.1477675514906@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657823.1477675514000.3376.1477675560355@Atlassian.JIRA>

Darran Lofthouse created REMJMX-120:
---------------------------------------

             Summary: Enable All Security Tests Backed By Elytron
                 Key: REMJMX-120
                 URL: https://issues.jboss.org/browse/REMJMX-120
             Project: Remoting JMX
          Issue Type: Enhancement
          Components: Security, Tests
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha3


By enabling the tests I mean get them all working ;-)

We most likely need a wildfly-client-config.xml for default settings, also tests should be updated to cover both direct JMXConnector use and cases where AuthenticationConfiguration can be set before.

Some clients such as jconsole will not be calling AuthenticationConfiguration first.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 13:26:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 28 Oct 2016 13:26:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-120) Enable All Security Tests
 Backed By Elytron
In-Reply-To: <JIRA.12657823.1477675515000@Atlassian.JIRA>
References: <JIRA.12657823.1477675515000@Atlassian.JIRA>
	<JIRA.12657823.1477675515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657823.1477675515000.3379.1477675560499@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-120:
------------------------------------
    Priority: Blocker  (was: Major)


> Enable All Security Tests Backed By Elytron
> -------------------------------------------
>
>                 Key: REMJMX-120
>                 URL: https://issues.jboss.org/browse/REMJMX-120
>             Project: Remoting JMX
>          Issue Type: Enhancement
>          Components: Security, Tests
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha3
>
>
> By enabling the tests I mean get them all working ;-)
> We most likely need a wildfly-client-config.xml for default settings, also tests should be updated to cover both direct JMXConnector use and cases where AuthenticationConfiguration can be set before.
> Some clients such as jconsole will not be calling AuthenticationConfiguration first.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 13:51:00 2016
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 28 Oct 2016 13:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-961) A security-domain can only
 load login-modules from a single JBoss module
In-Reply-To: <JIRA.12657825.1477677031000@Atlassian.JIRA>
References: <JIRA.12657825.1477677031000@Atlassian.JIRA>
	<JIRA.12657825.1477677031838@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657825.1477677031000.3420.1477677060203@Atlassian.JIRA>

Stefan Guilhen created SECURITY-961:
---------------------------------------

             Summary:  A security-domain can only load login-modules from a single JBoss module 
                 Key: SECURITY-961
                 URL: https://issues.jboss.org/browse/SECURITY-961
             Project: PicketBox 
          Issue Type: Bug
          Components: JBossSX, Security-SPI
            Reporter: Derek Horton
            Assignee: Stefan Guilhen



A security-domain can only load login-modules from a single JBoss module.  Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.  

For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:

  <security-domain name="jmx-console" cache-type="default">
      <authentication>
          <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
              <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
              <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
          </login-module>
          <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
              <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
              <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
          </login-module>

      </authentication>
  </security-domain>

Unfortunately, it does not work like this.  Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.

There seems to be two issues.  1)  The security subsystem code only "remembers" the last module that is defined within a single security domain.  2)  I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code.  The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 13:52:00 2016
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 28 Oct 2016 13:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7412) A security-domain can only
 load login-modules from a single JBoss module
In-Reply-To: <JIRA.12657825.1477677032000@Atlassian.JIRA>
References: <JIRA.12657825.1477677032000@Atlassian.JIRA>
	<JIRA.12657825.1477677032000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657825.1477677032000.3427.1477677120394@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen moved SECURITY-961 to WFLY-7412:
-----------------------------------------------

        Project: WildFly  (was: PicketBox )
            Key: WFLY-7412  (was: SECURITY-961)
       Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Component/s: Security
                     (was: JBossSX, Security-SPI)


>  A security-domain can only load login-modules from a single JBoss module 
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7412
>                 URL: https://issues.jboss.org/browse/WFLY-7412
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>
> A security-domain can only load login-modules from a single JBoss module.  Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.  
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
>   <security-domain name="jmx-console" cache-type="default">
>       <authentication>
>           <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>           <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>       </authentication>
>   </security-domain>
> Unfortunately, it does not work like this.  Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
> There seems to be two issues.  1)  The security subsystem code only "remembers" the last module that is defined within a single security domain.  2)  I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code.  The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 13:52:00 2016
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 28 Oct 2016 13:52:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7412) A security-domain can only
 load login-modules from a single JBoss module
In-Reply-To: <JIRA.12657825.1477677032000@Atlassian.JIRA>
References: <JIRA.12657825.1477677032000@Atlassian.JIRA>
	<JIRA.12657825.1477677032000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657825.1477677032000.3434.1477677120656@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen updated WFLY-7412:
---------------------------------
    Description: 
A security-domain can only load login-modules from a single JBoss module.  Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.  

For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:

  <security-domain name="jmx-console" cache-type="default">
      <authentication>
          <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
              <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
              <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
          </login-module>
          <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
              <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
              <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
          </login-module>

      </authentication>
  </security-domain>

Unfortunately, it does not work like this.  Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.

  was:

A security-domain can only load login-modules from a single JBoss module.  Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.  

For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:

  <security-domain name="jmx-console" cache-type="default">
      <authentication>
          <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
              <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
              <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
          </login-module>
          <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
              <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
              <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
          </login-module>

      </authentication>
  </security-domain>

Unfortunately, it does not work like this.  Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.

There seems to be two issues.  1)  The security subsystem code only "remembers" the last module that is defined within a single security domain.  2)  I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code.  The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.



>  A security-domain can only load login-modules from a single JBoss module 
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7412
>                 URL: https://issues.jboss.org/browse/WFLY-7412
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>
> A security-domain can only load login-modules from a single JBoss module.  Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.  
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
>   <security-domain name="jmx-console" cache-type="default">
>       <authentication>
>           <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>           <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>       </authentication>
>   </security-domain>
> Unfortunately, it does not work like this.  Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 13:55:00 2016
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 28 Oct 2016 13:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-930) A security-domain can only
 load login-modules from a single JBoss module
In-Reply-To: <JIRA.12597491.1450716628000@Atlassian.JIRA>
References: <JIRA.12597491.1450716628000@Atlassian.JIRA>
	<JIRA.12597491.1450716628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597491.1450716628000.3439.1477677300282@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen resolved SECURITY-930.
-------------------------------------
    Fix Version/s: PicketBox_5_0_0.Beta1
       Resolution: Done


The PicketBox side has been fixed. WildFly has been updated to use the latest PicketBox release that includes the fix and we need to change the WildFly side to use the new API that allows for the specification of multiple modules.

I've cloned this into WFLY-7412 to track the WildFly side of the issue.

>  A security-domain can only load login-modules from a single JBoss module 
> --------------------------------------------------------------------------
>
>                 Key: SECURITY-930
>                 URL: https://issues.jboss.org/browse/SECURITY-930
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_5_0_0.Beta1
>
>
> A security-domain can only load login-modules from a single JBoss module.  Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.  
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
>   <security-domain name="jmx-console" cache-type="default">
>       <authentication>
>           <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>           <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
>               <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
>               <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
>           </login-module>
>       </authentication>
>   </security-domain>
> Unfortunately, it does not work like this.  Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
> There seems to be two issues.  1)  The security subsystem code only "remembers" the last module that is defined within a single security domain.  2)  I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code.  The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 16:29:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 16:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-698) Rework the constructor
 exclusion logic for authentication rules and configurations
In-Reply-To: <JIRA.12657810.1477671802000@Atlassian.JIRA>
References: <JIRA.12657810.1477671802000@Atlassian.JIRA>
	<JIRA.12657810.1477671802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657810.1477671802000.3743.1477686540178@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned ELY-698:
-------------------------------

    Assignee: David Lloyd


> Rework the constructor exclusion logic for authentication rules and configurations
> ----------------------------------------------------------------------------------
>
>                 Key: ELY-698
>                 URL: https://issues.jboss.org/browse/ELY-698
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Minor
>
> The current authentication rule and configuration classes are designed to ensure that mutually incompatible rules and configurations cannot coexist.  However the implementation is applied a bit erratically.  There may be problems with commutatively applying checks.  Some checks may be missing or extraneous.
> We need a new approach where the mutual exclusion set is somehow enforced centrally.  One option is to have literal sets, and each class that is a member of one or more sets must remove all other handlers that are also within the set(s).  A predicate could be used to make this efficient by only sweeping the list one time, in contrast to the current mechanism which sweeps the list once per exclusive type.
> Another option is to have a marker interface for each capability, and to remove all peers with the same capability.  A predicate can also be used in this case.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 16:29:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 16:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-699) Client authentication should
 default to using the URI userInfo if present
In-Reply-To: <JIRA.12657821.1477675103000@Atlassian.JIRA>
References: <JIRA.12657821.1477675103000@Atlassian.JIRA>
	<JIRA.12657821.1477675103000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657821.1477675103000.3746.1477686540234@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned ELY-699:
-------------------------------

    Assignee: David Lloyd


> Client authentication should default to using the URI userInfo if present
> -------------------------------------------------------------------------
>
>                 Key: ELY-699
>                 URL: https://issues.jboss.org/browse/ELY-699
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>
> The client should be using the userInfo from the connection URI in preference to anonymous authentication if that information is present.  The challenge is that the API does not presently require a URI to be given when getting the authentication principal.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 16:40:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Oct 2016 16:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7413) Singleton policy quorum
 attribute is missing a validator
In-Reply-To: <JIRA.12657833.1477687190000@Atlassian.JIRA>
References: <JIRA.12657833.1477687190000@Atlassian.JIRA>
	<JIRA.12657833.1477687190166@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657833.1477687190000.3755.1477687200139@Atlassian.JIRA>

Paul Ferraro created WFLY-7413:
----------------------------------

             Summary: Singleton policy quorum attribute is missing a validator
                 Key: WFLY-7413
                 URL: https://issues.jboss.org/browse/WFLY-7413
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 16:40:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Oct 2016 16:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7414) Singleton policy quorum
 attribute is missing a validator
In-Reply-To: <JIRA.12657834.1477687198000@Atlassian.JIRA>
References: <JIRA.12657834.1477687198000@Atlassian.JIRA>
	<JIRA.12657834.1477687198205@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657834.1477687198000.3759.1477687200277@Atlassian.JIRA>

Paul Ferraro created WFLY-7414:
----------------------------------

             Summary: Singleton policy quorum attribute is missing a validator
                 Key: WFLY-7414
                 URL: https://issues.jboss.org/browse/WFLY-7414
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 16:41:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 16:41:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-700) Fix AuthenticationClient
	comparison behavior
In-Reply-To: <JIRA.12657835.1477687229000@Atlassian.JIRA>
References: <JIRA.12657835.1477687229000@Atlassian.JIRA>
	<JIRA.12657835.1477687229270@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657835.1477687229000.3776.1477687260665@Atlassian.JIRA>

David Lloyd created ELY-700:
-------------------------------

             Summary: Fix AuthenticationClient comparison behavior
                 Key: ELY-700
                 URL: https://issues.jboss.org/browse/ELY-700
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Authentication Client
            Reporter: David Lloyd
            Assignee: David Lloyd


The authentication client's comparison behavior is more or less banjaxed.  It needs to be fixed, starting probably with killing off multi-valued configuration items.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 16:43:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 28 Oct 2016 16:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-700) Fix AuthenticationClient
	comparison behavior
In-Reply-To: <JIRA.12657835.1477687229000@Atlassian.JIRA>
References: <JIRA.12657835.1477687229000@Atlassian.JIRA>
	<JIRA.12657835.1477687229000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657835.1477687229000.3780.1477687380075@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313659#comment-13313659 ] 

David Lloyd commented on ELY-700:
---------------------------------

Other helpful things: equal/hashCode-stable suppliers/functions/etc.

> Fix AuthenticationClient comparison behavior
> --------------------------------------------
>
>                 Key: ELY-700
>                 URL: https://issues.jboss.org/browse/ELY-700
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>
> The authentication client's comparison behavior is more or less banjaxed.  It needs to be fixed, starting probably with killing off multi-valued configuration items.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 16:45:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 28 Oct 2016 16:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7415) Add backup service support
 for singleton services
In-Reply-To: <JIRA.12657836.1477687471000@Atlassian.JIRA>
References: <JIRA.12657836.1477687471000@Atlassian.JIRA>
	<JIRA.12657836.1477687471060@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657836.1477687471000.3784.1477687500364@Atlassian.JIRA>

Paul Ferraro created WFLY-7415:
----------------------------------

             Summary: Add backup service support for singleton services
                 Key: WFLY-7415
                 URL: https://issues.jboss.org/browse/WFLY-7415
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 10.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 11.0.0.Alpha1


Currently, singleton services are started on the primary node only - no service is started on the backup nodes.  We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes.  When a node is elected as the primary provider, we stop the backup service, and start the primary service.  Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 17:48:00 2016
From: issues at jboss.org (Dennis Reed (JIRA))
Date: Fri, 28 Oct 2016 17:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6882) A client is not able to
 invoke EJB's deployed as "HASingleton deployment"
In-Reply-To: <JIRA.12640877.1469626112000@Atlassian.JIRA>
References: <JIRA.12640877.1469626112000@Atlassian.JIRA>
	<JIRA.12640877.1469626112000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640877.1469626112000.3999.1477691280223@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313677#comment-13313677 ] 

Dennis Reed commented on WFLY-6882:
-----------------------------------

In EAP 5 and earlier, this was mostly handled by HA-JNDI.  When looking up a singleton in HA-JNDI, you got a non-clustered proxy to whatever node it was deployed on.  If it went down, you looked it up again in HA-JNDI and got a proxy to the new singleton.

Does this still work (new lookup of the EJB)?

> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
>                 Key: WFLY-6882
>                 URL: https://issues.jboss.org/browse/WFLY-6882
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Enrique Gonz?lez Mart?nez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Fri Oct 28 17:56:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 17:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7416) Minimize usage of deprecated
 PropertiesAttributeDefintion#setXmlName()
In-Reply-To: <JIRA.12657839.1477691701000@Atlassian.JIRA>
References: <JIRA.12657839.1477691701000@Atlassian.JIRA>
	<JIRA.12657839.1477691701465@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657839.1477691701000.4002.1477691760365@Atlassian.JIRA>

Tomaz Cerar created WFLY-7416:
---------------------------------

             Summary: Minimize usage of deprecated PropertiesAttributeDefintion#setXmlName()
                 Key: WFLY-7416
                 URL: https://issues.jboss.org/browse/WFLY-7416
             Project: WildFly
          Issue Type: Task
          Components: Domain Management
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


There are some leftovers in different subsystems that still use setXmlName() to control the properties single element name instead of name of the attribute itself.
For such scenarios custom instance of PropertiesAttributeParser/Marshaller should be created instead



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 17:56:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 28 Oct 2016 17:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7417) Minimize usage of deprecated
 PropertiesAttributeDefintion#setXmlName()
In-Reply-To: <JIRA.12657840.1477691729000@Atlassian.JIRA>
References: <JIRA.12657840.1477691729000@Atlassian.JIRA>
	<JIRA.12657840.1477691729173@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657840.1477691729000.4005.1477691760498@Atlassian.JIRA>

Tomaz Cerar created WFLY-7417:
---------------------------------

             Summary: Minimize usage of deprecated PropertiesAttributeDefintion#setXmlName()
                 Key: WFLY-7417
                 URL: https://issues.jboss.org/browse/WFLY-7417
             Project: WildFly
          Issue Type: Task
          Components: Domain Management
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


There are some leftovers in different subsystems that still use setXmlName() to control the properties single element name instead of name of the attribute itself.
For such scenarios custom instance of PropertiesAttributeParser/Marshaller should be created instead



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 18:55:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 28 Oct 2016 18:55:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7418) Batch deployments with a
 large number of executed jobs can lock up or slow down the web console
In-Reply-To: <JIRA.12657844.1477695274000@Atlassian.JIRA>
References: <JIRA.12657844.1477695274000@Atlassian.JIRA>
	<JIRA.12657844.1477695274924@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657844.1477695274000.4097.1477695300068@Atlassian.JIRA>

James Perkins created WFLY-7418:
-----------------------------------

             Summary: Batch deployments with a large number of executed jobs can lock up or slow down the web console
                 Key: WFLY-7418
                 URL: https://issues.jboss.org/browse/WFLY-7418
             Project: WildFly
          Issue Type: Enhancement
          Components: Batch, Web Console
            Reporter: James Perkins
            Assignee: James Perkins


Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.

One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.

JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Fri Oct 28 18:58:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 28 Oct 2016 18:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7418) Batch deployments with a
 large number of executed jobs can lock up or slow down the web console
In-Reply-To: <JIRA.12657844.1477695275000@Atlassian.JIRA>
References: <JIRA.12657844.1477695275000@Atlassian.JIRA>
	<JIRA.12657844.1477695275000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657844.1477695275000.4099.1477695480076@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313683#comment-13313683 ] 

James Perkins commented on WFLY-7418:
-------------------------------------

[~harald.pehl] [~claudio4j] just wanted to ping both of you on this issue as it does affect the console so maybe you guys have some ideas too. Really returning large data sets like this is a problem that the console likely can't do much about, but any ideas you might have would be appreciated.

> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7418
>                 URL: https://issues.jboss.org/browse/WFLY-7418
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Batch, Web Console
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 04:43:00 2016
From: issues at jboss.org (Kai Jemella (JIRA))
Date: Sat, 29 Oct 2016 04:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1350) 401 Unauthorized kie-server
 rest api peflight call error -> change web.xml security constraints
In-Reply-To: <JIRA.12657849.1477730543000@Atlassian.JIRA>
References: <JIRA.12657849.1477730543000@Atlassian.JIRA>
	<JIRA.12657849.1477730543530@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657849.1477730543000.4171.1477730580208@Atlassian.JIRA>

Kai Jemella created DROOLS-1350:
-----------------------------------

             Summary: 401 Unauthorized kie-server rest api peflight call error -> change web.xml security constraints
                 Key: DROOLS-1350
                 URL: https://issues.jboss.org/browse/DROOLS-1350
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 7.0.0.Beta2
            Reporter: Kai Jemella
            Assignee: Edson Tirelli
         Attachments: kie-server_cors_preflight_401.png


Using the kie-server REST API with a javascript framework like angular2 results in a [CORS Preflight W3C|https://www.w3.org/TR/cors/#resource-preflight-requests] response 401 :

{code}
zone.js:1274 OPTIONS http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances 

XMLHttpRequest cannot load http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances. Response for preflight has invalid HTTP status code 401
{code}

CORS Response Header are set, this is not the problem:
{code:xml}
# filter references
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Origin:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Methods:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Headers:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Credentials:add

# filter
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Origin:add(header-name=Access-Control-Allow-Origin,header-value="*")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Methods:add(header-name=Access-Control-Allow-Methods,header-value="GET, PUT, POST, OPTIONS, DELETE")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Headers:add \
(header-name=Access-Control-Allow-Headers,header-value="accept, authorization, content-type, x-requested-with, X-KIE-ContentType")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Credentials:add(header-name=Access-Control-Allow-Credentials,header-value="true")

{code}

The problem occurs by the kie-server web descriptor security constraint:

{code:title=web.xml}
...
<security-constraint>
    <web-resource-collection>
      <web-resource-name>REST web resources</web-resource-name>
      <url-pattern>/services/rest/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>kie-server</role-name>
    </auth-constraint>
</security-constraint>
...
{code}

The security constraint should be active for all jax-rs HTTP methods, EXPECT the OPTIONS mehtod:
{code:title=web.xml}
...
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>REST web resources</web-resource-name>
      <url-pattern>/services/rest/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>PUT</http-method>
      <http-method>POST</http-method>
      <http-method>DELETE</http-method>
    </web-resource-collection>
    <auth-constraint>
      <role-name>kie-server</role-name>
    </auth-constraint>
  </security-constraint>
...
{code}

Tested with firefox and chrome.




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 04:45:00 2016
From: issues at jboss.org (Kai Jemella (JIRA))
Date: Sat, 29 Oct 2016 04:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1350) 401 Unauthorized kie-server
 rest api peflight call error -> change web.xml security constraints
In-Reply-To: <JIRA.12657849.1477730544000@Atlassian.JIRA>
References: <JIRA.12657849.1477730544000@Atlassian.JIRA>
	<JIRA.12657849.1477730544000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657849.1477730544000.4174.1477730700122@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kai Jemella updated DROOLS-1350:
--------------------------------
    Description: 
Using the kie-server REST API with a javascript framework like angular2 results in a [CORS Preflight W3C|https://www.w3.org/TR/cors/#resource-preflight-requests] response 401 :

{code}
zone.js:1274 OPTIONS http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances 

XMLHttpRequest cannot load http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances. Response for preflight has invalid HTTP status code 401
{code}

CORS Response Header are set, this is not the problem:
{code:xml}
# filter references
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Origin:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Methods:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Headers:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Credentials:add

# filter
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Origin:add(header-name=Access-Control-Allow-Origin,header-value="*")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Methods:add(header-name=Access-Control-Allow-Methods,header-value="GET, PUT, POST, OPTIONS, DELETE")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Headers:add \
(header-name=Access-Control-Allow-Headers,header-value="accept, authorization, content-type, x-requested-with, X-KIE-ContentType")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Credentials:add(header-name=Access-Control-Allow-Credentials,header-value="true")

{code}

The problem occurs by the kie-server web descriptor security constraint:

{code:title=web.xml}
...
<security-constraint>
    <web-resource-collection>
      <web-resource-name>REST web resources</web-resource-name>
      <url-pattern>/services/rest/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>kie-server</role-name>
    </auth-constraint>
</security-constraint>
...
{code}

The security constraint should be active for all jax-rs HTTP methods, without the OPTIONS method:
{code:title=web.xml}
...
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>REST web resources</web-resource-name>
      <url-pattern>/services/rest/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>PUT</http-method>
      <http-method>POST</http-method>
      <http-method>DELETE</http-method>
    </web-resource-collection>
    <auth-constraint>
      <role-name>kie-server</role-name>
    </auth-constraint>
  </security-constraint>
...
{code}

Tested with firefox and chrome.


  was:

Using the kie-server REST API with a javascript framework like angular2 results in a [CORS Preflight W3C|https://www.w3.org/TR/cors/#resource-preflight-requests] response 401 :

{code}
zone.js:1274 OPTIONS http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances 

XMLHttpRequest cannot load http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances. Response for preflight has invalid HTTP status code 401
{code}

CORS Response Header are set, this is not the problem:
{code:xml}
# filter references
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Origin:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Methods:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Headers:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Credentials:add

# filter
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Origin:add(header-name=Access-Control-Allow-Origin,header-value="*")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Methods:add(header-name=Access-Control-Allow-Methods,header-value="GET, PUT, POST, OPTIONS, DELETE")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Headers:add \
(header-name=Access-Control-Allow-Headers,header-value="accept, authorization, content-type, x-requested-with, X-KIE-ContentType")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Credentials:add(header-name=Access-Control-Allow-Credentials,header-value="true")

{code}

The problem occurs by the kie-server web descriptor security constraint:

{code:title=web.xml}
...
<security-constraint>
    <web-resource-collection>
      <web-resource-name>REST web resources</web-resource-name>
      <url-pattern>/services/rest/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>kie-server</role-name>
    </auth-constraint>
</security-constraint>
...
{code}

The security constraint should be active for all jax-rs HTTP methods, EXPECT the OPTIONS mehtod:
{code:title=web.xml}
...
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>REST web resources</web-resource-name>
      <url-pattern>/services/rest/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>PUT</http-method>
      <http-method>POST</http-method>
      <http-method>DELETE</http-method>
    </web-resource-collection>
    <auth-constraint>
      <role-name>kie-server</role-name>
    </auth-constraint>
  </security-constraint>
...
{code}

Tested with firefox and chrome.




> 401 Unauthorized kie-server rest api peflight call error -> change web.xml security constraints
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1350
>                 URL: https://issues.jboss.org/browse/DROOLS-1350
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Kai Jemella
>            Assignee: Edson Tirelli
>         Attachments: kie-server_cors_preflight_401.png
>
>
> Using the kie-server REST API with a javascript framework like angular2 results in a [CORS Preflight W3C|https://www.w3.org/TR/cors/#resource-preflight-requests] response 401 :
> {code}
> zone.js:1274 OPTIONS http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances 
> XMLHttpRequest cannot load http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances. Response for preflight has invalid HTTP status code 401
> {code}
> CORS Response Header are set, this is not the problem:
> {code:xml}
> # filter references
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Origin:add
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Methods:add
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Headers:add
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Credentials:add
> # filter
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Origin:add(header-name=Access-Control-Allow-Origin,header-value="*")
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Methods:add(header-name=Access-Control-Allow-Methods,header-value="GET, PUT, POST, OPTIONS, DELETE")
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Headers:add \
> (header-name=Access-Control-Allow-Headers,header-value="accept, authorization, content-type, x-requested-with, X-KIE-ContentType")
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Credentials:add(header-name=Access-Control-Allow-Credentials,header-value="true")
> {code}
> The problem occurs by the kie-server web descriptor security constraint:
> {code:title=web.xml}
> ...
> <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>REST web resources</web-resource-name>
>       <url-pattern>/services/rest/*</url-pattern>
>     </web-resource-collection>
>     <auth-constraint>
>       <role-name>kie-server</role-name>
>     </auth-constraint>
> </security-constraint>
> ...
> {code}
> The security constraint should be active for all jax-rs HTTP methods, without the OPTIONS method:
> {code:title=web.xml}
> ...
>   <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>REST web resources</web-resource-name>
>       <url-pattern>/services/rest/*</url-pattern>
>       <http-method>GET</http-method>
>       <http-method>PUT</http-method>
>       <http-method>POST</http-method>
>       <http-method>DELETE</http-method>
>     </web-resource-collection>
>     <auth-constraint>
>       <role-name>kie-server</role-name>
>     </auth-constraint>
>   </security-constraint>
> ...
> {code}
> Tested with firefox and chrome.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 08:47:00 2016
From: issues at jboss.org (Fabian Meyer (JIRA))
Date: Sat, 29 Oct 2016 08:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-844) Crash when node is deleted
 from query node
In-Reply-To: <JIRA.12577655.1436522424000@Atlassian.JIRA>
References: <JIRA.12577655.1436522424000@Atlassian.JIRA>
	<JIRA.12577655.1436522424000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577655.1436522424000.4205.1477745220096@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313691#comment-13313691 ] 

Fabian Meyer commented on DROOLS-844:
-------------------------------------

The problem seems to be fixed in the current snapshot (no NPEs after a few test runs). 
7.0.0.Beta2 still crashes with a NPE in "org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:728)"

> Crash when node is deleted from query node
> ------------------------------------------
>
>                 Key: DROOLS-844
>                 URL: https://issues.jboss.org/browse/DROOLS-844
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final, 7.0.0.Beta1
>            Reporter: Fabian Meyer
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.4.0.Beta1
>
>
> When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException.
> Exception in thread "Thread-6" java.lang.NullPointerException
> 	at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176)
> 	at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973)
> 	at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331)



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:02 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476025000@Atlassian.JIRA>
References: <JIRA.12657047.1477476025000@Atlassian.JIRA>
	<JIRA.12657047.1477476025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476025000.4276.1477763342966@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1897:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Follow up WFCORE-296 once migrated to Remoting 5
> ------------------------------------------------
>
>                 Key: WFCORE-1897
>                 URL: https://issues.jboss.org/browse/WFCORE-1897
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha12
>
>
> WFCORE-296 adds support for the schemes remote:// remote_http:// and remote+https:// - once we switch to centralised Endpoints we need to ensure this new set is still supported along with the previous set.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1891) Split WildFly Elytron into
 two modules with a public / private split.
In-Reply-To: <JIRA.12656506.1477391493000@Atlassian.JIRA>
References: <JIRA.12656506.1477391493000@Atlassian.JIRA>
	<JIRA.12656506.1477391493000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656506.1477391493000.4284.1477763343310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1891:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Split WildFly Elytron into two modules with a public / private split.
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-1891
>                 URL: https://issues.jboss.org/browse/WFCORE-1891
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Alpha12
>
>
> The Elytron jar will be contained within a private module, possibly 'elytron-private' then a module 'elytron' will depend on this and make the public packages visible.
> The following packages have been identified as being private: -
> org.wildfly.security._private
> org.wildfly.security.asn1
> org.wildfly.security.auth.realm
> org.wildfly.security.auth.realm.*
> org.wildfly.security.authz.jacc
> org.wildfly.security.credential.store.impl
> org.wildfly.security.security.digest
> org.wildfly.security.http.impl
> org.wildfly.security.security.keystore
> org.wildfly.security.mechanism.oauth2
> org.wildfly.security.mechanism.scram
> org.wildfly.security.password.impl
> org.wildfly.security.password.util
> org.wildfly.security.pem
> org.wildfly.security.sasl
> org.wildfly.security.sasl.* (Except util)
> org.wildfly.security.util
> org.wildfly.security.util_private
> org.wildfly.security.x500
> org.wildfly.security.x500.cert



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1884) Introduce discovery
	subsystem
In-Reply-To: <JIRA.12655787.1476904150000@Atlassian.JIRA>
References: <JIRA.12655787.1476904150000@Atlassian.JIRA>
	<JIRA.12655787.1476904150000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655787.1476904150000.4287.1477763343365@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1884:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Introduce discovery subsystem
> -----------------------------
>
>                 Key: WFCORE-1884
>                 URL: https://issues.jboss.org/browse/WFCORE-1884
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 3.0.0.Alpha12
>
>
> Introduce discovery subsystem to be used by any other subsystem which can utilize discovery.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1822) Address thread safety of
 CredentialReference
In-Reply-To: <JIRA.12651861.1474815467000@Atlassian.JIRA>
References: <JIRA.12651861.1474815467000@Atlassian.JIRA>
	<JIRA.12651861.1474815467000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651861.1474815467000.4295.1477763343539@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1822:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Address thread safety of CredentialReference
> --------------------------------------------
>
>                 Key: WFCORE-1822
>                 URL: https://issues.jboss.org/browse/WFCORE-1822
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Peter Skopek
>             Fix For: 3.0.0.Alpha12
>
>
> Following on from the comments in this pull requests some minor follow up is required regarding thread safety of CredentialReference: -
> https://github.com/wildfly/wildfly-core/pull/1816



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1701) In-VM Identity
	Representation
In-Reply-To: <JIRA.12642592.1470745276000@Atlassian.JIRA>
References: <JIRA.12642592.1470745276000@Atlassian.JIRA>
	<JIRA.12642592.1470745276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642592.1470745276000.4308.1477763343876@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1701:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> In-VM Identity Representation
> -----------------------------
>
>                 Key: WFCORE-1701
>                 URL: https://issues.jboss.org/browse/WFCORE-1701
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>
> If Elytron has no current SecurityIdentity then an anonymous identity is used.  The issue however is that this anonymous identity could be because the current user does not have access to be inflowed to the SecurityDomain being used for management or it could be because it is an in-vm call and no identity is established.
> We need a solution to safely represent an in-vm call and differentiate it from a user with no appropriate identity,



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1693) Upgrade to JBoss Remoting
	5.0.0.Beta4
In-Reply-To: <JIRA.12641805.1470240600000@Atlassian.JIRA>
References: <JIRA.12641805.1470240600000@Atlassian.JIRA>
	<JIRA.12641805.1470240600000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641805.1470240600000.4315.1477763344068@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1693:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Upgrade to JBoss Remoting 5.0.0.Beta4
> -------------------------------------
>
>                 Key: WFCORE-1693
>                 URL: https://issues.jboss.org/browse/WFCORE-1693
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1602) Elytron integration with JMX
In-Reply-To: <JIRA.12633500.1466178398000@Atlassian.JIRA>
References: <JIRA.12633500.1466178398000@Atlassian.JIRA>
	<JIRA.12633500.1466178398000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633500.1466178398000.4321.1477763344270@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1602:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Elytron integration with JMX
> ----------------------------
>
>                 Key: WFCORE-1602
>                 URL: https://issues.jboss.org/browse/WFCORE-1602
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: JMX
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1600) Update the legacy security
 realms to add factory methods to obtain SaslAuthenticationFactory and
 HttpAuthenticationFactory instances.
In-Reply-To: <JIRA.12633492.1466175366000@Atlassian.JIRA>
References: <JIRA.12633492.1466175366000@Atlassian.JIRA>
	<JIRA.12633492.1466175366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633492.1466175366000.4328.1477763344474@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1600:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances.
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1600
>                 URL: https://issues.jboss.org/browse/WFCORE-1600
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>
> These are for use when security realms are directly referenced, although Elytron types these should not be advertised as capabilities as these are for specific backwards compatibility requirements and not to increase their use as Elytron capabilities.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.4301.1477763343673@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1802:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Integrate OpenSSL Provider registration with Elytron
> ----------------------------------------------------
>
>                 Key: WFCORE-1802
>                 URL: https://issues.jboss.org/browse/WFCORE-1802
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Stuart Douglas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha12
>
>
> We need to remove the following block from SecurityRealmResourceDefinition: -
> {code}
>     static {
>         //register the Openssl Provider, if possible
>         //not really sure if this is the best place for it
>         try {
>             OpenSSLProvider.register();
>             DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider();
>         } catch (Throwable t){
>             DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider");
>         }
>     }
> {code}
> Registration will then be possible within the Elytron subsystem configuration.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1533) Integrate Management Access
 Control permission assignment with Elytron
In-Reply-To: <JIRA.12618464.1462530450000@Atlassian.JIRA>
References: <JIRA.12618464.1462530450000@Atlassian.JIRA>
	<JIRA.12618464.1462530450000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618464.1462530450000.4342.1477763344782@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1533:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Integrate Management Access Control permission assignment with Elytron
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1533
>                 URL: https://issues.jboss.org/browse/WFCORE-1533
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 3.0.0.Alpha12
>
>
> A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role.
> Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection.
> This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron.  
> After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based.
> _Note:  As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1438) Elytron integration with
 logging subsystem
In-Reply-To: <JIRA.12610886.1458208350000@Atlassian.JIRA>
References: <JIRA.12610886.1458208350000@Atlassian.JIRA>
	<JIRA.12610886.1458208350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610886.1458208350000.4346.1477763344951@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1438:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Elytron integration with logging subsystem
> ------------------------------------------
>
>                 Key: WFCORE-1438
>                 URL: https://issues.jboss.org/browse/WFCORE-1438
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>
> This is primarily an investigation task to start with, Logging can use syslog, Syslog access can be protected with TLS, Elytron is providing unified SSL configuration - do we need to bring these together.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1598) Conversion of Elytron
 SecurityIdentity to Subject for communication with older hosts.
In-Reply-To: <JIRA.12633268.1466074901000@Atlassian.JIRA>
References: <JIRA.12633268.1466074901000@Atlassian.JIRA>
	<JIRA.12633268.1466074901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633268.1466074901000.4335.1477763344647@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1598:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.
> -------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1598
>                 URL: https://issues.jboss.org/browse/WFCORE-1598
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>
> In the domain hierarchy clients trust the server they communicate with so this server currently sends a serialized representation of the Subject containing information about the user initiating the request.
> For Elytron we will use the new identity propagation features however for older slaves we will need to convert to a Subject representation.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:04 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1691) Upgrade to Remoting JMX
	3.0.0.Alpha1
In-Reply-To: <JIRA.12641802.1470238411000@Atlassian.JIRA>
References: <JIRA.12641802.1470238411000@Atlassian.JIRA>
	<JIRA.12641802.1470238411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641802.1470238411000.4318.1477763344214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1691:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Upgrade to Remoting JMX 3.0.0.Alpha1
> ------------------------------------
>
>                 Key: WFCORE-1691
>                 URL: https://issues.jboss.org/browse/WFCORE-1691
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: JMX
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:03 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1694) Upgrade to WildFly Client
 Config 1.0.0.Beta1
In-Reply-To: <JIRA.12641806.1470240820000@Atlassian.JIRA>
References: <JIRA.12641806.1470240820000@Atlassian.JIRA>
	<JIRA.12641806.1470240820000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641806.1470240820000.4311.1477763343979@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1694:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Upgrade to WildFly Client Config 1.0.0.Beta1
> --------------------------------------------
>
>                 Key: WFCORE-1694
>                 URL: https://issues.jboss.org/browse/WFCORE-1694
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:05 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1400) Update management
 interfaces to obtain the SSLContext using the new
 'org.wildfly.security.ssl-context' capability
In-Reply-To: <JIRA.12604817.1455822462000@Atlassian.JIRA>
References: <JIRA.12604817.1455822462000@Atlassian.JIRA>
	<JIRA.12604817.1455822462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12604817.1455822462000.4353.1477763345096@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1400:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1400
>                 URL: https://issues.jboss.org/browse/WFCORE-1400
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:05 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and
 Marshalling modules are required for Remoting to run with security manager
In-Reply-To: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.4364.1477763345370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1351:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1351
>                 URL: https://issues.jboss.org/browse/WFCORE-1351
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Remoting, Security
>            Reporter: Ondrej Kotek
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 3.0.0.Alpha12
>
>         Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of  _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:05 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1157) Managmement and JMX
 notifications when ControlledProcessState changes
In-Reply-To: <JIRA.12593860.1448317498000@Atlassian.JIRA>
References: <JIRA.12593860.1448317498000@Atlassian.JIRA>
	<JIRA.12593860.1448317498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593860.1448317498000.4383.1477763345817@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1157:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Managmement and JMX notifications when ControlledProcessState changes
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-1157
>                 URL: https://issues.jboss.org/browse/WFCORE-1157
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, JMX
>            Reporter: Brian Stansberry
>            Assignee: Jeff Mesnil
>             Fix For: 3.0.0.Alpha12
>
>
> When Jeff Mesnil added the core management notification stuff an obvious thing to do was to emit notifications around ControlledProcessState changes. But I forgot. :( So lets do it.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.4392.1477763346027@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1059:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> RestartParentResourceAdd/RemoveHandler should handle capability registration
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-1059
>                 URL: https://issues.jboss.org/browse/WFCORE-1059
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.0.CR6
>            Reporter: Paul Ferraro
>            Assignee: Tomaz Cerar
>             Fix For: 3.0.0.Alpha12
>
>
> RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:05 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.4388.1477763345911@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1145:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
>                 Key: WFCORE-1145
>                 URL: https://issues.jboss.org/browse/WFCORE-1145
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 3.0.0.Alpha12
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:05 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1282) Unable to create HTTPS
 connection using *ECDH_RSA* cipher suites / kECDHr cipher string
In-Reply-To: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.4373.1477763345585@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1282:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1282
>                 URL: https://issues.jboss.org/browse/WFCORE-1282
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 1.0.2.Final
>         Environment: Oracle Java
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Alpha12
>
>         Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. 
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). 
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1006) Upgrade to PicketBox 5
In-Reply-To: <JIRA.12585975.1443100813000@Atlassian.JIRA>
References: <JIRA.12585975.1443100813000@Atlassian.JIRA>
	<JIRA.12585975.1443100813000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585975.1443100813000.4400.1477763346183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1006:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Upgrade to PicketBox 5
> ----------------------
>
>                 Key: WFCORE-1006
>                 URL: https://issues.jboss.org/browse/WFCORE-1006
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Stefan Guilhen
>             Fix For: 3.0.0.Alpha12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-673) Elytron Integration with Core
In-Reply-To: <JIRA.12570704.1430821554000@Atlassian.JIRA>
References: <JIRA.12570704.1430821554000@Atlassian.JIRA>
	<JIRA.12570704.1430821554000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570704.1430821554000.4408.1477763346465@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-673:
------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Elytron Integration with Core
> -----------------------------
>
>                 Key: WFCORE-673
>                 URL: https://issues.jboss.org/browse/WFCORE-673
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha12
>
>
> This is the top level tracking task for Elytron integration within core.  The tasks for the changes actually being made will either be linked or added as sub-tasks.
> In addition to this general issues that affect the Elytron integration are being labelled with 'affects_elytron' and can be queried using the following query: -
> https://issues.jboss.org/issues/?filter=12323574
> The label is a general catch-all for issues that are of interest to us but are not automatically blockers for our progress.
> The general criteria for the resolution of this issue will be: -
>  - Inclusion of the Elytron Subsystem in core
>  - All network entry points in core to be securable using Elytron
>  - All SSL artefacts to be obtainable from Elytron.
> Note:  The legacy modes will become better defined as we progress but whilst it must be possible to use Elytron it's use may still be optional to a certain degree.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-610) Integrate Elytron for
 management security.
In-Reply-To: <JIRA.12566595.1427107186000@Atlassian.JIRA>
References: <JIRA.12566595.1427107186000@Atlassian.JIRA>
	<JIRA.12566595.1427107186000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566595.1427107186000.4417.1477763346634@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-610:
------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Integrate Elytron for management security.
> ------------------------------------------
>
>                 Key: WFCORE-610
>                 URL: https://issues.jboss.org/browse/WFCORE-610
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha12
>
>
> This is a top level container task for the integration of Elytron for domain management security.
> Do note however that the purpose of Elytron is a single unified security solution across the whole of the application server so many tasks here will be groundwork for the remainder of the integration.
> At the moment the Elytron subsystem is being developed outside of wildfly-core, this will need to change in the future due to dependency issues (i.e. to write a subsystem you need to depend on core and core will need to include the subsystem (I think.)).  However this will make it easier for now to ensure that the subsystem is 100% with no WildFly code accessing the subsystem - and also verify that we can create a distribtion with out the subsystem and still have a functional server.
> Overall if someone came up with an alternative subsystem that provided the same capabilities it should be possible to drop it in.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-363)
 ManagementResourceRegistration.getOverrideModel never returns null
In-Reply-To: <JIRA.12531538.1391919140000@Atlassian.JIRA>
References: <JIRA.12531538.1391919140000@Atlassian.JIRA>
	<JIRA.12531538.1391919140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531538.1391919140000.4420.1477763346693@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-363:
------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
>                 Key: WFCORE-363
>                 URL: https://issues.jboss.org/browse/WFCORE-363
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Alpha12
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-311) Better error message if
 authentication is required to connect to the master but no realm is
 associated on the slave
In-Reply-To: <JIRA.12533525.1393517943000@Atlassian.JIRA>
References: <JIRA.12533525.1393517943000@Atlassian.JIRA>
	<JIRA.12533525.1393517943000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12533525.1393517943000.4424.1477763346782@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-311:
------------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> Better error message if authentication is required to connect to the master but no realm is associated on the slave
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-311
>                 URL: https://issues.jboss.org/browse/WFCORE-311
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>         Environment: RH EL 6.3 - JBoss EAP 6.2
>            Reporter: Riccardo Benvenuti
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 3.0.0.Alpha12
>
>
> In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below
> <domain-controller>
>    <remote host="10.123.137.200" port="9999"/>
> </domain-controller>
> we get the following error:
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /opt/jboss7/jboss-eap-6.2
>   JAVA: /usr/java/jdk1.7.0_51/bin/java
>   JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
> [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
> [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
> [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999
> [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
> [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm]
> [Host Controller]
> [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management]
> [Host Controller]
> [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014776: Newly corrected services:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required)
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required)
> [Host Controller]
> [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms
> 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting
> Adding the realm everything works correctly 
> <domain-controller>
>    <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/>
> </domain-controller>
> Maybe a warning message could be useful to find the problem.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 13:49:06 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 29 Oct 2016 13:49:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.4429.1477763346909@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-13:
-----------------------------------
    Fix Version/s: 3.0.0.Alpha12
                       (was: 3.0.0.Alpha11)


> End users can call non-published management API operations
> ----------------------------------------------------------
>
>                 Key: WFCORE-13
>                 URL: https://issues.jboss.org/browse/WFCORE-13
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>              Labels: EAP
>             Fix For: 3.0.0.Alpha12
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 14:58:00 2016
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Sat, 29 Oct 2016 14:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7419) Add resteasy wadl as a module
In-Reply-To: <JIRA.12657858.1477767448000@Atlassian.JIRA>
References: <JIRA.12657858.1477767448000@Atlassian.JIRA>
	<JIRA.12657858.1477767448252@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657858.1477767448000.4432.1477767480208@Atlassian.JIRA>

Frank Langelage created WFLY-7419:
-------------------------------------

             Summary: Add resteasy wadl as a module
                 Key: WFLY-7419
                 URL: https://issues.jboss.org/browse/WFLY-7419
             Project: WildFly
          Issue Type: Enhancement
          Components: REST
    Affects Versions: 10.1.0.Final, 11.0.0.Alpha1
            Reporter: Frank Langelage
            Assignee: Stuart Douglas
             Fix For: 10.2.0.Final, 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 15:07:00 2016
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Sat, 29 Oct 2016 15:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7419) Add resteasy wadl as a module
In-Reply-To: <JIRA.12657858.1477767448000@Atlassian.JIRA>
References: <JIRA.12657858.1477767448000@Atlassian.JIRA>
	<JIRA.12657858.1477767448000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657858.1477767448000.4439.1477768020265@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-7419:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9315, https://github.com/wildfly/wildfly/pull/9316  (was: https://github.com/wildfly/wildfly/pull/9315)


> Add resteasy wadl as a module
> -----------------------------
>
>                 Key: WFLY-7419
>                 URL: https://issues.jboss.org/browse/WFLY-7419
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: REST
>    Affects Versions: 10.1.0.Final, 11.0.0.Alpha1
>            Reporter: Frank Langelage
>            Assignee: Stuart Douglas
>             Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 15:49:00 2016
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Sat, 29 Oct 2016 15:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7419) Add resteasy wadl as a module
In-Reply-To: <JIRA.12657858.1477767448000@Atlassian.JIRA>
References: <JIRA.12657858.1477767448000@Atlassian.JIRA>
	<JIRA.12657858.1477767448000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657858.1477767448000.4446.1477770540306@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-7419:
---------------------------------

    Assignee: Alessio Soldano  (was: Stuart Douglas)


> Add resteasy wadl as a module
> -----------------------------
>
>                 Key: WFLY-7419
>                 URL: https://issues.jboss.org/browse/WFLY-7419
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: REST
>    Affects Versions: 10.1.0.Final, 11.0.0.Alpha1
>            Reporter: Frank Langelage
>            Assignee: Alessio Soldano
>             Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sat Oct 29 23:44:00 2016
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sat, 29 Oct 2016 23:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1350) 401 Unauthorized kie-server
 rest api peflight call error -> change web.xml security constraints
In-Reply-To: <JIRA.12657849.1477730544000@Atlassian.JIRA>
References: <JIRA.12657849.1477730544000@Atlassian.JIRA>
	<JIRA.12657849.1477730544000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657849.1477730544000.4492.1477799040239@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-1350:
-------------------------------------

    Assignee: Maciej Swiderski  (was: Edson Tirelli)


> 401 Unauthorized kie-server rest api peflight call error -> change web.xml security constraints
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1350
>                 URL: https://issues.jboss.org/browse/DROOLS-1350
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Kai Jemella
>            Assignee: Maciej Swiderski
>         Attachments: kie-server_cors_preflight_401.png
>
>
> Using the kie-server REST API with a javascript framework like angular2 results in a [CORS Preflight W3C|https://www.w3.org/TR/cors/#resource-preflight-requests] response 401 :
> {code}
> zone.js:1274 OPTIONS http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances 
> XMLHttpRequest cannot load http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/rest/server/containers/quickorder-kie/processes/quickorder/instances. Response for preflight has invalid HTTP status code 401
> {code}
> CORS Response Header are set, this is not the problem:
> {code:xml}
> # filter references
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Origin:add
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Methods:add
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Headers:add
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Credentials:add
> # filter
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Origin:add(header-name=Access-Control-Allow-Origin,header-value="*")
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Methods:add(header-name=Access-Control-Allow-Methods,header-value="GET, PUT, POST, OPTIONS, DELETE")
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Headers:add \
> (header-name=Access-Control-Allow-Headers,header-value="accept, authorization, content-type, x-requested-with, X-KIE-ContentType")
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Credentials:add(header-name=Access-Control-Allow-Credentials,header-value="true")
> {code}
> The problem occurs by the kie-server web descriptor security constraint:
> {code:title=web.xml}
> ...
> <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>REST web resources</web-resource-name>
>       <url-pattern>/services/rest/*</url-pattern>
>     </web-resource-collection>
>     <auth-constraint>
>       <role-name>kie-server</role-name>
>     </auth-constraint>
> </security-constraint>
> ...
> {code}
> The security constraint should be active for all jax-rs HTTP methods, without the OPTIONS method:
> {code:title=web.xml}
> ...
>   <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>REST web resources</web-resource-name>
>       <url-pattern>/services/rest/*</url-pattern>
>       <http-method>GET</http-method>
>       <http-method>PUT</http-method>
>       <http-method>POST</http-method>
>       <http-method>DELETE</http-method>
>     </web-resource-collection>
>     <auth-constraint>
>       <role-name>kie-server</role-name>
>     </auth-constraint>
>   </security-constraint>
> ...
> {code}
> Tested with firefox and chrome.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sun Oct 30 08:20:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Sun, 30 Oct 2016 08:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5866) ClosedChannelException in
 SingleFileStore after server is shut down
In-Reply-To: <JIRA.12597024.1450349932000@Atlassian.JIRA>
References: <JIRA.12597024.1450349932000@Atlassian.JIRA>
	<JIRA.12597024.1450349932000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597024.1450349932000.4618.1477830000207@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313713#comment-13313713 ] 

Paul Ferraro commented on WFLY-5866:
------------------------------------

[~mvinkler] Please close this if it is no longer an issue.

> ClosedChannelException in SingleFileStore after server is shut down
> -------------------------------------------------------------------
>
>                 Key: WFLY-5866
>                 URL: https://issues.jboss.org/browse/WFLY-5866
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR4
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>            Priority: Minor
>
> Seen in our failover tests for remote stateful EJBs:
>  - scenario ejb-ejbremote-shutdown-dist-sync-tcpStack
> After perf21 was shut down, other nodes received new view and logged these exceptions, all of them having the same stacktrace and coming from {{org.infinispan.persistence.file.SingleFileStore._load(SingleFileStore.java:484)}}
> {code:title=AsynchronousCloseException}
> [JBossINF] [0m[31m18:06:00,890 ERROR [org.infinispan.persistence.file.SingleFileStore] (transport-thread--p16-t13) ISPN000252: Error executing parallel store task: org.infinispan.persistence.spi.PersistenceException: java.nio.channels.AsynchronousCloseException
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore._load(SingleFileStore.java:484)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore.access$600(SingleFileStore.java:71)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore$2.call(SingleFileStore.java:535)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore$2.call(SingleFileStore.java:531)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:21)
> [JBossINF] 	at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
> [JBossINF] 	at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore.process(SingleFileStore.java:531)
> [JBossINF] 	at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:171)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: java.nio.channels.AsynchronousCloseException
> [JBossINF] 	at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:205)
> [JBossINF] 	at sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:745)
> [JBossINF] 	at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:726)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore._load(SingleFileStore.java:482)
> [JBossINF] 	... 18 more
> {code}
> {code:title=ClosedByInterruptException}
> [JBossINF] [0m[31m18:06:00,890 ERROR [org.infinispan.persistence.file.SingleFileStore] (transport-thread--p16-t10) ISPN000252: Error executing parallel store task: org.infinispan.persistence.spi.PersistenceException: java.nio.channels.ClosedByInterruptException
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore._load(SingleFileStore.java:484)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore.access$600(SingleFileStore.java:71)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore$2.call(SingleFileStore.java:535)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore$2.call(SingleFileStore.java:531)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:21)
> [JBossINF] 	at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
> [JBossINF] 	at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore.process(SingleFileStore.java:531)
> [JBossINF] 	at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:171)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: java.nio.channels.ClosedByInterruptException
> [JBossINF] 	at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
> [JBossINF] 	at sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:745)
> [JBossINF] 	at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:726)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore._load(SingleFileStore.java:482)
> [JBossINF] 	... 18 more
> {code}
> {code:title=ClosedChannelException}
> [JBossINF] [0m[31m18:06:00,895 ERROR [org.infinispan.persistence.file.SingleFileStore] (transport-thread--p16-t13) ISPN000252: Error executing parallel store task: org.infinispan.persistence.spi.PersistenceException: java.nio.channels.ClosedChannelException
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore._load(SingleFileStore.java:484)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore.access$600(SingleFileStore.java:71)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore$2.call(SingleFileStore.java:535)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore$2.call(SingleFileStore.java:531)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:21)
> [JBossINF] 	at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
> [JBossINF] 	at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore.process(SingleFileStore.java:531)
> [JBossINF] 	at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:171)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: java.nio.channels.ClosedChannelException
> [JBossINF] 	at sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:110)
> [JBossINF] 	at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:720)
> [JBossINF] 	at org.infinispan.persistence.file.SingleFileStore._load(SingleFileStore.java:482)
> [JBossINF] 	... 18 more
> {code}
> While the first two exceptions were logged only few times, the {{ClosedChannelException}} was logged tens of thousand times on perf19 and perf20.
> These exceptions don't seem to cause any sampling errors on the client side.
> Link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-ejbremote-shutdown-dist-sync-tcpStack/14/console-perf20/



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sun Oct 30 17:13:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sun, 30 Oct 2016 17:13:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-692) Add tests for special chars in
 LegacyPropertiesSecurityRealm
In-Reply-To: <JIRA.12657100.1477486534000@Atlassian.JIRA>
References: <JIRA.12657100.1477486534000@Atlassian.JIRA>
	<JIRA.12657100.1477486534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657100.1477486534000.4676.1477861980083@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313718#comment-13313718 ] 

Jan Kalina commented on ELY-692:
--------------------------------

Please add references to related issues as Links, to we can see that such issue exists in related issues too.

> Add tests for special chars in LegacyPropertiesSecurityRealm
> ------------------------------------------------------------
>
>                 Key: ELY-692
>                 URL: https://issues.jboss.org/browse/ELY-692
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms, Testsuite
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Lukas
>
> Add tests for issue https://issues.jboss.org/browse/ELY-688 and https://issues.jboss.org/browse/ELY-691



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sun Oct 30 17:15:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sun, 30 Oct 2016 17:15:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-692) Add tests for special chars in
 LegacyPropertiesSecurityRealm
In-Reply-To: <JIRA.12657100.1477486534000@Atlassian.JIRA>
References: <JIRA.12657100.1477486534000@Atlassian.JIRA>
	<JIRA.12657100.1477486534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657100.1477486534000.4679.1477862100117@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313718#comment-13313718 ] 

Jan Kalina edited comment on ELY-692 at 10/30/16 5:14 PM:
----------------------------------------------------------

Please add references to related issues as Links next time, to we can see that such issue exists in related issues too.


was (Author: honza889):
Please add references to related issues as Links, to we can see that such issue exists in related issues too.

> Add tests for special chars in LegacyPropertiesSecurityRealm
> ------------------------------------------------------------
>
>                 Key: ELY-692
>                 URL: https://issues.jboss.org/browse/ELY-692
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms, Testsuite
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Lukas
>
> Add tests for issue https://issues.jboss.org/browse/ELY-688 and https://issues.jboss.org/browse/ELY-691



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sun Oct 30 18:04:00 2016
From: issues at jboss.org (william teskey (JIRA))
Date: Sun, 30 Oct 2016 18:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7364)
 java.lang.IllegalArgumentException: UT000068: Servlet path match failed
In-Reply-To: <JIRA.12656014.1477000674000@Atlassian.JIRA>
References: <JIRA.12656014.1477000674000@Atlassian.JIRA>
	<JIRA.12656014.1477000674000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656014.1477000674000.3.1477865040852@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313810#comment-13313810 ] 

william teskey commented on WFLY-7364:
--------------------------------------

It looks like I inadvertently removed the default servlet.  I have restored what I believe to be it.

> java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7364
>                 URL: https://issues.jboss.org/browse/WFLY-7364
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: william teskey
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> [0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> 	at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
> 	at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
> 	at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
> 	at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Sun Oct 30 19:51:01 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 30 Oct 2016 19:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7374) WildFfly openssl requires
 glibc 2.14 resulting in failure when starting on RHEL 6
In-Reply-To: <JIRA.12656785.1477410763000@Atlassian.JIRA>
References: <JIRA.12656785.1477410763000@Atlassian.JIRA>
	<JIRA.12656785.1477410763000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656785.1477410763000.59.1477871461748@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-7374.
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Done


> WildFfly openssl requires glibc 2.14 resulting in failure when starting on RHEL 6
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-7374
>                 URL: https://issues.jboss.org/browse/WFLY-7374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Server, Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: Stuart Douglas
>            Priority: Blocker
>              Labels: wildfly-openssl
>             Fix For: 11.0.0.Alpha1
>
>
> When starting EAP on RHEL 6 it shows ERROR messages when loading openssl \[1\]. This is caused by the wrapper requiring glibc 2.14 or newer but on RHEL 6 (RHEL 6.7) there is only glibc 2.12.
> As there should be no ERROR messages during EAP start with default configuration, marking as blocker.
> \[1\]
> {noformat}
> 11:20:42,474 ERROR [stderr] (MSC service thread 1-3) java.lang.reflect.InvocationTargetException
> 11:20:42,476 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:20:42,479 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:20:42,481 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:20:42,494 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Method.invoke(Method.java:498)
> 11:20:42,495 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.init(SSL.java:73)
> 11:20:42,496 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
> 11:20:42,497 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName0(Native Method)
> 11:20:42,498 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.forName(Class.java:348)
> 11:20:42,499 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
> 11:20:42,505 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
> 11:20:42,508 ERROR [stderr] (MSC service thread 1-3) 	at java.security.AccessController.doPrivileged(Native Method)
> 11:20:42,516 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
> 11:20:42,517 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:20:42,524 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:20:42,525 ERROR [stderr] (MSC service thread 1-3) 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:20:42,539 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> 11:20:42,540 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Class.newInstance(Class.java:442)
> 11:20:42,541 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> 11:20:42,542 ERROR [stderr] (MSC service thread 1-3) 	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> 11:20:42,543 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
> 11:20:42,548 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
> 11:20:42,550 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
> 11:20:42,551 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
> 11:20:42,552 ERROR [stderr] (MSC service thread 1-3) 	at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
> 11:20:42,553 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
> 11:20:42,557 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
> 11:20:42,572 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
> 11:20:42,581 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> 11:20:42,582 ERROR [stderr] (MSC service thread 1-3) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 11:20:42,590 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:20:42,591 ERROR [stderr] (MSC service thread 1-3) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:20:42,593 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Thread.run(Thread.java:745)
> 11:20:42,595 ERROR [stderr] (MSC service thread 1-3) Caused by: java.lang.UnsatisfiedLinkError: /tmp/tmp-2717760086872143296openssl/libwfssl.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/tmp-2717760086872143296openssl/libwfssl.so)
> 11:20:42,596 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> 11:20:42,597 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
> 11:20:42,598 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1837)
> 11:20:42,610 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> 11:20:42,611 ERROR [stderr] (MSC service thread 1-3) 	at java.lang.System.loadLibrary(System.java:1122)
> 11:20:42,619 ERROR [stderr] (MSC service thread 1-3) 	at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
> 11:20:42,620 ERROR [stderr] (MSC service thread 1-3) 	... 34 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sun Oct 30 19:56:00 2016
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Sun, 30 Oct 2016 19:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7418) Batch deployments with a
 large number of executed jobs can lock up or slow down the web console
In-Reply-To: <JIRA.12657844.1477695275000@Atlassian.JIRA>
References: <JIRA.12657844.1477695275000@Atlassian.JIRA>
	<JIRA.12657844.1477695275000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657844.1477695275000.75.1477871760144@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313813#comment-13313813 ] 

Harald Pehl commented on WFLY-7418:
-----------------------------------

One workaround could be to open another tab, browser window or different browser to avoid blocking the rest of the management console. Not sure if that works out, though. Another option could be the use of web workers [1], but that would need more analysis and would be something to consider for HAL.next.

Apart from that I don't have other solutions atm. 

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7418
>                 URL: https://issues.jboss.org/browse/WFLY-7418
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Batch, Web Console
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Sun Oct 30 20:21:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 30 Oct 2016 20:21:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7364)
 java.lang.IllegalArgumentException: UT000068: Servlet path match failed
In-Reply-To: <JIRA.12656014.1477000674000@Atlassian.JIRA>
References: <JIRA.12656014.1477000674000@Atlassian.JIRA>
	<JIRA.12656014.1477000674000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656014.1477000674000.85.1477873260273@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-7364.
----------------------------------
    Resolution: Rejected


> java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7364
>                 URL: https://issues.jboss.org/browse/WFLY-7364
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: william teskey
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> [0m[31m16:24:45,861 ERROR [io.undertow.request] (default I/O-6) UT005071: Undertow request failed HttpServerExchange{ GET china2000fineart.com request {Accept=[*/*], User-Agent=[Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36], Referer=[http://china2000fineart.com], Host=[china2000fineart.com]} response {}}: java.lang.IllegalArgumentException: UT000068: Servlet path match failed
> 	at io.undertow.servlet.handlers.ServletPathMatchesData.getServletHandlerByPath(ServletPathMatchesData.java:83)
> 	at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:83)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:151)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:39)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
> 	at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:295)
> 	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
> 	at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:303)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:54)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> 	at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> 	at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:128)
> 	at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 03:46:00 2016
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 31 Oct 2016 03:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5029) Reintroduce EJB, JMS,
 JNDI over HTTP/HTTPS capability with HTTP Loadbalancer
In-Reply-To: <JIRA.12579802.1438189664000@Atlassian.JIRA>
References: <JIRA.12579802.1438189664000@Atlassian.JIRA>
	<JIRA.12579802.1438189664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12579802.1438189664000.528.1477899960247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-5029:
------------------------------------

    Assignee: Stuart Douglas  (was: Jason Greene)


> Reintroduce EJB, JMS, JNDI over HTTP/HTTPS capability with HTTP Loadbalancer
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-5029
>                 URL: https://issues.jboss.org/browse/WFLY-5029
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB, Server, Web (Undertow)
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Bilge Ozpeynirci
>            Assignee: Stuart Douglas
>
> Ability to run EJB, JMS, JNDI over HTTP/HTTPS which was possible in earlier JBoss AS/EAP 5 & 4.
> User will be able to do 1:1 EJB invocation to HTTP request, so that HTTP requests (that carry EJB Load) can be load balanced at the request level instead of at the connection level.
> 1:1 mapping of EJB invocation to an HTTP request will be possible. This way, a hardware HTTP LB or Undertow Load Balancer or HTTPD Load Balancer can balance the requests according to a custom LB policy. In this case; the EJB clustering will not have to be configured. 



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 04:15:01 2016
From: issues at jboss.org (Chao Wang (JIRA))
Date: Mon, 31 Oct 2016 04:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1908) Tab completion suggest
 writing attribute which has access type metric and is not writable
In-Reply-To: <JIRA.12658019.1477901637000@Atlassian.JIRA>
References: <JIRA.12658019.1477901637000@Atlassian.JIRA>
	<JIRA.12658019.1477901637000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658019.1477901637000.651.1477901701033@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang moved JBEAP-6715 to WFCORE-1908:
------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-1908  (was: JBEAP-6715)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: CLI
                           (was: CLI)
                           (was: User Experience)
    Affects Version/s: 3.0.0.Alpha11
                           (was: 7.1.0.DR7)


> Tab completion suggest writing attribute which has access type metric and is not writable
> -----------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1908
>                 URL: https://issues.jboss.org/browse/WFCORE-1908
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha11
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>
> CLI tab completion suggests attributes that are not writable and their access-type is {{metric}}
> Example {code}
> /subsystem=messaging-activemq/server=default/jms-queue=DLQ:write-attribute(name=<TAB>
> consumer-count  delivering-count  entries  legacy-entries  message-count  messages-added  scheduled-count  
> {code}
> From executing {{:read-resource-description}} we can see, attributes consumer-count, delivering-count, message-count, messages-added, scheduled-count are of type metric.
> On attempt to write metric attribute, for example message-count, non writable error is printed {code}
> [standalone at localhost:9990 jms-queue=q] :write-attribute(name=message-count, value=5)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0048: Attribute message-count is not writable",
>     "rolled-back" => true
> }
> {code}
> CLI should not suggest writing attributes that are not writable.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 04:45:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 31 Oct 2016 04:45:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1909) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.784.1477903500418@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise moved WFLY-7398 to WFCORE-1909:
----------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-1909  (was: WFLY-7398)
    Component/s: CLI
                     (was: CLI)


> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1909
>                 URL: https://issues.jboss.org/browse/WFCORE-1909
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 05:20:00 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 31 Oct 2016 05:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.1152.1477905600818@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13313987#comment-13313987 ] 

Jan Kalina commented on WFLY-7322:
----------------------------------

[~dlofthouse] Do we need *throw* mode of LDAP referrals support? If we will follow every referral, it will be equivalent of *follow* mode.

> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 05:47:00 2016
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 31 Oct 2016 05:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7420) Ignore client messaging tests
 failing with a security manager
In-Reply-To: <JIRA.12658041.1477907198000@Atlassian.JIRA>
References: <JIRA.12658041.1477907198000@Atlassian.JIRA>
	<JIRA.12658041.1477907198931@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658041.1477907198000.1423.1477907220603@Atlassian.JIRA>

Jeff Mesnil created WFLY-7420:
---------------------------------

             Summary: Ignore client messaging tests failing with a security manager
                 Key: WFLY-7420
                 URL: https://issues.jboss.org/browse/WFLY-7420
             Project: WildFly
          Issue Type: Task
          Components: JMS
    Affects Versions: 10.1.0.Final
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil


The upgrade to Artemis 1.4.0 (WFLY-7245) introduced a regression for JMS clients running with a security manager.
The issue was fixed in Artemis master branch (https://issues.apache.org/jira/browse/ARTEMIS-808) and will be part of the next release after 1.4.0.

In the meantime, ignore the failing tests when the security manager is set.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 05:58:00 2016
From: issues at jboss.org (Pavel Jelinek (JIRA))
Date: Mon, 31 Oct 2016 05:58:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1910) Add ability to inherit
	resources
In-Reply-To: <JIRA.12658048.1477907859000@Atlassian.JIRA>
References: <JIRA.12658048.1477907859000@Atlassian.JIRA>
	<JIRA.12658048.1477907859221@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658048.1477907859000.1529.1477907880617@Atlassian.JIRA>

Pavel Jelinek created WFCORE-1910:
-------------------------------------

             Summary: Add ability to inherit resources
                 Key: WFCORE-1910
                 URL: https://issues.jboss.org/browse/WFCORE-1910
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Pavel Jelinek
            Assignee: Brian Stansberry


Motivation: 

to be able to have stable resources which name and structure will be backward compatible even between major releases (e.g. something like /subsystem=web-abstract) and which could be inherited/implemented by resources which bring more configuration possibilities but may not be backward compatible between major releases (like e.g. /subsystem=undertow). 

This would give users the possibility to write *stable CLI/HTTP API/whatever automation* if they use stable (parent) resources. There will still remain the option to use full configuration options offered by the implementing (children) resources but without backward compatibility guarantee.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 06:00:00 2016
From: issues at jboss.org (Pavel Jelinek (JIRA))
Date: Mon, 31 Oct 2016 06:00:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1910) Add ability to inherit
	resources
In-Reply-To: <JIRA.12658048.1477907859000@Atlassian.JIRA>
References: <JIRA.12658048.1477907859000@Atlassian.JIRA>
	<JIRA.12658048.1477907859000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658048.1477907859000.1549.1477908000284@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pavel Jelinek updated WFCORE-1910:
----------------------------------
    Labels: user_experience  (was: )


> Add ability to inherit resources
> --------------------------------
>
>                 Key: WFCORE-1910
>                 URL: https://issues.jboss.org/browse/WFCORE-1910
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Pavel Jelinek
>            Assignee: Brian Stansberry
>              Labels: user_experience
>
> Motivation: 
> to be able to have stable resources which name and structure will be backward compatible even between major releases (e.g. something like /subsystem=web-abstract) and which could be inherited/implemented by resources which bring more configuration possibilities but may not be backward compatible between major releases (like e.g. /subsystem=undertow). 
> This would give users the possibility to write *stable CLI/HTTP API/whatever automation* if they use stable (parent) resources. There will still remain the option to use full configuration options offered by the implementing (children) resources but without backward compatibility guarantee.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 06:01:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 31 Oct 2016 06:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1909) Tab completion causes NUL
 characters ('\0') to be injected...sometimes
In-Reply-To: <JIRA.12657551.1477577764000@Atlassian.JIRA>
References: <JIRA.12657551.1477577764000@Atlassian.JIRA>
	<JIRA.12657551.1477577764000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657551.1477577764000.1556.1477908060260@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314015#comment-13314015 ] 

Jean-Francois Denise commented on WFCORE-1909:
----------------------------------------------

Hi David,
thank-you for the additional information. I ran your branch, the value-type is a simple String, nothing special there. I checked CLI code, no way to internally inject this character,

I found an explanation to what you are experiencing. It could be that, as our IDE are offering completion with the combination of "Ctrl- space" (at least NetBeans and Eclipse), you typed at some point this combination to complete the CLI as you are used to do in your IDE. In the terminal Ctrl-space means '\0' character...

I was able to reproduce the problem. Type 'Ctrl space', nothing is displayed in the CLI console although '\0' has been stored.

I am going to see if we can filter out (or make them visible) these characters at the Aesh level. Aesh sees all characters and has the choice to keep them or not.

> Tab completion causes NUL characters ('\0') to be injected...sometimes
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1909
>                 URL: https://issues.jboss.org/browse/WFCORE-1909
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: David Lloyd
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>
> I noticed while testing my subsystem that sometimes using tab-complete on an attribute causes NUL ('\0') characters to be injected into the input.  These characters are invisible on the screen but cause XML marshalling to fail as that character is forbidden.
> My "less" output of .jboss-cli-history looks something like this:
> {noformat}
> embed-server --std-out=echo
> cd subsystem=discovery
> ./static-provider=test:add(services=[{uri=^@^@"local", abstract-type="ejb", abstract-type-authority="jboss"}])
> ./static-provider=test4:add(services=[{uri="local", abstract-type="ejb", abstract-type-authority="jboss"}])
> {noformat}
> In the first "test:add" case I used tab-completion; in the second "test4:add" case I typed it out by hand.  The "^@" are in inverse video in less, indicating a NUL character.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 06:03:00 2016
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Mon, 31 Oct 2016 06:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-169) Use JBoss Modules to load
 RESTEasy implementations of javax.ws.rs.ext.RuntimeDelegate and
 javax.ws.rs.client.ClientBuilder
In-Reply-To: <JIRA.12658050.1477908124000@Atlassian.JIRA>
References: <JIRA.12658050.1477908124000@Atlassian.JIRA>
	<JIRA.12658050.1477908124384@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658050.1477908124000.1571.1477908180114@Atlassian.JIRA>

Alessio Soldano created JBEE-169:
------------------------------------

             Summary: Use JBoss Modules to load RESTEasy implementations of javax.ws.rs.ext.RuntimeDelegate and javax.ws.rs.client.ClientBuilder
                 Key: JBEE-169
                 URL: https://issues.jboss.org/browse/JBEE-169
             Project: JBoss JavaEE Spec APIs
          Issue Type: Enhancement
          Components: jboss-jaxrs-api
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano


Currently jboss-jaxrs-api_2.0_spec has a modified RESTEasy value for the default implementation of javax.ws.rs.ext.RuntimeDelegate. It should likely keep the default Jersey / JDK values and load JBoss/RESTEasy implementations of both javax.ws.rs.ext.RuntimeDelegate and javax.ws.rs.client.ClientBuilder using JBoss Modules when running in-container. This is basically what the jaxws-api already does for the javax.xml.ws.spi.Provider.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 06:46:00 2016
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 31 Oct 2016 06:46:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7421) Port
	DeploymentScannerTestCase to upstream
In-Reply-To: <JIRA.12658058.1477910749000@Atlassian.JIRA>
References: <JIRA.12658058.1477910749000@Atlassian.JIRA>
	<JIRA.12658058.1477910749238@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658058.1477910749000.1798.1477910760704@Atlassian.JIRA>

Peter Palaga created WFLY-7421:
----------------------------------

             Summary: Port DeploymentScannerTestCase to upstream
                 Key: WFLY-7421
                 URL: https://issues.jboss.org/browse/WFLY-7421
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Peter Palaga


The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 06:47:00 2016
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 31 Oct 2016 06:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7421) Port
	DeploymentScannerTestCase to upstream
In-Reply-To: <JIRA.12658058.1477910749000@Atlassian.JIRA>
References: <JIRA.12658058.1477910749000@Atlassian.JIRA>
	<JIRA.12658058.1477910749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658058.1477910749000.1808.1477910820397@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga updated WFLY-7421:
-------------------------------
    Description: The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.  (was: The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.)


> Port DeploymentScannerTestCase to upstream
> ------------------------------------------
>
>                 Key: WFLY-7421
>                 URL: https://issues.jboss.org/browse/WFLY-7421
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Peter Palaga
>
> The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 06:48:00 2016
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 31 Oct 2016 06:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7422) (EAP 7.1.z) Port
 DeploymentScannerTestCase to upstream
In-Reply-To: <JIRA.12658059.1477910848000@Atlassian.JIRA>
References: <JIRA.12658059.1477910848000@Atlassian.JIRA>
	<JIRA.12658059.1477910848704@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658059.1477910848000.1811.1477910880236@Atlassian.JIRA>

Peter Palaga created WFLY-7422:
----------------------------------

             Summary: (EAP 7.1.z) Port DeploymentScannerTestCase to upstream
                 Key: WFLY-7422
                 URL: https://issues.jboss.org/browse/WFLY-7422
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Peter Palaga


The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 07:05:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Mon, 31 Oct 2016 07:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-701) keyStoreType in
 wildfly-elytron_1_0.xsd contains "password" attribute.
In-Reply-To: <JIRA.12658063.1477911867000@Atlassian.JIRA>
References: <JIRA.12658063.1477911867000@Atlassian.JIRA>
	<JIRA.12658063.1477911867138@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658063.1477911867000.1966.1477911900591@Atlassian.JIRA>

Hynek ?v?bek created ELY-701:
--------------------------------

             Summary: keyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
                 Key: ELY-701
                 URL: https://issues.jboss.org/browse/ELY-701
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Hynek ?v?bek
            Assignee: Darran Lofthouse
            Priority: Minor


KeyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.

There is "credential-reference" element that is replacement for "password" attribute.

Please remove "password" attribute from keyStoreType.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 07:05:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Mon, 31 Oct 2016 07:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-701) keyStoreType in
 wildfly-elytron_1_0.xsd contains "password" attribute.
In-Reply-To: <JIRA.12658063.1477911867000@Atlassian.JIRA>
References: <JIRA.12658063.1477911867000@Atlassian.JIRA>
	<JIRA.12658063.1477911867000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658063.1477911867000.1970.1477911900824@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-701:
-----------------------------
    Affects Version/s: 1.1.0.Beta11


> keyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> ----------------------------------------------------------------------
>
>                 Key: ELY-701
>                 URL: https://issues.jboss.org/browse/ELY-701
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Hynek ?v?bek
>            Assignee: Darran Lofthouse
>            Priority: Minor
>
> KeyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> There is "credential-reference" element that is replacement for "password" attribute.
> Please remove "password" attribute from keyStoreType.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 07:06:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Mon, 31 Oct 2016 07:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-701) keyStoreType in
 wildfly-elytron_1_0.xsd contains "password" attribute.
In-Reply-To: <JIRA.12658063.1477911867000@Atlassian.JIRA>
References: <JIRA.12658063.1477911867000@Atlassian.JIRA>
	<JIRA.12658063.1477911867000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658063.1477911867000.1977.1477911960328@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek reassigned ELY-701:
--------------------------------

    Assignee: Peter Skopek  (was: Darran Lofthouse)


> keyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> ----------------------------------------------------------------------
>
>                 Key: ELY-701
>                 URL: https://issues.jboss.org/browse/ELY-701
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store, KeyStores
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>            Priority: Minor
>
> KeyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> There is "credential-reference" element that is replacement for "password" attribute.
> Please remove "password" attribute from keyStoreType.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 07:06:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Mon, 31 Oct 2016 07:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-701) keyStoreType in
 wildfly-elytron_1_0.xsd contains "password" attribute.
In-Reply-To: <JIRA.12658063.1477911867000@Atlassian.JIRA>
References: <JIRA.12658063.1477911867000@Atlassian.JIRA>
	<JIRA.12658063.1477911867000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658063.1477911867000.1973.1477911960242@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-701:
-----------------------------
    Component/s: Credential Store
                 KeyStores


> keyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> ----------------------------------------------------------------------
>
>                 Key: ELY-701
>                 URL: https://issues.jboss.org/browse/ELY-701
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store, KeyStores
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Hynek ?v?bek
>            Assignee: Darran Lofthouse
>            Priority: Minor
>
> KeyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> There is "credential-reference" element that is replacement for "password" attribute.
> Please remove "password" attribute from keyStoreType.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 07:12:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 31 Oct 2016 07:12:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-701) keyStoreType in
 wildfly-elytron_1_0.xsd contains "password" attribute.
In-Reply-To: <JIRA.12658063.1477911867000@Atlassian.JIRA>
References: <JIRA.12658063.1477911867000@Atlassian.JIRA>
	<JIRA.12658063.1477911867000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658063.1477911867000.2020.1477912320139@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314050#comment-13314050 ] 

Darran Lofthouse commented on ELY-701:
--------------------------------------

[~hsvabek] For any issues specifically related to the subsystem can you please create the community issue in the WFLY project.  

At some point we will move the subsystem into WildFly Core as we don't have a specific Jira project for it for now but it is the WildFly project that currently pulls it into the build so we are tracking issues there.

> keyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> ----------------------------------------------------------------------
>
>                 Key: ELY-701
>                 URL: https://issues.jboss.org/browse/ELY-701
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store, KeyStores
>    Affects Versions: 1.1.0.Beta11
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>            Priority: Minor
>
> KeyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> There is "credential-reference" element that is replacement for "password" attribute.
> Please remove "password" attribute from keyStoreType.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 07:19:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Mon, 31 Oct 2016 07:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7423) keyStoreType in
 wildfly-elytron_1_0.xsd contains "password" attribute.
In-Reply-To: <JIRA.12658063.1477911867000@Atlassian.JIRA>
References: <JIRA.12658063.1477911867000@Atlassian.JIRA>
	<JIRA.12658063.1477911867000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658063.1477911867000.2040.1477912740439@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek moved ELY-701 to WFLY-7423:
----------------------------------------

              Project: WildFly  (was: WildFly Elytron)
                  Key: WFLY-7423  (was: ELY-701)
          Component/s: Security
                           (was: Credential Store)
                           (was: KeyStores)
    Affects Version/s:     (was: 1.1.0.Beta11)


> keyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7423
>                 URL: https://issues.jboss.org/browse/WFLY-7423
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>            Priority: Minor
>
> KeyStoreType in wildfly-elytron_1_0.xsd contains "password" attribute.
> There is "credential-reference" element that is replacement for "password" attribute.
> Please remove "password" attribute from keyStoreType.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 07:27:00 2016
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 31 Oct 2016 07:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5522) split artemis journal in its
	own module
In-Reply-To: <JIRA.12588882.1444735181000@Atlassian.JIRA>
References: <JIRA.12588882.1444735181000@Atlassian.JIRA>
	<JIRA.12588882.1444735181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588882.1444735181000.2070.1477913220288@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-5522:
--------------------------------
    Component/s: Transactions


> split artemis journal in its own module
> ---------------------------------------
>
>                 Key: WFLY-5522
>                 URL: https://issues.jboss.org/browse/WFLY-5522
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS, Transactions
>    Affects Versions: 10.0.0.CR2
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> The org.jboss.jts is depending on the org.apache.activemq.artemis only for its journal functionality but get all the module dependencies (including messaging stuff) that is not used at all.
> The org.apache.activemq.artemis should be split with a separate module for its journal containing the journal jar + commons jar + native lib required for libAIO.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 08:34:01 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Mon, 31 Oct 2016 08:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-695) Is impossible remove whole
 Elytron subsystem when Elytron resource depends on another Elytron
 resource.
In-Reply-To: <JIRA.12657545.1477576794000@Atlassian.JIRA>
References: <JIRA.12657545.1477576794000@Atlassian.JIRA>
	<JIRA.12657545.1477576794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657545.1477576794000.3224.1477917241173@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated ELY-695:
-----------------------------
    Description: 
Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource.

*Scenario:*
* I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore
* I want to delete whole Elytron subsystem
* I execute this CLI command */subsystem=elytron:remove()* and get error
{code}
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly",
    "rolled-back" => true
}
{code}

*NOTES:*
* When I perform CLI command */subsystem=elytron:remove()* again as it passes.
* When I use for remove {allow-resource-service-restart=true} as /subsystem=elytron:remove(){allow-resource-service-restart=true} then result is successful.

  was:
Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource.

*Scenario:*
* I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore
* I want to delete whole Elytron subsystem
* I execute this CLI command */subsystem=elytron:remove()* and get error
{code}
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly",
    "rolled-back" => true
}
{code}



> Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-695
>                 URL: https://issues.jboss.org/browse/ELY-695
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store, KeyStores
>            Reporter: Hynek ?v?bek
>            Assignee: Darran Lofthouse
>
> Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource.
> *Scenario:*
> * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore
> * I want to delete whole Elytron subsystem
> * I execute this CLI command */subsystem=elytron:remove()* and get error
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly",
>     "rolled-back" => true
> }
> {code}
> *NOTES:*
> * When I perform CLI command */subsystem=elytron:remove()* again as it passes.
> * When I use for remove {allow-resource-service-restart=true} as /subsystem=elytron:remove(){allow-resource-service-restart=true} then result is successful.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 08:50:01 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 31 Oct 2016 08:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6841) Add backup service support
 for singleton services
In-Reply-To: <JIRA.12639294.1468871269000@Atlassian.JIRA>
References: <JIRA.12639294.1468871269000@Atlassian.JIRA>
	<JIRA.12639294.1468871269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639294.1468871269000.3362.1477918201138@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314115#comment-13314115 ] 

Paul Ferraro commented on WFLY-6841:
------------------------------------

Restating this jira as a bug, since apparently "Feature request" is too loaded.

> Add backup service support for singleton services
> -------------------------------------------------
>
>                 Key: WFLY-6841
>                 URL: https://issues.jboss.org/browse/WFLY-6841
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 10.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> Currently, singleton services are started on the primary node only - no service is started on the backup nodes.  We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes.  When a node is elected as the primary provider, we stop the backup service, and start the primary service.  Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 08:50:00 2016
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Mon, 31 Oct 2016 08:50:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7419) Add resteasy wadl as a module
In-Reply-To: <JIRA.12657858.1477767448000@Atlassian.JIRA>
References: <JIRA.12657858.1477767448000@Atlassian.JIRA>
	<JIRA.12657858.1477767448000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657858.1477767448000.3356.1477918200950@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314114#comment-13314114 ] 

Frank Langelage commented on WFLY-7419:
---------------------------------------

This just adds the module.
If you want to use it, in your REST application it's necessary to reference this module in your jboss-deployment-structure.xml:
{code:xml}
    <sub-deployment name="rs-sales.war">
        <dependencies>
            <module name="org.jboss.resteasy.resteasy-wadl"/>
        </dependencies>
    </sub-deployment>
{code}
and also add servlet mapping to your web.xml file:
{code:xml}
<web-app 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/web-app_3_1.xsd" version="3.1">
    <servlet>
        <servlet-name>WADL</servlet-name>
        <servlet-class>org.jboss.resteasy.wadl.ResteasyWadlServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>WADL</servlet-name>
        <url-pattern>/application.wadl</url-pattern>
    </servlet-mapping>
</web-app>
{code}


> Add resteasy wadl as a module
> -----------------------------
>
>                 Key: WFLY-7419
>                 URL: https://issues.jboss.org/browse/WFLY-7419
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: REST
>    Affects Versions: 10.1.0.Final, 11.0.0.Alpha1
>            Reporter: Frank Langelage
>            Assignee: Alessio Soldano
>             Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 08:51:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 31 Oct 2016 08:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6841) Add backup service support
 for singleton services
In-Reply-To: <JIRA.12639294.1468871269000@Atlassian.JIRA>
References: <JIRA.12639294.1468871269000@Atlassian.JIRA>
	<JIRA.12639294.1468871269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639294.1468871269000.3368.1477918260563@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-6841:
-------------------------------
    Issue Type: Bug  (was: Feature Request)


> Add backup service support for singleton services
> -------------------------------------------------
>
>                 Key: WFLY-6841
>                 URL: https://issues.jboss.org/browse/WFLY-6841
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> Currently, singleton services are started on the primary node only - no service is started on the backup nodes.  We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes.  When a node is elected as the primary provider, we stop the backup service, and start the primary service.  Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 08:51:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 31 Oct 2016 08:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6841) Singleton backup service
 cannot be overridden
In-Reply-To: <JIRA.12639294.1468871269000@Atlassian.JIRA>
References: <JIRA.12639294.1468871269000@Atlassian.JIRA>
	<JIRA.12639294.1468871269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12639294.1468871269000.3376.1477918260839@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-6841:
-------------------------------
    Summary: Singleton backup service cannot be overridden  (was: Add backup service support for singleton services)


> Singleton backup service cannot be overridden
> ---------------------------------------------
>
>                 Key: WFLY-6841
>                 URL: https://issues.jboss.org/browse/WFLY-6841
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> Currently, singleton services are started on the primary node only - no service is started on the backup nodes.  We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes.  When a node is elected as the primary provider, we stop the backup service, and start the primary service.  Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 08:53:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 31 Oct 2016 08:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7424) Singleton backup service
 cannot be overridden
In-Reply-To: <JIRA.12658089.1477918337000@Atlassian.JIRA>
References: <JIRA.12658089.1477918337000@Atlassian.JIRA>
	<JIRA.12658089.1477918337413@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658089.1477918337000.3392.1477918380368@Atlassian.JIRA>

Paul Ferraro created WFLY-7424:
----------------------------------

             Summary: Singleton backup service cannot be overridden
                 Key: WFLY-7424
                 URL: https://issues.jboss.org/browse/WFLY-7424
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 11.0.0.Alpha1


Currently, singleton services are started on the primary node only - no service is started on the backup nodes.  We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes.  When a node is elected as the primary provider, we stop the backup service, and start the primary service.  Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 09:31:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 31 Oct 2016 09:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1911) Port
 DeploymentScannerTestCase to upstream
In-Reply-To: <JIRA.12658058.1477910749000@Atlassian.JIRA>
References: <JIRA.12658058.1477910749000@Atlassian.JIRA>
	<JIRA.12658058.1477910749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658058.1477910749000.3766.1477920660319@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-7421 to WFCORE-1911:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-1911  (was: WFLY-7421)
    Component/s: Deployment Scanner
                 Test Suite
                     (was: Test Suite)


> Port DeploymentScannerTestCase to upstream
> ------------------------------------------
>
>                 Key: WFCORE-1911
>                 URL: https://issues.jboss.org/browse/WFCORE-1911
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Deployment Scanner, Test Suite
>            Reporter: Peter Palaga
>
> The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 09:31:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 31 Oct 2016 09:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1911) Port
 DeploymentScannerTestCase to upstream
In-Reply-To: <JIRA.12658058.1477910749000@Atlassian.JIRA>
References: <JIRA.12658058.1477910749000@Atlassian.JIRA>
	<JIRA.12658058.1477910749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658058.1477910749000.3771.1477920660511@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314141#comment-13314141 ] 

Brian Stansberry commented on WFCORE-1911:
------------------------------------------

I moved this to WFCORE because WildFly Core is where tests like this belong.

> Port DeploymentScannerTestCase to upstream
> ------------------------------------------
>
>                 Key: WFCORE-1911
>                 URL: https://issues.jboss.org/browse/WFCORE-1911
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Deployment Scanner, Test Suite
>            Reporter: Peter Palaga
>
> The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 09:36:00 2016
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 31 Oct 2016 09:36:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1911) Port
 DeploymentScannerTestCase to upstream
In-Reply-To: <JIRA.12658058.1477910749000@Atlassian.JIRA>
References: <JIRA.12658058.1477910749000@Atlassian.JIRA>
	<JIRA.12658058.1477910749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658058.1477910749000.3856.1477920960714@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314145#comment-13314145 ] 

Peter Palaga commented on WFCORE-1911:
--------------------------------------

> I moved this to WFCORE because WildFly Core is where tests like this belong.

Even though it is an Arquillian integration test?

> Port DeploymentScannerTestCase to upstream
> ------------------------------------------
>
>                 Key: WFCORE-1911
>                 URL: https://issues.jboss.org/browse/WFCORE-1911
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Deployment Scanner, Test Suite
>            Reporter: Peter Palaga
>
> The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 09:39:00 2016
From: issues at jboss.org (Stephen Fikes (JIRA))
Date: Mon, 31 Oct 2016 09:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7425) [GSS] (7.1.z) add per PU
 cache of the new temp classloader returned from
 PersistenceUnitMetadataImpl.getNewTempClassLoader()
In-Reply-To: <JIRA.12658104.1477921099000@Atlassian.JIRA>
References: <JIRA.12658104.1477921099000@Atlassian.JIRA>
	<JIRA.12658104.1477921099342@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658104.1477921099000.3867.1477921140162@Atlassian.JIRA>

Stephen Fikes created WFLY-7425:
-----------------------------------

             Summary: [GSS] (7.1.z) add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
                 Key: WFLY-7425
                 URL: https://issues.jboss.org/browse/WFLY-7425
             Project: WildFly
          Issue Type: Enhancement
          Components: JPA / Hibernate
            Reporter: Stephen Fikes
            Assignee: Scott Marlow


The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.

Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns.

Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnitInfo.html#getNewTempClassLoader--]
{quote}
ClassLoader getNewTempClassLoader()

Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.

Returns:
    temporary ClassLoader with same visibility as current loader 
{quote}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 09:47:01 2016
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 31 Oct 2016 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1911) Port
 DeploymentScannerTestCase to upstream
In-Reply-To: <JIRA.12658058.1477910749000@Atlassian.JIRA>
References: <JIRA.12658058.1477910749000@Atlassian.JIRA>
	<JIRA.12658058.1477910749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658058.1477910749000.4004.1477921621113@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman reassigned WFCORE-1911:
------------------------------------

    Assignee: Tomas Hofman


> Port DeploymentScannerTestCase to upstream
> ------------------------------------------
>
>                 Key: WFCORE-1911
>                 URL: https://issues.jboss.org/browse/WFCORE-1911
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Deployment Scanner, Test Suite
>            Reporter: Peter Palaga
>            Assignee: Tomas Hofman
>
> The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:05:00 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 31 Oct 2016 10:05:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7426) Attempt to remove cache
 container with default-cache defined throws NPE
In-Reply-To: <JIRA.12658123.1477922626000@Atlassian.JIRA>
References: <JIRA.12658123.1477922626000@Atlassian.JIRA>
	<JIRA.12658123.1477922626000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658123.1477922626000.4357.1477922700565@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved JBEAP-6743 to WFLY-7426:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7426  (was: JBEAP-6743)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Clustering
                           (was: Clustering)
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR7)


> Attempt to remove cache container with default-cache defined throws NPE
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7426
>                 URL: https://issues.jboss.org/browse/WFLY-7426
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Minor
>
> When I create a local cache as a child of some cache container and then set it to that cache container as its default cache, it is impossible to remove that cache container.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:05:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 31 Oct 2016 10:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7389) Improve undefined
 statistics-enabled attribute testing in infnispan subsystem for EAP 6.2
In-Reply-To: <JIRA.12657184.1477502615000@Atlassian.JIRA>
References: <JIRA.12657184.1477502615000@Atlassian.JIRA>
	<JIRA.12657184.1477502615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657184.1477502615000.4370.1477922701341@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7389:
---------------------------------
    Affects Version/s: 10.1.0.Final


> Improve undefined statistics-enabled attribute testing in infnispan subsystem for EAP 6.2
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-7389
>                 URL: https://issues.jboss.org/browse/WFLY-7389
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 10.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> The test file clustering/infinispan/extension/src/test/resources/org/jboss/as/clustering/infinispan/subsystem/infinispan-transformer-reject.xml specifies {code}statistics-enabled="false"{code} for all caches and cache-containers thus the situation when its undefined is never tested.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:05:01 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 31 Oct 2016 10:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7389) Improve undefined
 statistics-enabled attribute testing in infnispan subsystem for EAP 6.2
In-Reply-To: <JIRA.12657184.1477502615000@Atlassian.JIRA>
References: <JIRA.12657184.1477502615000@Atlassian.JIRA>
	<JIRA.12657184.1477502615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657184.1477502615000.4373.1477922701460@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7389:
---------------------------------
    Affects Version/s: 10.0.0.Final
                           (was: 10.1.0.Final)


> Improve undefined statistics-enabled attribute testing in infnispan subsystem for EAP 6.2
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-7389
>                 URL: https://issues.jboss.org/browse/WFLY-7389
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 10.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> The test file clustering/infinispan/extension/src/test/resources/org/jboss/as/clustering/infinispan/subsystem/infinispan-transformer-reject.xml specifies {code}statistics-enabled="false"{code} for all caches and cache-containers thus the situation when its undefined is never tested.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:05:01 2016
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Mon, 31 Oct 2016 10:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7427) CMTTxInterceptor transaction
	comparison
In-Reply-To: <JIRA.12658124.1477922695000@Atlassian.JIRA>
References: <JIRA.12658124.1477922695000@Atlassian.JIRA>
	<JIRA.12658124.1477922695569@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658124.1477922695000.4375.1477922701504@Atlassian.JIRA>

Tomasz Adamski created WFLY-7427:
------------------------------------

             Summary: CMTTxInterceptor transaction comparison
                 Key: WFLY-7427
                 URL: https://issues.jboss.org/browse/WFLY-7427
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 10.1.0.CR1
            Reporter: Tomasz Adamski
            Assignee: Tomasz Adamski






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:06:00 2016
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Mon, 31 Oct 2016 10:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7427) CMTTxInterceptor transaction
	comparison
In-Reply-To: <JIRA.12658124.1477922696000@Atlassian.JIRA>
References: <JIRA.12658124.1477922696000@Atlassian.JIRA>
	<JIRA.12658124.1477922696000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658124.1477922696000.4377.1477922760149@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski closed WFLY-7427.
--------------------------------
    Resolution: Duplicate Issue


> CMTTxInterceptor transaction comparison
> ---------------------------------------
>
>                 Key: WFLY-7427
>                 URL: https://issues.jboss.org/browse/WFLY-7427
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.CR1
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:06:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 31 Oct 2016 10:06:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7389) Improve undefined
 statistics-enabled attribute testing in infinispan subsystem for EAP 6.2
In-Reply-To: <JIRA.12657184.1477502615000@Atlassian.JIRA>
References: <JIRA.12657184.1477502615000@Atlassian.JIRA>
	<JIRA.12657184.1477502615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657184.1477502615000.4380.1477922760259@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7389:
---------------------------------
    Summary: Improve undefined statistics-enabled attribute testing in infinispan subsystem for EAP 6.2  (was: Improve undefined statistics-enabled attribute testing in infnispan subsystem for EAP 6.2)


> Improve undefined statistics-enabled attribute testing in infinispan subsystem for EAP 6.2
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7389
>                 URL: https://issues.jboss.org/browse/WFLY-7389
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 10.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> The test file clustering/infinispan/extension/src/test/resources/org/jboss/as/clustering/infinispan/subsystem/infinispan-transformer-reject.xml specifies {code}statistics-enabled="false"{code} for all caches and cache-containers thus the situation when its undefined is never tested.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:17:01 2016
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 31 Oct 2016 10:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7428) Add ExtendedJBossXATerminator
 service to the transactions subsystem
In-Reply-To: <JIRA.12658130.1477923417000@Atlassian.JIRA>
References: <JIRA.12658130.1477923417000@Atlassian.JIRA>
	<JIRA.12658130.1477923417777@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658130.1477923417000.4496.1477923421564@Atlassian.JIRA>

Gytis Trikleris created WFLY-7428:
-------------------------------------

             Summary: Add ExtendedJBossXATerminator service to the transactions subsystem
                 Key: WFLY-7428
                 URL: https://issues.jboss.org/browse/WFLY-7428
             Project: WildFly
          Issue Type: Enhancement
          Components: Transactions
            Reporter: Gytis Trikleris
            Assignee: Gytis Trikleris
             Fix For: 11.0.0.Alpha1


ExtendedJBossXATerminator from Narayana SPI is not currently injectable as a service. However, it is needed to check if the specific transaction is available in the server.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:23:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 31 Oct 2016 10:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7429)
 configurable-sasl-server-factory cannot set mechanism information
In-Reply-To: <JIRA.12658132.1477923741000@Atlassian.JIRA>
References: <JIRA.12658132.1477923741000@Atlassian.JIRA>
	<JIRA.12658132.1477923741114@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658132.1477923741000.4576.1477923781652@Atlassian.JIRA>

Jan Kalina created WFLY-7429:
--------------------------------

             Summary: configurable-sasl-server-factory cannot set mechanism information
                 Key: WFLY-7429
                 URL: https://issues.jboss.org/browse/WFLY-7429
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Jan Kalina
            Assignee: Jan Kalina


sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following factory in chain but with rewriting of the server name.
In this chain is also *SetMechanismInformationSaslServerFactory*, which call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.

*The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.

The chain of SaslServerFactories:
{code:java}
AuthenticationTimeoutSSF
TrustManagerSSF
AuthenticationCompleteSSF
SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
ServerNameSSF
ProtocolSSF
SetMechanismInformationSSF => cbh => "Too late to set" => return null
SecurityProviderSSF
{code}

Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:23:01 2016
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 31 Oct 2016 10:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-702)
 configurable-sasl-server-factory cannot set mechanism information
In-Reply-To: <JIRA.12658132.1477923741000@Atlassian.JIRA>
References: <JIRA.12658132.1477923741000@Atlassian.JIRA>
	<JIRA.12658132.1477923741000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658132.1477923741000.4586.1477923781928@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7429 to ELY-702:
--------------------------------------

        Project: WildFly Elytron  (was: WildFly)
            Key: ELY-702  (was: WFLY-7429)
    Component/s: Authentication Client
                     (was: Security)


> configurable-sasl-server-factory cannot set mechanism information
> -----------------------------------------------------------------
>
>                 Key: ELY-702
>                 URL: https://issues.jboss.org/browse/ELY-702
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> sasl-authentication-factory and sasl-server-factory creates chain of SaslServerFactories - for example ServerNameSaslServerFactory only delegates creating to following factory in chain but with rewriting of the server name.
> In this chain is also *SetMechanismInformationSaslServerFactory*, which call callback handler to send MechanismInformation into ServerAuthenticationContext - there it will cause state change from InactiveState to InitialState.
> *The problem is,* if the configurable-sasl-server-factory is used, the *SetMechanismInformationSaslServerFactory* is in chain twice. The first occurence (by sasl-authentication-factory) will cause change state to InitialState, but before the serverName+protocol is overriden by SaslServerFactories following in chain. The second occurence (by configurable-sasl-server-factory) already have serverName+protocol set, but because the ServerAuthenticationContext is already in InitialState, the exception "Too late to set" is thrown and createSaslServer returns null - fail completely.
> The chain of SaslServerFactories:
> {code:java}
> AuthenticationTimeoutSSF
> TrustManagerSSF
> AuthenticationCompleteSSF
> SetMechanismInformationSSF => cbh => InactiveState -> InitialState(undefined, null)
> ServerNameSSF
> ProtocolSSF
> SetMechanismInformationSSF => cbh => "Too late to set" => return null
> SecurityProviderSSF
> {code}
> Will have to discuss yet how to correctly solve this... (maybe consider allowing of multiple MechanismInformation setting? In current design the sasl-authentication-factory cannot detect the configurable-sasl-server-factory WILL change the MechanismInformation yet...)



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 10:40:01 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 31 Oct 2016 10:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1911) Port
 DeploymentScannerTestCase to upstream
In-Reply-To: <JIRA.12658058.1477910749000@Atlassian.JIRA>
References: <JIRA.12658058.1477910749000@Atlassian.JIRA>
	<JIRA.12658058.1477910749000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658058.1477910749000.4907.1477924801226@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314199#comment-13314199 ] 

Brian Stansberry commented on WFCORE-1911:
------------------------------------------

Yes. The initial test design shouldn't drive the structure of our test suite. Everything it does using Arquillian can be done using similar non-arquillian mechanisms available in core, e.g. WildFlyTestRunner. That's true for any @RunAsClient arquilian test.

> Port DeploymentScannerTestCase to upstream
> ------------------------------------------
>
>                 Key: WFCORE-1911
>                 URL: https://issues.jboss.org/browse/WFCORE-1911
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Deployment Scanner, Test Suite
>            Reporter: Peter Palaga
>            Assignee: Tomas Hofman
>
> The EAP 6.4.x PR https://github.com/jbossas/jboss-eap/pull/2669 added the DeploymentScannerTestCase silently without porting it to upstream, thus not fulfilling the "Upstream First" requirement. Note that https://github.com/jbossas/jboss-eap/pull/2800 updates DeploymentScannerTestCase.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:03:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 31 Oct 2016 11:03:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1912) Redeploy deployment if all
 missing dependencies for deployment are corrected
In-Reply-To: <JIRA.12657519.1477572269000@Atlassian.JIRA>
References: <JIRA.12657519.1477572269000@Atlassian.JIRA>
	<JIRA.12657519.1477572269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657519.1477572269000.5165.1477926180183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-7394 to WFCORE-1912:
------------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-1912  (was: WFLY-7394)
          Component/s: Server
                           (was: Server)
    Affects Version/s:     (was: 10.1.0.Final)


> Redeploy deployment if all missing dependencies for deployment are corrected 
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-1912
>                 URL: https://issues.jboss.org/browse/WFCORE-1912
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>
> If deployment failed to deploy and later all missing dependencies for deployment are corrected then deployment would redeploy automatically. This behavior could be configurable. 
> For example if you deploy EJB which injects queue like:
> {code}
> @Resource(mappedName = "java:/jms/queue/OutQueue")
> private Queue outQueue;
> {code}
> and administrator deploys queue later then EJB would automatically get redeployed. 



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:04:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 31 Oct 2016 11:04:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1912) Redeploy deployment if all
 missing dependencies for deployment are corrected
In-Reply-To: <JIRA.12657519.1477572269000@Atlassian.JIRA>
References: <JIRA.12657519.1477572269000@Atlassian.JIRA>
	<JIRA.12657519.1477572269000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657519.1477572269000.5182.1477926240722@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314212#comment-13314212 ] 

Brian Stansberry commented on WFCORE-1912:
------------------------------------------

Doesn't this already work if the rollback-on-runtime-failure=false operation header is used when the deployment is initially deployed? 

> Redeploy deployment if all missing dependencies for deployment are corrected 
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-1912
>                 URL: https://issues.jboss.org/browse/WFCORE-1912
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>            Reporter: Miroslav Novak
>            Assignee: Jason Greene
>
> If deployment failed to deploy and later all missing dependencies for deployment are corrected then deployment would redeploy automatically. This behavior could be configurable. 
> For example if you deploy EJB which injects queue like:
> {code}
> @Resource(mappedName = "java:/jms/queue/OutQueue")
> private Queue outQueue;
> {code}
> and administrator deploys queue later then EJB would automatically get redeployed. 



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:07:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Oct 2016 11:07:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4133) Hanging EJB threads because
 of a persistent timer and failed deployment
In-Reply-To: <JIRA.12558333.1417105718000@Atlassian.JIRA>
References: <JIRA.12558333.1417105718000@Atlassian.JIRA>
	<JIRA.12558333.1417105718000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558333.1417105718000.5204.1477926420260@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314215#comment-13314215 ] 

RH Bugzilla Integration commented on WFLY-4133:
-----------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1147948|https://bugzilla.redhat.com/show_bug.cgi?id=1147948] from POST to MODIFIED

> Hanging EJB threads because of a persistent timer and failed deployment 
> ------------------------------------------------------------------------
>
>                 Key: WFLY-4133
>                 URL: https://issues.jboss.org/browse/WFLY-4133
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Enrique Gonz?lez Mart?nez
>            Assignee: Enrique Gonz?lez Mart?nez
>             Fix For: 9.0.0.Beta1
>
>
> When there is a time service with pending timeouts a bad redeploy can hang worker threads in the server.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 11:14:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Oct 2016 11:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1407) Test coverage for syslog
	reconnection
In-Reply-To: <JIRA.12607486.1456303088000@Atlassian.JIRA>
References: <JIRA.12607486.1456303088000@Atlassian.JIRA>
	<JIRA.12607486.1456303088000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12607486.1456303088000.5326.1477926840963@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314223#comment-13314223 ] 

RH Bugzilla Integration commented on WFCORE-1407:
-------------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1311440|https://bugzilla.redhat.com/show_bug.cgi?id=1311440] from POST to MODIFIED

> Test coverage for syslog reconnection
> -------------------------------------
>
>                 Key: WFCORE-1407
>                 URL: https://issues.jboss.org/browse/WFCORE-1407
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 2.1.0.CR2
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Lukas
>             Fix For: 3.0.0.Alpha1
>
>
> Added test coverage for syslog reconnection issues - https://issues.jboss.org/browse/LOGMGR-123.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:16:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 31 Oct 2016 11:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1902) Error messages from CLI
 batch should be more informative
In-Reply-To: <JIRA.12657504.1477567805000@Atlassian.JIRA>
References: <JIRA.12657504.1477567805000@Atlassian.JIRA>
	<JIRA.12657504.1477567805000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657504.1477567805000.5346.1477926960354@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314225#comment-13314225 ] 

Brian Stansberry commented on WFCORE-1902:
------------------------------------------

Trying to figure out what line in a script sounds like more trouble than it is worth. If it's possible to report the batch step number and the operation invoked by that step, I think that would provide most of the value. Seeing that :readAttribute(name=nonsence) failed should provide enough insight to let people figure out what line in a script was at fault.

Side note: be cautious about using DMR syntax to report high level failures that aren't simply showing the output of the low level failure. AFAIK we don't do that elsewhere and it's probably not something we should do on a case by case basis without an overall strategy.

> Error messages from CLI batch should be more informative
> --------------------------------------------------------
>
>                 Key: WFCORE-1902
>                 URL: https://issues.jboss.org/browse/WFCORE-1902
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Error messages from CLI batch should be more informative
> *Steps to Reproduce:*
> {noformat}
> cat <<EOF >a
> batch
> :read-attribute(name=product-version)
> :read-attribute(name=product-name)
> :read-attribute(name=nonsence)
> :read-attribute(name=product-name)
> run-batch
> EOF
> ./jboss-cli.sh -c --file=a
> {noformat}
> *Actual results:*
> {noformat}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-3" => "WFLYCTL0201: Unknown attribute 'nonsence'"}}
> {noformat}
> *Expected results:*
> I can imagine content like following could be helpful for troubleshooting:
> {noformat}
> {
>    "WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {
>       "Operation step-3" => {
>          "line number" => 4
>          "operation" => ":read-attribute(name=nonsence)"
>          "response" => "WFLYCTL0201: Unknown attribute 'nonsence'"
>    }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 11:20:01 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 31 Oct 2016 11:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-695) Is impossible remove whole
 Elytron subsystem when Elytron resource depends on another Elytron
 resource.
In-Reply-To: <JIRA.12657545.1477576794000@Atlassian.JIRA>
References: <JIRA.12657545.1477576794000@Atlassian.JIRA>
	<JIRA.12657545.1477576794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657545.1477576794000.5409.1477927201633@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314232#comment-13314232 ] 

Brian Stansberry commented on ELY-695:
--------------------------------------

I don't know if this is relevant, but please see description of WFCORE-1106 in case it is.

> Is impossible remove whole Elytron subsystem when Elytron resource depends on another Elytron resource.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-695
>                 URL: https://issues.jboss.org/browse/ELY-695
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store, KeyStores
>            Reporter: Hynek ?v?bek
>            Assignee: Darran Lofthouse
>
> Is impossible remove whole Elytron subsystem by one command when Elytron resource depends on another Elytron resource.
> *Scenario:*
> * I have KeyStore in Elytron subsystem with CredentialStoreReference set to CredentialStore
> * I want to delete whole Elytron subsystem
> * I execute this CLI command */subsystem=elytron:remove()* and get error
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service org.wildfly.security.credential-store-client.credStore was depended upon by service org.wildfly.security.key-store.firefly",
>     "rolled-back" => true
> }
> {code}
> *NOTES:*
> * When I perform CLI command */subsystem=elytron:remove()* again as it passes.
> * When I use for remove {allow-resource-service-restart=true} as /subsystem=elytron:remove(){allow-resource-service-restart=true} then result is successful.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 11:23:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 31 Oct 2016 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7430) Typo in thread-pool resource
	description
In-Reply-To: <JIRA.12658143.1477927328000@Atlassian.JIRA>
References: <JIRA.12658143.1477927328000@Atlassian.JIRA>
	<JIRA.12658143.1477927328000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658143.1477927328000.5447.1477927380500@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins moved JBEAP-6746 to WFLY-7430:
--------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7430  (was: JBEAP-6746)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Batch
                           (was: Batch)
                           (was: User Experience)
    Affects Version/s:     (was: 7.1.0.DR7)


> Typo in thread-pool resource description
> ----------------------------------------
>
>                 Key: WFLY-7430
>                 URL: https://issues.jboss.org/browse/WFLY-7430
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Trivial
>
> /subsystem=batch-jberet/thread-pool=batch:read-resource-description()
> returns 
> "description" => "... be greaterthan 3..."
> Please split  'greaterthan' to 'greater than'



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:23:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 31 Oct 2016 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1913) Update management realm
 readiness checks to be backed by a function rather than a SecurityRealm
In-Reply-To: <JIRA.12658144.1477927371000@Atlassian.JIRA>
References: <JIRA.12658144.1477927371000@Atlassian.JIRA>
	<JIRA.12658144.1477927371952@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658144.1477927371000.5450.1477927380568@Atlassian.JIRA>

Darran Lofthouse created WFCORE-1913:
----------------------------------------

             Summary: Update management realm readiness checks to be backed by a function rather than a SecurityRealm
                 Key: WFCORE-1913
                 URL: https://issues.jboss.org/browse/WFCORE-1913
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha12






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:31:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Oct 2016 11:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7027) MBeans with ObjectName
 attributes throw ClassNotFoundException
In-Reply-To: <JIRA.12648009.1472680652000@Atlassian.JIRA>
References: <JIRA.12648009.1472680652000@Atlassian.JIRA>
	<JIRA.12648009.1472680652000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648009.1472680652000.5532.1477927860869@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314241#comment-13314241 ] 

RH Bugzilla Integration commented on WFLY-7027:
-----------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1372096|https://bugzilla.redhat.com/show_bug.cgi?id=1372096] from POST to MODIFIED

> MBeans with ObjectName attributes throw ClassNotFoundException
> --------------------------------------------------------------
>
>                 Key: WFLY-7027
>                 URL: https://issues.jboss.org/browse/WFLY-7027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 10.0.0.Final
>            Reporter: Dennis Reed
>            Assignee: Bartosz Baranowski
>             Fix For: 11.0.0.Alpha1
>
>
> An MBean with:
>     public void setObj(javax.management.ObjectName someObject)
>     <mbean ...>
>         <attribute name="Obj" />
> causes "java.lang.ClassNotFoundException: javax.management.MalformedObjectNameException from [Module \"org.jboss.common-beans:main\"
> org.jboss.common.beans.property.ObjectNameEditor in that module is used to convert to ObjectName objects, and requires MalformedObjectNameException but it is not on the classpath of that module.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:32:01 2016
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 31 Oct 2016 11:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7431) Convert stats-enabled metric
 into proper statistics-enabled attribute
In-Reply-To: <JIRA.12658145.1477927878000@Atlassian.JIRA>
References: <JIRA.12658145.1477927878000@Atlassian.JIRA>
	<JIRA.12658145.1477927878000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658145.1477927878000.5559.1477927921710@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved JBEAP-6747 to WFLY-7431:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-7431  (was: JBEAP-6747)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Clustering
                           (was: Clustering)
                           (was: User Experience)
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR7)


> Convert stats-enabled metric into proper statistics-enabled attribute
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7431
>                 URL: https://issues.jboss.org/browse/WFLY-7431
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Minor
>
> {code}
> /subsystem=jgroups/channel=ee:read-attribute(name=stats-enabled)
> {code}
> Other subsystems usually use attribute name {{statistics-enabled}}, we should deprecate the current attribute name and support the this unified attribute name. This is the case in the transaction subsystem. This issue is similar to JBEAP-6501.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:38:00 2016
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 31 Oct 2016 11:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1914) Test default CLI assignee
In-Reply-To: <JIRA.12658149.1477928234000@Atlassian.JIRA>
References: <JIRA.12658149.1477928234000@Atlassian.JIRA>
	<JIRA.12658149.1477928234791@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658149.1477928234000.5620.1477928280458@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-1914:
--------------------------------------------

             Summary: Test default CLI assignee
                 Key: WFCORE-1914
                 URL: https://issues.jboss.org/browse/WFCORE-1914
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:39:00 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Mon, 31 Oct 2016 11:39:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7432) KeyStore requires set
 CredentialReference which is optional.
In-Reply-To: <JIRA.12658151.1477928285000@Atlassian.JIRA>
References: <JIRA.12658151.1477928285000@Atlassian.JIRA>
	<JIRA.12658151.1477928285409@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658151.1477928285000.5647.1477928340425@Atlassian.JIRA>

Hynek ?v?bek created WFLY-7432:
----------------------------------

             Summary: KeyStore requires set CredentialReference which is optional.
                 Key: WFLY-7432
                 URL: https://issues.jboss.org/browse/WFLY-7432
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Hynek ?v?bek
            Assignee: Darran Lofthouse


In EAP7.1.0.DR7 keystore uses credentialReference with clear-text attribute for password instead of password attribute.
But there is problem with credential reference element which is optional.

*Scenario:*
I want to create KeyStore with minimum required settings.
But this CLI command */subsystem=elytron/key-store=keyStore:add(type=JKS)* ends with error
{
    "outcome" => "failed",
    "failure-description" => {
        "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.org.jboss.as.controller.security.CredentialReference"],
        "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.keyStore is missing [org.wildfly.security.credential-store-client.org.jboss.as.controller.security.CredentialReference]"]
    },
    "rolled-back" => true
}

Resource description says this
{code}
"credential-reference" => {
                "type" => OBJECT,
                "description" => "The reference to credential stored in CredentialStore under defined alias or clear text password.",
                "expressions-allowed" => false,
                "nillable" => true,
                "value-type" => {
                    "store" => {
                        "type" => STRING,
                        "description" => "The name of the credential store holding the alias to credential.",
                        "expressions-allowed" => false,
                        "nillable" => true,
                        "min-length" => 1L,
                        "max-length" => 2147483647L
                    },
                    "alias" => {
                        "type" => STRING,
                        "description" => "The alias which denotes stored secret or credential in the store.",
                        "expressions-allowed" => false,
                        "nillable" => true,
                        "min-length" => 1L,
                        "max-length" => 2147483647L
                    },
                    "type" => {
                        "type" => STRING,
                        "description" => "The type of credential this reference is denoting.",
                        "expressions-allowed" => false,
                        "nillable" => true,
                        "min-length" => 1L,
                        "max-length" => 2147483647L
                    },
                    "clear-text" => {
                        "type" => STRING,
                        "description" => "Secret specified using clear text. Check credential store way of supplying credential/secrets to services.",
                        "expressions-allowed" => false,
                        "nillable" => true,
                        "min-length" => 1L,
                        "max-length" => 2147483647L
                    }
                },
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
{code}

*NOTE*
EAP7.1.0.DR6 works fine with "password" attribute.






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 11:40:01 2016
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Mon, 31 Oct 2016 11:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7432) KeyStore requires set
 CredentialReference which is optional.
In-Reply-To: <JIRA.12658151.1477928285000@Atlassian.JIRA>
References: <JIRA.12658151.1477928285000@Atlassian.JIRA>
	<JIRA.12658151.1477928285000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658151.1477928285000.5677.1477928401091@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek reassigned WFLY-7432:
----------------------------------

    Assignee: Peter Skopek  (was: Darran Lofthouse)


> KeyStore requires set CredentialReference which is optional.
> ------------------------------------------------------------
>
>                 Key: WFLY-7432
>                 URL: https://issues.jboss.org/browse/WFLY-7432
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> In EAP7.1.0.DR7 keystore uses credentialReference with clear-text attribute for password instead of password attribute.
> But there is problem with credential reference element which is optional.
> *Scenario:*
> I want to create KeyStore with minimum required settings.
> But this CLI command */subsystem=elytron/key-store=keyStore:add(type=JKS)* ends with error
> {
>     "outcome" => "failed",
>     "failure-description" => {
>         "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store-client.org.jboss.as.controller.security.CredentialReference"],
>         "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.key-store.keyStore is missing [org.wildfly.security.credential-store-client.org.jboss.as.controller.security.CredentialReference]"]
>     },
>     "rolled-back" => true
> }
> Resource description says this
> {code}
> "credential-reference" => {
>                 "type" => OBJECT,
>                 "description" => "The reference to credential stored in CredentialStore under defined alias or clear text password.",
>                 "expressions-allowed" => false,
>                 "nillable" => true,
>                 "value-type" => {
>                     "store" => {
>                         "type" => STRING,
>                         "description" => "The name of the credential store holding the alias to credential.",
>                         "expressions-allowed" => false,
>                         "nillable" => true,
>                         "min-length" => 1L,
>                         "max-length" => 2147483647L
>                     },
>                     "alias" => {
>                         "type" => STRING,
>                         "description" => "The alias which denotes stored secret or credential in the store.",
>                         "expressions-allowed" => false,
>                         "nillable" => true,
>                         "min-length" => 1L,
>                         "max-length" => 2147483647L
>                     },
>                     "type" => {
>                         "type" => STRING,
>                         "description" => "The type of credential this reference is denoting.",
>                         "expressions-allowed" => false,
>                         "nillable" => true,
>                         "min-length" => 1L,
>                         "max-length" => 2147483647L
>                     },
>                     "clear-text" => {
>                         "type" => STRING,
>                         "description" => "Secret specified using clear text. Check credential store way of supplying credential/secrets to services.",
>                         "expressions-allowed" => false,
>                         "nillable" => true,
>                         "min-length" => 1L,
>                         "max-length" => 2147483647L
>                     }
>                 },
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> {code}
> *NOTE*
> EAP7.1.0.DR6 works fine with "password" attribute.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)


From issues at jboss.org  Mon Oct 31 11:44:00 2016
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Mon, 31 Oct 2016 11:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7433) Upgrade HAL to 2.9.0.Alpha5
In-Reply-To: <JIRA.12658153.1477928595000@Atlassian.JIRA>
References: <JIRA.12658153.1477928595000@Atlassian.JIRA>
	<JIRA.12658153.1477928595764@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658153.1477928595000.5764.1477928640093@Atlassian.JIRA>

Harald Pehl created WFLY-7433:
---------------------------------

             Summary: Upgrade HAL to 2.9.0.Alpha5
                 Key: WFLY-7433
                 URL: https://issues.jboss.org/browse/WFLY-7433
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Harald Pehl
             Fix For: 11.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:44:00 2016
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Mon, 31 Oct 2016 11:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7433) Upgrade HAL to 2.9.0.Alpha5
In-Reply-To: <JIRA.12658153.1477928596000@Atlassian.JIRA>
References: <JIRA.12658153.1477928596000@Atlassian.JIRA>
	<JIRA.12658153.1477928596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658153.1477928596000.5766.1477928640131@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl updated WFLY-7433:
------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/9285)


> Upgrade HAL to 2.9.0.Alpha5
> ---------------------------
>
>                 Key: WFLY-7433
>                 URL: https://issues.jboss.org/browse/WFLY-7433
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:51:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 31 Oct 2016 11:51:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1836) Rejection-style transformer
 tests assume each operation generated by parser has distinct PathAddress
In-Reply-To: <JIRA.12634897.1466714467000@Atlassian.JIRA>
References: <JIRA.12634897.1466714467000@Atlassian.JIRA>
	<JIRA.12634897.1466714467000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12634897.1466714467000.5868.1477929060412@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFCORE-1836:
--------------------------------------

    Fix Version/s: 3.0.0.Alpha11
         Assignee: Radoslav Husar  (was: Brian Stansberry)
       Resolution: Done


> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1836
>                 URL: https://issues.jboss.org/browse/WFCORE-1836
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 3.0.0.Alpha11
>
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress.  This is fine when the subsystem's parser only generates add operations.  However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address.  If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 11:53:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 31 Oct 2016 11:53:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7434) Improve undefined
 statistics-enabled attribute testing in infinispan subsystem for EAP 6.2
In-Reply-To: <JIRA.12658155.1477929164000@Atlassian.JIRA>
References: <JIRA.12658155.1477929164000@Atlassian.JIRA>
	<JIRA.12658155.1477929164124@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658155.1477929164000.5877.1477929180181@Atlassian.JIRA>

Radoslav Husar created WFLY-7434:
------------------------------------

             Summary: Improve undefined statistics-enabled attribute testing in infinispan subsystem for EAP 6.2
                 Key: WFLY-7434
                 URL: https://issues.jboss.org/browse/WFLY-7434
             Project: WildFly
          Issue Type: Task
          Components: Clustering
    Affects Versions: 10.0.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
            Priority: Minor


The test file clustering/infinispan/extension/src/test/resources/org/jboss/as/clustering/infinispan/subsystem/infinispan-transformer-reject.xml specifies {code}statistics-enabled="false"{code} for all caches and cache-containers thus the situation when its undefined is never tested.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 12:24:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Oct 2016 12:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3549) Deadlock during shutdown
In-Reply-To: <JIRA.12544785.1403703306000@Atlassian.JIRA>
References: <JIRA.12544785.1403703306000@Atlassian.JIRA>
	<JIRA.12544785.1403703306000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544785.1403703306000.6072.1477931040803@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314272#comment-13314272 ] 

RH Bugzilla Integration commented on WFLY-3549:
-----------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1213817|https://bugzilla.redhat.com/show_bug.cgi?id=1213817] from POST to MODIFIED

> Deadlock during shutdown
> ------------------------
>
>                 Key: WFLY-3549
>                 URL: https://issues.jboss.org/browse/WFLY-3549
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.1.0.Final
>            Reporter: Dan Berindei
>            Assignee: David Lloyd
>             Fix For: 8.2.0.Final
>
>
> This deadlock appeared in an Arquillian test:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "undefined":
>   waiting to lock monitor 0x00007f67a421bfa8 (object 0x00000000e0700480, a org.jboss.as.threads.ScheduledThreadPoolService),
>   which is held by "MSC service thread 1-2"
> "MSC service thread 1-2":
>   waiting for ownable synchronizer 0x00000000e0700618, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
>   which is held by "undefined"
> Java stack information for the threads listed above:
> ===================================================
> "undefined":
> 	at org.jboss.as.threads.ScheduledThreadPoolService$ExecutorImpl.terminated(ScheduledThreadPoolService.java:121)
> 	- waiting to lock <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService)
> 	at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:704)
> 	at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1006)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1163)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:724)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> "MSC service thread 1-2":
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000e0700618> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> 	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> 	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> 	at java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:781)
> 	at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:695)
> 	at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1397)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor.shutdown(ScheduledThreadPoolExecutor.java:759)
> 	at org.jboss.as.threads.ManagedScheduledExecutorService.internalShutdown(ManagedScheduledExecutorService.java:53)
> 	at org.jboss.as.threads.ScheduledThreadPoolService.stop(ScheduledThreadPoolService.java:67)
> 	- locked <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService)
> 	at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> 	at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:724)
> Found 1 deadlock.
> {noformat}
> Looks like two MSC service threads exited and tried to terminate the thread pool at the same time. And because the MSC threads are not daemon threads, the entire JVM hangs and blocks the Arquillian test that was waiting for the container to shut down.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 12:42:00 2016
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 31 Oct 2016 12:42:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1892) Support rejection-style
 testing for capabilities-enabled subsystem in test framework
In-Reply-To: <JIRA.12656791.1477412943000@Atlassian.JIRA>
References: <JIRA.12656791.1477412943000@Atlassian.JIRA>
	<JIRA.12656791.1477412943000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656791.1477412943000.6170.1477932120242@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFCORE-1892:
-----------------------------------
    Description: 
Rejection-style transformer tests assumes each operation generated by parser can be executed on its own, outside of a batch This has been generally the case until introduction of capabilities. If a subsystem add operation references a capability introduced by subsequent add operations the rejection test cannot be bent over to pass. This is an issue of the test framework, during normal boot the operations are batched and this is not a problem.

An example of this can be found in the singleton subsystem:

/subsystem=singleton:add(default=mypolicy) 
/subsystem=singleton/singleton-policy=mypolicy:add(...)

So the test fails for the 1st parsed operation
{noformat}
{
    "operation" => "add",
    "address" => [("subsystem" => "singleton")],
    "default" => "simple"
}
{noformat}
with
{noformat}
java.lang.AssertionError: WFLYCTL0369: Required capabilities are not available:
    org.wildfly.clustering.singleton.policy.simple; There are no known registration points which can provide this capability.
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at org.jboss.as.model.test.ModelTestUtils.checkOutcome(ModelTestUtils.java:121)
	at org.jboss.as.model.test.ModelTestUtils.checkFailedTransformedBootOperations(ModelTestUtils.java:509)
	at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejections(SingletonTransformersTestCase.java:130)
	at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejectionsEAP700(SingletonTransformersTestCase.java:105)
{noformat}

I assume this will be more of a problem when testing EAP 7.2 to 7.1 transformations since there aren't many subsystems supporting capabilities in 7.0 apart from the singleton subsystem.

  was:
Rejection-style transformer tests assumes each operation generated by parser can be executed on its own, outside of a batch This has been generally the case until introduction of capabilities. If a subsystem add operation references a capability introduced by subsequent add operations the rejection test cannot be bent over to pass. This is an issue of the test framework, during normal boot the operations are batched and this is not a problem.

An example of this can be found in the singleton subsystem:

/subsystem=singleton:add(default=mypolicy) 
/subsystem=singleton/singleton-policy=mypolicy:add(...)

I assume this will be more of a problem when testing EAP 7.2 to 7.1 transformations since there aren't many subsystems supporting capabilities in 7.0 apart from the singleton subsystem.



> Support rejection-style testing for capabilities-enabled subsystem in test framework
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1892
>                 URL: https://issues.jboss.org/browse/WFCORE-1892
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 3.0.0.Alpha10
>            Reporter: Radoslav Husar
>            Assignee: Kabir Khan
>
> Rejection-style transformer tests assumes each operation generated by parser can be executed on its own, outside of a batch This has been generally the case until introduction of capabilities. If a subsystem add operation references a capability introduced by subsequent add operations the rejection test cannot be bent over to pass. This is an issue of the test framework, during normal boot the operations are batched and this is not a problem.
> An example of this can be found in the singleton subsystem:
> /subsystem=singleton:add(default=mypolicy) 
> /subsystem=singleton/singleton-policy=mypolicy:add(...)
> So the test fails for the 1st parsed operation
> {noformat}
> {
>     "operation" => "add",
>     "address" => [("subsystem" => "singleton")],
>     "default" => "simple"
> }
> {noformat}
> with
> {noformat}
> java.lang.AssertionError: WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.clustering.singleton.policy.simple; There are no known registration points which can provide this capability.
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.assertTrue(Assert.java:41)
> 	at org.jboss.as.model.test.ModelTestUtils.checkOutcome(ModelTestUtils.java:121)
> 	at org.jboss.as.model.test.ModelTestUtils.checkFailedTransformedBootOperations(ModelTestUtils.java:509)
> 	at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejections(SingletonTransformersTestCase.java:130)
> 	at org.wildfly.extension.clustering.singleton.SingletonTransformersTestCase.testRejectionsEAP700(SingletonTransformersTestCase.java:105)
> {noformat}
> I assume this will be more of a problem when testing EAP 7.2 to 7.1 transformations since there aren't many subsystems supporting capabilities in 7.0 apart from the singleton subsystem.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 13:24:00 2016
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 31 Oct 2016 13:24:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7418) Batch deployments with a
 large number of executed jobs can lock up or slow down the web console
In-Reply-To: <JIRA.12657844.1477695275000@Atlassian.JIRA>
References: <JIRA.12657844.1477695275000@Atlassian.JIRA>
	<JIRA.12657844.1477695275000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657844.1477695275000.6543.1477934640085@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314307#comment-13314307 ] 

James Perkins commented on WFLY-7418:
-------------------------------------

Excellent, thanks! The web workers approach does look interesting. I assume an approach like that would benefit from having some kind of description on the resource indicating it may be a slow runtime resource.

> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7418
>                 URL: https://issues.jboss.org/browse/WFLY-7418
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Batch, Web Console
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 13:28:01 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Oct 2016 13:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1198) CLI does not resolve
 multiple properties if one property is undefined
In-Reply-To: <JIRA.12595887.1449653400000@Atlassian.JIRA>
References: <JIRA.12595887.1449653400000@Atlassian.JIRA>
	<JIRA.12595887.1449653400000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12595887.1449653400000.6574.1477934881158@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314309#comment-13314309 ] 

RH Bugzilla Integration commented on WFCORE-1198:
-------------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1289316|https://bugzilla.redhat.com/show_bug.cgi?id=1289316] from POST to MODIFIED

> CLI does not resolve multiple properties if one property is undefined
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-1198
>                 URL: https://issues.jboss.org/browse/WFCORE-1198
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 2.0.4.Final
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 2.0.5.Final
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1289316 description:
> {noformat}
> Multiple property substitution is working with EAP 6.4.3+, however, if a variable amongst the multiple variables is empty or has no value, then the subsequent property in the CLI command is not substituted. 
> For example : 
> cat props.properties 
> -----------------------------------------
> PROFILE-NAME=TestProfile
> SERVER-INSTANCE-NUMBER=TestInstance
> APP-VERSION=
> VAR=test
> -----------------------------------------
> cat test.cli :
> ---------------------------------------
> /host=master/server-config=${PROFILE-NAME}${APP-VERSION}${SERVER-INSTANCE-NUMBER}${VAR}:add(auto-start=true, group="${PROFILE-NAME}${APP-VERSION}-server-group")
> ---------------------------------------
> and if I execute "./jboss-cli.sh --connect --file=test.cli --properties=props.properties" then I have the following in the host.xml ": 
> ----------
> ...
> <server name="TestProfile${SERVER-INSTANCE-NUMBER}test" group="TestProfile-server-group" auto-start="true"/>
> ...
> -----------
> Note APP-VERSION had no value, and so the subsequent SERVER-INSTANCE-NUMBER was not properly resolved
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 15:25:00 2016
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 31 Oct 2016 15:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1915)
 ParseUtils.parseAttributeValue should not fail due to DMR type conversions
In-Reply-To: <JIRA.12658181.1477941894000@Atlassian.JIRA>
References: <JIRA.12658181.1477941894000@Atlassian.JIRA>
	<JIRA.12658181.1477941894725@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658181.1477941894000.7125.1477941900073@Atlassian.JIRA>

Brian Stansberry created WFCORE-1915:
----------------------------------------

             Summary: ParseUtils.parseAttributeValue should not fail due to DMR type conversions
                 Key: WFCORE-1915
                 URL: https://issues.jboss.org/browse/WFCORE-1915
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 3.0.0.Alpha11
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 3.0.0.Alpha12


The task of ParseUtils.parseAttributeValue is to convert a string into a ModelNode. The type of the ModelNode is not particularly important, as later code will do type conversion. And, it is *not* the job of this method to do validation; there is other code that does that. So, the type conversion this method does should not be allowed to produce failures. Continuing to try the conversion is ok, although not required, but if a conversion can't succeed the pre-conversion ModelType.STRING node should be returned.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 15:31:00 2016
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 31 Oct 2016 15:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (ELY-703) Introduce LegacyConfiguration
 SPI in client auth package
In-Reply-To: <JIRA.12658183.1477942232000@Atlassian.JIRA>
References: <JIRA.12658183.1477942232000@Atlassian.JIRA>
	<JIRA.12658183.1477942232924@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658183.1477942232000.7160.1477942260241@Atlassian.JIRA>

David Lloyd created ELY-703:
-------------------------------

             Summary: Introduce LegacyConfiguration SPI in client auth package
                 Key: ELY-703
                 URL: https://issues.jboss.org/browse/ELY-703
             Project: WildFly Elytron
          Issue Type: Task
          Components: Authentication Client
            Reporter: David Lloyd


If no client-configuration section is found for Elytron's client configuration, there should be a fallback SPI using java.util.ServiceLoader to allow the legacy EJB client to inject a client configuration.  The service interface should yield an AuthenticationContext.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 16:29:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Oct 2016 16:29:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-102) Remove the need for OSH
 authors to deal with ServiceVerificationHandler or removal of installed
 services in rollback
In-Reply-To: <JIRA.12552219.1410805540000@Atlassian.JIRA>
References: <JIRA.12552219.1410805540000@Atlassian.JIRA>
	<JIRA.12552219.1410805540000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552219.1410805540000.7282.1477945740365@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314368#comment-13314368 ] 

RH Bugzilla Integration commented on WFCORE-102:
------------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1299102|https://bugzilla.redhat.com/show_bug.cgi?id=1299102] from POST to MODIFIED

> Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-102
>                 URL: https://issues.jboss.org/browse/WFCORE-102
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 1.0.0.Alpha9
>
>
> The various base classes OSH authors use to create handlers force the author to deal with ServiceVerificationHandler and, during rollback, with removing any services the OSH added. This task is to have the OperationContext handle these things transparently, removing the need for authors to do so.
> To preserve compatibility, the various API methods authors may have overridden that expose the SVH and the list of added ServiceControllers will be retained (but deprecated), but the SVH and the list of handlers won't be used. The API javadoc will encourage use of method variants that don't use these parameters.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 16:53:01 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 31 Oct 2016 16:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6935) CMTTxInterceptor transaction
	comparison
In-Reply-To: <JIRA.12642666.1470772077000@Atlassian.JIRA>
References: <JIRA.12642666.1470772077000@Atlassian.JIRA>
	<JIRA.12642666.1470772077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642666.1470772077000.7393.1477947181138@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reopened WFLY-6935:
------------------------------


I am not sure why this was closed and marked as done? There is a PR for it, which I am merging now, so I am reopening and resolving for 11.0.0.Alpha1. Once that release is out the issue gets closed

> CMTTxInterceptor transaction comparison
> ---------------------------------------
>
>                 Key: WFLY-6935
>                 URL: https://issues.jboss.org/browse/WFLY-6935
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.CR1
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 16:54:00 2016
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 31 Oct 2016 16:54:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6935) CMTTxInterceptor transaction
	comparison
In-Reply-To: <JIRA.12642666.1470772077000@Atlassian.JIRA>
References: <JIRA.12642666.1470772077000@Atlassian.JIRA>
	<JIRA.12642666.1470772077000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12642666.1470772077000.7397.1477947240443@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-6935.
------------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Done


> CMTTxInterceptor transaction comparison
> ---------------------------------------
>
>                 Key: WFLY-6935
>                 URL: https://issues.jboss.org/browse/WFLY-6935
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.CR1
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 18:14:00 2016
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 31 Oct 2016 18:14:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-119) Where a username and
 credential are supplied accept the default realm
In-Reply-To: <JIRA.12657815.1477674129000@Atlassian.JIRA>
References: <JIRA.12657815.1477674129000@Atlassian.JIRA>
	<JIRA.12657815.1477674129000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657815.1477674129000.7596.1477952040461@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-119.
-------------------------------------
    Resolution: Done


> Where a username and credential are supplied accept the default realm
> ---------------------------------------------------------------------
>
>                 Key: REMJMX-119
>                 URL: https://issues.jboss.org/browse/REMJMX-119
>             Project: Remoting JMX
>          Issue Type: Enhancement
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha3
>
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 18:20:00 2016
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 31 Oct 2016 18:20:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-121) Ensure anonymous
 authentication will only be used if a callback handler has not been
 specified and no credentials have been provided
In-Reply-To: <JIRA.12658197.1477952355000@Atlassian.JIRA>
References: <JIRA.12658197.1477952355000@Atlassian.JIRA>
	<JIRA.12658197.1477952355487@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658197.1477952355000.7612.1477952400068@Atlassian.JIRA>

Farah Juma created REMJMX-121:
---------------------------------

             Summary: Ensure anonymous authentication will only be used if a callback handler has not been specified and no credentials have been provided
                 Key: REMJMX-121
                 URL: https://issues.jboss.org/browse/REMJMX-121
             Project: Remoting JMX
          Issue Type: Bug
          Components: Security
            Reporter: Farah Juma
            Assignee: Farah Juma






--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 18:25:00 2016
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 31 Oct 2016 18:25:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3578) jboss-cli.bat always exits
 with return code 0 even after a cli failure
In-Reply-To: <JIRA.12545477.1404376956000@Atlassian.JIRA>
References: <JIRA.12545477.1404376956000@Atlassian.JIRA>
	<JIRA.12545477.1404376956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545477.1404376956000.7633.1477952700252@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13314399#comment-13314399 ] 

RH Bugzilla Integration commented on WFLY-3578:
-----------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1223877|https://bugzilla.redhat.com/show_bug.cgi?id=1223877] from POST to MODIFIED

> jboss-cli.bat always exits with return code 0 even after a cli failure
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3578
>                 URL: https://issues.jboss.org/browse/WFLY-3578
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.1.0.Final
>         Environment: Windows
>            Reporter: Gabriele Garuglieri
>            Assignee: Alexey Loubyansky
>             Fix For: 9.0.0.Alpha1
>
>
> jboss-cli.bat cannot be reliably controlled by other scripts because it does not report return code from cli execution and  always exits with 0 even after a failure.
> It can be solved with the following patch:
> {noformat}
> --- C:/home/JBoss/wildfly-8.1.0.Final/bin/jboss-cli-orig.bat	Sat May 31 04:54:25 2014
> +++ C:/home/JBoss/wildfly-8.1.0.Final/bin/jboss-cli.bat	Thu Jul 03 10:19:09 2014
> @@ -1,4 +1,5 @@
>  @echo off
> +setlocal ENABLEEXTENSIONS
>  rem -------------------------------------------------------------------------
>  rem JBoss Admin CLI Script for Windows
>  rem -------------------------------------------------------------------------
> @@ -48,6 +49,7 @@
>  if not exist "%JBOSS_RUNJAR%" (
>    echo Could not locate "%JBOSS_RUNJAR%".
>    echo Please check that you are in the bin directory when running this script.
> +  set /A RC=1
>    goto END
>  )
>  
> @@ -71,5 +73,11 @@
>       org.jboss.as.cli ^
>       %*
>  
> +set /A RC=%errorlevel%
>  :END
>  if "x%NOPAUSE%" == "x" pause
> +
> +if "x%RC%" == "x" (
> +  set /A RC=0
> +)
> +exit /B %RC%
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

From issues at jboss.org  Mon Oct 31 21:11:00 2016
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 31 Oct 2016 21:11:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-121) Ensure anonymous
 authentication will only be used if a callback handler has not been
 specified and no credentials have been provided
In-Reply-To: <JIRA.12658197.1477952355000@Atlassian.JIRA>
References: <JIRA.12658197.1477952355000@Atlassian.JIRA>
	<JIRA.12658197.1477952355000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12658197.1477952355000.63.1477962660127@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated REMJMX-121:
------------------------------
    Git Pull Request: https://github.com/jbossas/remoting-jmx/pull/24


> Ensure anonymous authentication will only be used if a callback handler has not been specified and no credentials have been provided
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: REMJMX-121
>                 URL: https://issues.jboss.org/browse/REMJMX-121
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Security
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>




--
This message was sent by Atlassian JIRA
(v7.2.2#72004)

