You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Marc Veary <nw...@googlemail.com> on 2007/07/02 09:39:46 UTC
DefaultUserInfoService
Hi All,
Just got the HEAD from SVN and was checking over the changes as I try
to keep this in sync with the code I am using. I noticed the
following does not seem to be correct:
public Map getUserInfo(PortletRequest request)
throws PortletContainerException {
if ( request.getRemoteUser() != null ) {
Map info = (Map)userInfoMap.get(request.getRemoteUser());
if ( info == null ) {
return Collections.EMPTY_MAP;
}
}
return new HashMap();
}
This ALWAYS returns an EMPTY MAP? Whereas the previous version
returned the userInfoMap from the request. I think the attempt was to
return an empty map if the 'info' was null?
Kind regards,
--
Marc
Re: DefaultUserInfoService
Posted by Elliot Metsger <em...@jhu.edu>.
Marc Veary wrote:
> The portal is not yet released - when it is I'll let you know and the
> site can be added.
Great!
>
> I assume you are US based?
>
Yep, a lot of us are but not everyone -
> Thanks for the discussion - hope to chat again soon.
No problem,
Best
Elliot
>
> Kind regards
>
> On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>>
>>
>> Marc Veary wrote:
>> > Okay, I would like to contribute something back to the project as I
>> > use the code in a portal.
>>
>> Great! Should it be listed here?
>> http://portals.apache.org/pluto/powered.html
>>
>> >
>> > What I'll do is submit patches containing one or two classes at a time
>> > - I like the little-and-often paradigm ;-)
>>
>> Sounds good!
>>
>> Thanks again,
>>
>> Elliot
>>
>> >
>> > Kind regards,
>> > --
>> > Marc
>> >
>> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >>
>> >>
>> >> Marc Veary wrote:
>> >> > Excellent!
>> >> >
>> >> > I have been going through the trunk over the past 4-6 months
>> >> > converting the obvious, doing a code tidying and amending javadocs
>> >> > where necessary (this is not meant to be rude to other developers or
>> >> > imply anything bad) - I simply started to do this as I wanted to
>> >> > understand what the code was doing and found the learning curve
>> steep.
>> >> > I can submit some of these changes if it would be helpful?
>> >>
>> >> Absolutely!
>> >>
>> >> The best thing to do is to open a Jira issue and then submit
>> patches on
>> >> that issue.
>> >>
>> >> I don't know exactly what a good sized patch would be (or even if that
>> >> is an issue). I don't think we'd want one big mega patch, but maybe
>> >> patches scoped to a group of related packages (e.g.
>> >> org.apache.pluto.core.*). It just makes it a little easier to review
>> >> and apply.
>> >>
>> >> Others please chime in if you disagree -
>> >>
>> >> How does this sound?
>> >>
>> >> Elliot
>> >>
>> >> >
>> >> > I now check all revisions committed to the trunk as I reflect these
>> >> > changes (if the change required) in the code I compile and use.
>> >> >
>> >> > Kind regards,
>> >> > --
>> >> > Marc
>> >> >
>> >> >
>> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >> >> Marc,
>> >> >>
>> >> >> I hear you on finals - we just haven't been using them
>> throughout the
>> >> >> codebase, though that is something we could change.
>> >> >>
>> >> >> Trunk does require Java 1.5, so yes, developers are able to use 1.5
>> >> >> features. However, the 1.1.x branch needs to maintain 1.4 compat.
>> >> >>
>> >> >> Since a lot of patches are being applied to both the 1.1.x
>> branch and
>> >> >> the trunk, the code in trunk hasn't really begun to take
>> advantage of
>> >> >> 1.5 features. However, before 1.2.0 (trunk) is released, we do
>> >> plan to
>> >> >> convert to generics, at least for many of the interfaces.
>> >> >>
>> >> >> Sound good?
>> >> >>
>> >> >> Thanks,
>> >> >> Elliot
>> >> >>
>> >> >> Marc Veary wrote:
>> >> >> > You can leave out the finals - is there an issue with using
>> >> finals? I
>> >> >> > use them all the time - you would be surprised at the issues it
>> >> >> > prevents.
>> >> >> >
>> >> >> > Also the annotations, please omit them - I do not mind in the
>> least.
>> >> >> >
>> >> >> > Are you converting the loops to the newer format?
>> >> >> >
>> >> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >> >> >> Nope,
>> >> >> >>
>> >> >> >> Not forward at all.
>> >> >> >>
>> >> >> >> Can I leave out the 'final's or do you want them for some
>> >> reason? We
>> >> >> >> also haven't been putting in the Java 5 annotations.
>> >> >> >>
>> >> >> >> What do you think?
>> >> >> >>
>> >> >> >> Elliot
>> >> >> >>
>> >> >> >> Marc Veary wrote:
>> >> >> >> > Cool.
>> >> >> >> >
>> >> >> >> > Can I submit this:
>> >> >> >> >
>> >> >> >> > @SuppressWarnings("unchecked")
>> >> >> >> > public Map getUserInfo( final PortletRequest request )
>> throws
>> >> >> >> > PortletContainerException
>> >> >> >> > {
>> >> >> >> > final String remoteUser = request.getRemoteUser();
>> >> >> >> > if( remoteUser != null )
>> >> >> >> > {
>> >> >> >> > final Map info = (Map)this.userInfoMap.get(
>> >> remoteUser );
>> >> >> >> > if( info == null )
>> >> >> >> > {
>> >> >> >> > return Collections.EMPTY_MAP;
>> >> >> >> > }
>> >> >> >> > return info;
>> >> >> >> > }
>> >> >> >> > return Collections.EMPTY_MAP;
>> >> >> >> > }
>> >> >> >> >
>> >> >> >> > I hope this is not too forward of me.
>> >> >> >> >
>> >> >> >> > Keep up the good work!
>> >> >> >> >
>> >> >> >> > Kind regards,
>> >> >> >> > --
>> >> >> >> > Marc
>> >> >> >> >
>> >> >> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >> >> >> >> Good catch Marc,
>> >> >> >> >>
>> >> >> >> >> Not enough sleep and too much coffee on my part. :-)
>> >> >> >> >>
>> >> >> >> >> Fixed r552420, 552421.
>> >> >> >> >>
>> >> >> >> >> Thanks!
>> >> >> >> >> Elliot
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Marc Veary wrote:
>> >> >> >> >> > Hi All,
>> >> >> >> >> > Just got the HEAD from SVN and was checking over the
>> >> changes as I
>> >> >> >> try
>> >> >> >> >> > to keep this in sync with the code I am using. I
>> noticed the
>> >> >> >> >> > following does not seem to be correct:
>> >> >> >> >> >
>> >> >> >> >> > public Map getUserInfo(PortletRequest request)
>> >> >> >> >> > throws PortletContainerException {
>> >> >> >> >> > if ( request.getRemoteUser() != null ) {
>> >> >> >> >> > Map info =
>> >> >> (Map)userInfoMap.get(request.getRemoteUser());
>> >> >> >> >> > if ( info == null ) {
>> >> >> >> >> > return Collections.EMPTY_MAP;
>> >> >> >> >> > }
>> >> >> >> >> > }
>> >> >> >> >> > return new HashMap();
>> >> >> >> >> > }
>> >> >> >> >> >
>> >> >> >> >> > This ALWAYS returns an EMPTY MAP? Whereas the previous
>> >> version
>> >> >> >> >> > returned the userInfoMap from the request. I think the
>> >> attempt
>> >> >> >> was to
>> >> >> >> >> > return an empty map if the 'info' was null?
>> >> >> >> >> >
>> >> >> >> >> > Kind regards,
>> >> >> >> >> > --
>> >> >> >> >> > Marc
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>
Re: DefaultUserInfoService
Posted by Marc Veary <nw...@googlemail.com>.
The portal is not yet released - when it is I'll let you know and the
site can be added.
I assume you are US based?
Thanks for the discussion - hope to chat again soon.
Kind regards
On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>
>
> Marc Veary wrote:
> > Okay, I would like to contribute something back to the project as I
> > use the code in a portal.
>
> Great! Should it be listed here?
> http://portals.apache.org/pluto/powered.html
>
> >
> > What I'll do is submit patches containing one or two classes at a time
> > - I like the little-and-often paradigm ;-)
>
> Sounds good!
>
> Thanks again,
>
> Elliot
>
> >
> > Kind regards,
> > --
> > Marc
> >
> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >>
> >>
> >> Marc Veary wrote:
> >> > Excellent!
> >> >
> >> > I have been going through the trunk over the past 4-6 months
> >> > converting the obvious, doing a code tidying and amending javadocs
> >> > where necessary (this is not meant to be rude to other developers or
> >> > imply anything bad) - I simply started to do this as I wanted to
> >> > understand what the code was doing and found the learning curve steep.
> >> > I can submit some of these changes if it would be helpful?
> >>
> >> Absolutely!
> >>
> >> The best thing to do is to open a Jira issue and then submit patches on
> >> that issue.
> >>
> >> I don't know exactly what a good sized patch would be (or even if that
> >> is an issue). I don't think we'd want one big mega patch, but maybe
> >> patches scoped to a group of related packages (e.g.
> >> org.apache.pluto.core.*). It just makes it a little easier to review
> >> and apply.
> >>
> >> Others please chime in if you disagree -
> >>
> >> How does this sound?
> >>
> >> Elliot
> >>
> >> >
> >> > I now check all revisions committed to the trunk as I reflect these
> >> > changes (if the change required) in the code I compile and use.
> >> >
> >> > Kind regards,
> >> > --
> >> > Marc
> >> >
> >> >
> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >> >> Marc,
> >> >>
> >> >> I hear you on finals - we just haven't been using them throughout the
> >> >> codebase, though that is something we could change.
> >> >>
> >> >> Trunk does require Java 1.5, so yes, developers are able to use 1.5
> >> >> features. However, the 1.1.x branch needs to maintain 1.4 compat.
> >> >>
> >> >> Since a lot of patches are being applied to both the 1.1.x branch and
> >> >> the trunk, the code in trunk hasn't really begun to take advantage of
> >> >> 1.5 features. However, before 1.2.0 (trunk) is released, we do
> >> plan to
> >> >> convert to generics, at least for many of the interfaces.
> >> >>
> >> >> Sound good?
> >> >>
> >> >> Thanks,
> >> >> Elliot
> >> >>
> >> >> Marc Veary wrote:
> >> >> > You can leave out the finals - is there an issue with using
> >> finals? I
> >> >> > use them all the time - you would be surprised at the issues it
> >> >> > prevents.
> >> >> >
> >> >> > Also the annotations, please omit them - I do not mind in the least.
> >> >> >
> >> >> > Are you converting the loops to the newer format?
> >> >> >
> >> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >> >> >> Nope,
> >> >> >>
> >> >> >> Not forward at all.
> >> >> >>
> >> >> >> Can I leave out the 'final's or do you want them for some
> >> reason? We
> >> >> >> also haven't been putting in the Java 5 annotations.
> >> >> >>
> >> >> >> What do you think?
> >> >> >>
> >> >> >> Elliot
> >> >> >>
> >> >> >> Marc Veary wrote:
> >> >> >> > Cool.
> >> >> >> >
> >> >> >> > Can I submit this:
> >> >> >> >
> >> >> >> > @SuppressWarnings("unchecked")
> >> >> >> > public Map getUserInfo( final PortletRequest request ) throws
> >> >> >> > PortletContainerException
> >> >> >> > {
> >> >> >> > final String remoteUser = request.getRemoteUser();
> >> >> >> > if( remoteUser != null )
> >> >> >> > {
> >> >> >> > final Map info = (Map)this.userInfoMap.get(
> >> remoteUser );
> >> >> >> > if( info == null )
> >> >> >> > {
> >> >> >> > return Collections.EMPTY_MAP;
> >> >> >> > }
> >> >> >> > return info;
> >> >> >> > }
> >> >> >> > return Collections.EMPTY_MAP;
> >> >> >> > }
> >> >> >> >
> >> >> >> > I hope this is not too forward of me.
> >> >> >> >
> >> >> >> > Keep up the good work!
> >> >> >> >
> >> >> >> > Kind regards,
> >> >> >> > --
> >> >> >> > Marc
> >> >> >> >
> >> >> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >> >> >> >> Good catch Marc,
> >> >> >> >>
> >> >> >> >> Not enough sleep and too much coffee on my part. :-)
> >> >> >> >>
> >> >> >> >> Fixed r552420, 552421.
> >> >> >> >>
> >> >> >> >> Thanks!
> >> >> >> >> Elliot
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Marc Veary wrote:
> >> >> >> >> > Hi All,
> >> >> >> >> > Just got the HEAD from SVN and was checking over the
> >> changes as I
> >> >> >> try
> >> >> >> >> > to keep this in sync with the code I am using. I noticed the
> >> >> >> >> > following does not seem to be correct:
> >> >> >> >> >
> >> >> >> >> > public Map getUserInfo(PortletRequest request)
> >> >> >> >> > throws PortletContainerException {
> >> >> >> >> > if ( request.getRemoteUser() != null ) {
> >> >> >> >> > Map info =
> >> >> (Map)userInfoMap.get(request.getRemoteUser());
> >> >> >> >> > if ( info == null ) {
> >> >> >> >> > return Collections.EMPTY_MAP;
> >> >> >> >> > }
> >> >> >> >> > }
> >> >> >> >> > return new HashMap();
> >> >> >> >> > }
> >> >> >> >> >
> >> >> >> >> > This ALWAYS returns an EMPTY MAP? Whereas the previous
> >> version
> >> >> >> >> > returned the userInfoMap from the request. I think the
> >> attempt
> >> >> >> was to
> >> >> >> >> > return an empty map if the 'info' was null?
> >> >> >> >> >
> >> >> >> >> > Kind regards,
> >> >> >> >> > --
> >> >> >> >> > Marc
> >> >> >> >>
> >> >> >>
> >> >>
> >>
>
Re: DefaultUserInfoService
Posted by Elliot Metsger <em...@jhu.edu>.
Marc Veary wrote:
> Okay, I would like to contribute something back to the project as I
> use the code in a portal.
Great! Should it be listed here?
http://portals.apache.org/pluto/powered.html
>
> What I'll do is submit patches containing one or two classes at a time
> - I like the little-and-often paradigm ;-)
Sounds good!
Thanks again,
Elliot
>
> Kind regards,
> --
> Marc
>
> On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>>
>>
>> Marc Veary wrote:
>> > Excellent!
>> >
>> > I have been going through the trunk over the past 4-6 months
>> > converting the obvious, doing a code tidying and amending javadocs
>> > where necessary (this is not meant to be rude to other developers or
>> > imply anything bad) - I simply started to do this as I wanted to
>> > understand what the code was doing and found the learning curve steep.
>> > I can submit some of these changes if it would be helpful?
>>
>> Absolutely!
>>
>> The best thing to do is to open a Jira issue and then submit patches on
>> that issue.
>>
>> I don't know exactly what a good sized patch would be (or even if that
>> is an issue). I don't think we'd want one big mega patch, but maybe
>> patches scoped to a group of related packages (e.g.
>> org.apache.pluto.core.*). It just makes it a little easier to review
>> and apply.
>>
>> Others please chime in if you disagree -
>>
>> How does this sound?
>>
>> Elliot
>>
>> >
>> > I now check all revisions committed to the trunk as I reflect these
>> > changes (if the change required) in the code I compile and use.
>> >
>> > Kind regards,
>> > --
>> > Marc
>> >
>> >
>> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >> Marc,
>> >>
>> >> I hear you on finals - we just haven't been using them throughout the
>> >> codebase, though that is something we could change.
>> >>
>> >> Trunk does require Java 1.5, so yes, developers are able to use 1.5
>> >> features. However, the 1.1.x branch needs to maintain 1.4 compat.
>> >>
>> >> Since a lot of patches are being applied to both the 1.1.x branch and
>> >> the trunk, the code in trunk hasn't really begun to take advantage of
>> >> 1.5 features. However, before 1.2.0 (trunk) is released, we do
>> plan to
>> >> convert to generics, at least for many of the interfaces.
>> >>
>> >> Sound good?
>> >>
>> >> Thanks,
>> >> Elliot
>> >>
>> >> Marc Veary wrote:
>> >> > You can leave out the finals - is there an issue with using
>> finals? I
>> >> > use them all the time - you would be surprised at the issues it
>> >> > prevents.
>> >> >
>> >> > Also the annotations, please omit them - I do not mind in the least.
>> >> >
>> >> > Are you converting the loops to the newer format?
>> >> >
>> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >> >> Nope,
>> >> >>
>> >> >> Not forward at all.
>> >> >>
>> >> >> Can I leave out the 'final's or do you want them for some
>> reason? We
>> >> >> also haven't been putting in the Java 5 annotations.
>> >> >>
>> >> >> What do you think?
>> >> >>
>> >> >> Elliot
>> >> >>
>> >> >> Marc Veary wrote:
>> >> >> > Cool.
>> >> >> >
>> >> >> > Can I submit this:
>> >> >> >
>> >> >> > @SuppressWarnings("unchecked")
>> >> >> > public Map getUserInfo( final PortletRequest request ) throws
>> >> >> > PortletContainerException
>> >> >> > {
>> >> >> > final String remoteUser = request.getRemoteUser();
>> >> >> > if( remoteUser != null )
>> >> >> > {
>> >> >> > final Map info = (Map)this.userInfoMap.get(
>> remoteUser );
>> >> >> > if( info == null )
>> >> >> > {
>> >> >> > return Collections.EMPTY_MAP;
>> >> >> > }
>> >> >> > return info;
>> >> >> > }
>> >> >> > return Collections.EMPTY_MAP;
>> >> >> > }
>> >> >> >
>> >> >> > I hope this is not too forward of me.
>> >> >> >
>> >> >> > Keep up the good work!
>> >> >> >
>> >> >> > Kind regards,
>> >> >> > --
>> >> >> > Marc
>> >> >> >
>> >> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >> >> >> Good catch Marc,
>> >> >> >>
>> >> >> >> Not enough sleep and too much coffee on my part. :-)
>> >> >> >>
>> >> >> >> Fixed r552420, 552421.
>> >> >> >>
>> >> >> >> Thanks!
>> >> >> >> Elliot
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> Marc Veary wrote:
>> >> >> >> > Hi All,
>> >> >> >> > Just got the HEAD from SVN and was checking over the
>> changes as I
>> >> >> try
>> >> >> >> > to keep this in sync with the code I am using. I noticed the
>> >> >> >> > following does not seem to be correct:
>> >> >> >> >
>> >> >> >> > public Map getUserInfo(PortletRequest request)
>> >> >> >> > throws PortletContainerException {
>> >> >> >> > if ( request.getRemoteUser() != null ) {
>> >> >> >> > Map info =
>> >> (Map)userInfoMap.get(request.getRemoteUser());
>> >> >> >> > if ( info == null ) {
>> >> >> >> > return Collections.EMPTY_MAP;
>> >> >> >> > }
>> >> >> >> > }
>> >> >> >> > return new HashMap();
>> >> >> >> > }
>> >> >> >> >
>> >> >> >> > This ALWAYS returns an EMPTY MAP? Whereas the previous
>> version
>> >> >> >> > returned the userInfoMap from the request. I think the
>> attempt
>> >> >> was to
>> >> >> >> > return an empty map if the 'info' was null?
>> >> >> >> >
>> >> >> >> > Kind regards,
>> >> >> >> > --
>> >> >> >> > Marc
>> >> >> >>
>> >> >>
>> >>
>>
Re: DefaultUserInfoService
Posted by Marc Veary <nw...@googlemail.com>.
Okay, I would like to contribute something back to the project as I
use the code in a portal.
What I'll do is submit patches containing one or two classes at a time
- I like the little-and-often paradigm ;-)
Kind regards,
--
Marc
On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>
>
> Marc Veary wrote:
> > Excellent!
> >
> > I have been going through the trunk over the past 4-6 months
> > converting the obvious, doing a code tidying and amending javadocs
> > where necessary (this is not meant to be rude to other developers or
> > imply anything bad) - I simply started to do this as I wanted to
> > understand what the code was doing and found the learning curve steep.
> > I can submit some of these changes if it would be helpful?
>
> Absolutely!
>
> The best thing to do is to open a Jira issue and then submit patches on
> that issue.
>
> I don't know exactly what a good sized patch would be (or even if that
> is an issue). I don't think we'd want one big mega patch, but maybe
> patches scoped to a group of related packages (e.g.
> org.apache.pluto.core.*). It just makes it a little easier to review
> and apply.
>
> Others please chime in if you disagree -
>
> How does this sound?
>
> Elliot
>
> >
> > I now check all revisions committed to the trunk as I reflect these
> > changes (if the change required) in the code I compile and use.
> >
> > Kind regards,
> > --
> > Marc
> >
> >
> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >> Marc,
> >>
> >> I hear you on finals - we just haven't been using them throughout the
> >> codebase, though that is something we could change.
> >>
> >> Trunk does require Java 1.5, so yes, developers are able to use 1.5
> >> features. However, the 1.1.x branch needs to maintain 1.4 compat.
> >>
> >> Since a lot of patches are being applied to both the 1.1.x branch and
> >> the trunk, the code in trunk hasn't really begun to take advantage of
> >> 1.5 features. However, before 1.2.0 (trunk) is released, we do plan to
> >> convert to generics, at least for many of the interfaces.
> >>
> >> Sound good?
> >>
> >> Thanks,
> >> Elliot
> >>
> >> Marc Veary wrote:
> >> > You can leave out the finals - is there an issue with using finals? I
> >> > use them all the time - you would be surprised at the issues it
> >> > prevents.
> >> >
> >> > Also the annotations, please omit them - I do not mind in the least.
> >> >
> >> > Are you converting the loops to the newer format?
> >> >
> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >> >> Nope,
> >> >>
> >> >> Not forward at all.
> >> >>
> >> >> Can I leave out the 'final's or do you want them for some reason? We
> >> >> also haven't been putting in the Java 5 annotations.
> >> >>
> >> >> What do you think?
> >> >>
> >> >> Elliot
> >> >>
> >> >> Marc Veary wrote:
> >> >> > Cool.
> >> >> >
> >> >> > Can I submit this:
> >> >> >
> >> >> > @SuppressWarnings("unchecked")
> >> >> > public Map getUserInfo( final PortletRequest request ) throws
> >> >> > PortletContainerException
> >> >> > {
> >> >> > final String remoteUser = request.getRemoteUser();
> >> >> > if( remoteUser != null )
> >> >> > {
> >> >> > final Map info = (Map)this.userInfoMap.get( remoteUser );
> >> >> > if( info == null )
> >> >> > {
> >> >> > return Collections.EMPTY_MAP;
> >> >> > }
> >> >> > return info;
> >> >> > }
> >> >> > return Collections.EMPTY_MAP;
> >> >> > }
> >> >> >
> >> >> > I hope this is not too forward of me.
> >> >> >
> >> >> > Keep up the good work!
> >> >> >
> >> >> > Kind regards,
> >> >> > --
> >> >> > Marc
> >> >> >
> >> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >> >> >> Good catch Marc,
> >> >> >>
> >> >> >> Not enough sleep and too much coffee on my part. :-)
> >> >> >>
> >> >> >> Fixed r552420, 552421.
> >> >> >>
> >> >> >> Thanks!
> >> >> >> Elliot
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Marc Veary wrote:
> >> >> >> > Hi All,
> >> >> >> > Just got the HEAD from SVN and was checking over the changes as I
> >> >> try
> >> >> >> > to keep this in sync with the code I am using. I noticed the
> >> >> >> > following does not seem to be correct:
> >> >> >> >
> >> >> >> > public Map getUserInfo(PortletRequest request)
> >> >> >> > throws PortletContainerException {
> >> >> >> > if ( request.getRemoteUser() != null ) {
> >> >> >> > Map info =
> >> (Map)userInfoMap.get(request.getRemoteUser());
> >> >> >> > if ( info == null ) {
> >> >> >> > return Collections.EMPTY_MAP;
> >> >> >> > }
> >> >> >> > }
> >> >> >> > return new HashMap();
> >> >> >> > }
> >> >> >> >
> >> >> >> > This ALWAYS returns an EMPTY MAP? Whereas the previous version
> >> >> >> > returned the userInfoMap from the request. I think the attempt
> >> >> was to
> >> >> >> > return an empty map if the 'info' was null?
> >> >> >> >
> >> >> >> > Kind regards,
> >> >> >> > --
> >> >> >> > Marc
> >> >> >>
> >> >>
> >>
>
Re: DefaultUserInfoService
Posted by Elliot Metsger <em...@jhu.edu>.
Marc Veary wrote:
> Excellent!
>
> I have been going through the trunk over the past 4-6 months
> converting the obvious, doing a code tidying and amending javadocs
> where necessary (this is not meant to be rude to other developers or
> imply anything bad) - I simply started to do this as I wanted to
> understand what the code was doing and found the learning curve steep.
> I can submit some of these changes if it would be helpful?
Absolutely!
The best thing to do is to open a Jira issue and then submit patches on
that issue.
I don't know exactly what a good sized patch would be (or even if that
is an issue). I don't think we'd want one big mega patch, but maybe
patches scoped to a group of related packages (e.g.
org.apache.pluto.core.*). It just makes it a little easier to review
and apply.
Others please chime in if you disagree -
How does this sound?
Elliot
>
> I now check all revisions committed to the trunk as I reflect these
> changes (if the change required) in the code I compile and use.
>
> Kind regards,
> --
> Marc
>
>
> On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> Marc,
>>
>> I hear you on finals - we just haven't been using them throughout the
>> codebase, though that is something we could change.
>>
>> Trunk does require Java 1.5, so yes, developers are able to use 1.5
>> features. However, the 1.1.x branch needs to maintain 1.4 compat.
>>
>> Since a lot of patches are being applied to both the 1.1.x branch and
>> the trunk, the code in trunk hasn't really begun to take advantage of
>> 1.5 features. However, before 1.2.0 (trunk) is released, we do plan to
>> convert to generics, at least for many of the interfaces.
>>
>> Sound good?
>>
>> Thanks,
>> Elliot
>>
>> Marc Veary wrote:
>> > You can leave out the finals - is there an issue with using finals? I
>> > use them all the time - you would be surprised at the issues it
>> > prevents.
>> >
>> > Also the annotations, please omit them - I do not mind in the least.
>> >
>> > Are you converting the loops to the newer format?
>> >
>> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >> Nope,
>> >>
>> >> Not forward at all.
>> >>
>> >> Can I leave out the 'final's or do you want them for some reason? We
>> >> also haven't been putting in the Java 5 annotations.
>> >>
>> >> What do you think?
>> >>
>> >> Elliot
>> >>
>> >> Marc Veary wrote:
>> >> > Cool.
>> >> >
>> >> > Can I submit this:
>> >> >
>> >> > @SuppressWarnings("unchecked")
>> >> > public Map getUserInfo( final PortletRequest request ) throws
>> >> > PortletContainerException
>> >> > {
>> >> > final String remoteUser = request.getRemoteUser();
>> >> > if( remoteUser != null )
>> >> > {
>> >> > final Map info = (Map)this.userInfoMap.get( remoteUser );
>> >> > if( info == null )
>> >> > {
>> >> > return Collections.EMPTY_MAP;
>> >> > }
>> >> > return info;
>> >> > }
>> >> > return Collections.EMPTY_MAP;
>> >> > }
>> >> >
>> >> > I hope this is not too forward of me.
>> >> >
>> >> > Keep up the good work!
>> >> >
>> >> > Kind regards,
>> >> > --
>> >> > Marc
>> >> >
>> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >> >> Good catch Marc,
>> >> >>
>> >> >> Not enough sleep and too much coffee on my part. :-)
>> >> >>
>> >> >> Fixed r552420, 552421.
>> >> >>
>> >> >> Thanks!
>> >> >> Elliot
>> >> >>
>> >> >>
>> >> >>
>> >> >> Marc Veary wrote:
>> >> >> > Hi All,
>> >> >> > Just got the HEAD from SVN and was checking over the changes as I
>> >> try
>> >> >> > to keep this in sync with the code I am using. I noticed the
>> >> >> > following does not seem to be correct:
>> >> >> >
>> >> >> > public Map getUserInfo(PortletRequest request)
>> >> >> > throws PortletContainerException {
>> >> >> > if ( request.getRemoteUser() != null ) {
>> >> >> > Map info =
>> (Map)userInfoMap.get(request.getRemoteUser());
>> >> >> > if ( info == null ) {
>> >> >> > return Collections.EMPTY_MAP;
>> >> >> > }
>> >> >> > }
>> >> >> > return new HashMap();
>> >> >> > }
>> >> >> >
>> >> >> > This ALWAYS returns an EMPTY MAP? Whereas the previous version
>> >> >> > returned the userInfoMap from the request. I think the attempt
>> >> was to
>> >> >> > return an empty map if the 'info' was null?
>> >> >> >
>> >> >> > Kind regards,
>> >> >> > --
>> >> >> > Marc
>> >> >>
>> >>
>>
Re: DefaultUserInfoService
Posted by Marc Veary <nw...@googlemail.com>.
Excellent!
I have been going through the trunk over the past 4-6 months
converting the obvious, doing a code tidying and amending javadocs
where necessary (this is not meant to be rude to other developers or
imply anything bad) - I simply started to do this as I wanted to
understand what the code was doing and found the learning curve steep.
I can submit some of these changes if it would be helpful?
I now check all revisions committed to the trunk as I reflect these
changes (if the change required) in the code I compile and use.
Kind regards,
--
Marc
On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> Marc,
>
> I hear you on finals - we just haven't been using them throughout the
> codebase, though that is something we could change.
>
> Trunk does require Java 1.5, so yes, developers are able to use 1.5
> features. However, the 1.1.x branch needs to maintain 1.4 compat.
>
> Since a lot of patches are being applied to both the 1.1.x branch and
> the trunk, the code in trunk hasn't really begun to take advantage of
> 1.5 features. However, before 1.2.0 (trunk) is released, we do plan to
> convert to generics, at least for many of the interfaces.
>
> Sound good?
>
> Thanks,
> Elliot
>
> Marc Veary wrote:
> > You can leave out the finals - is there an issue with using finals? I
> > use them all the time - you would be surprised at the issues it
> > prevents.
> >
> > Also the annotations, please omit them - I do not mind in the least.
> >
> > Are you converting the loops to the newer format?
> >
> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >> Nope,
> >>
> >> Not forward at all.
> >>
> >> Can I leave out the 'final's or do you want them for some reason? We
> >> also haven't been putting in the Java 5 annotations.
> >>
> >> What do you think?
> >>
> >> Elliot
> >>
> >> Marc Veary wrote:
> >> > Cool.
> >> >
> >> > Can I submit this:
> >> >
> >> > @SuppressWarnings("unchecked")
> >> > public Map getUserInfo( final PortletRequest request ) throws
> >> > PortletContainerException
> >> > {
> >> > final String remoteUser = request.getRemoteUser();
> >> > if( remoteUser != null )
> >> > {
> >> > final Map info = (Map)this.userInfoMap.get( remoteUser );
> >> > if( info == null )
> >> > {
> >> > return Collections.EMPTY_MAP;
> >> > }
> >> > return info;
> >> > }
> >> > return Collections.EMPTY_MAP;
> >> > }
> >> >
> >> > I hope this is not too forward of me.
> >> >
> >> > Keep up the good work!
> >> >
> >> > Kind regards,
> >> > --
> >> > Marc
> >> >
> >> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >> >> Good catch Marc,
> >> >>
> >> >> Not enough sleep and too much coffee on my part. :-)
> >> >>
> >> >> Fixed r552420, 552421.
> >> >>
> >> >> Thanks!
> >> >> Elliot
> >> >>
> >> >>
> >> >>
> >> >> Marc Veary wrote:
> >> >> > Hi All,
> >> >> > Just got the HEAD from SVN and was checking over the changes as I
> >> try
> >> >> > to keep this in sync with the code I am using. I noticed the
> >> >> > following does not seem to be correct:
> >> >> >
> >> >> > public Map getUserInfo(PortletRequest request)
> >> >> > throws PortletContainerException {
> >> >> > if ( request.getRemoteUser() != null ) {
> >> >> > Map info = (Map)userInfoMap.get(request.getRemoteUser());
> >> >> > if ( info == null ) {
> >> >> > return Collections.EMPTY_MAP;
> >> >> > }
> >> >> > }
> >> >> > return new HashMap();
> >> >> > }
> >> >> >
> >> >> > This ALWAYS returns an EMPTY MAP? Whereas the previous version
> >> >> > returned the userInfoMap from the request. I think the attempt
> >> was to
> >> >> > return an empty map if the 'info' was null?
> >> >> >
> >> >> > Kind regards,
> >> >> > --
> >> >> > Marc
> >> >>
> >>
>
Re: DefaultUserInfoService
Posted by Elliot Metsger <em...@jhu.edu>.
Marc,
I hear you on finals - we just haven't been using them throughout the
codebase, though that is something we could change.
Trunk does require Java 1.5, so yes, developers are able to use 1.5
features. However, the 1.1.x branch needs to maintain 1.4 compat.
Since a lot of patches are being applied to both the 1.1.x branch and
the trunk, the code in trunk hasn't really begun to take advantage of
1.5 features. However, before 1.2.0 (trunk) is released, we do plan to
convert to generics, at least for many of the interfaces.
Sound good?
Thanks,
Elliot
Marc Veary wrote:
> You can leave out the finals - is there an issue with using finals? I
> use them all the time - you would be surprised at the issues it
> prevents.
>
> Also the annotations, please omit them - I do not mind in the least.
>
> Are you converting the loops to the newer format?
>
> On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> Nope,
>>
>> Not forward at all.
>>
>> Can I leave out the 'final's or do you want them for some reason? We
>> also haven't been putting in the Java 5 annotations.
>>
>> What do you think?
>>
>> Elliot
>>
>> Marc Veary wrote:
>> > Cool.
>> >
>> > Can I submit this:
>> >
>> > @SuppressWarnings("unchecked")
>> > public Map getUserInfo( final PortletRequest request ) throws
>> > PortletContainerException
>> > {
>> > final String remoteUser = request.getRemoteUser();
>> > if( remoteUser != null )
>> > {
>> > final Map info = (Map)this.userInfoMap.get( remoteUser );
>> > if( info == null )
>> > {
>> > return Collections.EMPTY_MAP;
>> > }
>> > return info;
>> > }
>> > return Collections.EMPTY_MAP;
>> > }
>> >
>> > I hope this is not too forward of me.
>> >
>> > Keep up the good work!
>> >
>> > Kind regards,
>> > --
>> > Marc
>> >
>> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> >> Good catch Marc,
>> >>
>> >> Not enough sleep and too much coffee on my part. :-)
>> >>
>> >> Fixed r552420, 552421.
>> >>
>> >> Thanks!
>> >> Elliot
>> >>
>> >>
>> >>
>> >> Marc Veary wrote:
>> >> > Hi All,
>> >> > Just got the HEAD from SVN and was checking over the changes as I
>> try
>> >> > to keep this in sync with the code I am using. I noticed the
>> >> > following does not seem to be correct:
>> >> >
>> >> > public Map getUserInfo(PortletRequest request)
>> >> > throws PortletContainerException {
>> >> > if ( request.getRemoteUser() != null ) {
>> >> > Map info = (Map)userInfoMap.get(request.getRemoteUser());
>> >> > if ( info == null ) {
>> >> > return Collections.EMPTY_MAP;
>> >> > }
>> >> > }
>> >> > return new HashMap();
>> >> > }
>> >> >
>> >> > This ALWAYS returns an EMPTY MAP? Whereas the previous version
>> >> > returned the userInfoMap from the request. I think the attempt
>> was to
>> >> > return an empty map if the 'info' was null?
>> >> >
>> >> > Kind regards,
>> >> > --
>> >> > Marc
>> >>
>>
Re: DefaultUserInfoService
Posted by Marc Veary <nw...@googlemail.com>.
You can leave out the finals - is there an issue with using finals? I
use them all the time - you would be surprised at the issues it
prevents.
Also the annotations, please omit them - I do not mind in the least.
Are you converting the loops to the newer format?
On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> Nope,
>
> Not forward at all.
>
> Can I leave out the 'final's or do you want them for some reason? We
> also haven't been putting in the Java 5 annotations.
>
> What do you think?
>
> Elliot
>
> Marc Veary wrote:
> > Cool.
> >
> > Can I submit this:
> >
> > @SuppressWarnings("unchecked")
> > public Map getUserInfo( final PortletRequest request ) throws
> > PortletContainerException
> > {
> > final String remoteUser = request.getRemoteUser();
> > if( remoteUser != null )
> > {
> > final Map info = (Map)this.userInfoMap.get( remoteUser );
> > if( info == null )
> > {
> > return Collections.EMPTY_MAP;
> > }
> > return info;
> > }
> > return Collections.EMPTY_MAP;
> > }
> >
> > I hope this is not too forward of me.
> >
> > Keep up the good work!
> >
> > Kind regards,
> > --
> > Marc
> >
> > On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> >> Good catch Marc,
> >>
> >> Not enough sleep and too much coffee on my part. :-)
> >>
> >> Fixed r552420, 552421.
> >>
> >> Thanks!
> >> Elliot
> >>
> >>
> >>
> >> Marc Veary wrote:
> >> > Hi All,
> >> > Just got the HEAD from SVN and was checking over the changes as I try
> >> > to keep this in sync with the code I am using. I noticed the
> >> > following does not seem to be correct:
> >> >
> >> > public Map getUserInfo(PortletRequest request)
> >> > throws PortletContainerException {
> >> > if ( request.getRemoteUser() != null ) {
> >> > Map info = (Map)userInfoMap.get(request.getRemoteUser());
> >> > if ( info == null ) {
> >> > return Collections.EMPTY_MAP;
> >> > }
> >> > }
> >> > return new HashMap();
> >> > }
> >> >
> >> > This ALWAYS returns an EMPTY MAP? Whereas the previous version
> >> > returned the userInfoMap from the request. I think the attempt was to
> >> > return an empty map if the 'info' was null?
> >> >
> >> > Kind regards,
> >> > --
> >> > Marc
> >>
>
Re: DefaultUserInfoService
Posted by Elliot Metsger <em...@jhu.edu>.
Nope,
Not forward at all.
Can I leave out the 'final's or do you want them for some reason? We
also haven't been putting in the Java 5 annotations.
What do you think?
Elliot
Marc Veary wrote:
> Cool.
>
> Can I submit this:
>
> @SuppressWarnings("unchecked")
> public Map getUserInfo( final PortletRequest request ) throws
> PortletContainerException
> {
> final String remoteUser = request.getRemoteUser();
> if( remoteUser != null )
> {
> final Map info = (Map)this.userInfoMap.get( remoteUser );
> if( info == null )
> {
> return Collections.EMPTY_MAP;
> }
> return info;
> }
> return Collections.EMPTY_MAP;
> }
>
> I hope this is not too forward of me.
>
> Keep up the good work!
>
> Kind regards,
> --
> Marc
>
> On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
>> Good catch Marc,
>>
>> Not enough sleep and too much coffee on my part. :-)
>>
>> Fixed r552420, 552421.
>>
>> Thanks!
>> Elliot
>>
>>
>>
>> Marc Veary wrote:
>> > Hi All,
>> > Just got the HEAD from SVN and was checking over the changes as I try
>> > to keep this in sync with the code I am using. I noticed the
>> > following does not seem to be correct:
>> >
>> > public Map getUserInfo(PortletRequest request)
>> > throws PortletContainerException {
>> > if ( request.getRemoteUser() != null ) {
>> > Map info = (Map)userInfoMap.get(request.getRemoteUser());
>> > if ( info == null ) {
>> > return Collections.EMPTY_MAP;
>> > }
>> > }
>> > return new HashMap();
>> > }
>> >
>> > This ALWAYS returns an EMPTY MAP? Whereas the previous version
>> > returned the userInfoMap from the request. I think the attempt was to
>> > return an empty map if the 'info' was null?
>> >
>> > Kind regards,
>> > --
>> > Marc
>>
Re: DefaultUserInfoService
Posted by Marc Veary <nw...@googlemail.com>.
Cool.
Can I submit this:
@SuppressWarnings("unchecked")
public Map getUserInfo( final PortletRequest request ) throws
PortletContainerException
{
final String remoteUser = request.getRemoteUser();
if( remoteUser != null )
{
final Map info = (Map)this.userInfoMap.get( remoteUser );
if( info == null )
{
return Collections.EMPTY_MAP;
}
return info;
}
return Collections.EMPTY_MAP;
}
I hope this is not too forward of me.
Keep up the good work!
Kind regards,
--
Marc
On 7/2/07, Elliot Metsger <em...@jhu.edu> wrote:
> Good catch Marc,
>
> Not enough sleep and too much coffee on my part. :-)
>
> Fixed r552420, 552421.
>
> Thanks!
> Elliot
>
>
>
> Marc Veary wrote:
> > Hi All,
> > Just got the HEAD from SVN and was checking over the changes as I try
> > to keep this in sync with the code I am using. I noticed the
> > following does not seem to be correct:
> >
> > public Map getUserInfo(PortletRequest request)
> > throws PortletContainerException {
> > if ( request.getRemoteUser() != null ) {
> > Map info = (Map)userInfoMap.get(request.getRemoteUser());
> > if ( info == null ) {
> > return Collections.EMPTY_MAP;
> > }
> > }
> > return new HashMap();
> > }
> >
> > This ALWAYS returns an EMPTY MAP? Whereas the previous version
> > returned the userInfoMap from the request. I think the attempt was to
> > return an empty map if the 'info' was null?
> >
> > Kind regards,
> > --
> > Marc
>
Re: DefaultUserInfoService
Posted by Elliot Metsger <em...@jhu.edu>.
Good catch Marc,
Not enough sleep and too much coffee on my part. :-)
Fixed r552420, 552421.
Thanks!
Elliot
Marc Veary wrote:
> Hi All,
> Just got the HEAD from SVN and was checking over the changes as I try
> to keep this in sync with the code I am using. I noticed the
> following does not seem to be correct:
>
> public Map getUserInfo(PortletRequest request)
> throws PortletContainerException {
> if ( request.getRemoteUser() != null ) {
> Map info = (Map)userInfoMap.get(request.getRemoteUser());
> if ( info == null ) {
> return Collections.EMPTY_MAP;
> }
> }
> return new HashMap();
> }
>
> This ALWAYS returns an EMPTY MAP? Whereas the previous version
> returned the userInfoMap from the request. I think the attempt was to
> return an empty map if the 'info' was null?
>
> Kind regards,
> --
> Marc