Please elaborate on, "url-pattern... unique to world"

This question is in reference to Atlassian Developer Documentation: Servlet Filter Module
Can anyone restate this note in the above page? It’s worded oddly and confuses me.

Because servlet filters are deployed beneath root, be careful when choosing each url-pattern under which your filter is deployed. If you plan to handle the request in the filter, it is recommended to use a value that will always be unique to the world!


1 Like

Basically anything in the url-pattern put after /plugins/servlet . So if you had /admin/* in the url-pattern - the real url-pattern is /plugins/servlet/admin/* .

Now the fun comes into play if a second add-on registers /admin. At that point /plugins/servlet/admin would go it while /plugins/servlet/admin/foo would go to your add-on.

The real fun though is if both add-on registered /admin/* - at that point I believe it’s basically whoever gets registered first in the plugin system that gets the url-pattern.

To avoid that - make your url-pattern unique. At Wittified we preface all of our servlets with /wittified/string-unique-to-add-on. We do the same with the . I would suggest doing something similar.



Thanks Daniel for your response. Are you saying to avoid registering our servlets with URLs under common paths, such as /admin, since someone may want to register a filter on everything under that path and potentially affect requests to you servlet. Is that accurate?

I’m not sure that’s what the page is saying.

…be careful when choosing each url-pattern under which your filter is deployed…

“be careful” makes no sense. If I am filtering on a specific pattern, say, /admin/foo, then I have to chose that pattern; I have no other choice.

with “be careful” they mean “be aware that you’re sitting next to other servlets” - every servlet will have the /plugins/servlet prepended to it.

You should avoid registering the servlet with /admin - /alj/admin would be better (because you can at least claim /alj ).

Side tangent. If you’re using webwork actions in JIRA you’ll have the same problem - just worse. The actual java class names matters there: