Extending basic James services (Virtual Hosting)

[Simeon Kirov <sk...@worldnn.com>]

Hi all,

I know it's bad teasing you at release time, but could you consider this:

I developed some extension to James 2.1a1, which allows virtual hosting.
I decided to extend some of the basic James service classes like
org.apache.james.James, org.apache.james.pop3server.POP3ServerHandler,
org.apache.james.remotemanager.RemoteManagerHandler etc.

MY MAIN POINT is, that in order to make this I should redeclare almost all
private members of the respective classes as protected. Could you consider
in your future releases making those members protected by default? This will
make James extendable not only by mailets...

If you're interested in the exact implementation, look at the attached zip
file. It contains sources and modified configuration files.

Supported virtual hosts are defined in separate
<virtualHosts>...</virtualHosts> section in config.xml. Every virtual host
uses a separate Users and Inbox repository. Virtual POP3 boxes are accessed
through fully qualified user's e-mail address, i.e. user1@virtualhost.com.

RemoteManager is modified also to support this kind of virtual hosting, by
adding 3 new commands:

listhost, selecthost and activehost.

Fill free to use it, if you find it useful.

Simeon

RE: Extending basic James services (Virtual Hosting)

["Peter M. Goldstein" <pe...@yahoo.com>]

Simeon,

> I developed some extension to James 2.1a1, which allows virtual
hosting.
> I decided to extend some of the basic James service classes like
> org.apache.james.James, org.apache.james.pop3server.POP3ServerHandler,
> org.apache.james.remotemanager.RemoteManagerHandler etc.

We'd be very happy to have you participate in a discussion of how we add
virtual host support to James in the next version.  This is a fairly
contentious topic, especially when it involves changes to the core code
(i.e. is not accomplished through mailets) and needs to be fully
designed and architected.  But we'd love to hear your thoughts on the
matter.
 
> MY MAIN POINT is, that in order to make this I should redeclare almost
all
> private members of the respective classes as protected. Could you
consider
> in your future releases making those members protected by default?
This
> will
> make James extendable not only by mailets...

-1

There is a very, very good reason not to do things like this.  What
you're effectively asking us to do is to make all of our service and
handler classes public APIs.  That ties our implementation in place.  We
have enough problems maintaining backwards compatibility with the mailet
API.  Doing as you suggest with the classes in the code base would not
only introduce backwards compatibility issues, but would also tie our
hands when it came to redesign.  See "Effective Java" by Joshua Bloch
for a more complete discussion of this issue.

> If you're interested in the exact implementation, look at the attached
zip
> file. It contains sources and modified configuration files.

I'll be very happy to look at this, after the current release goes out.

--Peter



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Extending basic James services (Virtual Hosting)

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

Simeon,

My personal view is that virtual hosting needs a complete design review from
top to bottom.  I would not undertake that at this time.

When we do undertake it, I have questions about how best to deal with it.
For example, the approach that you and Zsombor Gegesy took was substantial
recoding of James to support fully-qualified mailbox (FQMB) identification.
That appears to be all that is provided by the code changes, and the basic
change is support for:

  - store mail keyed by FQMB
  - retrieve mail by FQMB

It does not provide anything more than FQMB support, e.g., catch-all
matching or other types of behavior found in sendmail's virtual user table
scheme.

For the next release, I'd want to start with the data model.  I think that
there are a number of things that could be integrated coherently.

	--- Noel

-----Original Message-----
From: Simeon Kirov [mailto:skirov@worldnn.com]
Sent: Friday, October 04, 2002 9:18
To: james-dev@jakarta.apache.org
Subject: Extending basic James services (Virtual Hosting)


Hi all,

I know it's bad teasing you at release time, but could you consider this:

I developed some extension to James 2.1a1, which allows virtual hosting.
I decided to extend some of the basic James service classes like
org.apache.james.James, org.apache.james.pop3server.POP3ServerHandler,
org.apache.james.remotemanager.RemoteManagerHandler etc.

MY MAIN POINT is, that in order to make this I should redeclare almost all
private members of the respective classes as protected. Could you consider
in your future releases making those members protected by default? This will
make James extendable not only by mailets...

If you're interested in the exact implementation, look at the attached zip
file. It contains sources and modified configuration files.

Supported virtual hosts are defined in separate
<virtualHosts>...</virtualHosts> section in config.xml. Every virtual host
uses a separate Users and Inbox repository. Virtual POP3 boxes are accessed
through fully qualified user's e-mail address, i.e. user1@virtualhost.com.

RemoteManager is modified also to support this kind of virtual hosting, by
adding 3 new commands:

listhost, selecthost and activehost.

Fill free to use it, if you find it useful.

Simeon


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>