In this new world of micro-services, our need for understanding Web\Application servers has just dropped a notch. This is because, in general using Restful micro-services delivered by the SDL RnD team, there is no need for an application server for the several micro-services. For your Web Application itself there is very little Tridion interference. Some included jars/dll's depending on your flavor of the .NET/JAVA divide and a sprinkling of config files, that allow your Web Applications to connect with the new all-knowing discovery service and you are good to go!
Buuuut, yes but (look at the title there had to be a "but") when you are not ready to go all restful because of the many reasons customers are not ready to rest, then we are forced to go In-Process and use the unwieldy, bulky Content Delivery API stack to say "hello world". As years of working with Tridion has probably taught us, this is not such a big deal as we know the In-Process API will generally work just fine out-of-the-install-folder (I did not see any box ). However there is one well known exception, WebSphere! Yeah talk about a box, unwieldy, bulky and "I like things my way or the highway" Web Application Server. If you are lucky enough to have WebSphere as your "WebApp Server" (accept my condolences first of all) then understand this, it is probably not going to work as per docs.sdl.com.
Ok so point number two docs.sdl.com is a guide not a fact with WebSphere… OK? (why do I feel I am repeating myself?)
How do you make it work then I hear you ask? Well…. I have had the p[lr]e[as]sure of having to make 4 different websites perform the tasks they were meant to do using WebSphere. I found out 4 different limitations on the way which I would like to share here. The fact that I found a different one every time has told me that I don’t know the length and breadth of this process, so I will state the known must-do's and leave you to send in  your comments on the rest.
Please note, I am no Java or WebSphere expert so if I am uttering rubbish and you know it, just comment…… nicely! Also this is not an installation guide, I am just trying to share my experience while trying to get my SDL Web based websites to work on WebSphere.

Point 1:The Java on the Server, is not your Java!
Yeah, you read that right, WebSphere has its own Java and unless that Java meets up with the SDL Web CD Prerequisite of Java 8 you are going to go around in circles for a long time banging you head on the table on why nothing seems to work! Pre WebSphere 8.5 you really could not use Java 8 which is a Prerequisite for SDL Web 8 and beyond so be careful here. To check your Java version follow this steps

On Windows : run %WAS_HOME%\java\bin\java -fullversion (e.g) c:\WebSphere\AppServer\java\bin\java -fullversion

On Unix : run $WAS_HOME/java/bin/java -fullversion (e.g) /opt/WebSphere/AppServer/java/bin/java -fullversion

If you are using the wrong version google your way out.

Point 2:Children need to be taken care of before their parents
There is a setting in WebSphere that -seems to - allow you to determine the order in which classes are loaded in order to get the correct versions, classes and jars to be used in your Web Application. In a nutshell with so many classes belonging to several jars in the Java world (who does that?), you could (in)conveniently have similarly named methods belonging to different classes in different Jars, the problem is somewhere along the line these classes\methods get confused on who is in charge. By default WebSphere goes with the "Parent-First" approach, meaning the parent (i.e. WebSphere >Server > Application >Module) has the highest priority while your web applications' jars has the lowest priority! You can turn this around and set the application to "Parent_Last" meaning you want your application to have priority. When using SDL Web CD jars this has to be the setting if not you will get a ClassCastException. To make this setting apply there are 3 levels (Server, Application and Module) where you can affect the change, I have always used one and it has worked.

Culled from http://www-01.ibm.com/support/docview.wss?uid=swg21260679 these are the steps to change classloader configuration at application level

1. Open the WebSphere Application Server admin console.

2. Expand the Applications navigation node in the left column and click Enterprise Applications.

3. Find and click on your application. (For example, WPF-GF_WebServices.war is the application used in this technote). You will see a screen with a list of properties for the application and some links for additional properties and related items.

4. Click the link for Web modules (on the right side under "Related Items")

5. Click the link for the Web module for the application.

6. Change the class loader mode to parent last.

7. Click OK.

8. Click the Save button and then, on the next screen, click the Save link.

9. Restart the application server so that the application will use the new class loader setting.

10. Rerun the model that executes the Web service.

Point 3:When jumping out of plane first take care of yourself before the kids!
In spite of the setting in point 2 WebSphere as a decidedly independent entity will always compare the classes your Web Application gives it to do its own mission critical activities - i.e when using Parent_Last setting and if it does not like the version or naming convention of your classes it goes "meh!" (i.e. several different errors that dont seem to add up to the issue) ….. And believe me it won't change its mind until you remove whatever class your application put in there and allow its own class to reign supreme. So find errors that say "a type is not a method"  and\or other errors and find the jar and …………

Point 4:Sometimes the child has to be the parent!
This is a tricky one. It works like this, if your classloader needs a class which it can find in and of its self (well-done) but that class needs another class which it can only find at the parent level, and the Parent class needs another class which can be found at the child level then you will have an error saying that the application cannot find a class (ClassNotFoundException), which by just checking your child application jars you know is available! The problem in this case is that if a class is loaded by a classloader, it can't call a class that's loaded by a classloader that's lower in the hierarchy. This is hair raising to put it mildly, I mean looking for something you can find is just………………………WebSpherish! Anyway without trying to be an expert (which I am not!) just take the jar and put at the parent class level then thank me later if it works, if not…………….. I guess you have a blog to write!

OK these 4 points should help you some way, if you find more points, update us all by putting a comment, writing a blog, sending me a mail or just show me the money!