You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsrp4j-dev@portals.apache.org by "Ricky Frost (JIRA)" <ws...@ws.apache.org> on 2004/11/12 18:14:23 UTC

[jira] Created: (WSRP4J-39) The pluto PortletInvokerImpl assumes there is always a valid UserContext available

The pluto PortletInvokerImpl assumes there is always a valid UserContext available
----------------------------------------------------------------------------------

         Key: WSRP4J-39
         URL: http://nagoya.apache.org/jira/browse/WSRP4J-39
     Project: WSRP4J
        Type: Bug
  Components: Producer  
    Versions: current (nightly)    
 Environment: Tomcat 4.1.30, Win XP, etc.
    Reporter: Ricky Frost


Whenever I use a portal that supports using portlets without logging in first I get a NullPointerException in the PortletInvokerImpl when it tries to get the remoteUser variable from the incoming request. The request has:

   <userContext xsi:nil="true" />

and so the getUserContext returns null.

The simple fix is to null protect the check in BOTH the markup and blocking action calls as in the following before and after:

// before
String remoteUser = request.getUserContext().getUserContextKey();

// after
String remoteUser = "";
UserContext userCtx = request.getUserContext();
if( userCtx != null )
    remoteUser = userCtx.getUserContextKey();


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


[jira] Commented: (WSRP4J-39) The pluto PortletInvokerImpl assumes there is always a valid UserContext available

