[JBoss JIRA] (WFCORE-4500) IllegalStateException in ManagementSecurityIdentitySupplier
by Farah Juma (Jira)
Farah Juma created WFCORE-4500:
----------------------------------
Summary: IllegalStateException in ManagementSecurityIdentitySupplier
Key: WFCORE-4500
URL: https://issues.jboss.org/browse/WFCORE-4500
Project: WildFly Core
Issue Type: Bug
Components: Management, Security
Reporter: Farah Juma
Assignee: Farah Juma
The following {{IllegalStateException}} occurred during a test suite run:
{code}
2019-05-30 08:28:36,646 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "BasicMechTestCase.war" (runtime-name: "BasicMechTestCase.war")
2019-05-30 08:28:36,704 ERROR [org.jboss.as.arquillian] (MSC service thread 1-1) Cannot stop Arquillian Test Runner: java.lang.IllegalStateException
at org.jboss.msc@1.4.5.Final//org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:50)
at org.jboss.as.controller@9.0.0.Beta7//org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:60)
at org.jboss.as.controller@9.0.0.Beta7//org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:39)
at org.jboss.as.jmx@9.0.0.Beta7//org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1180)
at org.jboss.as.jmx@9.0.0.Beta7//org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
at org.jboss.as.jmx@9.0.0.Beta7//org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.isRegistered(MBeanServerAuditLogRecordFormatter.java:176)
at org.jboss.as.jmx@9.0.0.Beta7//org.jboss.as.jmx.PluggableMBeanServerImpl.isRegistered(PluggableMBeanServerImpl.java:784)
at deployment.arquillian-service//org.jboss.arquillian.protocol.jmx.JMXTestRunner.unregisterMBean(JMXTestRunner.java:89)
at deployment.arquillian-service//org.jboss.as.arquillian.service.ArquillianService.stop(ArquillianService.java:96)
at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1794)
at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1763)
at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ELY-1822) security domain with multiple realms
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1822?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1822:
---------------------------------------
[~i015101] If you are interested you can also join our chat server at https://wildfly.zulipchat.com/ - the WildFly Elytron engineers tend to be in a stream called #wildfly-elytron - it is good for us to hear about issues as they are being worked through so hopefully we can use the feedback to plan our next steps.
> security domain with multiple realms
> -------------------------------------
>
> Key: ELY-1822
> URL: https://issues.jboss.org/browse/ELY-1822
> Project: WildFly Elytron
> Issue Type: Clarification
> Components: Authentication Server
> Affects Versions: 1.8.0.Final
> Environment: windows mssql
> Reporter: Christopher Willems
> Priority: Optional
> Attachments: D95_J00_VM-DEV95-LS01, D95_J00_VM-DEV95-LS01.1, D95_J00_VM-DEV95-LS01.2, D95_SCS01_VM-DEV95-LS01, DEFAULT.PFL, HistorianMIIActionBlock - Shortcut.lnk, HistorianMIIActionBlock.zip, MaterialLotServicesMII.java, MovilitasFileHandling.zip, config-jwt-elytron.cli, config-jwtnw-elytron.cli, config-jwtnw-elytron.cli.txt, defaultTrace_00.8, defaultTrace_00.8.trc, defaultTracehana.txt, demofile.txt, editingactivitieswithnestedactivities.txt, inxites.be~inx~veri95.ejb.jar, jboss-ejb-client.properties, jboss-ejb3.xml, jboss-ejb3.xml, jboss-web.xml, jboss-web.xml, public.txt, server.log, standalone.xml
>
>
> we have an ear file with 2 war files and one ejb jar . Purpose of the war files is to allow for different authentication mechanisms, one for jwt (BEARER_TOKEN) the other one jdbc (BASIC) .
> After the authentication we have a call to the ejb layer which we expect to have the principal of the authentication.
> Everything works fine for one realm, the default realm. The other realm will return unauthorized . With no default nothing works. The relevant information from the standalone xml is pasted below and others are attached.
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> <default-security-domain value="other"/>
> <application-security-domains>
> <application-security-domain name="war-domain" security-domain="war-domain"/>
> </application-security-domains>
> <default-missing-method-permissions-deny-access value="false"/>
>
> <subsystem xmlns="urn:wildfly:elytron:6.0"
> <security-domain name="war-domain" default-realm="jdbc-realm" permission-mapper="default-permission-mapper" outflow-security-domains="ApplicationDomain">
> <realm name="jdbc-realm"/>
> <realm name="jwt-realm"/>
> </security-domain>
>
> <http-authentication-factory name="war-http-authentication" security-domain="war-domain" http-server-mechanism-factory="global">
> <mechanism-configuration>
> <mechanism mechanism-name="BEARER_TOKEN">
> <mechanism-realm realm-name="jwt-realm"/>
> </mechanism>
> <mechanism mechanism-name="BASIC">
> <mechanism-realm realm-name="jdbc-realm"/>
> </mechanism>
> </mechanism-configuration>
> </http-authentication-factory>
> below the exert from the log on using the jdbc realm when jwt is the default
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /veri95web
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1@1505d380] for mechanism [BASIC]
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='BASIC' host-name='localhost' protocol='http'
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling AvailableRealmsCallback: realms = [jdbc-realm]
> 2019-05-30 15:28:05,290 DEBUG [org.wildfly.security.http.password] (default task-1) Username authentication. Realm: [jdbc-realm], Username: [user1].
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [jdbc-realm]
> 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = user1
> 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Principal assigning: [user1], pre-realm rewritten: [user1], realm name: [jwt-realm], post-realm rewritten: [user1], realm rewritten: [user1]
> 2019-05-30 15:28:05,291 DEBUG [org.wildfly.security.http.basic] (default task-1) User user1 authentication failed.
> 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: fail
> 2019-05-30 15:28:05,291 DEBUG [io.undertow.request.security] (default task-1) Authentication failed with message ELY06002: An authentication attempt for user 'user1' failed validation using mechanism 'BASIC'. and mechanism BASIC for HttpServerExchange{ POST /veri95web/rest/Xml/process/Equipment request {Accept=[*/*], Postman-Token=[9bba6216-81a7-4048-aa24-ec110d677e4a], Cache-Control=[no-cache], accept-encoding=[gzip, deflate], User-Agent=[PostmanRuntime/7.13.0], Connection=[keep-alive], Authorization=[Basic dXNlcjE6MGZmZDkzNDkyNzgzNzE5YQ==], Content-Type=[applicati
> [^server.log]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ELY-1822) security domain with multiple realms
by Christopher Willems (Jira)
[ https://issues.jboss.org/browse/ELY-1822?page=com.atlassian.jira.plugin.s... ]
Christopher Willems edited comment on ELY-1822 at 5/31/19 9:13 AM:
-------------------------------------------------------------------
adding the following is required
<constant-realm-mapper name="constant-jdbc-realm" realm-name="jdbc-realm"/>
<constant-realm-mapper name="constant-jwt-realm" realm-name="jwt-realm"/>
<http-authentication-factory name="war-http-authentication" security-domain="war-domain" http-server-mechanism-factory="global">
<mechanism-configuration>
<mechanism mechanism-name="BEARER_TOKEN" realm-mapper="constant-jwt-realm">
<mechanism-realm realm-name="jwt-realm"/>
</mechanism>
<mechanism mechanism-name="BASIC" realm-mapper="constant-jdbc-realm">
<mechanism-realm realm-name="jdbc-realm"/>
</mechanism>
</mechanism-configuration>
</http-authentication-factory>
was (Author: i015101):
closing this , adding the following is required
<constant-realm-mapper name="constant-jdbc-realm" realm-name="jdbc-realm"/>
<constant-realm-mapper name="constant-jwt-realm" realm-name="jwt-realm"/>
<http-authentication-factory name="war-http-authentication" security-domain="war-domain" http-server-mechanism-factory="global">
<mechanism-configuration>
<mechanism mechanism-name="BEARER_TOKEN" realm-mapper="constant-jwt-realm">
<mechanism-realm realm-name="jwt-realm"/>
</mechanism>
<mechanism mechanism-name="BASIC" realm-mapper="constant-jdbc-realm">
<mechanism-realm realm-name="jdbc-realm"/>
</mechanism>
</mechanism-configuration>
</http-authentication-factory>
> security domain with multiple realms
> -------------------------------------
>
> Key: ELY-1822
> URL: https://issues.jboss.org/browse/ELY-1822
> Project: WildFly Elytron
> Issue Type: Clarification
> Components: Authentication Server
> Affects Versions: 1.8.0.Final
> Environment: windows mssql
> Reporter: Christopher Willems
> Priority: Optional
> Attachments: D95_J00_VM-DEV95-LS01, D95_J00_VM-DEV95-LS01.1, D95_J00_VM-DEV95-LS01.2, D95_SCS01_VM-DEV95-LS01, DEFAULT.PFL, HistorianMIIActionBlock - Shortcut.lnk, HistorianMIIActionBlock.zip, MaterialLotServicesMII.java, MovilitasFileHandling.zip, config-jwt-elytron.cli, config-jwtnw-elytron.cli, config-jwtnw-elytron.cli.txt, defaultTrace_00.8, defaultTrace_00.8.trc, defaultTracehana.txt, demofile.txt, editingactivitieswithnestedactivities.txt, inxites.be~inx~veri95.ejb.jar, jboss-ejb-client.properties, jboss-ejb3.xml, jboss-ejb3.xml, jboss-web.xml, jboss-web.xml, public.txt, server.log, standalone.xml
>
>
> we have an ear file with 2 war files and one ejb jar . Purpose of the war files is to allow for different authentication mechanisms, one for jwt (BEARER_TOKEN) the other one jdbc (BASIC) .
> After the authentication we have a call to the ejb layer which we expect to have the principal of the authentication.
> Everything works fine for one realm, the default realm. The other realm will return unauthorized . With no default nothing works. The relevant information from the standalone xml is pasted below and others are attached.
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> <default-security-domain value="other"/>
> <application-security-domains>
> <application-security-domain name="war-domain" security-domain="war-domain"/>
> </application-security-domains>
> <default-missing-method-permissions-deny-access value="false"/>
>
> <subsystem xmlns="urn:wildfly:elytron:6.0"
> <security-domain name="war-domain" default-realm="jdbc-realm" permission-mapper="default-permission-mapper" outflow-security-domains="ApplicationDomain">
> <realm name="jdbc-realm"/>
> <realm name="jwt-realm"/>
> </security-domain>
>
> <http-authentication-factory name="war-http-authentication" security-domain="war-domain" http-server-mechanism-factory="global">
> <mechanism-configuration>
> <mechanism mechanism-name="BEARER_TOKEN">
> <mechanism-realm realm-name="jwt-realm"/>
> </mechanism>
> <mechanism mechanism-name="BASIC">
> <mechanism-realm realm-name="jdbc-realm"/>
> </mechanism>
> </mechanism-configuration>
> </http-authentication-factory>
> below the exert from the log on using the jdbc realm when jwt is the default
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /veri95web
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1@1505d380] for mechanism [BASIC]
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='BASIC' host-name='localhost' protocol='http'
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling AvailableRealmsCallback: realms = [jdbc-realm]
> 2019-05-30 15:28:05,290 DEBUG [org.wildfly.security.http.password] (default task-1) Username authentication. Realm: [jdbc-realm], Username: [user1].
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [jdbc-realm]
> 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = user1
> 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Principal assigning: [user1], pre-realm rewritten: [user1], realm name: [jwt-realm], post-realm rewritten: [user1], realm rewritten: [user1]
> 2019-05-30 15:28:05,291 DEBUG [org.wildfly.security.http.basic] (default task-1) User user1 authentication failed.
> 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: fail
> 2019-05-30 15:28:05,291 DEBUG [io.undertow.request.security] (default task-1) Authentication failed with message ELY06002: An authentication attempt for user 'user1' failed validation using mechanism 'BASIC'. and mechanism BASIC for HttpServerExchange{ POST /veri95web/rest/Xml/process/Equipment request {Accept=[*/*], Postman-Token=[9bba6216-81a7-4048-aa24-ec110d677e4a], Cache-Control=[no-cache], accept-encoding=[gzip, deflate], User-Agent=[PostmanRuntime/7.13.0], Connection=[keep-alive], Authorization=[Basic dXNlcjE6MGZmZDkzNDkyNzgzNzE5YQ==], Content-Type=[applicati
> [^server.log]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ELY-1822) security domain with multiple realms
by Christopher Willems (Jira)
[ https://issues.jboss.org/browse/ELY-1822?page=com.atlassian.jira.plugin.s... ]
Christopher Willems edited comment on ELY-1822 at 5/31/19 9:12 AM:
-------------------------------------------------------------------
closing this , adding the following is required
<constant-realm-mapper name="constant-jdbc-realm" realm-name="jdbc-realm"/>
<constant-realm-mapper name="constant-jwt-realm" realm-name="jwt-realm"/>
<http-authentication-factory name="war-http-authentication" security-domain="war-domain" http-server-mechanism-factory="global">
<mechanism-configuration>
<mechanism mechanism-name="BEARER_TOKEN" realm-mapper="constant-jwt-realm">
<mechanism-realm realm-name="jwt-realm"/>
</mechanism>
<mechanism mechanism-name="BASIC" realm-mapper="constant-jdbc-realm">
<mechanism-realm realm-name="jdbc-realm"/>
</mechanism>
</mechanism-configuration>
</http-authentication-factory>
was (Author: i015101):
closing this , adding the following is required
<constant-realm-mapper name="constant-jdbc-realm" realm-name="jdbc-realm"/>
<constant-realm-mapper name="constant-jwt-realm" realm-name="jwt-realm"/>
> security domain with multiple realms
> -------------------------------------
>
> Key: ELY-1822
> URL: https://issues.jboss.org/browse/ELY-1822
> Project: WildFly Elytron
> Issue Type: Clarification
> Components: Authentication Server
> Affects Versions: 1.8.0.Final
> Environment: windows mssql
> Reporter: Christopher Willems
> Priority: Optional
> Attachments: D95_J00_VM-DEV95-LS01, D95_J00_VM-DEV95-LS01.1, D95_J00_VM-DEV95-LS01.2, D95_SCS01_VM-DEV95-LS01, DEFAULT.PFL, HistorianMIIActionBlock - Shortcut.lnk, HistorianMIIActionBlock.zip, MaterialLotServicesMII.java, MovilitasFileHandling.zip, config-jwt-elytron.cli, config-jwtnw-elytron.cli, config-jwtnw-elytron.cli.txt, defaultTrace_00.8, defaultTrace_00.8.trc, defaultTracehana.txt, demofile.txt, editingactivitieswithnestedactivities.txt, inxites.be~inx~veri95.ejb.jar, jboss-ejb-client.properties, jboss-ejb3.xml, jboss-ejb3.xml, jboss-web.xml, jboss-web.xml, public.txt, server.log, standalone.xml
>
>
> we have an ear file with 2 war files and one ejb jar . Purpose of the war files is to allow for different authentication mechanisms, one for jwt (BEARER_TOKEN) the other one jdbc (BASIC) .
> After the authentication we have a call to the ejb layer which we expect to have the principal of the authentication.
> Everything works fine for one realm, the default realm. The other realm will return unauthorized . With no default nothing works. The relevant information from the standalone xml is pasted below and others are attached.
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> <default-security-domain value="other"/>
> <application-security-domains>
> <application-security-domain name="war-domain" security-domain="war-domain"/>
> </application-security-domains>
> <default-missing-method-permissions-deny-access value="false"/>
>
> <subsystem xmlns="urn:wildfly:elytron:6.0"
> <security-domain name="war-domain" default-realm="jdbc-realm" permission-mapper="default-permission-mapper" outflow-security-domains="ApplicationDomain">
> <realm name="jdbc-realm"/>
> <realm name="jwt-realm"/>
> </security-domain>
>
> <http-authentication-factory name="war-http-authentication" security-domain="war-domain" http-server-mechanism-factory="global">
> <mechanism-configuration>
> <mechanism mechanism-name="BEARER_TOKEN">
> <mechanism-realm realm-name="jwt-realm"/>
> </mechanism>
> <mechanism mechanism-name="BASIC">
> <mechanism-realm realm-name="jdbc-realm"/>
> </mechanism>
> </mechanism-configuration>
> </http-authentication-factory>
> below the exert from the log on using the jdbc realm when jwt is the default
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /veri95web
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1@1505d380] for mechanism [BASIC]
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='BASIC' host-name='localhost' protocol='http'
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling AvailableRealmsCallback: realms = [jdbc-realm]
> 2019-05-30 15:28:05,290 DEBUG [org.wildfly.security.http.password] (default task-1) Username authentication. Realm: [jdbc-realm], Username: [user1].
> 2019-05-30 15:28:05,290 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [jdbc-realm]
> 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = user1
> 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Principal assigning: [user1], pre-realm rewritten: [user1], realm name: [jwt-realm], post-realm rewritten: [user1], realm rewritten: [user1]
> 2019-05-30 15:28:05,291 DEBUG [org.wildfly.security.http.basic] (default task-1) User user1 authentication failed.
> 2019-05-30 15:28:05,291 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: fail
> 2019-05-30 15:28:05,291 DEBUG [io.undertow.request.security] (default task-1) Authentication failed with message ELY06002: An authentication attempt for user 'user1' failed validation using mechanism 'BASIC'. and mechanism BASIC for HttpServerExchange{ POST /veri95web/rest/Xml/process/Equipment request {Accept=[*/*], Postman-Token=[9bba6216-81a7-4048-aa24-ec110d677e4a], Cache-Control=[no-cache], accept-encoding=[gzip, deflate], User-Agent=[PostmanRuntime/7.13.0], Connection=[keep-alive], Authorization=[Basic dXNlcjE6MGZmZDkzNDkyNzgzNzE5YQ==], Content-Type=[applicati
> [^server.log]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3819) Rule Unit Handling: restore older behavior in new prototype
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3819?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-3819:
-----------------------------------
Sprint: 2019 Week 23-25 (was: 2019 Week 20-22)
> Rule Unit Handling: restore older behavior in new prototype
> -----------------------------------------------------------
>
> Key: DROOLS-3819
> URL: https://issues.jboss.org/browse/DROOLS-3819
> Project: Drools
> Issue Type: Bug
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Priority: Major
> Labels: drools-core, submarine
> Fix For: 8.0.0.Final
>
>
> I have disabled generation of `unit()` API invocation on DRL compiler in order to make the Unit prototype work quickly. We are now assuming that 1 unit === 1 session, therefore some previous assumptions do not hold anymore. Previous assertions are therefore broken. It is also a good time to re-evaluate some previous considerations on how rule units are supposed to work (e.g. reconsider how guards work etc)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3929) Cleanup and consolidate submarine-codegen
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3929?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-3929:
-----------------------------------
Sprint: 2019 Week 17-19, 2019 Week 23-25 (was: 2019 Week 17-19, 2019 Week 20-22)
> Cleanup and consolidate submarine-codegen
> -----------------------------------------
>
> Key: DROOLS-3929
> URL: https://issues.jboss.org/browse/DROOLS-3929
> Project: Drools
> Issue Type: Task
> Reporter: Edoardo Vacchi
> Assignee: Edoardo Vacchi
> Priority: Major
> Labels: drools-core, submarine
> Fix For: 8.0.0.Final
>
>
> After codegen refactoring there are some classes that do little more than carrying data around. This task is to remove those leftovers and in general cleanup the codebase so that any dangling part is removed or repurposed.
> e.g. {drools,jbpm}.ModuleGenerator vs. ApplicationGenerator
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month