portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Veary" <nwl...@googlemail.com>
Subject Re: DefaultUserInfoService
Date Mon, 02 Jul 2007 13:15:34 GMT
Hi Craig,

Will do.  As I said to Elliot, I plan to do a small number of changes
to a couple of classes at a time and submit them so that it is not too
much at one go.

A question: There are a small number of deprecated methods on one or
two interfaces which are referenced internally within the container.
Would it be inappropriate to update the internal classes so that they
do not use these deprectated methods?

Sorry to ask a question to which the answer might seem obvious (I am
new to this group), but experience has shown me that it is better to
ask than charge ahead and waste everyone's time (e.g. in my mind:
deprecate means 'do not use this any more', it is there for legacy
reason only and might later be removed).

Kind regards

On 7/2/07, CDoremus@hannaford.com <CDoremus@hannaford.com> wrote:
> Hi Marc,
>
> Any contribution would be greatly appreciated. Please group the patches into
> functional units (related to build system, deployer, descriptor,
> documentation, maven pluto plugin, portal driver, portlet container, portlet
> container taglibs, portlets-admin, portlets-testsuite), create a Jira issue
> for each unit and attach the patch(es) to the Jira issue.
>
> TIA
> /Craig
>
> -----"Marc Veary" <nwlcoc@googlemail.com> wrote: -----
>
> To: pluto-dev@portals.apache.org
> From: "Marc Veary" <nwlcoc@googlemail.com>
> Date: 07/02/2007 04:34AM
> Subject: Re: DefaultUserInfoService
>
> 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 <emetsger@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 <emetsger@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 <emetsger@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 <emetsger@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
> > >> >> >>
> > >> >>
> > >>
> >
>
>

Mime
View raw message