Websphere adaptions in forPackage and forResource

[Xnyle]

This change is the bare minimum needed so that this library is usable on Websphere.

Hope this minimal change gets accepted this time.

Websphere is not able to find resources if you don't add / to it.
This is especially a problem when using forPackage as the Websphere Classloader will never find anything!
In case of forResource you might find something but it might be incomplete!

[lorenzobenvenuti]

+1. I had to apply this patch in order to deploy my app on Websphere.

[ronmamo]

I hate websphere

[martin-g]

Me too!
On Aug 10, 2015 5:36 PM, "ronmamo" notifications@github.com wrote:

I hate websphere

—
Reply to this email directly or view it on GitHub
#85 (comment).

[Xnyle]

Very mature comments. I think we can all agree that WAS is one of the worst servers out there. But what does that assessment help? Either I am able to used reflections on the server the customer had chosen and paid millions for to IBM or I'm not. If not I have to maintain my own fork and others who have to use WAS will run into the same trap...

[martin-g]

My reasoning is: if you/your client pays for WAS then you/your client should file a bug at WAS reporting the problem and demand a fix in WAS.
Otherwise every library (like Reflections) should add such noise in its code to deal with yet another non sense in WAS (or any other unfriendly product).
Until you (the paying customers) start asking IBM to fix its sh*t, WAS won't be improved and we (the OSS developers) will suffer (by having to apply such kind of code to our libraries).
Point me to your bug report at WAS issue tracker and I'll give my +1 for your patch.

[Xnyle]

Yet reality looks different. My chances convincing our customer to file a bug report are nil even if I spend hour's explaining and convincing 10 different ppl who all have (or think they have) a saying in "organizing" this kind of stuff on their side. So i won't do this as I'm bound to limited resources myself.

Besides, even if IBM by some miracle will fix this, they will probably never bring out another patch for the current server version which our customer will probably use until 2050...

So in principle you are right, but the approach just isn't pragmatic. I guess that's the reason other projects on Apache from which I basically stole the PR patched their libraries as well.

[ronmamo]

@Xnyle, regardless of my prev. comment (had to say it, can't control it ;),
We can easily normalise resourceName in forPackage/forResource to end with '/'.
That is more elegant, would work well for other environments as well, and save us from specifically mentioning that app server (or another)
WDYT?

[Xnyle]

But what if I only want to find a certain file in forResource? I don't know if always adding a / causes other problems on other servers in that case .

Even in forPackage I'm not sure if some other implementations maybe don't accept a trailing /

I try to only change the behaviour on WAS and also add some warn/debug logs in that case, so I won't break anything on other implementations Additionally I give users a chance to detect that there is some magic happening if they look at the logs.

Might blow up the code a bit but OTOH it doesn't break things for other uses cases.