RE: [jira] Commented: (JAMES-562) Aliasmanagment should not dependon a user

["Noel J. Bergman" <no...@devtech.com>]

Norman Maurer wrote:

> Stefano Bagnara:
> > Noel J. Bergman wrote:
> > > Also, to speak directly to your concern, please consider that we
already
> > > have JDBC and XML based VUT implementations.  Doesn't it seem
reasonable to
> > > unify the mapping code by writing a VUT that is populated from user
> > > repositories?  For one thing, as I noted, the account-based
alias/forwarding
> > > code happens only during local delivery, whereas virtual user table
behavior
> > > can happen anywhere in the pipeline, from in-protocol to delivery.
> > I already splitted LocalDelivery into UsersRepositoryAliasingForwarding
> > and ToMultiRepository. The first one is the one that is needed to
> > support the aliasing/forwarding. We may remove LocalDelivery from our
> > config.xml and insert the 2 mailets as separate instances so that it
> > will be much more clear what happens and when.

> +1
> Im not sure if we should do this in 2.3 or in later versions. IF we want
> todo it not now we should mark LocalDelivery as @deprecated before
> release 2.3 final.

It isn't so bad as that.  :-)  But it should be for later.  :-)


> > This may mean that also UsersRepositoryAliasingForwarding is movable
> > around like the VUTs and that we could write a fastfail for it like for
> > VUTs.

> I don't understand this. Can you explain ?

See below.

> > I always thought that all of this stuff should be accessed via a common
> > interface so we may create services and have generic
> > mailets/matchers/fastfailfilters to access them.

> IF we could manage this this whould be great.

We already have a common interface.  The UsersRepositoryAliasingForwarding
code should be rewritten as a virtual user table, following the existing
interfaces.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org