RE: [Cruisecontrol-devel] EmailAddressMapper interface

[Jeffrey F. <jt...@ag...>]

=20
1) I mentally have the "shorter config.xml files" discussion slated for
2.2.1, which I imagine to be in a week or two after I can merge the =
patches
for MX4J & multithreaded building.
=20
2) I'm not sure I understand, but to the extend that I have an idea I =
think
it is the same as what I'm suggesting.  In my mental model the publisher
would pass a set to the mapper and get a different set in return. Is =
this
what you had in mind or did I misunderstand?
=20
Jtf

-----Original Message-----
From: cru...@li...
[mailto:cru...@li...] On Behalf Of =
Esa
Laine
Sent: Monday, February 23, 2004 5:38 PM
To: Jeffrey Fredrick; 'Cruisecontrol Developers'
Subject: Re: [Cruisecontrol-devel] EmailAddressMapper interface


That would be OK.
=20
This does raise two points thou.
=20
1) time to have the 'blue sky features, shorter config.xml files' =
discussion
=20
2) Would it make sense for the mappers to consume the set (maybe
constructing a mapped set in the process) so that mapped entries need =
not be
passed around?
=20
Esa
=20
=20
----- Original Message -----=20

From: Jeffrey Fredrick <mailto:jt...@ag...> =20
To: 'Esa Laine' <mailto:es...@in...>  ; 'Cruisecontrol
<mailto:cru...@li...> Developers'=20
Sent: Monday, February 23, 2004 8:09 PM
Subject: RE: [Cruisecontrol-devel] EmailAddressMapper interface

=20
actually it was this sort of scenario I had in mind -- multiple address
mappers and each just mapping the address they care/know about.
=20
the config.xml might look like:
=20
<email ...>
  <ldapmapper ... />
  <propertiesmapper ... />
  <webservicemapper ../>
  <databasemapper ...>
</email>
=20
the email publisher would just iterate over the list of mappers and pass =
the
set along between them. In each case the mapper could ignore any that =
have
already been mapped and map the ones it knew about.  Of course providing =
one
super duper mapper that used an inheritance hierarchy would work as =
well,
but the point is that the email publisher wouldn't know and wouldn't =
care.
=20
that seem like it would work for your use case, or is there something =
I'm
missing?
=20
Jtf

-----Original Message-----
From: cru...@li...
[mailto:cru...@li...] On Behalf Of =
Esa
Laine
Sent: Monday, February 23, 2004 4:47 PM
To: Jeffrey Fredrick; 'Cruisecontrol Developers'
Subject: Re: [Cruisecontrol-devel] EmailAddressMapper interface


Jeffrey,
=20
I only care to the extent that this increases my work;)
=20
(read that to mean: by all means change it, but make the changes such =
that
what I'll describe here is easy to accomplish, even if in a different =
way)
=20
I work for a very large corporation, and as such nothing is simple, not =
even
'single signon' (which really is single in name only).
=20
So, what I've ended up having to do is to use four (4) diffrent
EmailAddressMappers for our projects. (And we really need all four for =
quite
a few of our projects, I have them stuck in all of them for simplicity)
=20
The EmailAddressMappers we use are for these purposes:
=20
map users from a coprorate ldap
map users from a properties file
map users from a web service
map users from a database
=20
I'm using the <map/> entries in the config file to pass configuration
parameters to the EmailAddressMapper classes I've implemented. Instead =
of
email addresses, I'm using it for generic hashmap of config variables =
(such
as ldap host, etc).
=20
My classes are put into action by an inheritance hierarchy.
=20
ProperitesFileEmailAddressMapper extends LDAPEmailAddressMapper extends
WebServiceEmailAddressMapper extends DBEmailAddressMapper
=20
(I forget the actual order, but you get the point).
=20
Each individual class if of one of two forms
=20
One)
=20
open()
    super.open()
    string s =3D super.mapUser(configLookupString[s])
    openForReal(using s, the configLookupValue[s]);
=20
close()
    closeForReal()
    super.close()
=20
mapUser(String user)
    if ( doIKnowHowToMapUser(user) )
        retrurn myWayOfMappingUser(user)
    else
        return super.mapUser(user)
=20
or alternatively
=20
Two)
=20
open and close exactly like above
=20
mapUser(String user)
    String mappedUser =3D super.mapperUser(user)
    if (mappedUser =3D=3D null)
        mappedUser =3D myWayOfMappingUser(user)
=20
    return mappedUser
=20
An inheritance hierarchy is a very convinient way of doing multiple
different mappings, without having to manage the set of ids to look up.
=20
That having been said, it would be possible to implement something =
similiar
using the Set mapUser(Set) approach, but [potentially] each
EmailAddressMapper would have to manage the set (I would implement a
subclass of EmailAddressMapper that exposes open, close, and =
mapUser(String)
and inherit from there.)
=20
Essentially, what I'm saying is that the set of users needs to (in my =
case)
be managed, and different things done based on what the individual =
member of
the set. So why not just let one spot in the code worry about managing =
the
set.
=20
In addition to the 4 different ways of mapping users there is looming a =
5th
that will come my way this summer.
=20
Welcome to 'large corporate world',
=20
Esa
=20
   =20

----- Original Message -----=20
From: Jeffrey  <mailto:jt...@ag...> Fredrick=20
To: 'Esa Laine' <mailto:es...@in...>  ; 'Cruisecontrol
<mailto:cru...@li...> Developers'=20
Sent: Sunday, February 22, 2004 8:47 PM
Subject: [Cruisecontrol-devel] EmailAddressMapper interface

=20
Hi Esa,
=20
I've given some thought to the EmailAddressMapper interface and I wonder
what you'd think of changing it to be a single method:
=20
    Set mapUsers(Set users)
=20
This method would take the set of users and return the set of users w/an
mapping completed. My main motivation for this change is that I like the
idea of the publisher not caring about the open & close steps.
=20
Thoughts?
=20
Jtf

-----Original Message-----
From: cru...@li...
[mailto:cru...@li...] On Behalf Of Esa
Laine
Sent: Wednesday, February 18, 2004 2:49 PM
To: Garrick Olson; cru...@li...
Subject: Re: [Cruisecontrol-user] Can I still use a property file to map
email users?


Take a look at the emailaddressmapper property of the emailpublisher, =
entend
the default class with your own implementation (just the methods
open(),close() and mapUser(String)), and stick it in.
=20
The current test cases has a sample (not reading a properties file thou)
that you can use as a starting point.
=20
Esa
=20

----- Original Message -----=20
From: Garrick Olson <mailto:Garrick.Olson@Aceva.com> =20
To: cru...@li...=20
Sent: Tuesday, February 17, 2004 6:01 PM
Subject: [Cruisecontrol-user] Can I still use a property file to map =
email
users?



This was possible with earlier versions of CC, but it looks like this
feature was removed.=20

I know you can use XML formatted mappings (both as part of config.xml =
and by
including a separate file), but I don't see how to use a property file.  =
Am
I just missing something obvious?