Re: Configuration Subsystem (was Mailet Configuration)
Serge Knystautas wrote: - Original Message - From: Aaron Knauf [EMAIL PROTECTED] Hi Danny, The format you suggest certainly allows for multiple matchers and better matcher configuration. However, it still leaves us with unstructured name/value pairs. There have been a number of requests for structured mailet configuration. I don't think the level of configuration you're proposing needs to be included as part of the mailet container. IMO, the container should load an application, and if the application has complex configuration, the application should handle configuring itself. I think many of your suggestions unnecessarily raise the bar for mailet container implementations and is looking for more than just a container. I disagree, but rather than go into the why's and wherefore's here, I will finish off the UML that I am working on to ensure that we are not just misunderstanding each other. I will however, say this: I think that access to some form of structured config for mailets is important. Plugability of config implementations is not something that needs to be reflected directly in the Mailet API, but can be a value add for a particular container implementation. (Like ours!) Dynamic reconfiguration must be supported by the configuration subsystem if it is to exist at all. Someone listed this item on the wiki as being a desirable for V3. It is quite a lot simpler not to do it. IMHO, the key to doing this successfully is to provide a system that is simple by default, but powerful for those that wish to put in the effort and dig a little deeper. Log4J is an excellent example of this concept. It takes a 4 line config file and single line of code to get basic logging to work. However, if you want more, you can make your logs get up and make coffee! Cheers ADK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] v2.1.1 release[spam 0.308]
As I've not been directly involved in the changes +0 from me. -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] Sent: 28 January 2003 23:02 To: James Developers List Subject: RE: [VOTE] v2.1.1 release[spam 0.308] (again IMHO) Votes for releases should still be made by that sub-project's community/contributors, ergo on the appropriate dev list. Fine with me. Trying to have one right now. LOL --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration Subsystem (was Mailet Configuration)
Aaron Knauf wrote: I disagree, but rather than go into the why's and wherefore's here, I will finish off the UML that I am working on to ensure that we are not just misunderstanding each other. I will however, say this: I think that access to some form of structured config for mailets is important. Plugability of config implementations is not something that needs to be reflected directly in the Mailet API, but can be a value add for a particular container implementation. (Like ours!) Ok sure, just as long as it's not in the mailet API or specification, that's cool with me. Dynamic reconfiguration must be supported by the configuration subsystem if it is to exist at all. Someone listed this item on the wiki as being a desirable for V3. It is quite a lot simpler not to do it. Yes, I think dynamic reconfiguration is a must. IMHO, the key to doing this successfully is to provide a system that is simple by default, but powerful for those that wish to put in the effort and dig a little deeper. Log4J is an excellent example of this concept. It takes a 4 line config file and single line of code to get basic logging to work. However, if you want more, you can make your logs get up and make coffee! I agree, and I think your log4j reference is a good example of what I'm shooting for... let the application developer do whatever he or she wants using all the options available with Java. I'm just looking to provide rules for a mailet container, i.e., how you could write some Java to process email messages. This doesn't need to (and shouldn't IMHO) include much about logging, databases, configuration, etc... So I like to keep it lightweight and focused on the specific problem of email processing. Also when in doubt about the appropriate level of complexity, I tend to fall back on whatever the servlet API deemed appropriate. Servlet apps haven't shown much limitations with that API (either too advanced or too lightweight), and it's fostered numerous implementations. So for the sake of Mailet API and specification, if in doubt, leave it out. Then figure out a way how a specific mailet container like James could offer the necessary features on its own. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Problem with font size on James website and documentation
-- Forwarded Message From: Rodent of Unusual Size [EMAIL PROTECTED] Organization: The Apache Software Foundation Date: Wed, 29 Jan 2003 11:32:55 -0500 To: [EMAIL PROTECTED] Subject: Re: Problem with font size on James website and documentation this brings up a very very valid point. our sites need to be concerned with accessibility. acked. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -- End of Forwarded Message ---BeginMessage--- Webmaster: could you please forward this to the person who maintains the James web site and documentation? I couldn't find the address. Thanks. Hi. I just wanted to point out that I cannot read the James web site nor can I read the James documentation. The reason is that in your style sheet you are using hard-coded font sizes rather than using relative declarations such as: font-size: 1.0em font-size: 100% font-size: x-small Please consider using these instead of pixels or points. The reason is that I have poor vision. Therefore, I have to set the default font size in my browser to 20 points. Since your style sheet doesn't respect that I quite literally cannot read much of anything in your documentation or web site. It's simply too small. This could be a big usability issue for other people, too. Jakob Nielsen even listed this as one of the top web design mistakes of 2002 (see #4: http://www.useit.com/alertbox/20021223.html) I hope you'll consider changing your style sheet so that your web site and documentation will be accessible to all users, not just those users with perfect eyesight. Thanks for your time. -- Matt Perry | matt at primefactor dot com ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with font size on James website and documentation
This came in across infrastructure@. Looks like our .xsl files are introducing a LINK pointing to /stylesheet.css, and that is introducing the problem. I'll fix the CSS file for now, unless Danny gets to it first [Danny, send me a quick note if you're going to do it]. This needs to be kept in mind regarding whatever change we make regarding the use of Maven or Forrest. I'll send a thank you to the Matt Perry after confirming that the fix takes. --- Noel -Original Message- From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 11:33 To: [EMAIL PROTECTED] Subject: Re: Problem with font size on James website and documentation this brings up a very very valid point. our sites need to be concerned with accessibility. acked. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -- Attached Message - From: Matt Perry [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 11:20 To: [EMAIL PROTECTED] Subject: Problem with font size on James website and documentation Webmaster: could you please forward this to the person who maintains the James web site and documentation? I couldn't find the address. Thanks. Hi. I just wanted to point out that I cannot read the James web site nor can I read the James documentation. The reason is that in your style sheet you are using hard-coded font sizes rather than using relative declarations such as: font-size: 1.0em font-size: 100% font-size: x-small Please consider using these instead of pixels or points. The reason is that I have poor vision. Therefore, I have to set the default font size in my browser to 20 points. Since your style sheet doesn't respect that I quite literally cannot read much of anything in your documentation or web site. It's simply too small. This could be a big usability issue for other people, too. Jakob Nielsen even listed this as one of the top web design mistakes of 2002 (see #4: http://www.useit.com/alertbox/20021223.html) I hope you'll consider changing your style sheet so that your web site and documentation will be accessible to all users, not just those users with perfect eyesight. Thanks for your time. -- Matt Perry | matt at primefactor dot com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-james/src/xdocs stylesheet.css
noel2003/01/29 10:29:40
Modified:src/xdocs stylesheet.css
Log:
Changed font size from pixel size to keyword
Revision ChangesPath
1.2 +3 -3 jakarta-james/src/xdocs/stylesheet.css
Index: stylesheet.css
===
RCS file: /home/cvs/jakarta-james/src/xdocs/stylesheet.css,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- stylesheet.css30 Jul 2002 13:37:34 - 1.1
+++ stylesheet.css29 Jan 2003 18:29:40 - 1.2
@@ -1,5 +1,5 @@
-body { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10px}
-td { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px}
-strong { font-weight: bold; font-size: 14px}
+body { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: x-small}
+td { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: x-small}
+strong { font-weight: bold; font-size: larger}
table { border-style: none}
td { border-style: none}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-james/www stylesheet.css
noel2003/01/29 10:29:51
Modified:www stylesheet.css
Log:
Changed font size from pixel size to keyword
Revision ChangesPath
1.3 +3 -3 jakarta-james/www/stylesheet.css
Index: stylesheet.css
===
RCS file: /home/cvs/jakarta-james/www/stylesheet.css,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- stylesheet.css30 Dec 2002 05:36:50 - 1.2
+++ stylesheet.css29 Jan 2003 18:29:51 - 1.3
@@ -1,5 +1,5 @@
-body { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10px}
-td { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px}
-strong { font-weight: bold; font-size: 14px}
+body { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: x-small}
+td { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: x-small}
+strong { font-weight: bold; font-size: larger}
table { border-style: none}
td { border-style: none}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with font size on James website and documentation
Matt, I have uploaded a replacment stylesheet, and would like to make sure that it does work for you. Please let me know if it works. And thank you very much for your report. --- Noel -- Attached Message - From: Matt Perry [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 11:20 To: [EMAIL PROTECTED] Subject: Problem with font size on James website and documentation Webmaster: could you please forward this to the person who maintains the James web site and documentation? I couldn't find the address. Thanks. Hi. I just wanted to point out that I cannot read the James web site nor can I read the James documentation. The reason is that in your style sheet you are using hard-coded font sizes rather than using relative declarations such as: font-size: 1.0em font-size: 100% font-size: x-small Please consider using these instead of pixels or points. The reason is that I have poor vision. Therefore, I have to set the default font size in my browser to 20 points. Since your style sheet doesn't respect that I quite literally cannot read much of anything in your documentation or web site. It's simply too small. This could be a big usability issue for other people, too. Jakob Nielsen even listed this as one of the top web design mistakes of 2002 (see #4: http://www.useit.com/alertbox/20021223.html) I hope you'll consider changing your style sheet so that your web site and documentation will be accessible to all users, not just those users with perfect eyesight. Thanks for your time. -- Matt Perry | matt at primefactor dot com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with font size on James website and documentation
Matt, I have committed the change to the CVS, and will make sure that it is in the next build. --- Noel -Original Message- From: Matt Perry [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 14:00 To: Noel J. Bergman Cc: James-Dev Mailing List Subject: RE: Problem with font size on James website and documentation Noel, Looks good now. I can read it with no problems. Thanks for the quick work. Will this style sheet be added to the docs in the distribution archive? I noticed that it had the same problem, although reading the docs online is fine for me. - .\\ On Wed, 29 Jan 2003, Noel J. Bergman wrote: Matt, I have uploaded a replacment stylesheet, and would like to make sure that it does work for you. Please let me know if it works. And thank you very much for your report. --- Noel -- Attached Message - From: Matt Perry [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 11:20 To: [EMAIL PROTECTED] Subject: Problem with font size on James website and documentation Webmaster: could you please forward this to the person who maintains the James web site and documentation? I couldn't find the address. Thanks. Hi. I just wanted to point out that I cannot read the James web site nor can I read the James documentation. The reason is that in your style sheet you are using hard-coded font sizes rather than using relative declarations such as: font-size: 1.0em font-size: 100% font-size: x-small Please consider using these instead of pixels or points. The reason is that I have poor vision. Therefore, I have to set the default font size in my browser to 20 points. Since your style sheet doesn't respect that I quite literally cannot read much of anything in your documentation or web site. It's simply too small. This could be a big usability issue for other people, too. Jakob Nielsen even listed this as one of the top web design mistakes of 2002 (see #4: http://www.useit.com/alertbox/20021223.html) I hope you'll consider changing your style sheet so that your web site and documentation will be accessible to all users, not just those users with perfect eyesight. Thanks for your time. -- Matt Perry | matt at primefactor dot com -- Matt Perry | matt at primefactor dot com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration Subsystem (was Mailet Configuration)
Hi Serge, I think that we are both on the same page here. Your Servlet API guideline is a pretty good one, I think. When it comes to the actual Mailet API itself, I don't intend to do anything particularly momentus or far-reaching. Certainly I will be discussing it on this list before wedding myself to any particular idea. At the moment, I am leaning toward a very basic MailetConfig interface, with a default implementation that provides name/value pairs. There would need to be a cast from MailetConfig to BasicMailetConfig in order to get at the accessor methods. I am thinking that this could be done in GenericMailet - so that the Mailet author doesn't need to worry about it. The only other standard MailetConfig impl would be a DomMailetConfig - which provides a DOM tree containing the XML within the Mailet tag. (Or possibly within a config child tag.) This would provide, within the standard API: Default to NVP at zero effort for the Mailet author. Introduction of the concept of alternative mechanisms into the API, with DomMailetConfig. Requirement to implement two types of MailetConfig - but no requirement to provide any further alternatives or to provide plugability. Requirement to provide a way of configuring a Mailet via XML. This would *not* tie the container to the whole config XML. A mailet might be packaged with its own mailet-config.xml in one implementation, while another implementation could save the XML in a DB (maybe in xindice?) and allow editing via an admin console. I do propose to provide a standard XSD to describe mailet configuration. It would then be up to a particular Mailet container implementation to provide ways for a Mailet to use other MailetConfig implementations if it so desired. I am not in love with the idea of a cast in the normal flow, however. I'm still mulling that one over. I don't want to limit alternative implementations with the requirement to return name/value pairs. Any ideas? A couple of alternatives for the API might be to provide: MailetConfig cfg = Mailet.getMailetConfig(); and org.w3c.dom.DocumentFragment = Mailet.getConfigXml(); or: BasicMailetConfig cfg = GenericMailet.getBasicMailetConfig(); and DomMailetConfig cfg = (DomMailetConfig)Mailet.getMailetConfig(); Hmmm. I can see various implications/drawbacks in both of these. I'm all thunk out for now. I just wanted to get a few thoughts down. Feedback welcome. Cheers ADK There is no magic. Serge Knystautas To: James Developers List [EMAIL PROTECTED] sergek@lokite cc: ch.com Subject: Re: Configuration Subsystem (was Mailet Configuration) 30/01/2003 05:04 Please respond to James Developers List Aaron Knauf wrote: I disagree, but rather than go into the why's and wherefore's here, I will finish off the UML that I am working on to ensure that we are not just misunderstanding each other. I will however, say this: I think that access to some form of structured config for mailets is important. Plugability of config implementations is not something that needs to be reflected directly in the Mailet API, but can be a value add for a particular container implementation. (Like ours!) Ok sure, just as long as it's not in the mailet API or specification, that's cool with me. Dynamic reconfiguration must be supported by
James v3 Requirements and Planning
Folks, What I'd like to do is see if we can have a bit of structure to the James v3 development dialog without impeding people's ability to work. Otherwise everyone will be talking about everything at once without really getting anywhere. And once we have some consensus on how we'd like to proceed on a given subject, then we can move onto other items while people are coding the agreed upon solutions. To start, I've updated the JamesV3/Requirements page. I've noted on it what appear to be the minimum requirements for James v3. Nothing is cast in stone. These are just talking points. I've also added work that is already underway; specifically, Serge's work with JNDI. ref: http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/Requirements The /Requirements page is distinct from the /Plans page, which is more of a wish list with commentary. I'd like to keep the requirements page pared down to what we must do, not what we could do. At some point we'll create a separate page for the work that is done or in-progress, but for the moment, I thought it would be helpful to keep those items here. Everyone will have their own ideas of things that they want to work on. Personally, I believe that the big items that must be addressed because they impact everything else are the User and Message stores, along with User and Mail attributes. Once those are squared away, services, matchers and mailets can be coded to them without ad hoc techniques or too much concern about change. In terms of priority, I put Mailet API *structural* changes at a higher priority than other changes, because of their pervasive nature. But, again, that's my view. I added a page on Mailet Configuration. I just tried to collect the various proposals that have been put forth so far. I left my old one out, thinking that the current ones provide sufficient fodder for discussion. ref: http://nagoya.apache.org/wiki/apachewiki.cgi?action=editid=JamesV3/MailetCo nfiguration The Wiki is used as a white board -- a persistent URL -- where people can prepare and revise their proposals, highlight some of the pros and cons. We'll discuss them here, but we can follow the state online. When we agree on something, we'll leave the agreed upon solution on the page, and remove (or move) the discarded approaches. Right now the Wiki represents my personal views, and my best attempt to record other people's views as I understand them. Until we all agree, the Wiki should not be taken to record an consensus of the James project. Are there other *requirements*? Let's discuss (and record) them. Do you have an issue with something you see recorded? Raise it for discussion, and we can record the revisions. Etc. I look forward to replies, including which topic folks would like to achieve consensus upon first so that people can get to work on it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James v3 Requirements and Planning
[Noel] In terms of priority, I put Mailet API *structural* changes at a higher priority than other changes, because of their pervasive nature. But, again, that's my view. I agree. However, it may be difficult to judge the impact that other aspects of development have on the Mailet API until those topics are addressed. We should consider the Mailet API decisions that we reach to be not-quite-final until the areas of development affected by them are addressed. Cheers ADK There is no magic. --- Have you seen our website? http://www.vodafone.co.nz CAUTION: This correspondence is confidential and intended for the named recipient(s) only. If you are not the named recipient and receive this correspondence in error, you must not copy, distribute or take any action in reliance on it and you should delete it from your system and notify the sender immediately. Thank you. Unless otherwise stated, any views or opinions expressed are solely those of the author and do not represent those of Vodafone New Zealand Limited. Vodafone New Zealand Limited 21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand Telephone + 64 9 357 5100 Facsimile + 64 9 377 0962 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: James v3 Requirements and Planning
it may be difficult to judge the impact that other aspects of development have on the Mailet API until those topics are addressed. Oh, of course. :-) We anticipate as best we can when we discuss, but the best that we can do is identify the directions that we'd like to try. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James v3 Requirements and Planning
- Original Message - From: Noel J. Bergman [EMAIL PROTECTED] Are there other *requirements*? Let's discuss (and record) them. Do you have an issue with something you see recorded? Raise it for discussion, and we can record the revisions. Etc. - Standard repository interface. This has been talked about. I thought Danny had a proposal but there has been no agreement or code in proposal - Move all the protocol servers to the standard repository. - Default IMAP to on. Corollary is that it should work even in a narrow sense. Maybe one can pick a one or two clients and support them. Harmeet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James v3 Requirements and Planning
Noel J. Bergman wrote: it may be difficult to judge the impact that other aspects of development have on the Mailet API until those topics are addressed. Oh, of course. :-) We anticipate as best we can when we discuss, but the best that we can do is identify the directions that we'd like to try. It maybe of interest to people here that I am I working on a container and part of the requirements I aim to fulfill it to provide a complete solution to the Mailet container scenario. In fact - I will be promoting the ability to declaring (via a James configuration argument ) the container implementation to be used for mailet management. In case your wondering which container I'm talking about - then get yourself ready for some blatant advertising - its Merlin! Lookout world - magic is in the air. Cheers, Steve. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: James v3 Requirements and Planning
Harmeet Bedi wrote: Noel J. Bergman wrote: Are there other *requirements*? Let's discuss (and record) them. Do you have an issue with something you see recorded? Raise it for discussion, and we can record the revisions. Etc. - Standard repository interface. Isn't that part of the user and message stores? - Move all the protocol servers to the standard repository. - Default IMAP to on. Protocols do not default to on until they pass testing. We will probably restructure the CVS, and with some of the work that Darrell just did, it may make it easier to re-integrate things since we don't have to load those components when we do the distribution build. Serge suggested that my estimate of James v3 being one year away is realistic if we wait for everything, but he'd like something sooner. If we make the structural changes necessary, added key enhancements, and removed obstacles that impede proper development of IMAP and NNTP, then there is an argument for releasing James v3.0. I'm not saying that a functional IMAP server isn't part of James v3.0, but I'm accepting that we may not want to wait that long. So I am trying to define the minimum requirements that must be met along the way. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: James v3 Requirements and Planning
It maybe of interest to people here that I am I working on a container and part of the requirements I aim to fulfill it to provide a complete solution to the Mailet container scenario. Well, of course we're interested. I'm just not sure what, if anything, to take away from your comments regarding what we need to do in terms of James v3 design and implementation. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: James v3 Requirements and Planning
Noel J. Bergman wrote: It maybe of interest to people here that I am I working on a container and part of the requirements I aim to fulfill it to provide a complete solution to the Mailet container scenario. Well, of course we're interested. I'm just not sure what, if anything, to take away from your comments regarding what we need to do in terms of James v3 design and implementation. 1. stop being paranoid about dependencies 2. think about users and what they want 3. containers are about delivering value to users 4. there is a lot of scope that we can deal with 5. most of that scope is a container concern 6. if the spec if good then containment solution will be transparent 7. transparence isn't so easy 8. I'm willing and able to contribute to the work 9. just wanted to have more than eight points ;-) Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: James v3 Requirements and Planning
I'm just not sure what, if anything, to take away from your comments regarding what we need to do in terms of James v3 design and implementation. 1. stop being paranoid about dependencies 2. think about users and what they want 3. containers are about delivering value to users 4. there is a lot of scope that we can deal with 5. most of that scope is a container concern 6. if the spec if good then containment solution will be transparent 7. transparence isn't so easy 8. I'm willing and able to contribute to the work 9. just wanted to have more than eight points I'm not sure what point(s) you're making, in the context of James. This isn't a discussion about an Avalon container. We have domain specific needs regarding a user data model and message storage model. Those are key services provided to the protocol handlers, matchers and mailets. And those, in turn, implement the messaging server. I don't care which container we're operating in. And people seem fairly firm regarding a Mailet API that works well within an Avalon container, but is not tied to requiring one. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] v2.1.1 release
Please vote to release v2.1.1, as represented by v2.1.1a4 in the nightly build structure. I am withdrawing this vote due to a defect in the file system repository. I believe that I have a fix, which I am uploading as part of v2.1.1a5. Since I have to do that, anyway, do we *want* to try the new dnsserver code? Is anyone using the DNS code checked into HEAD? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help with custom james/avalon
Hi, I was trying to override org.apache.james.mailrepository.AvalonMailRepository to implement additional features for store/retrieve/remove operations. However, I got the following exception when starting james (within phoenix): org.apache.excalibur.containerkit.lifecycle.LifecycleException: Component named James failed to pass through the Initialization stage. (Reason: java.lang.NoClassDefFoundError: org/apache/james/mailrepository/AvalonMailRepository). ( A more detailed trace for the above exception is appended at the end of this email. ) Here are the steps that I've done to bump into this exception:+ Write a subclass, SDMailRepository, of AvalonMailRepository+ Modify the james-config.xml to make repository class inside mailstore -- repositories point to SDMailRepository instead of AvalonMailRepository.+ Package myRepository.jar (for SDMailRepository and its related classes) into james.sar I assume that the classloader didn't load SDMailRepository's superclass or I missed some avalon specific configuration. Please help! Thanks a bunch,Sean - Live on the Earth, from the Above!--- detailed exception backtrace --- org.apache.excalibur.containerkit.lifecycle.LifecycleException: Component named James failed to pass through the Initialization stage. (Reason: java.lang.NoClassDefFoundError: org/apache/james/mailrepository/AvalonMailRepository). at org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.fail(LifecycleHelper.java:289) at org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.startup(LifecycleHelper.java:159) at org.apache.avalon.phoenix.components.application.DefaultApplication.startup(DefaultApplication.java:480) at org.apache.avalon.phoenix.components.application.DefaultApplication.doRunPhase(DefaultApplication.java:428) at org.apache.avalon.phoenix.components.application.DefaultApplication.runPhase(DefaultApplication.java:364) at org.apache.avalon.phoenix.components.application.DefaultApplication.start(DefaultApplication.java:138) at org.apache.avalon.framework.container.ContainerUtil.start(ContainerUtil.java:251) at org.apache.avalon.phoenix.components.kernel.DefaultKernel.startup(DefaultKernel.java:178) at org.apache.avalon.phoenix.components.kernel.DefaultKernel.addApplication(DefaultKernel.java:254) at org.apache.avalon.phoenix.components.deployer.DefaultDeployer.deploy(DefaultDeployer.java:353) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:498) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:491) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFiles(DefaultEmbeddor.java:476) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployDefaultApplications(DefaultEmbeddor.java:466) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.execute(DefaultEmbeddor.java:224) at org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:158) at org.apache.avalon.phoenix.frontends.CLIMain.execute(CLIMain.java:144) at org.apache.avalon.phoenix.frontends.CLIMain.main(CLIMain.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.avalon.phoenix.launcher.Main.startup(Main.java:94) at org.apache.avalon.phoenix.launcher.Main.main(Main.java:46) Caused by: java.lang.NoClassDefFoundError: org/apache/james/mailrepository/AvalonMailRepository at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:509) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:246) at java.net.URLClassLoader.access$100(URLClassLoader.java:54) at java.net.URLClassLoader$1.run(URLClassLoader.java:193) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:262) at org.apache.james.core.AvalonMailStore.select(AvalonMailStore.java:278) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.avalon.phoenix.components.application.BlockInvocationHandler.invoke(BlockInvocationHandler.java:92) at $Proxy3.select(Unknown Source) at
Help with custom james/avalon (plain txt)
Hi, I was trying to override org.apache.james.mailrepository.AvalonMailRepository to implement additional features for store/retrieve/remove operations. However, I got the following exception when starting james (within phoenix): org.apache.excalibur.containerkit.lifecycle.LifecycleException: Component named James failed to pass through the Initialization stage. (Reason: java.lang.NoClassDefFoundError: org/apache/james/mailrepository/AvalonMailRepository). ( A more detailed trace for the above exception is appended at the end of this email. ) Here are the steps that I've done to bump into this exception: + Write a subclass, SDMailRepository, of AvalonMailRepository + Modify the james-config.xml to make repository class inside mailstore -- repositories point to SDMailRepository instead of AvalonMailRepository. + Package myRepository.jar (for SDMailRepository and its related classes) into james.sar I assume that the classloader didn't load SDMailRepository's superclass or I missed some avalon specific configuration. Please help! Thanks a bunch, Sean - Live on the Earth, from the Above! --- detailed exception backtrace --- org.apache.excalibur.containerkit.lifecycle.LifecycleException: Component named James failed to pass through the Initialization stage. (Reason: java.lang.NoClassDefFoundError: org/apache/james/mailrepository/AvalonMailRepository). at org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.fail(LifecycleHelper.java:289) at org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.startup(LifecycleHelper.java:159) at org.apache.avalon.phoenix.components.application.DefaultApplication.startup(DefaultApplication.java:480) at org.apache.avalon.phoenix.components.application.DefaultApplication.doRunPhase(DefaultApplication.java:428) at org.apache.avalon.phoenix.components.application.DefaultApplication.runPhase(DefaultApplication.java:364) at org.apache.avalon.phoenix.components.application.DefaultApplication.start(DefaultApplication.java:138) at org.apache.avalon.framework.container.ContainerUtil.start(ContainerUtil.java:251) at org.apache.avalon.phoenix.components.kernel.DefaultKernel.startup(DefaultKernel.java:178) at org.apache.avalon.phoenix.components.kernel.DefaultKernel.addApplication(DefaultKernel.java:254) at org.apache.avalon.phoenix.components.deployer.DefaultDeployer.deploy(DefaultDeployer.java:353) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:498) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:491) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFiles(DefaultEmbeddor.java:476) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployDefaultApplications(DefaultEmbeddor.java:466) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.execute(DefaultEmbeddor.java:224) at org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:158) at org.apache.avalon.phoenix.frontends.CLIMain.execute(CLIMain.java:144) at org.apache.avalon.phoenix.frontends.CLIMain.main(CLIMain.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.avalon.phoenix.launcher.Main.startup(Main.java:94) at org.apache.avalon.phoenix.launcher.Main.main(Main.java:46) Caused by: java.lang.NoClassDefFoundError: org/apache/james/mailrepository/AvalonMailRepository at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:509) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:246) at java.net.URLClassLoader.access$100(URLClassLoader.java:54) at java.net.URLClassLoader$1.run(URLClassLoader.java:193) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:262) at org.apache.james.core.AvalonMailStore.select(AvalonMailStore.java:278) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.avalon.phoenix.components.application.BlockInvocationHandler.invoke(BlockInvocationHandler.java:92) at $Proxy3.select(Unknown Source) at
Help with custom james/avalon (plain txt)
Hi, I was trying to override org.apache.james.mailrepository.AvalonMailRepository to implement additional features for store/retrieve/remove operations. However, I got the following exception when starting james (within phoenix): org.apache.excalibur.containerkit.lifecycle.LifecycleException: Component named James failed to pass through the Initialization stage. (Reason: java.lang.NoClassDefFoundError: org/apache/james/mailrepository/AvalonMailRepository). ( A more detailed trace for the above exception is appended at the end of this email. ) Here are the steps that I've done to bump into this exception: + Write a subclass, SDMailRepository, of AvalonMailRepository + Modify the james-config.xml to make repository class inside mailstore -- repositories point to SDMailRepository instead of AvalonMailRepository. + Package myRepository.jar (for SDMailRepository and its related classes) into james.sar I assume that the classloader didn't load SDMailRepository's superclass or I missed some avalon specific configuration. Please help! Thanks a bunch, Sean - Live on the Earth, from the Above! --- detailed exception backtrace --- org.apache.excalibur.containerkit.lifecycle.LifecycleException: Component named James failed to pass through the Initialization stage. (Reason: java.lang.NoClassDefFoundError: org/apache/james/mailrepository/AvalonMailRepository). at org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.fail(LifecycleHelper.java:289) at org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.startup(LifecycleHelper.java:159) at org.apache.avalon.phoenix.components.application.DefaultApplication.startup(DefaultApplication.java:480) at org.apache.avalon.phoenix.components.application.DefaultApplication.doRunPhase(DefaultApplication.java:428) at org.apache.avalon.phoenix.components.application.DefaultApplication.runPhase(DefaultApplication.java:364) at org.apache.avalon.phoenix.components.application.DefaultApplication.start(DefaultApplication.java:138) at org.apache.avalon.framework.container.ContainerUtil.start(ContainerUtil.java:251) at org.apache.avalon.phoenix.components.kernel.DefaultKernel.startup(DefaultKernel.java:178) at org.apache.avalon.phoenix.components.kernel.DefaultKernel.addApplication(DefaultKernel.java:254) at org.apache.avalon.phoenix.components.deployer.DefaultDeployer.deploy(DefaultDeployer.java:353) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:498) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFile(DefaultEmbeddor.java:491) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployFiles(DefaultEmbeddor.java:476) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployDefaultApplications(DefaultEmbeddor.java:466) at org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.execute(DefaultEmbeddor.java:224) at org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:158) at org.apache.avalon.phoenix.frontends.CLIMain.execute(CLIMain.java:144) at org.apache.avalon.phoenix.frontends.CLIMain.main(CLIMain.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.avalon.phoenix.launcher.Main.startup(Main.java:94) at org.apache.avalon.phoenix.launcher.Main.main(Main.java:46) Caused by: java.lang.NoClassDefFoundError: org/apache/james/mailrepository/AvalonMailRepository at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:509) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:246) at java.net.URLClassLoader.access$100(URLClassLoader.java:54) at java.net.URLClassLoader$1.run(URLClassLoader.java:193) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:262) at org.apache.james.core.AvalonMailStore.select(AvalonMailStore.java:278) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.avalon.phoenix.components.application.BlockInvocationHandler.invoke(BlockInvocationHandler.java:92) at $Proxy3.select(Unknown Source) at
cvs commit: jakarta-james/src/xdocs changelog.xml index.xml stylesheet.css weare.xml
noel2003/01/29 20:26:50
Modified:src/xdocs Tag: branch_2_1_fcs changelog.xml index.xml
stylesheet.css weare.xml
Log:
updated v2 branch to reflect TLP status, code changes, and stylesheet change
Revision ChangesPath
No revision
No revision
1.11.4.1 +13 -1 jakarta-james/src/xdocs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-james/src/xdocs/changelog.xml,v
retrieving revision 1.11
retrieving revision 1.11.4.1
diff -u -r1.11 -r1.11.4.1
--- changelog.xml 13 Dec 2002 17:46:31 - 1.11
+++ changelog.xml 30 Jan 2003 04:26:50 - 1.11.4.1
@@ -11,8 +11,20 @@
pThis is a living document that records what was done between releases. As
always, thank you to everyone who contributed code, documentation, bug reports, and
feedback.
/p
+section name=Version 2.1.1
+pExpected release January 2003/p
+li [NjB] (code) Fixed synchronizaion bug in file repository/li
+li [NjB] (code) Enabled log rotation/li
+li [NjB] (doc) Fixed broken links/li
+li [DA, NjB] (update) Updated JavaMail and JAF/li
+li [NjB] (code) Updated sqlResources.xml for PostgreSQL with patch from simon
/li
+li [NjB] (code) Reorder primary key for JDBCMailRepository? to optimize queries
using just the repository name./li
+li[PG,HB] (code) NNTP dot stuffing fix/li
+li[PG] (code) NNTP OVER/XOVER fix/li
+/section
+
section name=Version 2.1
-pExpected release December 2002/p
+pReleased 29 December 2002/p
ul
li(AK) (doc) Added LDAP RFCs./li
li(PG) (code) Fixed platform-specific performance issue with the POP3 server
delivery./li
1.23.2.4 +3 -1 jakarta-james/src/xdocs/index.xml
Index: index.xml
===
RCS file: /home/cvs/jakarta-james/src/xdocs/index.xml,v
retrieving revision 1.23.2.3
retrieving revision 1.23.2.4
diff -u -r1.23.2.3 -r1.23.2.4
--- index.xml 10 Jan 2003 07:49:54 - 1.23.2.3
+++ index.xml 30 Jan 2003 04:26:50 - 1.23.2.4
@@ -15,7 +15,9 @@
pJames is based upon the Apache Avalon application framework. (For more
information about Avalon, please go to a
href=http://jakarta.apache.org/avalon;http://jakarta.apache.org/avalon/a)/p
pJames requires Java 2 (either JRE 1.3 or 1.4 as of 2.0a3). /p
subsection name=news
-pbFind out how to use James with sendmail/bbr/We've added a HOW TO document
explaining how to configure sendmail to route all mail through James, read it a
href=james_and_sendmail.htmlHere/a./p
+pbJames Comes Of Age/bbr/We're proud to announce that Jakarta James has
been promoted from being a Jakarta sub-project to Apache James, a top-level project of
the Apache Software Foundation (ASF). James now has its own Project Management
Committee, and reports directly to the a
href=http://www.apache.org/foundation;ASF/a./p
+pWe also have a brand new domain name: bhttp://james.apache.org/b and are in
the process of moving our infrastructure over to the new domain, so please forgive any
confusion that might occur./p
+piAt this time we would especially appreciate hearing about broken links or out
of date references on this site./i/p
/subsection
subsection name=releases
pbLatest and Stable: james-2.1/bbr/
1.1.4.1 +3 -3 jakarta-james/src/xdocs/stylesheet.css
Index: stylesheet.css
===
RCS file: /home/cvs/jakarta-james/src/xdocs/stylesheet.css,v
retrieving revision 1.1
retrieving revision 1.1.4.1
diff -u -r1.1 -r1.1.4.1
--- stylesheet.css30 Jul 2002 13:37:34 - 1.1
+++ stylesheet.css30 Jan 2003 04:26:50 - 1.1.4.1
@@ -1,5 +1,5 @@
-body { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10px}
-td { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px}
-strong { font-weight: bold; font-size: 14px}
+body { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: x-small}
+td { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: x-small}
+strong { font-weight: bold; font-size: larger}
table { border-style: none}
td { border-style: none}
1.12.4.1 +1 -0 jakarta-james/src/xdocs/weare.xml
Index: weare.xml
===
RCS file: /home/cvs/jakarta-james/src/xdocs/weare.xml,v
retrieving revision 1.12
retrieving revision 1.12.4.1
diff -u -r1.12 -r1.12.4.1
--- weare.xml 13 Dec 2002 17:46:31 - 1.12
+++ weare.xml 30 Jan 2003 04:26:50 - 1.12.4.1
@@ -45,6 +45,7 @@
pbShilpa Dalmia (shilpa at postx.com) (SD)/b/p
pbSteve Short (sshort at postx.com) (SS3)/b/p
pbAaron Knauf (aknauf at xtra.co.nz) (AK)/b/p
+pbSerge Sergei
cvs commit: jakarta-james/src/xdocs changelog.xml
noel2003/01/29 20:29:59 Modified:src/xdocs changelog.xml Log: updated change log Revision ChangesPath 1.13 +1 -2 jakarta-james/src/xdocs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-james/src/xdocs/changelog.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- changelog.xml 28 Jan 2003 21:07:25 - 1.12 +++ changelog.xml 30 Jan 2003 04:29:59 - 1.13 @@ -16,12 +16,11 @@ li[SS4] (code) DNS service can auto-discover DNS servers/li li[SS4] (code) return an unmodifiable Collection from findMXRecords()/li li[SS4] (code) Added some more logging to DNS service/li -li[PG,HB] (code) NNTP dot stuffing fix/li -li[PG] (code) NNTP OVER/XOVER fix/li /section section name=Version 2.1.1 pExpected release January 2003/p +li [NjB] (code) Fixed synchronizaion bug in file repository/li li [NjB] (code) Enabled log rotation/li li [NjB] (doc) Fixed broken links/li li [DA, NjB] (update) Updated JavaMail and JAF/li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] v2.1.1 release
Noel J. Bergman wrote: I am withdrawing this vote due to a defect in the file system repository. I believe that I have a fix, which I am uploading as part of v2.1.1a5. This is kind of a silly question, but what happened to alphas 1 through 4? I guess you have been building them and I just hadn't noticed. Nice catch with the synchronization woes, btw. Since I have to do that, anyway, do we *want* to try the new dnsserver code? Is anyone using the DNS code checked into HEAD? I would like to since it promises to reduce the number of problems caused by people not configuring the DNS servers, but unfortunately can't commit to testing this in the next week. -- Serge Knystautas Lokitech Software - Strategy - Design http://www.lokitech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] v2.1.1 release
what happened to alphas 1 through 4? Uh ... v2.1.1a1 Jan 9 v2.1.1a2 Jan 10 v2.1.1a3 Jan 16 v2.1.1a4 Jan 26 v2.1.1a5 Jan 29 I've been announcing them on james-user@. I would like to [have the DNSServer change] since it promises to reduce the number of problems [...] Have you been running with HEAD? Is anyone using that code right now? I have some additional changes for it, too. I suppose we can put out a v2.1.1a6 to test the DNSServer code. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
