Swiss "crack" SSL in "obscure" mail usage
Purely FYI. Not a big deal. http://slashdot.org/articles/03/02/20/1956229.shtml?tid=93&tid=172 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avalon Jars
Noel J. Bergman wrote: I've just completed test of the current Phoenix dist (in the James CVS) against the James sar file and that passed OK (i.e. James in Phoneix as is appears to be working fine). That's good :-) The one file that can be safely removed is cornerstone.jar (its not referenced by anything). The rest are related to the Phoenix implementation and I would really need to get some advice on what can be replaced here. I don't know, either. It seems to me that as Avalon proposes an RC, we should get that for testing. If it passes your initial sanity check, it should go into HEAD for community testing; if not, we need to report that to Avalon ASAP. When the RC becomes a Release, that goes into HEAD. Does that make sense? Yep - that's consitent with the policy I've been applying. My only concern is that there is an overlap between jars used as part of the Phoenix distribution that are also used or implied by the James distribution. It's this area that I want to get some confirmation form Phoneix developers as James HEAD requires later versions of jars than those available under Phoenix. The current build addresses this by included the dependent jars into the James sar - and this seems to work without problem. 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]
cvs commit: jakarta-james/src/conf james-config.xml
noel2003/02/22 12:16:50 Modified:src/conf Tag: branch_2_1_fcs james-config.xml Log: Corrected and added some comments and dbfile examples Revision ChangesPath No revision No revision 1.40.2.3 +20 -3 jakarta-james/src/conf/james-config.xml Index: james-config.xml === RCS file: /home/cvs/jakarta-james/src/conf/james-config.xml,v retrieving revision 1.40.2.2 retrieving revision 1.40.2.3 diff -u -r1.40.2.2 -r1.40.2.3 --- james-config.xml 11 Feb 2003 18:18:07 - 1.40.2.2 +++ james-config.xml 22 Feb 2003 20:16:49 - 1.40.2.3 @@ -13,7 +13,7 @@ - + @@ -70,6 +70,15 @@ --> + + + + + @@ -339,7 +348,7 @@ - + 110 @@ -554,6 +563,14 @@ + + + + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-james/src/conf james-config.xml
noel2003/02/22 12:17:43 Modified:src/conf james-config.xml Log: Corrected and added some comments, dbfile examples, and autoreconnect for mysql Revision ChangesPath 1.48 +20 -3 jakarta-james/src/conf/james-config.xml Index: james-config.xml === RCS file: /home/cvs/jakarta-james/src/conf/james-config.xml,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- james-config.xml 21 Feb 2003 01:35:45 - 1.47 +++ james-config.xml 22 Feb 2003 20:17:43 - 1.48 @@ -13,7 +13,7 @@ - + @@ -70,6 +70,15 @@ --> + + + + + @@ -619,6 +628,14 @@ --> + + + + @@ -685,7 +702,7 @@
Re: Proposed Mailet AP v3I change
Noel J. Bergman wrote: For Mailet API v3, I'd like to add: public InetAddress getRemoteAddress(); Both getRemoteHost() and getRemoteAddr() can be implemented based upon an InetAddress object, and when dealing with the IP address, having an InetAddress is faster than having to convert from the String form. Noel, This was pulled straight from the servlet spec, and the reason they give for the two methods is that a container may choose not to resolve the hostnames (to speed performance). If a container does this, then getRemoteHost() returns the same thing as getRemoteAddr(). I think James always needs to do this resolution, so I think it's fine to change this to getRemoteAddress(). -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What should be in each release package?
I'd like to review the contents of the release packages. IMO, we don't need to put generated files in the source releases. The source releases don't, but the source + phoenix releases do. Neither needs to have the generated HTML. The following are based on the v2.1 branch; I haven't checked for any packaging changes in HEAD. The fileset for Source + Phoenix is: - - - - + The -/+ indicate changes that would remove dist and the generated www/ from the package. I don't see why they are included, since they are generated. The fileset for Source is: - - + dist/ isn't present, but I'd remove the generated www/ and the phoenix lib, since I'm just not sure why phoenix-bin/lib/ is included if phoenix-bin isn't. The binary and binary w/Mailet SDK package contents seem to be appropriate. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
