We Keep Coding

Set up permissions/features in desktop application?

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.

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:
You're delivering your application as a .jar file,
Each customer gets their build directly from you, and there's a small number of customers,
You configure a build specifically for each customer, and
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.

You should consider using a License management api to do the same, which will give u both security and capability to change License pre/post installations.
It is not advisable to build adhoc licensing capabilty, take a look at License3j and TrueLicense, they are both free and can help you gain perspective or better fulfil your requirement

You could try and encode that in a file. I assume each user has an own installation/version of the application, right? I further assume the application should not need to check some web resource. Thus you need to implement that in a file.
However, you should encrypt that file and put the salt and key somewhere in the code where they can't easily be decompiled. Additionally create a hash to check for modifications of the file. That hash could be based on the application's size or something else.
Please note that there's no 100% security and any hacker could still crack your application. But in that case this would need some form of criminal energy not commonly present in the business world.

Modularize the application and deploy to each client only those parts that he wants/has access to. There's many ways to do it (the most complete but heavyweight being OSGi), but the specifics depend on your circumstances and requirements.
The quickest way to implement it might be to simply extract your extra functionality in separate JARs, and on deployment update the classpath appropriately.

It depends on the kind of application,kind of security you want and the number of people likely to use the application.
If the number of clients is not that big you can store their preference in some in memory data structure like a Map . Otherwise you can use file system or a DB depending upon the kind of security you want.

This is very open ended - it really depends on what you're trying to achieve, and what you mean by a feature.
One approach is to use a plugin based architecture. e.g. you have an interface
public interface Feature {}
and provide each of your ten features as implementors of this interface. Then have some method which runs at application start which looks for Feature subclasses on the classpath.
You can control which features a client has by including only the relevant features on the classpath, e.g. using maven.

Generating Java from WSDL for use on Android with ksoap2-android SOAP client?

I have to access a existing SOAP webservice from an Android application. I have been provided some WSDL files describing the webservice. Reading some other answers here on SO, it seems ksoap2-android is the way to go, with respect to which SOAP client to use.
The next issue is then how to generate the Java classes needed from the WSDL files, and this is where I am coming up short. As far as I can see there are the following options:
AXIS2 code generator
WSDL2ksoap
JAX-WS wsimport tool
I initially tried #1, with the AXIS2 eclipse plugin for wsdl2code generator. The wizard did successfully generate a lot of Java code, however it also changed my android project to some kind of webservice project, and I was never able to get anything that was generated to compile, let alone work with ksoap2-android. Has anybody has success with this?
I am not able to run wsdl2ksoap successfully, as it seems to require a running webservice, and all I have at the current point in time is WSDL files. Likewise from reading the webpage, it seems to be a project in its initial stages, and not really ready for prime time.
JAX-WS wsimport I have not had a chance to try yet. However I am unsure if what it generates will work with ksoap2-android?
Question: How can I generate Java files from WSDL files, for use on Android with ksoap2-android SOAP client library?
Thanks a lot in advance.
(PS: Yes, the choice is SOAP, it is suboptimal for Android use, but I cannot change that.)

I found this tool to auto generate wsdl to android code,
http://www.wsdl2code.com/example.aspx
Here is the code:
public void callWebService() {
SampleService srv1 = new SampleService();
Request req = new Request();
req.companyId = "1";
req.userName = "userName";
req.password = "pas";
Response response = srv1.ServiceSample(req);
}

I had similar situation (I had only wsdl file without working webservice). I've used
http://easywsdl.com/
to generate classes for android without any problem. This tool uses ksoap library. The great thing with this tool is that it supports WCF extensions and types like data contract with IsReference attribute or Guid.

My conclusion after quite a bit of researching is that there is no such (mature) tool available, unfortunately. Neither AXIS2 or JAX-WS will work on Android, and WSDL2ksoap is simply too immature for any real use.
However there is a proprietary tool called wsclient++ that will do the job really well. (Read update below, when put to real use, it does not stand the distance at all.) It does not use the ksoap2-android client library, it has it's own.
The client library is a bit crude as it has a hard dependency on the http transport, making (unit) testing a bit complicated. But it can be modified quite easily to allow DI, as the source is available in the distributed jar file.
The wsdl to java generator however works just perfect, and will save us tons of time.
Update
After working with wsclient++ for a while, it is clear that the generated classes are really crude, and does not handle error cases at all. (Every method declares throws Exception).
We are no longer using wsclient++, and I would not recommend anyone to use it!
We have not really found any working alternative, unfortunately. :/
In the end we converted our WSDL files using AXIS2, and then wrote a bunch of custom script to strip and transform the generated java files to something that will build on android using ksoap2-android library. Very hackish, and needs tons of manual labor to run. Unfortunately. If you find a better way, or one comes up, please provide a new answer.

