March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1727) Develop an alternative to 'org.wildfly.security.auth.util.GSSCredentialSecurityFactory'

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1727?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1727: ---------------------------------- Fix Version/s: 2.0.0.Alpha2 > Develop an alternative to 'org.wildfly.security.auth.util.GSSCredentialSecurityFactory' > --------------------------------------------------------------------------------------- > > Key: ELY-1727 > URL: https://issues.jboss.org/browse/ELY-1727 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Critical > Fix For: 1.9.0.CR1, 2.0.0.Alpha1, 2.0.0.Alpha2 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1734) Clean up the 'wildfly-elytron-asn1' module as it currently contains both public and private API

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1734?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1734: ---------------------------------- Fix Version/s: 2.0.0.Alpha2 > Clean up the 'wildfly-elytron-asn1' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------- > > Key: ELY-1734 > URL: https://issues.jboss.org/browse/ELY-1734 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Assignee: Justin Cook > Priority: Major > Fix For: 1.9.0.CR1, 2.0.0.Alpha1, 2.0.0.Alpha2 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-634) Setup Kubernetes Cluster on Packet for Security Audit

by Gary Brown (Jira)

[ https://issues.jboss.org/browse/SWSQE-634?page=com.atlassian.jira.plugin.... ] Gary Brown commented on SWSQE-634: ---------------------------------- Hi [~gbaufake], hopefully you have received your invite to the project now. There is a bi-weekly Jaeger community meeting this Friday pm - the last before the security audit is supposed to commence (on 1st April). Do you have an estimate for when the environment would be ready with some simple instructions on how to access the environment that could be passed to the security audit company? Thanks in advance. > Setup Kubernetes Cluster on Packet for Security Audit > ----------------------------------------------------- > > Key: SWSQE-634 > URL: https://issues.jboss.org/browse/SWSQE-634 > Project: Kiali QE > Issue Type: Task > Reporter: Kevin Earls > Priority: Major > Labels: infrastructure > > [~objectiser] has requested we setup a Kubernetes cluster with Jaeger installed via the operator on Packet. This is needed for a security audit of Jaeger which will be done by a third party at the beginning of April. > I will need admin help with this when someone is available. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-613) Document Manual Events

by Matt Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-613?page=com.atlassian.jira.plugin.... ] Matt Mahoney commented on SWSQE-613: ------------------------------------ https://docs.google.com/document/d/1x5scIulhkkHLzyW58xs_kDwmQvgtlygroZDwb... > Document Manual Events > ---------------------- > > Key: SWSQE-613 > URL: https://issues.jboss.org/browse/SWSQE-613 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Matt Mahoney > Priority: Major > Labels: infrastructure > > Document what can not be automated > Document why it can not be automated -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11874) Remove unneeded dependencies from Hibernate ORM module

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-11874?page=com.atlassian.jira.plugin... ] Scott Marlow updated WFLY-11874: -------------------------------- Fix Version/s: 17.0.0.Beta1 > Remove unneeded dependencies from Hibernate ORM module > ------------------------------------------------------ > > Key: WFLY-11874 > URL: https://issues.jboss.org/browse/WFLY-11874 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Affects Versions: 16.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > Fix For: 17.0.0.Beta1 > > > As mentioned in [https://github.com/wildfly/wildfly/pull/12155], we should remove remove ASM dependency from org/hibernate/main/module.xml. Check other Hibernate dependencies as well. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4368) Remove the org.apache.commons:commons-lang3 exclusion from elytron-tool

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4368?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-4368: ------------------------------------------ [~kabirkhan] What was the actual error being addressed by the exclusion? The scope within the tool for this artefact is presently test so unless something else pulling it in transitively it should not be coming from the tool at all. > Remove the org.apache.commons:commons-lang3 exclusion from elytron-tool > ----------------------------------------------------------------------- > > Key: WFCORE-4368 > URL: https://issues.jboss.org/browse/WFCORE-4368 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Kabir Khan > Priority: Major > > See https://issues.jboss.org/browse/WFCORE-4366 for details of why it is needed. Since the Elytron tool shades all its dependencies, can they have a scope which does not get exported again? Perhaps provided, although I don't know if those work with the shade plugin. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11874) Remove unneeded dependencies from Hibernate ORM module

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-11874?page=com.atlassian.jira.plugin... ] Scott Marlow commented on WFLY-11874: ------------------------------------- Note that javax.xml is also used in generated Hibernate code, like tooling/metamodel-generator/src/main/java/org/hibernate/jpamodelgen/util/xml/XmlParserHelper.java, so will still include javax.xml.bind.api module dependency. > Remove unneeded dependencies from Hibernate ORM module > ------------------------------------------------------ > > Key: WFLY-11874 > URL: https://issues.jboss.org/browse/WFLY-11874 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Affects Versions: 16.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > > As mentioned in [https://github.com/wildfly/wildfly/pull/12155], we should remove remove ASM dependency from org/hibernate/main/module.xml. Check other Hibernate dependencies as well. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup

