RE: fix for bug 20370

[Steve Short]

> I would suggest perhaps changing the error messages. If 
> someone is only 
> sending LR instead of CRLF, I think we should deny the 
> command, but deny 
> it with an error message that tells them they need to use 
> CRLF and gives 
> them a URL to learn more (however, that URL should not be the RFC, it 
> should be a doc for the unsavvy and the impatient).

This is exacly what qmail does, with a reference to the RFC in it.

Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Shutting down James

[Steve Short]

Noel,

I didn't have to 'do' anything to James to get the JMX stop/start
mechanism working, all that is provided by the Phoenix SystemManager /
JMX implementation.  

What I (thought I) said was 'we made some minor changes to the dispose()
methods'.  This is because some of the components were shutting down
untidily and throwing a bunch of exceptions.  Mainly trying to use a
context log object after that object had already been removed.

I would like to improve the JMX monitoring and management of James, but
don't hold your breath as I have a lot of things on my plate right now!

Cheers
Steve


> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, May 29, 2003 9:04 AM
> To: James Developers List
> Subject: RE: Shutting down James
> 
> 
> > I am working on JMX stuff right now.  My objective is to provide 
> > fine-grain redeployment of an appliance inside a container.  This 
> > means that all components would be redeployable (without changing 
> > existing component code).
> 
> Great.  :-)
> 
> > this will not bne available tommorow
> 
> Understood.  We haven't been rushing at JMX.  When the 
> support is there from Avalon, we'll want to take advantage of 
> it.  If Steve has some stuff already working for James, 
> that'll be good to look at, too.
> 
>   --- 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: Shutting down James

[Steve Short]

We run James in Jboss and use (Jboss) JMX to stop and start James, so I
expect MX4J should work just as well for this.

We made a couple of changes to various dispose() methods which have not
been submitted because we are a few versions behind - but I can resync
if it looks like it'd be useful.

Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Synchronised??

[Steve Short]

Yes it's possible for multiple threads to call your service
concurrently.

Steve

> -Original Message-
> From: Scherer Pierre [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 25, 2003 10:03 AM
> To: James-dev
> Subject: Synchronised??
> 
> 
> 
> Hi,
> 
> I have a question about the synchronisation of service.
> In fact, I log in Database when a mailet call the service 
> tracking!! But is it possible that more threads (several mail 
> on the server ) call this service? Or avalon gives the 
> garanty that, if a call is doing by a thread, it locks this service.
> 
> Thanks,
> 
> -Pierre
> 
> 
> -
> 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: User-Log

[Steve Short]

> Point taken, but if we use delegation properly, not just 
> lightweight wrapping, the wrapping mailet can wrap the mailet 
> context provided by get Mailet context and watch that too..

Can you expand on that as I don't see how it will help.  These
operations aren't on the Mailet context they are on the Javamail API and
the spool repository directly.

Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: User-Log

[Steve Short]

It is a nice solution, but I don't think it will work in this case
because a tracking service will need to log delivery status on a per
message basis. RemoteDelivery can split up messages for different target
recipient domains and now also has partial delivery capability, so one
invocation to RemoteDelivery could yield multiple tracking entries with
different status value and RemoteDelivery  can also store message in a
retry queue for later delivery.  

Steve

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED] 
> Sent: Friday, February 28, 2003 10:03 AM
> To: James Developers List
> Subject: RE: User-Log
> 
> 
> > Perhaps consideration should be give to wrapping mailets
> > in mailets, that way the tracking mailet could contain
> > any mailet, all it has to do is delegate calls to the
> > mailet methods to the wrapped class, and intercept those
> > its interested in on the way.
> 
> Very clever and general solution!  Nicely done.  :-D  Best of 
> the lot so far.
> 
> > I suspect the config model isn't up to this though.
> 
>  
>RealMailet
>...
>...
>  
> 
> The wrapper would instantiate the inner mailet instance, and 
> pass along the lifecycle calls, including the config object.  
> The inner mailet wouldn't know about or bother with the 
> wrapper's configuration parameters.
> 
> > I'm also concerned that this mailet is not portable
> 
> I don't think that there is much question of that, right now. 
>  But at least it is isolated into one place.
> 
>   --- 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: What should be in each release package?

[Steve Short]

Noel,

I like source packages that download and build with as little fuss as
possible.  To me that says have one released source package and make it
the Source + Phoenix one.

