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

Bug 1051105

Summary: Build & deploy will fail with a user defined kbase and ksession.
Product: [Retired] JBoss BRMS Platform 6 Reporter: Marek Baluch <mbaluch>
Component: Business CentralAssignee: Maciej Swiderski <mswiders>
Status: CLOSED WONTFIX QA Contact: Jiri Locker <jlocker>
Severity: high Docs Contact:
Priority: medium    
Version: 6.0.0CC: etirelli, kverlaen, mswiders, vigoyal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
A BRMS project that contains a user defined kbase and ksession will fail auto deployment to the runtime engine unless these are marked as default. This is expected behavior and is not likely to be changed in the future. The runtime engine expects kbase and ksession names in order to be deployed but these are not available for user defined artifacts.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-03 16:20:57 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:
Attachments:
Description Flags
screencast
none
stacktrace1
none
stacktrace2
none
kmodule with default kbase and default stateful session
none
server.log with NPE none

Description Marek Baluch 2014-01-09 17:22:17 UTC 
Description of problem:
'Build & Deploy' of a project will fail if a user defined kbase and/or a ksession is present. Despite that the status dialog will say 'Build Failed' the jar is generated in the repository and the kmodule.xml file has correct content.

How reproducible:
100%

Steps to Reproduce:
1. Create a new project (e.g. project2)
2. Switch to 'Knowledge bases and sessions' in the 'project editor'
3. Add a new kbase (e.g. kbase1 - optionally make it default)
4. Add a new ksession (e.g. ksession1 - optionally make it default)
5. Save the changes and hit 'Build & Deploy'

Actual results:
When 'Build & Deploy' is hit the build process will FAIL.

Expected results:
When 'Build & Deploy' is hit the build process will PASS.

Additional info:
'Build & Deploy' will fail also when:
1) only a user defined kbase (kbase is made default) is present with no user defined ksession
2) both user defined kbase and ksession is present
- weather the kbase or ksession is made default does not make any difference
Comment 1 Marek Baluch 2014-01-09 17:23:31 UTC 
Created attachment 847739 [details]
screencast

Added screencast which shows how to reproduce the issue.
Comment 2 Marek Baluch 2014-01-09 17:25:05 UTC 
Created attachment 847740 [details]
stacktrace1
Comment 3 Marek Baluch 2014-01-09 17:25:45 UTC 
Created attachment 847741 [details]
stacktrace2
Comment 4 Maciej Swiderski 2014-01-09 18:30:48 UTC 
Marek,

actually this is by design. What fails is the deployment to runtime engine (might be we could try to enhance the message to be more meaningful). As this is auto deploy it expects to have either no kbase/ksessions defined or have both marked as default so it can bootstrap the right ones without additional information. 
Additional information is kbase name and ksession name that can be provided when deploying kjar using Deployments View.

Please also note that for runtime engine only ksession of type statefull is supported. I believe you used stateless and that's why it still was not possible to be deployed even when marked as default.
Comment 5 Marek Baluch 2014-01-09 18:48:33 UTC 
Maciej,

many thanks for the detailed explanation.

I have only one question. Should 'Build&Deploy' be enabled when the deployment cannot succeed? This is very confusing and I can imagine that customers will do the same mistake I did.

@MB
Comment 6 Edson Tirelli 2014-01-09 21:29:11 UTC 
Maciej,

Should the error message be changed to make it clear?
Comment 7 Jiri Locker 2014-01-10 09:56:49 UTC 
Created attachment 848124 [details]
kmodule with default kbase and default stateful session

I get NPE when building project with this kmodule (edited using Project Editor in the workbench). I think it complies with requirements in comment 4 - there is all the information needed to bootstrap a session during auto deploy.

Tested with BRMS. NPE stack trace will follow.
Comment 8 Jiri Locker 2014-01-10 10:01:37 UTC 
Created attachment 848125 [details]
server.log with NPE
Comment 9 Jiri Locker 2014-01-10 10:49:05 UTC 
So, the NPE is thrown if kmodule contains kbase with spaces in name. I think I should report it as a separate issue.
Comment 10 Maciej Swiderski 2014-01-10 10:54:12 UTC 
(In reply to Marek Baluch from comment #5)
> Maciej,
> 
> many thanks for the detailed explanation.
> 
> I have only one question. Should 'Build&Deploy' be enabled when the
> deployment cannot succeed? This is very confusing and I can imagine that
> customers will do the same mistake I did.
> 
> @MB
Certainly it needs to be documented - requirements for auto deploy. Disabling the button might be too much as then users won't be able to build and deploy to maven at all. While sometimes that is desired.
We plan to include some sort of deployment descriptors that might be a solution for this so users could specify what should be used when deploying. Would that be sufficient?
Comment 11 Maciej Swiderski 2014-01-10 10:55:44 UTC 
(In reply to Edson Tirelli from comment #6)
> Maciej,
> 
> Should the error message be changed to make it clear?

Edson, I believe detailed error message is shown in problems panel so changing the "flyover" message not sure will bring any additional value.
As mentioned in comment 10 it should be documented what is actually needed for auto deploy to runtime.
Comment 12 Maciej Swiderski 2014-01-10 10:58:12 UTC 
(In reply to Jiri Locker from comment #9)
> So, the NPE is thrown if kmodule contains kbase with spaces in name. I think
> I should report it as a separate issue.
better to have it as separate issue as based on stack trace it fails on actual build of the project and not deploy to runtime.
Comment 13 Jiri Locker 2014-01-10 11:06:32 UTC 
The NPE is unrelated to this issue and reported as bug 1051469.
Comment 14 Marek Baluch 2014-01-10 11:32:50 UTC 
(In reply to Maciej Swiderski from comment #10)
> (In reply to Marek Baluch from comment #5)
> > Maciej,
> > 
> > many thanks for the detailed explanation.
> > 
> > I have only one question. Should 'Build&Deploy' be enabled when the
> > deployment cannot succeed? This is very confusing and I can imagine that
> > customers will do the same mistake I did.
> > 
> > @MB
> Certainly it needs to be documented - requirements for auto deploy.
> Disabling the button might be too much as then users won't be able to build
> and deploy to maven at all. While sometimes that is desired.
> We plan to include some sort of deployment descriptors that might be a
> solution for this so users could specify what should be used when deploying.
> Would that be sufficient?

Yes I believe that would work.
Comment 15 Maciej Swiderski 2014-01-10 11:48:46 UTC 
thanks Marek, just for reference (and possible ideas on how it should look like) link to deployment descriptor bz: https://bugzilla.redhat.com/show_bug.cgi?id=1017327
Comment 16 Marek Baluch 2014-01-10 11:55:25 UTC 
you're reading my mind! that's what I was going to ask next :D. weather you have specifics about the deployment descriptor. thanks.
Comment 17 Kris Verlaenen 2014-01-28 20:39:32 UTC 
Should we close this off as won't fix and rather document the requirements related to defining kbases and ksessions to allow auto-deployment?
Comment 18 Marek Baluch 2014-01-28 20:51:42 UTC 
Give me one more day please. There may be more to this issue. Based on my latest attempts it seems that if deployed using the described way an error window will keep popping up with message: null. I would like to confirm or refute.
Comment 19 Marek Baluch 2014-02-01 09:11:05 UTC 
Nvermind - I'm unable to reproduce the issue I saw anymore.
Comment 20 Maciej Swiderski 2014-02-03 15:16:53 UTC 
Marek, so can we close this one?
Comment 21 Marek Baluch 2014-02-03 15:22:54 UTC 
yes we can. thanks!