Description of problem: - The process for dynamically loading rules from the BRMS repo is apparently fundamentally broken. On the Guvnor pages, I can clearly see a link to a ChangeSet URL which, presumably, could be used to load rules from the repo. However, the server password protects this connection. And the tool used to load those, the ResourceFactory, doesn't, apparently, include any method for passing a username and password for basic HTTP authentication (beyond encoding it in the URL, which I'm not sure is a good idea). What's worse, perhaps, is that the ChangeSet files that are downloaded invariably refer to a repo location, also accessed via HTTP, and also password protected. While it is possible to put the authentication info in the change set files if you download them and bundle them into your application, it seems a little . . . silly . . . to have to do that. In the end, I'm trying to sort out if there is, in fact, any possible way to leverage the repo directly via these URLs, or if I'm essentially stuck with an export from the repo to an application-local bundle in order to get this functioning. It seems to me that I have three options: - turn off the login-config.xml settings for the brms deployment, effectively making the entire repo open to the world, which isn't a good idea, generally, I think. - Download the changeset and bundle it, after making appropriate changes (which still doesn't work properly, more on this next). - Download the rules themselves and bundle them, which, frankly, begs the question: why have a separate BRMS repository? A better fix, of course, would be for the ResourceFactory to allow for usernames and passwords, or other authentication schemes, and for the BRMS server to include the same auth in the changesets by default when downloading. Or something like that. It seems that we've effectively secured the server without providing a cogent or obvious way for the client to access it. That seems like a ship blocker to me. - After fixing the changeset to use the authentication, I still have issues due to incompatibility of the libraries used on the client and server side. Specifically, the MVELDecoder was giving me serialization ID issues. I used the Drools runtime files generated by JBDS 4.0.0 to no avail. I just downloaded JBDS 4.1 today, and I'll give that a try, but so far, the solution seems to be to copy out the runtime jars from the deployed application jboss-brms.war, because I'm not seeing those jars anywhere else in the 5.2.ER2 deployment I have running. That's beyond frustrating. These are the two big ones. Consider, also, that Seam uses Drools libraries, and that that integration may not be very clean. That's likely part of the problem I'm running in to here (it's basically a Seam app that's acting as the client - I'm wrapping the KnowledgeBase in an application-scoped Seam component). It may get worse. I'll keep you posted. For now, I'm going to have to go with bundled rules for the sake of expediency. I can file these in bugzilla as well, if you'd like. Thanks, Will Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(In reply to comment #0) > Description of problem: > > - The process for dynamically loading rules from the BRMS repo is apparently > fundamentally broken. On the Guvnor pages, I can clearly see a link to a > ChangeSet URL which, presumably, could be used to load rules from the repo. > However, the server password protects this connection. And the tool used to > load those, the ResourceFactory, doesn't, apparently, include any method for > passing a username and password for basic HTTP authentication (beyond encoding > it in the URL, which I'm not sure is a good idea). What's worse, perhaps, is > that the ChangeSet files that are downloaded invariably refer to a repo > location, also accessed via HTTP, and also password protected. While it is > possible to put the authentication info in the change set files if you download > them and bundle them into your application, it seems a little . . . silly . . . > to have to do that. In the end, I'm trying to sort out if there is, in fact, > any possible way to leverage the repo directly via these URLs, or if I'm > essentially stuck with an export from the repo to an application-local bundle > in order to get this functioning. It seems to me that I have three options: > - turn off the login-config.xml settings for the brms deployment, effectively > making the entire repo open to the world, which isn't a good idea, generally, I > think. > - Download the changeset and bundle it, after making appropriate changes (which > still doesn't work properly, more on this next). > - Download the rules themselves and bundle them, which, frankly, begs the > question: why have a separate BRMS repository? > > A better fix, of course, would be for the ResourceFactory to allow for > usernames and passwords, or other authentication schemes, and for the BRMS > server to include the same auth in the changesets by default when downloading. > Or something like that. It seems that we've effectively secured the server > without providing a cogent or obvious way for the client to access it. That > seems like a ship blocker to me. > > - After fixing the changeset to use the authentication, I still have issues due > to incompatibility of the libraries used on the client and server side. > Specifically, the MVELDecoder was giving me serialization ID issues. I used > the Drools runtime files generated by JBDS 4.0.0 to no avail. I just > downloaded JBDS 4.1 today, and I'll give that a try, but so far, the solution > seems to be to copy out the runtime jars from the deployed application > jboss-brms.war, because I'm not seeing those jars anywhere else in the 5.2.ER2 > deployment I have running. That's beyond frustrating. > > These are the two big ones. Consider, also, that Seam uses Drools libraries, > and that that integration may not be very clean. That's likely part of the > problem I'm running in to here (it's basically a Seam app that's acting as the > client - I'm wrapping the KnowledgeBase in an application-scoped Seam > component). It may get worse. I'll keep you posted. > > For now, I'm going to have to go with bundled rules for the sake of expediency. > I can file these in bugzilla as well, if you'd like. > > Thanks, > Will > > > Version-Release number of selected component (if applicable): > > > How reproducible: > > > Steps to Reproduce: > 1. > 2. > 3. > > Actual results: > > > Expected results: > > > Additional info: Hi Prakash, problem is that you don't set up authentication. When accessing URL resources that need authentication you either have to provide username and password in URL or set Authenticator. I include a piece of code that might help you. If you run this before creating URL resource it will work (assuming you have an admin account with password admin). To ensure security more things should be done (encrypting the password in code, creating user with readonly access to resources etc.). Also please note that preffered way of accessing the Guvnor changeset is through KnowledgeAgent to allow dynamic changes. Authenticator.setDefault(new Authenticator() { @Override protected PasswordAuthentication getPasswordAuthentication() { if (getRequestingPrompt().equals("users")) { return new PasswordAuthentication("admin", "admin".toCharArray()); } return super.getPasswordAuthentication(); } });
Re-assigning to Documentation component since there is nothing development needs to do.
As for the second problem. If I recall correctly, the client and server should use the exact same drools version (which transitively includes the mvel version). If they're using maven/gradle/ivy/buildr, then it's a matter to of specifying the same drools version on the client and the server pom's. If not, then copying the jars from the distribution is probably the best thing you can do.
Is this still an issue with 5.3.1?
Closing this issue. If it's still an issue, please reopen with a comment explaining what is required from docs.