Cheers
Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Really slow spooling again... :(

[Steve Short]

I like the idea of a connection cache, but we should try not to use
isConnected().  This is because the SMTPTransport isConnected() method
sends a NOOP command to the destination host and therefore involves a
network transfer. 

Steve

> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, February 11, 2003 1:48 AM
> To: James Developer List
> Subject: RE: Really slow spooling again... :(
> 
> 
> 
> > The remote delivery could use more smarts by grouping messages into 
> > the
> > different hostname buckets, so it knows the 3 messages going to 
> > yahoo.com accounts, and work through those buckets one by 
> one, rather 
> > than the current message-based (so host-agnostic) ordering. 
>  That's more 
> > work and requires some refactoring to that spool implementation.
> 
> From what I can see sendmail caches open connections to 
> hosts, keeping them open for a short time so that any 
> subsequent messages to the same host can be delivered on the 
> existing open connection.
> 
> From what I can see this would require us to cache 
> "Transport"s in RemoteDelivery, test with 
> Transport.isConnected() and only connect if the answer is no. 
> Unless JavaMail is already only creating single Transports 
> for each URLName, in which case the conditional connect/close 
> would help.  
> 
> I can see that it would also help if we could get messages by 
> hostname, when we would then be able to guarentee useing a 
> single session for all mail to a single host, but this would 
> require, as you say, overhaul of the spool interface.
> 
> On the other hand if we could somehow make Mail a 
> ConnectionListener on the relevant Transport then we could 
> use an event driven remote delivery which would work, 
> perhaps, by adding mail to the transport as a listener, we'd 
> then open the transport when we know mail is waiting for that 
> host, at which point all the mail which was listening would 
> know, and send itself. We could listen to the transport for 
> the results of the send and take action based upon the 
> transport events raised this way. Just a thought.
> 
> d.
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Help with custom james/avalon (plain txt)

[Steve Short]

Your basic approach looks right. Within james.sar, was your jar in
subdirectory SAR-INF/lib?  

Try running phoenix with the debug flag, i.e. run.bat -d or run.sh -d
and look at the mailstore startup section in the phoenix.log file to see
what phoenix _has_ found.  A normal startup looks like this:

DEBUG   2003-01-30 10:49:03.566 [Phoenix.] (): Processing Block named
"mailstore" through phase "startup".
DEBUG   2003-01-30 10:49:03.576 [Phoenix.] (): Component named
"mailstore" is passing through the Creation stage.
DEBUG   2003-01-30 10:49:03.576 [Phoenix.] (): Component named
"mailstore" is passing through the Logger initialization stage.
DEBUG   2003-01-30 10:49:03.576 [Phoenix.] (): Component named
"mailstore" is passing through the Contextualization stage.
DEBUG   2003-01-30 10:49:03.576 [Phoenix.] (): Component named
"mailstore" is passing through the Composing stage.
DEBUG   2003-01-30 10:49:03.576 [Phoenix.] (): Component named
"mailstore" is passing through the Configuration stage.
DEBUG   2003-01-30 10:49:03.576 [Phoenix.] (): Component named
"mailstore" is passing through the Initialization stage.
DEBUG   2003-01-30 10:49:03.586 [Phoenix.] ():
findClass(org.apache.james.mailrepository.AvalonSpoolRepository)
DEBUG   2003-01-30 10:49:03.586 [Phoenix.] ():
findClass(org.apache.james.mailrepository.AvalonMailRepository)
DEBUG   2003-01-30 10:49:03.586 [Phoenix.] ():
findClass(org.apache.james.services.MailRepository)
DEBUG   2003-01-30 10:49:03.586 [Phoenix.] ():
findClass(org.apache.james.services.SpoolRepository)
DEBUG   2003-01-30 10:49:03.586 [Phoenix.] ():
findClass(org.apache.james.core.MimeMessageSource)
DEBUG   2003-01-30 10:49:03.596 [Phoenix.] ():
findClass(org.apache.james.mailrepository.MimeMessageAvalonSource)
DEBUG   2003-01-30 10:49:03.596 [Phoenix.] ():
findClass(javax.mail.internet.MimeMessage)

Cheers
Steve

> -Original Message-
> From: Sean Zou [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, January 29, 2003 7:42 PM
> To: [EMAIL PROTECTED]
> Subject: 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  -->  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.fa
> il(LifecycleHelper.java:289)
>  at
> org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.st
> artup(LifecycleHelper.java:159)
>  at
> org.apache.avalon.phoenix.components.application.DefaultApplic
> ation.startup(DefaultApplication.java:480)
>  at
> org.apache.avalon.phoenix.components.application.DefaultApplic
> ation.doRunPhase(DefaultApplication.java:428)
>  at
> org.apache.avalon.phoenix.components.application.DefaultApplic
> ation.runPhase(DefaultApplication.java:364)
>  at
> org.apache.avalon.phoenix.components.application.DefaultApplic
> ation.start(DefaultApplication.java:138)
>  at
> org.apache.avalon.framework.container.ContainerUtil.start(Cont
> ainerUtil.java:251)
>  at
> org.apache.avalon.phoenix.components.kernel.DefaultKernel.star
> tup(DefaultKernel.java:178)
>  at
> org.apache.avalon.phoenix.components.kernel.DefaultKernel.addA
> pplication(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.component

TestMaker

[Steve Short]

There's a tool called TestMaker, http://www.pushtotest.com/ptt looks
like it could be very useful for testing James.  It already has a Mail
Protocol Handler for SMTP, POP and IMAP.

Steve

RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api

[Steve Short]

Return the ordered List not a SortedSet without removing anything. That
way you do not risk losing any servers from the list and has no negative
impact on any installations that do not use repeated server records.

Steve

> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, January 20, 2003 8:51 PM
> To: James Developers List
> Subject: Re: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server 
> autodetect, Make use of higher level api
> 
> 
> Steve Short wrote:
> > You can use multiple MX records to the same IP to improve 
> performance 
> > by allowing James to use multiple concurrent connections to 
> the same 
> > mail server.  IIRC Javamail has some per connection synchronisation 
> > and multiple MX records can be used to enable multiple connections.
> 
> So do you think we should collapse these and return a 
> SortedSet, or just 
> return all possible servers using a List?
> 
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:james-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [PATCH] Upgrade to DnsJava 1.3.1, add DNS Server autodetect, Make use of higher level api

[Steve Short]

> As for SortedSet vs. List, it logically makes more sense to 
> have it as a 
> SortedSet since it wouldn't make sense to have multiple MX records to 
> the same IP address.  But you never know, I don't think DNS could 
> enforce this... I guess we just do extra checks as we add the IP 
> addresses and avoid duplication.  I might just make it a List 
> to avoid 
> working this out... the benefit of making it a SortedSet seem 
> minimal to me.

You can use multiple MX records to the same IP to improve performance by
allowing James to use multiple concurrent connections to the same mail
server.  IIRC Javamail has some per connection synchronisation and
multiple MX records can be used to enable multiple connections.

Steve

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Remote Delivery error

[Steve Short]

Is that '.' supposed to be there "java.net.UnknownHostException:
mail.tigerbrands.co.za." 

Steve

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, January 16, 2003 8:08 AM
> To: James Developers List
> Subject: RE: Remote Delivery error
> 
> 
> Which version of James?  v2.1, or the current v2.1.1a2 
> nightly?  I don't know if it would make any difference, but 
> we just updated the JavaMail package included with James.  
> James uses JavaMail to do the delivery.
> 
> I'm going to post a v2.1.1a3 later today, fixing a bug in the 
> SMTPHandler
> (incoming) in the current nightly build.
> 
> Can you give me a valid address at the target server to which 
> I can send a test message?
> 
>   --- Noel
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: MBox format

[Steve Short]

Serge,

Here's the message/thread I remember from Alexander Zhukov one of (?)
the authors of Javamaildir.

http://www.mail-archive.com/james-dev@jakarta.apache.org/msg05037.html

Steve

> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]] 
> Sent: Sunday, December 29, 2002 6:23 PM
> To: James Developers List
> Subject: Re: MBox format
> 
> 
> Ajit George wrote:
> > Serge -
> > 
> > I think there was previous discussion about using maildir.  There's 
> > lots
> > of discussion (bordering on religious wars) around about 
> maildir vs. 
> > mbox.  My two cents: mbox is very slow for large (5000+ messages) 
> > folders, and file corruption will corrupt whole folders 
> instead of a 
> > single message.  Also, the trend in filesystem optimization 
> is in favor 
> > of small files.
> > 
> > No reason not to implement both, especially given that mbox is
> > relatively easy, but I think maildir is more robust.
> 
> Ah ok, yeah maildir looks cool, but I'm not sure how you'd 
> implement it 
> since you're supposed to be changing files modified times.  
> Maybe I read 
> the spec wrong.
> 
> But anyway, yeah if that talk was about maildir, then yeah 
> I'm happy to 
> do this work for mbox.  Like you said, it's not the best thing out 
> there, but that's ok... hopefully with some tools in the future James 
> will make it that much easier to move between these repository 
> implementations.
> 
> -- 
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Embeded JAMES into JBoss as a service with JMX

[Steve Short]

Yes.  I added wrote a JMXLauncher which is now part of the Phoenix
project.  See this thread for more info:

http://www.mail-archive.com/james-user@jakarta.apache.org/msg03365.html

And this message which is part of the same thread be seems to have been
orphaned:

http://www.mail-archive.com/james-user@jakarta.apache.org/msg03415.html


Cheers
Steve

> -Original Message-
> From: Eric Chow [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, December 11, 2002 9:16 PM
> To: [EMAIL PROTECTED]
> Subject: Embeded JAMES into JBoss as a service with JMX
> 
> 
> Hello,
> 
> Is it possible to Embedded JAMES to JBoss with JMX?
> 
> So that JAMES will be one of the service for JBoss ?
> 
> 
> Best regards,
> Eric
> 
> 
> ==
> If you know what you are doing, 
> it is not called RESEARCH!
> ==
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Mailets v3

[Steve Short]

(Not so much Mailets v3 and James v3) I'd like to add improved JMX
management capabilities, e.g to monitor spool queues via JMX.

> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, November 27, 2002 5:55 AM
> To: James Developers List
> Subject: Re: Mailets v3
> 
> 
> Danny Angus wrote:
> >>Improved Mailet deployment.  Hot deployment is a nice-to 
> have, but not
> >>essential. What is essential is for me to be able to build a simple 
> >>deployment unit that is easily inserted into JAMES in a clear and 
> >>defined manner.
> > 
> > 
> > +1 this too is on the agenda, I've been looking at new Phoenix 
> > +classloader configuration classes, this gives us/you the 
> opportunity 
> > +to configure classloaders (in otherwords class paths & 
> jars) fron an 
> > +xml file. In theory we can use this both to build a default mailet 
> > +classloader path, and allow "power users" the ability to 
> alter this 
> > +to include/exclude jars and paths.
> > 
> > 
> > 
> >>Improved Mailet configuration.  Pluggability of config sources, in
> >>particular.  I would like to be able to get my config from 
> (variously) a 
> >>RDBMS, an XML file, or the JAMES init params.
> > 
> > 
> > again +1, there has been talk for *ages* about the desirability of 
> > "hot" reconfiguration of the spoolmanager.
> > 
> > I would like to allow processors to have their own 
> configuration, in 
> > seperate files, and have these files discovered by james at 
> runtime, 
> > much like tomcat discovering context configuration files. I 
> would like 
> > to think that we could abstract this so that James would 
> know how to 
> > look for processor configurations in different 
> configuration loaders, 
> > but I'd be cautious about how popular this feature would 
> actually be, 
> > particularly if the real problem is dynamic 
> re-configuration, and is 
> > already addressed.
> > 
> > d.
> 
> Hot mailet deployment and configurability are two of my top 
> agenda items 
> for the next mailet version.  I actually wrote a decent part of the 
> hot-deployment stuff months and months ago and can revisit 
> when we agree 
> how to do it.  How hot-deployment works is really dependent on 
> configuration (if we do add support for different kinds of 
> processors). 
>   Both of these are largely James issues and only would 
> slightly affect 
> the mailet API (as I envisioned them).
> 
> -- 
> Serge Knystautas
> Loki Technologies - Unstoppable Websites http://www.lokitech.com
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Modifing timers and James delivery speed

[Steve Short]

Jason,

There's no such one minute delay.  It may be that some service (internal
or external) James is using is not responding correctly.  I have seen
similar behaviour when the DNS server entry is wrong.

Regards
Steve

> -Original Message-
> From: Jason Webb [mailto:jw@;inovem.com] 
> Sent: Thursday, November 07, 2002 6:38 AM
> To: 'James Developers List'; [EMAIL PROTECTED]
> Subject: Modifing timers and James delivery speed
> 
> 
> I'd like to change the time the spoolmanager runs at. At the 
> moment it seems to be about once a minute. No matter what I 
> changed in the james-config.xml file it seems to make no 
> difference. The reason for doing this is to make James 
> deliver mail faster, and I feel that tweaking the number of 
> spool manager threads is less than ideal. Is there a 
> particular config that was used to maximised throughput when 
> the stress and load tests were being performed?
> 
> What I'd ideally like to do is expose this in the config file 
> so I can change it when I need to.
> 
> Help?
> 
> -- Jason
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] James as an official Apache project

[Steve Short]

+1 (Non-committer)

> -Original Message-
> From: Danny Angus [mailto:danny@;apache.org] 
> Sent: Wednesday, October 30, 2002 9:47 AM
> To: James Developers List
> Subject: [VOTE] James as an official Apache project
> 
> 
> All,
> 
> Now that we've had a chance to digest whats meant by a top 
> level project, I'll subject you to my opinion, which I've 
> held back so far.
> 
> Basically I'm in favour of proposing james as an apache top 
> level project (tlp), I'm prepared to take the lead on our 
> proposal, and here's why:
> 
>  James has a small yet mature community, we seldom seek 
> recourse to the jakarta PMC, and equally seldom are we 
> scrutinised by them. We are not the most active project, and 
> I feel that this sometimes causes James to be disregarded. 
> Likewise, apart from Avalon, we have few direct ties with 
> other jakarta projects, and little in common apart from the 
> language/platform and culture (but the culture is Apache)
> 
> The tlp issue is more about management than web-site and mail 
> addresses, I don't believe that james.apache.org will bring 
> many benefits, but I do think that normalising our managerial 
> relationship with Jakarta by becoming a sibling rather than a 
> child, and taking official control of all the issues we 
> currently inherit and "interpret" from Jakarta would benefit 
> James. The James PMC would be responsible to The Board.
> 
> I do believe that Jakarta is becoming too big to function as 
> a single project, that community and culture become diluted 
> as you descend the heirarchy and that one solution is for 
> mature projects leave the nest. Of course other projects are 
> free to make their own choices but as James consists 
> primarily of the server which is an end-user product I feel 
> that top level project status, emphasisng its purpose rather 
> then its technology, would suit it well.
> 
> The proposals being discussed on reorg & community include 
> the notion of federated projects, James, with the approval of 
> the Jakarta PMC, could continue to be associated with 
> Jakarta, I would like to think that we wouldn't be leaving 
> Jakarta, just growing up. I also know that James would 
> continue to rely on Jakarta for code, insight and cool 
> thinking, but we don't need to be a Jakarta sub-project for that.
> 
> It would also give us the opportunity, as Serge mentioned, to 
> better promote our sub-projects, theres Mailet, and mailets, 
> and there are the beginings of full blown mailet applications.
> 
> So.. we've had time to examine the issues, lets vote.. 
> 
> Should we prepare a proposal for submission to the board, 
> that James be elevated to a top level project?
> 
>[ ] +1  I think it's a good idea 
>[ ] +0  I'll accept the majority decision, stop bothering me
>[ ] -0  I have reservations 
>[ ] -1, I don't think its a good idea
> 
> 
> d.
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: performance figures w/ spool enabled

[Steve Short]

Defer, defer, defer.  There have been a number of issues with file
repositories in the past 9 months or so, and without a decent set of
regression tests you risk re-introducing old problems such as the
ConcurrentModificationException or the 0 size file.  At the moment they
are stable and working reasonably well - don't touch them - please.

There is already a todo list item tabled for v3.0 to revisit the
repostories (mailbox versus spoool queue repositories) and this would be
a better place for this work.

Regards
Steve

> -Original Message-
> From: Noel J. Bergman [mailto:noel@;devtech.com] 
> Sent: Monday, October 28, 2002 10:27 AM
> To: James Developers List
> Subject: RE: performance figures w/ spool enabled
> 
> 
> I'll give it a shot.  Mind you, one difference is that the 
> JDBC spool code is able to iterate through the first 1000 
> entries of the database, whereas each call to 
> loadPendingMessages() for the file system will have to clone 
> the entire HashSet again.  But if we can keep that down to 
> once or twice a minute instead of hundreds of times per 
> minute, it ought to help.
> 
> I'm going to pull the pending messages code into a common 
> class with an abstract load method.
> 
>   --- Noel
> 
> -Original Message-
> From: Peter M. Goldstein [mailto:peter_m_goldstein@;yahoo.com]
> Sent: Monday, October 28, 2002 12:23
> To: 'James Developers List'
> Subject: RE: performance figures w/ spool enabled
> 
> > Noel J. Bergman wrote:
> > > Serge wrote:
> > >   (2) Use the same approach found in JCBCSpoolRepository,
> > >   where we maintain a small cache of keys.  When the
> > >   list is exhausted, it is reloaded.  I believe that I
> > >   can pretty much clone the code from one to the other,
> > >   with the obvious change in populating the list.
> > >
> > > Are either of those approaches something that we want to undertake
> for
> > v2.1?
> > > Do you want to consider this a bug fix, or a performance 
> enhancement
> to
> > > defer?  I don't have a problem implementing the change, 
> but I don't
> want
> > to
> > > undertake it today if we don't want it until after the release.
> >
> > If you can get the code from JDBCSpoolRepository and pretty quickly
> get
> > this alternate approach running, then see how your 
> performance tests 
> > do... if it's an improvement, I would go ahead and put it 
> in.  In my 
> > mind it's known logic, so it's not that big of a deal.
> 
> I'm of the same mind as Serge on this one.  If the logic is 
> already written and has been shown to work, I say put it in.
> 
> --Peter
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Code change the Apache way

[Steve Short]

Given that you are going to commit this code, I don't see any benefit in
posting new updates without committing.  Surely we want to be testing
this as much as possible and this is much easier to do out of CVS rather
than CVS plus patches.

Regards
Steve 

> -Original Message-
> From: Peter M. Goldstein [mailto:peter_m_goldstein@;yahoo.com] 
> Sent: Friday, October 25, 2002 10:58 AM
> To: 'James Developers List'
> Subject: RE: Code change the Apache way
> 
> 
> 
> Danny,
> 
> > Are we near to seeing stuff commited.. ?
> > apart from the obvious fact that some contentious items can 
> be vetoed
> > *after* commit, I'd say that as long as it builds we should be
> commiting
> > often.
> 
> Noel and I are currently running more tests, and everything 
> is coming up green.  What I will do is post the latest, 
> greatest code for evaluation later today.  If the consensus 
> is that I should commit said code, I'll be more than happy to 
> do so.  I have simply been unwilling to do so over an outstanding -1.
> 
> --Peter
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Latest diffs, source code

[Steve Short]

Peter,

The class TimeoutWatchdogFactory is missing from this list.

Regards
Steve

> -Original Message-
> From: Peter M. Goldstein [mailto:peter_m_goldstein@;yahoo.com] 
> Sent: Saturday, October 19, 2002 2:01 PM
> To: 'James Developers List'
> Subject: Latest diffs, source code
> 
> 
> 
> All,
> 
> Attached is a set of source files and diffs that should allow 
> you to reproduce the code base that Noel and I have been 
> using for our latest testing.
> 
> The test ran for over seven hours, with a rate that started 
> close to ~3000 messages/minute and stabilized at ~2500 
> messages/minute.  We don't have a good explanation for this 
> change, but the system was under a great deal of stress 
> (logging, TCP/IP, etc.) that may have accounted for the 
> eventual degradation.
> 
> Total number of threads was stable at 112 for the first hour 
> or two, but grew to 162 threads after that and stabilized.  
> Analysis of the logs (~750 MB of them) confirmed that there 
> was no thread leak (all worker threads were reused as 
> expected over the course of the test run).  My suspicion is 
> that the growth in the thread pool size was a result of a 
> thread scheduler statistical anomaly (disposed but not exited 
> connection handler/watchdog threads) and is not an actual 
> cause for concern. Unfortunately this is difficult to confirm 
> or refute, but it matches the observed behavior.
> 
> Java heap size grew slowly over the course of the test, from 
> about 4.5 MB to about 5MB.  We don't see this as a real cause 
> for concern, considering the number of open resources, etc. 
> that the product was managing.
> 
> The code executing threads from the thread pool is now 
> appropriately wrapped in try/catch/finally blocks that ensure 
> that a temporarily empty thread pool does not constitute a 
> fatal error.  If a thread is unavailable, the connection will 
> simply be refused.  Obviously, if the thread pool is too 
> small (i.e. no threads available at any time to service 
> connections), then this will result in an unresponsive 
> server. But the current configuration has proved to be more 
> than adequate for our test.
> 
> Noel ended the test when he saw a notable performance 
> degradation (drop to <1000 messages/minute).  He later 
> discovered that some other work was being done on the same 
> server at that time that very well may have been responsible 
> for the drop in performance.  So we don't actually know what 
> caused this issue and it may not actually be an issue at all. 
>  If Noel and I can find the time we will attempt to run 
> another test to get info on this one way or another.
> 
> So here's the summary:
> 
> i) James' SMTP handler can process 2500-3000 messages/minute 
> consistently on a PII 400 MHz Celeron running Linux
> 
> ii) In the source of seven hours, over 1,000,000 messages 
> were pushed through the James SMTP service.
> 
> iii) There was no sign of the catastrophic memory leaks that 
> plagued earlier versions of James.
> 
> iv) There may be some outstanding "glitches" but they are 
> orders of magnitude less severe than the previous issues.
> 
> --Peter
> 
> 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Latest diffs, source code

[Steve Short]

Correction: the patch results in the RemoteManager trying to import and
declare a TimeoutWatchdogFactory which is not included in the list of
files.  However the RemoteManager is not actually using this so it can
be commented out.

Steve

> -Original Message-
> From: Steve Short 
> Sent: Monday, October 21, 2002 11:45 AM
> To: James Developers List
> Subject: RE: Latest diffs, source code
> 
> 
> Peter,
> 
> The class TimeoutWatchdogFactory is missing from this list.
> 
> Regards
> Steve
> 
> > -Original Message-
> > From: Peter M. Goldstein [mailto:peter_m_goldstein@;yahoo.com]
> > Sent: Saturday, October 19, 2002 2:01 PM
> > To: 'James Developers List'
> > Subject: Latest diffs, source code
> > 
> > 
> > 
> > All,
> > 
> > Attached is a set of source files and diffs that should allow
> > you to reproduce the code base that Noel and I have been 
> > using for our latest testing.
> > 
> > The test ran for over seven hours, with a rate that started
> > close to ~3000 messages/minute and stabilized at ~2500 
> > messages/minute.  We don't have a good explanation for this 
> > change, but the system was under a great deal of stress 
> > (logging, TCP/IP, etc.) that may have accounted for the 
> > eventual degradation.
> > 
> > Total number of threads was stable at 112 for the first hour
> > or two, but grew to 162 threads after that and stabilized.  
> > Analysis of the logs (~750 MB of them) confirmed that there 
> > was no thread leak (all worker threads were reused as 
> > expected over the course of the test run).  My suspicion is 
> > that the growth in the thread pool size was a result of a 
> > thread scheduler statistical anomaly (disposed but not exited 
> > connection handler/watchdog threads) and is not an actual 
> > cause for concern. Unfortunately this is difficult to confirm 
> > or refute, but it matches the observed behavior.
> > 
> > Java heap size grew slowly over the course of the test, from
> > about 4.5 MB to about 5MB.  We don't see this as a real cause 
> > for concern, considering the number of open resources, etc. 
> > that the product was managing.
> > 
> > The code executing threads from the thread pool is now
> > appropriately wrapped in try/catch/finally blocks that ensure 
> > that a temporarily empty thread pool does not constitute a 
> > fatal error.  If a thread is unavailable, the connection will 
> > simply be refused.  Obviously, if the thread pool is too 
> > small (i.e. no threads available at any time to service 
> > connections), then this will result in an unresponsive 
> > server. But the current configuration has proved to be more 
> > than adequate for our test.
> > 
> > Noel ended the test when he saw a notable performance
> > degradation (drop to <1000 messages/minute).  He later 
> > discovered that some other work was being done on the same 
> > server at that time that very well may have been responsible 
> > for the drop in performance.  So we don't actually know what 
> > caused this issue and it may not actually be an issue at all. 
> >  If Noel and I can find the time we will attempt to run 
> > another test to get info on this one way or another.
> > 
> > So here's the summary:
> > 
> > i) James' SMTP handler can process 2500-3000 messages/minute
> > consistently on a PII 400 MHz Celeron running Linux
> > 
> > ii) In the source of seven hours, over 1,000,000 messages
> > were pushed through the James SMTP service.
> > 
> > iii) There was no sign of the catastrophic memory leaks that
> > plagued earlier versions of James.
> > 
> > iv) There may be some outstanding "glitches" but they are
> > orders of magnitude less severe than the previous issues.
> > 
> > --Peter
> > 
> > 
> > 
> > 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:james-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:james-dev-help@;jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>

RE: [VOTE] Interface for resettable, time-guarded, operations

[Steve Short]

