March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11926) Upgrade ejb-client to 4.0.16.Final

by Kabir Khan (Jira)

[ https://issues.jboss.org/browse/WFLY-11926?page=com.atlassian.jira.plugin... ] Kabir Khan resolved WFLY-11926. ------------------------------- Fix Version/s: 17.0.0.Beta1 Resolution: Done > Upgrade ejb-client to 4.0.16.Final > ---------------------------------- > > Key: WFLY-11926 > URL: https://issues.jboss.org/browse/WFLY-11926 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: Kabir Khan > Assignee: Tomasz Adamski > Priority: Blocker > Fix For: 17.0.0.Beta1 > > > [~tomekadamski] Please link the issues fixed to this -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11926) Upgrade ejb-client to 4.0.16.Final

by Kabir Khan (Jira)

Kabir Khan created WFLY-11926: --------------------------------- Summary: Upgrade ejb-client to 4.0.16.Final Key: WFLY-11926 URL: https://issues.jboss.org/browse/WFLY-11926 Project: WildFly Issue Type: Component Upgrade Components: EJB Reporter: Kabir Khan Assignee: Tomasz Adamski [~tomekadamski] Please link the issues fixed to this -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11906) Managed Executor Task Fails with CDI if created from Batchlet

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-11906?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-11906: ----------------------------------- Yes, I will look into any problems in batch subsystem. > Managed Executor Task Fails with CDI if created from Batchlet > ------------------------------------------------------------- > > Key: WFLY-11906 > URL: https://issues.jboss.org/browse/WFLY-11906 > Project: WildFly > Issue Type: Bug > Components: Batch, CDI / Weld, Concurrency Utilities > Affects Versions: 16.0.0.Final > Environment: Java 8 > Reporter: Cody Lerum > Assignee: Cheng Fang > Priority: Major > > This previously was working (verified in reproducer) on Wildfly 14.0.1 > Inside of a batchlet if a Managed Executor Task is executed and that Task uses CDI.current() an exception is thrown > {code:java} > 11:00:02,343 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) java.lang.IllegalStateException: WFLYWELD0039: Singleton not set for ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @78e94dcf (finder: local module finder @233fe9b6 (roots: V:\opt\wildfly-16.0.0.Final\modules,V:\opt\wildfly-16.0.0.Final\modules\system\layers\base)). This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:77) > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:134) > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.weld.Container.instance(Container.java:57) > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.WeldProvider.getCDI(WeldProvider.java:69) > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$0(CDI.java:87) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.TreeMap$KeySpliterator.tryAdvance(TreeMap.java:2770) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:88) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.current(CDI.java:64) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at com.outjected.demo.DemoTask.run(DemoTask.java:27) > 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105) > 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) > 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run(FutureTask.java) > 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141) > 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.lang.Thread.run(Thread.java:748) > 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) > 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:85) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11925) Add documentation to the "Using the Elytron Subsystem" section on the attributes that can be specified when configuring server and client SSLContexts

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFLY-11925?page=com.atlassian.jira.plugin... ] Farah Juma updated WFLY-11925: ------------------------------ Summary: Add documentation to the "Using the Elytron Subsystem" section on the attributes that can be specified when configuring server and client SSLContexts (was: Add documentation to the "Using the Elytron Subsystem" on the attributes that can be specified when configuring server and client SSLContexts) > Add documentation to the "Using the Elytron Subsystem" section on the attributes that can be specified when configuring server and client SSLContexts > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11925 > URL: https://issues.jboss.org/browse/WFLY-11925 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > > Add documentation to the "Using the Elytron Subsystem" section on the attributes that can be specified when configuring a {{server-ssl-context}} and a {{client-ssl-context}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11925) Add documentation to the "Using the Elytron Subsystem" on the attributes that can be specified when configuring server and client SSLContexts

by Farah Juma (Jira)

