2016-10-20 3 views
0

Wir verwenden WebSphere Portal Version 7. In unseren Themen haben wir ein Flyout-Menü in der Kopfzeile. Die Links im Flyout-Menü hängen vom Typ des Benutzers ab, der auf die Anwendung zugreift. Die Links werden gerendert die Portal-Navigation-Tags -URLGeneration-Fehler in WebSphere Portal

<portal:urlGeneration contentNode="com.XXXXX.member.XX.XXX123" keepNavigationalState="false"> 

Der Zugang zum contentNode wird auf Sichtbarkeitsregeln. Für Benutzer, die keinen Zugriff auf einen bestimmten Inhaltsknoten haben, ist die Verknüpfung nicht sichtbar.

Da sich das Flyout-Menü im Themenkopf befindet, löst der Portalnavigationspfad immer dann URLGenerationsfehler aus, wenn ein angemeldeter Benutzer keinen Zugriff auf einen bestimmten Link im Menü hat, was zu NullPointer-Ausnahmen führt. Diese Fehler werden in unseren SysOut eingeloggt. Die Fehlerhäufigkeit wird so hoch, dass die Logs zurückrollen und für das Server-Team schwer werden, sie zu warten.

Da dies ein WebSphere Portal Problem gibt es eine Lösung für sie in Portal 8 ab und nicht in Portal zur Verfügung 7.

Wir möchten wissen, ob es einen Weg geben, könnte der applicatoin anmutig die URLGeneration Fehler umgehen konnte und hör auf, unsere Protokolle zu füllen. Wir möchten nicht, dass in unseren Themes dieselben Sichtbarkeitsregel-Checks implementiert werden, denn dann würden wir den gesamten Zweck der Portalnavigation verlieren und auch wenn Business Rules sich ändern, wäre dies ein weiterer zu ändernder Add-On-Punkt.

Möchte einige Eingaben hören. Danke.

PS - PFB Fehlerprotokoll-Stack-Trace -

[10/13/16 17:03:16:097 EDT] 00000052 CreateUrlComm E com.ibm.wps.util.CreateUrlCommand execute EJPEJ0012E: Could not find the node ID and root ID corresponding to the given content node ID. 
[10/13/16 17:03:16:099 EDT] 00000052 UrlGeneration E com.ibm.wps.engine.tags.UrlGenerationTag doStartTag EJPEJ0004E: An unexpected exception occurred. 
           java.lang.NullPointerException 
    at com.ibm.wps.util.CreateUrlCommand.createFriendlyURL(CreateUrlCommand.java:809) 
    at com.ibm.wps.engine.tags.UrlGenerationTag.doStartTag(UrlGenerationTag.java:344) 
    at com.ibm._jsp._header._jspService(_header.java:1678) 
    at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:99) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) 
    at com.ibm.ws.cache.servlet.ServletWrapper.serviceProxied(ServletWrapper.java:307) 
    at com.ibm.ws.cache.servlet.CacheHook.handleFragment(CacheHook.java:576) 
    at com.ibm.ws.cache.servlet.CacheHook.handleServlet(CacheHook.java:250) 
    at com.ibm.ws.cache.servlet.ServletWrapper.service(ServletWrapper.java:259) 
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1694) 
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:970) 
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:508) 

Antwort

1

Sie können es sagen zu ignorieren, sei es fatal nur oder deaktivieren https://www.ibm.com/support/knowledgecenter/SSEQTP_7.0.0/com.ibm.websphere.nd.doc/info/ae/ae/rtrb_enabletrc.html

com.ibm.wps.engine.tags.UrlGenerationTag = off

oder Sie könnten die Ausnahmebehandlung rund um die jsp setzen, um es

+1

der Logger Namen 'off' in diesem Fall einzustellen besser handhaben ist' com.i bm.wps.engine.tags.UrlGenerationTag' - es ist das Abfangen der Ausnahme von 'CreateUrlCommand' und das Protokollieren der unerwünschten EJPEJ0004E-Nachricht. –

+0

Ja, Sie haben Recht, versucht zu antworten – Crosstalk22

+0

Das Ausschalten der Logger ist die letzte Option, die wir versuchten zu erkunden, aber die meisten Optionen waren nur in Portal 8 verfügbar. Wir versuchten Ausnahmebehandlung am Jsp, aber es scheint wie die geworfenen Null Pointer Exception fließt bis zum JSP, daher können die try catch-Blöcke sie nicht fangen. Wir werden es noch einmal versuchen, bevor wir den Logger endlich ausschalten. –

Verwandte Themen