I don't get a vote either, but my non-vote is +1.

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, October 14, 2002 11:13 PM
> To: James-Dev Mailing List
> Subject: [VOTE] Interface for resettable, time-guarded, operations
> 
> 
> The question is: shall we adopt the Watchdog interface with a 
> choice of using either a dual or shared thread 
> implementation?  Advantages of the change have already been 
> presented, and include:
> 
>   1) Supports both dual-thread and shared-thread implementations.
>   2) Provides a standalone, reusable service that can be used in
>  non-Avalon situations.  I would suggest that we can donate
>  the code, so to speak, to Jakarta-Commons.  This is a very
>  useful, and oft-needed, facility.
>   3) Can easily be unit tested outside of an Avalon container.
> 
> The code has already been written to make this change, so 
> there is little effort to adopt the vote.  I don't see any 
> downside to adopting this interface, and because it allows 
> the choice of either implementation, both "camps" should be 
> satisfied.  Both Harmeet and Peter have told me, personally, 
> that they appreciate my efforts to mediate the issue.  This 
> is my best proposal.
> 
> I don't get a vote (and I am really beginning to regret 
> that), but my non-vote is +1.
> 
>   --- Noel
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Scheduler Interface

[Steve Short]

I'm not sure I can do anything to help you guys resolve this, but FWIW
here's my view.  I do not think that a scheduler is an appropriate
solution for implementing a connection timeout.  I was surprised when
Shilpa first incovered this how inefficient it was.  Apart from the
issue of running out of memory, the core mechanism necessitates adding a
new event object to a list every time the trigger is reset and its
eventual removal and garbage collection.  I do not think this is good
design for a scalable, enterprise quality mail server and I think that
Peter has made effective arguments against this.

Regards
Steve






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] Removing Scheduler dependency, refactoring service code

[Steve Short]

> When Andrei did his tests, he commented out the sendMail line 
> in SMTPHandler, so that he could isolate the Handler's issues 
> from the rest of James.  That is probably a good idea.

I wrote a NullSpool some time ago for this kind of testing without
needing to change the code and also so that I can use James as an SMTP
sink.  I've attached it here in case anyone else wants to use it.  Note
that it currently resides in package com.postx.james.store, but this is
trivial to change.  In order to configure James to use NullSpool, I
simply replace this:



With this:
 


In the   ... section of config.xml.

Note: the one time I tried to use James as an SMTP sink for James - it
didn't work! I got some exception which I never had time to track down.

Regards
Steve



NullSpool.java
Description: NullSpool.java

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: James/Avalon versions up-to-date?

[Steve Short]

See thread titled "[PATCH] Replace Component Classes with Service
Equivalents" for details.

> -Original Message-
> From: Brad Walker [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, October 07, 2002 11:40 AM
> To: 'James Developers List'
> Subject: James/Avalon versions up-to-date?
> 
> 
> Hi,
>  
> I was just wondering how far out of sync the HEAD version of 
> James is from the latest Avalon release. The reason I ask 
> this is that I recently did a build off of the latest Avalon 
> CVS tree, and it seems that the latest version of James isn't 
> compatible. Here is the error I get:
>  
> Caused by: java.lang.NoSuchMethodError: 
> org.apache.avalon.cornerstone.services.store.Store.select(Ljav
> a/lang/Object;
> )Lorg/apache/avalon/framework/component/Component;
>  
> From what I can tell, the latest version of AvalonMailStore 
> doesn't implement all of the methods of Store (apparently 
> there are new ones in the lastest Avalon build).
>  
> So I guess my questions are as follows:
> 1. Is what I have described really the case, or am I just 
> trying to think too much on a Monday ;)
> 2. If so, is there any reason that the James builds 
> haven't kept up with changes in Avalon
> 3. If not, is there any reason that I shouldn't be able 
> to dump the latest version of James into the latest version of Avalon?
>  
> Thanks for the input,
> Brad
>  
> ~~
> Brad D. Walker
> Sr. Software Engineer
> Student Advantage, Inc.
> 617-880-1737
>   
> mailto:[EMAIL PROTECTED]
>  
 http://www.studentadvantage.com
~~
 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] SMTPHandler logging

[Steve Short]

I think the Avalon components in James 2.0a3 have the required logging
support.  The newer mechanism is indicated by upping the version
attribute in the logs element in the environment.xml file.

Steve

> -Original Message-
> From: Alan Gerhard [mailto:[EMAIL PROTECTED]] 
> Sent: Saturday, October 05, 2002 8:26 AM
> To: 'James Developers List'
> Subject: RE: [PATCH] SMTPHandler logging
> 
> 
> yes, i recall. 
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg01
> 629.html 
> 
> i am running James 2.0a3 - the latest 'stable' version.
> to implement the changes described i would bump up to the 
> later version of avalon i suppose, and with a quick review of 
> this xml config file, it appears that a lot has changed with 
> reference to the logging. the avalon framework is great; 
> the logging mechanism for it's components is great too;
> the interdependencies between avalon and james is not so 
> great. in a sense, these logging issues really belong with 
> avalon and not with james, so, i can configure *avalon* "... 
> to log all messages to a single file, if it helps.  Examples 
> have been posted to this mailing list several times before." 
> that is if i understand 'avalon' correctly in being an 
> application server to launch other applications 
> 
> and to that i will and i am sure most of the issues i am 
> facing will go away.
> 
> however, has this new avalon been tested enough with james so 
> we can call it "stable", or is this really a non-issue ??
> 
> alan
> 
> 
> -Original Message-
> 
> > these multiple log files are not very informative nor consistant.
> 
> You can configure James to log all messages to a single file, 
> if it helps.  Examples have been posted to this mailing list 
> several times before.
> 
> Steve
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] SMTPHandler logging

[Steve Short]

> these multiple log files are not very informative nor consistant.

You can configure James to log all messages to a single file, if it
helps.  Examples have been posted to this mailing list several times
before.

Steve

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: logs

[Steve Short]

Yes that would do it.

Steve

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: logs

[Steve Short]

Yes - for me it started with the official Phoenix 4.0 release and does
not happen with the ealier betas.  I notified the Avalon developers
mailing list. 

Steve

> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, September 27, 2002 4:21 AM
> To: James Developers List
> Subject: logs
> 
> 
> All my logs seem to go into the default log now, anyone else 
> experiencing this?
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: We need a Wiki

[Steve Short]

Maybe this can be escalated to the Jakarta powers that be, how is this
done?

Steve

> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, September 27, 2002 12:22 AM
> To: James Developers List
> Subject: RE: We need a Wiki
> 
> 
> > Danny, any chance you can put one on mailet.org?
> 
> Not for discussing James dev, no.
> James is a Jakarta sub-project and IMHO there are some things 
> we should stick to, namely using the mailing lists for 
> communication and cvs for version control of source and docs.
> 
> A wiki to get doc contributions is a different matter.
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Release Plan

[Steve Short]

Is it the the memory leak due to Cornerstone creating new entries on
it's task list but not clearing them up until they 'expire'?

http://issues.apache.org/bugzilla/show_bug.cgi?id=9275
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02938.html

Steve

> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, September 26, 2002 2:27 PM
> To: James Developers List
> Subject: RE: Release Plan
> 
> 
> 
> > 2) Change code so that it doesn't use the TimeScheduler in the 
> > assorted server blocks (excluding the newly introduced FetchPOP)
> 
> Sorry, slightly off the topic of this thread, whats wrong 
> with TimeScheduler, and why is it OK for fetchpop, have I 
> missed something?
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-james build.xml

[Steve Short]

Question:  are the other comitters running James before comitting their
changes to CVS?  I don't mean this in a critical, negative way, and I
know it is easy to have jars lying around so stuff still works until you
do a cleanup, but when the Phoenix server doesn't even startup I feel
the question has to be asked.

Cheers
Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, September 26, 2002 4:52 AM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-james build.xml
> 
> 
> danny   2002/09/26 04:52:07
> 
>   Modified:.build.xml
>   Log:
>   now it actually runs...
>   
>   Revision  ChangesPath
>   1.111 +2 -2  jakarta-james/build.xml
>   
>   Index: build.xml
>   ===
>   RCS file: /home/cvs/jakarta-james/build.xml,v
>   retrieving revision 1.110
>   retrieving revision 1.111
>   diff -u -r1.110 -r1.111
>   --- build.xml   26 Sep 2002 00:39:23 -  1.110
>   +++ build.xml   26 Sep 2002 11:52:07 -  1.111
>   @@ -397,7 +397,7 @@
>
>
> basedir="${build.classes}" manifest="${src.dir}/Manifest.mf" 
> includes="org/apache/mailet/**"/>
>   - todir="${dist.dir}/lib"/>
>   +
>
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Phoenix 4.0 final pushed up.

[Steve Short]

Yes it's:

 java.lang.NoClassDefFoundError: javax/mail/internet/ParseException

It can't work with mailet.jar in the phoenix/lib directory and
mail_1_2.jar in the James SAR because this means that mailet.jar is
loaded by the extenation ClassLoader and mail_1_2.jar is loaded by the
Phoenix PolicyClassLoader. Since the PolicyClassLoader is higher in the
delegation chain, mailet.jar cannot load any javax.mail.* classes.

I've since read Peter's mail which says he added the mailet classes into
james.jar file and this approach also works, but only if the mailet.jar
file does not also exist in the phoenix/lib.  The current build.xml file
builds a separate mailet.jar file and then copies it into ${dist}/lib,
i.e. the target phoenix/lib dir.

Steve

> -Original Message-
> From: Paul Hammant [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, September 25, 2002 3:14 PM
> To: James Developers List
> Subject: Re: Phoenix 4.0 final pushed up.
> 
> 
> Steve,
> 
> >I tried this with a clean checkout and build and I'm afraid 
> it doesn't 
> >work.  I think you need to move mailet.jar back into the james.sar 
> >file, path SAR-INF/lib.
> >  
> >
> What did not work dude?  What were the exceptions logged?  
> 
> I was able to launch Phoenix and poke things thru the NNTP 
> server, I'm 
> going to need some advice on how to configure a local-loop 
> SMTP test so 
> that this does not happen again (no unit tests for that?).
> 
> Could you test the moving back of the mailet jar into the primordial 
> class loader (what phoenix/lib becomes)
> 
> - Paul
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Phoenix 4.0 final pushed up.

[Steve Short]

Paul,

I tried this with a clean checkout and build and I'm afraid it doesn't
work.  I think you need to move mailet.jar back into the james.sar file,
path SAR-INF/lib.

Cheers
Steve

> -Original Message-
> From: Paul Hammant [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, September 25, 2002 2:33 PM
> To: James Developers List
> Subject: Phoenix 4.0 final pushed up.
> 
> 
> Folks,
> 
> Phoenix 4.0
> ---
> 
> I have committed Avalon-Phoenix 4.0 to CVS.
> I have not touched Avalon-Conerstone
> I have moved activation.jar, mail_1_2.jar and commons-net.jar to 
> /lib as that is the correct place for them. I have updated the 
> build script for that.
> 
>   - Have your folks considered the license conditions from 
> Sun for the 
> two Sun jars?  They differentiate between the rules concerning CVS 
> listing versus, the availability of the same jar in a 'finished 
> product'.  i.e. it may be OK for you to include them in james.sar (if 
> available as a download) or in james-bin.zip.
> 
> JMX
> ---
> 
> MX4J is launched on start of Phoenix.  It listens on 
> localhost:8082, and 
> is bound to localhost.  You can turn it off in kernel.conf.  There is 
> bugger-all managable in James, though it is really easy to setup.
> 
> Wrapper
> ---
> 
> The wrapper project's Windows executables are included.  This 
> allows you 
> to install James to the Windows Services (see control panel).  To do 
> this do:
> 
>   wrapper -i ..\conf\wrapper.conf
> 
> You can then start stop James from the control panel, or 
> command line :
> 
>   net start James
>   net stop James
> 
> It will relaunch if it abends (I have tested this for other 
> sars and it 
> is cool).
> 
> I have not done any work for Unix, as I cannot test this.  Volunteers?
> 
> Regards,
> 
> - Paul
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] Replace Component Classes with Service Equivalents

[Steve Short]

I agree, although I submitted the patch and have no voting status within
Avalon.  I had no idea it was going to be such a problem for James,
especially since I warned them days before that I was going to do it and
noone even commented!

Apologies for the inconvenience.

Cheers
Steve

> -Original Message-
> From: Leo Simons [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, September 25, 2002 3:59 AM
> To: Avalon Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCH] Replace Component Classes with Service 
> Equivalents
> 
> 
> Following lots of discussion with regard to this change on 
> james-dev currently going on, I feel I need to -1 this change 
> until at least the next major release for Cornerstone (ie 
> until 5.0), as it breaks backward compatibility.
> 
> Rationale
> -
> Some projects (ie JAMES) expose the ComponentManager 
> interface, and hence the Component interface, as part of 
> their API, while also depending on some of the cornerstone 
> components and exposing these through the ComponentManager by 
> contract. Hence, removing Component and ComponentManager from 
> Cornerstone means that this client API breaks.
> 
> We should be supportive of our fellow developers at JAMES -- 
> and any other projects with a similar concern -- and give 
> them the time to handle this issue gracefully.
> 
> We should, however, formally deprecate the pieces in 
> Cornerstone that depend on the Component (& friends) 
> interfaces, and indicate that they will move to 
> ServiceManager in the future, if we still want to continue 
> with this change.
> 
> 
> Impact
> --
> This means that containers that want to be able to host the 
> Cornerstone components (ie Phoenix, Merlin) need to keep 
> supporting Component/Composable and friends. This is a good thing =)
> 
> best regards,
> 
> Leo Simons
> 
> On Tue, 2002-09-24 at 14:21, Peter Donald wrote:
> > Applied - thanks!
> > 
> > On Tue, 24 Sep 2002 08:58, Steve Short wrote:
> > > Following my email a few days ago - here is a patch to replace 
> > > Component Classes with Service Equivalents in Cornerstone Store, 
> > > RepositoryManager and AbstractFileRepository.  Diff 
> generated using 
> > > cvs diff -u at top level jakarta-avalon-cornerstone directory.
> > >
> > > Regards
> > > Steve
> > >
> > >  <>
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:james-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [PATCH] Replace Components with Services

[Steve Short]

Yes - replace ComponentManager with SystemManager.  I do not think is as
big a deal as you do.

Steve

> -Original Message-
> From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, September 24, 2002 4:05 PM
> To: 'James Developers List'
> Subject: RE: [PATCH] Replace Components with Services
> 
> 
> 
> Steve,
> 
> > It is an unfortunate situation, but I think the path that will cause
> the
> > least pain now and in the future is to bite the bullet and do it.
> There
> > aren't too many mailets that use a ComponentManager / ServiceManager
> and
> > for those the code change is trivial.
> 
> But that's exactly the question - do what?  Replace 
> ComponentManager with ServiceManager?  Is this our permanent 
> solution (very -1)?  If not, how do we present it to our user 
> base?  When do we expect to have a permanent solution?
>  
> > Let's not get into forked Cornerstone or being tied to prehistoric 
> > releases of Avalon packages, both of which will just lead 
> to more and 
> > more compatibility problems.  James needs to be able to move up to
> newer
> > releases of these packages as easily as possible.
> 
> Absolutely agree.
>  
> > As far as backwards compatibility is concerned, this is partially
> blown
> > already with the enabled flag required in  config files so existing 
> > config files will no longer work.  Admittedly this is much 
> easier to 
> > fix.
> 
> There is a huge difference here.  Basically we can (and 
> should) write some simple XML transform code to change the 
> config file as necessary. Even if we don't do this, any 
> administrator can be instructed to do minor adjustments to 
> their config file.
> 
> Changing APIs is an entirely different order of magnitude.
> 
> --Peter
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] Replace Components with Services

