[JBoss JIRA] (WFCORE-3129) [7.1.z] standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly
by Radovan Stancel (JIRA)
Radovan Stancel created WFCORE-3129:
---------------------------------------
Summary: [7.1.z] standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly
Key: WFCORE-3129
URL: https://issues.jboss.org/browse/WFCORE-3129
Project: WildFly Core
Issue Type: Bug
Components: Scripts
Affects Versions: 3.0.0.Beta30
Reporter: Radovan Stancel
Assignee: Radovan Stancel
======================
Scenario-1)
============ With the following line of JAVA_OPTS in "standalone.bat.conf" file
set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost|127.0.0.1|10.10.10.*"
{code}
Error while starting EAP 6.1.1
C:\jboss-eap-6.1.1\bin>standalone.bat
Calling "C:\jboss-eap-6.1.1\bin\standalone.conf.bat"
Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java"
'127.0.0.1' is not recognized as an internal or external command,
operable program or batch file.
{code}
Scenario-2)
============ In Windows "^" sign is the escape character so we tried altering the JAVA_OPTS as following in the "standalone.bat.conf" file:
set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost^|127.0.0.1^|10.10.10.*"
Now EAP 6.1.1 server starts but still we see the following messages in windows console:
{code}
C:\jboss-eap-6.1.1\bin>standalone.bat
Calling "C:\jboss-eap-6.1.1\bin\standalone.conf.bat"
Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java"
'127.0.0.1' is not recognized as an internal or external command,
operable program or batch file.
'127.0.0.1' is not recognized as an internal or external command,
operable program or batch file.
'127.0.0.1' is not recognized as an internal or external command,
operable program or batch file.
'127.0.0.1' is not recognized as an internal or external command,
operable program or batch file.
'127.0.0.1' is not recognized as an internal or external command,
operable program or batch file.
'127.0.0.1' is not recognized as an internal or external command,
operable program or batch file.
'127.0.0.1' is not recognized as an internal or external command,
operable program or batch file.
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFLY-9126) Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9126?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas commented on WFLY-9126:
------------------------------------
[~swd847] reproducer app is attached in original Jira - JBEAP-12328.
> Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9126
> URL: https://issues.jboss.org/browse/WFLY-9126
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security, Web (Undertow)
> Reporter: Josef Cacek
> Assignee: Stuart Douglas
> Priority: Critical
>
> The WAR deployment fails when it contains EJBs and Servlets with security domains mapped under different names (application-security-domain). The underlying Elytron domain is the same for both subsystems.
> EJB subsystem tries to search also for the domain name which is used in {{jboss-web.xml}} and this lookup fails.
> Sample configuration:
> {code:xml|title=jboss-ejb3.xml}
> <jboss:ejb-jar>
> <assembly-descriptor><s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>seccontext-whoami</s:security-domain>
> </s:security></assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> {code:xml|title=jboss-web.xml}
> <jboss-web>
> <security-domain>seccontext-web</security-domain>
> </jboss-web>
> {code}
> {code:title=application-security-domain-mapping.cli}
> /subsystem=ejb3/application-security-domain=seccontext-whoami:add( \
> security-domain=ApplicationDomain)
> /subsystem=undertow/application-security-domain=seccontext-web:add( \
> http-authentication-factory=application-http-authentication)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFLY-9126) Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9126?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-9126:
--------------------------------------
Looks like the reproducer app is missing?
> Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9126
> URL: https://issues.jboss.org/browse/WFLY-9126
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security, Web (Undertow)
> Reporter: Josef Cacek
> Assignee: Stuart Douglas
> Priority: Critical
>
> The WAR deployment fails when it contains EJBs and Servlets with security domains mapped under different names (application-security-domain). The underlying Elytron domain is the same for both subsystems.
> EJB subsystem tries to search also for the domain name which is used in {{jboss-web.xml}} and this lookup fails.
> Sample configuration:
> {code:xml|title=jboss-ejb3.xml}
> <jboss:ejb-jar>
> <assembly-descriptor><s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>seccontext-whoami</s:security-domain>
> </s:security></assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> {code:xml|title=jboss-web.xml}
> <jboss-web>
> <security-domain>seccontext-web</security-domain>
> </jboss-web>
> {code}
> {code:title=application-security-domain-mapping.cli}
> /subsystem=ejb3/application-security-domain=seccontext-whoami:add( \
> security-domain=ApplicationDomain)
> /subsystem=undertow/application-security-domain=seccontext-web:add( \
> http-authentication-factory=application-http-authentication)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFCORE-3073) Handle TERM gracefully
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3073:
------------------------------------------
[~swd847] I get into that a bit in the analysis doc. The main use case for this is things like OpenShift. I don't see them wanting to mess with management API or our xml to configure this. And even something like putting an attribute in our standard config but with an expression with this property as the value makes it something that may or may not work, depending on whether the user retains that attribute in their xml.
So I figured
1) -1 to *requiring* a proper management attribute; i.e. not supporting directly reading a property in the runtime.
2) Adding a proper attribute, and only falling back to the property if the attribute is not set is fine. But I can come back to that later. I wanted to do the quick part first, in case someone got excited and pushed to get this in ASAP.
> Handle TERM gracefully
> ----------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Parees
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFCORE-3073) Handle TERM gracefully
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
Stuart Douglas commented on WFCORE-3073:
----------------------------------------
Proposed patch looks reasonable to me. The main question I have is if this should be configured via a system property, or via the management API?
> Handle TERM gracefully
> ----------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Parees
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months