Re: cvs commit: james-server/tools/lib LICENSE.xdoclet.txt commons-logging.jar log4j-core.jar xdoclet-20020825.jar xjavadoc-20020825.jar
Hi, Yes, I plan to commit it for MAIN as well, hopefully today. --Søren On Thursday 19 February 2004 00:24, Steve Brewin wrote: > Hi Soren and Noel, > > These updates look great. The only worry I have is that in order to help > Noel with the task of merging the MAIN (3.0) and branch_2_1_fcs sources I > had recently synchronized the two fetchmail code paths. Now they are out of > sync. again as you have applied the JMX changes to branch_2_1_fcs only. > > Nothing wrong with that, but fetchmail cannot be resynced in MAIN without > adding to MAIN many of the changes committed to branch_2_1_fcs by this > commit. > > Is the intention to also commit the JMX changes to MAIN? If not, can we > agree that for the merge branch_2_1_fcs is the definitive source for > fetchmail and we will ignore MAIN? > > I would guess the same issues touch other areas too? > > -- Steve > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[IGNORE] test of mailing list filters
This is just a message to test which attachments get through. --- Noel attachements: hello.java, hello.xml, hello.html, hello.txt did I get filtered? did I get filtered? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: james-server/tools/lib LICENSE.xdoclet.txt commons-logging.jar log4j-core.jar xdoclet-20020825.jar xjavadoc-20020825.jar
Hi Soren and Noel, These updates look great. The only worry I have is that in order to help Noel with the task of merging the MAIN (3.0) and branch_2_1_fcs sources I had recently synchronized the two fetchmail code paths. Now they are out of sync. again as you have applied the JMX changes to branch_2_1_fcs only. Nothing wrong with that, but fetchmail cannot be resynced in MAIN without adding to MAIN many of the changes committed to branch_2_1_fcs by this commit. Is the intention to also commit the JMX changes to MAIN? If not, can we agree that for the merge branch_2_1_fcs is the definitive source for fetchmail and we will ignore MAIN? I would guess the same issues touch other areas too? -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: james-server/tools/lib LICENSE.xdoclet.txt commons-logging.jar log4j-core.jar xdoclet-20020825.jar xjavadoc-20020825.jar
hilmer 2004/02/18 13:47:28 Modified:.Tag: branch_2_1_fcs build.xml src/java/org/apache/james Tag: branch_2_1_fcs JamesMBean.java src/java/org/apache/james/context Tag: branch_2_1_fcs AvalonContextUtilities.java src/java/org/apache/james/core Tag: branch_2_1_fcs AbstractJamesService.java src/java/org/apache/james/dnsserver Tag: branch_2_1_fcs DNSServer.java DNSServer.xinfo src/java/org/apache/james/fetchmail Tag: branch_2_1_fcs FetchScheduler.java FetchScheduler.xinfo src/java/org/apache/james/fetchpop Tag: branch_2_1_fcs FetchScheduler.java FetchScheduler.xinfo src/java/org/apache/james/nntpserver Tag: branch_2_1_fcs NNTPServer.java NNTPServer.xinfo src/java/org/apache/james/pop3server Tag: branch_2_1_fcs POP3Server.java POP3Server.xinfo src/java/org/apache/james/remotemanager Tag: branch_2_1_fcs RemoteManager.java RemoteManager.xinfo src/java/org/apache/james/smtpserver Tag: branch_2_1_fcs SMTPServer.java SMTPServer.xinfo Added: src/java/org/apache/james/dnsserver Tag: branch_2_1_fcs DNSServerMBean.java src/java/org/apache/james/fetchmail Tag: branch_2_1_fcs FetchSchedulerMBean.java src/java/org/apache/james/fetchpop Tag: branch_2_1_fcs FetchSchedulerMBean.java src/java/org/apache/james/nntpserver Tag: branch_2_1_fcs NNTPServerMBean.java src/java/org/apache/james/pop3server Tag: branch_2_1_fcs POP3ServerMBean.java src/java/org/apache/james/remotemanager Tag: branch_2_1_fcs RemoteManagerMBean.java src/java/org/apache/james/smtpserver Tag: branch_2_1_fcs SMTPServerMBean.java tools/lib Tag: branch_2_1_fcs LICENSE.xdoclet.txt commons-logging.jar log4j-core.jar xdoclet-20020825.jar xjavadoc-20020825.jar Removed: src/java/org/apache/james Tag: branch_2_1_fcs JamesMBean.mxinfo Log: Submitted by:Steve SHort Reviewed by:hilmer More information are made available through JMX. .mxinfo files are autogenerated by the build process. Needed tools for mxinfo generation are added to tools/lib these jars obtained from Phoenix 4.0.3 Revision ChangesPath No revision No revision 1.116.2.21 +32 -2 james-server/build.xml Index: build.xml === RCS file: /home/cvs/james-server/build.xml,v retrieving revision 1.116.2.20 retrieving revision 1.116.2.21 diff -u -r1.116.2.20 -r1.116.2.21 --- build.xml 23 Oct 2003 19:00:45 - 1.116.2.20 +++ build.xml 18 Feb 2004 21:47:26 - 1.116.2.21 @@ -66,6 +66,14 @@ + + + + @@ -122,10 +130,24 @@ + + + + + + + + + + + + + + - + + + + + + No revision Index: DNSServer.xinfo === RCS file: /home/cvs/james-server/src/java/org/apache/james/dnsserver/DNSServer.xinfo,v retrieving revision 1.3 retrieving revision 1.3.6.1 diff -u -r1.3 -r1.3.6.1 --- DNSServer.xinfo 25 Sep 2001 04:51:19 - 1.3 +++ DNSServer.xinfo 18 Feb 2004 21:47:26 - 1.3.6.1 @@ -12,4 +12,10 @@ + + + + + + No revision Index: DNSServer.xinfo === RCS file: /home/cvs/james-server/src/java/org/apache/james/dnsserver/DNSServer.xinfo,v retrieving revision 1.3 retrieving revision 1.3.6.1 diff -u -r1.3 -r1.3.6.1 --- DNSServer.xinfo 25 Sep 2001 04:51:19 - 1.3 +++ DNSServer.xinfo 18 Feb 2004 21:47:26 - 1.3.6.1 @@ -12,4 +12,10 @@ + + + + + + 1.1.2.1 +71 -0 james-server/src/java/org/apache/james/dnsserver/Attic/DNSServerMBean.java No revision No revision 1.8.2.4 +12 -2 james-server/src/java/org/apache/james/fetchmail/FetchScheduler.java Index: FetchScheduler.java ===
RE: CVS problems
Been there, done that! Glad to be of help. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS problems
Thanks Steve How stupid can one get, totally forgot that I reinstalled a standard JDK 1.3.1, so i lost the jar, and got totally confused as the compilation started to fail. --Søren On Wednesday 18 February 2004 18:46, Steve Brewin wrote: > Soren > > For branch_2_1_fcs I see revision 1.1.2.2 of > src/java/org/apache/james/util/dbcp/JdbcDataSource.java, timestamped > 24/07/03 02:45. I believe this is the correct version and compiles fine > with JDK 1.3.1. > > Sure you have jdbc2_0-stdext.jar in your classpath? > > -- Steve > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding a user with his password
Roberto Sánchez (QO) wrote: > Hi, > > One question: > If the interface "User" hasn't a method to get the user's > password, How can I add to my repository a new user with the > correct password ? The interface UsersRepository has the > method: "boolean addUser(User user)", the only reference to > the user's data is an interface "User". The User interface has no knowledge of how your repository maintains security, or even if it does! > In other implementations of UserRepository, it is done a cast > to "DefaultUser" to use the method "getHashedPassword()" > > For example in > org.apache.james.userrepository.DefaultUsersJdbcRepository#set > UserForInsertStatement(User user, ...) > DefaultUser defUser = (DefaultUser)user; > ... > userInsert.setString(3, defUser.getHashedPassword()); > > What do you think about to include the method > "getHashedPassword()" in "User" interface ? I don't think it would be a good idea to force implementations of User to make their passwords accessable via a public method, hashed or otherwise. > Is it correct to do a cast to a class from an interface ? I > think this generate a dependency between RemoteManager and > Users Repositories then the interface "UserRepository" itsn't > sufficient to determine the "contract" for the Users > repository implementation. Is that correct ? The pragmatic approach taken currently is to say that only one type of UserRepository is concurrently supported, so it is safe to cast. It would be possible to refactor and use polymorphism to avoid this, but that isn't strictly neccesary when there is only ever one type of reposoitory involved. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CVS problems
Soren For branch_2_1_fcs I see revision 1.1.2.2 of src/java/org/apache/james/util/dbcp/JdbcDataSource.java, timestamped 24/07/03 02:45. I believe this is the correct version and compiles fine with JDK 1.3.1. Sure you have jdbc2_0-stdext.jar in your classpath? -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding a user with his password
Hi, One question: If the interface "User" hasn't a method to get the user's password, How can I add to my repository a new user with the correct password ? The interface UsersRepository has the method: "boolean addUser(User user)", the only reference to the user's data is an interface "User". In other implementations of UserRepository, it is done a cast to "DefaultUser" to use the method "getHashedPassword()" For example in org.apache.james.userrepository.DefaultUsersJdbcRepository#setUserForInsertStatement(User user, ...) DefaultUser defUser = (DefaultUser)user; ... userInsert.setString(3, defUser.getHashedPassword()); What do you think about to include the method "getHashedPassword()" in "User" interface ? Is it correct to do a cast to a class from an interface ? I think this generate a dependency between RemoteManager and Users Repositories then the interface "UserRepository" itsn't sufficient to determine the "contract" for the Users repository implementation. Is that correct ? Roberto.
CVS problems
Hi, I just did an update on my branch_2_1_fcs checkout and suddenly I got the file ../util/dbcp/JdbcDataSource which belongs to MAIN, and cannot compile using JDK 1.3 so I completely removed my checkout and did a new one, but the file in question keeps coming back. The CVS/Entries in dbcp reports: /JdbcDataSource.java/1.1.2.2/Thu Jul 24 01:45:58 2003//Tbranch_2_1_fcs so apparently it belongs to this branch, although looking at: http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james/util/ dbcp/?only_with_tag=branch_2_1_fcs says this is empty. Any suggestions what is happening Søren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: virtual hosting
Uwe Rosebrock wrote: Hi guys, I am new to the mailing-list (or rather back), I am currently adding some functionality to use James in a production environment. For that purpose I needed virtual hosting. Now I was wondering if you guys would be interested in that solution, very simple based on two db tables whereby a user account is mapped to any number of aliases. A db driven Matcher/Mailet pair does the work. The other issue I have got is that I like block certain ip addresses at the connection level, meaning that I like the SMTPHandler to refuse/close the connection if the address is in the 'drop' list. Does that sound feasible or would that generate to much overhead? On that note, why is everything in e.g. SMTPHandler/SMTPServer declared private, it makes it very difficult to extend efficiently? i guess you can solve these issues with my smtpacl + virtual domains patch http://www.ukrpost.net/research/james/maildir_acl_ldap_virtual_20040120.tar.gz Cheers Uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Was: SMTPACL
Serge Knystautas wrote:
I got the proposal for SMTPACL and generally think it's very sound. I
like the idea of using the mailet API, with certain restrictions.
There are two things I would suggest changing:
1. The name. ACL doesn't make sense as this isn't a list of anything.
This is specific to SMTP, and in fact I might make it a bit more
specific to SMTP...
2. The class/state structure. You need to be sure that both mailets AND
matchers are aware that this is during an SMTP transaction and we do not
have a MimeMessage. So I would do two changes:
why? you just supply Mail implementation to matcher and this Mail
implementation is dynamically initialized during smtp dialog.
think of the following:
you can get content of message only after server has sent data after
DATA command
you can get sender right after MAIL FROM command
so if you matcher operates on data but admin has put it after rcpt it
will just think mail has no content it wont break and it will be
compatible with mailet api.
the greatest advantage of such an architecture is compatibility with
mailet api. you dont have to rewrite _anything_ in you matchers to use
matchers in smtpacl. code reuse rules! :)
as for SMTPResult it is yet another abstract mailet again compatible
with mailet api. this type of mailets are handled by SMTPHandler during
smtp acl processing.
As for name (SMTPACL) this name was first mentioned in Exim mailer so i
decided to keep it anyway it _is_ a list (L) to control(C) access(A) to
services of SMTPHandler. But I'm open to name change if you think it is
wrong. For admins acl is a good hint. you have acls in cisco routers to
control who is allowed to connect to this or that service.
a. class-wise, make an interface (probably empty interface) that
declares that this matcher and mailet can be used in the tag,
i.e., they don't care about the MimeMessage.
b. state-wise, just use the existing state/errorMessage fields.
Instead of SMTPAccept, you just leave getState() as Mail.DEFAULT.
Instead of SMTPReject, you do setState(Mail.ERROR) and
setErrorMessage("550 cannot find MX for your domain").
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] Maildir + LDAP + SMTPACL + Virtual Domains
Noel J. Bergman wrote: Posting this for third time :) please just say you are not interested do not keep silent Alex, are you not receiving your e-mail? Or not subscribed to the James Developers List? He was cc'ed on a number of the messages. Besides which, I checked. ;-) --- Noel for some unknown reason i received everything from server-dev list except discussion of my patch if you are admin of mailing list or you know how to contact this person could you ask him to check if all posts are delievered to my domain (@ukrpost.net mx=may.priocom.com) i am an admin of my mail server so i checked logs if there were any rejections and it appears there wasnt. looks odd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
