[JBoss JIRA] (WFLY-13823) Windows Service Script stopping problems
by Martin Miller (Jira)
Martin Miller created WFLY-13823:
------------------------------------
Summary: Windows Service Script stopping problems
Key: WFLY-13823
URL: https://issues.redhat.com/browse/WFLY-13823
Project: WildFly
Issue Type: Bug
Components: Scripts
Affects Versions: 20.0.1.Final
Reporter: Martin Miller
I'm trying to have two standalone instances running at the same time, and I think it works.
The problem is that stopping service 2 stops service 1 and service 2 seems to be stuck as far as windows is concerned.
I then have to kill java to be back to a normal state.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-5106) Add configuration option in Elytron subsystem to change file encoding in FileAuditEndpoint.
by Ilia Vassilev (Jira)
[ https://issues.redhat.com/browse/WFCORE-5106?page=com.atlassian.jira.plug... ]
Ilia Vassilev updated WFCORE-5106:
----------------------------------
Description:
Add configuration option in Elytron subsystem to change file encoding in FileAuditEndpoint introduced by ELY-1211.
Add "encoding" attribute to "file-audit-log", "periodic-rotating-file-audit-log" and "size-rotating-file-audit-log" elements in Elytron subsystem to utilize the new feature introduced by ELY-1211.
was:Add configuration option in Elytron subsystem to change file encoding in FileAuditEndpoint introduced by ELY-1211.
> Add configuration option in Elytron subsystem to change file encoding in FileAuditEndpoint.
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-5106
> URL: https://issues.redhat.com/browse/WFCORE-5106
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Major
>
> Add configuration option in Elytron subsystem to change file encoding in FileAuditEndpoint introduced by ELY-1211.
> Add "encoding" attribute to "file-audit-log", "periodic-rotating-file-audit-log" and "size-rotating-file-audit-log" elements in Elytron subsystem to utilize the new feature introduced by ELY-1211.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13679) Make legacy security optional for "org.wildfly.iiop-openjdk"
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13679?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13679:
-----------------------------------------
I've been poking a bit and I see four things to look into, although there may be more:
1) The module depends on org.jboss.as.security, which afaict is not necessary. If so that's an easy fix.
2) If the 'security-domain' attribute is set, then the legacy security domain from the legacy security subsystem is required. But there is a proper capability reference there, so that should be fine. The LegacySSLSocketFactory use of org.jboss.security (i.e. picketbox) would only come into play if that attribute is set, so *that use* of picketbox could be marked as optional.
3) TrustedIdentityTokenLoginModule uses picketbox but AFAICT that class is unused and can be removed, so it doesn't drove a non-optional dep on the picketbox module.
4) The problematic bit is SASClientIdentityInterceptor which uses Picketbox. AFAICT it is used if the 'security' attribute is set to 'identity'. That is not the default value for the AttributeDefinition, but it is the standard value in our configuration, and any iiop layer that uses the standard 'iiop-openjdk' feature-group would also set that value. I think that would be wrong for a layer, as any such layer would be required to depend on the legacy security subsystem to function properly, I believe. If 'identity' was not a default value nor a standard value then perhaps the module.xml could treat the org.picketbox module dependency as optional. Galleon has no hook to ensure legacy security is provisioned though if the user sets the value to 'identity'.
> Make legacy security optional for "org.wildfly.iiop-openjdk"
> ------------------------------------------------------------
>
> Key: WFLY-13679
> URL: https://issues.redhat.com/browse/WFLY-13679
> Project: WildFly
> Issue Type: Sub-task
> Components: IIOP, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> The dependency needs to optional so provisioning a layer with iiop-openjdk does not automatically pull in legacy security.
> This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional.
> This needs to consider:
> * Default Configuration
> * User Defined Configuration
> Both of these can have different consequences depending on of they are used for:
> * Resource defined services
> * DeploymentUnitProcessor processing
> iiop-openjdk module.xml: https://github.com/wildfly/wildfly/blob/master/ee-feature-pack/common/src...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFWIP-346) Bootable JAR - Second bootable JAR fails to package if first uses certain layers
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-346?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFWIP-346:
--------------------------------------------
[~jkasik], very good catch! We have a unwanted JBoss module classes sharing between executions. I have fixed it in this branch, could you give it a try: [https://github.com/jfdenise/wildfly-jar-maven-plugin/tree/WFWIP-346]
Thank-you. Again excellent finding!
> Bootable JAR - Second bootable JAR fails to package if first uses certain layers
> --------------------------------------------------------------------------------
>
> Key: WFWIP-346
> URL: https://issues.redhat.com/browse/WFWIP-346
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Jan Kasik
> Assignee: Jean Francois Denise
> Priority: Critical
>
> See the reproducer: https://github.com/honza-kasik/layer-conflict - there are two Maven modules, each configured to run WildFly Maven JAR plugin.
> If I run {{mvn clean package -Dversion.org.wildfly.jar.plugin=2.0.0.Beta3}}, bootable JAR for app-one builds but for app-two the build ends up with an error and app-two fails to package:
> {noformat}
> [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-jar-maven-plugin:2.0.0.Beta3:package (default) on project app-two: Provisioning failed: Failed to generate standalone.xml on {
> [ERROR] "operation" => "composite",
> [ERROR] "address" => [],
> [ERROR] "rollback-on-runtime-failure" => true,
> [ERROR] "steps" => [
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("interface" => "public")],
> [ERROR] "inet-address" => "${jboss.bind.address:127.0.0.1}"
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.wildfly.extension.bean-validation")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.weld")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.naming")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.ee")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.wildfly.extension.io")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.wildfly.extension.undertow")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.jaxrs")]
> [ERROR] }
> [ERROR] ]
> [ERROR] }: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-8" => "WFLYCTL0310: Extension module org.jboss.as.jaxrs not found"}}
> {noformat}
> Packaging when running {{mvn clean install -Dversion.org.wildfly.jar.plugin=2.0.0.Beta3 -pl app-two}} ends with success. Same for {{app-one}} only.
> If I replace layers in app-one with layer {{cloud-server}} both modules build successfully.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFWIP-346) Bootable JAR - Second bootable JAR fails to package if first uses certain layers
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-346?page=com.atlassian.jira.plugin... ]
Jean Francois Denise edited comment on WFWIP-346 at 9/3/20 12:15 PM:
---------------------------------------------------------------------
[~jkasik], very good catch! We have an unwanted JBoss module classes sharing between executions. I have fixed it in this branch, could you give it a try: [https://github.com/jfdenise/wildfly-jar-maven-plugin/tree/WFWIP-346]
Thank-you. Again excellent finding! In addition having such a nice reproducer really really helps.
was (Author: jdenise):
[~jkasik], very good catch! We have an unwanted JBoss module classes sharing between executions. I have fixed it in this branch, could you give it a try: [https://github.com/jfdenise/wildfly-jar-maven-plugin/tree/WFWIP-346]
Thank-you. Again excellent finding!
> Bootable JAR - Second bootable JAR fails to package if first uses certain layers
> --------------------------------------------------------------------------------
>
> Key: WFWIP-346
> URL: https://issues.redhat.com/browse/WFWIP-346
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Jan Kasik
> Assignee: Jean Francois Denise
> Priority: Critical
>
> See the reproducer: https://github.com/honza-kasik/layer-conflict - there are two Maven modules, each configured to run WildFly Maven JAR plugin.
> If I run {{mvn clean package -Dversion.org.wildfly.jar.plugin=2.0.0.Beta3}}, bootable JAR for app-one builds but for app-two the build ends up with an error and app-two fails to package:
> {noformat}
> [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-jar-maven-plugin:2.0.0.Beta3:package (default) on project app-two: Provisioning failed: Failed to generate standalone.xml on {
> [ERROR] "operation" => "composite",
> [ERROR] "address" => [],
> [ERROR] "rollback-on-runtime-failure" => true,
> [ERROR] "steps" => [
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("interface" => "public")],
> [ERROR] "inet-address" => "${jboss.bind.address:127.0.0.1}"
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.wildfly.extension.bean-validation")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.weld")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.naming")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.ee")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.wildfly.extension.io")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.wildfly.extension.undertow")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.jaxrs")]
> [ERROR] }
> [ERROR] ]
> [ERROR] }: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-8" => "WFLYCTL0310: Extension module org.jboss.as.jaxrs not found"}}
> {noformat}
> Packaging when running {{mvn clean install -Dversion.org.wildfly.jar.plugin=2.0.0.Beta3 -pl app-two}} ends with success. Same for {{app-one}} only.
> If I replace layers in app-one with layer {{cloud-server}} both modules build successfully.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFWIP-346) Bootable JAR - Second bootable JAR fails to package if first uses certain layers
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-346?page=com.atlassian.jira.plugin... ]
Jean Francois Denise edited comment on WFWIP-346 at 9/3/20 12:14 PM:
---------------------------------------------------------------------
[~jkasik], very good catch! We have an unwanted JBoss module classes sharing between executions. I have fixed it in this branch, could you give it a try: [https://github.com/jfdenise/wildfly-jar-maven-plugin/tree/WFWIP-346]
Thank-you. Again excellent finding!
was (Author: jdenise):
[~jkasik], very good catch! We have a unwanted JBoss module classes sharing between executions. I have fixed it in this branch, could you give it a try: [https://github.com/jfdenise/wildfly-jar-maven-plugin/tree/WFWIP-346]
Thank-you. Again excellent finding!
> Bootable JAR - Second bootable JAR fails to package if first uses certain layers
> --------------------------------------------------------------------------------
>
> Key: WFWIP-346
> URL: https://issues.redhat.com/browse/WFWIP-346
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Jan Kasik
> Assignee: Jean Francois Denise
> Priority: Critical
>
> See the reproducer: https://github.com/honza-kasik/layer-conflict - there are two Maven modules, each configured to run WildFly Maven JAR plugin.
> If I run {{mvn clean package -Dversion.org.wildfly.jar.plugin=2.0.0.Beta3}}, bootable JAR for app-one builds but for app-two the build ends up with an error and app-two fails to package:
> {noformat}
> [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-jar-maven-plugin:2.0.0.Beta3:package (default) on project app-two: Provisioning failed: Failed to generate standalone.xml on {
> [ERROR] "operation" => "composite",
> [ERROR] "address" => [],
> [ERROR] "rollback-on-runtime-failure" => true,
> [ERROR] "steps" => [
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("interface" => "public")],
> [ERROR] "inet-address" => "${jboss.bind.address:127.0.0.1}"
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.wildfly.extension.bean-validation")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.weld")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.naming")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.ee")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.wildfly.extension.io")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.wildfly.extension.undertow")]
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "add",
> [ERROR] "address" => [("extension" => "org.jboss.as.jaxrs")]
> [ERROR] }
> [ERROR] ]
> [ERROR] }: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-8" => "WFLYCTL0310: Extension module org.jboss.as.jaxrs not found"}}
> {noformat}
> Packaging when running {{mvn clean install -Dversion.org.wildfly.jar.plugin=2.0.0.Beta3 -pl app-two}} ends with success. Same for {{app-one}} only.
> If I replace layers in app-one with layer {{cloud-server}} both modules build successfully.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (ELY-2018) Add ability to FileAuditEndpoint to allow file encoding to be overridden.
by Ilia Vassilev (Jira)
[ https://issues.redhat.com/browse/ELY-2018?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev updated ELY-2018:
-------------------------------
Description: The FileAuditEndpoint doesn't allow file encoding to be overridden. It should allow the encoding to be overridden and specify UTF-8 as the default. (was: The {{FileAuditEndpoint}} doesn't allow for the file encoding to be overridden. It should likely allow the encoding to be overridden or at the very least specify {{UTF-8}} as the default. )
> Add ability to FileAuditEndpoint to allow file encoding to be overridden.
> -------------------------------------------------------------------------
>
> Key: ELY-2018
> URL: https://issues.redhat.com/browse/ELY-2018
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Major
>
> The FileAuditEndpoint doesn't allow file encoding to be overridden. It should allow the encoding to be overridden and specify UTF-8 as the default.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5434) Incorrect warning about file declaring wrong package
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5434?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-5434:
-------------------------------------
[~magnus_larsson] can you please attach a reproducer of this problem?
> Incorrect warning about file declaring wrong package
> ----------------------------------------------------
>
> Key: DROOLS-5434
> URL: https://issues.redhat.com/browse/DROOLS-5434
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Magnus Larsson
> Assignee: Mario Fusco
> Priority: Major
> Attachments: image-2020-09-03-09-20-10-089.png
>
>
> I am running Drools in a Spring-Boot jar and get the following warning statement _File 'BOOT-INF/classes/com/example/test/TEST.drl' is in folder 'BOOT-INF/classes/com/example/test' but declares package 'com.example.test'. It is advised to have a correspondance between package and folder names_. The package name in the drl file is correct, the problem is just that _BOOT-INF.classes._ isn't considered when evaluating if printing the warning or not.
> I have tracked it down to *KieBuilderImpl.java*, method *isFileInKieBase*. The last 2 lines in that method calls:
> {code:java}
> // packageNameForFile prints warning if package in .drl file is not same as flatted directory structure
> // Does not care about SUPPORTED_RESOURCES_ROOTS, thus prints the warning
> String pkgNameForFile = packageNameForFile( fileName, folderNameForFile, !useFolders, file );
> // Does care about SUPPORTED_RESOURCES_ROOTS, so the drl file is loaded
> return isPackageInKieBase( kieBase, pkgNameForFile );
> {code}
> As it is implemented right now, the warning might either be a false-positive (and still get loaded), or the package is wrong (and the file is not loaded).
> Voting to include the SUPPORTED_RESOURCES_ROOTS as valid prefixes when checking if the warning should be printed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months