Question

i have a desktop application that consists of 10 features, and some clients asks only for 8 features or 7 features.
i want to have a way to manage adding/removing the permissions/features for the client (only i can control that). so that i can hide/show feature based on a flag.

is that should be done through a property file that contains the name of the feature with boolean flag, or what ?

please give me some ideas, thanks.

Answer 1

From your other answers, it sounds to me like the following additional details have cropped up; please let me know if I have these wrong:

1. You’re delivering your application as a .jar file,
2. Each customer gets their build directly from you, and there’s a small number of customers,
3. You configure a build specifically for each customer, and
4. You don’t want your customers to be able to modify their feature access.

In that scenario, I’d store the “active” feature list in a hashed property value stored in a .properties file bound into the .jar. I’ll describe one way to do that below. You generate the properties file just before delivery, add the file to the jar:

jar -uf applicationJarFile.jar configuration.properties

then sign the .jar and deliver it. At runtime, your app can load the properties file, run the hash of each feature, compare with the properties you’ve stored, and determine which ones are off or on.

Your properties, which determine which features are enabled, might consist of a list like this:

feature1=enabled
feature2=disabled
feature3=disabled
feature4=enabled

Write yourself a utility which hashes the whole string “feature1=enabled” plus a salt value, e.g. “feature1=enabledaKn087*h5^jbAS5yt”. (There’s code for this built into java; see How can I generate an MD5 hash?, for example.) The result will be an opaque 16-byte number, which you can then store in another properties file to be included in your app: feature1=1865834…. The salt value should be broken into multiple shorter strings in your code so your customer can’t just retrieve it and easily duplicate the process themselves.

In your app, at startup, you construct the string above using both the “enabled” and the “disabled” value, run the MD5 of both, and compare it with the stored hash. That’ll tell you what features to enable.

I think a separate .jar or .properties is a bad idea; it clutters your delivery.

You can automate the whole process fairly easily, since you can generate the properties on the fly any time, and bind them into your app.

You can add other “baked in” properties which gives you a lot of flexibility in the final deliverable, including things like skinning for customer branding.

As others have pointed out, though: there’s lots of ways to approach this, depending on the rest of the details of your product and your overall goals. This is one way to do it, given the assumptions above. AFAIK, there’s no “canonical” way to do this sort of thing.