[JBoss JIRA] (DROOLS-1648) Maven dependency resolution through "LATEST" and "RELEASE" version labels using "KieServices.newKieContainer(ReleaseId releaseId)" method fails
by Pyit Phyo Aung (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1648?page=com.atlassian.jira.plugi... ]
Pyit Phyo Aung commented on DROOLS-1648:
----------------------------------------
Thank you very much for useful information, [~mfusco]. Have a great week.
> Maven dependency resolution through "LATEST" and "RELEASE" version labels using "KieServices.newKieContainer(ReleaseId releaseId)" method fails
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1648
> URL: https://issues.jboss.org/browse/DROOLS-1648
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Environment: OS: macOS Sierra (10.12.5)
> Hardware: MacBook Pro (13-inch, 2017)
> Reporter: Pyit Phyo Aung
> Assignee: Mario Fusco
> Priority: Minor
>
> I tried to use KieScanner for automatic business rule deployment through kjar modules setup in private maven repository. For that, I tried to specify getting latest kjar modules using "LATEST" and "RELEASE" version labels. They failed for three drools versions I tried (6.5.0.Final, 7.0.0.Final and 7.1.0.Beta3). However, when I tried open-ended version label, solution works. So, I believe that there is issue in dependency resolution related to KieContainer through KieServices.newKieContainer(ReleaseId releaseId) method.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9020) Wildfly 10 - JPA Entity deserialization problem on @Transient field
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9020?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-9020:
------------------------------------
Assignee: David Lloyd (was: Stuart Douglas)
> Wildfly 10 - JPA Entity deserialization problem on @Transient field
> -------------------------------------------------------------------
>
> Key: WFLY-9020
> URL: https://issues.jboss.org/browse/WFLY-9020
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 10.0.0.Final
> Environment: Windows 7, Eclipselink 2.6.4 integration, Widlfly 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: David Lloyd
> Priority: Minor
>
> In Wildfly 10,
> We have some system tests that sporadically fail when the client of the application loads an entity, connected to other sub-entities, where one of these sub-entities has a @Transient field.
> In Particular, we have an entity Attributes that has a field of the form:
> {panel}
> @Transient
> private Map<String, String> attributeMap = new TreeMap<String, String>();
> {panel}
> The root cause of the deserialization problem is of the form:
> {panel}
> Caused by: an exception which occurred:
> in object of type java.util.TreeMap
> in field attributeMap
> in object of type basepackage.entity.Attributes
> in field attributes
> in object of type basepackage.entity.SubEntityB
> in element at index [0] of size [1]
> in field delegate
> in object of type org.eclipse.persistence.internal.indirection.jdk8.IndirectList
> in field loadUnits
> in object of type basepackage.entity.ParentEntityA
> {panel}
> The de-serialization execution stack looks as follows:
> {panel}
> Caused by: java.io.OptionalDataException
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:147)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
> at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
> at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:367)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2567)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2583)
> at java.util.TreeMap.buildFromSorted(TreeMap.java:2508)
> at java.util.TreeMap.readObject(TreeMap.java:2454)
> at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)
> at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:776)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:675)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1658)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:104)
> {panel}
> We are using the following cliean library:
> {panel}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-client-all</artifactId>
> <version>10.0.0.Final</version>
> <scope>test</scope>
> <optional>true</optional>
> <exclusions>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-commons</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-core-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-jms-client</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.activemq</groupId>
> <artifactId>artemis-hqclient-protocol</artifactId>
> </exclusion>
> <exclusion>
> <groupId> org.slf4j</groupId>
> <artifactId>jcl-over-slf4j</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {panel}
> Currently no sample application exists to reproduce the issue.
> On weblogic the deserialization process goes without incident.
> Could the @Transient annotation and the eventual (empty map vs popuated attribtues map) play a role on this issue?
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3040) StepCapabilityStatus should take capability dependencies into account
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3040?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3040:
------------------------------------------
The WFCORE-1106 design is about tracking the capability dependencies. Are the dependencies between these capabilities properly declared?
> StepCapabilityStatus should take capability dependencies into account
> ---------------------------------------------------------------------
>
> Key: WFCORE-3040
> URL: https://issues.jboss.org/browse/WFCORE-3040
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Beta28
> Reporter: ehsavoie Hugonnet
> Assignee: Brian Stansberry
>
> Currently at stage RUNTIME we check the stepCapabilityStatus before executing the OSH associated with a capability. But this check doesn't take into account the state of the capability dependencies.
> For example if we add the undertow subsystem from scratch : the server service is not added because its capability is RELOAD_REQUIRED but when adding the listener the stepCapabilityStatus is NORMAL while it depends on a service that is in RELOAD_REQUIRED so is potentially not there (which is the case) thus the RUNTIME OSH will fail instead of being skipped.
> Reproducer:
> {code:java}
> /extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow")
> /extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io")
> batch
> /subsystem=undertow:add
> /subsystem=undertow/servlet-container=default:add
> /subsystem=undertow/server=default-server:add
> /subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"])
> /subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http")
> /subsystem=undertow/buffer-cache=default:add
> /subsystem=undertow/configuration=handler:add
> /subsystem=undertow/configuration=filter:add
> /subsystem=io:add
> /subsystem=io/buffer-pool=default:add
> /subsystem=io/worker=default:add
> /socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}")
> run-batch
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8316) Mapping roles in legacy security domain is ignored when this domain is used as Elytron realm
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/WFLY-8316?page=com.atlassian.jira.plugin.... ]
Stefan Guilhen reassigned WFLY-8316:
------------------------------------
Assignee: Stefan Guilhen (was: Darran Lofthouse)
> Mapping roles in legacy security domain is ignored when this domain is used as Elytron realm
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-8316
> URL: https://issues.jboss.org/browse/WFLY-8316
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Stefan Guilhen
> Priority: Critical
> Attachments: print-roles.war
>
>
> In case when legacy security domain is used as Elytron realm then roles assigned in mapping are unavailable in Elytron security realm.
> e.g. when UsersRoles login module, which assigns role JBossAdmin to user admin is used and then role User is assigned for user admin in SimpleRoles mapping module through:
> {code}
> <mapping>
> <mapping-module code="SimpleRoles" type="role">
> <module-option name="admin" value="User"/>
> </mapping-module>
> </mapping>
> {code}
> then only role JBossAdmin is available for Elytron. Following appears in server log:
> {code}
> Authorizing against the following attributes: [Roles, CallerPrincipal] => [JBossAdmin, admin]
> {code}
> In case when this legacy security domain is used directly as PicketBox security domain, then both roles, JBossAdmin and User, are assigned to user admin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (HIBERNATE-158) Duplicate names found for compund primarykey
by George Lindholm (JIRA)
George Lindholm created HIBERNATE-158:
-----------------------------------------
Summary: Duplicate names found for compund primarykey
Key: HIBERNATE-158
URL: https://issues.jboss.org/browse/HIBERNATE-158
Project: Hibernate Integration
Issue Type: Bug
Reporter: George Lindholm
Assignee: Steve Ebersole
What steps will reproduce the problem?
1. Have two tables with a compound primary key with the same name
2.
3.
Version: 5.2.0.v20170529-1840
-- Error Details --
Date: Fri Jun 30 17:03:46 PDT 2017
Message: org.hibernate.cfg.JDBCBinderException: Duplicate names found for primarykey. Existing name: CTZSI_EVENTS_SERV_EVENT_PK JDBC name: CT_SI_EVENTS_SERV_EVENT_PK on table org.hibernate.mapping.Table(CTC.CT_SI_EVENTS)
Severity: Error
Product: Eclipse 4.7.0.20170620-1800 (org.eclipse.epp.package.java.product)
Plugin: org.hibernate.eclipse
Session Data:
eclipse.buildId=4.7.0.I20170612-0950
java.version=1.8.0_131
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments: -product org.eclipse.epp.package.java.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.java.product -data file:/W:/workspace/
Exception Stack Trace:
org.hibernate.cfg.JDBCBinderException: Duplicate names found for primarykey. Existing name: CTZSI_EVENTS_SERV_EVENT_PK JDBC name: CT_SI_EVENTS_SERV_EVENT_PK on table org.hibernate.mapping.Table(CTC.CT_SI_EVENTS)
at org.hibernate.cfg.reveng.JDBCReader.processPrimaryKey(JDBCReader.java:371)
at org.hibernate.cfg.reveng.JDBCReader.readDatabaseSchema(JDBCReader.java:86)
at org.hibernate.cfg.reveng.JDBCReader.readDatabaseSchema(JDBCReader.java:860)
at org.hibernate.cfg.JDBCBinder.readDatabaseSchema(JDBCBinder.java:124)
at org.hibernate.cfg.JDBCBinder.readFromDatabase(JDBCBinder.java:92)
at org.hibernate.cfg.JDBCMetaDataConfiguration.readFromJDBC(JDBCMetaDataConfiguration.java:75)
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.jboss.tools.hibernate.runtime.common.Util.invokeMethod(Util.java:43)
at org.jboss.tools.hibernate.runtime.common.AbstractConfigurationFacade.readFromJDBC(AbstractConfigurationFacade.java:208)
at org.hibernate.eclipse.console.common.ConsoleExtension$2.execute(ConsoleExtension.java:308)
at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:107)
at org.hibernate.eclipse.console.common.ConsoleExtension.buildConfiguration(ConsoleExtension.java:266)
at org.hibernate.eclipse.console.common.ConsoleExtension.runExporters(ConsoleExtension.java:174)
at org.hibernate.eclipse.console.common.ConsoleExtension.launchExporters(ConsoleExtension.java:110)
at org.hibernate.eclipse.launch.CodeGenerationLaunchDelegate.launch(CodeGenerationLaunchDelegate.java:266)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
at org.jboss.tools.hibernate.jpt.ui.wizard.GenerateEntitiesWizard$2.runInWorkspace(GenerateEntitiesWizard.java:101)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
-- Error Details --
Date: Fri Jun 30 17:03:46 PDT 2017
Message: org.hibernate.cfg.JDBCBinderException: Duplicate names found for primarykey. Existing name: CTZSI_EVENTS_SERV_EVENT_PK JDBC name: CT_SI_EVENTS_SERV_EVENT_PK on table org.hibernate.mapping.Table(CTC.CT_SI_EVENTS)
Severity: Error
Product: Eclipse 4.7.0.20170620-1800 (org.eclipse.epp.package.java.product)
Plugin: org.hibernate.eclipse
Exception Stack Trace:
org.hibernate.cfg.JDBCBinderException: Duplicate names found for primarykey. Existing name: CTZSI_EVENTS_SERV_EVENT_PK JDBC name: CT_SI_EVENTS_SERV_EVENT_PK on table org.hibernate.mapping.Table(CTC.CT_SI_EVENTS)
at org.hibernate.cfg.reveng.JDBCReader.processPrimaryKey(JDBCReader.java:371)
at org.hibernate.cfg.reveng.JDBCReader.readDatabaseSchema(JDBCReader.java:86)
at org.hibernate.cfg.reveng.JDBCReader.readDatabaseSchema(JDBCReader.java:860)
at org.hibernate.cfg.JDBCBinder.readDatabaseSchema(JDBCBinder.java:124)
at org.hibernate.cfg.JDBCBinder.readFromDatabase(JDBCBinder.java:92)
at org.hibernate.cfg.JDBCMetaDataConfiguration.readFromJDBC(JDBCMetaDataConfiguration.java:75)
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.jboss.tools.hibernate.runtime.common.Util.invokeMethod(Util.java:43)
at org.jboss.tools.hibernate.runtime.common.AbstractConfigurationFacade.readFromJDBC(AbstractConfigurationFacade.java:208)
at org.hibernate.eclipse.console.common.ConsoleExtension$2.execute(ConsoleExtension.java:308)
at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:107)
at org.hibernate.eclipse.console.common.ConsoleExtension.buildConfiguration(ConsoleExtension.java:266)
at org.hibernate.eclipse.console.common.ConsoleExtension.runExporters(ConsoleExtension.java:174)
at org.hibernate.eclipse.console.common.ConsoleExtension.launchExporters(ConsoleExtension.java:110)
at org.hibernate.eclipse.launch.CodeGenerationLaunchDelegate.launch(CodeGenerationLaunchDelegate.java:266)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
at org.jboss.tools.hibernate.jpt.ui.wizard.GenerateEntitiesWizard$2.runInWorkspace(GenerateEntitiesWizard.java:101)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1645) Wildcard in packages does not work in Spring Boot jar
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1645?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1645:
-------------------------------------
I launched the main in the Application class, and it seems to work for me, or at least the rule gets fired and indeed it prints
{code}
2017-07-04 19:22:26.017 INFO 21441 --- [ main] o.d.c.k.builder.impl.KieRepositoryImpl : KieModule was added: FileKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT,file=/home/mario/Downloads/droolsSpringBootIssue-master/build/resources/main]
>>> Rule fired <<<
2017-07-04 19:22:27.105 INFO 21441 --- [ main] com.company.Application : Started Application in 4.734 seconds (JVM running for 5.347)
{code}
What am I missing?
> Wildcard in packages does not work in Spring Boot jar
> -----------------------------------------------------
>
> Key: DROOLS-1645
> URL: https://issues.jboss.org/browse/DROOLS-1645
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Final
> Reporter: Jacek Hola
> Assignee: Mario Fusco
>
> In applications built with Spring Boot the resources under {{src/main/resources/}} are packed into jar in {{BOOT-INF/classes/}}. That's why when in {{kmodule.xml}} someone specifies
> {code:xml}
> <kbase name="base" default="true" packages="com.company.*">
> ...
> </kbase>
> {code}
> then for example resource {{src/main/resources/com/company/rule.drl}} will not be picked up, because the path in jar(zip) is {{BOOT-INF/classes/com/company/rule.drl}}.
> From my investigation it seems the logic in org.drools.compiler.kie.builder.impl.KieBuilderImpl#isFileInKieBase does not recognize these files as it compares the packages for equality or if one starts with the other.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1645) Wildcard in packages does not work in Spring Boot jar
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1645?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1645:
--------------------------------
Sprint: 2017 Week 26-27
> Wildcard in packages does not work in Spring Boot jar
> -----------------------------------------------------
>
> Key: DROOLS-1645
> URL: https://issues.jboss.org/browse/DROOLS-1645
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Final
> Reporter: Jacek Hola
> Assignee: Mario Fusco
>
> In applications built with Spring Boot the resources under {{src/main/resources/}} are packed into jar in {{BOOT-INF/classes/}}. That's why when in {{kmodule.xml}} someone specifies
> {code:xml}
> <kbase name="base" default="true" packages="com.company.*">
> ...
> </kbase>
> {code}
> then for example resource {{src/main/resources/com/company/rule.drl}} will not be picked up, because the path in jar(zip) is {{BOOT-INF/classes/com/company/rule.drl}}.
> From my investigation it seems the logic in org.drools.compiler.kie.builder.impl.KieBuilderImpl#isFileInKieBase does not recognize these files as it compares the packages for equality or if one starts with the other.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1648) Maven dependency resolution through "LATEST" and "RELEASE" version labels using "KieServices.newKieContainer(ReleaseId releaseId)" method fails
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1648?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1648:
--------------------------------
Sprint: 2017 Week 26-27
> Maven dependency resolution through "LATEST" and "RELEASE" version labels using "KieServices.newKieContainer(ReleaseId releaseId)" method fails
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1648
> URL: https://issues.jboss.org/browse/DROOLS-1648
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Environment: OS: macOS Sierra (10.12.5)
> Hardware: MacBook Pro (13-inch, 2017)
> Reporter: Pyit Phyo Aung
> Assignee: Mario Fusco
> Priority: Minor
>
> I tried to use KieScanner for automatic business rule deployment through kjar modules setup in private maven repository. For that, I tried to specify getting latest kjar modules using "LATEST" and "RELEASE" version labels. They failed for three drools versions I tried (6.5.0.Final, 7.0.0.Final and 7.1.0.Beta3). However, when I tried open-ended version label, solution works. So, I believe that there is issue in dependency resolution related to KieContainer through KieServices.newKieContainer(ReleaseId releaseId) method.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-1279) principal-query attribute of jdbc-realm is required but description says false
by Claudio Miranda (JIRA)
Claudio Miranda created ELY-1279:
------------------------------------
Summary: principal-query attribute of jdbc-realm is required but description says false
Key: ELY-1279
URL: https://issues.jboss.org/browse/ELY-1279
Project: WildFly Elytron
Issue Type: Bug
Reporter: Claudio Miranda
Assignee: Darran Lofthouse
jdbc-realm description, for principal-query attribute says it is required=false, nillable=true, but that is false, because a jdbc-realm cannot be added without a principal-query.
{code}
/profile=full/subsystem=elytron/jdbc-realm=*:read-resource-description
{
"outcome" => "success",
"result" => [{
"address" => [
("profile" => "full"),
("subsystem" => "elytron"),
("jdbc-realm" => "*")
],
"outcome" => "success",
"result" => {
"description" => "A security realm definition backed by database using JDBC.",
"capabilities" => [{
"name" => "org.wildfly.security.security-realm",
"dynamic" => true
}],
"access-constraints" => {
"sensitive" => {"elytron-security" => {"type" => "elytron"}},
"application" => {"elytron-security" => {"type" => "elytron"}}
},
"attributes" => {"principal-query" => {
"type" => LIST,
"description" => "The authentication query used to authenticate users based on specific key types.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"value-type" => {
{code}
The add operation with no principal-query
{code}
/profile=full/subsystem=elytron/jdbc-realm=jdbc2:add
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYCTL0155: 'principal-query' may not be null"},
"rolled-back" => true
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months