[Red Hat JIRA] (DROOLS-5925) Partitioned Alpha Network Compiler
by Luca Molteni (Jira)
Luca Molteni created DROOLS-5925:
------------------------------------
Summary: Partitioned Alpha Network Compiler
Key: DROOLS-5925
URL: https://issues.redhat.com/browse/DROOLS-5925
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Luca Molteni
Assignee: Luca Molteni
We need to support very large Alpha Networks in order to use the alpha network compiler with DMN, to avoid "code too large" errors
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14254) WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-14254?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-14254:
--------------------------------------
Hmm, the only thing I can think of is that you are combining EJB and CDI annotations - {{javax.ejb.Singleton}} with {{javax.inject.Singleton}}.
EJB beans have to be initialized by EJB container and CDI container just takes them from there and performs additional actions such as CDI injection.
Now, with constructor injection, this can create some cyclic dependencies that are unexpected (and undefined by specifications) - in this case I _think_ it might be the fact that the EJB singleton is not deemed "complete" until its constructed by EJB and injected into by CDI. And while CDI tries to perform injection, it will have to construct {{Child}}, which in turn requires {{Parent}}. And that one wasn't fully constructed and is not yet registered as bean so an attempt to make new one occurs.
Basically, this is grey area between specs because they don't exactly specify how EJB and CDI container interoperate and it might (and likely will) differ between EE server implementations as well as CDI implementations.
BTW if you make the {{Child}} class {{@ApplicationScoped}} instead, it might work because then there will be a proxy and its init will be lazy - meaning creation and injection into {{Parent}} will only create the proxy and won't attempt to create {{Child}} bean until it's used for the first time.
Alternatively, you can OFC use the workaround that you figured out. That's perfectly fine and will avoid the problem because {{Child}} instance can be created without direct dependency on {{Parent}}.
> WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
> -----------------------------------------------------------------------
>
> Key: WFLY-14254
> URL: https://issues.redhat.com/browse/WFLY-14254
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 21.0.1.Final
> Reporter: nimo stephan
> Assignee: Matěj Novotný
> Priority: Major
>
> I have following two classes:
>
> The *Parent* class is a "javax.ejb.Singleton" and injects the other Singleton *Child*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.ejb.Singleton
> @javax.ejb.Startup
> public class Parent {
>
> @Inject
> private Child child;
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Parent (" + getId() + ") created.");
> child.sendMessage();
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> The *Child* class is a "javax.inject.Singleton" and injects the other Singleton *Parent*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.inject.Singleton
> //(a)javax.ejb.Singleton
> public class Child {
>
> private Parent parent;
>
> // no-args constructor not needed for @javax.inject.Singleton
> public Child() {
> }
>
> // the parent should be injected if already created by container
> @Inject
> public Child(Parent parent) {
> this.parent = parent;
> }
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Child (" + getId() + ") created.");
> }
>
> public void sendMessage() {
> System.out.println("> Child called to parent: " + parent.getId());
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> As both are Singletons, the "postConstruct()" for those two classes should only be called once. The Child uses a constructor with an injected Parent thus it should look for it if this instance is already created. However, it seems that the container tries to create the Parent-Instance twice, hence the following error:
> {code:java}
> Caused by: java.lang.IllegalStateException: WFLYEJB0132: @PostConstruct method of EJB singleton Parent of type io.Parent has been recursively invoked
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:48)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:199)
> ... 101 more{code}
> Of course, I can use "@Inject Parent parent" within the Singleton "Child" instead of constructor injection, then no error is shown. However, constructor injection should also work, or? Is this a bug or is this intended?
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14253) Deployment error caused by missing java.security.acl.Group on Java 15
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFLY-14253?page=com.atlassian.jira.plugi... ]
Richard Opalka resolved WFLY-14253.
-----------------------------------
Resolution: Duplicate Issue
> Deployment error caused by missing java.security.acl.Group on Java 15
> ---------------------------------------------------------------------
>
> Key: WFLY-14253
> URL: https://issues.redhat.com/browse/WFLY-14253
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 21.0.1.Final
> Reporter: Steve Brooksbank
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: SecurityTestWildfly.zip
>
>
> I'm getting the following error when trying to deploy a simple application that includes Container-based authentication based on the EE8 Security functionality, when WiIldfly is running on Java 15 VM:
> {code:java}
> 23:28:59,162 INFO [org.glassfish.soteria.cdi.CdiExtension] (MSC service thread 1-5) Activating javax.security.enterprise.authentication.mechanism.http.CustomFormAuthenticationMechanismDefinition authentication mechanism from com.brooksbank.weldexamples.security.ApplicationConfig class
> 23:28:59,822 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."weldExamples-1.0.war".undertow-deployment.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.deployment.unit."weldExamples-1.0.war".undertow-deployment.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:832)
> Caused by: java.lang.NoClassDefFoundError: java/security/acl/Group
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.handleJASPIMechanism(UndertowDeploymentInfoService.java:475)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:284)
> at org.jboss.msc@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.12.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> Caused by: java.lang.ClassNotFoundException: java.security.acl.Group from [Module "org.wildfly.extension.undertow" version 21.0.1.Final from local module loader @6187d1f5 (finder: local module finder @2445445a (roots: C:\Wildfly\wildfly-21.0.1.Final\modules,C:\Wildfly\wildfly-21.0.1.Final\modules\system\layers\base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> ... 10 more{code}
> The problem DOESN'T occur if Wildfly is running on Java 11 VM.
> The issue appears to be indirectly related to https://issues.redhat.com/browse/WFCORE-4592 as the ACL module was removed from Java14, but still seems to be needed.
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14258) The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
by Ronald Feicht (Jira)
[ https://issues.redhat.com/browse/WFLY-14258?page=com.atlassian.jira.plugi... ]
Ronald Feicht updated WFLY-14258:
---------------------------------
Description:
*Two* war files are deployed on the same Wildfly instance and both use websockets. The *first* page with f:websocket that gets loaded by the browser works perfectly well. Any websocket on any other page of the *same* war file also works perfectly well. Yet, any websocket of the *second* war file will not work until the server is restartet. Then the first page with a websocket that gets loaded determines which war file's websockets will work.
Example:
# WS1/index.xhtml --> websocket works
# WS2/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
# restart Wildfly
# WS2/index.xhtml --> websocket works
# WS1/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
# if we had a WS3/index.xhtml its websockets would also not work
issue found on: Mojarra 2.3.9.SP11 on WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final)
Example war files attached for you to easily confirm this issue:
ws1.tar.gz
ws2.tar.gz
Created the same bug report here because I cannot tell whether the bug is in Mojarra or the Wildfly integration of Mojarra: [https://github.com/eclipse-ee4j/mojarra/issues/4799]
was:
*Two* war files are deployed on the same Wildfly instance and both use websockets. The *first* page with f:websocket that gets loaded by the browser works perfectly well. Any websocket on any other page of the *same* war file also works perfectly well. Yet, any websocket of the *second* war file will not work until the server is restartet. Then the first page with a websocket that gets loaded determines which war file's websockets will work.
Example:
# WS*1*/index.xhtml --> websocket works
# WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
# restart Wildfly
# WS*2*/index.xhtml --> websocket works
# WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
# if we had a WS*3*/index.xhtml its websockets would also not work
issue found on: Mojarra 2.3.9.SP11 on WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final)
Example war files attached for you to easily confirm this issue:
ws1.tar.gz
ws2.tar.gz
Created the same bug report here because I cannot tell whether the bug is in Mojarra or the Wildfly integration of Mojarra: [https://github.com/eclipse-ee4j/mojarra/issues/4799]
> The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14258
> URL: https://issues.redhat.com/browse/WFLY-14258
> Project: WildFly
> Issue Type: Bug
> Reporter: Ronald Feicht
> Assignee: Farah Juma
> Priority: Major
> Attachments: ws1.tar.gz, ws2.tar.gz
>
>
> *Two* war files are deployed on the same Wildfly instance and both use websockets. The *first* page with f:websocket that gets loaded by the browser works perfectly well. Any websocket on any other page of the *same* war file also works perfectly well. Yet, any websocket of the *second* war file will not work until the server is restartet. Then the first page with a websocket that gets loaded determines which war file's websockets will work.
> Example:
> # WS1/index.xhtml --> websocket works
> # WS2/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # restart Wildfly
> # WS2/index.xhtml --> websocket works
> # WS1/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # if we had a WS3/index.xhtml its websockets would also not work
> issue found on: Mojarra 2.3.9.SP11 on WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final)
> Example war files attached for you to easily confirm this issue:
> ws1.tar.gz
> ws2.tar.gz
>
> Created the same bug report here because I cannot tell whether the bug is in Mojarra or the Wildfly integration of Mojarra: [https://github.com/eclipse-ee4j/mojarra/issues/4799]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14258) The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
by Ronald Feicht (Jira)
[ https://issues.redhat.com/browse/WFLY-14258?page=com.atlassian.jira.plugi... ]
Ronald Feicht updated WFLY-14258:
---------------------------------
Description:
*Two* war files are deployed on the same Wildfly instance and both use websockets. The *first* page with f:websocket that gets loaded by the browser works perfectly well. Any websocket on any other page of the *same* war file also works perfectly well. Yet, any websocket of the *second* war file will not work until the server is restartet. Then the first page with a websocket that gets loaded determines which war file's websockets will work.
Example:
# WS*1*/index.xhtml --> websocket works
# WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
# restart Wildfly
# WS*2*/index.xhtml --> websocket works
# WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
# if we had a WS*3*/index.xhtml its websockets would also not work
issue found on: Mojarra 2.3.9.SP11 on WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final)
Example war files attached for you to easily confirm this issue:
ws1.tar.gz
ws2.tar.gz
Created the same bug report here because I cannot tell whether the bug is in Mojarra or the Wildfly integration of Mojarra: [https://github.com/eclipse-ee4j/mojarra/issues/4799]
was:
*Two* war files are deployed on the same Wildfly instance and both use websockets. The *first* page with f:websocket that gets loaded by the browser works perfectly well. Any websocket on any other page of the *same* war file also works perfectly well. Yet, any websocket of the *second* war file will not work until the server is restartet. Then the first page with a websocket that gets loaded determines which war file's websockets will work.
Example:
# WS1/index.xhtml --> websocket works
# WS2/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
# restart Wildfly
# WS2/index.xhtml --> websocket works
# WS1/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
# if we had a WS3/index.xhtml its websockets would also not work
issue found on: Mojarra 2.3.9.SP11 on WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final)
Example war files attached for you to easily confirm this issue:
ws1.tar.gz
ws2.tar.gz
Created the same bug report here because I cannot tell whether the bug is in Mojarra or the Wildfly integration of Mojarra: [https://github.com/eclipse-ee4j/mojarra/issues/4799]
> The first websocket that gets triggered from any deployed war file on server prevents all websockets in all other deployed war files from working
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14258
> URL: https://issues.redhat.com/browse/WFLY-14258
> Project: WildFly
> Issue Type: Bug
> Reporter: Ronald Feicht
> Assignee: Farah Juma
> Priority: Major
> Attachments: ws1.tar.gz, ws2.tar.gz
>
>
> *Two* war files are deployed on the same Wildfly instance and both use websockets. The *first* page with f:websocket that gets loaded by the browser works perfectly well. Any websocket on any other page of the *same* war file also works perfectly well. Yet, any websocket of the *second* war file will not work until the server is restartet. Then the first page with a websocket that gets loaded determines which war file's websockets will work.
> Example:
> # WS*1*/index.xhtml --> websocket works
> # WS*2*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # restart Wildfly
> # WS*2*/index.xhtml --> websocket works
> # WS*1*/index.xhtml --> websocket does not work (because it seems to be closed on the server side?)
> # if we had a WS*3*/index.xhtml its websockets would also not work
> issue found on: Mojarra 2.3.9.SP11 on WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final)
> Example war files attached for you to easily confirm this issue:
> ws1.tar.gz
> ws2.tar.gz
>
> Created the same bug report here because I cannot tell whether the bug is in Mojarra or the Wildfly integration of Mojarra: [https://github.com/eclipse-ee4j/mojarra/issues/4799]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (DROOLS-5924) String vs Number Coercion behavior difference between standard-drl and exec-model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5924?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5924:
--------------------------------------
Description:
If there is a constraint to compare String with Number, standard-drl (MvelConstraint) coerces String to Number so the evaluation will be Number comparison (e.g. 10 > 5). But exec-model coerces Number to String so the evaluation will be String comparison (e.g. "10" < "5").
Note that we need to use Object or Map to test this because simple comparison String vs Number causes a compilation error.
for example)
{noformat}
ObjectHolder($o : value)
StringHolder( value > $o )
{noformat}
or
{noformat}
$map : Map()
StringHolder( value > $map.get("key") )
{noformat}
was:
If there is a constraint to compare String with Number, standard-drl (MvelConstraint) coerces String to Number so the evaluation will be Number comparison (e.g. 10 > 5). But exec-model coerces Number to String so the evaluation will be String comparison (e.g. "10" < "5").
Note that we need to use Object or Map to test this because simple comparison String vs Number causes a compilation error.
for example)
{noformat}
ObjectHolder($o : value)
StringHolder( value > $o )
{noformat}
or
{noformat}
$map : Map()
StringHolder( value > $map.get("key") )
{noformat}
> String vs Number Coercion behavior difference between standard-drl and exec-model
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-5924
> URL: https://issues.redhat.com/browse/DROOLS-5924
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.47.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> If there is a constraint to compare String with Number, standard-drl (MvelConstraint) coerces String to Number so the evaluation will be Number comparison (e.g. 10 > 5). But exec-model coerces Number to String so the evaluation will be String comparison (e.g. "10" < "5").
> Note that we need to use Object or Map to test this because simple comparison String vs Number causes a compilation error.
> for example)
> {noformat}
> ObjectHolder($o : value)
> StringHolder( value > $o )
> {noformat}
> or
> {noformat}
> $map : Map()
> StringHolder( value > $map.get("key") )
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (DROOLS-5924) String vs Number Coercion behavior difference between standard-drl and exec-model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5924?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5924:
--------------------------------------
Description:
If there is a constraint to compare String with Number, standard-drl (MvelConstraint) coerces String to Number so the evaluation will be Number comparison (e.g. 10 > 5). But exec-model coerces Number to String so the evaluation will be String comparison (e.g. "10" < "5").
Note that we need to use Object or Map to test this because simple comparison String vs Number causes a compilation error.
for example)
{noformat}
ObjectHolder($o : value)
StringHolder( value > $o )
{noformat}
or
{noformat}
$map : Map()
StringHolder( value > $map.get("key") )
{noformat}
was:
If there is a constraint to compare String with Number, standard-drl (MvelConstraint) coerces String to Number so the evaluation will be Number comparison (e.g. 10 > 5). But exec-model coerces Number to String so the evaluation will be String comparison (e.g. "10" < "5").
Note that we need to use a Map to test this because simple comparison String vs Number causes a compilation error.
for example)
{noformat}
$map : Map()
p : Cheese(type < $map.get("key"))
{noformat}
> String vs Number Coercion behavior difference between standard-drl and exec-model
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-5924
> URL: https://issues.redhat.com/browse/DROOLS-5924
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.47.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> If there is a constraint to compare String with Number, standard-drl (MvelConstraint) coerces String to Number so the evaluation will be Number comparison (e.g. 10 > 5). But exec-model coerces Number to String so the evaluation will be String comparison (e.g. "10" < "5").
> Note that we need to use Object or Map to test this because simple comparison String vs Number causes a compilation error.
> for example)
> {noformat}
> ObjectHolder($o : value)
> StringHolder( value > $o )
> {noformat}
> or
> {noformat}
> $map : Map()
> StringHolder( value > $map.get("key") )
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months