Re: [VOTE] Release jsieve 0.4 (AGAIN)
[x] +1 Please release the artifacts -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: s...@widetrail.dk DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [VOTE] Release mailet-standard 1.0 (AGAIN)
[x] +1 Please release the artifacts -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: s...@widetrail.dk DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [VOTE] Add Hupa as subproject to JAMES
+1 On Friday 18 September 2009 09:58:20 Norman Maurer wrote: Hi all, just for to be safe I would start a VOTE about adding Hupa[1] as subproject to JAMES. So here we go.. [ ] +1 Yeah I would like to Hupa included it [ ] +0 I don't care to much [ ] -1 No I don't want to have it in JAMES Thx, Norman [1] http://svn.apache.org/repos/asf/labs/hupa - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: s...@widetrail.dk DK-8961 Allingåbro Web:www.widetrail.dk
Re: [VOTE] Introduce mailet-base product
+1 On the question to move in the direction of a mailet-building toolkit, I think that is a good idea. --Søren -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Thu, April 24, 2008 20:00, Robert Burrell Donkin wrote: JAMES 2.3.x contains mailet and mailet-api jars. the contents are now in http://svn.apache.org/repos/asf/james/mailet/api/trunk/. this means that clearly API classes such as Mailet are mixed in with clearly utility classes such as GenericMailet. it would be good to release 2.3.x improvements to these classes but IMO this needs to be sorted out first. we've talk before about whether a library for utility classes (in addition to standard-mailets) would be useful. i would like to propose introducing mailet-base to contain utility classes for the mailet-api. this would leave standard-mailets free for implementations and mailet-api free to contain just the API. i propose to judge each classes in http://svn.apache.org/repos/asf/james/mailet/api/trunk/ by it's merits so i don't want to propose contents at this stage just principle. here's my +1 - robert --8- [ ] +1 Create mailet-base [ ] +0 [ ] -0 [ ] -1 Do not create mailet-base --- - 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: [VOTE] jSPF-0.9.6
+0 -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Tue, March 25, 2008 11:17, Norman Maurer wrote: Hi dev-team, I finally found the time to prepare for next jSPF release... Fixed bugs and improvements can be found at: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310350fixfor=12312813 Packages can be found at: http://people.apache.org/~norman/staging-repository/org/apache/james/apache-jspf/0.9.6/ So please vote.. The VOTE will be closed on 23.03.08 11:00:00 CET 2008 VOTE: [ ] +1 Yes plz make this release official! [ ] +0 Cool to see the release [ ] -0 Anyway I don't care to much.. [ ] -1 No.. I don't want a new release for some reason! - 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: [VOTE] Mailet First Steps
--8--- [X] +1 Create product standard-mailets in mailet subproject --8- [X] +1 Create product crypto-mailets in mailet subproject --- - 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: [VOTE] Mailets - Mailet subproject
+1 -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Sun, March 2, 2008 21:59, Robert Burrell Donkin wrote: though the mailet API has been moved to the mailet subproject, mailet implementations are still contained in the server codebase. managing mailets as part of the mailet sub-project will allow releases to be made independent of the JAMES server, reduce the learning time required before developers can contribute, improve modularity in the JAMES core and allow libraries to be shared between different JAMES versions (allowing bugs to be fixed in one place). though some mailets are too tightly coupled to be moved immediately, others can be moved with no or minimal effort. some extra work will be required to produce a good website but these practicality can be resolved once consensus about the principle has been established. proposal -- establish the ideal that mailets should not depend on JAMES and should be managed within the mailet subproject rather than the server project. a home for mailets should be created within the mailet subproject and mailets gradually moved to it over time. here's my +1 - robert -- 8-- [ ] +1 Move Mailets to Mailet subproject [ ] +0 Sounds reasonable [ ] -0 Sounds unreasonable [ ] -1 Do not move Mailets to Mailet subproject - - 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: [VOTE] Jukka Zitting commit in trunk
+1 On Sunday 03 February 2008 01:09, Danny Angus wrote: Hi, I just want to get this recorded, Jukka is a commiter on this project but has agreed to limit his contribution to the sandbox. If you agree that Jukka's limited agreement to commit only to the sandbox be lifted and it be understood that Jukka is now trusted to commit wherever he feels appropriate please vote accordingly.. [ ] +1 I agree that Jukka should be allowed to commit anywhere in James codebase [ ] 0 I will abide by the majority decision [ ] -1 I disagree, the PMC should debate this case further. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] next-major from trunk will be 3.0
+1 I really think this next-minor/next-major stuff has added confusion. -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Tue, July 31, 2007 10:00, Robert Burrell Donkin wrote: trunk has been dubbed 'next-major' for a long time now. a lot of extra function has been added to trunk and though a full release is definitely a long way in the future, the time seems right now to decide that a future release from this code stream will be designated 3.0. dubbing trunk 3.0 does imply that if the 2.x code base requires a new major release then this will take the 4.0 designation. i have no problem with that contingency. here's my +1 i'll tally this vote no earlier than friday the 3rd of August 1200GMT - robert -- 8 [ ] +1 Dub trunk 'JAMES 3.0' [ ] +0 Sounds reasonable [ ] -0 Sounds unreasonable [ ] -1 Find another name -- - 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: JAMES technology uplift
On Thursday 03 May 2007 23:13, Steve Brewin wrote: snipped No, actually I did not believe I was :-) As I received this several time I guess you really must believe this :-) Sorry, about that my webmail acted up upon me :-( In truth, while the JCA spec. is somewhat opaque, implementations are not so hard. Its best learnt by looking at working example source code. Yeah, I have done one previously, and I believe that API is heavily over-engineered. But depending on what you try to implement, can often cut some corners, like only supporting MappedRecords for instance. I did not have the luxury of looking into existing adapters, guess I could not find any OSS ones (it was back in 2002-2003). As I've said before, this would be an excellent starting point for exposing James to the J2EE environment. Perhaps a summer of code '08 project could address exposing a small but useful set of James interfaces via a JCA such as mail injection and mailbox retrieval? Good idea! While this is orthagonal to the question of how we might 'uplift' the technology on which we build James, it would enable tighter integration. It would make James attractive as a email integration point in the SOA world. Agreed. --Søren Cheers -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES technology uplift
Hi, Well, just thinking, this being ASF. Shouldn't we eat our own dogfood, and go for Geronimo as our default deployment if/when we choose to take the EJB-container road? Also I might be wrong, but as we talk directly to the network, the authorized way to integrate into an EJB container is through a JCA adapter, and they are kind of beastly to implement :-) --Søren -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Thu, May 3, 2007 08:46, Danny Angus wrote: On 5/3/07, David Blevins [EMAIL PROTECTED] wrote: Just an FYI, OpenEJB is extremely non-intrusive and it's very easy to use as just a library in various ways. I hadn't really thought of that, I know Noel had mentioned OpenEJB, but I couldn't figure out why, and I used it years ago so I should have remembered. I'm still not sure exactly where we should go with all this, but it was worth reminding us. Thanks. d. - 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: JAMES technology uplift
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote: On 5/3/07, Søren Hilmer [EMAIL PROTECTED] wrote: Hi, Well, just thinking, this being ASF. Shouldn't we eat our own dogfood, and go for Geronimo as our default deployment if/when we choose to take the EJB-container road? I'd rather be able to deploy to Geronimo _and_ other containers. OpenEJB by the way is Geronimo's standard EJB container and currently applying for becoming top-level ASF. Was not aware of that, thanks for the info! Also I might be wrong, but as we talk directly to the network, the authorized way to integrate into an EJB container is through a JCA adapter, and they are kind of beastly to implement :-) Unfortunately, you aren't wrong :-) No, actually I did not believe I was :-) Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES technology uplift
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote: On 5/3/07, Søren Hilmer [EMAIL PROTECTED] wrote: Hi, Well, just thinking, this being ASF. Shouldn't we eat our own dogfood, and go for Geronimo as our default deployment if/when we choose to take the EJB-container road? I'd rather be able to deploy to Geronimo _and_ other containers. OpenEJB by the way is Geronimo's standard EJB container and currently applying for becoming top-level ASF. Was not aware of that, thanks for the info! Also I might be wrong, but as we talk directly to the network, the authorized way to integrate into an EJB container is through a JCA adapter, and they are kind of beastly to implement :-) Unfortunately, you aren't wrong :-) No, actually I did not believe I was :-) Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES technology uplift
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote: On 5/3/07, Søren Hilmer [EMAIL PROTECTED] wrote: Hi, Well, just thinking, this being ASF. Shouldn't we eat our own dogfood, and go for Geronimo as our default deployment if/when we choose to take the EJB-container road? I'd rather be able to deploy to Geronimo _and_ other containers. OpenEJB by the way is Geronimo's standard EJB container and currently applying for becoming top-level ASF. Was not aware of that, thanks for the info! Also I might be wrong, but as we talk directly to the network, the authorized way to integrate into an EJB container is through a JCA adapter, and they are kind of beastly to implement :-) Unfortunately, you aren't wrong :-) No, actually I did not believe I was :-) Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES technology uplift
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote: On 5/3/07, Søren Hilmer [EMAIL PROTECTED] wrote: Hi, Well, just thinking, this being ASF. Shouldn't we eat our own dogfood, and go for Geronimo as our default deployment if/when we choose to take the EJB-container road? I'd rather be able to deploy to Geronimo _and_ other containers. OpenEJB by the way is Geronimo's standard EJB container and currently applying for becoming top-level ASF. Was not aware of that, thanks for the info! Also I might be wrong, but as we talk directly to the network, the authorized way to integrate into an EJB container is through a JCA adapter, and they are kind of beastly to implement :-) Unfortunately, you aren't wrong :-) No, actually I did not believe I was :-) Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES technology uplift
On Thu, May 3, 2007 11:40, Bernd Fondermann wrote: On 5/3/07, Søren Hilmer [EMAIL PROTECTED] wrote: Hi, Well, just thinking, this being ASF. Shouldn't we eat our own dogfood, and go for Geronimo as our default deployment if/when we choose to take the EJB-container road? I'd rather be able to deploy to Geronimo _and_ other containers. OpenEJB by the way is Geronimo's standard EJB container and currently applying for becoming top-level ASF. Was not aware of that, thanks for the info! Also I might be wrong, but as we talk directly to the network, the authorized way to integrate into an EJB container is through a JCA adapter, and they are kind of beastly to implement :-) Unfortunately, you aren't wrong :-) No, actually I did not believe I was :-) Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES technology uplift
On Thu, May 3, 2007 11:48, Ahmed Mohombe wrote: Well, just thinking, this being ASF. Shouldn't we eat our own dogfood... If that would be so, than the entire ASF messaging infrastructure should run on JAMES in *first* place, including newsgroups and mailing lists (and this since years) :). He he, good one! Also, AFAIK the Geronimo food has a strong Maven taste :). Uhmm, yes and that is good tasting food IMO. Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jukka Zitting Committer Karma
+1 -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Wed, May 2, 2007 11:23, Noel J. Bergman wrote: Jukka Zitting, JackRabbit Committer PMC Chair, has volunteered to help work on a Proof of Concept related to the use of JCR as our unified data store. The proof of concept will start by focusing on the modelling of the data in JCR, and will build from the JCR side out, not start with existing JAMES code at all. The work should be done in our SVN, hence the need for karma. +1 from me. --- Noel - 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: [VOTE] JAMES 2.3.1 (final)
+0 -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Wed, April 25, 2007 17:02, Norman Maurer wrote: Hi all, its me again :-P If we want to get JAMES 2.3.1 out of the door before ApacheCon EU we have to VOTE now. So here it is... You can grab the builds from: http://people.apache.org/~norman/james/downloads Please test and review ;-) This VOTE will be closed at 2007-04-29 12:00:00 GMT bye Norman - 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: [RESULT] [VOTE] JAMES 2.3.1RC1
Hi, I do not think the accidental VOTE I made from my wife's account should be tallied ;-) --Søren -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Thu, April 19, 2007 08:28, Norman Maurer wrote: Hi all, the VOTE for JAMES-2.3.1RC1 is closed. Here is the result: +1 4x (Norman, Stefano, Vincenzo, Danny) +0 3x (Bernd, Serge, Joan, Søren) -0 0x -1 0x So we have four binding VOTES with +1. Time to release ;-) I will take care of moving the build to the dist folder. bye Norman - 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: [VOTE] JAMES 2.3.1RC1
Ups forgot I was on my wife's account. Still +0 though; I have not had time to test it. -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Tue, April 10, 2007 14:10, Norman Maurer wrote: Hi guys, after noone replied to my question about 2.3.1rc1 I dediced to moved forward to start a vote (to much time allready lost). So please download,test and vote ;-) A list of changes can be found here: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10411fixfor=12312150 You can grab it from: http://people.apache.org/~norman/james/downloads bye Norman Ps: I hope it was ok to just move forward - 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: ApacheCon EU, May 2-5
Sorry, I cannot make it. Very unfortunate especially given the great comitter discount this year. --Søren -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Thu, February 22, 2007 15:54, Noel J. Bergman wrote: Who will be there? I am hoping to see everyone. That means you: Norman, Danny, Robert, Stefano, Vincenzo, Bernd, Steve, Soren, et al. Serge, if you can make it, that'd be great. It should be a good community experience for us. ApacheCon is May 2-5, Tuesday-Friday. The formal hack-a-thon is on May 2. May 1 is a *huge* Dutch party (Queen's Day) in Amsterdam. We can also meet in rooms on May 1 to do any hacking when people are partied out. --- Noel - 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: [VOTE] Apply JAMES-358 patch (singleIPperMX option)
+1 (but It should not be a default, the current behaviour is like the RFC says, and our default should mirror that) --Søren On Friday 14 July 2006 16:14, Stefano Bagnara wrote: I'm sorry for another vote today, but I found the time only today to collect enough informations to proceed. The vote is to apply the patch attached to http://issues.apache.org/jira/browse/JAMES-358 (Ok, i will fix tabs to spaces if this get a +1) Vincenzo, Bernd, Norman and I already agreed we should apply it, but Noel expressed in a comment I disagree with this patch... and maybe even Danny had something to say. So I decided for a vote because this is there from too much time. The patch introduce a new *optional* value for the dnsserver that make it to only return a single IP for each MX server (even if it is multihomed) when resolving mail servers for a domain. Without this patch I was unable to send 10 mails per day (or similar volumes). As a reference about previous discussions you can read: 1) JIRA Comments: http://issues.apache.org/jira/browse/JAMES-358 2) Thread: [EMAIL PROTECTED] 3) Thread: [EMAIL PROTECTED] Stefano PS: I even think this should be the default, but this vote is not to make it the default, only to add it as an option. PS2: If you have better ideas for the configuration option name singleIPperMX is not so good, so any better idea is welcome! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] James website update (Was: svn commit: r421896 - in /james/site/trunk/www)
+1 On Friday 14 July 2006 15:26, Stefano Bagnara wrote: This time a real, official, standard vote. Normally I wouldn't call a vote for a site update, but I just finished committing more than *1000* files updated in our site/trunk repository. As you can see from the funny comment about the 261 parts it changed almost all the website. I published an export of the updated site here: http://people.apache.org/~bago/james/www/ http://people.apache.org/~bago/james/www/jspf/ Main changes: 1) Added jspf website 2) Changed the left column to include 2.3b documentation 3) Added all the latest documentation under 2.3 submenus (mainly updated by Norman, more to be done) 4) Removed few very old files no more linked. 5) Updated mailets API and James javadoc to 2.3.0b3: the one previously online was related to an old 3.0 trunk that has never really been published (it had repositories in Mailet APIs). It was so bad to have javadocs for an unsupported apis that I decided it was better to put 2.3b without not many discussions about putting 2.2.0 or anything else. A +1 will mean I will leave the code in the current trunk and I will run an update on minotaur to publish the changes. If you cast a -1 please let me know if you are simply against the publishing of the updated website or if you want me to revert the commit. This is far from perfect, but I think it is better than before, so let's publish this, and them we can tune it with further changes (maybe with no need to vote at each one). The commit log explain how I generated the files I committed. Stefano [EMAIL PROTECTED] wrote: Author: bago Date: Fri Jul 14 06:05:56 2006 New Revision: 421896 URL: http://svn.apache.org/viewvc?rev=421896view=rev Log: Update full website to include jspf and 2.3 things. 1) ant website from james/server/trunk root. 2) replaced 2.2.0 with 2.3.0 in download.xml 3) mvn site from james/jspf/trunk root. 4) copied jspf/target/site to site root/jspf 5) fixcrlf on all the html files under www [This commit notification would consist of 261 parts, which exceeds the limit of 50 ones, so it was shortened to the summary.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 opinions
Hi Stefano, Just to be sure I understood your comment when you say POM you mean the SDL ? Well, now you got me :-) What do you mean by SDL? By POM I mean Project Object Model, to me that is more than the pom.xml. But the model or layout of the project as such. And Maven have a preferred way to do that, and following that way makes it alot easier to use Maven IMO. If I understood your message you are +1 to change our current layout to match the default maven2 layout and have a simple pom.xml because we refactor our repository to match the maven2 standard. Exactly! You are instead -1 to introduce maven2 as a complicate pom.xml that override every default to match our current build model. Again exactly my view. I believe that if you go the Maven way, you go it all the way! --Søren Is this correct or is this the opposite of your thought? Stefano PS: I think that SDL (Standard Directory Layout) is one of the best thing introduced by the maven project. When I look to new projects using the SDL I feel home, I understand much more thing at a glance than what I understand from non SDL projects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 opinions
I am a +1 for Maven. I believe that Maven greatly simplifies build, test, documentation. Of course you have to buy it's POM, but I do not consider that to be a major drawback, since it is close to what we got and is well designed. It is my opinion that if you try to bend your own POM to Maven instead of adopting Maven's POM you are in for a bumpy ride, and in that case I would be -1 on the subject. --Søren On Wednesday 24 May 2006 11:58, Stefano Bagnara wrote: I was writing this to ask Noel for some more explanations about why he doesn't like Maven2, but I'd like to know the opinion of all committers about this. What is your opinion about switching our build system to maven2 ? I'm +0.5 for the following reasons: 1. using a standard directory layout simplify the use of third party tools 2. At least Eclipse and maybe even IDEA and NetBeans have a maven2 plugin that simplify the import/configuration of a maven2 project. 3. We can try to remove libraries from our repository 4. It will allow us to split James in subprojects: mailet-api, mailet-impl, core, smtp, pop3, nntp, fetchmail, mailets, spoolmanager having well-defined dependencies between modules. This will improve the self-documentation provided by james sourcecode (it makes much more clear the modules and the dependencies) and maybe a step towards OSGi bundles. 5. It simplify the integration in continuous integrations environments. 6. It should be easier to create a website integrating James Server and our subprojects (jSPF, jSieve, Mime4J, Postage). I know we can achieve some of the tasks even not using Maven2: in this case I would like to know what you propose as an alternative. About the website skin if anyone does not like the maven2 default skins: Stylus: http://maven.apache.org/ Default: http://www.mime4j.org/ We can even write our own skin to match as close as possible the current james style. I would also like to know what is the opinion about the usage of the Standard Directory Layout (http://maven.apache.org/guides/introduction/introduction-to-the-standard-d irectory-layout.html) and the splitting of James in modules. Can we do the latter without switching to Maven2 ? Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Create jSPF project
+1 -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Create jSPF project
+1 -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (JAMES-451) Check for valid domain in HELO
Hi, I tested such issues using a separate DNS server which returned localhost for the domains i tested. I used Jnamed from dnsjava for this. --Søren On Sunday 26 March 2006 21:35, Norman Maurer wrote: Just start to write a junit test for this,, Now i notice a problem .. The method helo(InetAddress) in SMTPProtocol needs a InetAddress but i need to test it with not resolvable domains. So if i do a InetAddress.getHostbyName(egjoerg.de); an exception is thrown before pass this to the HeloCmdHandler.. So i need to create an own witch extends the one which is used now.. Or there are any other solutions ? bye Am Sonntag, den 26.03.2006, 19:22 +0100 schrieb Norman Maurer (JIRA): [ http://issues.apache.org/jira/browse/JAMES-451?page=all ] Norman Maurer updated JAMES-451: Attachment: helo-v2.patch -fix the bug that stefano reported -update james-config.xml TODO: Add junit test. Check for valid domain in HELO -- Key: JAMES-451 URL: http://issues.apache.org/jira/browse/JAMES-451 Project: James Type: Wish Components: SMTPServer Reporter: Norman Maurer Assignee: Stefano Bagnara Attachments: helo-v2.patch, helo.patch IT would be nice to let /james-dev/src/java/org/apache/james/smtpserver/HeloCmdHandler.java to accept an init parameter for specify that the helo value must be an resolvable domainname. In RFC HELO names should always a valid domainname. -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web:www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] James 2.3.0a1
+1 -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Fri, February 10, 2006 06:21, Noel J. Bergman wrote: I tagged it: http://svn.apache.org/viewcvs?rev=376553view=rev, and it is the current nightly build. I have also uploaded it to people.apache.org/~noel/james for review. --- Noel - 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: Secure mailing list using S/MIME
Hi Noel, This is really in my ball-game, and a very interesting scenario. Unfortunately my time is a bit sparse, after leaving my secure job and starting as an independant consultant. Do you know if any standard exists for such a scheme? --Søren -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Wed, January 4, 2006 05:11, Noel J. Bergman wrote: For key management, I could see something like: - A keypair is provided to the MLM for each mailing list - During the subscribe request handshake, the user would sign the subscription request. - The MLM would verify that the signature matches the e-mail address associated with the request, sign and encrypt a confirmation request, and send it to the requested address. - The user would send a signed and encypted confirmation. - The MLM would subscribe the user and public key, and send an encrypted confirmation. Thereafter, the sender would send encrypted and/or signed messages, depending upon list policy, and the list would be able to send encrypted messages to each user. This would provide privacy of content and prevent address spoofing, both for senders and recipients. --- Noel - 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: Secure mailing list using S/MIME
On Wed, January 4, 2006 10:27, Stefano Bagnara wrote: Noel J. Bergman wrote: For key management, I could see something like: A more genereric approach to secure email would be the following: - Every time james receive a signed message it store the public key in a keystore (if not already existing). and replacing if the certificate in the store has expired or otherwise become invalid (e.g. placed on a CRL list) - Every time james send a message should check in the keystore to find out wether it contains the public key and if found encrypt the message. If the stored certificate is still valid an not on a CRL? Otherwise the mail should bounce with a message of that fact. If the message is sent to multiple receivers, this is further complicated as a decission has to be made on the bouncing/delivery rules: a) always send mail even if it cannot be encrypted to every recipient b) do not send to anyone if it cannot be encrypted to everyone c) send to those we can encrypt to bounce for rest. Different organisations will have opinions on this, trust me! This would add automatic transparent secure messaging to users signing their messages. One further step would be to automatically generate new certificates for authenticated users and automatically sign every outgoing message and decrypt any incoming message: this way the users would continue to use plain email but with added security. This is exactly the way we used James in my previous position at TietoEnator , they have ~250 customers on this solution (banks, ministries, ...) (only the authenticated users certificates where issued by a CA and placed on the James server). And while the concept is easy a lot of business logic quickly comes into play. End users wish to only sometimes encrypt/sign outgoing based on subtle rules (markings in Subject, headers, sender,...) --Søren Stefano - 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: Status, Release Candidates and Derby
I am on par with Stefano regarding the number scheme, and also on a beta release before a RC release. IMO we should save 3.0 for the more drastic upcomming changes, and continue with 2.3.0 for this release. --Søren -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Thu, December 15, 2005 11:20, Stefano Bagnara wrote: Noel J. Bergman wrote: Would people take a look at the current code and see if they feel comfortable with a release candidate? Unless I encounter a definitive memory leak or other problem, I'd like to call a vote on a release candidate. And since there are both configuration and functional changes, I'd suggest that v3 is perhaps the more appropriate designation than v2.3. I would better like a a 2.3b1 or 3.0b1 (beta release) before the 3.0rc1. I'm not sure James is ready for release candidate: changes I've done in the past months need to be tested by a wider audience to understand wether the users understand them or we need to change some behaviour. Furthermore, I think that we could change our opinion (I hope it doesn't happen but i'm not sure) about the default configuration (for mail stores, or anything else) after a beta cycle and I would not be happy to change similar thing in release candidate cycles. Anyway I'm +1 for the release, soon! About the version numbers I'm +1 for a 2.3.0 and +0 for 3.0. We didn't publish a numbering rule, so it's a personal feeling. I like the 2.3.0 because current trunk has less changes than the 2.1 to 2.2 step and it's not a revolution. I would prefer to keep the 3.0 for the next generation (pojo, different container, different configuration style, much different behaviours). My preference is for an early 2.3.0 release and a fast move to the 3.0. 2.3.0 (current trunk) fixes a lot of bugs from 2.2.0 and is a due upgrade. Stefano - 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: Regarding BUG 24885: RemoteDelivery only tries one of multiple A record
to
main().
* But if args is left empty then a hardcoded list of names will be
tested.
* For each domain name given, this lists each hostname and then each
* InetAddress for each hostname. Thus it shows the entire
sequence of
* InetAddresses which may be tried for the given domain.
*/
public static void main(String[] args) throws UnknownHostException{
if(args.length == 0){ //if args have not been given, set some
names to test
String[] newArgs = {nc.rr.com,\r^Illegal.characters,
mailscreen.net,aol.com,
rockland.com,mindspring.com,mx02.mindspring.com.,,
mx2.mail.yahoo.com, IMpossible.domain-3, hotmail.com};
args = newArgs;
}
DNSServer dnsServer = new DNSServer();
for (int domainIndex = 0; domainIndex args.length; domainIndex++){
String domainName = args[domainIndex];
System.out.println(Results for domain + domainName);
Enumeration hostsForDomain =
dnsServer.getSMTPHostAddresses(domainName);
int hostCount = 0;
while (hostsForDomain.hasMoreElements()){
SMTPHostAddresses thisHost =
(SMTPHostAddresses)hostsForDomain.nextElement();
System.out.print(thisHost.getHostname());
InetAddress[] addresses = thisHost.getAddresses();
for (int addressIndex = 0; addressIndex addresses.length;
addressIndex++){
System.out.print( + addresses[addressIndex].toString());
}
System.out.println();
hostCount++;
}
System.out.println(Done, found + hostCount + hosts.\n);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Søren Hilmer, M.Sc.
RD manager Phone: +45 70 27 64 00
TietoEnator IT+ Fax:+45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 64 57
DK-8230 Åbyhøj Email: soren.hilmer at tietoenator.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding BUG 24885: RemoteDelivery only tries one of multiple A record
On Saturday 06 December 2003 00:22, Richard O. Hammer wrote: Noel J. Bergman wrote: Søren Hilmer wrote: ... So it is handling a multihomed destination that needs to be addressed. I want to make sure I understand this issue. I've put some debugging statements into org.apache.james.dnsserver.DNSServer, which print out Record.toString() in places of interest. Today, when I call findMXRecords(yahoo.com), the subsequent lookup(yahoo.com, Type.MX); returns the following three records, shown here before they are sorted for priority order. yahoo.com. 2320 IN MX 1 mx2.mail.yahoo.com. yahoo.com. 2320 IN MX 5 mx4.mail.yahoo.com. yahoo.com. 2320 IN MX 1 mx1.mail.yahoo.com. The problem being discussed here is that host mx2.mail.yahoo.com. may exist at several IP addresses (i.e., that a subsequent lookup of mx2.mail.yahoo.com. may produce several A records.)(?) Yes, mx2.mail.yahoo.com can have sevearl A records. So that if, after sorting for priorities, we decide to connect to mx2.mail.yahoo.com. , then we need to try each of the IP addresses for mx2.mail.yahoo.com. before we go on to try the next host-name in our priority ordering (which would be mx1.mail.yahoo.com.) Is that the problem? Yes, taht is the problem, now only one of the returned A-rcords for mx2.mail.yahoo.com is tried. Do we know for sure that the JavaMail code underlying the call: transport = session.getTransport(urlname); (in method RemoteDelivery.deliver(Mail, Session)) does not do this for us? My tests shows that JavaMail does not handle it, but I hope to be proven wrong. Do you have an example, Søren, of a MX host which you know has multiple A records, so that I can test with it? Yes, hotmail.com returns this for is MX records: hotmail.com.274 IN MX 5 mx2.hotmail.com. hotmail.com.274 IN MX 5 mx3.hotmail.com. hotmail.com.274 IN MX 5 mx4.hotmail.com. hotmail.com.274 IN MX 5 mx1.hotmail.com. A lookup of mx2.hotmail.com's A records get you: mx2.hotmail.com.3017IN A 65.54.254.145 mx2.hotmail.com.3017IN A 65.54.166.230 mx2.hotmail.com.3017IN A 65.54.252.230 The return is a Collection of String objects. Each one is currently of the form host, but if we were to handle multi-homed hosts by using host/IP, it seems to me that we could either parse it directly ... I guess this may require an additional call to the underlying DNSServer.rawDNSLookup(), because I don't think DNSServer.findMXRecords() ever has the redundant A records. This is interesting -- but with my ignorance of DNS I am just guessing. Yes, rawDNSLookup needs to be called twice. I am adding a DNSServer.findARecords method to do it (basically a copy/paste of findMXRecords). -Søren -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer at tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
private vs. protected access
Hi, I propose the following change(s). Mainly for the supplied matchers and mailets I would like to reconsider having instance variables and methods being of private access and move promote them to protected access. Lets take Andreas' DSNBounce as an example of what I am suggesting. Now to make this Andreas had to make a change to RemoteDelivery failMessage, but failMessage has private access, so Andreas have had to make his own copy of RemoteDelivery to make this change, now when RemoteDelivery for some reason changes in James, he will have to get this new version and patch in his changes (major inconvenience). Now had failMessage had protected access, he could just have inherited from RemoteDelivery and overridden failMesssage, voila. The same goes for a lot of the instance variables, when they are private you cannot get to them in subclasses (and usually there are no protected set/get access methods as well) and it evidently leads to copy paste coding, which I consider bad. As the situation is now, a lot of the mailets/matchers could just as well have been declared final. I won't mind doing the grunt work on this one. --Søren -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] RemoteDelivery support for multiple delayTimes
On Friday 24 October 2003 21:47, Noel J. Bergman wrote: Søren, We might do some further tweaking, but I think you've got the right idea. The thought I have is that (down the road) some code might want to accept messages based upon other criteria, so we might want to enlarge upon our options there, possibly by using introspection. A few minor items: (1) Could you submit against branch_2_1_fcs? Yep, will do that. (2) The spool is purely internal. Let's chance accept() to return the message. Okay, I guess you want this for all three accepts. (3) Please see GenericRegexMatcher.java for correct usage of the regex code in a multithreaded environment. We need to compile as READ-ONLY, and create a matcher in the executing thread. But is the regex done from muliple threads? Only if init() can be called from multiple threads, and at initialization time we are not particularly pressed by performance issues, so I did a synchronized (MATCHER) in the Delay constructor. But I have no problem doing it the other way. I also discovered a minor mistake in my patch, as the new accept method implementation in JDBCSpoolRepository does not enforce the minimum delay set by WAIT_LIMIT, will fix that as well. Expect a new patch tomorrow. --Søren I'd like to get this change included in our next release. The spooler has never been exposed to anyone, and there are only two calls in the codebase. The James code didn't follow the correct usage pattern for regex previously, but it is documented by the regex classes, as I discovered when trying to do some other things with them. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationale behind explicit setLastUpdated in MailImpl writeobject sought.
I can see, why you wish to keep lastUpdated as the time the mail was actually put in the spool for diagnostic purposes. I was hoping to keep the changes local to RemoteDelivery, but this boils down to that not being possible. So I will start working on Spool.Filter and Spool.TimeFilter. and accept (Filter); But let be just be sure this is what you mean: Spool.accept(TimeFilter) will consult the supplied TimeFilter with the mail as input, which in turn uses the lastUpdated time of the Mail and its current retrycount (which exists in the errormessage), and based on these it determines if the Mail is ready for retry. This is quite elegant IMO as the concrete TimeFilter implementation can reside in RemoteDelivery, so the misuse of the errormessage for the retrycount is localized in RemoteDelivery. And it requires minimal changes to Spool. --Søren On Thursday 23 October 2003 00:19, Noel J. Bergman wrote: Mind you, I'd also like to see Spool.accept() return the message, not the key. There are exactly two calls to Spool.accept()/accept(long) in James. In both cases, we immediately follow up by retrieving the message, but we have a much more complex synchronization process because of the two stage access method. Agreed. But to address the fundamental challenge, I would say this is a good use of mail attributes. Sounds like we would need to provide a query interface on the repository for this, but really you want to set a date on the mail that is not last updated, but independent of any data we store right now. I had thought of that, but it would mean that: (a) scheduling would only work on systems with attributes enabled (b) scheduling would require reading the attributes, too. We already have the lastUpdate time. We can easily add the retry count to the same query, which we'll want, anyway. From that, we can compute the delivery time. What we could do is establish something like: Spool.accept(Filter filter) Spool.Filter would be an static inner interface of the Spool interface, so we tie the concepts. If we have a Spool.TimeFilter interface, we could check for that interface, which just tells us that all we need are the time and retry count. Then we can call it, perhaps TimeFilter.accept(long time, int retries) to see if the current pending message is suitable. I dislike the lack of polymorphism, but the JDBC Spool uses a very lightweight object that isn't a full MailImpl. Anyhow, that's an idea. Seems like something useful (and reusable) there if we tweak it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationale behind explicit setLastUpdated in MailImpl writeobject sought.
Ahh, now I fully understand Noels comments. I started doing accept(Filter) in JDBCSpoolRepository and we do not have complete MaiImpl's in there and even the misused errormessage is not in PendingMessage. But as it is in the underlying db I will just change the sql query and PendingMessage. I am beginning to understand why this hasn't been done before. --Søren On Thursday 23 October 2003 08:42, Søren Hilmer wrote: I can see, why you wish to keep lastUpdated as the time the mail was actually put in the spool for diagnostic purposes. I was hoping to keep the changes local to RemoteDelivery, but this boils down to that not being possible. So I will start working on Spool.Filter and Spool.TimeFilter. and accept (Filter); But let be just be sure this is what you mean: Spool.accept(TimeFilter) will consult the supplied TimeFilter with the mail as input, which in turn uses the lastUpdated time of the Mail and its current retrycount (which exists in the errormessage), and based on these it determines if the Mail is ready for retry. This is quite elegant IMO as the concrete TimeFilter implementation can reside in RemoteDelivery, so the misuse of the errormessage for the retrycount is localized in RemoteDelivery. And it requires minimal changes to Spool. --Søren On Thursday 23 October 2003 00:19, Noel J. Bergman wrote: Mind you, I'd also like to see Spool.accept() return the message, not the key. There are exactly two calls to Spool.accept()/accept(long) in James. In both cases, we immediately follow up by retrieving the message, but we have a much more complex synchronization process because of the two stage access method. Agreed. But to address the fundamental challenge, I would say this is a good use of mail attributes. Sounds like we would need to provide a query interface on the repository for this, but really you want to set a date on the mail that is not last updated, but independent of any data we store right now. I had thought of that, but it would mean that: (a) scheduling would only work on systems with attributes enabled (b) scheduling would require reading the attributes, too. We already have the lastUpdate time. We can easily add the retry count to the same query, which we'll want, anyway. From that, we can compute the delivery time. What we could do is establish something like: Spool.accept(Filter filter) Spool.Filter would be an static inner interface of the Spool interface, so we tie the concepts. If we have a Spool.TimeFilter interface, we could check for that interface, which just tells us that all we need are the time and retry count. Then we can call it, perhaps TimeFilter.accept(long time, int retries) to see if the current pending message is suitable. I dislike the lack of polymorphism, but the JDBC Spool uses a very lightweight object that isn't a full MailImpl. Anyhow, that's an idea. Seems like something useful (and reusable) there if we tweak it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rationale behind explicit setLastUpdated in MailImpl writeobject sought.
Hi, During my implementation the multiple delay times in RemoteDelivery, I have run into a little problem. My idea was to always do an outgoing.accept(0) and set the Mails lastUpdated to currentTimeMillis+the next delay for that mail- But alas in MailImpl.writeObject always does a lastUpdated=new Date() prior to the actual storing of the object, which effectly prevents me from dating the mail into the future. What is the rationale behind this? Does it actually make sense to have a setLastUpdated method, when the effect of it is changed behind your back? -Søren -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
