Re: Download jars instead of keeping in CVS?
Noel J. Bergman wrote: Nicola, I suggest that you look again. Java WebStart is an application launcher, but look at the JNLP underneath it. It is a resource downloading system. As they say, and you quoted: The software distribution technology is only one aspect of JavaTM Web Start. It also provides security, updates to the applications, ease-of-use for end users, and flexibility for developers when they create the applications. It's for applications. Read on... It cannot be used as-is though. It has no way of defining a jar repository, and it gets resources like this: resources j2se version=1.3/ jar href=lib/SwingSet2.jar/ /resources The version is for the application. For what you want to do, if each jar had resource information in it, the check would be iterative. For example jar that you load, you check the j2se version necessary. I don't get this (I read the other mail too)... As you see there is no version info, the version info is about the whole JNPL descriptor. A better example, from my perspective, is: resources j2se version=1.2+/ jar href=application.jar version=1.1/ jar href=lib.jar version=2.1/ /resources Because that specifies which version of the jar is necessary. See also version.xml. Is this in the JNPL spec? Didn't know. There was a bit of misunderstanding here because IIUC you were talking about getting the releases, I was talking about getting the jars for the developers. Why not use it for both? I fail to see practical need for it. Let me explain. I want to get application.jar version 1.1 from http://mysite.net/ In practice, what do I need JNPL for? Where are the jars placed? In JNPL I see that it specifies what jars are needed for an app, not how to make a repository of jars. I see the need if I say: I want the jars for latest James. Ok, then I check for the JNPL file of James and it knows what to get... but then, if I want the jars for James 1.1? Is there a scheme for asking for a specific version of the app? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Download jars instead of keeping in CVS?
Danny, it seems that you have a good idea of what you would like to see, could you give me some pointers, maybe an implementation idea? :-) I don't think that I'm concerned with the repository *using* version information contained in the jars, if it keeps track externally and can return a file for a requiest containing name and version. The client should be able to tell whether or not a correctly named jar does or does not contain the intended library version. And furthermore that it can continue to tell even if the filename changes. Of course this is what the manifest is supposed to do. What we need is a library management tool to allow shared libraries to be installed and maintained centrally by the JVM, this can be queried by application classloaders to discover the file containing the required version of the relevant package, the returned path would be added to the classloader. Then library installation would be a case of defining dependancies and pointing this tool at a URL containing jars for download. If the version is found on the system no action is necessary, otherwise; Download the jar Confirm that the downloaded jar is indeed the expected version, Store it on the filesystem Provide classloaders with the path when they request the package version. Of course there are two immediate concerns, 1/ there is a requirement for strong names, whereby package names cannot collide. 2/ there is a security issue involved in allowing applications to access any installed library, even those not explicitly required by the application. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: An interesting note about memory leaks (was Memory leaks in RemoteDelivery mailet?)
After a day of wasted effort, I discovered that using -server to set the hotspot VM to server mode cured the problem entirely. The heap usage sat at around 5 - 6MB indefinitely. Apparently, when garbage collection is performed, memory is only freed until a certain threshold is reached. After that, the client VM decides that's enough until the high water mark is reached once more. The moral of the story is that not all memory consumption is leakage. and that -server is a necessity for java applications with long uptimes. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Download jars instead of keeping in CVS?
Note: sorry for the OT, but it's really interesting :-) Danny Angus wrote: Danny, it seems that you have a good idea of what you would like to see, could you give me some pointers, maybe an implementation idea? :-) I don't think that I'm concerned with the repository *using* version information contained in the jars, if it keeps track externally and can return a file for a requiest containing name and version. The client should be able to tell whether or not a correctly named jar does or does not contain the intended library version. And furthermore that it can continue to tell even if the filename changes. Ah, ok, good point. Using filenames is a reasonable possibility only if it's validated by the info in the manifest. Of course this is what the manifest is supposed to do. Yup. What we need is a library management tool to allow shared libraries to be installed and maintained centrally by the JVM, this can be queried by application classloaders to discover the file containing the required version of the relevant package, the returned path would be added to the classloader. Then library installation would be a case of defining dependancies and pointing this tool at a URL containing jars for download. If the version is found on the system no action is necessary, otherwise; Download the jar Confirm that the downloaded jar is indeed the expected version, Store it on the filesystem Provide classloaders with the path when they request the package version. This is exactly what Ruper does, *except* for the confirmation step. I agree that we have to do it, thanks for the suggestion :-) -ccing krysalis-dev for this- Of course there are two immediate concerns, 1/ there is a requirement for strong names, whereby package names cannot collide. Yes, we are working on it in the sandbox with a Krysalis Version project. Currently the Ruper conventions seem reasonably strong enough (basically the Jakarta ones: name-major.minor.fix-?label-?date), but the Version project is for using diverse mechanisms and more robust ones. 2/ there is a security issue involved in allowing applications to access any installed library, even those not explicitly required by the application. Could you please expand on this? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Download jars instead of keeping in CVS?
2/ there is a security issue involved in allowing applications to access any installed library, even those not explicitly required by the application. Could you please expand on this? It seems to me that an application could check for the presence of packages which you would not ordinarily want it to access. Activation and reflection allow programmes to programatically create objects/refrences at runtime, JDBC drivers and logging are two areas where runtime binding plays a key role, two ways to limit access to potentially dangerous code include not putting classes in the classpath and using the security manager. If somekind of system wide package discovery is available it removes the first of these safety nets, putting the whole burden on correct administration of the security manager. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Download jars instead of keeping in CVS?
Danny Angus wrote: 2/ there is a security issue involved in allowing applications to access any installed library, even those not explicitly required by the application. Could you please expand on this? It seems to me that an application could check for the presence of packages which you would not ordinarily want it to access. Activation and reflection allow programmes to programatically create objects/refrences at runtime, JDBC drivers and logging are two areas where runtime binding plays a key role, two ways to limit access to potentially dangerous code include not putting classes in the classpath and using the security manager. If somekind of system wide package discovery is available it removes the first of these safety nets, putting the whole burden on correct administration of the security manager. Ok, I get it. Coupling it with Noel's suggestion, it seems that JNPL has already thought of this with the sandbox and the jar signing. Ok, I guess that this thread is finally coming to an end, I really enjoyed it. Thanks for the info all of you, it was of great help :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDI Mailet Configuration
On Tue, 4 Feb 2003 17:42, Aaron Knauf wrote: Ok Folks, After careful deliberation, I think it is fair to sum up the JNDI discussion as follows: 1)Making JNDI integral to the Mailet container will not fly. Noel correctly points out that lightweight container are made difficult (impossible?) by requiring JNDI support. I can't really see the use of a lightweight container, but my perspective is somewhat narrow on this count, so I am willing to agree that someone else might find one useful. :-) 2)While I am convinced that per-mailet contexts are a great idea, no-one else seems to be. This tells me that my approach here might be the silver bullet that I am looking for (;-p), but others won't find it generally useful - so I won't force it on anyone. 3)Everyone seems to agree (or at least, not disagree) that JNDI is a good way for James to implement general resource sharing. This is to be considered a James-specific implementation detail and provided to Mailets as extended functionality, rather than as part of the Mailet API/spec. To tell the truth, the whole idea of using JNDI for standard resource access doesn't sit all that well with me. The JNDI Context interface just seems too broad and too general for what we want to achieve. I don't feel really strongly about this, but it seems that the primary benefit listed for using JNDI is that it's pre-existing standard. This is important, but not the only factor to consider. We should also examine whether it's a good match for what we want to provide to mailets. Namely: 1) Is there a close match between the javax.naming.Context interface, and what we want to provide to mailets? Do we want to provide a mutable context to Mailets? 2) Will using JNDI be easier for a Mailet author than, say, something like an Avalon Context? 3) Will using JNDI make it harder to provide a controlled, constrained environment for running Mailets. I'm a fan of IoC, and I think we need to keep control over what each Mailet can access. 4) Are we better off adding explicit lookup (and bind) methods to the Mailet API? Will this be clearer for Mailet authors than a simple, for anything else you use JNDI? 5) The hard part of resource provision is allowing Mailets to declare what they need, and for containers to set up their environment accordingly. The Servlet API just avoids this, it seems, by assuming everything is already there in JNDI under well-known names. This is simpler, I guess; and maybe that's all we want? Just some stuff I've been mulling over from behind the firewall, where my mailing lists are hidden from me :-/ (I'm starting to wonder if this work caper is all it's cracked up to be :). -- ciao, Daz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JNDI Mailet Configuration
- Original Message - From: Aaron Knauf [EMAIL PROTECTED] 2)Provide a configuration mechanism for initialising the JNDI tree with resources at system startup. I am thinking that a generic XML configuration file for setting resources into JNDI could be used. (This ought to be applicable beyond James.) Haven't thought this through too far, but at a minimum we should be able to create Contexts, set primitive values for these attributes, provide pluggability for setting non-primitive values (such as DataSources, ThreadPools, or custom objects like complex user configurations.). I think using XML/JNDI for mailet configuration may be heavy weight. A simple DTD as suggested earlier (by Danny? Aaron ? not sure) may be good enough. However if JNDI/XML is the direction to take, DSML (or subset) may be good candidate for Schema. It provides XML mapping to directory information and there are DSML providers for JNDI.. Spec is at http://www.oasis-open.org/committees/dsml/ Harmeet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail as the message store
Hi all, If nobody else jumps, I would not mind giving it a try. Sergei - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Monday, February 03, 2003 7:49 PM Subject: RE: JavaMail as the message store I believe that we have a consensus. :-) My suggestion, before we make changes globally, would be to replace the inbox handling in pop3handler.java and the store call in LocalDelivery.java to use a JavaMail store. It would be a temporary partial step backwards, so that we can make big steps forwards, and it would feel good to just see it working, albiet in an unreleasable form. Anyone feel like giving this a go to start? --- 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: JavaMail as the message store
Noel J. Bergman wrote: Serge, According to Alex's messages, he has spoken with Bill and there seems to be some willingness to address whatever issues Alex raised. We'll have to await details from Alex on those issues. In any event, my point about migration is simple. We won't preserve two implementations of the mail repository for the interim. But during initial development, we don't have to change the spool implementation, and we really don't need to change the ToRepository mailet, which is used to dump spam and error in the stock configuration. At the beginning, the only things that we HAVE to change are the LocalDelivery and POP3 handler components. 1. Change LocalDelivery and POP3 to use JavaMail stores. Use one of the existing JavaMail stores. 2. Test, tweak, test again. 3. Change ToRepository Mailet 4. After the spooler is replaced, we can remove the current mail repository interface. As I understand it, we also convert our implementations to JavaMail stores. This incremental development is intended to make sure that we have a working server throughout the entire process. Right, so basically just removing (and/or making abstract) the MailRepository interface, removing the definitions of MailRepository URLs in config.xml, and then fixing everything that uses that directly. I'm a bit leary we're missing something, but sounds like a plan. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail as the message store
- Original Message - From: Serge Sozonoff [EMAIL PROTECTED] Sent: Feb 4, 3:44 PM If nobody else jumps, I would not mind giving it a try. Go for it. :-) Harmeet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JavaMail as the message store
Right, so basically just removing (and/or making abstract) the MailRepository interface, removing the definitions of MailRepository URLs in config.xml, and then fixing everything that uses that directly. I'm a bit leary we're missing something, but sounds like a plan. Me too. I'd like to know what mailetcontext get repository is going to be replaced with in mailets, I hope it will be clear and simple for mailet authors to see how to get and create new repositories. Also, if fetch is going to use javamail we need to make sure that other mailets cant harvest usernames and passwords, or make connections masquerading as the users fetch is authenticating as. I'm not sure how suitable it is for multiuser like this, it may be fine, this is 2c worth of security warning. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16765] New: - Socket exception when trying to get news message from a NNTP client
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16765. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16765 Socket exception when trying to get news message from a NNTP client Summary: Socket exception when trying to get news message from a NNTP client Product: James Version: 2.1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: NNTPServer Repository AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] NNTP Client : Outlook, Mozilla Error occured when trying to get message ERROR nntpserver: Exception during connection:Connection aborted by peer: JVM_recv in socket input stream read java.net.SocketException: Connection aborted by peer: JVM_recv in socket input stream read at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at java.net.SocketInputStream.read(SocketInputStream.java:67) at java.io.InputStreamReader.fill(InputStreamReader.java:173) at java.io.InputStreamReader.read(InputStreamReader.java:249) at java.io.BufferedReader.fill(BufferedReader.java:139) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) at org.apache.james.nntpserver.NNTPHandler.handleConnection (NNTPHandler.java:357) at org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run (ServerConnection.java:404) at org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute (ExecutableRunnable.java:47) at org.apache.avalon.excalibur.thread.impl.WorkerThread.run (WorkerThread.java:80) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JNDI Mailet Configuration
To tell the truth, the whole idea of using JNDI for standard resource access doesn't sit all that well with me. The JNDI Context interface just seems too broad and too general for what we want to achieve. I appreciate this view. A lot of people have been scared away from JNDI because they view it as a complicated thing. But it need not be, and isn't. As noted, it has become an integral part of J2EE programming, included in the Servlet Specification, as well as other places. If you look at its use in those contexts, it is simple and straightfoward. 1) Is there a close match between the javax.naming.Context interface, and what we want to provide to mailets? Do we want to provide a mutable context to Mailets? I don't see this as an issue. It has already been resolved for J2EE. There are constraints over mutability. 2) Will using JNDI be easier for a Mailet author than, say, something like an Avalon Context? A consensus was to not adopt non-standard interfaces into the Mailet Specification. JNDI, JAAS, JDBC, JavaMail, etc., are all standard interfaces. 3) Will using JNDI make it harder to provide a controlled, constrained environment for running Mailets. I'm a fan of IoC, and I think we need to keep control over what each Mailet can access. I believe that it is unnecessary to do it per-matcher/mailet. We could do it the same way that the Servlet Specification does it: per-webapp, i.e., per-classloader. There are a variety of choices for how we might define what gets a unique classloader. Packages, sets of packages, processors, ... *if* we need to do it. A lot less overhead than per-class classloaders, and provides administrative control over JNDI context(s). It would also relieve Aaron of having to hack around JNDI usage patterns. If something like this becomes desirable, we can easily address it when we discover the need, and we'll adjust how we define resources. 4) Are we better off adding explicit lookup (and bind) methods to the Mailet API? Will this be clearer for Mailet authors than a simple, for anything else you use JNDI? Not in my view. We'd be just another ad hoc API that had to keep changing each time we had a new justifiable feature request. Plus, we would lose the benefits of people using a standard API. We may very well have some convenience methods. 5) The hard part of resource provision is allowing Mailets to declare what they need, and for containers to set up their environment accordingly. The funny thing is that both you and Aaron talk about this, but the simple fact is that James doesn't do that at all. The MailetContext is shared across all matchers and mailets, with no separation or security. If you look at config.xml, and then attempt to add to each matcher and mailet a list of all resources that each needs, I think you'll rapidly become sick of it. The Servlet API just avoids this, it seems, by assuming everything is already there in JNDI under well-known names. The well-defined names issue exists either way. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16770] New: - JAMES silently consumes java.lang.Error thrown by Maillet.service()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770
JAMES silently consumes java.lang.Error thrown by Maillet.service()
Summary: JAMES silently consumes java.lang.Error thrown by
Maillet.service()
Product: James
Version: 2.1
Platform: Other
OS/Version: Other
Status: NEW
Severity: Major
Priority: Other
Component: Mailet API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
A java.lang.Error indicates a catastrophic, unrecoverable failure for the JVM
itself. It should never be caught, the JVM should be allowed to abort.
For application servers that absolutely insist on attempting to continue to
provide uninterrupted service for other components when one component
experiences such a condition, the error should at the very least be reported to
the administrator and the component marked as offline; silently consuming a
java.lang.Error is Very Bad; continuing to attempt to stuff requests through a
failed component is Extraordinarily Bad.
Catching Throwable is Really Quite Bad.
My particular problem arose from having an error in my build.xml which meant
that a jar needed by the maillet was missing which meant that a
java.lang.NoClassDefFoundError was thrown during class loading while servicing
the first request. JAMES decided to pretend that the Error had not happened and
(a) not log it anywhere then (b) continue to stuff requests through the failed
component. It wasn't until I decided to investigate why multiple threads
appeared to be occupying the same synchronized block that I realised that
something other than an Exception was being thrown and that JAMES was concealing it.
If you're going to try to catch anything more than Exception, then PLEASE handle
them sensibly.
Oh, how to reproduce:
public void service(Mail mail) { throw new Error(); }
Then notice the complete absence of logging, stdout or stderr clues about what
has happened.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Download jars instead of keeping in CVS?
What we need is a library management tool to allow shared libraries to be installed and maintained centrally by the JVM, this can be queried by application classloaders to discover the file containing the required version of the relevant package, the returned path would be added to the classloader. We can use custom classloaders to inspect the jar manifests. That would be very slick. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JNDI Mailet Configuration
3)Everyone seems to agree (or at least, not disagree) that JNDI is a good way for James to implement general resource sharing. This is to be considered a James-specific implementation detail and provided to Mailets as extended functionality, rather than as part of the Mailet API/spec. No, I think that it should be a part of the Mailet Specification, in order to promote portable matchers and mailets. Just expressed as optional for a container implementation, to cover the lightweight scenario. 2)Provide a configuration mechanism for initialising the JNDI tree with resources at system startup. I am thinking that a generic XML configuration file for setting resources into JNDI could be used. Please look at tomcat configuration. Probably the server.xml approach, rather than what is in web.xml. We can pass a reference to a conf/jndi.xml file to a JNDIService from config.xml. JNDIService enabled=true configuration=file://conf/jndi.xml / 4)Add MailRepositories to JNDI for use by James Mailets. Leave this one alone for now. There are remaining nuances to be worked out. We've got a good handle on resources, so let's start with resources, and get to users and repositories after we have had time to work on those issues further. this generic approach to putting values into JNDI as system startup is something that is valueable beyond the scope of James. Considering that we're copying it from J2EE, that should not be surprising. I also intend to make is possible to approximate per-Mailet Contexts Please do not do it as you've proposed. As I suggested earlier, there are more appropriate ways to do this than what you are proposing. The classloader is the key. This is vital not only because of the previously discussed implications for JNDI, but because it is necessary if we want to impose Java Security on matchers and mailets. If we decide that we need separate (security) contexts for matchers and mailets, we will need to define them using classloaders anyway. If we want dynamically (re-)loadable processors, we will need classloaders. If/when we want to segment mailet applications, we will have to use classloaders to implement the segmentation on whatever boundaries we define. imply a commitment to keep the solution a little more generic than might otherwise be necessary. (i.e. no James-specific or Avalon-specific stuff in the core loading/initialisation code.) The JNDIService will be, and should be, an Avalon component. Internally, you can wrap a more generic class. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail as the message store
Hi Guys, I have been looking into this a little more and I have done some local testing (I now store mail through JavaMail (Maildir)) however there is something I am not sure about. What sort of a file based JavaMail Store are we thinking of using as the default for storing local James mail? Maildir is nice but it does not work under Windows. JProof Local Message Store should work but I am not sure what the license implications are. ICE MH JavaMail Provider (http://trustice.com/java/icemh/index.shtml) Others and as far as a JDBC Store goes, it looks like we might need to write our own Any thoughts on this? Thanks, Serge - Original Message - From: Danny Angus [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Tuesday, February 04, 2003 4:45 PM Subject: RE: JavaMail as the message store Right, so basically just removing (and/or making abstract) the MailRepository interface, removing the definitions of MailRepository URLs in config.xml, and then fixing everything that uses that directly. I'm a bit leary we're missing something, but sounds like a plan. Me too. I'd like to know what mailetcontext get repository is going to be replaced with in mailets, I hope it will be clear and simple for mailet authors to see how to get and create new repositories. Also, if fetch is going to use javamail we need to make sure that other mailets cant harvest usernames and passwords, or make connections masquerading as the users fetch is authenticating as. I'm not sure how suitable it is for multiuser like this, it may be fine, this is 2c worth of security warning. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Download jars instead of keeping in CVS?
Note: sorry for the OT, but it's really interesting :-) Especially since Andy just proposed using the maven repository as the primary means for distributing all ASF Java technologies. I think I'll let other people worry about that suggestion. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail as the message store
Maildir is nice but it does not work under Windows. Hi Serge, Why doesn't the maildir implementation work on Windows? Kenny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail as the message store
Hi Kenny, Because it uses filenames which are invalid on the Windows file system. Serge - Original Message - From: Kenny Smith [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Tuesday, February 04, 2003 7:37 PM Subject: Re: JavaMail as the message store Maildir is nice but it does not work under Windows. Hi Serge, Why doesn't the maildir implementation work on Windows? Kenny - 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: An interesting note about memory leaks (was Memory leaks inRemoteDelivery mailet?)
The moral of the story is that not all memory consumption is leakage. and that -server is a necessity for java applications with long uptimes. Well, recommended, but not strictly a necessity. The thing actually worked perfectly. The only troble is that if it suddely got a flurry of requests, it would have to garbage collect madly to free up enough memory to manage them. ADK There is no magic. --- Have you seen our website? http://www.vodafone.co.nz CAUTION: This correspondence is confidential and intended for the named recipient(s) only. If you are not the named recipient and receive this correspondence in error, you must not copy, distribute or take any action in reliance on it and you should delete it from your system and notify the sender immediately. Thank you. Unless otherwise stated, any views or opinions expressed are solely those of the author and do not represent those of Vodafone New Zealand Limited. Vodafone New Zealand Limited 21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand Telephone + 64 9 357 5100 Facsimile + 64 9 377 0962 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaMail as the message store
Serge Sozonoff wrote: Hi Guys, I have been looking into this a little more and I have done some local testing (I now store mail through JavaMail (Maildir)) however there is something I am not sure about. What sort of a file based JavaMail Store are we thinking of using as the default for storing local James mail? Maildir is nice but it does not work under Windows. JProof Local Message Store should work but I am not sure what the license implications are. ICE MH JavaMail Provider (http://trustice.com/java/icemh/index.shtml) Others and as far as a JDBC Store goes, it looks like we might need to write our own Any thoughts on this? I'm thinking (at least for porting reasons), we'll want to implement a JavaMail Store to access the existing (legacy) file mail repository. This may also be a fast, non-portable implementation... whether we pick that long-term as the default implementation is another thing, but this is what I figured we'd do in the short-term. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Download jars instead of keeping in CVS?
We can use custom classloaders to inspect the jar manifests. That would be very slick. :-) Oh yes indeedy, but it depends upon the manifests being correctly created. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16770] - JAMES silently consumes java.lang.Error thrown by Maillet.service()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770 JAMES silently consumes java.lang.Error thrown by Maillet.service() [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-02-04 19:24 --- Ironically, I fixed this defect yesterday and will be checking in code to the v2.1 branch that fixes it. The description of the error is not quite accurate, however. The problem was that JamesSpoolManager.run() did NOT catch the exception. Nothing else did, either, until it got up to Excalibur's WorkerThread, which silently ate the exception. What is necesary is for James to catch the exception, and then do whatever is necessary. For now, I am just logging the exceptions, which will show up in the spoolmanager log, as shown: java.lang.Error at org.apache.james.transport.mailets.Error.service(Error.java:27) at org.apache.james.transport.LinearProcessor.service (LinearProcessor.java:362) at org.apache.james.transport.JamesSpoolManager.process (JamesSpoolManager.java:385) at org.apache.james.transport.JamesSpoolManager.run (JamesSpoolManager.java:315) at org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute (ExecutableRunnable.java:47) at org.apache.avalon.excalibur.thread.impl.WorkerThread.run (WorkerThread.java:80) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-james/src/java/org/apache/james/core MimeMessageWrapper.java
noel2003/02/04 11:38:21
Modified:src/java/org/apache/james/core Tag: branch_2_1_fcs
MimeMessageWrapper.java
Log:
allow subject and date to be mutable in the pipeline
Revision ChangesPath
No revision
No revision
1.17.4.1 +7 -0
jakarta-james/src/java/org/apache/james/core/MimeMessageWrapper.java
Index: MimeMessageWrapper.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/core/MimeMessageWrapper.java,v
retrieving revision 1.17
retrieving revision 1.17.4.1
diff -u -r1.17 -r1.17.4.1
--- MimeMessageWrapper.java 26 Oct 2002 04:15:30 - 1.17
+++ MimeMessageWrapper.java 4 Feb 2003 19:38:21 - 1.17.4.1
@@ -697,6 +697,7 @@
loadMessage();
}
modified = true;
+headers.setHeader(RFC2822Headers.SUBJECT, subject);
message.setSubject(subject);
}
@@ -705,6 +706,11 @@
loadMessage();
}
modified = true;
+// is this correct?
+try {
+headers.setHeader(RFC2822Headers.SUBJECT, new
String(subject.getBytes(charset)));
+}
+catch (java.io.UnsupportedEncodingException _) { /* TODO */ }
message.setSubject(subject, charset);
}
@@ -713,6 +719,7 @@
loadMessage();
}
modified = true;
+headers.setHeader(RFC2822Headers.DATE, mailDateFormat.format(d));
message.setSentDate(d);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-james/src/java/org/apache/james/services SpoolRepository.java
noel2003/02/04 11:38:25
Modified:src/java/org/apache/james/mailrepository Tag: branch_2_1_fcs
AvalonSpoolRepository.java JDBCMailRepository.java
JDBCSpoolRepository.java
src/java/org/apache/james/services Tag: branch_2_1_fcs
SpoolRepository.java
Log:
made SpoolRepository.accept() interruptable; logged 'impossible' exceptions; fixed
bad javadoc markup
Revision ChangesPath
No revision
No revision
1.7.4.1 +17 -13
jakarta-james/src/java/org/apache/james/mailrepository/AvalonSpoolRepository.java
Index: AvalonSpoolRepository.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/mailrepository/AvalonSpoolRepository.java,v
retrieving revision 1.7
retrieving revision 1.7.4.1
diff -u -r1.7 -r1.7.4.1
--- AvalonSpoolRepository.java18 Aug 2002 07:23:55 - 1.7
+++ AvalonSpoolRepository.java4 Feb 2003 19:38:24 - 1.7.4.1
@@ -18,14 +18,12 @@
* Implementation of a MailRepository on a FileSystem.
*
* Requires a configuration element in the .conf.xml file of the form:
- * repository destinationURL=file://path-to-root-dir-for-repository
+ * lt;repository destinationURL=file://path-to-root-dir-for-repository
* type=MAIL
- * model=SYNCHRONOUS/
+ * model=SYNCHRONOUS/gt;
* Requires a logger called MailRepository.
*
* @version 1.0.0, 24/04/1999
- * @author Federico Barbieri [EMAIL PROTECTED]
- * @author Charles Benett [EMAIL PROTECTED]
*/
public class AvalonSpoolRepository
extends AvalonMailRepository
@@ -40,15 +38,15 @@
*
* @return the key for the mail
*/
-public synchronized String accept() {
+public synchronized String accept() throws InterruptedException {
if ((DEEP_DEBUG) (getLogger().isDebugEnabled())) {
getLogger().debug(Method accept() called);
}
-while (true) {
+while (!Thread.currentThread().isInterrupted()) {
try {
for(Iterator it = list(); it.hasNext(); ) {
-String s = it.next().toString();
+String s = it.next().toString();
if ((DEEP_DEBUG) (getLogger().isDebugEnabled())) {
StringBuffer logBuffer =
new StringBuffer(64)
@@ -66,11 +64,14 @@
}
wait();
-} catch (InterruptedException ignored) {
-} catch (ConcurrentModificationException ignoredAlso) {
+} catch (InterruptedException ex) {
+throw ex;
+} catch (ConcurrentModificationException cme) {
// Should never get here now that list methods clones keyset for
iterator
+getLogger().error(CME in spooler - please report to
http://james.apache.org;, cme);
}
}
+throw new InterruptedException();
}
/**
@@ -84,11 +85,11 @@
*
* @return the key for the mail
*/
-public synchronized String accept(long delay) {
+public synchronized String accept(long delay) throws InterruptedException {
if ((DEEP_DEBUG) (getLogger().isDebugEnabled())) {
getLogger().debug(Method accept(delay) called);
}
-while (true) {
+while (!Thread.currentThread().isInterrupted()) {
long youngest = 0;
for (Iterator it = list(); it.hasNext(); ) {
String s = it.next().toString();
@@ -139,10 +140,13 @@
} else {
wait(youngest - System.currentTimeMillis());
}
-} catch (InterruptedException ignored) {
-} catch (ConcurrentModificationException ignoredAlso) {
+} catch (InterruptedException ex) {
+throw ex;
+} catch (ConcurrentModificationException cme) {
// Should never get here now that list methods clones keyset for
iterator
+getLogger().error(CME in spooler - please report to
http://james.apache.org;, cme);
}
}
+throw new InterruptedException();
}
}
1.30.4.2 +1 -1
jakarta-james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java
Index: JDBCMailRepository.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java,v
retrieving revision 1.30.4.1
retrieving revision 1.30.4.2
diff -u -r1.30.4.1 -r1.30.4.2
---
cvs commit: jakarta-james/src/java/org/apache/james/util/connection ServerConnection.java
noel2003/02/04 11:38:30
Modified:src/java/org/apache/james/nntpserver/repository Tag:
branch_2_1_fcs NNTPSpooler.java
src/java/org/apache/james/transport Tag: branch_2_1_fcs
JamesSpoolManager.java
src/java/org/apache/james/transport/mailets Tag:
branch_2_1_fcs RemoteDelivery.java
src/java/org/apache/james/util/connection Tag:
branch_2_1_fcs ServerConnection.java
Log:
Runnables should log all exceptions in run() - Avalon Excalibur WorkerThread doesn't
Revision ChangesPath
No revision
No revision
1.11.4.3 +1 -1
jakarta-james/src/java/org/apache/james/nntpserver/repository/NNTPSpooler.java
Index: NNTPSpooler.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/nntpserver/repository/NNTPSpooler.java,v
retrieving revision 1.11.4.2
retrieving revision 1.11.4.3
diff -u -r1.11.4.2 -r1.11.4.3
--- NNTPSpooler.java 1 Feb 2003 21:00:29 - 1.11.4.2
+++ NNTPSpooler.java 4 Feb 2003 19:38:28 - 1.11.4.3
@@ -214,7 +214,7 @@
getLogger().debug(Processing file:
+f.getAbsolutePath());
try {
process(f);
-} catch(Exception ex) {
+} catch(Throwable ex) {
getLogger().debug(Exception occured while
processing file: +
f.getAbsolutePath(),ex);
} finally {
No revision
No revision
1.20.4.2 +3 -3
jakarta-james/src/java/org/apache/james/transport/JamesSpoolManager.java
Index: JamesSpoolManager.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/JamesSpoolManager.java,v
retrieving revision 1.20.4.1
retrieving revision 1.20.4.2
diff -u -r1.20.4.1 -r1.20.4.2
--- JamesSpoolManager.java1 Feb 2003 20:12:54 - 1.20.4.1
+++ JamesSpoolManager.java4 Feb 2003 19:38:29 - 1.20.4.2
@@ -335,11 +335,11 @@
spool.unlock(key);
}
mail = null;
-} catch (Exception e) {
+} catch (Throwable e) {
e.printStackTrace();
if (getLogger().isErrorEnabled()) {
getLogger().error(Exception in JamesSpoolManager.run
- + e.getMessage());
+ + e.getMessage(), e);
}
}
}
No revision
No revision
1.33.4.1 +2 -2
jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java
Index: RemoteDelivery.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java,v
retrieving revision 1.33
retrieving revision 1.33.4.1
diff -u -r1.33 -r1.33.4.1
--- RemoteDelivery.java 14 Dec 2002 03:30:11 - 1.33
+++ RemoteDelivery.java 4 Feb 2003 19:38:29 - 1.33.4.1
@@ -605,7 +605,7 @@
outgoing.remove(key);
throw e;
}
-} catch (Exception e) {
+} catch (Throwable e) {
log(Exception caught in RemoteDelivery.run(): + e);
}
}
No revision
No revision
1.3.4.1 +2 -2
jakarta-james/src/java/org/apache/james/util/connection/ServerConnection.java
Index: ServerConnection.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/util/connection/ServerConnection.java,v
retrieving revision 1.3
retrieving revision 1.3.4.1
diff -u -r1.3 -r1.3.4.1
--- ServerConnection.java 30 Oct 2002 10:34:58 - 1.3
+++ ServerConnection.java 4 Feb 2003 19:38:29 - 1.3.4.1
@@ -317,7 +317,7 @@
}
} catch( IOException ioe ) {
getLogger().error( Exception accepting connection, ioe );
-} catch( Exception e ) {
+} catch( Throwable e ) {
getLogger().error( Exception executing client connection runner:
+ e.getMessage(), e );
}
}
@@ -408,7 +408,7 @@
getLogger().debug( message );
}
-
cvs commit: jakarta-james/src/java/org/apache/james/mailrepository AvalonMailRepository.java
noel2003/02/04 11:51:17 Modified:src/java/org/apache/james/mailrepository Tag: branch_2_1_fcs AvalonMailRepository.java Log: fixed bad javadoc markup Revision ChangesPath No revision No revision 1.20.4.1 +2 -4 jakarta-james/src/java/org/apache/james/mailrepository/AvalonMailRepository.java Index: AvalonMailRepository.java === RCS file: /home/cvs/jakarta-james/src/java/org/apache/james/mailrepository/AvalonMailRepository.java,v retrieving revision 1.20 retrieving revision 1.20.4.1 diff -u -r1.20 -r1.20.4.1 --- AvalonMailRepository.java 2 Oct 2002 06:12:02 - 1.20 +++ AvalonMailRepository.java 4 Feb 2003 19:51:16 - 1.20.4.1 @@ -33,14 +33,12 @@ * Implementation of a MailRepository on a FileSystem. * * Requires a configuration element in the .conf.xml file of the form: - * repository destinationURL=file://path-to-root-dir-for-repository + * lt;repository destinationURL=file://path-to-root-dir-for-repository * type=MAIL - * model=SYNCHRONOUS/ + * model=SYNCHRONOUS/gt; * Requires a logger called MailRepository. * * @version 1.0.0, 24/04/1999 - * @author Federico Barbieri [EMAIL PROTECTED] - * @author Charles Benett [EMAIL PROTECTED] */ public class AvalonMailRepository extends AbstractLogEnabled - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JNDI Mailet Configuration
Hi Noel, I don't have a problem with any of this. I am, however, a little unclear of your meaning on one point: I also intend to make is possible to approximate per-Mailet Contexts [Noel] Please do not do it as you've proposed. As I suggested earlier, there are more appropriate ways to do this than what you are proposing. The classloader is the key. This is vital not only because of the previously discussed implications for JNDI, but because it is necessary if we want to impose Java Security on matchers and mailets. If we decide that we need separate (security) contexts for matchers and mailets, we will need to define them using classloaders anyway. If we want dynamically (re-)loadable processors, we will need classloaders. If/when we want to segment mailet applications, we will have to use classloaders to implement the segmentation on whatever boundaries we define. Do I take it that you are advocating that we go back to the idea that new InitialContext() will provide a mailet-specific context? (Well, actually classloader-specific, by the sound.) If so, I do not disagree. However, as a first step, treating JNDI as a single tree, to which all mailets have access is easier than playing with classloaders - particularly because the manner in which we use (and scope) classloaders is not yet fully defined. (Unless Danny is further along with this than I realise?) Basically, I am saying that step one should be to get it working - step two can make it fancy. [Noel] The JNDIService will be, and should be, an Avalon component. Internally, you can wrap a more generic class. This is precisely my intent. The reason I mentioned that generic aspect is just to point out that it will be necessary to maintain that border. It might otherwise be tempting to abandon genericity for the convenience of giving James/Avalon direct hooks into the JNDI code. If that happens, I'll be stuck re-writing those non-generic bits when I go to use the code elsewhere. Cheers ADK There is no magic. Noel J. Bergman To: James Developers List [EMAIL PROTECTED] noel@devtech. cc: com Subject: RE: JNDI Mailet Configuration 05/02/2003 06:23 Please respond to James Developers List 3)Everyone seems to agree (or at least, not disagree) that JNDI is a good way for James to implement general resource sharing. This is to be considered a James-specific implementation detail and provided to Mailets as extended functionality, rather than as part of the Mailet API/spec. No, I think that it should be a part of the Mailet Specification, in order to promote portable matchers and mailets. Just expressed as optional for a container implementation, to cover the lightweight scenario. 2)Provide a configuration mechanism for initialising the JNDI tree with resources at system startup. I am thinking that a generic XML configuration file for setting resources into JNDI could be used. Please look at tomcat configuration. Probably the server.xml approach, rather than what is in web.xml. We can pass a reference to a conf/jndi.xml file to a JNDIService from config.xml. JNDIService enabled=true configuration=file://conf/jndi.xml / 4)Add MailRepositories to JNDI for use by James Mailets. Leave this one alone for now. There are remaining nuances to be worked out.
Re: JNDI Mailet Configuration
Thanks Harmeet. I'll take a look at DSML. As for JNDI/XML being heavyweight - you are correct. However, it is no longer being proposed as part of the Mailet API. Apparently (based on Noel's latest comments) it is to be an optional part of the spec. Note also that any existing J2EE appserver that wants to add a mailet container to their bag of tricks will already have JNDI, anyway. Cheers ADK There is no magic. Harmeet Bedi harmeet@kodem To: James Developers List [EMAIL PROTECTED] use.com cc: Subject: Re: JNDI Mailet Configuration 05/02/2003 01:27 Please respond to James Developers List - Original Message - From: Aaron Knauf [EMAIL PROTECTED] 2)Provide a configuration mechanism for initialising the JNDI tree with resources at system startup. I am thinking that a generic XML configuration file for setting resources into JNDI could be used. (This ought to be applicable beyond James.) Haven't thought this through too far, but at a minimum we should be able to create Contexts, set primitive values for these attributes, provide pluggability for setting non-primitive values (such as DataSources, ThreadPools, or custom objects like complex user configurations.). I think using XML/JNDI for mailet configuration may be heavy weight. A simple DTD as suggested earlier (by Danny? Aaron ? not sure) may be good enough. However if JNDI/XML is the direction to take, DSML (or subset) may be good candidate for Schema. It provides XML mapping to directory information and there are DSML providers for JNDI.. Spec is at http://www.oasis-open.org/committees/dsml/ Harmeet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Have you seen our website? http://www.vodafone.co.nz CAUTION: This correspondence is confidential and intended for the named recipient(s) only. If you are not the named recipient and receive this correspondence in error, you must not copy, distribute or take any action in reliance on it and you should delete it from your system and notify the sender immediately. Thank you. Unless otherwise stated, any views or opinions expressed are solely those of the author and do not represent those of Vodafone New Zealand Limited. Vodafone New Zealand Limited 21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand Telephone + 64 9 357 5100 Facsimile + 64 9 377 0962 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JNDI Mailet Configuration
[Darrell] 5) The hard part of resource provision is allowing Mailets to declare what they need, and for containers to set up their environment accordingly. [Noel] The funny thing is that both you and Aaron talk about this, but the simple fact is that James doesn't do that at all. The MailetContext is shared across all matchers and mailets, with no separation or security. If you look at config.xml, and then attempt to add to each matcher and mailet a list of all resources that each needs, I think you'll rapidly become sick of it. I think that all three of us have a very different concept of how this would work. I would not expect that mailet to /declare/ any resources. The administrator would have to know what resources (e.g. data sources, ejb's, etc.) the mailet needed (presumably through reading the doco that accompanied the mailet) in order to configure them in the mailet's context. Further, a template method would automatically add any resources that are deemed necessary to every mailet. However, given that per-mailet contexts seem not to have found favour, the point is moot. Cheers ADK There is no magic. --- Have you seen our website? http://www.vodafone.co.nz CAUTION: This correspondence is confidential and intended for the named recipient(s) only. If you are not the named recipient and receive this correspondence in error, you must not copy, distribute or take any action in reliance on it and you should delete it from your system and notify the sender immediately. Thank you. Unless otherwise stated, any views or opinions expressed are solely those of the author and do not represent those of Vodafone New Zealand Limited. Vodafone New Zealand Limited 21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand Telephone + 64 9 357 5100 Facsimile + 64 9 377 0962 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16765] - Socket exception when trying to get news message from a NNTP client
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16765. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16765 Socket exception when trying to get news message from a NNTP client --- Additional Comments From [EMAIL PROTECTED] 2003-02-04 20:30 --- It would help to know the specific version and vendor of the JVM. If I recall correctly, previous reports of this problem have been cleared up, and appear to have been related to a bug in a particular version of the JVM for Windows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JNDI Mailet Configuration
As for JNDI/XML being heavyweight - you are correct. All of the code that we should want is already present in tomcat's CVS module. Apparently (based on Noel's latest comments) it is to be an optional part of the spec. That is a proposal. So far there is the makings of a lazy consensus. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16765] - Socket exception when trying to get news message from a NNTP client
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16765. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16765 Socket exception when trying to get news message from a NNTP client --- Additional Comments From [EMAIL PROTECTED] 2003-02-04 20:47 --- The problem seems to be solve with the latest version James 2.1a5. Additional information : JDK was 1.3.1 Thanks for your help - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16765] - Socket exception when trying to get news message from a NNTP client
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16765. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16765 Socket exception when trying to get news message from a NNTP client --- Additional Comments From [EMAIL PROTECTED] 2003-02-04 20:59 --- If you can, would you please install Sun JVM 1.4.1 and see if it goes away. My understanding is that there was an SoTimeout defect in an earlier version of Sun JVM for Windows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-james/src/java/org/apache/james/core MimeMessageWrapper.java
noel2003/02/04 13:05:34
Modified:src/java/org/apache/james/core MimeMessageWrapper.java
Log:
allow subject and date to be mutable in the pipeline
Revision ChangesPath
1.21 +7 -0
jakarta-james/src/java/org/apache/james/core/MimeMessageWrapper.java
Index: MimeMessageWrapper.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/core/MimeMessageWrapper.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- MimeMessageWrapper.java 12 Jan 2003 22:38:30 - 1.20
+++ MimeMessageWrapper.java 4 Feb 2003 21:05:32 - 1.21
@@ -716,6 +716,7 @@
loadMessage();
}
modified = true;
+headers.setHeader(RFC2822Headers.SUBJECT, subject);
message.setSubject(subject);
}
@@ -724,6 +725,11 @@
loadMessage();
}
modified = true;
+// is this correct?
+try {
+headers.setHeader(RFC2822Headers.SUBJECT, new
String(subject.getBytes(charset)));
+}
+catch (java.io.UnsupportedEncodingException _) { /* TODO */ }
message.setSubject(subject, charset);
}
@@ -732,6 +738,7 @@
loadMessage();
}
modified = true;
+headers.setHeader(RFC2822Headers.DATE, mailDateFormat.format(d));
message.setSentDate(d);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-james/src/java/org/apache/mailet SpoolRepository.java
noel2003/02/04 13:05:45
Modified:src/java/org/apache/james/mailrepository
AvalonSpoolRepository.java JDBCMailRepository.java
JDBCSpoolRepository.java
src/java/org/apache/mailet SpoolRepository.java
Log:
made SpoolRepository.accept() interruptable; logged 'impossible' exceptions
Revision ChangesPath
1.13 +14 -8
jakarta-james/src/java/org/apache/james/mailrepository/AvalonSpoolRepository.java
Index: AvalonSpoolRepository.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/mailrepository/AvalonSpoolRepository.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- AvalonSpoolRepository.java14 Jan 2003 13:58:21 - 1.12
+++ AvalonSpoolRepository.java4 Feb 2003 21:05:41 - 1.13
@@ -38,11 +38,11 @@
*
* @return the key for the mail
*/
-public synchronized String accept() {
+public synchronized String accept() throws InterruptedException {
if ((DEEP_DEBUG) (getLogger().isDebugEnabled())) {
getLogger().debug(Method accept() called);
}
-while (true) {
+while (!Thread.currentThread().isInterrupted()) {
try {
for(Iterator it = list(); it.hasNext(); ) {
@@ -64,11 +64,14 @@
}
wait();
-} catch (InterruptedException ignored) {
-} catch (ConcurrentModificationException ignoredAlso) {
+} catch (InterruptedException ex) {
+throw ex;
+} catch (ConcurrentModificationException cme) {
// Should never get here now that list methods clones keyset for
iterator
+getLogger().error(CME in spooler - please report to
http://james.apache.org;, cme);
}
}
+throw new InterruptedException();
}
/**
@@ -82,11 +85,11 @@
*
* @return the key for the mail
*/
-public synchronized String accept(long delay) {
+public synchronized String accept(long delay) throws InterruptedException {
if ((DEEP_DEBUG) (getLogger().isDebugEnabled())) {
getLogger().debug(Method accept(delay) called);
}
-while (true) {
+while (!Thread.currentThread().isInterrupted()) {
long youngest = 0;
for (Iterator it = list(); it.hasNext(); ) {
String s = it.next().toString();
@@ -137,10 +140,13 @@
} else {
wait(youngest - System.currentTimeMillis());
}
-} catch (InterruptedException ignored) {
-} catch (ConcurrentModificationException ignoredAlso) {
+} catch (InterruptedException ex) {
+throw ex;
+} catch (ConcurrentModificationException cme) {
// Should never get here now that list methods clones keyset for
iterator
+getLogger().error(CME in spooler - please report to
http://james.apache.org;, cme);
}
}
+throw new InterruptedException();
}
}
1.39 +1 -1
jakarta-james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java
Index: JDBCMailRepository.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- JDBCMailRepository.java 2 Feb 2003 23:36:16 - 1.38
+++ JDBCMailRepository.java 4 Feb 2003 21:05:41 - 1.39
@@ -755,7 +755,7 @@
rsListMessages = listMessages.executeQuery();
List messageList = new ArrayList();
-while (rsListMessages.next() /*
!Thread.currentThread().isInterrupted() -- post 2.1 enable this (NjB) */) {
+while (rsListMessages.next()
!Thread.currentThread().isInterrupted()) {
messageList.add(rsListMessages.getString(1));
}
return messageList.iterator();
1.19 +13 -10
jakarta-james/src/java/org/apache/james/mailrepository/JDBCSpoolRepository.java
Index: JDBCSpoolRepository.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/mailrepository/JDBCSpoolRepository.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- JDBCSpoolRepository.java 14 Jan 2003 13:58:21 - 1.18
+++ JDBCSpoolRepository.java 4 Feb 2003 21:05:41 - 1.19
@@ -95,12 +95,12 @@
/**
* Return the
cvs commit: jakarta-james/src/java/org/apache/james/util/connection ServerConnection.java
noel2003/02/04 13:06:00
Modified:src/java/org/apache/james/nntpserver/repository
NNTPSpooler.java
src/java/org/apache/james/transport JamesSpoolManager.java
src/java/org/apache/james/transport/mailets
RemoteDelivery.java
src/java/org/apache/james/util/connection
ServerConnection.java
Log:
Runnables should log all exceptions in run() - Avalon Excalibur WorkerThread doesn't
Revision ChangesPath
1.17 +1 -1
jakarta-james/src/java/org/apache/james/nntpserver/repository/NNTPSpooler.java
Index: NNTPSpooler.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/nntpserver/repository/NNTPSpooler.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- NNTPSpooler.java 1 Feb 2003 21:02:16 - 1.16
+++ NNTPSpooler.java 4 Feb 2003 21:05:54 - 1.17
@@ -214,7 +214,7 @@
getLogger().debug(Processing file:
+f.getAbsolutePath());
try {
process(f);
-} catch(Exception ex) {
+} catch(Throwable ex) {
getLogger().debug(Exception occured while
processing file: +
f.getAbsolutePath(),ex);
} finally {
1.27 +3 -3
jakarta-james/src/java/org/apache/james/transport/JamesSpoolManager.java
Index: JamesSpoolManager.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/JamesSpoolManager.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- JamesSpoolManager.java1 Feb 2003 20:13:33 - 1.26
+++ JamesSpoolManager.java4 Feb 2003 21:05:55 - 1.27
@@ -290,10 +290,10 @@
spool.unlock(key);
}
mail = null;
-} catch (Exception e) {
+} catch (Throwable e) {
e.printStackTrace();
if (getLogger().isErrorEnabled()) {
-getLogger().error(Exception in JamesSpoolManager.run +
e.getMessage());
+getLogger().error(Exception in JamesSpoolManager.run +
e.getMessage(), e);
}
}
}
1.41 +3 -3
jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java
Index: RemoteDelivery.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- RemoteDelivery.java 14 Jan 2003 13:41:56 - 1.40
+++ RemoteDelivery.java 4 Feb 2003 21:05:56 - 1.41
@@ -602,8 +602,8 @@
outgoing.remove(key);
throw e;
}
-} catch (Exception e) {
-log(Exception caught in RemoteDelivery.run(): + e);
+} catch (Throwable e) {
+if (!destroyed) log(Exception caught in RemoteDelivery.run():
+ e);
}
}
} finally {
1.6 +2 -2
jakarta-james/src/java/org/apache/james/util/connection/ServerConnection.java
Index: ServerConnection.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/util/connection/ServerConnection.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ServerConnection.java 14 Jan 2003 13:42:07 - 1.5
+++ ServerConnection.java 4 Feb 2003 21:05:59 - 1.6
@@ -315,7 +315,7 @@
}
} catch( IOException ioe ) {
getLogger().error( Exception accepting connection, ioe );
-} catch( Exception e ) {
+} catch( Throwable e ) {
getLogger().error( Exception executing client connection runner:
+ e.getMessage(), e );
}
}
@@ -404,7 +404,7 @@
getLogger().debug( message );
}
-} catch( Exception e ) {
+} catch( Throwable e ) {
getLogger().error( Error handling connection, e );
} finally {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: JavaMail as the message store
Sergei, As Serge said, we'll eventually migrate the existing repository implementations, but in the meantime, why don't you use mbox or MH? Either one of those should get you going without other changes. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Avalon expectations: platform or toolset?
I have always viewed Avalon as a server platform, hence was bothered that it didn't have convenient/solid logging, usable error messages on configuration problems, no service installation feature, and etc... I believe that those are things that Avalon would view as responsibilities of a container, so you would be right to complain about things being missing from, for example, Phoenix. the Avalon community IS looking at this project as primarily a way to make the IoC design pattern much easier to implement and use. Perhaps, but when they implement pooling, threading, I/O packages, and all of the other stuff, they are making a commitment, not just providing a proof of concept. The servlet group rejected [mailets as servlets] then largely because servlets (HTTP) is a request/response model while mailets (SMTP) are a filtering/queuing/messaging model. That's the same way I view it. Similar philosophically, but different where the models are different. At this point I think following the same J2EE design patterns will allow us to get traction from that community even more. In fact, we should probably invite Remy to participate as we incorporate org.apache.naming, and I am beginning to think that it should eventually be moved into Commons. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JavaMail as the message store
Another question I have, having followed this thread with only half my attention.. we currently store Mail's in the repository, and were planning to add attributes to Mail, will this proposal still allow this? I would hate to see messages delivered into, say, an error repository lose all their meta-data. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JavaMail as the message store
Danny, You raise a good question. Attributes were, in my understanding, supposed to be stored on the Mail objects. MimeMessage objects would not be touched. For something like mbox or maildir, which are standard formats that need to be read by other toosl, I don't think that there is a place to preserve the meta-data from the Mail object (but we can check). During processing it is a non-issue beause the mail objects will be persistent in the spool, and will preserve that information. If we want to make it a requirement to support special stores for spam and error that preserve the associated mail objects, I think that'll be OK. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16770] - JAMES silently consumes java.lang.Error thrown by Maillet.service()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770
JAMES silently consumes java.lang.Error thrown by Maillet.service()
--- Additional Comments From [EMAIL PROTECTED] 2003-02-04 23:55 ---
Ah, superb timing.
You are right of course about the inaccuracy in my description, in all cases by
JAMES I meant JAMES or one of the components upon which it depends. I have
not yet looked deeply enough to make sense of what Excalibur is or does. (I'll
do so later.)
Given that it is Excalibur's WorkerThread that is silently consuming
java.lang.Error, then it might be reasonable to report the bug there (I don't
yet know enough to do this). Given that inserting a workaround into JAMES gets
JAMES clear of this bug, then I'm all for it of course.
At the risk of teaching you to suck eggs, I'll point out that, if you are going
to catch java.lang.Error, then a not-unreasonable response is System.exit().
This is because java.lang.Error and its decendants are generally used to signify
problems that represent a breach of the Java type system (e.g. out of memory,
classes missing, signatures altered incompatibly, etc.), in roughly the same
sense that a kernel panic does in an operating system. That Java allows you a
chance to clean up (by throwing an Error instead of aborting immediately) is a
deliberate feature, however using it to keep a broken type system running
indefinitely may introduce further problems. Most seriously, if a type system
breach leaves a SecurityManager in an inconsistent state (e.g. out of memory
leading to failed allocation of an object during the updating of a linked list
of credentials), then by catching Error and not aborting the JVM, you've
provided a vulnerability through which an adversary may breach access control,
confidentiality or integrity constraints.
Better to reduce availability and allow an adversary to bring about a denial of
service (by tickling a bug which aborts the JVM) than to open a potentially
serious hole. IMHO.
{{ Lecture ends :-) }}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-james/src/conf james-assembly.xml james-config.xml james-server.xml
noel2003/02/04 20:30:04 Modified:src/conf james-assembly.xml james-config.xml james-server.xml Log: Added FetchMail service; updated DNS config (missed it last time somehow) Revision ChangesPath 1.14 +7 -0 jakarta-james/src/conf/james-assembly.xml Index: james-assembly.xml === RCS file: /home/cvs/jakarta-james/src/conf/james-assembly.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- james-assembly.xml26 Oct 2002 04:15:29 - 1.13 +++ james-assembly.xml5 Feb 2003 04:30:03 - 1.14 @@ -109,6 +109,13 @@ provide name=James role=org.apache.james.services.MailServer/ /block + !-- FetchMail Service -- + block name=fetchmail class=org.apache.james.fetchmail.FetchScheduler +provide name=scheduler + role=org.apache.avalon.cornerstone.services.scheduler.TimeScheduler/ +provide name=James role=org.apache.james.services.MailServer/ + /block + !-- The High Level Storage block -- block name=mailstore class=org.apache.james.core.AvalonMailStore provide name=objectstorage 1.45 +49 -4 jakarta-james/src/conf/james-config.xml Index: james-config.xml === RCS file: /home/cvs/jakarta-james/src/conf/james-config.xml,v retrieving revision 1.44 retrieving revision 1.45 diff -u -r1.44 -r1.45 --- james-config.xml 18 Jan 2003 23:22:34 - 1.44 +++ james-config.xml 5 Feb 2003 04:30:03 - 1.45 @@ -42,7 +42,7 @@ !-- In most cases this will be necessary. -- !-- By default, the servername 'localhost' is specified. This can be removed, if required. -- !-- -- - !-- Warning: If you are using fetchpop it is important to include the -- + !-- Warning: If you are using fetchmail it is important to include the -- !-- fetched domains in the server name list to prevent looping. -- servernames autodetect=true autodetectIP=true !-- CONFIRM? -- @@ -76,6 +76,7 @@ !-- Warning: It is important to prevent mail from looping by setting the -- !-- fetched domains in the servernames section of the James block -- !-- above. This block is disabled by default. -- + !-- DEPRECATED: SEE FETMCHMAIL BLOCK, BELOW. -- fetchpop enabled=false !-- You can have as many fetch tasks as you want, but each must have a -- !-- unique name by which it identified -- @@ -91,6 +92,46 @@ /fetch /fetchpop + !-- Fetch mail block, fetches mail from message servers and inserts it into the incoming spool -- + !-- Warning: It is important to prevent mail from looping by setting the -- + !-- fetched domains in the servernames section of the James block -- + !-- above. This block is disabled by default. -- +fetchmail enabled=false +!-- You can have as many fetch tasks as you want, but each must have a -- +!-- unique name by which it identified -- +fetch name=mydomain.com +!-- Host name or IP address -- +hostmail.mydomain.com/host +!-- Account login username -- +userusername/user +!-- Account login password -- +passwordpass/password +!-- How frequently this account is checked - in milliseconds. 60 is every ten minutes -- +interval60/interval +!-- Fetchmail will leave the fetched message unchanged and will add a new envelope -- +!-- recipient before spooling the message in James. -- +!-- Fetchmail will try and determine the original recipient of the message -- +!-- in the following ways: -- +!-- First it tries to parse the Received: headers and look for the for parameter-- +!-- If the for parameter is not found it will check the To: header and if it only -- +!-- contains one address it will be used as the new envelope recipient. -- +!-- If no recipient can be determined, the value defined in the recipient parameter -- +!-- will be used. Setting ignorercpt-header to true will force the defined recipient -- +!-- to ALWAYS be used and the parsing of headers will be ignored -- +recipient ignorercpt-header=false[EMAIL PROTECTED]/recipient + +!-- name of the javamail provider you wish to use -- +!-- (pop3, imap, etc. -- +javaMailProviderNamepop3/javaMailProviderName + +!-- name of the folder to open -- +
cvs commit: jakarta-james/src/java/org/apache/james/fetchmail - New directory
noel2003/02/04 20:31:05 jakarta-james/src/java/org/apache/james/fetchmail - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-james/src/java/org/apache/james/fetchmail FetchMail.java FetchScheduler.java FetchScheduler.xinfo ReaderInputStream.java
noel2003/02/04 20:31:40
Added: src/java/org/apache/james/fetchmail FetchMail.java
FetchScheduler.java FetchScheduler.xinfo
ReaderInputStream.java
Log:
Added FetchMail service
Revision ChangesPath
1.1 jakarta-james/src/java/org/apache/james/fetchmail/FetchMail.java
Index: FetchMail.java
===
/*
* Copyright (C) The Apache Software Foundation. All rights reserved.
*
* This software is published under the terms of the Apache Software License
* version 1.1, a copy of which has been included with this distribution in
* the LICENSE file.
*/
package org.apache.james.fetchmail;
import java.io.IOException;
import java.io.InputStream;
import java.net.SocketException;
import java.util.Enumeration;
import java.util.Vector;
import java.util.*;
import java.io.*;
import javax.mail.*;
import javax.mail.event.*;
import javax.mail.internet.*;
import javax.activation.*;
import org.apache.avalon.cornerstone.services.scheduler.Target;
import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.component.ComponentManager;
import org.apache.avalon.framework.component.Composable;
import org.apache.avalon.framework.component.DefaultComponentManager;
import org.apache.avalon.framework.configuration.Configurable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.logger.AbstractLogEnabled;
import org.apache.commons.net.pop3.POP3Client;
import org.apache.commons.net.pop3.POP3MessageInfo;
import org.apache.james.services.MailServer;
import org.apache.mailet.*;
import org.apache.james.core.MailImpl;
/**
*
* A class which fetches mail from a single account and inserts it
* into the incoming spool
*
* $Id: FetchMail.java,v 1.1 2003/02/05 04:31:40 noel Exp $
*
*/
public class FetchMail extends AbstractLogEnabled implements Configurable, Target {
/**
* The MailServer service
*/
private MailServer server;
/**
* The user to send the fetched mail to
*/
private MailAddress recipient;
/**
* Don't parse header looking for recipient
*/
private boolean ignoreOriginalRecipient;
/**
* The unique, identifying name for this task
*/
private String fetchTaskName;
/**
* The POP3 server host name for this fetch task
*/
private String popHost;
/**
* The POP3 user name for this fetch task
*/
private String popUser;
/**
* The POP3 user password for this fetch task
*/
private String popPass;
/**
* Flag to determine if you want to leave messages on server
* If so unseen messages will be marked as seen
*/
private boolean popLeaveOnServer = false;
/**
* The name of the javamail provider we want to user (pop3,imap,nntp,etc...)
*
*/
private String javaMailProviderName = pop3;
/**
* The name of the folder to fetch from the javamail provider
*
*/
private String javaMailFolderName = INBOX;
/**
* @see
org.apache.avalon.cornerstone.services.scheduler.Target#targetTriggered(String)
*/
private boolean fetching = false;
public void targetTriggered(String arg0) {
//
// if we are already fetching then just return
if (fetching) return;
fetching = true;
if (getLogger().isDebugEnabled()) {
getLogger().debug(fetchTaskName + fetcher starting fetch);
}
Store store = null;
Session session = null;
Folder folder = null;
// Get a Properties object
Properties props = System.getProperties();
// Get a Session object
session = Session.getDefaultInstance(props, null);
// session.setDebug(debug);
// Get a Store object
try {
store = session.getStore(javaMailProviderName);
// Connect
if (popHost != null || popUser != null || popPass != null)
store.connect(popHost, popUser, popPass);
else
store.connect();
// Open the Folder
folder = store.getFolder(javaMailFolderName);
if (folder == null) {
getLogger().debug(fetchTaskName + No default folder);
}
//// try to open read/write and if that fails try
New FetchMail Service added to HEAD
Guys, Thanks to Leo and Sergei, we have a new JavaMail-based FetchMail service. I have not tested this code. What I did was add it along side of FetchPOP, until we are satisfied that we can remove the FetchPOP service. Both are disabled by default. We're be wanting some additional docs for this. I'm hoping that we can get licensing permission to add JDAVMail, too. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FileObjectStore FileStreamStore
I am wondering why James has two files created -- one .FileObjectFile and one .FileStreamStore what are they for perspectively? One file from the pair has message content, the other persistent object content. See the org.apache.james.mailrepository.filepair package. James uses both internally. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