[Steve Short]

It is an unfortunate situation, but I think the path that will cause the
least pain now and in the future is to bite the bullet and do it.  There
aren't too many mailets that use a ComponentManager / ServiceManager and
for those the code change is trivial.

Let's not get into forked Cornerstone or being tied to prehistoric
releases of Avalon packages, both of which will just lead to more and
more compatibility problems.  James needs to be able to move up to newer
releases of these packages as easily as possible.

As far as backwards compatibility is concerned, this is partially blown
already with the enabled flag required in  config files so existing
config files will no longer work.  Admittedly this is much easier to
fix.

Regards
Steve

> -Original Message-
> From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, September 24, 2002 3:44 PM
> To: 'James Developers List'
> Subject: RE: [PATCH] Replace Components with Services
> 
> 
> 
> Paul,
> 
> > With the greatest of respect, your users are far smaller in number
> that
> > those to say Servlet (or those to say jdbc - a real balls-up of 
> > backwards compatability)
> 
> I absolutely agree with you.  But it doesn't really matter.  
> We haven't given any notice to our user base, no matter how 
> small that base might be.  That's the problem.
> 
> Part of evolving into an enterprise piece of software is 
> being attentive to the user base, both at the beginning and 
> as it grows.  That means you don't do things like this.  
> Otherwise you have trouble getting to the point where you 
> carry a large customer base with you.
> 
> > I myself, might devise an API that has a custom 'lifecyle' 
> methods for 
> > mailets :-
> ...
> > Anyway, that is abig subject that embraces many IoC concerns, and 
> > definately breaks back-compatability.
> 
> Exactly.  It's a big subject, requiring a lot of discussion.  
> And I think it's clear that the James developers don't have a 
> consensus on this one (see the Mailet logging discussion for 
> reference).  This will require lots of discussion and time - 
> IMHO we shouldn't do this before 2.2.
>  
> > >Ok, so that's the argument for preserving as much backwards 
> > >compatibility as possible.  So why don't we just leave the code as
> is,
> > >compiling and running against frozen versions of these 
> > >libraries/containers from a particular date?
> > >
> > Could do.  Stephen offers to maintain the forked Cornerstone.
> 
> Personally I'd -1 this one.  For all the reasons I list.
>  
> > I have pointed out that the wrapper solution, though 
> clever, will not 
> > work for two of the mailets in James codebase ( JDBCAlias and 
> > JDBCListserv ).
> > 
> 
> This is taken care of by (iii) and (iv).  We can add (v), but 
> my concern is custom written mailets, not core code base.  As 
> (iii) states, the ServiceManager is exposed analogously to 
> the component manager.  As (iv) states, all code stored in 
> the James CVS would be migrated.  That includes the JDBCAlias 
> and JDBCListserv.  So (v) is unnecessary to deal with these 
> mailets.  It's only necessary if custom mailets are using the 
> DataSourceSelector.  Not necessarily a bad idea, just doesn't 
> solve the generic problem.
> 
> --Peter
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] Replace Components with Services

[Steve Short]

I agree.  If James has to keep any references to Component then we
needn't bother doing any changes at all. Component is currently
deprecated and presumably it will be remove entirely in future release.

Steve

> -Original Message-
> From: Paul Hammant [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, September 24, 2002 1:00 PM
> To: James Developers List
> Subject: Re: [PATCH] Replace Components with Services
> 
> 
> Peter,
> 
> >As we've discussed before on the james-dev list, it's a little more 
> >indepth than this patch addresses.
> >
> > 
> >
> >i) The Mailet API is to remain invariant 
> - that is,
> >mailets must be able to access the same components as 
> previously using 
> >the component manager that was provided to them through the 
> >MailetContext.
> >
> >ii)   Point (i) requires that all James services
> >continue to implement the Component marker interface.  No 
> biggie, it's 
> >just a marker interface
> >
> True, but it has been eliminated from Cornerstone in Apache 
> HEAD CVS.  
> 
> >iii)  Point (i) also requires that we use an
> >AdaptingComponentManager (sic?) to wrap the ServiceManager 
> and provide 
> >components to the mailets.
> >  
> >
> (wrapping) Perfectly possible. but .
> 
> Take init() from org.apache.james.transport.mailets.ToRepository
> 
> ComponentManager compMgr = 
> (ComponentManager)getMailetContext().getAttribute(Constants.AV
ALON_COMPONENT_MANAGER);
> try {
> MailStore mailstore = (MailStore) 
> compMgr.lookup("org.apache.james.services.MailStore");
> 
> 1) If MailStore extends Component this will work.
> 
> Well it does not anymore, it extends Cornerstone's store, but 
> you have 
> the source for MailStore, so can to "extends Store, Component".
> 
> 2) If all ComponentManager looked up things are in your 
> codebase, then 
> you have a strategy in (1).
> 
> Well, that is not true, JDBCAlias (and JDBCListserv) returns 
> DataSourceSelector on lookup, which is in Cornerstone's CVS.  
> You could 
> invent JamesDataSourceSelector which wraps the Cornerstone 
> one and adds 
> an impl of Component, then it it will work fine, but it changes the 
> JDBCAlias source, which breaks the backwads compatible directive.
> 
> >If it weren't for these little issues, we'd probably have 
> gotten to it 
> >a while back.  If you'd like, you can update the patch to 
> address these 
> >issues and resubmit.  Thanks.
> >  
> >
> The patch can be fixed as per the strategy outlines in (1) and (2) 
> above.  It will mean that the DataSourceSelector usage will end, but 
> that is only two mailets in your codebase.
> 
> If I were you I'd decomission ComponentManager completely for 
> the sake 
> of ServiceManager (Component for Object, and Composable for 
> Serviceable).  It is a brave step and does break backwars 
> compatability, 
> but it is very nearly a word replacement issue for the user 
> community. 
>  If James mailets were distributed as shrink wrapped, then 
> you'd have a 
> problem, but they are not.
> 
> You choice, I'm an honarary committer here (my capacity is limited to 
> Phoenix related issues).
> 
> Regards,
> 
> - Paul
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] Replace Components with Services

[Steve Short]

