[JBoss JIRA] (WFLY-9846) Unsatisfied dependencies for CDI Beans in static module's dependency
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/WFLY-9846?page=com.atlassian.jira.plugin.... ]
Matej Novotny updated WFLY-9846:
--------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/10958
> Unsatisfied dependencies for CDI Beans in static module's dependency
> --------------------------------------------------------------------
>
> Key: WFLY-9846
> URL: https://issues.jboss.org/browse/WFLY-9846
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Martin Kouba
>
> WAR CDI bean is failing to inject a CDI bean from a static module's exported dependency. war -> static module X -> static module Y (containing CDI Beans)
> A WAR uses a static module with the slot attribute. This static module is referenced in jboss-deployment-structure.xml:
> {code}
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <module name="module2" meta-inf="export" annotations="true" />
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> module2 which the app depends on is depending on module1 and including/exporting META-INF where the beans.xml is located:
> {code}
> <?xml version="1.0"?>
> <module xmlns="urn:jboss:module:1.5" name="module2">
> <dependencies>
> <module name="module1" export="true">
> <imports>
> <include path="META-INF**"/>
> <include path="org**"/>
> </imports>
> <exports>
> <include path="META-INF**"/>
> <include path="org**"/>
> </exports>
> </module>
> </dependencies>
> </module>
> {code}
> module1 contains the jar with the CDI beans and has a META-INF/beans.xml in it:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.5" name="module1">
> <resources>
> <resource-root path="cdi-beans.jar"/>
> </resources>
> <dependencies>
> <module name="javax.faces.api" export="true"/>
> <module name="javax.ejb.api"/>
> <module name="javax.enterprise.api"/>
> </dependencies>
> </module>
> {code}
>
> The deploy fails with the next message:
>
> {code}
> 14:04:07,085 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".WeldStartService: Failed to start service
> ...
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type ExampleCdiBean with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private backingbeans.BackingBean.cdiBean
> at backingbeans.BackingBean.cdiBean(BackingBean.java:0)
> {code}
>
> In JBoss EAP 6.4, this scenario, the CDI is working fine.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9846) Unsatisfied dependencies for CDI Beans in static module's dependency
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/WFLY-9846?page=com.atlassian.jira.plugin.... ]
Matej Novotny reassigned WFLY-9846:
-----------------------------------
Assignee: Matej Novotny (was: Martin Kouba)
> Unsatisfied dependencies for CDI Beans in static module's dependency
> --------------------------------------------------------------------
>
> Key: WFLY-9846
> URL: https://issues.jboss.org/browse/WFLY-9846
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Matej Novotny
>
> WAR CDI bean is failing to inject a CDI bean from a static module's exported dependency. war -> static module X -> static module Y (containing CDI Beans)
> A WAR uses a static module with the slot attribute. This static module is referenced in jboss-deployment-structure.xml:
> {code}
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <module name="module2" meta-inf="export" annotations="true" />
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> module2 which the app depends on is depending on module1 and including/exporting META-INF where the beans.xml is located:
> {code}
> <?xml version="1.0"?>
> <module xmlns="urn:jboss:module:1.5" name="module2">
> <dependencies>
> <module name="module1" export="true">
> <imports>
> <include path="META-INF**"/>
> <include path="org**"/>
> </imports>
> <exports>
> <include path="META-INF**"/>
> <include path="org**"/>
> </exports>
> </module>
> </dependencies>
> </module>
> {code}
> module1 contains the jar with the CDI beans and has a META-INF/beans.xml in it:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.5" name="module1">
> <resources>
> <resource-root path="cdi-beans.jar"/>
> </resources>
> <dependencies>
> <module name="javax.faces.api" export="true"/>
> <module name="javax.ejb.api"/>
> <module name="javax.enterprise.api"/>
> </dependencies>
> </module>
> {code}
>
> The deploy fails with the next message:
>
> {code}
> 14:04:07,085 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".WeldStartService: Failed to start service
> ...
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type ExampleCdiBean with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private backingbeans.BackingBean.cdiBean
> at backingbeans.BackingBean.cdiBean(BackingBean.java:0)
> {code}
>
> In JBoss EAP 6.4, this scenario, the CDI is working fine.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFCORE-3658) Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3658?page=com.atlassian.jira.plugi... ]
Jan Kalina updated WFCORE-3658:
-------------------------------
Git Pull Request: (was: https://github.com/wildfly-security/wildfly-elytron/pull/930)
> Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3658
> URL: https://issues.jboss.org/browse/WFCORE-3658
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
>
> One of the scenarios which are expected to work in Elytron is a Security context propagation from a protected EJB to a protected Servlet using HttpUrlConnection (details in RFE EAP7-284).
> The scenario doesn't work for me. My configuration:
> {noformat}
> EJB client -> protected EJB on server-1 -> protected Servlet on server-2 (BASIC authn)
> {noformat}
> The EJB contains following code:
> {code:java}
> final Callable<String> callable = () -> {
> URLConnection conn = url.openConnection();
> conn.connect();
> try (InputStream is = conn.getInputStream()) {
> return IOUtils.toString(is, StandardCharsets.UTF_8);
> }
> };
> AuthenticationContext.empty().with(MatchRule.ALL, AuthenticationConfiguration.empty()
> .useForwardedIdentity(SecurityDomain.getCurrent())
> .setSaslMechanismSelector(SaslMechanismSelector.ALL))
> .runCallable(callable);
> {code}
> The server-2 returns 401:
> {noformat}
> java.io.IOException: Server returned HTTP response code: 401 for URL: http://127.0.0.1:8180/seccontext-server2/whoAmI
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
> at org.wildfly.test.manual.elytron.seccontext.EntryBean.lambda$readUrl$1(EntryBean.java:69)
> {noformat}
> There is still a chance, the problem is in the scenario configuration, but the documentation is silent about this topic.
> The problem could be in a missing integration of ElytronAuthenticator within the AuthenticationContext. I don't see it used when I debug the scenario. When I register the authenticator manually, I see another problem which will be reported in a separate JIRA.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFCORE-3658) Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3658?page=com.atlassian.jira.plugi... ]
Jan Kalina moved WFLY-9931 to WFCORE-3658:
------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3658 (was: WFLY-9931)
Component/s: Security
(was: Security)
> Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3658
> URL: https://issues.jboss.org/browse/WFCORE-3658
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
>
> One of the scenarios which are expected to work in Elytron is a Security context propagation from a protected EJB to a protected Servlet using HttpUrlConnection (details in RFE EAP7-284).
> The scenario doesn't work for me. My configuration:
> {noformat}
> EJB client -> protected EJB on server-1 -> protected Servlet on server-2 (BASIC authn)
> {noformat}
> The EJB contains following code:
> {code:java}
> final Callable<String> callable = () -> {
> URLConnection conn = url.openConnection();
> conn.connect();
> try (InputStream is = conn.getInputStream()) {
> return IOUtils.toString(is, StandardCharsets.UTF_8);
> }
> };
> AuthenticationContext.empty().with(MatchRule.ALL, AuthenticationConfiguration.empty()
> .useForwardedIdentity(SecurityDomain.getCurrent())
> .setSaslMechanismSelector(SaslMechanismSelector.ALL))
> .runCallable(callable);
> {code}
> The server-2 returns 401:
> {noformat}
> java.io.IOException: Server returned HTTP response code: 401 for URL: http://127.0.0.1:8180/seccontext-server2/whoAmI
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
> at org.wildfly.test.manual.elytron.seccontext.EntryBean.lambda$readUrl$1(EntryBean.java:69)
> {noformat}
> There is still a chance, the problem is in the scenario configuration, but the documentation is silent about this topic.
> The problem could be in a missing integration of ElytronAuthenticator within the AuthenticationContext. I don't see it used when I debug the scenario. When I register the authenticator manually, I see another problem which will be reported in a separate JIRA.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9932) Update docs for WF 12
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-9932:
---------------------------------
Summary: Update docs for WF 12
Key: WFLY-9932
URL: https://issues.jboss.org/browse/WFLY-9932
Project: WildFly
Issue Type: Task
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Minor task to update references to 12 everywhere where possible.
cleanup the links and warnings at conversion.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9854) jgroups-channel cannot use name which is already used by jgroups/stacks
by Chuck Copello (JIRA)
[ https://issues.jboss.org/browse/WFLY-9854?page=com.atlassian.jira.plugin.... ]
Chuck Copello commented on WFLY-9854:
-------------------------------------
[~kabirkhan], thank you for the tag. Will this need to be documented for EL12, or can we target EL13 / 7.2 Beta?
[https://issues.jboss.org/browse/EAP7-941] created to update documentation.
cc: [~bprioux]
> jgroups-channel cannot use name which is already used by jgroups/stacks
> -----------------------------------------------------------------------
>
> Key: WFLY-9854
> URL: https://issues.jboss.org/browse/WFLY-9854
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 12.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The configuration \[1\] results to an error \[2\]. This is backward compatibility issue since the configuration works with previous releases of Wildfly.
> \[1\]
> {code:xml}
> <broadcast-group name="bg-group1" jgroups-stack="udp" jgroups-channel="udp" broadcast-period="2000" connectors="connector"/>
> {code}
> \[2\]
> {code}
> 10:52:29,982 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "udp")
> ]) - failure description: "WFLYCTL0436: Cannot register capability 'org.wildfly.clustering.jgroups.channel-factory.udp' at location '[
> (\"subsystem\" => \"jgroups\"),
> (\"channel\" => \"udp\")
> ]' as it is already registered in context 'global' at location(s) '[[
> (\"subsystem\" => \"jgroups\"),
> (\"stack\" => \"udp\")
> ]]'"
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9931) Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-9931?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved WFCORE-3657 to WFLY-9931:
------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-9931 (was: WFCORE-3657)
Component/s: Security
(was: Security)
> Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-9931
> URL: https://issues.jboss.org/browse/WFLY-9931
> Project: WildFly
> Issue Type: Enhancement
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
>
> One of the scenarios which are expected to work in Elytron is a Security context propagation from a protected EJB to a protected Servlet using HttpUrlConnection (details in RFE EAP7-284).
> The scenario doesn't work for me. My configuration:
> {noformat}
> EJB client -> protected EJB on server-1 -> protected Servlet on server-2 (BASIC authn)
> {noformat}
> The EJB contains following code:
> {code:java}
> final Callable<String> callable = () -> {
> URLConnection conn = url.openConnection();
> conn.connect();
> try (InputStream is = conn.getInputStream()) {
> return IOUtils.toString(is, StandardCharsets.UTF_8);
> }
> };
> AuthenticationContext.empty().with(MatchRule.ALL, AuthenticationConfiguration.empty()
> .useForwardedIdentity(SecurityDomain.getCurrent())
> .setSaslMechanismSelector(SaslMechanismSelector.ALL))
> .runCallable(callable);
> {code}
> The server-2 returns 401:
> {noformat}
> java.io.IOException: Server returned HTTP response code: 401 for URL: http://127.0.0.1:8180/seccontext-server2/whoAmI
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
> at org.wildfly.test.manual.elytron.seccontext.EntryBean.lambda$readUrl$1(EntryBean.java:69)
> {noformat}
> There is still a chance, the problem is in the scenario configuration, but the documentation is silent about this topic.
> The problem could be in a missing integration of ElytronAuthenticator within the AuthenticationContext. I don't see it used when I debug the scenario. When I register the authenticator manually, I see another problem which will be reported in a separate JIRA.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9930) Get data source information
by Kabir Khan (JIRA)
Kabir Khan created WFLY-9930:
--------------------------------
Summary: Get data source information
Key: WFLY-9930
URL: https://issues.jboss.org/browse/WFLY-9930
Project: WildFly
Issue Type: Feature Request
Components: JCA
Reporter: Jesper Pedersen
Assignee: Lin Gao
Fix For: 12.0.0.Final
Create a DMR operation that returns the available properties for the data source class, and xa data source class for the <driver>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Pedro Igor commented on WFLY-9892:
----------------------------------
+1. As suggested already, we should consider this one a quickstart/test/doc issue.
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months