Hello Richard, The build and test cases are very impressive, and a nightly build might have to do. There is only so much that test cases will cover of course. To use it in a production environment might make people nervous though.
It also built out of the box, without me having to tinker with pom.xmls and hunt and gather and guess for repositories to solve missing dependencies. I ran into that problem trying to build CXF and the wstrust sample.
It's a long story. My goal is to provide WS-Trust security to a webservice. The webservice is going to transfer information between third parties across the internet (but just WLANs for now).
I started off with PicketLink think that that would provide what I needed. I got the sample working, but the only thing I could get out of it is web-browser based SSO features. The contributed (Talend?) STS appears to work. What I need is a remote Java client making WS calls. For that it needs org.picketlink.trust packages, which apparently aren't implemented yet for JBoss 7. Plus it wasn't clear at all how to provide security without blanketing the web-server with HTML redirects (to web-browser login page). So that was game over.
I then tried to see if I could get this going with JBossWS-CXF. I couldn't immediately figure out from the documentation that one could choose from things like Axis2, CXF, or Metro. At first I though, yes, I have a choice, but then it became clear that JBoss is tightly integrated with CXF (only). Am I wrong?
Proceeding with CXF, basic web-services worked very well. @WebService. deploy. wsconsume.sh. new Service(), etc. worked great.
But then that WS-Trust can of worms again. Hand code WSDL, copy-pasting bits, trial and error, etc.
What I did is I tried to make the wstrust demo work, as is. Problem with that was the maven build process that comes with it, didn't work because of repository errors. I tried to poke around with reposity and plugin reposity urls, googling around to see where around the net I could find a close match to what it wants. Often I can muddle my way around when I run into repository issues, but this time I got stuck at one point.
I then tried to just try to make sense what that demo is made up off. Created a build process, made sure all the right stuff lands in the right places. This eventually deployed. The url for the app and the sts worked, and produced the wsdl it came with.
Then the trouble started. At runtime, the Java client (standalone Java app, not from inside JBoss), error: "None of the policy alternatives could be satisfied.". I created a topic about this here: https://community.jboss.org/message/755232
I couldn't for the longest time figure out what the heck this meant. "Alternatives"? What the heck is an "alternative". Can't it just do its thing and not look for "alternatives", and if it's not happy about a specific thing, just report what exactly it is that it is unhappy about? eg. "require token, but configuration not specifying the location of the sts where to get one" (just as an example). Very confusing.
The way I gathered the jar files needed at runtime for the Java client, was to let it run into class-not-found exceptions, and then searching the jar files for that class. I have scripts for that that lets me home in on the missing jars very quickly.
Error refused to go away. I then started to clue in that there are all these other cxf-rt-* jar files, offering various (optional) features that it would dynamically try to resolve at runtime. At the same time, someone asked me if cxf-rt-ws-security-2.6.1.jar is in the classpath. I tossed in all the jar files. Error stubbornly refused to go away. Trying to make sure that it's there at runtime, I do: Class.forName("org.apache.cxf.ws.security.policy.model.AsymmetricBinding");
Class resolves, but error remains. I forgot to mention, I've made it log "ALL", which revealed that "AsymmetricBinding is not supported". Which is why I tried the above Class.forName thing.
So I got stuck. No answers to be found anywhere. No related discussions with solutions anywhere.
My previous project was on JBoss 4.something, and there I used Metro, and made web.xml tie in a url to a servlet that comes with Metro. But now we want to upgrade to JBoss 7, and I need those new WS-Security features (WS-Trust specifically). PicketLink didn't do, and got stuck with CXF.
So then I tried to make a Metro based client, thinking that it ought to be able to deal with a web-service that's served up by CXF, because after all, we're dealing with "standards". Seems reasonable.
But then Metro wasn't happy, because it wanted to access a URL with "/mex" tagged on to the end. What the heck is "mex"... Why? Can I tell it not to? Is there anything in the wsdl that makes it do that?
Supposedly this metadata feature emerged some time in 2009. From what I gathered, CXF didn't get this until either earlier this year or end last year.
JBoss 7.1.1 uses CXF 2.4.6, but mex wasn't supported until 2.5.something. JBoss 7.2.0 which is what I'm using now, has 2.6.2, which should have it.
But CXF isn't making availale that "mex" url of the sts (wstrust sample). 404, error. Metro not happy. No way in Metro to tell it not to look for metadata. Metro assuming that even when wsdl doesn't specify it, that it's there and for it to go and get it. Error makes it cop out with an exception.
So much for the "standards". Now Metro can't access "older" web-services?
So either I find a workaround to make Metro not request mex, or convince CXF to make available mex. Can't find anything about this described in any document, or any online discussion someone else might have had about it.
Ok, next. Use Metro on the server side. CXF appears pretty tightly integrated with JBoss. But JBoss uses a module class-loading / resolution process, which ought to make it possible to make a specific app opt for an alternative (be it Metro, or Axis2, whatever). Not seeing a module for it, or anything that hints its already there. Searching for related information, I found one single message: https://community.jboss.org/thread/173486
Incomplete, left guessing, again. I tried to mock around with injecting some class-packages into sun.jdk module, but I could not make @WebService tie in to Metro. To test, what I did is made the method implementation throw an exception, which would reveal what called it. Either CXF was calling it, or nothing would work because I mocked with JBoss' configuration.
Stuck, again.
So:
* PicketLink doesn't do remote Java client based incoming WS-Trust.
* CXF doesn't pick up the security "features" "alternatives" (or whatever they're called) from the cfx-rt-*.jars even though they're available on the classpath.
* Metro can't call CXF because CXF isn't making /mex urls available
* Metro can't be installed on the server because JBoss is too cozy with CXF
My appologies for being a little frustrated, but I'm normally a lot more productive after weeks of doing stuff...
The current JBoss I'm using is the 7.2.0.Final-SHAPSHOT from Aug 22 which had a "stable" label on it, which I'm assuming, means, it passed all the unit tests. Very cool all those unit tests btw. I hope they're complete enough. (does it have any concurrent testing, simulating multiple incoming calls, kind of like a WS load test, stuff like that?)
I'm assuming that the latest-latest nightly build has further upgrades, changes, bug fixes, that makes CXF work better and that it resolves the AsymmetricBinding at runtime this time... I'll let you know what happens.
If it works, then I got finally past this problem, and the fun can begin, making an STS tie into user accounts at runtime (through those callbacks).