Cool - are these made available to the public or only internally to
Avalon folk?

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, September 24, 2002 11:17 AM
> To: James Developers List
> Subject: RE: [PATCH] Replace Components with Services
> 
> 
> Steve,
> 
> Paul Hammant provides the relevant Avalon binaries for 
> inclusion in James.
> 
>   --- Noel
> 
> -Original Message-
> From: Steve Short [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 24, 2002 14:02
> To: James Developers List
> Subject: RE: [PATCH] Replace Components with Services
> 
> 
> Er, I'm not sure what you mean by 'produced' though, as far 
> as I can tell cornerstone binaries are never made available.
> 
> > -Original Message-
> > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, September 24, 2002 10:58 AM
> > To: 'James Developers List'
> > Subject: RE: [PATCH] Replace Components with Services
> > 
> > 
> >  
> > 
> > Steve,
> > 
> >  
> > 
> > Have the Avalon folks made the relevant updates to the
> > cornerstone classes and produced a corrected cornerstone.jar?
> > 
> >  
> > 
> > --Peter
> > 
> >  
> > 
> > -Original Message-
> > From: Steve Short [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, September 24, 2002 10:46 AM
> > To: [EMAIL PROTECTED]
> > Subject: [PATCH] Replace Components with Services
> > 
> >  
> > 
> >  
> > 
> > Here is a patch for the latest CVS James (as of 10 AM PST
> > today) to replace the use of Component classes with their 
> > Service equivalents. Note that this will requires a new 
> > version of Cornerstone from CVS.
> > 
> > Regards
> > Steve 
> > 
> > <>
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:james-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [PATCH] Change PoolConnEntry to work in IDEs

[Steve Short]

Scratch that - it was plain stupid!

-Original Message-
From: Steve Short 
Sent: Tuesday, September 24, 2002 11:09 AM
To: [EMAIL PROTECTED]
Subject: [PATCH] Change PoolConnEntry to work in IDEs




I've modified PoolConnEntry so that the conditional JDBC3 comments work
inside a regular IDE without breaking the existing ant build. Like this:


// /* JDBC_3_ANT_KEY 
...conditional code... 
// JDBC_3_ANT_KEY */ 


Steve 


<> 

[PATCH] Change PoolConnEntry to work in IDEs

[Steve Short]

Title: [PATCH] Change PoolConnEntry to work in IDEs







I've modified PoolConnEntry so that the conditional JDBC3 comments work inside a regular IDE without breaking the existing ant build. Like this:


    // /* JDBC_3_ANT_KEY

    ...conditional code...

    // JDBC_3_ANT_KEY */



Steve



 <> 





PoolConnEntry.java.diff
Description: PoolConnEntry.java.diff

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] Replace Components with Services

[Steve Short]

Er, I'm not sure what you mean by 'produced' though, as far as I can
tell cornerstone binaries are never made available.

> -Original Message-
> From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, September 24, 2002 10:58 AM
> To: 'James Developers List'
> Subject: RE: [PATCH] Replace Components with Services
> 
> 
>  
> 
> Steve,
> 
>  
> 
> Have the Avalon folks made the relevant updates to the 
> cornerstone classes and produced a corrected cornerstone.jar?
> 
>  
> 
> --Peter
> 
>  
> 
> -Original Message-
> From: Steve Short [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, September 24, 2002 10:46 AM
> To: [EMAIL PROTECTED]
> Subject: [PATCH] Replace Components with Services
> 
>  
> 
>  
> 
> Here is a patch for the latest CVS James (as of 10 AM PST 
> today) to replace the use of Component classes with their 
> Service equivalents. Note that this will requires a new 
> version of Cornerstone from CVS.
> 
> Regards 
> Steve 
> 
> <> 
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [PATCH] Replace Components with Services

[Steve Short]

Yes.  I submitted a patch yesterday and it has already been applied.

> -Original Message-
> From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, September 24, 2002 10:58 AM
> To: 'James Developers List'
> Subject: RE: [PATCH] Replace Components with Services
> 
> 
>  
> 
> Steve,
> 
>  
> 
> Have the Avalon folks made the relevant updates to the 
> cornerstone classes and produced a corrected cornerstone.jar?
> 
>  
> 
> --Peter
> 
>  
> 
> -Original Message-
> From: Steve Short [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, September 24, 2002 10:46 AM
> To: [EMAIL PROTECTED]
> Subject: [PATCH] Replace Components with Services
> 
>  
> 
>  
> 
> Here is a patch for the latest CVS James (as of 10 AM PST 
> today) to replace the use of Component classes with their 
> Service equivalents. Note that this will requires a new 
> version of Cornerstone from CVS.
> 
> Regards 
> Steve 
> 
> <> 
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Component / Service Change

[Steve Short]

FYI I've updated James locally to use the Service classes from Avalon
instead of the Component classes.  I also had to modify Cornerstone so I
need to find out what the Avalon folks want to do about the Cornerstone
change before I can submit the James changes.

Cheers
Steve

RE: Latest CVS Broken

[Steve Short]

Yes - that's it.

Danny, do you have cornerstone on your classpath, extenstion classpath
or in james.sar file?  'cos it's definitely missing when I do a clean
CVS checkout and build.

Steve

> -Original Message-
> From: Stefano Debenedetti [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, September 20, 2002 4:23 PM
> To: James Developers List
> Subject: Re: Latest CVS Broken
> 
> 
> Please find attached a copy of the error I get at startup 
> time with the 
> latest cvs snapshot, manually copying conerstone.jar into 
> build/lib and 
> relaunching the build script solved the issue
> ciao
> ste
> 
> Danny Angus wrote:
> > Hmm... hate to say, works for me, but it does, what do you think is 
> > going wrong that this fixes? d.
> > 
> > 
> >>-Original Message-
> >>From: Steve Short [mailto:[EMAIL PROTECTED]]
> >>Sent: 20 September 2002 22:08
> >>To: [EMAIL PROTECTED]
> >>Subject: Latest CVS Broken
> >>
> >>
> >>
> >>The latest CVS version of James will not run.  You need to copy 
> >>cornerstone.jar into the Phoenix distribution lib directory.
> >>
> >>Cheers
> >>Steve
> >>
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> <mailto:james-dev-> [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > <mailto:[EMAIL PROTECTED]>
> > 
> > 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Latest CVS Broken

[Steve Short]

The latest CVS version of James will not run.  You need to copy
cornerstone.jar into the Phoenix distribution lib directory.

Cheers
Steve

RE: New "latest"

[Steve Short]

It would be good to have a James plugins directory, but I think the way
Phoenix manages the ClassLoaders for the application (James) makes this
difficuly, in fact I think the application plugin concept would need to
be implemented inside Phoenix.  It is easy to create a ClassLoader that
will allow James to load matchers and mailets from a plugins directory,
but if you also want to add Avalon Components (as I do), these need to
be visible to the ClassLoader that Phoenix uses to load Avalon
components, and Phoenix would not be able to see the James plugins
directory.  I guess if we restrict plugins to matchers/mailets though
this would work fine.

Steve

> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, September 19, 2002 9:07 AM
> To: James Developers List
> Subject: New "latest"
> 
> 
> Hi,
> 
> I've made a new latest build, because I just noticed that it 
> isn't currently possible for end-users to "drop" mailet jars 
> into /lib/ and have them picked up by the mailet loader.
> 
> This is something that I got concerned about if we're going 
> to try to kick start a 3rd party mailet community at 
www.mailet.org, something that seems to be generating its own inertia,
so I've moved some jars, in particularly Mailet and Mail into
phoenix-lib. I also moved some commonly used avalon ones; cornerstone,
excalibur-datasource. And activation which just wanted to be there.

This now means that any mailet packages in a jar archive can be simply
dropped into ~installdir/lib/ and the classes will be found by the
mailet/matcher loader, either with appropriate  and
 elements, or as fully qualified classnames.


d.


--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Local vs Remote delivery failures

[Steve Short]

We have a version of RemoteDelivery that takes a configurable processor
name for routing bounce messages to. I haven't submitted it because it
was a bit of a hack, I lifted the bounce method out of James.java and
made it use an optional bounceProcessor parameter.  

But my point is that the idea works well and it's pretty easy to
implement.

Steve



> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, September 06, 2002 8:51 AM
> To: James Developers List
> Subject: Re: Local vs Remote delivery failures
> 
> 
> Yeah, I like that idea of a bounce processor for the RemoteDelivery.
> 
> So the thing is, the LocalDelivery mailet DOESN'T handle a bounce 
> condition.  The process that calles LocalDelivery is supposed 
> to check 
> that this is a valid mailbox before calling LocalDelivery to 
> store it... 
> the code you are looking at in LocalDelivery (that's sending 
> it to the 
> error processor) should only get used if the mail repository 
> is corrupt 
> or there's some other configuration error.  You use a matcher before 
> calling LocalDelivery so that you can then handle delivering 
> to default 
> mailboxes or a custom bounce or what-have-you.
> 
> RemoteDelivery also has a few states and additional info 
> because it will 
> contain who it was trying to connect to and the error messages. 
> RemoteDelivery also has retries in certain cases, you actually have a 
> variety of "bounce"-esque conditions... I've seen some servers give a 
> warning notice when a message doesn't deliver immediately and 
> gets put 
> in the try-again-later bucket.
> 
> Anyway, just some thoughts... please feel free to improve on 
> it however 
> you think best.  I'm still too busy besides lurking and moderating. :(
> 
> -- 
> Serge Knystautas
> Loki Technologies - Unstoppable Websites http://www.lokitech.com
> 
> Danny Angus wrote:
> > worthwhile, yes.
> > 
> > Although the mailet API has bounce() in the mailet context 
> I'm pretty 
> > sure that creating a bounce processor which would allow people to 
> > configure bounces would be worthwhile. I think you'd have 
> to alter all 
> > the bounce() methods to send their mail to the bounce processor 
> > though.
> > 
> > 
> > 
> >>-Original Message-
> >>From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> >>Sent: 06 September 2002 15:46
> >>To: James Developers List
> >>Subject: RE: Local vs Remote delivery failures
> >>
> >>
> >>
> Why isn't the handling consistent?
> >>>
> >>>probably because this is an Open Source project, and any number of
> >>
> >>different
> >>
> >>>people have any number of different ideas.
> >>
> >>That was my first thought, but checking the code and CVS first, it 
> >>appeared to come from the same origin.  So I thought that 
> there might 
> >>be some deeper
> >>reason for why it was handled two different ways; a reason 
> I had missed.
> >>
> >>Similarly with my question about instrumenting LocalDelivery and 
> >>RemoteDelivery to accept a processor name for failure 
> notification.  I 
> >>wasn't making the assumption that it hadn't been considered in the 
> >>past. Instead I was asking.
> >>
> >>Should I take your responses to mean that you don't know of any 
> >>reasons for the difference, and that you believe it might be 
> >>worthwhile (post-2.1?) to make such a change?
> >>
> >>--- Noel
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Lots of twisty, er, servers all the same ...

[Steve Short]

Not sure about this, but they may be doing some kind of load balancing.
I'd suggest not condensing the MX records based on IP address.

Steve

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, August 19, 2002 8:48 PM
> To: James-Dev Mailing List
> Subject: Lots of twisty, er, servers all the same ...
> 
> 
> As you can see from the nslookup of ATT.NET that follows, 
> they have lots of MX records, all the same IP address.  On 
> nights like tonight when AT&T is jammed, this can block a 
> delivery thread for over an hour.
> 
> Is there a reason why getMailServers [actually, 
> DNSServer.findMXRecords()] should not return a collection 
> containing only one entry per IP address?
> 
>   --- Noel
> 
> > set q=mx
> > att.net
> Server:  MACU.MA.MT.NP.ELS-GMS.att.net
> Address:  199.191.145.136
> 
> att.net MX preference = 5, mail exchanger = gateway1.att.net 
> att.net MX preference = 5, mail exchanger = gateway2.att.net 
> att.net MX preference = 5, mail exchanger = gateway3.att.net 
> att.net MX preference = 5, mail exchanger = gateway4.att.net 
> att.net MX preference = 5, mail exchanger = gateway5.att.net 
> att.net MX preference = 5, mail exchanger = gateway6.att.net 
> att.net MX preference = 5, mail exchanger = gateway8.att.net 
> att.net nameserver = ohcu.oh.mt.np.els-gms.att.net att.net 
> nameserver = macu.ma.mt.np.els-gms.att.net att.net nameserver 
> = orcu.or.br.np.els-gms.att.net att.net nameserver = 
> wycu.wy.br.np.els-gms.att.net
> gateway1.att.netinternet address = 204.127.134.23
> gateway2.att.netinternet address = 204.127.134.23
> gateway3.att.netinternet address = 204.127.134.23
> gateway4.att.netinternet address = 204.127.134.23
> gateway5.att.netinternet address = 204.127.134.23
> gateway6.att.netinternet address = 204.127.134.23
> gateway8.att.netinternet address = 204.127.134.23
> ohcu.oh.mt.np.els-gms.att.net   internet address = 199.191.144.75
> macu.ma.mt.np.els-gms.att.net   internet address = 199.191.145.136
> orcu.or.br.np.els-gms.att.net   internet address = 199.191.129.139
> wycu.wy.br.np.els-gms.att.net   internet address = 199.191.128.43
> >
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Bizzarre new bug...

[Steve Short]

Maybe he sent his message via James, so his ? got changed to a ?.

Steve

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, August 19, 2002 11:56 AM
> To: James Developers List
> Subject: RE: Bizzarre new bug...
> 
> 
> I'm lost.  What is the problem?  "? is being changed to ?"
> 
> As for the message body being recycled, isn't that what 
> happens (not looking at the code) when a new Mail object is 
> created for a given subset of recipients?
> 
> I'm sorry, but I really have no idea what this is about.
> 
>   --- Noel
> 
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 14:19
> To: James Developers List
> Subject: Bizzarre new bug...
> 
> 
> ? is being changed to ? in mail handled by James, in 
> particular the message body is being re-cycled into a new message.
> 
> Odd.
> d.
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: What do we need to release 2.1?

[Steve Short]

> As a courtesy, I'll reply to this note off-list.

Just as it was getting interesting :)

Steve

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: handling connection vs sheduler problem

[Steve Short]

Agreed,  I think using the socket timeout option is the way to go. I don't see any 
advantage in implementing a manual timeout solution.  One less moving part to go wrong 
and less overhead because we remove the SchedulerNotifyInputStream.

Regards
Steve

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: Sunday, August 11, 2002 3:59 PM
> To: James Developers List
> Subject: RE: handling connection vs sheduler problem
> 
> 
> Andrei,
> 
> What issue do you have with using socket timeout?  Is it not 
> reliable enough for you?  In the case of his problem, calling 
> it fixes a platform specific problem, and should be neutral 
> for other platforms.
> 
> I've looked at replacing the DefaultTimeScheduler with 
> something more appropriate for James, but I haven't had time 
> to do it yet.
> 
>   --- Noel
> 
> -Original Message-
> From: Andrei Ivanov [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, August 11, 2002 18:10
> To: James Developers List
> Subject: handling connection vs sheduler problem
> 
> 
> Hi
> I don't think that setting socket timeout will help to solve 
> scheduler problem. It is not possible to control connection 
> by setting socket timeout. As it was several times mentioned 
> before scheduler isn't designed to be used as in James 
> servers. It is nice and elegant solution, I mean 
> ShedulerNotifyînputStream, but it results in overhead we know 
> about. The solution is in cornerstone connection classes 
> which create connection handlers for James. My idea is to 
> adapt (modify) cornerstone connection classes by adding 
> connection control facilities.
> 
> About cornerstone. I've been using different cornerstone 
> blocks a lot for my project. I can say that cornerstone is 
> well written and reliable library. On the other hand for 
> complex and particular phoenix based applications (like
> James) cornerstone shall be considered more as guideline than 
> ready to use solution. If we really want to improve James we 
> shall adapt cornerstone for James (but not James for 
> cornerstone as it is now)
> 
> Andrei
> 
> - Original Message -
> From: "Noel J. Bergman" <[EMAIL PROTECTED]>
> To: "James Users List" <[EMAIL PROTECTED]>
> Sent: Monday, August 12, 2002 12:04 AM
> Subject: RE: Admin problem
> 
> 
> > I have no problem with the socket.setSoTimeout(timeout) call.  We 
> > should start making more use of setSoTimeout elsewere, and wean 
> > ourselves off of the scheduler.
> >
> > With respect to the logging, I think that only the one 
> where we echo 
> > the timeout is necessary, not the one where we log it for each 
> > connection.
> >
> > Would you please submit a [PATCH] to James-Dev?
> >
> > --- Noel
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For 
> additional commands, e-mail: 
> 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: memory leak in scheduler in 2.0a3, is this fixed?

[Steve Short]

He's talking about this (copied from a mail I sent to Paul Hammant about
a week ago).:

The DefaultTimeScheduler bug,
http://issues.apache.org/bugzilla/show_bug.cgi?id=9275, has crept up
again in the James developer list and Noel suggested I contact you
regarding a fix for this.  Do you have any news ?

Just to overwhelm you with information :), 
Original James Dev thread
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02216.html
Orignal Avalon Dev thread
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg08676.html 

New James Dev thread titled Handler timeout/trigger  (can't find in
archive to provide URL)

Regards
Steve

> -Original Message-
> From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] 
> Sent: Saturday, August 10, 2002 5:26 PM
> To: 'James Developers List'
> Subject: RE: memory leak in scheduler in 2.0a3, is this fixed?
> 
> 
> 
> Hontvari,
> 
> Some more detail here would really help.  A link to the 
> messages in the mail archive you mention would be great.
> 
> Whether or not this issue has been addressed, I personally 
> don't feel that we're in a position to release a new version. 
>  There is some substantial bug fixing to be done (closing all 
> the open James bugs) as well as some new features that are on 
> the immediate horizon (most notably IMAP).  We also need to 
> validate and roll in all uncommitted patches that have been 
> posted to the group (catching up nicely on this one - we've 
> got one really big one left AFAIK).  I'd say that once those 
> tasks are complete we'd be in a position to talk about a new 
> version. Of course, that's just my opinion.
> 
> --Peter
> 
> > -Original Message-
> > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, August 10, 2002 5:13 PM
> > To: James Developers List
> > Subject: RE: memory leak in scheduler in 2.0a3, is this fixed?
> > 
> > Which memory leak?  We've done a lot of work in the CVS on resource
> leaks.
> > Have we fixed the specific one you spotted?  I don't know, 
> because it
> is
> > possible we missed one.  Can you be more specific?
> > 
> > --- Noel
> > 
> > -Original Message-
> > From: Hontvari Jozsef [mailto:[EMAIL PROTECTED]]
> > 
> > There is a memory leak related to SMTPHandler and Avalon scheduler.
> When
> > handling a large number of emails this consumes the entire memory
> after a
> > few hours. Is this fixed in the meantime?
> > 
> > I tracked down this leak using hrprof and also read about 
> this in the
> mail
> > archive, but I cannot find wheter it is solved or not in the newer 
> > version.
> > 
> > If it s solved wouldn't it be time to release a new version?
> > 
> > 
> > --
> > To unsubscribe, e-mail:    > [EMAIL PROTECTED]>
> > For additional commands, e-mail:  > [EMAIL PROTECTED]>
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PATCH] 2. attempt - FAQ - How to remove unneeded services like NNTP,POP?

[Steve Short]

Looks good, tried it, it works.

> -Original Message-
> From: Hontvari Jozsef [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, August 09, 2002 10:35 AM
> To: 'James Developers List'
> Subject: [PATCH] 2. attempt - FAQ - How to remove unneeded 
> services like NNTP,POP?
> 
> 
> I posted this a week ago, but haven't got any reaction. It is 
> really short, it can be read easily - please take a look on it :-)
> 
> 
> - Original Message -
> From: "Hontvari Jozsef" <[EMAIL PROTECTED]>
> To: "'James Developers List'" <[EMAIL PROTECTED]>
> Sent: Thursday, August 01, 2002 12:34 PM
> Subject: [PATCH] FAQ - How to remove unneeded services like NNTP, POP?
> 
> 
> > patch is attached with a new faq entry. Feel free to correct it, 
> > including my English.
> >
> >
> 
> 
> 
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Changes to database table structure and class Mail

[Steve Short]

Add the retry count as a distinct field.  The error message field is
currently used for this.

Steve

> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, August 01, 2002 2:33 PM
> To: James Developers List
> Subject: [VOTE] Changes to database table structure and class Mail
> 
> 
> Serge,
> 
> re: 
> http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02862.html
> 
> I can add a serializable Map (probably a HashMap) to Mail, 
> and I can write a utility to convert the database format to 
> account for the table change(s).
> 
> Do I need a vote on this?  I'd like not to do all the work, 
> and have the concept voted down.
> 
> Specifically, we are proposing that org.apache.mailet.Mail 
> now include support for a Map allowing attributes to be 
> dynamically associated with mail instances.  These attributes 
> are different from X- headers, and are intended to be provide 
> internal (and unforgable) communication of metadata within 
> the James server.
> 
> The map can be exposed via explicit methods, a la the Servlet API:
> 
>public void setAttribute(String, Object);
>public Object getAttribute(String);
>public Object removeAttribute(String);
>public Enumeration getAttributeNames();
> 
> by exposing the Map:
> 
>public Map getAttributes();
> 
> or by being a Map:
> 
>public interface Mail extends Serializable, Cloneable, Map
> 
> I know what my suggestion would be, but I'm opening the topic 
> for discussion.  Regardless of how we expose it, the new Map 
> would be stored as a BLOB in the table, thus stored/retrieved 
> as a unit.
> 
> Next, Serge is proposing that the error message be moved from 
> a separate field to the attribute map.  My proposal would be 
> that any such properties be added to the Map, and have their 
> set/get methods deprecated.  What other properties, besides 
> error, should be moved?  Perhaps the remote host and remote 
> address properties.  I don't see any others that appear to be 
> good candidates.  Message state is separately queried, and 
> I'd like to keep that lightweight query available.
> 
> So ... we need to make a decision so that this can be implemented.
> 
>   --- Noel
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Processing messages from spool

[Steve Short]

Sorry previous message escaped prematurely.

Yes, the one I think Jozsef was referring to in his post.  Here are the
diffs:

http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02103.html

You can ignore the filemem bit in item 1

And here are the discussion threads that preceded the patch submission:

http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02077.html
http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02051.html

Cheers
Steve


> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, July 30, 2002 1:51 PM
> To: James Developers List
> Subject: RE: Processing messages from spool
> 
> 
> >this must be applied on top of Shilpa's changes.
> 
> Steve, Shilpa's changes?
> d.
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: this..

[Steve Short]

This happens when using file repositories too and as far as I can tell it's
benign, although slightly annoying.

Steve


> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, July 30, 2002 2:25 PM
> To: James Developers List
> Subject: Re: this..
> 
> 
> The db repository doesn't seem to do a very good job locking for 
> whatever reason (not sure if it's a function of the caller or the 
> implementation itself), but occassionally a message will get 
> processed, 
> then a second thread that was blocking errantly gets told to process 
> that same message ID.  That ID isn't there anymore, so it throws this 
> message.  If I remember correctly, it handles it cleanly by just 
> throwing the stack trace (to remind the developers to fix 
> eventually), 
> but then picks right back up to try to process the next message.
> 
> -- 
> Serge Knystautas
> Loki Technologies - Unstoppable Websites http://www.lokitech.com
> 
> Danny Angus wrote:
> > anyone want to have a crack at telling me why I keep seeing 
> this, its 
> > in 2.0a3, I don't trust 2.1a1 enough to have used it in anger yet.
> > 
> >  java.lang.RuntimeException: Did not find a record 
> > Mail1028052929534-0-!1036393 in spool
> > at 
> > 
> org.apache.james.mailrepository.JDBCMailRepository.retrieve(JDBCMailRe
> > posito
> > ry.java:443)
> > at
> > 
> org.apache.james.transport.JamesSpoolManager.run(JamesSpoolMan
> ager.java:205)
> > at
> > 
> org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.exe
> cute(Executabl
> > eRunnable.java:47)
> > at
> > 
> org.apache.avalon.excalibur.thread.impl.WorkerThread.run(Worke
> rThread.java:8
> > 6)
> > 
> > d.
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Processing messages from spool

[Steve Short]

Yes, the one I think Jozsef was referring to in his post.  Here are the
diffs:

http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02103.html

You can ignore the filemem bit in item 1

And here is the discussion threads that preceded the patch submission:




> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, July 30, 2002 1:51 PM
> To: James Developers List
> Subject: RE: Processing messages from spool
> 
> 
> >this must be applied on top of Shilpa's changes.
> 
> Steve, Shilpa's changes?
> d.
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Processing messages from spool

[Steve Short]

And on the subject of performance...we also found the James did not scale
well on multi CPU boxes, we tried 2 different Sun 4-CPU boxes, one a 450MHx
and one a 750 MHz.  We tracked the problem down to the fact the the service
method in LinearProcessor is synchronized.

We fixed this and gained a huge performance gain. I don't have exact
measurements handy, but we were driving RemoteDelivery to a mail sink at a
rate approaching 100 messages per second.

I've attached the diff for LinearProcessor.java to this message, please note
that this must be applied on top of Shilpa's changes.

Cheers
Steve


> -Original Message-
> From: Jerry Crone [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, July 30, 2002 9:26 AM
> To: [EMAIL PROTECTED]
> Subject: Processing messages from spool
> 
> 
> I have been looking at the code that takes messages from the 
> spool and processes them. Assume that I am running a 
> production server with more than 300k messages per day, and 
> that there are 2,000 messages on the spool. It seems that 
> AvalonMailRepository.list() is called for every message that 
> is processed, creating a new HashSet. This would mean:
> 1) a lot of objects are created and GCed soon thereafter
> 2) if the spool always has messages, how could you be 
> optimistic that the last message in the HashSet would be processed?
> 
> What is the problem of using a queue for the keys; e.g., a 
> single instance of Vector? The keys for messages being 
> processed would have been removed from the Vector; however, 
> their corresponding members would still be in the 
> ObjectRepository and StreamRepository until their processing 
> is done. If James is shutdown and restarted, the keys would 
> be included in the new queue.
> 
> I want to emphasize that I am not being critical; I am 
> ignorant of the discussions that occurred while James was 
> being designed. You all have done a lot of excellent work.
> 
> P.S. I incorporated Shilpa's new classes and code mods. It 
> increased throughput by more than 30% (using files for both 
> spool and inboxes).
> 
> Have a good day, Jerry Crone
> 