by Laird Nelson (Jira)

[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ] Laird Nelson edited comment on WFLY-11858 at 3/20/19 1:34 PM: -------------------------------------------------------------- Yes, the scope of any given {{JNDIBean}} should continue to be {{Singleton}}. But the {{AbstractBean<InitialContext>}} subclass instance's scope should be {{Dependent}}, I think. My guess (I don't really know, as I'm not up on the sophisticated classloading involved in .ear files here) is that any solution that allows the {{InitialContext}} to be created at the point that the {{lookup}} call is made will work. So it would seem that in general it is not OK to have a single instance of {{InitialContext}} floating around, i.e. I believe that the scope of the {{AbstractBean<InitialContext>}} subclass should be {{Dependent}}, not {{Singleton}}. I've updated this in my other (approved so far) [PR|https://github.com/jbosstm/narayana/pull/1403]. Making the {{JNDIBean}} "use directly the initial context with {{new InitialContext().lookup(this.name)}}" is exactly the same as placing the {{AbstractBean<InitialContext>}} in {{Dependent}} scope. I personally prefer going through the bean here as it allows user-supplied {{InitialContext}} bean implementations. was (Author: ljnelson): My guess (I don't really know, as I'm not up on the sophisticated classloading involved in .ear files here) is that any solution that allows the {{InitialContext}} to be created at the point that the {{lookup}} call is made will work. So it would seem that in general it is not OK to have a single instance of {{InitialContext}} floating around, i.e. I believe that the scope of the {{AbstractBean<InitialContext>}} subclass should be {{Dependent}}, not {{Singleton}}. I've updated this in my other (approved so far) [PR|https://github.com/jbosstm/narayana/pull/1403]. Making the {{JNDIBean}} "use directly the initial context with {{new InitialContext().lookup(this.name)}}" is exactly the same as placing the {{AbstractBean<InitialContext>}} in {{Dependent}} scope. I personally prefer going through the bean here as it allows user-supplied {{InitialContext}} bean implementations. > [Wildfly16] CDI fails to inject InitialContext during startup > ------------------------------------------------------------- > > Key: WFLY-11858 > URL: https://issues.jboss.org/browse/WFLY-11858 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Transactions > Affects Versions: 16.0.0.Final > Reporter: Rakesh K. Cherukuri > Assignee: Matej Novotny > Priority: Major > Attachments: stacktrace.log > > > We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error > _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_ > In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error. > Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself. > Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :) > Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4380) Remove dependency on separate WildFly Elytron Tool

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-4380: ---------------------------------------- Summary: Remove dependency on separate WildFly Elytron Tool Key: WFCORE-4380 URL: https://issues.jboss.org/browse/WFCORE-4380 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 9.0.0.Beta2 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11858) [Wildfly16] CDI fails to inject InitialContext during startup

by Laird Nelson (Jira)

[ https://issues.jboss.org/browse/WFLY-11858?page=com.atlassian.jira.plugin... ] Laird Nelson edited comment on WFLY-11858 at 3/20/19 1:11 PM: -------------------------------------------------------------- One possibility for an immediate workaround (I haven't tried it) might be to throw a quick portable extension together that programmatically adds {{@Dependent}} to the {{InitialContext}} class. This should make {{InitialContext}} be discovered and used directly instead of the {{AbstractBean}} subclass implementation. was (Author: ljnelson): One possibility for an immediate workaround (I haven't tried it) might be to throw a quick portable extension together that programmatically adds `@Dependent` to the `InitialContext` class. This should make `InitialContext` be discovered and used directly instead of the `AbstractBean` subclass. > [Wildfly16] CDI fails to inject InitialContext during startup > ------------------------------------------------------------- > > Key: WFLY-11858 > URL: https://issues.jboss.org/browse/WFLY-11858 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Transactions > Affects Versions: 16.0.0.Final > Reporter: Rakesh K. Cherukuri > Assignee: Matej Novotny > Priority: Major > Attachments: stacktrace.log > > > We are in the process of upgrading from 14.0.1.Final. While Wildfly 15.0.1 works fine, 16.0.0.Final is intermittently (3 out of 5 times) failing to start with following error > _WELD-001334: Unsatisfied dependencies for type InitialContext with qualifiers_ > In our application, a bootstrap servlet startsup services (Stateless EJBs) during server startup. During this process the server fails to start with above error. > Basically CDI is not able to find the appropriate InitialContext bean *intermittently*. This is not failing in our application code but in the wildfly libraries itself. > Any pointers on this will be helpful. Don't want to end up with startup issues in stage/production :) > Unfortunately my efforts to come up with a simplified maven module to showcase the error didn't succeed. So, please let me know if any further information is required and i will be glad to fill it in. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019