I use Apache CXF tool just to create dto, and i wrote a class to perform a basic unmarshalling based on name of elements

A bit late on this, but there is a ksoap2 stub generator under development, and I successfully used it to create the stubs.
http://ksoap2-stub-gen.sourceforge.net/
Also someone made it availabe as an online service (i.e. you give your WSDL's URL and the service will return a zip file containing the stubs).
http://www.davidgouveia.net/2011/04/online-stub-generator-for-android-applications-using-ksoap2/

I have used for iPhone too some auto-generated classes I wanted to see here too.
wsdl2code is one of the similar what I have used at iPhone. Give an url with wsdl file you will get some classes to download. For me the hardest part it was to download the required parts. It took more than 2 minutes of searching :) ksoap2-android-assembly-3.0.0-jar-with-dependencies.jar needed to download ad drag-and-drop to ADT ( Eclipse) . It is super easy, especially if you have used the counterpart at iPhone. - a similar tool I have used.
However in my case I am not happy at all with the solution, because I see I am using cannon, a set of cannons to shot a sparrow. In my case it should be used a HTTP Post and not including dependencies from other libraries.
To be honest I don't care to much, because once the server side believe we have unlimited battery power and unlimited data plan, than I close my eyes and I don't care about marshaling-unmarshaling overheads, which use the CPU ( battery ) increase the data transmitted over network.
In worse case it should be a JSON + HTTP POST not SOAP for mobiles...
I would suggest to talk at server side guys and explain for they why it will not good if they do 2 click on wizards and we do other click on forms to get the generated code. At least while the application is not a huge one, even than should be budget to optimise for mobile a few interfaces implementations.

Communication model: C++ and Java

Pals,
I have a requirement to establish a communication channel between C++ and Java layer of my application for the exchange of objects and their properties.
I have got the following options:
XML / SOAP
Postgre SQL
Can you please advice me the Pros & Cons on these. Please share your experiences on the implementation complexities.
Thanks,
Gtk

If the option is between those I would choose XML
Object <=> XML
Java side Simple, C++ side XML Objects
Reason, its simpler for what you want, i.e. pass language objects and not Data Base
Ah, could you specify the communication channel between the apps ?
UPDATE
If you can use JSON I would recommend it instead of XML, here is why.

Another option would be JMS. There are C++ clients out there.

Every time I see XML I think RESTful web service. Both platforms you mentioned have some form of tooling to marshal & unmarshal XML. There are plenty of working examples out in the wild, so a Google/Bing search is good. A nice side-effect is once you have those interfaces built, anything can connect to them.
If you really want to bother with generating a WSDL, then feel free to go the SOAP route. However, speaking with several years of web service integration experience, RESTful is so gosh darned simple compared to anything else.

I would like to suggest a third option : YAML
You have parsing library in YAML for both java and C++. In my experience, it's easier to debug exchange in YAML that in XML (especially if you got full text field or cyclic data structure).

I depends of the kind of message you transfer.
If your message are individual entity that have a short live, I would go for XML, YAML or something similar.
If your message contains information that is going to be used later on and refer to information in previous messages, I would use a database.

How to create WSDL file given SOAP WSDL operations

I haven't had any experience with web service related development. So, any ideas will be greatly appreciated.
Suppose, I have a file listing draft specification of WSDL operations. Following is one example. How would I go about creating the WSDL file. Is notepad sufficient or do I need to have WSDL editor?
getHostSystemInfo
Returns detailed information about host systems specified via given IDs.
input HostSystemIdCollection(Collection of Strings)
Output HostSystemInfoCollection
HostSystemInfo
Id: mandatory
Properties: Following properties should be provided for host systems
HostSystemName
HostSystemProperty1
HostSystemProperty2
HostSystemProperty3
....
....

If the question is just "how do I create the WSDL" then you could indeed use Notepad and just write it, it's only XML after all. However, writing syntactically correct XML by hand is pretty dull, and error prone. So I would recommend using WSDL aware tooling for example an Eclipse editor
An alternative is to write some Java which expresses the interface, and from it generate the WSDL. There are many ways of doing this, including starting with an EJB and annotating it accordingly. A few googles should help you find what you need.
My experience is that simple POC situations tend to work well starting at the Java. Larger scale projects benfit from considered designs starting at the WSDL.

