How best to package decision tables in a jar?

[Tim Stephenson]

Within the development environment it makes complete sense to have
everything laid out as files in a directory structure but at some
stage I want to bundle this up into an application archive (.jar, .war
etc.). What is the recommended way to do this? I have made the
assumption that the XML will be generated prior to packaging and then
executed at runtime.

I have found that this is indeed possible by creating a jar file both
with all xml files in the root and also keeping the DTRules.xml in the
root and specifying within that a sub-dir for the edd, dt and map
files. This latter required a patch to StreamSource.

It looks like the magic happens in StreamSource. And by 'magic' I mean
successively trying several different approaches like resource loading
in several different variations as well as URL and file loading. Is
any of these preferred? Are some preserved for historical reasons but
not really desirable? I also see that a StreamSource implementation
can be provided externally to the API.

So I have some options but it started me thinking about what the
'expected' or 'recommended' way of doing this is? From my perspective
I would not wish to rely on a file system as it may not be available
so I am leaning towards the resource or URL approaches.

Thanks for your thoughts on this
Tim

[paul snow]

I don't think there is a "preferred" way to do this, at this time.  In fact, all of the production systems that I know of deploy the XML to the file system.  This is because the XML can be updated on the fly, and the Rules Engine can be managed to "pick up" this updated XML without rebooting the server.

This happens to be the way this has been done, not because this is the best way to do things.

If you can email me your patch to StreamSource, I will look at it, and (assuming all is well) integrate it into the 5.1-SNAPSHOT branch.

Paul

[Tim Stephenson]

I wondered if the file system approach was the commonly used style
from some of the naming that seems to imply the same (e.g.
RulesDirectory). Unfortunately platform-as-a-service (PAAS) providers
don't usually make that available. Also I believe (though have not yet
tested) that providing there is only XML in the jar and that no
caching is employed the resource will be reloaded from the jar each
time and the jar replaced by whatever means the PAAS provides.

Given that the file system is most common (even universal) I wonder
what you think of making a couple of specialised IStreamSource
implementations, for example FileStreamSource and ResourceStreamSource
that did just one thing? I see the API on RulesDirectory can take an
IStreamSource implementation in one of its overloads and the
FileStreamSource could be default for the others. Thoughts?

Tim

[Tim Stephenson]

As far as my existing patch to StreamSource, it is very minimal; just
some checks on the values of filepath (to avoid double / and thus
stream = null) and resourcepath (to assume stream name is absolute if
resourcepath is null).

If you prefer the specialised IStreamSource implementation suggestion
I will refactor more significantly.

Tim

diff --git a/dtrules-engine/src/main/java/com/dtrules/session/
StreamSource.java
index da9079b..6ffdb01 100644
--- a/dtrules-engine/src/main/java/com/dtrules/session/
StreamSource.java
+++ b/dtrules-engine/src/main/java/com/dtrules/session/
StreamSource.java
@@ -28,9 +28,14 @@ public class StreamSource implements IStreamSource
{
if(s!=null)return s;

if(ruleSet != null){
- s = openstream(type, ruleSet.getFilepath()
+"/"+streamSpecification)
+ String filepath = ruleSet.getFilepath();
+ filepath = filepath.endsWith("/") ? filepath : filepath +
"/";
+ s = openstream(type, filepath + streamSpecification);
if(s!=null)return s;
- s = openstream(type, ruleSet.getResourcepath()
+streamSpecificati
+
+ String resourcepath = ruleSet.getResourcepath();
+ resourcepath = resourcepath == null ? "/" : resourcepath;
+ s = openstream(type, resourcepath+streamSpecification);