[rules-users] conversion of .pkg file to other formats

[Knapp, Barry]

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 at lists.jboss.org
[mailto:rules-users-bounces at 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 at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080312/6a587773/attachment.html