As a follow up to my whirlwind journey into the world of WebSphere and Java and civil service work, (don’t ask me which one) I will like, in this blog, to answer one simple question, how can I get a working DXA 1.7 Java on a WebSphere Application Server? I have gone to the oracle called google and sought the favour of the 'gods' named bing and none could help me. Even in TREX the best I got was this. For anyone who does not know, I have what you may call a recent relationship with WebSphere and Java. This relationship is one sided. The Java world wants me, my brain says this is sensible for your job, my heart says ……… "meh"! Anyway I digress, so I needed to get DXA 1.7 running on WebSphere, considering that I had already done it in a relatively straight forward manner on Tomcat, when I was asked to make it happen, I willingly took the bait, WebSphere made it a debate! (Heheee relax and enjoy the read!).
To start with I am hopeful that if you are on this page either to broaden your knowledge in general or to apply this particular knowledge then you do know how to build a DXA 1.7 Java Web Application, cos I aint helping you with that!  But if you need help read up here:

https://docs.sdl.com/LiveContent/content/en-US/SDL%20DXA-v7/GUID-D189EAD3-F5BB-4AE6-85BA-AC9C59EAA891

Now that we have gotten the difficult part out of the way, follow the next steps and make your default dxa website come alive, churning on the fire power of the ever indefatigable WebSphere.

1. Install Web Application on WebSphere
    If you don’t know how to do this already, please answer the following question honestly: Why am I using WebSphere? If the answer has to do with you and is not contrived by external forces (employers, bosses, management, customers or people who buy things and have no idea what or why it is - You can easily pick 2 of the above options) then please change your mind now!
    Are you still here? Damn! Well I tried. Ok I will help you further by not telling you how to do this, there is this personal assistant called google…….. Use it!
    Just to be nice, you can use default properties in the installation phase, nothing will break………
    
2. Change Class loading Policy
    …………… you really thought nothing will break (Heeeheee). Of course your application did not start, of course you are having errors in your websphere log files, of course you don’t yet know why! Well, Here I come to the rescue: Change the class loading policy to Parent_Last. I explained the why in my last blog here:

https://community.sdl.com/product-groups/sdl-tridion-dx/tridion-sites/tridion-developer/b/weblog/posts/getting-web8-5-in-process-api-web-applications-running-on-websphere-8-5-to-work
    You should read it up if you really are going to be mixing Tridion (we can call the object by its name) with WebSphere. For those of you who just want a quick fix, I will c opy and paste the steps to change class loading:
    
    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.
    
3. Get rid of unfriendly Jars
    I would have you know that figuring out what jars should go and which should remain was the toughest part of setting this up. If there is a reason why I should be paid for this blog, it has to be for figuring this one out. I wont go into the details but you will have more than enough reasons (errors and warnings) to throw out some jars that you need which may keep you confused. The real issue here is DXA is bloated with so many unnecessary jar files. WebSphere somewhat does not like guests as it easily gets confused on who is guest and who is host.
    The screenshot (apologies, its not extremely clear) shows jars in blue and red on the right hand side. No, you guessed wrong, it’s the blue ones you should remove. Get rid of those and you are almost there! Infact your application should start leaving only one error when you try to call a page. Something to the effect of
    
    Error 404: SRVE0190E: File not found: {0}.   

4. Set up DXA Properties
    In your web application find the dxa.properties config file which should be in the \WEB-INF\classes. I honestly don’t remember what I added, though I remember some of these entries were missing,  but this is what it looks like at the end:
    
            dxa.web.adf.enabled=true
            spring.profiles.active=search.solr,adf.context.provider
            dxa.modules.cid.mapping=/cid/*
            dxa.modules.cid.className=com.sdl.delivery.image.filter.ContextualImageFilter
            dxa.tridion.navigation.modelUrl=/navigation.json
            dxa.context.deviceFamilies.file=device-families.xml
    
    With the settings above DXA should start working fine.

If this has helped you or you have some corrections or updates, make a comment, contact me, or just like this story............ oops I mean blog post!