OK I will split my answer in 2 parts, here I will answer about the PortalContainerFilter and in the second thread I will give more details about why we allow to disable a portal container
If I understand you right, you have gatein.ear and another ear file that defines your target portal container called "myPalContainer" and you defined only this new portal container in PortalContainerConfig which implicitly disables the portal container "portal" (that will try to register itslef from the portal.war of gatein.ear) so in your case this filter is required in gatein.ear otherwise as /portal is still accessible, any access to /portal will cause this kind of issues https://issues.jboss.org/browse/GTNPORTAL-1345. In your custom ear you are free to remove it without any risk as you know that you don't need to disable it and more important it is a change in your ear file not in gatein.ear that cannot be modified if you need to be covered by the support.
roughly, I want to configure the portal cleanly...
without a portal container /portal if it is not used.
and without a filter initialized and run, on each http request,... if not useful.
if this is possible...
for the perfs, it is not significant compare to the huge process of the portal page + applications running.
but many "not significant" things consume some CPU, some memory, and garbage collection.
the more I avoid the waste, the better.
the global idea is : clean, no waste, ... and good knowledge of the portal mechanisms and running.
by the way : I don't have only "one portal I want to do...", but help companies setting and running their portal.
I see many questions about "how to..." and "why... ?".
it is difficult to explain to some architects, or dev team, that you have to keep the "/portal" container... but it is not used.
anyway, all this is for fine tuning : it does not prevent to use the portal, and take advantage of the huge amount of features and code available with this product.
Thanks for the answers,