[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    [jira] Updated: (JAMES-347) make POP3Handler.java/POP3Server.java and AvalonUsersStore.java extensib
From:       "Danny Angus (JIRA)" <server-dev () james ! apache ! org>
Date:       2005-01-10 14:54:12
Message-ID: 651441523.1105368852895.JavaMail.jira () ajax ! apache ! org
[Download RAW message or body]

     [ http://issues.apache.org/jira/browse/JAMES-347?page=history ]

Danny Angus updated JAMES-347:
------------------------------

        type: Improvement  (was: New Feature)
    Priority: Minor  (was: Major)
     Version: 2.2.1
                  (was: 3.0)

I can understand the reasons behind this request but I'm not convinced that all of \
them are valid. It may be that it is preferable to extract a generalisation for \
extension, or that Ralf Hauser would be better served using delegation.

Also:
"compose() method is executed even if though my config.xml says <smtpserver \
enabled="false">" That is correct, it is present but not active.

> make POP3Handler.java/POP3Server.java and AvalonUsersStore.java extensible
> --------------------------------------------------------------------------
> 
> Key: JAMES-347
> URL: http://issues.apache.org/jira/browse/JAMES-347
> Project: James
> Type: Improvement
> Components: POP3Server
> Versions: 2.2.1
> Environment: any
> Reporter: Ralf Hauser
> Priority: Minor

> 
> As discussed in James 288, my application of james i) needs more memory efficiency \
> and ii) unfortunately needs to remain with "db store" and iii) adds some extra \
> logic to the pop implementation (see http://p4u.ch) In order to allow for such \
> extensions without requiring duplication of existing code that is perfectly ok for \
> my purposes (most of the POP3Handler.do*() methods), it would great if 1) the \
> methods of POP3Handler.java would not be of type "private" such that classes \
> extending POP3Handler.java could use them if there is no need to overwrite them \
> (the same applies to the "final static String OK_RESPONSE="... and alike) even if \
> the extending class is not in the same directory 2) similarly, make \
> org.apache.james.core.AvalonUsersStore extensible by making its contents also \
> accessible to extending classes thereof (the methods are "public", but the content \
> only "protected" - so either provide getters and setters or make them public) 3) \
> ditto org.apache.james.pop3server.POP3Server - then I could specify the extended \
> class in james-assembly without having to copy all unchanged methods. If in \
> org.apache.james.pop3server.POP3Server.POP3HandlerFactory.newInstance() were to \
> create a configurable handler object as suggested in "4)" and not the hard-coded \
> POP3Handler, extending the POP3Server might not even be necessary 4) in the config, \
> allow to specify other (extended) classes for james-assembly's \
> role="org.apache.james.services.UsersStore" much like the struts-config.xml's \
> <message-resources null="false" ... className="...MessageResourcesConfigExtension" \
> /> does where either the default class is used or an own implementation will be \
>                 used 
> - another little difficulty is that it doesn't appear to be possible to use an \
> extended UserStore just for pop3server, but not the others since ins assembly.xml, \
> I can only specify one user-store in the <!-- The User Storage block -->  <block \
>                 name="users-store"
> - furthermore, the compose method of each AbstractJamesService such as \
> org.apache.james.smtpserver.SMTPServer all \
>                 lookup("org.apache.james.services.UsersStore") that is hard-coded
> - also, that compose() method is executed even if though my config.xml says \
> <smtpserver enabled="false"> Reasons for doing all these extensions:
> * above-mentioined efficiency
> * being able to provide error messages in the user's language (nls/i18n)
> * being able to perform the authentication test with additional parameters such as \
>                 remotehost, etc., SSL session ID, ...
> * additional security/privacy/DSN logic as implemented http://p4u.ch

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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


[prev in list] [next in list] [prev in thread] [next in thread]