Rick,

 

We had the same issue/concern and chose to pass the drl to our engine.  We bypass the default BRMS deployer and created a custom servlet to return the drl.  Here is some logic that will generate the drl.

 

PACKAGE_UUID = uuid of your package

REPOSITORY_SERVICE = "org.drools.brms.client.rpc.RepositoryService";

 

 

                    ServiceImplementation imp =

                        (ServiceImplementation)Component.getInstance(

                                    RulesManagementConstants.REPOSITORY_SERVICE );

                   

                    String  responsePayload = 

                        imp.buildPackageSource(

                                    RulesManagementConstants.PACKAGE_UUID);

 

 

As a warning though, you may run into upgrade issues since you are entering the non-supported api.

 

Barry

 

 

 

From: rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Mark Proctor
Sent: Tuesday, March 11, 2008 6:29 PM
To: Rules Users List
Subject: Re: [rules-users] conversion of .pkg file to other formats

 

Rick Lacy wrote:

Greetings. 

 

I'm using Drools for a project at work.  I'm investigating the feasibility of using the BRMS in our environment.  I have a question about the binary packages that are available for download from the BRMS.  Given one of these .pkg files, is there an easy API call that would get me a text string representing the .drl file equivalent of the .pkg file?  I realize that I can use the 'Show package source' from the BRMS.  However, if we decide to go with .pkg files for deployment, it would be really nice to be able to get a human-readable form of what was last deployed to production for any given .pkg for auditing / troubleshooting purposes.  I perused the docs, and I found something similar to what I want, but it seems to be specific to decision tables.

Not really a Package is trimmed down for transport. For instance the text representation of the consequence is gone, it's just bytecode now. You could intheory make a reverse engineering utility, like you can already do for bytecode, but we have nothing like this now.

 

Thanks,

 

 

Rick

_______________________________________________

rules-users mailing list

rules-users@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/rules-users

 

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users