July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13351) Add a Galleon layer for the Mail subsystem

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13351?page=com.atlassian.jira.plugi... ] Yeray Borges Santana updated WFLY-13351: ---------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13349 (was: https://github.com/wildfly/wildfly/pull/13233) > Add a Galleon layer for the Mail subsystem > ------------------------------------------ > > Key: WFLY-13351 > URL: https://issues.redhat.com/browse/WFLY-13351 > Project: WildFly > Issue Type: Feature Request > Components: Build System, Mail > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Major > Fix For: 21.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5538) DMN strongly typed class compile errors for collection types

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5538: ----------------------------------------- Summary: DMN strongly typed class compile errors for collection types Key: DROOLS-5538 URL: https://issues.redhat.com/browse/DROOLS-5538 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.40.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi If we have an itemDefinition with isCollection="true", it will cause a compile error for InputSet and OutputSet when typesafe is enabled. Note that itemComponent with isCollection="true" works fine. DMNRuntimeTypesTest.testCollectionType() {code:xml} <semantic:itemDefinition label="tPersonList" name="tPersonList" isCollection="true"> <semantic:typeRef>tPerson</semantic:typeRef> </semantic:itemDefinition> {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13707) Upgrade smallrye-open-api to 2.0.6

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13707?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13707: -------------------------------- Summary: Upgrade smallrye-open-api to 2.0.6 (was: Upgrade smallrye-open-api to 2.0.5) > Upgrade smallrye-open-api to 2.0.6 > ---------------------------------- > > Key: WFLY-13707 > URL: https://issues.redhat.com/browse/WFLY-13707 > Project: WildFly > Issue Type: Component Upgrade > Components: MP OpenAPI > Affects Versions: 20.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Fixes: > [https://github.com/smallrye/smallrye-open-api/issues/404] > > Release notes: > [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.4|https://...] > [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.5|https://...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5070) List to Set ParameterCorrectors and ParameterValidators

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-5070?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-5070: ------------------------------------- Description: The management API doesn't have a "SET" attribute/parameter type but use cases like JBEAP-19958 shows there's some need for a bit of set-like behavior. Idea here is the controller module could expose some static factories for ParameterCorrectors and ParameterValidators to impose set semantics on a ModelType.LIST attribute. A validator would be used to reject lists with duplicates. A corrector would be used to remove dups from a list without failing. For a corrector construction could perhaps be parameterized by allowing passing in the name of the attribute and a log level. Those would be used to log when the corrector removes duplicates. The corrector would definitely need to know the attribute name to log an appropriate message. The appropriate level for a message may vary based on the attribute. was: The management API doesn't have a "SET" attribute/parameter type but use cases like JBEAP-19958 shows there's some need. Idea here is the controller module could expose some static factories for ParameterCorrectors and ParameterValidators to impose set semantics on a ModelType.LIST attribute. A validator would be used to reject lists with duplicates. A corrector would be used to remove dups from a list without failing. For a corrector construction could perhaps be parameterized by allowing passing in the name of the attribute and a log level. Those would be used to log when the corrector removes duplicates. The corrector would definitely need to know the attribute name to log an appropriate message. The appropriate level for a message may vary based on the attribute. > List to Set ParameterCorrectors and ParameterValidators > ------------------------------------------------------- > > Key: WFCORE-5070 > URL: https://issues.redhat.com/browse/WFCORE-5070 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Minor > > The management API doesn't have a "SET" attribute/parameter type but use cases like JBEAP-19958 shows there's some need for a bit of set-like behavior. > Idea here is the controller module could expose some static factories for ParameterCorrectors and ParameterValidators to impose set semantics on a ModelType.LIST attribute. > A validator would be used to reject lists with duplicates. > A corrector would be used to remove dups from a list without failing. > For a corrector construction could perhaps be parameterized by allowing passing in the name of the attribute and a log level. Those would be used to log when the corrector removes duplicates. The corrector would definitely need to know the attribute name to log an appropriate message. The appropriate level for a message may vary based on the attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5070) List to Set ParameterCorrectors and ParameterValidators

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-5070: ---------------------------------------- Summary: List to Set ParameterCorrectors and ParameterValidators Key: WFCORE-5070 URL: https://issues.redhat.com/browse/WFCORE-5070 Project: WildFly Core Issue Type: Enhancement Components: Management Reporter: Brian Stansberry Assignee: Jeff Mesnil The management API doesn't have a "SET" attribute/parameter type but use cases like JBEAP-19958 shows there's some need. Idea here is the controller module could expose some static factories for ParameterCorrectors and ParameterValidators to impose set semantics on a ModelType.LIST attribute. A validator would be used to reject lists with duplicates. A corrector would be used to remove dups from a list without failing. For a corrector construction could perhaps be parameterized by allowing passing in the name of the attribute and a log level. Those would be used to log when the corrector removes duplicates. The corrector would definitely need to know the attribute name to log an appropriate message. The appropriate level for a message may vary based on the attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5067) Wildfly as Windows Service fails to stop in a timely fashion

by Cedric HENRY (Jira)

[ https://issues.redhat.com/browse/WFCORE-5067?page=com.atlassian.jira.plug... ] Cedric HENRY updated WFCORE-5067: --------------------------------- Affects Version/s: 2.2.0.Final > Wildfly as Windows Service fails to stop in a timely fashion > ------------------------------------------------------------ > > Key: WFCORE-5067 > URL: https://issues.redhat.com/browse/WFCORE-5067 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.2.0.Final > Reporter: Cedric HENRY > Assignee: Jeff Mesnil > Priority: Major > > As already discussed under WFCORE-1719, there a problem when stopping the 'Wildfly' Windows service resulting in error dialog about the service not stopping in a timely fashion. > Further details got also provided in the comment https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId=143... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2495) A variant of RELAY2.printTopology() returning a member list

by S Pokutniy (Jira)

[ https://issues.redhat.com/browse/JGRP-2495?page=com.atlassian.jira.plugin... ] S Pokutniy updated JGRP-2495: ----------------------------- I suppose I misunderstood how RELAY2 works - for some reason I thought that it was possible to send from LON site to a specific member in SFO site (using scenario in [http://www.jgroups.org/manual/html/user-advanced.html#Relay2Advanced)... But the idea behind RELAY2 is probably not to do it and to send from LON to site master of SFO, which means of course that sending to a specific member in SFO is not possible, as we simply don't have the address of that member in LON (the addresses are generated with every start and thus cannot be re-constructed at other side). If so, please accept my apologies and close the request. > A variant of RELAY2.printTopology() returning a member list > ----------------------------------------------------------- > > Key: JGRP-2495 > URL: https://issues.redhat.com/browse/JGRP-2495 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.0.24 > Reporter: S Pokutniy > Assignee: Bela Ban > Priority: Minor > > It would be great if there existed a variant of A variant of RELAY2.printTopology() function, returning a list of all members with their logical names and physical addresses. As of now printTopology(boolean) returns a string with all members. Even though the members of one site do not know about the members of the other site, it would still be great to be able to show the list of all members connected over the bridge, be it for demonstration or monitoring purpose. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5067) Wildfly as Windows Service fails to stop in a timely fashion

by Cedric HENRY (Jira)

[ https://issues.redhat.com/browse/WFCORE-5067?page=com.atlassian.jira.plug... ] Cedric HENRY updated WFCORE-5067: --------------------------------- Affects: Documentation (Ref Guide, User Guide, etc.),Compatibility/Configuration > Wildfly as Windows Service fails to stop in a timely fashion > ------------------------------------------------------------ > > Key: WFCORE-5067 > URL: https://issues.redhat.com/browse/WFCORE-5067 > Project: WildFly Core > Issue Type: Bug > Reporter: Cedric HENRY > Assignee: Jeff Mesnil > Priority: Major > > As already discussed under WFCORE-1719, there a problem when stopping the 'Wildfly' Windows service resulting in error dialog about the service not stopping in a timely fashion. > Further details got also provided in the comment https://issues.redhat.com/browse/WFCORE-1719?focusedCommentId=143... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5069) libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-5069?page=com.atlassian.jira.plug... ] Farah Juma moved WFSSL-38 to WFCORE-5069: ----------------------------------------- Project: WildFly Core (was: WildFly OpenSSL) Key: WFCORE-5069 (was: WFSSL-38) Fix Version/s: (was: 1.1.1.Final) > libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider > ------------------------------------------------------------------------------------- > > Key: WFCORE-5069 > URL: https://issues.redhat.com/browse/WFCORE-5069 > Project: WildFly Core > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > > Looks like detection of `libwfssl` is broken in current build. When I try to configure OpenSSL security provider in legacy security, I can see following errors in standalone.log: > {code:java} > 15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748)Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) at java.security.Provider$Service.newInstance(Provider.java:1617) at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at sun.security.jca.GetInstance.getInstance(GetInstance.java:164) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105) ... 8 moreCaused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.wildfly.openssl.SSL.init(SSL.java:87) at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129) at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi.<init>(OpenSSLContextSPI.java:484) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.security.Provider$Service.newInstance(Provider.java:1595) ... 12 moreCaused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.wildfly.openssl.SSL.init(SSL.java:82) ... 19 moreCaused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1124) at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288) ... 24 more > 15:39:44,818 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("core-service" => "management"), ("security-realm" => "ApplicationRealm")]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context" => "WFLYDM0018: Unable to start service Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException Caused by: java.lang.reflect.InvocationTargetException Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path"}} {code} > > This is a regression against previous release - {{EAP7.3.1}}. Expected behaviour is no error in the log, libwfssl is loaded successfully and OpenSSL is correctly used for TLS connections. > Note - there has been a change in the location of the particular libwfssl native binaries in the distribution, see https://github.com/wildfly-security/wildfly-openssl/commit/c5c07d3dc0d637... > {code:title=7.3.1} > $ find . -name *wfssl* > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-i386/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so > {code} > and > {code:title=7.4.0.CD20-CR1} > $ find . -name *ssl* > ./modules/system/layers/base/org/wildfly/openssl > ./modules/system/layers/base/org/wildfly/openssl/main/wildfly-openssl-java-1.1.0.Final-redhat-00001.jar > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el8-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el7-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-i386/libwfssl.so > ./modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-ssl-1.12.1.Final-redhat-00001.jar > {code} > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13128) Add a Galleon layer for batch-jberet

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13128?page=com.atlassian.jira.plugi... ] Yeray Borges Santana updated WFLY-13128: ---------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13434 (was: https://github.com/wildfly/wildfly/pull/13016) > Add a Galleon layer for batch-jberet > ------------------------------------ > > Key: WFLY-13128 > URL: https://issues.redhat.com/browse/WFLY-13128 > Project: WildFly > Issue Type: Feature Request > Components: Batch > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Major > Fix For: 21.0.0.Beta1 > > > I saw a community request for a Galleon layer for batch-jberet so let's make it first in the set we add to complete coverage of the various subsystems. > Besides the usual layer smoke tests, we can provision a cloud-server+batch-jberet server in testsuite/integration/basic and run most of the batch tests there against it. There are 4 that won't run because they use EJB, Agroal or the org.jboss.remoting3 module, none of which would be provisioned. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2020