[JBoss JIRA] (DROOLS-4916) Investigate modify parsing bug in executable model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4916?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-4916:
--------------------------------------
Description:
{noformat}
declare Application
categories : Set = new HashSet()
{noformat}
Then I had a modify statement scattered about:
{noformat}
modify ($a) {
$a.getCategories().add("hello");
}
{noformat}
The ExecutableModel did not seem to like any of those. I changed it to:
{noformat}
$a.getCategories().add("hello");
update($a);
{noformat}
was:
declare Application
categories : Set = new HashSet()
Then I had a modify statement scattered about:
modify ($a) {
$a.getCategories().add("hello");
}
The ExecutableModel did not seem to like any of those. I changed it to:
$a.getCategories().add("hello");
update($a);
> Investigate modify parsing bug in executable model
> --------------------------------------------------
>
> Key: DROOLS-4916
> URL: https://issues.redhat.com/browse/DROOLS-4916
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: good-first-issue
>
> {noformat}
> declare Application
> categories : Set = new HashSet()
> {noformat}
> Then I had a modify statement scattered about:
> {noformat}
> modify ($a) {
> $a.getCategories().add("hello");
> }
> {noformat}
> The ExecutableModel did not seem to like any of those. I changed it to:
> {noformat}
> $a.getCategories().add("hello");
> update($a);
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-4916) Investigate modify parsing bug in executable model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4916?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-4916:
--------------------------------------
Description:
{noformat}
declare Application
categories : Set = new HashSet()
end
{noformat}
Then I had a modify statement scattered about:
{noformat}
modify ($a) {
$a.getCategories().add("hello");
}
{noformat}
The ExecutableModel did not seem to like any of those. I changed it to:
{noformat}
$a.getCategories().add("hello");
update($a);
{noformat}
was:
{noformat}
declare Application
categories : Set = new HashSet()
{noformat}
Then I had a modify statement scattered about:
{noformat}
modify ($a) {
$a.getCategories().add("hello");
}
{noformat}
The ExecutableModel did not seem to like any of those. I changed it to:
{noformat}
$a.getCategories().add("hello");
update($a);
{noformat}
> Investigate modify parsing bug in executable model
> --------------------------------------------------
>
> Key: DROOLS-4916
> URL: https://issues.redhat.com/browse/DROOLS-4916
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Toshiya Kobayashi
> Priority: Major
> Labels: good-first-issue
>
> {noformat}
> declare Application
> categories : Set = new HashSet()
> end
> {noformat}
> Then I had a modify statement scattered about:
> {noformat}
> modify ($a) {
> $a.getCategories().add("hello");
> }
> {noformat}
> The ExecutableModel did not seem to like any of those. I changed it to:
> {noformat}
> $a.getCategories().add("hello");
> update($a);
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13301) Remove setting Metaspace
by Moulali Shikalwadi (Jira)
Moulali Shikalwadi created WFLY-13301:
-----------------------------------------
Summary: Remove setting Metaspace
Key: WFLY-13301
URL: https://issues.redhat.com/browse/WFLY-13301
Project: WildFly
Issue Type: Enhancement
Reporter: Moulali Shikalwadi
Assignee: Moulali Shikalwadi
Unlike perm gen, it is typically not necessary to set a max/min metaspace size[1] for the following reasons:
*Metaspace size is unlimited by default. Since it only holds class metadata, size requirements are minimal.
*It does not require a full gc to resize the metaspace, as it did with the perm generation.
MaxMetaspaceSize includes CompressedClassSpaceSize, so MaxMetaspaceSize should be larger than CompressedClassSpaceSize.
The default MaxMetaspaceSize is 1g:
java -XX:+PrintFlagsFinal -version | grep CompressedClassSpaceSize
uintx CompressedClassSpaceSize = 1073741824
{product}
If MaxMetaspaceSize is set smaller than CompressedClassSpaceSize, the JVM auto adjusts CompressedClassSpaceSize as follows: CompressedClassSpaceSize = MaxMetaspaceSize - (2 * InitialBootClassLoaderMetaspaceSize).[2]
The default EAP Metaspace sizes are less than the default CompressedClassSpaceSize:
-XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
This adjusts down the MaxMetaspaceSize to 248m:
java -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -XX:+PrintFlagsFinal -version | grep CompressedClassSpaceSize
uintx CompressedClassSpaceSize := 260046848 {product}
We have had a lot of OOME Metaspace cases[3], and support is no longer recommending customers set Metaspace:
"In general, you should not need to set a maximum size, unless you are experiencing large metaspace leaks and would prefer it to fail rather than keep increasing memory size."[1]
This was discussed with the OpenJDK developers[4], and their recommendation was to remove the Metaspace settings, and especially in the context of containers.
References:
[1]https://access.redhat.com/solutions/1489263
[2]https://access.redhat.com/solutions/2132101
[3]https://access.redhat.com/solutions/2038983
[4]http://post-office.corp.redhat.com/archives/support-openjdk/2019-July/m...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
I have created PR with hibernate-validator update: https://github.com/wildfly/wildfly/pull/13155
After it is merged I will push my WildFly stuff.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5201) ZipException is thrown when guided asset is opened
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5201?page=com.atlassian.jira.plug... ]
Michael Anstis commented on DROOLS-5201:
----------------------------------------
[~jomarko] OK, I've managed now to try with Business Central 7.36.0-SNAPSHOT built from {{master}}.
I could not replicate the problem. Could you please retry?
> ZipException is thrown when guided asset is opened
> --------------------------------------------------
>
> Key: DROOLS-5201
> URL: https://issues.redhat.com/browse/DROOLS-5201
> Project: Drools
> Issue Type: Bug
> Components: Guided Template Editor
> Affects Versions: 7.36.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2020-03-27 15-30-54.png, error.log
>
>
> User is unable to work with guided editors. Always guided editor is opened, this exception is thrown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5201) ZipException is thrown when guided asset is opened
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5201?page=com.atlassian.jira.plug... ]
Michael Anstis commented on DROOLS-5201:
----------------------------------------
[~jomarko] I tried to replicate with {{drools-wb-webapp}} built from {{master}} however was unsuccessful; i.e. it worked fine.
I will endeavour to try with {{kie-wb-distributions}} 7.36.0-SNAPSHOT too.....
> ZipException is thrown when guided asset is opened
> --------------------------------------------------
>
> Key: DROOLS-5201
> URL: https://issues.redhat.com/browse/DROOLS-5201
> Project: Drools
> Issue Type: Bug
> Components: Guided Template Editor
> Affects Versions: 7.36.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2020-03-27 15-30-54.png, error.log
>
>
> User is unable to work with guided editors. Always guided editor is opened, this exception is thrown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-12835) HealthChecks in subdeployments are not registered
by charles ghislain (Jira)
[ https://issues.redhat.com/browse/WFLY-12835?page=com.atlassian.jira.plugi... ]
charles ghislain edited comment on WFLY-12835 at 3/28/20 12:06 PM:
-------------------------------------------------------------------
It affects 19.0.0.Final as well.
The org.wildfly.extension.microprofile.health.deployment.CDIExtension resolves HealthChecks using 'Weld BeanManager for org.wildfly.extension.microprofile.health-smallrye.additionalClasses [bean count=32]' wich does not find Healtcheck present in ejbs or wars modules of an ear.
Using CDI.current() there works, but is not reliable for ear if im not mistaken.
Im sure it worked with earlier versions, before the change in the output json schema.
was (Author: cghislai):
It affects 19.0.0.Final as well.
The org.wildfly.extension.microprofile.health.deployment.CDIExtension resolves HealthChecks using 'org.wildfly.extension.microprofile.health.deployment.CDIExtension' wich does not find Healtcheck present in ejbs or wars modules of an ear.
Using CDI.current() there works, but is not reliable for ear if im not mistaken.
Im sure it worked with earlier versions, before the change in the output json schema.
> HealthChecks in subdeployments are not registered
> -------------------------------------------------
>
> Key: WFLY-12835
> URL: https://issues.redhat.com/browse/WFLY-12835
> Project: WildFly
> Issue Type: Feature Request
> Components: MP Health
> Affects Versions: 18.0.1.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Critical
>
> After EAR is deployed HealthChecks are not registered and not exposed under _/health_ endpoint.
> EAR contains one WAR and one JAR. Both of them contains HealthChecks.
> Test source: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-health/mic...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-12835) HealthChecks in subdeployments are not registered
by charles ghislain (Jira)
[ https://issues.redhat.com/browse/WFLY-12835?page=com.atlassian.jira.plugi... ]
charles ghislain commented on WFLY-12835:
-----------------------------------------
It affects 19.0.0.Final as well.
The org.wildfly.extension.microprofile.health.deployment.CDIExtension resolves HealthChecks using 'org.wildfly.extension.microprofile.health.deployment.CDIExtension' wich does not find Healtcheck present in ejbs or wars modules of an ear.
Using CDI.current() there works, but is not reliable for ear if im not mistaken.
Im sure it worked with earlier versions, before the change in the output json schema.
> HealthChecks in subdeployments are not registered
> -------------------------------------------------
>
> Key: WFLY-12835
> URL: https://issues.redhat.com/browse/WFLY-12835
> Project: WildFly
> Issue Type: Feature Request
> Components: MP Health
> Affects Versions: 18.0.1.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Critical
>
> After EAR is deployed HealthChecks are not registered and not exposed under _/health_ endpoint.
> EAR contains one WAR and one JAR. Both of them contains HealthChecks.
> Test source: https://github.com/istraka/eap-microprofile-test-suite/blob/mp-health/mic...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5201) ZipException is thrown when guided asset is opened
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5201?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-5201:
-------------------------------------
[~manstis] The piece of code where the exception is thrown didn't change in the last year or more. The problem here is that it has been never passed with an empty zip file and I don't know why this is happening now in that case. If you have a reproducer I could help with this.
> ZipException is thrown when guided asset is opened
> --------------------------------------------------
>
> Key: DROOLS-5201
> URL: https://issues.redhat.com/browse/DROOLS-5201
> Project: Drools
> Issue Type: Bug
> Components: Guided Template Editor
> Affects Versions: 7.36.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2020-03-27 15-30-54.png, error.log
>
>
> User is unable to work with guided editors. Always guided editor is opened, this exception is thrown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month