[JBoss JIRA] (SWSQE-294) Investigate ElasticSearch errors on Openshift Clusters
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/SWSQE-294?page=com.atlassian.jira.plugin.... ]
Guilherme Baufaker Rêgo resolved SWSQE-294.
-------------------------------------------
Resolution: Done
> Investigate ElasticSearch errors on Openshift Clusters
> ------------------------------------------------------
>
> Key: SWSQE-294
> URL: https://issues.jboss.org/browse/SWSQE-294
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Kevin Earls
> Assignee: Guilherme Baufaker Rêgo
> Priority: Minor
> Attachments: elasticsearch-0.log, elasticsearch-pod-description.log, es1.log
>
>
> On minishift and the CNCF CI OpenShift cluster, we install ElasticSearch using the commands:
> curl https://raw.githubusercontent.com/RHsyseng/docker-rhel-elasticsearch/5.x/... --output es-cluster-deployment.yml
> oc create -f es-cluster-deployment.yml
> However, on B24 this fails. The first 2 elasticsearch pods will start up, but then elasticsearch-2 gets into the following failure loop like:
> elasticsearch-2 1/1 Running 3 1m
> elasticsearch-2 0/1 OOMKilled 3 1m
> elasticsearch-2 0/1 CrashLoopBackOff 3 2m
> If I increase memory in the es-cluster-deployment.yml to 1Gi it will at least start, but I've found I really need to increase it to 2Gi to do anything non trivial.
> We may need to track down the people who originally created this template for help on this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10728) RESTEASY008200: JSON Binding deserialization error for valid JSON
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-10728?page=com.atlassian.jira.plugin... ]
Alessio Soldano reassigned WFLY-10728:
--------------------------------------
Assignee: Ron Sigal (was: Alessio Soldano)
> RESTEASY008200: JSON Binding deserialization error for valid JSON
> -----------------------------------------------------------------
>
> Key: WFLY-10728
> URL: https://issues.jboss.org/browse/WFLY-10728
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Environment: JDK-10.0.1
> Reporter: Guido Schmidt
> Assignee: Ron Sigal
> Attachments: User.java, UserQueryForm.java, UsersApi.java
>
>
> I found the following regression issue running the code inside an ejb jar:
> In the context of a search for a user for a user via the Wordpress REST API, I get e.g. following String:
> {{[{
> "id": 15,
> "username": "wpx1",
> "name": "Word Press1",
> "first_name": "Word",
> "last_name": "Press1",
> "email": "wpx1(a)pb.com",
> "url": "",
> "description": "",
> "link": "http:\/\/www.pbpiazza.com\/dayc\/archives\/author\/wpx1",
> "locale": "en_US",
> "nickname": "wpx1",
> "slug": "wpx1",
> "roles": ["contributor"],
> "registered_date": "2018-07-23T08:59:13+00:00",
> "capabilities": {
> "edit_posts": true,
> "read": true,
> "level_1": true,
> "level_0": true,
> "delete_posts": true,
> "manage_bookings": true,
> "upload_event_images": true,
> "delete_events": true,
> "edit_events": true,
> "read_private_events": true,
> "delete_recurring_events": true,
> "edit_recurring_events": true,
> "edit_locations": true,
> "read_private_locations": true,
> "read_others_locations": true,
> "contributor": true
> },
> "extra_capabilities": {
> "contributor": true
> },
> "avatar_urls": {
> "24": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=24&d=mm&r=g",
> "48": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=48&d=mm&r=g",
> "96": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=96&d=mm&r=g"
> },
> "meta": [],
> "_links": {
> "self": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users\/15"
> }
> ],
> "collection": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users"
> }
> ]
> }
> }
> ]}}
> This is achieved by a call of the UsersApi method listUsersAsString:
>
> ResteasyWebTarget target = (ResteasyWebTarget)restEasy.target(uri);
> target.proxy(UsersApi.class);
> The call rendering the result into a List<User> fails with error message in the subject.
> The result is perfectly fine running Wildfly 11.Plain test cases with Wildfly 13 libraries is also fine. It seems to be a runtime configuration issue of RESTEasy in WIldfly 13.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (JBEE-196) JSP and JSTL missing from EE 7 BOM
by Rich DiCroce (JIRA)
Rich DiCroce created JBEE-196:
---------------------------------
Summary: JSP and JSTL missing from EE 7 BOM
Key: JBEE-196
URL: https://issues.jboss.org/browse/JBEE-196
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Affects Versions: JavaEE 7 Spec APIs 1.1.0.Final
Reporter: Rich DiCroce
Assignee: Scott Marlow
jboss-javaee-7.0 version 1.0.4 includes JSP and JSTL. Version 1.1.0 and later effectively do not, because they declare those dependencies to be provided scope for some reason. Servlet would also be affected, except JACC has a transitive dependency on it.
This bug appears to have been introduced as part of resolving JBEE-170.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10728) RESTEASY008200: JSON Binding deserialization error for valid JSON
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10728?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-10728:
---------------------------------------
Component/s: REST
Assignee: Alessio Soldano (was: Jason Greene)
> RESTEASY008200: JSON Binding deserialization error for valid JSON
> -----------------------------------------------------------------
>
> Key: WFLY-10728
> URL: https://issues.jboss.org/browse/WFLY-10728
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Environment: JDK-10.0.1
> Reporter: Guido Schmidt
> Assignee: Alessio Soldano
> Attachments: User.java, UserQueryForm.java, UsersApi.java
>
>
> I found the following regression issue running the code inside an ejb jar:
> In the context of a search for a user for a user via the Wordpress REST API, I get e.g. following String:
> {{[{
> "id": 15,
> "username": "wpx1",
> "name": "Word Press1",
> "first_name": "Word",
> "last_name": "Press1",
> "email": "wpx1(a)pb.com",
> "url": "",
> "description": "",
> "link": "http:\/\/www.pbpiazza.com\/dayc\/archives\/author\/wpx1",
> "locale": "en_US",
> "nickname": "wpx1",
> "slug": "wpx1",
> "roles": ["contributor"],
> "registered_date": "2018-07-23T08:59:13+00:00",
> "capabilities": {
> "edit_posts": true,
> "read": true,
> "level_1": true,
> "level_0": true,
> "delete_posts": true,
> "manage_bookings": true,
> "upload_event_images": true,
> "delete_events": true,
> "edit_events": true,
> "read_private_events": true,
> "delete_recurring_events": true,
> "edit_recurring_events": true,
> "edit_locations": true,
> "read_private_locations": true,
> "read_others_locations": true,
> "contributor": true
> },
> "extra_capabilities": {
> "contributor": true
> },
> "avatar_urls": {
> "24": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=24&d=mm&r=g",
> "48": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=48&d=mm&r=g",
> "96": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=96&d=mm&r=g"
> },
> "meta": [],
> "_links": {
> "self": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users\/15"
> }
> ],
> "collection": [{
> "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users"
> }
> ]
> }
> }
> ]}}
> This is achieved by a call of the UsersApi method listUsersAsString:
>
> ResteasyWebTarget target = (ResteasyWebTarget)restEasy.target(uri);
> target.proxy(UsersApi.class);
> The call rendering the result into a List<User> fails with error message in the subject.
> The result is perfectly fine running Wildfly 11.Plain test cases with Wildfly 13 libraries is also fine. It seems to be a runtime configuration issue of RESTEasy in WIldfly 13.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1455) DB query seen for each request using programatic authentication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1455:
----------------------------------
Fix Version/s: 1.5.1.CR1
(was: 1.5.0.Final)
> DB query seen for each request using programatic authentication
> ----------------------------------------------------------------
>
> Key: ELY-1455
> URL: https://issues.jboss.org/browse/ELY-1455
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Beta10
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.5.1.CR1
>
> Attachments: elytron-bug.zip, server.log, standalone-full-ha.xml
>
>
> User is complaining, that DB is accessed on each request.
> Jdbc-realm + FORM authentication
> {noformat}
> <jdbc-realm name="myappRealm">
> <principal-query sql="SELECT r.role, u.password FROM user u join user_role_auth r on r.email = u.email where u.email=?" data-source="myds">
> <attribute-mapping>
> <attribute to="Roles" index="1"/>
> </attribute-mapping>
> <simple-digest-mapper password-index="2"/>
> </principal-query>
> </jdbc-realm>
> {noformat}
> {noformat}
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,051 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,052 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorization succeed
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,017 TRACE [org.wildfly.security] (default task-125) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:07,018 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,019 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,021 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorization succeed
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1440?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1440:
----------------------------------
Fix Version/s: 1.5.1.CR1
(was: 1.5.0.Final)
> FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.
> ----------------------------------------------------------------------------------------------
>
> Key: ELY-1440
> URL: https://issues.jboss.org/browse/ELY-1440
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.5.1.CR1
>
>
> This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event.
> Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance.
> At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1427) Credential store type PKCS12 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1427?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1427:
----------------------------------
Fix Version/s: 1.5.1.CR1
(was: 1.5.0.Final)
> Credential store type PKCS12 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.
> --------------------------------------------------------------------------------------------------------
>
> Key: ELY-1427
> URL: https://issues.jboss.org/browse/ELY-1427
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Priority: Critical
> Fix For: 1.5.1.CR1
>
>
> Credential store type PKCS12 works fine when using OracleJDK and OpenJDK.
> Problem occurs when we use IBM JDK, add-alias works fine for first time, but for add-alias for second time with same alias name we expect message about duplicity rather than current error message about SecretKeyFactory not availability.
> {code}
> "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: WFLYELY00009: Unable to complete operation. 'ELY09504: Cannot acquire a credential from the credential store->Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available->1.2.840.113549.1.7.1 SecretKeyFactory not available'",
> {code}
> *NOTE*
> I met same problem with Oracle JDK 1.8 u66, with u144 is everythink ok.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months