July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4800) [DMN Designer] Add support for copy and paste in grids

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4800?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4800: ------------------------------------ Description: Add support for copying/pasting between cells in grids. The implementation should re-use and integrate with the existing Stunner mechanism (i.e. if there are toolbar buttons to copy/paste nodes they should be re-used to copy/paste cells when in the grid view. Copying a grid cell(s) should probably replace any _node_ content on the virtual clipboard and vice-versa. In addition to toolbar buttons the feature should probably be also exposed on a context-menu and keyboard short-cuts... Pasting a cell into another should only be possible where the type of cell is compatible. I.E. you cannot paste an expression cell (e.g. nested Decision Table on a ContextEntry) into a literal cell (e.g. Relation grid cell); however should be possible to past a whole grid (literal expression, decision table, etc) to replace an undefined grid. was: Add support for copying/pasting between cells in grids. The implementation should re-use and integrate with the existing Stunner mechanism (i.e. if there are toolbar buttons to copy/paste nodes they should be re-used to copy/paste cells when in the grid view. Copying a grid cell(s) should probably replace any _node_ content on the virtual clipboard and vice-versa. In addition to toolbar buttons the feature should probably be also exposed on a context-menu and keyboard short-cuts... Pasting a cell into another should only be possible where the type of cell is compatible. I.E. you cannot paste an expression cell (e.g. nested Decision Table on a ContextEntry) into a literal cell (e.g. Relation grid cell). > [DMN Designer] Add support for copy and paste in grids > ------------------------------------------------------ > > Key: DROOLS-4800 > URL: https://issues.redhat.com/browse/DROOLS-4800 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.30.0.Final > Reporter: Michael Anstis > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > Add support for copying/pasting between cells in grids. > The implementation should re-use and integrate with the existing Stunner mechanism (i.e. if there are toolbar buttons to copy/paste nodes they should be re-used to copy/paste cells when in the grid view. Copying a grid cell(s) should probably replace any _node_ content on the virtual clipboard and vice-versa. In addition to toolbar buttons the feature should probably be also exposed on a context-menu and keyboard short-cuts... > Pasting a cell into another should only be possible where the type of cell is compatible. I.E. you cannot paste an expression cell (e.g. nested Decision Table on a ContextEntry) into a literal cell (e.g. Relation grid cell); however should be possible to past a whole grid (literal expression, decision table, etc) to replace an undefined grid. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13612) Bean Validation Problem In EJB inheritance

by Ivo Studensky (Jira)

[ https://issues.redhat.com/browse/WFLY-13612?page=com.atlassian.jira.plugi... ] Ivo Studensky edited comment on WFLY-13612 at 7/2/20 2:59 PM: -------------------------------------------------------------- If a stateless EJB implements an interface of a JAX-RS resource it gets a proxy created with a superclass being {{java.lang.Object}} due to the following code in {{DefaultComponentViewConfigurator}}: {code:java} //we define it in the modules class loader to prevent permgen leaks L92: if (viewClass.isInterface()) { proxyConfiguration.setSuperClass(Object.class); proxyConfiguration.addAdditionalInterface(viewClass); viewConfiguration = view.createViewConfiguration(viewClass, configuration, new ProxyFactory(proxyConfiguration)); } else { proxyConfiguration.setSuperClass(viewClass); viewConfiguration = view.createViewConfiguration(viewClass, configuration, new ProxyFactory(proxyConfiguration)); } {code} This leads to a {{java.lang.Object}} returned from {{EjbProxyBeanMetaDataClassNormalizer.normalize()}}: {code:java} public <T> Class<? super T> normalize(Class<T> clazz) { L56: if (EjbProxy.class.isAssignableFrom(clazz)) { return clazz.getSuperclass(); } return clazz; } {code} Which then denies the validation. I can't see any reasonable fix instead of setting the superclass of the proxy to the {{viewClass}}. I've tried to kick up a dirty fix and tests, but that effectively disables the WFLY-11566 fix for cases with a interface, see https://github.com/istudens/wildfly/commit/da2308e37a690b07892b67e66ecfb4... was (Author: istudens): If a stateless EJB implements an interface of a JAX-RS resource it gets a proxy created with a superclass being {{java.lang.Object}} due to the following code in {{DefaultComponentViewConfigurator}}: {code:java} //we define it in the modules class loader to prevent permgen leaks L92: if (viewClass.isInterface()) { proxyConfiguration.setSuperClass(Object.class); proxyConfiguration.addAdditionalInterface(viewClass); viewConfiguration = view.createViewConfiguration(viewClass, configuration, new ProxyFactory(proxyConfiguration)); } else { proxyConfiguration.setSuperClass(viewClass); viewConfiguration = view.createViewConfiguration(viewClass, configuration, new ProxyFactory(proxyConfiguration)); } {code} This leads to a {{java.lang.Object}} returned from {{EjbProxyBeanMetaDataClassNormalizer.normalize()}}: {code:java} public <T> Class<? super T> normalize(Class<T> clazz) { L56: if (EjbProxy.class.isAssignableFrom(clazz)) { return clazz.getSuperclass(); } return clazz; } {code} Which then denies the validation. I can't see any reasonable fix instead of setting the superclass of the proxy to the {{viewClass}}. I've tried to kick up a dirty fix and tests, but that effectively disables the WFLY-11566 fix for cases with a interface, see > Bean Validation Problem In EJB inheritance > ------------------------------------------ > > Key: WFLY-13612 > URL: https://issues.redhat.com/browse/WFLY-13612 > Project: WildFly > Issue Type: Bug > Components: Bean Validation > Affects Versions: 20.0.0.Final > Reporter: huaxu wu > Assignee: Ivo Studensky > Priority: Major > > > {code:java} > @Path("/test_action") > public interface TestResource { > @Path("test") > @POST > @Consumes(MediaType.APPLICATION_FORM_URLENCODED) > @Produces(MediaType.APPLICATION_JSON) > GeneralOperationResult test2(@FormParam("asdf") @NotBlank String asdf); > } > {code} > {code:java} > @Stateless > public class TestResourceImpl implements TestResource { > @Override > public GeneralOperationResult test2(String asdf) { > return GeneralOperationResult.createSuccess("test"); > } > } > {code} > The above code, the @NotBlank annotation works on wildfly19, but not on wildfly20. > To make it work on wildfly20, I must add @NotBlank annotation to the override method. > I wonder it's bug or it's your design? > The above code, If I remove the @Stateless annotation, the @NotBlank annotation works as expectd. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13612) Bean Validation Problem In EJB inheritance

by Ivo Studensky (Jira)

[ https://issues.redhat.com/browse/WFLY-13612?page=com.atlassian.jira.plugi... ] Ivo Studensky commented on WFLY-13612: -------------------------------------- If a stateless EJB implements an interface of a JAX-RS resource it gets a proxy created with a superclass being {{java.lang.Object}} due to the following code in {{DefaultComponentViewConfigurator}}: {code:java} //we define it in the modules class loader to prevent permgen leaks L92: if (viewClass.isInterface()) { proxyConfiguration.setSuperClass(Object.class); proxyConfiguration.addAdditionalInterface(viewClass); viewConfiguration = view.createViewConfiguration(viewClass, configuration, new ProxyFactory(proxyConfiguration)); } else { proxyConfiguration.setSuperClass(viewClass); viewConfiguration = view.createViewConfiguration(viewClass, configuration, new ProxyFactory(proxyConfiguration)); } {code} This leads to a {{java.lang.Object}} returned from {{EjbProxyBeanMetaDataClassNormalizer.normalize()}}: {code:java} public <T> Class<? super T> normalize(Class<T> clazz) { L56: if (EjbProxy.class.isAssignableFrom(clazz)) { return clazz.getSuperclass(); } return clazz; } {code} Which then denies the validation. I can't see any reasonable fix instead of setting the superclass of the proxy to the {{viewClass}}. I've tried to kick up a dirty fix and tests, but that effectively disables the WFLY-11566 fix for cases with a interface, see > Bean Validation Problem In EJB inheritance > ------------------------------------------ > > Key: WFLY-13612 > URL: https://issues.redhat.com/browse/WFLY-13612 > Project: WildFly > Issue Type: Bug > Components: Bean Validation > Affects Versions: 20.0.0.Final > Reporter: huaxu wu > Assignee: Ivo Studensky > Priority: Major > > > {code:java} > @Path("/test_action") > public interface TestResource { > @Path("test") > @POST > @Consumes(MediaType.APPLICATION_FORM_URLENCODED) > @Produces(MediaType.APPLICATION_JSON) > GeneralOperationResult test2(@FormParam("asdf") @NotBlank String asdf); > } > {code} > {code:java} > @Stateless > public class TestResourceImpl implements TestResource { > @Override > public GeneralOperationResult test2(String asdf) { > return GeneralOperationResult.createSuccess("test"); > } > } > {code} > The above code, the @NotBlank annotation works on wildfly19, but not on wildfly20. > To make it work on wildfly20, I must add @NotBlank annotation to the override method. > I wonder it's bug or it's your design? > The above code, If I remove the @Stateless annotation, the @NotBlank annotation works as expectd. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13641) WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml

by Jens Viebig (Jira)

Jens Viebig created WFLY-13641: ---------------------------------- Summary: WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml Key: WFLY-13641 URL: https://issues.redhat.com/browse/WFLY-13641 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 20.0.0.Final Reporter: Jens Viebig Assignee: Matěj Novotný When referencing a jar with CDI scan mode "annotaded" inside an ear from an external war via jboss-deployment-structure.xml a warning will be printed for every class: WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml Seems VFS cannot get hold of the classes. The warning is logged in ExternalBeanArchiveProcessor which catches an EOFException from the inputstream loading the class. (Line 284). Seems the input stream is not able to load a single byte from the class -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2486: --------------------------- Workaround Description: Lukas's fix applied to the 4.x branch Fix Version/s: 4.2.5 > FD Monitor get stuck on TrasferQueueBundler > ------------------------------------------- > > Key: JGRP-2486 > URL: https://issues.redhat.com/browse/JGRP-2486 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.22 > Reporter: lukas brandl > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.5, 4.0.24 > > Attachments: Main.java, stack-trace.txt > > > Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected. > The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1191) Automate AuthPolicy https://github.com/kiali/kiali/pull/2938

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1191?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1191: --------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/306 > Automate AuthPolicy https://github.com/kiali/kiali/pull/2938 > ------------------------------------------------------------ > > Key: SWSQE-1191 > URL: https://issues.redhat.com/browse/SWSQE-1191 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1190) Automate ServiceEntry to KIA1107

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1190?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1190: --------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/306 > Automate ServiceEntry to KIA1107 > -------------------------------- > > Key: SWSQE-1190 > URL: https://issues.redhat.com/browse/SWSQE-1190 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > https://github.com/kiali/kiali/pull/2931 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1190) Automate ServiceEntry to KIA1107

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1190?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan reassigned SWSQE-1190: ------------------------------------- Assignee: Hayk Hovsepyan > Automate ServiceEntry to KIA1107 > -------------------------------- > > Key: SWSQE-1190 > URL: https://issues.redhat.com/browse/SWSQE-1190 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > https://github.com/kiali/kiali/pull/2931 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ] Paul Ferraro commented on WFLY-13638: ------------------------------------- [~rhn-support-rhsilva] While I agree with you, i.e. exposing the /openapi endpoint at the context root instead of the host root makes a lot of sense for a traditional application server (as opposed to a single deployment MicroProfile container (e.g. Quarkus, ThornTail, etc.), this would unfortunately violate the MicroProfile OpenAPI specification. Instead, the specification indicates that the OpenAPI endpoint should return documentation of all REST endpoints available from the host (including all contexts deployed to that host). We don't yet have the ability to merge the OpenAPI model for each application, but that is currently the plan. > Permit multiples applications to the same server registry a MP openapi endpoint > ------------------------------------------------------------------------------- > > Key: WFLY-13638 > URL: https://issues.redhat.com/browse/WFLY-13638 > Project: WildFly > Issue Type: Feature Request > Components: MP OpenAPI > Affects Versions: 20.0.0.Final > Reporter: Rhuan Rocha > Assignee: Paul Ferraro > Priority: Major > > In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code: > [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] > > It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1193) Kiali make target "dep-install" No Longer Supported in with PR 2951

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1193?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1193. ---------------------------------- Resolution: Done The build will not fail when the PR is merged now - https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/-/commi... > Kiali make target "dep-install" No Longer Supported in with PR 2951 > -------------------------------------------------------------------- > > Key: SWSQE-1193 > URL: https://issues.redhat.com/browse/SWSQE-1193 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matthew Mahoney > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > With Kiali PR [2951|https://github.com/kiali/kiali/pull/2951], make target "dep-install" will no longer be supported. Thus. the Jenkins build job must change, otherwise all kiali builds will fail. > > See @edgarhz for more details. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

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