[JBoss JIRA] (WFLY-9079) Check style plugin should not run on generated sources
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9079?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9079:
---------------------------------
Description:
{noformat}
[INFO] --- maven-checkstyle-plugin:2.17:checkstyle (check-style) @ batch-processing ---
[INFO] Starting audit...
[ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:11:1: Line contains a tab character. [FileTabCharacter]
[ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:12:1: Line contains a tab character. [FileTabCharacter]
[ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:13:1: Line contains a tab character. [FileTabCharacter]
{noformat}
was:
{format}
[INFO] --- maven-checkstyle-plugin:2.17:checkstyle (check-style) @ batch-processing ---
[INFO] Starting audit...
[ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:11:1: Line contains a tab character. [FileTabCharacter]
[ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:12:1: Line contains a tab character. [FileTabCharacter]
[ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:13:1: Line contains a tab character. [FileTabCharacter]
{format}
> Check style plugin should not run on generated sources
> ------------------------------------------------------
>
> Key: WFLY-9079
> URL: https://issues.jboss.org/browse/WFLY-9079
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Quickstarts
> Reporter: Radoslav Husar
> Assignee: Tomaz Cerar
>
> {noformat}
> [INFO] --- maven-checkstyle-plugin:2.17:checkstyle (check-style) @ batch-processing ---
> [INFO] Starting audit...
> [ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:11:1: Line contains a tab character. [FileTabCharacter]
> [ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:12:1: Line contains a tab character. [FileTabCharacter]
> [ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:13:1: Line contains a tab character. [FileTabCharacter]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9079) Check style plugin should not run on generated sources
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-9079:
------------------------------------
Summary: Check style plugin should not run on generated sources
Key: WFLY-9079
URL: https://issues.jboss.org/browse/WFLY-9079
Project: WildFly
Issue Type: Component Upgrade
Components: Quickstarts
Reporter: Radoslav Husar
Assignee: Tomaz Cerar
{format}
[INFO] --- maven-checkstyle-plugin:2.17:checkstyle (check-style) @ batch-processing ---
[INFO] Starting audit...
[ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:11:1: Line contains a tab character. [FileTabCharacter]
[ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:12:1: Line contains a tab character. [FileTabCharacter]
[ERROR] /Users/rhusar/git/wildfly-quickstarts/batch-processing/target/generated-sources/annotations/org/jboss/as/quickstarts/batch/model/Contact_.java:13:1: Line contains a tab character. [FileTabCharacter]
{format}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9078) No caller principal in new thread created from EJB (elytron)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-9078?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved JBEAP-12091 to WFLY-9078:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9078 (was: JBEAP-12091)
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.ER2)
> No caller principal in new thread created from EJB (elytron)
> ------------------------------------------------------------
>
> Key: WFLY-9078
> URL: https://issues.jboss.org/browse/WFLY-9078
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> When elytron profile of testsuite enabled, *DefaultManagedThreadFactoryTestCase* fails, because caller principal is not passed into new thread:
> {code}
> java.lang.IllegalStateException: the caller principal anonymous is not the expected guest
> (TestEJBRunnable.java:70)
> {code}
> Lets have:
> {code}
> new InitialContext().lookup("java:comp/EJBContext").getCallerPrincipal()
> {code}
> * On *DefaultManagedThreadFactoryTestEJB:63* (in EJB, but outside of new thread yet) it gives correctly "guest".
> * On *DefaultManagedThreadFactoryTestEJB:70* (inside Runnable) it gives "anonymous".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-3061) On Windows, when running standalone/Domain with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3061?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-3061:
------------------------------------
moved to the WFCORE project since the fix is there.
> On Windows, when running standalone/Domain with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3061
> URL: https://issues.jboss.org/browse/WFCORE-3061
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Environment: Windows
> Reporter: Durgesh Anaokar
> Assignee: Durgesh Anaokar
> Priority: Minor
> Fix For: 3.0.0.Beta29
>
>
> On Windows 7, when running standalone.bat with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.
> On line 177 of the standalone.bat, a check is made to see if the JAVA_HOME variable points to a valid directory. If it does, it assumes this directory contains bin\java. If bin\java does not exist, the server fails to start and does not give a reason why.
> expect to see an error message such as "%JAVA_HOME% path doesn't contain an executable at %JAVA_HOME%\bin\java"
> Add additional checks in the standalone.conf to verify that %JAVA_HOME%\bin\java exists and warn if it does not.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-3061) On Windows, when running standalone/Domain with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3061?page=com.atlassian.jira.plugi... ]
Kabir Khan moved WFLY-8910 to WFCORE-3061:
------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3061 (was: WFLY-8910)
Component/s: Scripts
(was: Scripts)
Affects Version/s: (was: 11.0.0.Alpha1)
> On Windows, when running standalone/Domain with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3061
> URL: https://issues.jboss.org/browse/WFCORE-3061
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Environment: Windows
> Reporter: Durgesh Anaokar
> Assignee: Durgesh Anaokar
> Priority: Minor
>
> On Windows 7, when running standalone.bat with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.
> On line 177 of the standalone.bat, a check is made to see if the JAVA_HOME variable points to a valid directory. If it does, it assumes this directory contains bin\java. If bin\java does not exist, the server fails to start and does not give a reason why.
> expect to see an error message such as "%JAVA_HOME% path doesn't contain an executable at %JAVA_HOME%\bin\java"
> Add additional checks in the standalone.conf to verify that %JAVA_HOME%\bin\java exists and warn if it does not.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JGRP-2203) ASYM_ENCRYPT: no merge when coord is killed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2203?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2203 at 7/12/17 7:28 AM:
---------------------------------------------------------
A similar issue exists when we have \{A,B,C\} and C leaves gracefully and {{change_key_on_leave}} is true.
* A creates a new secret key, encrypts view \{A,B\} and broadcasts it.
* B drops the view because it cannot decrypt it.
* B then asks A for the secret key
* A sends the new secret key to B
* B is now able to decrypt the (retransmitted) view \{A,B\}
Perhaps the common solution for this issue and the issue described above is to have the coordinator send a {{FETCH_SECRET_KEY}} message to all members so they fetch the new secret key via the key exchange protocol.
Unit test: {{ASYM_ENCRYPT_Test.testLeaveOfParticipant()}}
was (Author: belaban):
A similar issue exists when we have \{A,B,C\} and C leaves gracefully and {{change_key_on_leave}} is true.
* A creates a new secret key, encrypts view \{A,B\} and broadcasts it.
* B drops the view because it cannot decrypt it.
* B then asks A for the secret key
* A sends the new secret key to B
* B is now able to decrypt the (retransmitted) view \{A,B\}
Perhaps the common solution for this issue and the issue described above is to have the coordinator send a {{FETCH_SECRET_KEY}} message to all members so they fetch the new secret key via the key exchange protocol.
> ASYM_ENCRYPT: no merge when coord is killed
> -------------------------------------------
>
> Key: JGRP-2203
> URL: https://issues.jboss.org/browse/JGRP-2203
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.5
>
> Attachments: asym-encrypt.xml
>
>
> When we have \{A,B,C\} and A is killed, B and C never end up with the same view. (This works when A leaves gracefully).
> The sample config is attached as asym-encrypt.xml
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JGRP-2203) ASYM_ENCRYPT: no merge when coord is killed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2203?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2203 at 7/12/17 7:22 AM:
---------------------------------------------------------
The reason is that B as new coord creates a new shared secret and uses it to encrypt and send view \{B,C\}. However, as C doesn't yet have the new shared secret, it won't be able to install the new view.
Not getting the view change, C won't know that B is the new key server (it still thinks A is) and therefore C won't ask B for the new shared key.
Unit test: {{ASYM_ENCRYPT_Test.testCrashOfCoord}}
Possible solutions:
* Have B encrypt and send the new view with the existing shared key, and change the shared key only after the view installation
* Notify everyone of the new key server; this would trigger key fetching from all members. Since such a notification message is sent below the reliable transmission protocols (NAKACK2, UNICAST3), we'd have to send until getting an ack from everyone (kind of like simplistic reliable transmission).
was (Author: belaban):
The reason is that B as new coord creates a new shared secret and uses it to encrypt and send view \{B,C\}. However, as C doesn't yet have the new shared secret, it won't be able to install the new view.
Not getting the view change, C won't know that B is the new key server (it still thinks A is) and therefore C won't ask B for the new shared key.
Possible solutions:
* Have B encrypt and send the new view with the existing shared key, and change the shared key only after the view installation
* Notify everyone of the new key server; this would trigger key fetching from all members. Since such a notification message is sent below the reliable transmission protocols (NAKACK2, UNICAST3), we'd have to send until getting an ack from everyone (kind of like simplistic reliable transmission).
> ASYM_ENCRYPT: no merge when coord is killed
> -------------------------------------------
>
> Key: JGRP-2203
> URL: https://issues.jboss.org/browse/JGRP-2203
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.5
>
> Attachments: asym-encrypt.xml
>
>
> When we have \{A,B,C\} and A is killed, B and C never end up with the same view. (This works when A leaves gracefully).
> The sample config is attached as asym-encrypt.xml
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months