在WebWork/Struts 2的應用框架中，可以讓系統開發者在寫程式時，專注在應用系統的邏輯，透過IoC的注入(injection)方式，程式碼中可以完全看不到與JavaEE相關的程式碼。但是這種美好的世界，在遇到一些需要根據使用者傳回不同的結果的action時，就不是那麼美好，除非你所開發的應用系統自行處理使用者權限與授權相關的功能。如果是使用JAAS，那程式中不免會需要透過HttpRequest來取得remoteUser等資訊。在Struts2/WebWork中，提供了兩個介面可以做到這樣的功能 HttpRequestAware 與 PrincipalAware。
HttpRequestAware 是第一個會想到的介面，既然remoteUser的資料是從request來的，那就叫struts幫我們注入個request object不就成了？但是一但在action中引入HttpRequest，使用Struts2/Webwork的最大好處，與平台低相依性，易測試的優點就當場被破壞了。當引入HttpRequest之後，為了測試action，必需透過如spring-mock等等的JavaEE mock 套件，無法簡單的透過如jmock, 或是自行打造stub的方式來進行測試，而且，只是需要getRemoteUser, isUserInRole等function，卻把整個HttpRequest 都暴露在action中，怎麼看味道也不對。
PrincipalAware 就是為了解決上述的問題產生的，如果你只是很單存的需要getRemoteUser, isSecured, getPrincipal, isUserInRole等功能，那action只需要實作PrincipalAware，Struts2/WebWork會為action注入一個PrincipalProxy，提供getRemoteUser等需要的方法，又不需要將整個HttpRequest都暴露在action中，造成與平台過度的相依。更好的是，PrincipalProxy是一個interface，可以利用jmock, dynaMock等mock framework簡單的產生測試時需要的替代品，對自動測試可是一大利多。
使用WebWork到現在，也好幾年了，居然到現在才發現有這個interface，該說是後知後覺，還是太不認真了，不過，這個介面可是解決了以往為了測試這些需要principal 的action，而搞了幾乎整套的JavaEE stack的問題，又能夠滿足整個應用系統的味道能夠一致，真該認真點的。
