Hi, Eric,
Thanks so much. I feel a bit more comfortable going this route now. Not
really a problem with the single repository now that I know about it.
The way we are doing the alias email addresses, it's going to be pretty
easy to determine if it's an alias email or a regular email. I'll just
code the custom repository class to be smart enough to determine whether
to look for the user info in my CIS or in the normal James user table.
I'm pretty sure I can make that work.
Thanks again.
Jerry
On 2/23/2013 7:16 AM, Eric Charles wrote:
Hi Jerry,
On the strategy (writing a custom UserRepository to fetch information
from your CIS), I would also go this way if I had to do it myself. So
you are on the right track I think.
This should give no problem if you want to use that single
UserRepository for all your mails, but you say you want to be able to
fallback to the normal UserRepository for normal mails.
I have worked more on James3 (not James2.3), and I remember at a time,
we had to take a decision to only migrate the 2.3 UsersRepository and
to ease things, we decided to remove that 'names' reference attribute,
so removing the possibility to support multiple UserRepository (this
could be readded after).
But at that time, and still now, I was wondering if James2.3 really
supported multiple UsersRepository. It is not because you have a name
as attribute that you can have multiple of those. From what I have
seen so far, I think it does not support this, but I may be wrong.
The best for you is to further digg into James2.3 sources or hope that
a James2.3 specialist answers your question here (relaunch to trigger
them).
Thx, Eric
On 23/02/2013 05:46, Jerry M wrote:
My client's company sells lead lists to vendors. They want to hide the
real email addresses for the leads and provide only aliased email
addresses for the leads in the lead lists. (e.g.
"12...@leads.mycompany.com") I will look for any mail coming into
"leads.mycompany.com", and map the aliased address to the real address
and pass it on (with a bit of logging, adding footers, etc along the
way).
I have a general knowledge of how the transport system works in James,
and I've been looking at the source code. Also, I've written several
mailets over the years. So I'm not a newbie at this. I want to do this
in the most efficient way possible. I know that if I created a massive
user table with useForwarding and ForwardingAddress, this would work.
But I do not want to maintain that user table. I want to do the lookup
in my existing Contact Information System, which already has all of the
data and mapping that I need built into it.
So, I'm thinking that the best way to do this to maximize all of the
existing transport code in James is to simply write a new UserRepository
Impl class that produces Userobjects built from my CIS. Am I on the
right track?
If this is the way to go, I do have one question regarding user
repositories. I'm using James 2.3.2, and my config XML file was started
many releases before that and has been migrated. It works. But I'm not
sure if it contains all of the latest capabilities. In my config file,
there is only one userrepository defined, and it is never referenced by
name. If I go this route with the special user repository, I will still
have regular "non-lead" mail coming in that will need to be handled and
stored using a standard James JDBC user repository. So, is it possible
to define two user repositories? And then I'll have one transport
processor that uses the default repository and a new transport processor
that uses my custom repository. Is this going to work? Since the user
repository that's in use now is not referenced by name, I'm not sure I
know how to specify which repository to use in the two transport
processors if I have more than one user repository defined.
Am I anywhere close to the right track for how to solve this problem? Is
there some completely different approach that makes it a lot easier?
Thanks for the advice.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2899 / Virus Database: 2639/6123 - Release Date: 02/22/13
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
