good addition. You might want to add some information on one level wild card too which, by default, is "-\*-" unfortunately we don't have much documentation on it.

NOTE: I'm thankful for that last sentence myself.

Well here is the scoop that turns our couplet into a triplet. The one-level wildcard was introduced in Sun Java System Access Manager 7.1. The wildcard itself is -\*- and it matches only the level for which it stands without crossing delimiter boundaries. A policy can include the one-level wildcard in resource names to allow and deny access. For example, if you allow access to http://www.sun.com/b/-\*-/d in a policy definition then access to http://www.sun.com/b/c/d will be allowed but access to http://www.sun.com/b/c/e/d will be denied. -\*- would match any character but only at the defined level.

And, in honor of all the gurus at Sun, here's a music clip from a very funny and sweet movie called The Guru. It's American-financed but filmed in the Bollywood-style. (Any suggestions on some Bollywood movies I should see would be appreciated.) The song is called Chori Chori which from my perusal on the internet means "secretly".

Can you update your post to include that info? Its probably been over a year since this feature of single level wildcards was added to J2ee agents, so the discrepancy has been there for a while.

I think one of the big wholes in am documentation is that along with info about a feature, there isn't a list of limitations or restrictions about where it will or will not work. Because when I read documentation about a feature, the question I'm really asking myself is "is this feature useful to ME in my deployment?" and having to dig through lots of documentation or do my own tests takes a lot of time.

Done, Christopher. I've also passed your comment on the AM docs to the rest of the staff. We often have to ppppuuuulllllll information from those who know and it ain't easy but remembering to ask one question, "Are there limitations or restrictions to this feature?" is a good place to start. Thanks.

Perhaps it would make things easier if your code checkin requirements where updated so that it was required for developers to create their follow up cases in opensso bug tracker before they can check in code for the new feature at all.

Perhaps I should have called them "follow up issues" or "follow on issues" in the issue tracker rather than cases. For example, assume the single level wildcard Enhancement was issue 100 in the bug tracker and a developer implemented a patch for for J2ee agent support only. The code reviewers wouldn't let them check in the code until they filed a new issue for URL Agent support for Single Level wildcard which would be issue 101. Issue 101 is a "follow on issue" to Issue 100 because its required to fully (or ubiquitously) implement the feature.

Ahhhh, I see. But that is a whole can of worms that I, as a writer, am not privvy too. I don't know how the implementation of this particular feature began. Maybe it came from a customer or marketing rather than an Enhancement Issue. In which case it might have started out as a feature only for J2EE agents. Of course, the developer could than file a bug against the feature but if they are given a job to do for J2EE agents then there really is no bug from their perspective. These are good ideas though, Christopher, and I will bring them up in our engineering meeting to see what can be done.