coding WSDL by hand is a big pain! i used a XML editor for creation of and then generated the stubs with JAXWS. It is important to understand and differences of the WSDL styles, which is not trivial (have a look at WSDL styles). a good help is to import the WSDL schema to your IDE (eclipse, idea) and then work with autocompletion.
just for interest, why are you using WSDL + SOAP. if you have a choice and you use anyway HTTP, have a look at REST. It can make implementation of web-api a LOT easier, both on server side and for api-clients.

If you haven't done any web services before, I would strongly recommend a WSDL Editor. The Netbeans has a plugin that should help.
The other way of doing it, which may be easier is by using the Java annotations defined in JSR 181.

Of course you could use the worst text editor in the world (!) but I'd seriously consider using any decent XML editor or IDE (Eclipse's WSDL support is pretty decent). This will save you a lot of pain and suffer.
Or, if this is an option, you could just annotate a Java class with JAX-WS annotations and have your WSDL dynamically generated from the Java code. Personally, I prefer the WSDL-first approach, the Java-first approach is just a suggestion to get you started.

You could use Axis2 to create that for you.

Working with large wsdl, can we trim it?

My webservice provider give me a large WSDL file, but we are going to use only a few function inside.
I believe that the large WSDL have negative impact to the application performance.
We use the webservice in client appliction, startup time and memory usage are issues.
Large WSDL means that jax-ws will takes longer to do binding and will takes more memory for the stub class.
Is is possible that we trim WSDL file to a lightweight version? Are there any tool for this purpose?
I do not think my webservice provider will generate another WSDL for us. We may have to do it auto in the build script.

In short, your answers are "No tool, but you can DIY".
I wish there are simple tool can do it because my WSDL contains too many unused function and schema of data structure.
If I can automate it, WSDL -> trimmed WSDL -> generate client stubs classes. Nothing unused will be generated, no misuse, no maintenances required, we will not touch on the generated code, and I can really focus on the code which in use. Smaller JAR, shorter XML parse time. If the WSDL get updated, I will had only to rebuild client stubs classes and run unit test.
I tried to keep off from human invoked. It takes time, easily to get mistake, and have to redo every time every little change on the original WSDL.
I am not conversant on the WSDL schema. I am thinking can it be done by XSLT?

The size of the WSDL will have zero impact on performance... unless you are downloading it and/or parsing it for every request. And if you are doing the latter, don't. It need only be processed when the service changes, and the service should always change compatibly, with continuing support of old messages (at least for some overlapping time period).
You should consider processing a WSDL to be a program change, and do it as you would any release, with versioning, and testing, etc.

The problem is not with the size of the WSDL itself. It's the size of the generated code that matters. For instance, if you use Axis2 to generate your code from a large WSDL, you'd end up creating a Request/Response class for every WSDL operation, as well as the classes of their return types. You'd end up with a huge stub class later on, which could affect performance since it would import classes that are required by web service operations that you don't need.
There's no easy tool to do that. I usually use notepad++ to do that, and YES you could always make mistakes while doing it.
Another common mistake is choosing to generate both Sync and Async style methods, when most of the time (In my case at least), you'd only use Sync style methods. This could dramatically increase the size of your stub as well.

I haven't used the tools that you're talking about, but you can successfully execute web service methods without the code ever touching a WSDL file.
This seems like a good time to run a quick test. Cut everything from the WSDL file except what you need to execute one of the simpler methods you plan to use. Reference that copy of the WSDL instead. If it works, you know what to do next!

There is no need to trim the WSDL. If you're set on going down this path, simply delete anything in the stub classes that you don't need. Just make sure to test it as you go to make sure everything is still working.

You could just manually remove the <wsdl:operation> elements corresponding to the methods you don't need and see if that's enough. You should be able to remove those elements without touching the rest of the file.

The physical size of the WSDL should not matter if you generate client stubs classes at compile time (e.g. via AXIS wsdl2java.) If you are downloading the WSDL and parsing it for each request then the download time will likely dwarf the parse time. Consider caching the file locally if the download time becomes an issue. If the parse time becomes an issue you may want to consider trimming the file or caching the parsed objects. Use care when caching or trimming the file as you will need to integrate any changes when your provider issues a new WSDL. Consider updating your cached/trimmed WSDL each time the service is restarted or at some interval.