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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
