[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6680:
---------------------------------
Comment: was deleted
(was: Vladimir Dosoudil <dosoudil(a)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@localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain@localhost:9999 subsystem=modcluster] :list-proxies
> {
> "outcome" => "success",
> "result" => [
> "web02:8009",
> "web01:8009"
> ]
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> [domain@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)
9 years, 7 months
[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6680:
---------------------------------
Comment: was deleted
(was: Aaron Ogburn <aogburn(a)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@localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain@localhost:9999 subsystem=modcluster] :list-proxies
> {
> "outcome" => "success",
> "result" => [
> "web02:8009",
> "web01:8009"
> ]
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> [domain@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)
9 years, 7 months
[JBoss JIRA] (WFLY-7252) war bean not visible for injection
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7252?page=com.atlassian.jira.plugin.... ]
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)
9 years, 7 months
[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6680:
---------------------------------
Comment: was deleted
(was: Peter Mackay <pmackay(a)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@localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain@localhost:9999 subsystem=modcluster] :list-proxies
> {
> "outcome" => "success",
> "result" => [
> "web02:8009",
> "web01:8009"
> ]
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> [domain@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)
9 years, 7 months
[JBoss JIRA] (WFLY-7252) war bean not visible for injection
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7252?page=com.atlassian.jira.plugin.... ]
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)
9 years, 7 months
[JBoss JIRA] (WFCORE-1848) Domain server process' main thread can terminate without triggering process exit
by Brian Stansberry (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)
9 years, 7 months
[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ]
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/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7254) pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.... ]
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)
9 years, 7 months
[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when at least one of the proxies is unreachable
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6680:
-----------------------------------------------
Peter Mackay <pmackay(a)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@localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain@localhost:9999 subsystem=modcluster] :list-proxies
> {
> "outcome" => "success",
> "result" => [
> "web02:8009",
> "web01:8009"
> ]
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> [domain@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)
9 years, 7 months