Posted by "Ricky Frost (JIRA)" <ws...@ws.apache.org>.
     [ http://issues.apache.org/jira/browse/WSRP4J-39?page=comments#action_64420 ]
     
Ricky Frost commented on WSRP4J-39:
-----------------------------------

You're absolutely right Julie.
The code has changed since I pulled it back in June 2004 to put it in the PeopleSoft portal.

I just pulled the current CVS files and it's not in there! The file I checked was:
....\ws-wsrp4j\src\org\apache\wsrp4j\producer\provider\pluto\driver\PortletInvokerImpl.java

My version of the file has it where line 120 is in the current file... Right in between the following lines:

        Locale usedLocale = LocaleHelper.getLocale(request.getMarkupParams().getLocales()[0]);
<<-------- right here
        StoredResponse servletResponse = new StoredResponse();

My version picks up both the userAgent and the remoteUser (from the _getMarkup request fields) and passes them into the WSRPServletRequestWrapperImpl constructor call on line 132 between the usedLocale, and the markupTypes...

Weird... But my followup question is: if the userAgent and remoteUser aren't passed along here, how are they being propogated from the incoming _getMarkup request? Seems like an even bigger problem...

Thanks so much for following up on this.

> The pluto PortletInvokerImpl assumes there is always a valid UserContext available
> ----------------------------------------------------------------------------------
>
>          Key: WSRP4J-39
>          URL: http://issues.apache.org/jira/browse/WSRP4J-39
>      Project: WSRP4J
>         Type: Bug
>   Components: Producer
>     Versions: current (nightly)
>  Environment: Tomcat 4.1.30, Win XP, etc.
>     Reporter: Ricky Frost

>
> Whenever I use a portal that supports using portlets without logging in first I get a NullPointerException in the PortletInvokerImpl when it tries to get the remoteUser variable from the incoming request. The request has:
>    <userContext xsi:nil="true" />
> and so the getUserContext returns null.
> The simple fix is to null protect the check in BOTH the markup and blocking action calls as in the following before and after:
> // before
> String remoteUser = request.getUserContext().getUserContextKey();
> // after
> String remoteUser = "";
> UserContext userCtx = request.getUserContext();
> if( userCtx != null )
>     remoteUser = userCtx.getUserContextKey();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


[jira] Resolved: (WSRP4J-39) The pluto PortletInvokerImpl assumes there is always a valid UserContext available

Posted by "Julie MacNaught (JIRA)" <ws...@ws.apache.org>.
     [ http://issues.apache.org/jira/browse/WSRP4J-39?page=all ]
     
Julie MacNaught resolved WSRP4J-39:
-----------------------------------

    Resolution: Invalid

> The pluto PortletInvokerImpl assumes there is always a valid UserContext available
> ----------------------------------------------------------------------------------
>
>          Key: WSRP4J-39
>          URL: http://issues.apache.org/jira/browse/WSRP4J-39
>      Project: WSRP4J
>         Type: Bug
>   Components: Producer
>     Versions: current (nightly)
>  Environment: Tomcat 4.1.30, Win XP, etc.
>     Reporter: Ricky Frost

>
> Whenever I use a portal that supports using portlets without logging in first I get a NullPointerException in the PortletInvokerImpl when it tries to get the remoteUser variable from the incoming request. The request has:
>    <userContext xsi:nil="true" />
> and so the getUserContext returns null.
> The simple fix is to null protect the check in BOTH the markup and blocking action calls as in the following before and after:
> // before
> String remoteUser = request.getUserContext().getUserContextKey();
> // after
> String remoteUser = "";
> UserContext userCtx = request.getUserContext();
> if( userCtx != null )
>     remoteUser = userCtx.getUserContextKey();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


[jira] Commented: (WSRP4J-39) The pluto PortletInvokerImpl assumes there is always a valid UserContext available

Posted by "Ricky Frost (JIRA)" <ws...@ws.apache.org>.
     [ http://issues.apache.org/jira/browse/WSRP4J-39?page=comments#action_62907 ]
     
Ricky Frost commented on WSRP4J-39:
-----------------------------------

Julie,
Thanks for following up on this. I've been on vacation till today.

Both the invokeGetMarkup and invokePerformBlockingInteraction in
org.apache.wsrp4j.producer.provider.pluto.driver.PortletInvokerImpl need this change...

> The pluto PortletInvokerImpl assumes there is always a valid UserContext available
> ----------------------------------------------------------------------------------
>
>          Key: WSRP4J-39
>          URL: http://issues.apache.org/jira/browse/WSRP4J-39
>      Project: WSRP4J
>         Type: Bug
>   Components: Producer
>     Versions: current (nightly)
>  Environment: Tomcat 4.1.30, Win XP, etc.
>     Reporter: Ricky Frost

>
> Whenever I use a portal that supports using portlets without logging in first I get a NullPointerException in the PortletInvokerImpl when it tries to get the remoteUser variable from the incoming request. The request has:
>    <userContext xsi:nil="true" />
> and so the getUserContext returns null.
> The simple fix is to null protect the check in BOTH the markup and blocking action calls as in the following before and after:
> // before
> String remoteUser = request.getUserContext().getUserContextKey();
> // after
> String remoteUser = "";
> UserContext userCtx = request.getUserContext();
> if( userCtx != null )
>     remoteUser = userCtx.getUserContextKey();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


[jira] Commented: (WSRP4J-39) The pluto PortletInvokerImpl assumes there is always a valid UserContext available

Posted by "Julie MacNaught (JIRA)" <ws...@ws.apache.org>.
     [ http://issues.apache.org/jira/browse/WSRP4J-39?page=comments#action_62593 ]
     
Julie MacNaught commented on WSRP4J-39:
---------------------------------------

I can't find this code.  Please tell me exactly the package and file name of the code that needs to be changed. Thanks!

> The pluto PortletInvokerImpl assumes there is always a valid UserContext available
> ----------------------------------------------------------------------------------
>
>          Key: WSRP4J-39
>          URL: http://issues.apache.org/jira/browse/WSRP4J-39
>      Project: WSRP4J
>         Type: Bug
>   Components: Producer
>     Versions: current (nightly)
>  Environment: Tomcat 4.1.30, Win XP, etc.
>     Reporter: Ricky Frost

>
> Whenever I use a portal that supports using portlets without logging in first I get a NullPointerException in the PortletInvokerImpl when it tries to get the remoteUser variable from the incoming request. The request has:
>    <userContext xsi:nil="true" />
> and so the getUserContext returns null.
> The simple fix is to null protect the check in BOTH the markup and blocking action calls as in the following before and after:
> // before
> String remoteUser = request.getUserContext().getUserContextKey();
> // after
> String remoteUser = "";
> UserContext userCtx = request.getUserContext();
> if( userCtx != null )
>     remoteUser = userCtx.getUserContextKey();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


[jira] Closed: (WSRP4J-39) The pluto PortletInvokerImpl assumes there is always a valid UserContext available

Posted by "Julie MacNaught (JIRA)" <ws...@ws.apache.org>.
     [ http://issues.apache.org/jira/browse/WSRP4J-39?page=all ]
     
Julie MacNaught closed WSRP4J-39:
---------------------------------


> The pluto PortletInvokerImpl assumes there is always a valid UserContext available
> ----------------------------------------------------------------------------------
>
>          Key: WSRP4J-39
>          URL: http://issues.apache.org/jira/browse/WSRP4J-39
>      Project: WSRP4J
>         Type: Bug
>   Components: Producer
>     Versions: current (nightly)
>  Environment: Tomcat 4.1.30, Win XP, etc.
>     Reporter: Ricky Frost

>
> Whenever I use a portal that supports using portlets without logging in first I get a NullPointerException in the PortletInvokerImpl when it tries to get the remoteUser variable from the incoming request. The request has:
>    <userContext xsi:nil="true" />
> and so the getUserContext returns null.
> The simple fix is to null protect the check in BOTH the markup and blocking action calls as in the following before and after:
> // before
> String remoteUser = request.getUserContext().getUserContextKey();
> // after
> String remoteUser = "";
> UserContext userCtx = request.getUserContext();
> if( userCtx != null )
>     remoteUser = userCtx.getUserContextKey();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


[jira] Commented: (WSRP4J-39) The pluto PortletInvokerImpl assumes there is always a valid UserContext available

Posted by "Julie MacNaught (JIRA)" <ws...@ws.apache.org>.
     [ http://issues.apache.org/jira/browse/WSRP4J-39?page=comments#action_64393 ]
     
Julie MacNaught commented on WSRP4J-39:
---------------------------------------

I have looked in the file you mentioned, but there is no code matching the change you suggest.  I have searched every file in wsrp4j for the string "remoteUser" and found zilch.  Searching for getUserContextKey turns up references in ParameterChecker, URLComposerImpl, and UserContext.

I even looked back at the comments for previous versions of the file and I don't see any changes that would suggest you have an old version.

There is some similar code on the consumer side in PortletDriverImpl (org.apache.wsrp4j.consumer.driver.PortletDriverImpl , but everything looks ok.  Oddly, there is a comment in this file:
        // workaround for Oracle bug, always send a userContext with dummy value
        // if none was provided
        
        if (userContext == null) {
        	userContext = new UserContext();
        	userContext.setUserContextKey("dummyUserContextKey");
        }


So I'm still stumped.

> The pluto PortletInvokerImpl assumes there is always a valid UserContext available
> ----------------------------------------------------------------------------------
>
>          Key: WSRP4J-39
>          URL: http://issues.apache.org/jira/browse/WSRP4J-39
>      Project: WSRP4J
>         Type: Bug
>   Components: Producer
>     Versions: current (nightly)
>  Environment: Tomcat 4.1.30, Win XP, etc.
>     Reporter: Ricky Frost

>
> Whenever I use a portal that supports using portlets without logging in first I get a NullPointerException in the PortletInvokerImpl when it tries to get the remoteUser variable from the incoming request. The request has:
>    <userContext xsi:nil="true" />
> and so the getUserContext returns null.
> The simple fix is to null protect the check in BOTH the markup and blocking action calls as in the following before and after:
> // before
> String remoteUser = request.getUserContext().getUserContextKey();
> // after
> String remoteUser = "";
> UserContext userCtx = request.getUserContext();
> if( userCtx != null )
>     remoteUser = userCtx.getUserContextKey();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira