[JBoss JIRA] (WFCORE-4083) org.apache.httpcomponents.core requires org.apache.commons.codec
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4083?page=com.atlassian.jira.plugi... ]
Sanne Grinovero commented on WFCORE-4083:
-----------------------------------------
[~kabirkhan] I only noticed this by testing an Hibernate Search feature which is not technically supported by products (the Elasticsearch integration), so not strictly a blocker ... yet:
# This is a very popular feature, I expect lots of people being annoyed by this
# Nobody else needing Basic Authentication of the apache http client to work ?? I don't know
Considering it can be fixed by a one-liner in the {{module.xml}} I would recommend to include it, especially for the sake of other usage beyond Hibernate Search needs.
> org.apache.httpcomponents.core requires org.apache.commons.codec
> ----------------------------------------------------------------
>
> Key: WFCORE-4083
> URL: https://issues.jboss.org/browse/WFCORE-4083
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Sanne Grinovero
> Fix For: 6.0.1.Final
>
>
> In WildFly 14 we get:
> {code:java}
> Exception in thread "Hibernate Search: Elasticsearch transport thread-2" java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
> 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.BasicScheme.authenticate(BasicScheme.java:168)
> 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239)
> 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:218)
> 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.nio.client.MainClientExec.generateRequest(MainClientExec.java:224)
> {code}
> Seems that the *org.apache.httpcomponents.core* (WildFly core) module is not declaring the dependency on module *org.apache.commons.codec* (WildFly full).
> Should this be added as an optional dependency, or maybe the need for this module warrants moving the *org.apache.commons.codec* module to WildFly core ?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 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 closed WFCORE-3658.
------------------------------
Resolution: Rejected
Rejected in EAP7-747
> 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
> Fix For: 5.0.0.Alpha1
>
>
> 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, 10 months
[JBoss JIRA] (JGRP-2283) Lock race condition
by Bernd Laengerich (JIRA)
[ https://issues.jboss.org/browse/JGRP-2283?page=com.atlassian.jira.plugin.... ]
Bernd Laengerich edited comment on JGRP-2283 at 9/3/18 8:34 AM:
----------------------------------------------------------------
There is only the test instance in the cluster, no other members.
The same is observed using CENTRAL_LOCK2 instead of CENTRAL_LOCK.
When running the loop2 with tryLock(1000, TimeUnit.MILLISECONDS), the Loop stalls at random intervals for a second, tryLock returning false and then it recovers with:
14:28:55.220 [jgroups-3,test,test] ERROR org.jgroups.protocols.CENTRAL_LOCK2 - JGRP000124: discarded LOCK-GRANTED response with lock-id=1118, my lock-id=1119
was (Author: dl6lr):
There is only the test instance in the cluster, no other members.
The same is observed using CENTRAL_LOCK2 instead of CENTRAL_LOCK.
> Lock race condition
> -------------------
>
> Key: JGRP-2283
> URL: https://issues.jboss.org/browse/JGRP-2283
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.14
>
> Attachments: RDBXGNBM.txt, m1PNLdDr.txt
>
>
> The attached program fails to run repeats of tryLock-unlock sequences.
> Program and config are attached
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (JGRP-2283) Lock race condition
by Bela Ban (JIRA)
Bela Ban created JGRP-2283:
------------------------------
Summary: Lock race condition
Key: JGRP-2283
URL: https://issues.jboss.org/browse/JGRP-2283
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0.14
The attached program fails to run repeats of tryLock-unlock sequences.
Program and config are attached
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months