Farah Juma created WFLY-11925: --------------------------------- Summary: Add documentation to the "Using the Elytron Subsystem" on the attributes that can be specified when configuring server and client SSLContexts Key: WFLY-11925 URL: https://issues.jboss.org/browse/WFLY-11925 Project: WildFly Issue Type: Task Components: Security Reporter: Farah Juma Assignee: Farah Juma Add documentation to the "Using the Elytron Subsystem" section on the attributes that can be specified when configuring a {{server-ssl-context}} and a {{client-ssl-context}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11924) Add ability to group distributed session attributes to avoid cost of SESSION granularity

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-11924: ----------------------------------- Summary: Add ability to group distributed session attributes to avoid cost of SESSION granularity Key: WFLY-11924 URL: https://issues.jboss.org/browse/WFLY-11924 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 16.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Since SESSION granularity requires the replication of *all* session attribute if *any* attribute was modified in a given request, most distributed web applications should leverage ATTRIBUTE granularity whenever to possible to reduce the replication payload costs per request. However, if session attribute contains any reference to another session attribute, they are forced to use SESSION granularity to avoid losing referential integrity on failover and duplication of serialized data. The proposal is to allow users the ability to annotate their session attribute classes such that they can group specific attribute together, while still being able to leverage ATTRIBUTE granularity for the remainder of their session attributes. >From the user's perspective, I envision something like this: {code:java} @SessionAttributeGroup("order") public class Order implements Serializable { List<OrderItem> items; } @SessionAttributeGroup("order") public class OrderItem implements Serializable { //... } {code} Thus the code: {code:java} session.setAttribute("order", order); session.setAttribute("customized-item", item); {code} will result in both attributes being store within a single cache entry. Internally, we use the @SessionAttributeGroup as the attribute name, and a Map<String, Object> as the attribute value, keyed by the actual attribute name. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4309) Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFCORE-4309?page=com.atlassian.jira.plugi... ] Jan Stourac commented on WFCORE-4309: ------------------------------------- Thanks for this fix, although I am afraid that since issues WFWIP-102 and WFCORE-4302 have not been resolved (and probably will be rejected) the hostname provided has to be entered in a regular expression format. In such case the introduced validation is too strict as even simple escaping characters (double backslash) are not allowed now. In this context, implementation of this needs to be either updated or the introduced validation removed completely. > Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource > ------------------------------------------------------------------------------------- > > Key: WFCORE-4309 > URL: https://issues.jboss.org/browse/WFCORE-4309 > Project: WildFly Core > Issue Type: Enhancement > Components: Security > Affects Versions: 7.0.0.Final > Reporter: Jan Stourac > Assignee: Diana Vilkolakova > Priority: Minor > Fix For: 9.0.0.Beta2 > > > There is not validation for 'host-context-map' property values on key side. There is validation for the values that represents 'server-ssl-contexts', although, there is no validation for host matching part. E.g. writing attribute of this value is possible: > {code} > /subsystem=elytron/server-ssl-sni-context=serverSslSniCtx:write-attribute(name=host-context-map,value={"\\?.example.com"=validSslContext,"..example.com"="validSslContext", "\\*\\*.example.com"=validSslContext}) > {code} > {code} > "\\?.example.com" > "..example.com" > "\\*\\*.example.com" > {code} > even though, these are invalid host name matchers IMHO. It would be nice to identify these and report those to user immediately during the configuration attempt. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11923) Elytron JDBC Realm hex encoding and modular crypt support.

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11923?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFLY-11923: ------------------------------------ Labels: (was: EAP-CD17) > Elytron JDBC Realm hex encoding and modular crypt support. > ---------------------------------------------------------- > > Key: WFLY-11923 > URL: https://issues.jboss.org/browse/WFLY-11923 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > > This relates to the following issues: - > https://issues.jboss.org/browse/WFCORE-3542 > https://issues.jboss.org/browse/WFCORE-3832 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11923) Elytron JDBC Realm hex encoding and modular crypt support.

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11923?page=com.atlassian.jira.plugin... ] Darran Lofthouse moved EAP7-1234 to WFLY-11923: ----------------------------------------------- Project: WildFly (was: EAP 7 Planning Pilot) Key: WFLY-11923 (was: EAP7-1234) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0) Component/s: Security (was: Security) EAP PT Pre-Checked (PC): (was: TODO) Target Release: (was: 7.3.0.GA) EAP PT Community Docs (CD): (was: TODO) EAP PT Product Docs (PD): (was: New) EAP PT Test Dev (TD): (was: TODO) EAP PT Docs Analysis (DA): (was: TODO) EAP PT Test Plan (TP): (was: TODO) EAP PT Analysis Document (AD): (was: TODO) Writer: (was: Chuck Copello) > Elytron JDBC Realm hex encoding and modular crypt support. > ---------------------------------------------------------- > > Key: WFLY-11923 > URL: https://issues.jboss.org/browse/WFLY-11923 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Labels: EAP-CD17 > > This relates to the following issues: - > https://issues.jboss.org/browse/WFCORE-3542 > https://issues.jboss.org/browse/WFCORE-3832 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4302) SNI wildcard mappings match multiple level of subdomain

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFCORE-4302?page=com.atlassian.jira.plugi... ] Jan Stourac commented on WFCORE-4302: ------------------------------------- [~mmazanek], I understand your point. Although, actually the correct variant is: {code} host-context-map={".*\\..*\\.example\\.com"=defaultSSC, "[^.]*\\.example\\.com"=asteriskSSC} {code} or simply {code} host-context-map={"[^.]*\\.example\\.com"=asteriskSSC} {code} Yeah... so user has to be aware that he has to provide correct regular expression instead of a simple notation. > SNI wildcard mappings match multiple level of subdomain > ------------------------------------------------------- > > Key: WFCORE-4302 > URL: https://issues.jboss.org/browse/WFCORE-4302 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 7.0.0.Final > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Pavel Jelinek > Assignee: Martin Mazanek > Priority: Major > Labels: SNI > > Based on the [text from analasys|https://github.com/wildfly/wildfly-proposals/blob/master/securit...]: > {quote} > Wildcard names use * as a wildcard, and can only be used to match a single level of subdomain in much the same way as with wildcard certificates. > {quote} > As such, in case I have configured SNI mapping for: > {code} > .*\\.example\\.com > {code} > I expect that this mapping is selected for any single level of subdomain of example.com although, in case of any extra subdomain, this mapping is not utilized. In other words, following hostnames should match: > {code} > test.example.com > another-test.example.com > {code} > although following should not be matched and default server-ssl-context shall be used instead: > {code} > two-sublevel.one-sublevel.example.com > {code} > Current behaviour also matches also 'two-sublevel.one-sublevel.example.com'. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019