LinearProcessor.diff
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Processing messages from spool

[Steve Short]

I agree.  I think the current spool repository implementations are
overloaded as they provide queueing and indexed store/retrieve
functionality.  This leads to some interesting quirks in the code for
dequeueing functionality messages, namely that the accept(long delay)
retrieves the key of the next message, reads the message from the repository
(so that it can check whether the message is a retry and if it's retry is
due), then it returns the key to the caller so that the caller can reread
the message from the store.

I'd like to propose that the error/retry mechanism is separated from the
main spool queue mechanism and that the spool queue becomes a pure queue as
you suggest.

Unfortunately this is a non-trivial change and I haven't fully investigated
what it entails.

Cheers
Steve

> -Original Message-
> From: Jerry Crone [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, July 30, 2002 9:26 AM
> To: [EMAIL PROTECTED]
> Subject: Processing messages from spool
> 
> 
> I have been looking at the code that takes messages from the 
> spool and processes them. Assume that I am running a 
> production server with more than 300k messages per day, and 
> that there are 2,000 messages on the spool. It seems that 
> AvalonMailRepository.list() is called for every message that 
> is processed, creating a new HashSet. This would mean:
> 1) a lot of objects are created and GCed soon thereafter
> 2) if the spool always has messages, how could you be 
> optimistic that the last message in the HashSet would be processed?
> 
> What is the problem of using a queue for the keys; e.g., a 
> single instance of Vector? The keys for messages being 
> processed would have been removed from the Vector; however, 
> their corresponding members would still be in the 
> ObjectRepository and StreamRepository until their processing 
> is done. If James is shutdown and restarted, the keys would 
> be included in the new queue.
> 
> I want to emphasize that I am not being critical; I am 
> ignorant of the discussions that occurred while James was 
> being designed. You all have done a lot of excellent work.
> 
> P.S. I incorporated Shilpa's new classes and code mods. It 
> increased throughput by more than 30% (using files for both 
> spool and inboxes).
> 
> Have a good day, Jerry Crone
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Handlers' streams RE: [Bug 11235]

[Steve Short]

And I remember it differently, of course. I thought that there was enough
interest from users/developers that the logging changes should be made, but
the discussion went off into whether to wrap the Avalon Logger interface for
better isolation from Avalon etc etc etc.

Steve

> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, July 29, 2002 12:59 AM
> To: James Developers List
> Subject: RE: Handlers' streams RE: [Bug 11235]
> 
> 
> I believe that this argument was settled with the commiters 
> deciding not to include logging in the API. Of course you are 
> entitled to produce your own extensions/frameowrks and 
> whatever you need to allow you to make useful mailet 
> applications, but they are not part of the API. d.
> 
> 
> > I will provide patches and difs for logging.
> > When we can
> > review this and put it to the scratch (or whatever cvs) branch. So 
> > ones who badly need fine grained logging in mailet (like me for 
> > example) will be able
> > to take it and test it. This change doesn't break mailet API, it
> > just extend
> > it a little bit, so there should be NO compatibility risk. 
> After testing
> > (and time) this can go into main code. And when new mailet 
> API will be
> > developed this change can be adopted or dropped out but 
> still this will be
> > done when there is at least one implemented and tested approach.
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: How to Extract Attachment from an Incoming Mail

[Steve Short]

Try something like this, suitably modified of course...

try {
MimeMultipart mp = (MimeMultipart)message.getContent();
int partCount = mp.getCount();
for (int i = 0; i < partCount; i++) {
MimeBodyPart part = (MimeBodyPart)mp.getBodyPart(i);
ContentType contentType = new
ContentType(part.getContentType());
String partType = contentType.getBaseType();
if (attachmentMatches(part)) {
imagePart = part;
}
}
}
catch (IOException iox) {
throw new MessagingException("Failed to process message
attachments", iox);
}

Note that this doesn't recurse through nested parts.

Steve

> -Original Message-
> From: Patrick Han [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, July 09, 2002 9:28 AM
> To: [EMAIL PROTECTED]
> Subject: How to Extract Attachment from an Incoming Mail
> 
> 
> Dear all,
> 
> I am new to JAMES and this mailing list.  Please excuse me if 
> I ask silly questions. :)
> 
> I am currently developing a mailet that should intercept with 
> an incoming mail and save the attachment (This will always be 
> an image, mostly in .jpg) to a local directory residing on 
> the mail server.  However, I have gone through the JAMES and 
> Mailet API and found various methods to extract almost all 
> parameters of a mail but the actual email attachment!
> 
> I have also searched all over the Web to look for related 
> topic but most of the searching result I got is related to 
> how to send attachment via email, not to extract attachment 
> from an email.
> 
> Does anyone has any clue on how I can proceed with this task? 
>  Thanks in advance!
> 
> Pat
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Mailet API] Logging Proposal

[Steve Short]

I still think it is highly desirable to allow logging at more than one
level, i.e. the typical error, warn, info and debug. Having followed the
discussion with varying degrees of interest :), what is wrong with having
the corresponding methods exposed via the MailetContext?  There's no need to
expose the actual logging mechanism to the mailets themselves, no need to
create a logging façade and no need to expose Avalon Framework logging
interfaces to the mailets.

Regards
Steve



> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, June 10, 2002 12:11 PM
> To: James-Dev Mailing List
> Subject: [Mailet API] Logging Proposal
> 
> 
> [Needless to say, these definitions include only the logging 
> related portion]
> 
> interface MailetContext
> {
>org.apache.avalon.framework.logger.Logger getLogger();
> 
>void log(String message);  // deprecated
>void log(String message, Throwable t); // deprecated
> }
> 
> abstract class GenericMailet implements Mailet, MailetConfig
> {
>void log(String message);  // deprecated
>void log(String message, Throwable t); // deprecated
> 
>/*
>   allows getLogger()."cat"(msg[, t]) instead of
>   getMailetContext().getLogger()."cat"(message[, t]);
> 
>   implementation may wrap the logger to include
>   config.getMailetName() + ": " in the message
> 
> */
>org.apache.avalon.framework.logger.Logger getLogger();
> }
> 
> Alternative would be to break with the Mailet v1 API 
> entirely, and go with:
> 
>interface Mailet extends 
> org.apache.avalon.framework.logger.LogEnabled
> 
> but I'm less inclined in that direction.
> 
> Please comment with specific changes (or even rewrites), so 
> we can keep the discussion concrete.
> 
>   --- Noel
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Mailet API] Logging Proposal

[Steve Short]

> I'd like to know why anyone would expect sophistcated logging 
> service to be provided by the API, and what stories or use 
> cases they can advance to support this.

Consistent logging throughout James and the Mailets.  This includes log
destinations, formatting, filtering etc.

> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, June 10, 2002 2:51 PM
> To: James Developers List
> Subject: RE: [Mailet API] Logging Proposal
> 
> 
> > The downside of (2) is that since logging, etc... are 
> *always* needed, 
> > every implementor will put in his, and you can say goodbye to 
> > interoperability.
> 
> Ok, this is just Not True.
> 
> Interoperability will be provided by the API, logging won't 
> affect this.
> 
> Any mailet application built according to the API and in 
> spirit with it, according to the specification document as 
> well as the code, will be interoperable with any container 
> similarly built and any other application.
> 
> Logging is a "leaf" on the tree of dependance, I can see how 
> other services, such as repository or spool providers need to 
> be controled in order to ensure interoperability, being 
> "nodes" on that tree. The solution to providing logging is 
> that the mailet application developer distributes their 
> preferred logging classes with their application, because in 
> that situation interoperability is not compromised, the 
> central purpose of the API is still served in spirit and in 
> detail. There must be zillions of servlet applications that 
> provide 100% of the logging service they require, and still 
> comply with the API.
> 
> I'm actually coming to the conclusion that providing logging 
> in the API would make logging more cumbersome for 
> sophisticated users, over engineered for trivial uses and 
> discourage many users from making their own architectural 
> decison on a matter which is of *no* relevance to us.
> 
> I'd like to know why anyone would expect sophistcated logging 
> service to be provided by the API, and what stories or use 
> cases they can advance to support this.
> 
> d.
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Bug report for James [2002/06/02]

[Steve Short]

BTW bug 6812, "can't relocate var directory", was fixed by a patch I
submitted (and was applied) to Avalon a while back (3rd April).  Affected
file was
org.apache.avalon.cornerstone.blocks.masterstore.AbstractFileRepository.

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: Sunday, June 02, 2002 10:12 AM
> To: [EMAIL PROTECTED]
> Subject: Bug report for James [2002/06/02]
> 
> 
> +-
> --+
> | Bugzilla Bug ID 
>   |
> | 
> +-
> +
> | | Status: UNC=Unconfirmed NEW=New ASS=Assigned  
>   |
> | | OPN=ReopenedVER=Verified(Skipped 
> Closed/Resolved)   |
> | |   
> +-+
> | |   | Severity: BLK=Blocker CRI=Critical
> MAJ=Major |
> | |   |   MIN=Minor   NOR=Normal  
> ENH=Enhancement   |
> | |   |   
> +-+
> | |   |   | Date Posted   
>   |
> | |   |   |  
> +--+
> | |   |   |  | Description
>   |
> | |   |   |  |
>   |
> | 2288|Ass|Maj|2001-06-22|Bounced mail to unknown sender 
> address or SMTP 
> | 2288|Ass|Maj|2001-06-22|ser|
> | 4003|Ass|Blk|2001-10-05|Mails stored in the file repo have their 
> | 4003|Ass|Blk|2001-10-05|objectsto|
> | 4032|New|Min|2001-10-08|Bad DB structure causes store 
> problems|
> | 4033|New|Nor|2001-10-08|JamesSpoolManager doesn't shutdown 
> gracefully |
> | 5824|Opn|Nor|2002-01-12|NNTP auth doesnt work   
>   |
> | 6340|New|Nor|2002-02-09|SMTP AUTH with  will not 
> work  |
> | 6812|Opn|Maj|2002-03-02|can't relocate var directory.   
>   |
> | 6928|New|Maj|2002-03-06|James gets stuck when processing a faulty 
> | 6928|New|Maj|2002-03-06|e-mail  |
> | 7472|New|Min|2002-03-26|Redirect Mailet uses empty sender 
> when reusing 
> | 7472|New|Min|2002-03-26|ori|
> | 8581|New|Nor|2002-04-27|add new local user for james thru telent to 
> | 8581|New|Nor|2002-04-27|james,|
> | 8774|New|Nor|2002-05-03|incorrect dates on postings 
>   |
> | 8839|New|Nor|2002-05-06|File repositories number themselves 
>   |
> | 8861|New|Nor|2002-05-07|Occasionally James gets stuck while 
> processing 
> | 8861|New|Nor|2002-05-07|inc|
> | 9194|New|Nor|2002-05-17|build failure   
>   |
> +-+---+---+--+
> --+
> | Total   14 bugs 
>   |
> +-
> --+
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: New avalon

[Steve Short]

Danny,

are you including the 'new' v 1.1 avalon logging configuration I submitted
many weeks ago ?

Steve

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 28, 2002 7:55 AM
To: James Developers List
Subject: New avalon


Just to warn everyone..

I'm working on a new version of Build.xml tidying up the targets, and
simplifying the whole business.
There will be new distributions, and better generation of the website and
other docs.
In the meantime bear with me..

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: SMTPHandler connection timeout

[Steve Short]

So let's review the options:

- use java.net.Socket.setSoTimeout(timeout)
- fix Avalon so that it removes redundant triggers when they are updated
- fix Avalon so that it calls notify every time a trigger is reset
- can we extend the Avalon scheduler/timer classes with a new timer that
  does what we need (sorry I don't have the code handy to check how feasibly
  this is myself)?
- implement a new timer mechanism purely within James

Noel, you stated that you didn't like the setSoTimeout approach, can you
clarify why James need to protect parseCommand as well as socket IO?

Cheers
Steve


-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 22, 2002 6:30 AM
To: James Developers List
Cc: Shilpa Dalmia
Subject: Re: SMTPHandler connection timeout


Noel,

Looks rather serious... like you said, perhaps building our own trigger
mechanism is the way to go.

More importantly, I just wanted to note that SchedulerNotifyInputStream will
reset the trigger every 20,000 bytes, not every byte.  So while bad, it's
not the end of JVM's as we know it. :)

Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
- Original Message -
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
To: "James-Dev Mailing List" <[EMAIL PROTECTED]>
Cc: "Shilpa Dalmia" <[EMAIL PROTECTED]>
Sent: Tuesday, May 21, 2002 11:54 PM
Subject: RE: SMTPHandler connection timeout


