Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1128661

Summary: Cannot build project after adding a knowledge base to kmodule
Product: [Retired] JBoss BPMS Platform 6 Reporter: Anton Giertli <agiertli>
Component: Business CentralAssignee: Marco Rietveld <mrietvel>
Status: CLOSED EOL QA Contact: Lukáš Petrovický <lpetrovi>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0.2CC: agiertli, alvesph.redhat, etirelli, jlocker, kverlaen, manstis, mbaluch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1011522 Environment:
Last Closed: 2020-03-27 20:03:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1011522    
Bug Blocks:    
Attachments:
Description Flags
all log of build action alvesph.redhat: review+

Comment 2 Jiri Locker 2014-08-11 11:28:12 UTC
I have examined previous releases and found out this issue affects all released BPMS versions since 6.0.0. Looks like bug 1011522 was only fixed for BRMS.

Comment 5 Paulo Henrique Alves 2014-09-30 18:53:23 UTC
Created attachment 942828 [details]
all log of build action

I have take some tests, the project build when I add Knowledge Sessions (Stateful and Stateless), but if I create another project and add dependence with this one and add a default kbase, the project does not build. See log.

Comment 6 Paulo Henrique Alves 2014-09-30 19:04:27 UTC
In the test, the Project2 depends of Project1. If in the Project1 I do not set a kBase as default the project build fine, but in my code when I try load a kieBase from the Project2 (org.kie.api.runtime.KieContainer.getKieBase()) create a default kBase of the Project1, and I can't read packages/facts from a Project2..

Ex:
KieServices kieServices = KieServices.Factory.get();
ReleaseId releaseId = kieServices.newReleaseId("org.kie.test", "project2", "1.0");
KieContainer kieContainer = kieServices.newKieContainer(releaseId);
KieBase kBase = kieContainer.getKieBase(); // This code load a default kie base from a project1.

Comment 7 Maciej Swiderski 2014-11-04 10:59:03 UTC
by making a dependency between kbases/kjars you effectively asking them to be merged and thus you can get hold of them from within same kieContainer. That's why they can be named so you can reference them directly to get the one you need. In my opinion this is expected.

Comment 8 Kris Verlaenen 2014-11-04 18:59:18 UTC
Lowering severity / priority as this seems to be working as expected.  If the error message needs to be improved (note it has already been improved a little in https://github.com/droolsjbpm/jbpm/commit/0739459d7d38179b88ceb45688473fbc535929c9), please let us know what you believe might be better.

Comment 9 Paulo Henrique Alves 2014-11-04 19:39:43 UTC
I believe that, Independent of hierarchical dependencies, when I call method getKieBase() from a project, I want a default KieBase of this project and not from a dependencies of this project.

Supposing that I have 2 projects, ProjA and ProjB, where ProjB depends of ProjA and each project have your default KieBase. When I load a KieContainer from ProjB and request a default KieBase (method getKieBase()) I expect that it returns a KieBase from ProjB and not from ProjA, seeing that I load KieContainer of ProjB and not from ProjA.

Comment 10 Maciej Swiderski 2014-11-05 11:09:20 UTC
if you have both kjars with default kbase set kieCOntainer will disable completely retrieval of default kbase as it won't be able to figure out which one to use. So if there is only one marked as default it will be returned regardless of what jar it comes from.

Comment 12 Maciej Swiderski 2014-11-24 16:12:58 UTC
for that kind of advanced deployment configuration 'Process Deployemnts'perspective shall be used. That's why there are various options to build (build and install vs build and deploy) is to allow users to not experience any errors in case they have more advanced setup.

I am in favor of not duplicating functionality and use build and deploy strictly to deploy default configuration.

WDYT?

Comment 13 Paulo Henrique Alves 2014-11-24 16:38:09 UTC
I think that is better do not duplicate and use default config to build and deploy too.

About comment 10, I have other principles to believe that this is not a right things to do.