> Shilpa,
>
> You've got me convinced.
>
> Having read the thread, more James code and the relevant portions of
> Cornerstone, I believe that you are actually underestimating.  If what
> appears to be the case from my reading of the code, and what you and Peter
> Donald say is happening, then you are underestimating the potential
> magnitude of the problem by orders.  Trace through the doDATA method.  It
> appears to be that SchedulerNotifyInputStream resets the trigger for EVERY
> BYTE OF DATA in the message stream; SchedulerNotifyOutputStream does the
> same when writing.  If those are really resulting in a new queue entry for
> each byte of data (which is what appears to be the case), that's brutal,
and
> really needs to be addressed either in Avalon or in James.
>
> As far as I can see, James is using this as a watchdog timer, which does
not
> appear to be the design point for Avalon's facility, based upon their own
> comments, design and implementation.  And even the workaround to Avalon of
> adding another thread or doing the replacement during the reset would be
> performance prohibitive given that the trigger is reset for each byte of
> data read from the stream.  I've done a grep of James to find all uses of
> the trigger code, and it looks to be similar in all cases.  Perhaps a more
> efficient watchdog solution can be devised, maybe tied to the handler
> instance.  I'd sooner create a watchdog thread per handler than have 100s
of
> thousands (or millions) of events in the scheduler queue.
>
> Am I reading this correctly?  Your throughts?
>
> --- Noel
>
> -Original Message-
> From: Shilpa Dalmia [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 21, 2002 19:26
> To: '[EMAIL PROTECTED]'
> Subject: FW: SMTPHandler connection timeout
>
>
> You can look at the foll. avalon mailing list thread on this issue where
> they have given an explanation for this.
> http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg08660.html
>
> I have a implemented a temporary solution for this issue, which fixes the
> problem.
>
> Shilpa
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Fwd: Re: Mailet API]

[Steve Short]

For consideration:

c) allow mailets (and matchers?) to log messages at levels other than info,
i.e. debug, warn, error, fatal etc.

Cheers
Steve

-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 30, 2002 12:46 PM
To: James Developers List
Subject: Re: [Fwd: Re: Mailet API]


I think I've sent around my thoughts on this, but here goes anyway.

a) I would like at some point to change the mailet API to have object 
attributes on the Mail object (e.g., add getAttribute(String name), 
setAttribute(String name, Object value), remoteAttribute(String name)). 
  This would let you pass information between matchers and mailets, and 
mailets and mailets for that matter.

b) the CommandForListserv/AvalonListservManager is a bad design pattern 
IMHO (although I did write it).  Matchers are supposed to be convenient 
ways to component-ize functionality you might want to use in multiple 
mail apps.  Checking the remote IP address, looking up a blacklist via 
DNS, checking a header, etc...  these are great checks that anybody 
could use, and make great matchers.

I think if you're doing something so functionally-specific as 
CommandForListserv does, you should just use the All matcher and have 
the Mailet do all the work.  There's nothing a matcher can do that a 
mailet can't, and I don't think we need to change the API to make 
mailets have a default... I think this makes the API more complicated 
without  simplifying configuration in most cases.  I mean to write a 
decent listserv soon and will likely squash/deprecate the command for 
listserv matcher since it is a bad example, IMHO.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/

Jeff Keyser wrote:
> I agree that the work of matching and doing something should be separate.
> However, I'd like to suggest an alternative way of communicating, since it
> may be helpful for a Mailet to know what parameters were user by the
> Matcher.
> 
> I'm thinking specifically about the CommandForListserv Matcher and the
> AvalonListservManager Mailet.  It would probably be helpful for the Mailet
> to explicitly know which mailing list it is processing for.  It may also
be
> helpful to know which command was matched, but that's getting even more
> complicated.
> 
> How to do this?  I'm not sure, but if it can be done cleanly, I see it
being
> useful.
> 
> 
>>-Original Message-
>>From: Andrew Timberlake [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, April 22, 2002 12:00 PM
>>To: [EMAIL PROTECTED]
>>Subject: [Fwd: Re: Mailet API]
>>
>>
>>Thanks Dave for the response
>>I'm forwarding this thread back into the list as I would like to hear
>>the main developers, and others, feedback and insight into this.
>>
>>Thanks
>>
>>Andrew
>>
>>-Forwarded Message-
>>
>>From: Dave Morris <[EMAIL PROTECTED]>
>>To: Andrew Timberlake <[EMAIL PROTECTED]>
>>Subject: Re: Mailet API
>>Date: 22 Apr 2002 16:19:22 +0100
>>
>>Yep.
>>Quite true.
>>However, kind of makes the Matcher redundant if all the
>>Mailets start doing their
>>own matching.
>>
>>I kind of like the separation of functionality, a Matcher
>>filters the messages
>>and a Mailet does stuff with the messages. What I want to add
>>is a way of the
>>Mailet an Matcher to talk to each other, mainly to share configuration
>>information.
>>
>>This came up when I was experimenting with designing some of
>>my own custom
>>Mailets.
>>In each case, the Mailet needed to process emails to one or
>>more addresses in a
>>list or group.
>>Both the Mailet and Matcher needed to be configured to access
>>the same list of
>>addresses.
>>
>>I kept ending up with an odd situation where both the Mailet
>>and Matcher share
>>the same list of addresses, but they can't communicate
>>directly with each other.
>>
>>Much like the current RecipientIsLocal Matcher and
>>LocalDeliver Mailet, both have
>>to use an Avalon lookup to get a reference to the local
>>reporistory, but they
>>can't talk to each other.
>>
>>You are right, it is possible to implement using the current
>>API, just a few
>>extra hoops to jump through.
>>The proposed change would just make it a little easier to
>>design Matcher and
>>Mailet combinations.
>>If it causes too many side effects, then it isn't worth it.
>>
>>Thanks,
>>Dave
>>
>>
>>Andrew Timberlake wrote:
>>
>>
>>>Just a quick question.
>>>A mailet can perform the function of a matcher just by virtue of
>>>checking the mail message as it processes it. Therefore
>>
>>could you not
>>
>>>achieve what you are looking for with the match="ALL" and then write
>>>"matching" information into the mailet?
>>>
>>>Andrew
>>>
>>>On Mon, 2002-04-22 at 14:21, Dave Morris wrote:
>>>
Hi,

I would like to propose a change to the Mailet API, and would be
interested in thoughts and ideas.

At the moment, Mailets have no access to their Matcher.
I appreciate that this is probably by design.
However . I would like to suggest adding th

RE: Found Problem with Retries and Bounces

[Steve Short]

Yes it does, but James already changes the name several times in the course
of processing a message so I didn't think this was introducing anything new.

Steve

-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 19, 2002 8:00 PM
To: James Developers List
Subject: Re: Found Problem with Retries and Bounces


Your patch changed the mail's name, which has a meaning for the 
application, to work around a bug in *one* of the storage mechanisms.  I 
would much rather fix the storage mechanism than add your patch and 
otherwise leave future developers to worry about this kind of stuff.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/

Steve Short wrote:
> This is essentially what the patch I mailed in does, it saves to a new
file
> and then deletes the old file. I don't really see any benefit to copying
> back over the original file.  I don't know what mail.dir does.
> 
> Regards
> Steve
> 
> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 19, 2002 4:33 PM
> To: James Developers List
> Subject: Re: Found Problem with Retries and Bounces
> 
> 
> Steve,
> 
> This is a good point... although I've patched the FileRepository so that 
> it does properly not save over itself and obliterate the mime message, 
> it does still leave your point as valid (about it not being on disk for 
> a bit of time).  Perhaps I should save to a temp file and then delete 
> the old copy and copy the temp over it.  Doesn't mail.dir do something 
> like this where it documents how it saves to a new file and copies the 
> temp over the original?


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Found Problem with Retries and Bounces

[Steve Short]

This is essentially what the patch I mailed in does, it saves to a new file
and then deletes the old file. I don't really see any benefit to copying
back over the original file.  I don't know what mail.dir does.

Regards
Steve

-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 19, 2002 4:33 PM
To: James Developers List
Subject: Re: Found Problem with Retries and Bounces


Steve,

This is a good point... although I've patched the FileRepository so that 
it does properly not save over itself and obliterate the mime message, 
it does still leave your point as valid (about it not being on disk for 
a bit of time).  Perhaps I should save to a temp file and then delete 
the old copy and copy the temp over it.  Doesn't mail.dir do something 
like this where it documents how it saves to a new file and copies the 
temp over the original?
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/

Steve Short wrote:
> Serge,
> 
> I something like that in LinearProcessor, it saves to a new file each time
> the message status has been changed, but I don't see this in
RemoteDelivery.
> For now I have simply added a call to saveChanges() immediately prior to
the
> call to store().  While this is simple and it works, it is less than ideal
> because it opens a small window when the data does not exist on disk and
> would therefore be lost during a system failure.
> 
> Regards
> Steve
> 
> -Original Message-
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 05, 2002 11:54 AM
> To: James Developers List
> Subject: Re: Found Problem with Retries and Bounces
> 
> 
> Thanks for the analysis.  I think what I did was changing RemoteDelivery
to
> save to a new file... I can also change the MimeMessageWrapper to check
> where the file is saved and accordingly move the old file to a temp
location
> or something like that.
> 
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
> - Original Message -
> From: "Steve Short" <[EMAIL PROTECTED]>
> To: "James Dev (E-mail)" <[EMAIL PROTECTED]>
> Sent: Tuesday, March 05, 2002 2:14 PM
> Subject: Found Problem with Retries and Bounces
> 
> 
> 
>>OK I have found the basic cause of the message header information being
> 
> lost
> 
>>during retries of temporary failures.  Basically the MimeMessageWrapper
>>doesn't fully load the data file until it is actually needed, it stores a
>>reference to a MimeMessageSource instead.  When RemoteDelivery updates the
>>message status and retry count, it attempts to store() the updated
> 
> message.
> 
>>What happens is that store() creates a new FileOutputStream, which
> 
> truncates
> 
>>the file to 0 bytes, then tells the message object to write itself to the
>>new file.  MimeMessageWrapper realises that it needs to read the header
> 
> data
> 
>>from it's MimeMessageSource and tries to do so, but this file has just
> 
> been
> 
>>wiped.  Therefore the data has been lost.
>>
>>Regards
>>Steve


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Exceptions Using MYSQL Database for Spool

[Steve Short]

Hi folks,

I'm trying to do some performance comparisons of using filestore versus
database for the main spool queue, and when I use a database, I keep getting
exceptions like the one below.  Having turned logging up to debug it looks
to me like this message has already been processed and sent, so my guess is
that it has been picked up from the spool queue by a second thread before
JamesSpoolManager deletes it from the spool.  I thought that
JDBCMailRepository locked this entry so this should not be possible, but
then I'm not sure how good the locking mechanism is.  (I notice that the
AvalonMailRepository lock() method has a notifyAll which is commented out in
JDBCMailRepository lock()).

Is anyone else seeing this error?  

Regards
Steve

2002-04-17T16:20:10 INFO  [James.Mailet   ]: RemoteDelivery: Remote delivery
thread (2) will process mail Mail1019085596655-19-!1366124276-to-postx.com
java.lang.RuntimeException: Did not find a record
Mail1019085596194-13-!1515491097 in spool
at
org.apache.james.mailrepository.JDBCMailRepository.retrieve(Unknown Source)
at org.apache.james.transport.JamesSpoolManager.run(Unknown Source)
at
org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(Executabl
eRunnable.java:47)
at
org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:8
5)
java.lang.RuntimeException: Exception while retrieving mail: Did not find a
record Mail1019085596194-13-!1515491097 in spool
at
org.apache.james.mailrepository.JDBCMailRepository.retrieve(Unknown Source)
at org.apache.james.transport.JamesSpoolManager.run(Unknown Source)
at
org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(Executabl
eRunnable.java:47)
at
org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:8
5)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: FW: problem sending email, body in Rich Text Format / Plain Text

[Steve Short]

I tried this out for myself, 'cos I was slightly concerned about it and have
been unable to reproduce the problem.  Do you have any more info about your
configuration that might help narrow this down and resolve it?

Steve

-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 03, 2002 10:59 AM
To: James Developers List
Subject: Re: FW: problem sending email, body in Rich Text Format / Plain
Text


Kishore,

This is a bug in JavaMail.  I see this error message occassionally in my 
logs but never had the email source that was causing it.  You'll have to 
follow-up with Sun on this one as we're rather dependent on their 
library for MIME parsing and writing.  I think JavaMail 1.3 is about to 
come out (or maybe already has) so you could test that it could read and 
write that message.  Once JavaMail 1.3 FCS is out, we'll need to upgrade 
James to use this new version of JavaMail, irregardless.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Kishore Metla wrote:
> Hi,
> 
> I did not get any answer and this is kind of important. Can someone please
> help me. 
> 
> Thanks in advance
> -Kishore
> 
> -Original Message-
> From: Kishore Metla [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 01, 2002 11:16 AM
> To: '[EMAIL PROTECTED]'
> Subject: problem sending email, body in Rich Text Format / Plain Text
> 
> 
> 
> Hi,
> 
> I have James set up. I have a problem when sending an email using
Microsoft
> Outlook 2000 Plain Text or Rich Text to the James with an attachment but
> with no message in the body.
> 
> I am choosing the format of the mail in the Outlook by going to Tools >>
> Options >> Mail Format >> 'Choose a format for outgoing mail ...'  and
> choosing the option as 2 or 3 from the available as listed below 
> 1. HTML
> 2. Microsoft Outlook Rich Text
> 3. Plain Text
> 
> When I send an email to the James Server to categorize, choosing HTML
(with
> or without a message in the body) it works fine. If I send an email
choosing
> either Plain Text or Rich Text with some message in the body it works
fine.
> But If no message in the body (sending just an attachment) it fails
throwing
> an exception (see below).
>

>

> 
> javax.activation.UnsupportedDataTypeException: no object DCH for MIME type
> application/octet-stream; 
> name="example.PDF"
> at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:851)

> at javax.activation.DataHandler.writeTo(DataHandler.java:305) 
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1089)
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:635)
> at javax.mail.internet.MimeMultipart.writeTo(MimeMultipart.java:233)
> at com.sun.mail.handlers.multipart_mixed.writeTo(multipart_mixed.java:68)
> at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:849)
> at javax.activation.DataHandler.writeTo(DataHandler.java:305)
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1089)
> at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1527)
> at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1503)
> at org.apache.james.core.MailImpl.writeMessageTo(MailImpl.java:198)
> at
>
org.apache.james.mailrepository.AvalonMailRepository.store(AvalonMailReposit
> ory.java:98)
> at org.apache.james.James.sendMail(James.java:298)
> at org.apache.james.James.sendMail(James.java:278)
> at org.apache.james.James.sendMail(James.java:270)
> at
>
org.apache.james.transport.mailets.NotifyPostmaster.service(NotifyPostmaster
> .java:167)
> at
>
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:152)
> at
>
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:
> 166)
> at
>
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:142)
> at org.apache.avalon.utils.recycle.pool.Worker.run(Worker.java:113)
> Exception in processor 
> javax.mail.MessagingException: Exception spooling message: Exception
caught
> while storing Message Container: javax.activ
> ation.UnsupportedDataTypeException: no object DCH for MIME type
> application/octet-stream;
> name="example.PDF"
> at org.apache.james.James.sendMail(James.java:304)
> at org.apache.james.James.sendMail(James.java:278)
> at org.apache.james.James.sendMail(James.java:270)
> at
>
org.apache.james.transport.mailets.NotifyPostmaster.service(NotifyPostmaster
> .java:167)
> at
>
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:152)
> at
>
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:
> 166)
> at
>
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:142)
> at org.apache.avalon.utils.recycle.pool.Worker.run(Worker.java:113)
>
---

Bug 6812 - Absolute File Repository Paths

[Steve Short]

Hi folks,

FYI I have just submitted a patch to the Avalon Developers mailing list to
fix James bug 6812.  

Steve

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Sticking with one undeliverable message

[Steve Short]

If I may just supplement that to help Gordon get moving:

LinearProcessor invokes the RemoteDelivery mailet service method.
RemoteDelivery service method stores the message in outgoing folder
One of the deliveryThreads in RemoteDelivery picks up message from outgoing
folder and calls deliver method

On failures within RemoteDelivery deliver, method failMessage is called
which handles the retry count etc.

Cheers
Steve

-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 08, 2002 8:58 AM
To: James Developers List
Subject: Re: Sticking with one undeliverable message


Well, there's a spool manager code (probably JamesSpoolManager ??) and
something in there will create a LinearProcessor that handles taking a
message through a processor (calling the appropriate mailets and matchers).
So those are good places to start... LinearProcessor should invoke the
RemoteDelivery mailet, which eventually/somehow calls the deliver method.

Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
- Original Message -
From: "Gordon Ross" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 08, 2002 11:46 AM
Subject: Re: Sticking with one undeliverable message


> PS - Where does the deliver method get called from ?
>
> GTG


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Found Problem with Retries and Bounces

[Steve Short]

Serge,

I something like that in LinearProcessor, it saves to a new file each time
the message status has been changed, but I don't see this in RemoteDelivery.
For now I have simply added a call to saveChanges() immediately prior to the
call to store().  While this is simple and it works, it is less than ideal
because it opens a small window when the data does not exist on disk and
would therefore be lost during a system failure.

Regards
Steve

-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 05, 2002 11:54 AM
To: James Developers List
Subject: Re: Found Problem with Retries and Bounces


Thanks for the analysis.  I think what I did was changing RemoteDelivery to
save to a new file... I can also change the MimeMessageWrapper to check
where the file is saved and accordingly move the old file to a temp location
or something like that.

Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
- Original Message -
From: "Steve Short" <[EMAIL PROTECTED]>
To: "James Dev (E-mail)" <[EMAIL PROTECTED]>
Sent: Tuesday, March 05, 2002 2:14 PM
Subject: Found Problem with Retries and Bounces


> OK I have found the basic cause of the message header information being
lost
> during retries of temporary failures.  Basically the MimeMessageWrapper
> doesn't fully load the data file until it is actually needed, it stores a
> reference to a MimeMessageSource instead.  When RemoteDelivery updates the
> message status and retry count, it attempts to store() the updated
message.
>
> What happens is that store() creates a new FileOutputStream, which
truncates
> the file to 0 bytes, then tells the message object to write itself to the
> new file.  MimeMessageWrapper realises that it needs to read the header
data
> from it's MimeMessageSource and tries to do so, but this file has just
been
> wiped.  Therefore the data has been lost.
>
> Regards
> Steve


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Found Problem with Retries and Bounces

[Steve Short]

OK I have found the basic cause of the message header information being lost
during retries of temporary failures.  Basically the MimeMessageWrapper
doesn't fully load the data file until it is actually needed, it stores a
reference to a MimeMessageSource instead.  When RemoteDelivery updates the
message status and retry count, it attempts to store() the updated message.

What happens is that store() creates a new FileOutputStream, which truncates
the file to 0 bytes, then tells the message object to write itself to the
new file.  MimeMessageWrapper realises that it needs to read the header data
from it's MimeMessageSource and tries to do so, but this file has just been
wiped.  Therefore the data has been lost.

Regards
Steve



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Problem with Retries and Bounces

[Steve Short]

Sorry for the delay, flu and other work got in the way but I'm back on the
case.

I can confirm that the problem is real and can give an easy way for anyone
else to reproduce it.  To do so, edit the RemoteDelivery parameters in the
'transport' section of your James config.xml. Add a gateway server and
reduce the retry count and timeout so you don't have to wait days to see the
problem, like this:

 5000 
 3 

NON.EXISTENT.COM
25

This tells the RemoteDelivery mailet to use a non existent server for
relaying messages.  Clearly this is an artifical test case that I am using
to demonstrate the problem, the issue affects all 'temporary' failures
within RemoteDelivery.

Now fire up James and send it an SMTP message.  What will happen is this:

- James will write the message to the spool queue
- James will read the message from the spool queue and hand it to
RemoteDelivery
- RemoteDelivery will write the message to the outgoing folder
- A RemoteDelivery deliverythread will read the message from the outgoing
folder and try to delivery it
- Delivery will fail ('cos the gateway server is invalid), and
RemoteDelivery increment the 'try' count for the message
- RemoteDelivery will write the message back to the outgoing folder 
*** This is where it goes wrong, the FILESTREAMOBJECT file has 0 bytes, 
*** so the message has lost all it's Mime headers
- RemoteDelivery will wakeup every 5 seconds and try again until the retry
count has been exceeded.
- RemoteDelivery will try to bounce the message by calling James.bounce()
(via a proxy context object).
- James.bounce() gets a NullPointerException while create the bounce message
because there are no
  valid recipient addresses in the message (they got wiped along with the
Mime headers).
- RemoteDelivery.run method gets general Exception. 

If you haven't installed my minor fix patches, then James will enter an
infitine loop, this is because the
invalid message is still in the outgoing folder, so RemoteDelivery will read
it, try to bounce it again, get
an exception again, read it again, try to bounce it, get exception again
etc. If you do have my fixes installed you'll
get alog message that says "encountered unexpected exception while bouncing
message" and the message is removed from the outgoing folder.  It should
probably also go into the error folder, but since the message is basically
corrupt I didn't feel confident about doing that.

So there is a basic problem with the way RemoteDelivery stores/retrieves the
message from it's outgoing mailrepository.

Regards
Steve



  





-Original Message-
From: Lucas Gonze [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 15, 2002 3:03 PM
To: James Developers List
Subject: RE: Problem with Retries and Bounces


That's a useful clue, Steve.  Have you tried incrementally morphing the
default config to yours to see at what point the problem happens?

On Fri, 15 Feb 2002, Steve Short wrote:

>
> I partially retract my statement.  The problem doesn't happen with
> unmodififed James configuration, so it could be my configuration - but I
> still don't know what it is!!
>
> Any help appreciated.
>
> Steve
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: James Diffs for Minor Fixes

[Steve Short]

Danny,

you're welcome, hope they're useful.  FYI we are still working on the mailet
shutdown stuff.   The diff's I have published work, but we are experiencing
some memory loss during repeated stop/start cycles, seems like everyone
wants to know when they have been interrupted().

Steve

-Original Message-
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 25, 2002 5:31 AM
To: James Developers List
Cc: [EMAIL PROTECTED]
Subject: RE: James Diffs for Minor Fixes


Steve, thanks for these, and the conf I'll apply them when I get a minute
:-)
d.

> -Original Message-----
> From: Steve Short [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, February 16, 2002 2:11 AM
> To: James Dev (E-mail)
> Subject: James Diffs for Minor Fixes
>
>
>
> Here are the diffs for the fixes I mailed about earlier.  The diffs were
> made using 'cvs diff -u' in cygwin on Windows 2000.  The
> following files are
> attached:
>
> JamesSpoolManager.diff
> AvalonSpoolRepository.diff
> AvalonMailRepository.diff
> LinearProcessor.diff
> RemoteDelivery.diff
> RemoteManager.diff
> SMTPServer.diff
>
> Regards
> Steve
>  <>  <>
> <>  <>
> <>  <>  <>
>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Updated james-server.xml with new Phoenix Logging

[Steve Short]

I'd like to offer the attached server.xml config file to the James project.
I have created this to exploit the new improved logging mechanisms in the
Avalon framework.  The highlights of this configuration are:

- can log to both console and file with different priority filters, by
default console logging is set to INFO and file logging is set to DEBUG.
- can log all messages to a single file.
- log file is configured as a rolling log, 1 thru 5, with a size threshold
set to ~10Mb.

Clearly this is easily extended for other targets, in my case syslog.

There's one 'issue' I haven't tracked down yet.  There are some DEBUG
messages appearing from 'database', but when I configure a database category
it has no effect.

Regards
Steve
 <> 



james-server.xml
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

James Diffs for Minor Fixes

[Steve Short]

Here are the diffs for the fixes I mailed about earlier.  The diffs were
made using 'cvs diff -u' in cygwin on Windows 2000.  The following files are
attached:
 
JamesSpoolManager.diff
AvalonSpoolRepository.diff
AvalonMailRepository.diff
LinearProcessor.diff
RemoteDelivery.diff
RemoteManager.diff
SMTPServer.diff

Regards
Steve
 <>  <>  
<>  <>  
<>  <>  <> 



JamesSpoolManager.diff
Description: Binary data


AvalonSpoolRepository.diff
Description: Binary data


AvalonMailRepository.diff
Description: Binary data


LinearProcessor.diff
Description: Binary data


RemoteDelivery.diff
Description: Binary data


RemoteManager.diff
Description: Binary data


SMTPServer.diff
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Problem with Retries and Bounces

[Steve Short]

I partially retract my statement.  The problem doesn't happen with
unmodififed James configuration, so it could be my configuration - but I
still don't know what it is!!

Any help appreciated.

Steve


-Original Message-----
From: Steve Short [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 15, 2002 10:18 AM
To: James Dev (E-mail)
Subject: Problem with Retries and Bounces


Hi,

this info first appeared as a reply in the 'spooling problem'  thread in the
James Users list but no one commented on it there so I thought I'd post it
here.

I'm pretty certain that James is losing some attributes from the mail
message during the store/retrieve cycle.  It seems to work ok the first time
round for each message, but the second time round it doesn't get a full copy
of the message.  I changed the run() method of RemoteDelivery to dump out
parts of the message and this is what I get:

Started SMTP Server plain:25
Delivery thread after retrieve mail.From [0] = [EMAIL PROTECTED]
Delivery thread after retrieve mail.To [0] =
[EMAIL PROTECTED]
Delivery thread after retrieve mail.Subject = Message form Perl
script
mailtest.pl
Delivery thread after store and retrieve mail.From = null
Delivery thread after store and retrieve mail.To = null
Delivery thread after store and retrieve mail.Subject = null
Delivery thread after 2nd store and retrieve mail.From = null
Delivery thread after 2nd store and retrieve mail.To = null
Delivery thread after 2nd store and retrieve mail.Subject = null

Here's the snippet of code I modified in the run() method of RemoteDelivery:

log(Thread.currentThread().getName() + " will process mail "+ key);
MailImpl mail = outgoing.retrieve(key);

dumpMessage("Delivery thread after retrieve mail", mail);
outgoing.store(mail);
MailImpl newMail = outgoing.retrieve(key);
dumpMessage("Delivery thread after store and retrieve
mail",newMail);
outgoing.store(mail);
MailImpl newMail2 = outgoing.retrieve(key);
dumpMessage("Delivery thread after 2nd store and retrieve mail",
newMail2);

I haven't got the full picture yet, but it looks like the combination of
the Mail wrapper classes that James uses do not fully preserve the object
state during the store / retrieve cycle. I can force things to work by added
a 
call to mail.getMessage().saveChanges() after the first retrieve, but it
seems to
me that this is really a workaround to the root problem, but I am not sure
what
the correct solution it.

This consequence of this is that retries and bounces do not work and testing
confirms this.

Any comments, folks?


Regards
Steve


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Updates to James

[Steve Short]

Hi folks,

we have made some minor changes to James and I was wondering if it would be
useful to pass these back to main project.  Here is a summary:

Added mailet shutdown.  Changed JamesSpoolManager, LinearProcessor and
RemoteDelivery.
  Self explanatory.

Prevent tight loop in RemoteDelivery on unexpected exceptions, remove
message from outgoing queue.
  This was a consequence of James.bounce() getting a NullPointerException
when there were no from
  addresses.  See thread 'Problem with Retries and Bounces' in James dev
mailing list for more info. After
  the exception, the RemoteDelivery run() method was getting the same
message from the next call to 
  accept() and repeating...

Prevent ConcurrentModificationException in AvalonMailRepository by cloning
key sey before returning iterator.
  This has since been fixed in the James sources by simply catching and
ignoring the exception.  I think it is
  better to prevent the exception occurring in the first place.  Also, the
published fix has only been implemented
  in the accept() method, but the accept(long delay) was missed.

Added the dispose method to SMTPServer.java and RemoteManager.java for NT
socket release issue.
  Running inside JBoss we have the ability to stop and restart James.  On NT
the restart failed frequently
  because the sockets were not being released.

Changed JamesSpoolManager to throw instead of system.exit for bad init
mailet.
  Running inside JBoss (or just plain Phoenix), it is not good for James to
take out the entire platform
  what it fails.


Regards
Steve

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Problem with Retries and Bounces

[Steve Short]

Hi,

this info first appeared as a reply in the 'spooling problem'  thread in the
James Users list but no one commented on it there so I thought I'd post it
here.

I'm pretty certain that James is losing some attributes from the mail
message during the store/retrieve cycle.  It seems to work ok the first time
round for each message, but the second time round it doesn't get a full copy
of the message.  I changed the run() method of RemoteDelivery to dump out
parts of the message and this is what I get:

Started SMTP Server plain:25
Delivery thread after retrieve mail.From [0] = [EMAIL PROTECTED]
Delivery thread after retrieve mail.To [0] =
[EMAIL PROTECTED]
Delivery thread after retrieve mail.Subject = Message form Perl
script
mailtest.pl
Delivery thread after store and retrieve mail.From = null
Delivery thread after store and retrieve mail.To = null
Delivery thread after store and retrieve mail.Subject = null
Delivery thread after 2nd store and retrieve mail.From = null
Delivery thread after 2nd store and retrieve mail.To = null
Delivery thread after 2nd store and retrieve mail.Subject = null

Here's the snippet of code I modified in the run() method of RemoteDelivery:

log(Thread.currentThread().getName() + " will process mail "+ key);
MailImpl mail = outgoing.retrieve(key);

dumpMessage("Delivery thread after retrieve mail", mail);
outgoing.store(mail);
MailImpl newMail = outgoing.retrieve(key);
dumpMessage("Delivery thread after store and retrieve
mail",newMail);
outgoing.store(mail);
MailImpl newMail2 = outgoing.retrieve(key);
dumpMessage("Delivery thread after 2nd store and retrieve mail",
newMail2);

I haven't got the full picture yet, but it looks like the combination of
the Mail wrapper classes that James uses do not fully preserve the object
state during the store / retrieve cycle. I can force things to work by added
a 
call to mail.getMessage().saveChanges() after the first retrieve, but it
seems to
me that this is really a workaround to the root problem, but I am not sure
what
the correct solution it.

This consequence of this is that retries and bounces do not work and testing
confirms this.

Any comments, folks?


Regards
Steve


--
To unsubscribe, e-mail:   
For additional commands, e-mail: