> Well OK, I may have tried to bite off more than I can chew > here....
+1 it would certainly seem so ;-) > 1. First let me report what I think may be an installation > problem with the release candidate of James and will be interested in > hearing feedback on this as well. I have a bunch of mailets and > jar files to support them and I stashed these in my James/lib > directory. But I had a heck of a time trying to figure out why > James was crashing after I ported all my config.xml code over! I > finally was able to track the problem down to what is apparently > a misconfiguration ??? of the places where some of the needed jar > files were being placed. I found them in > James/work/James-1038102691318/SAR-INF/lib and when I copied all > these jar files over to > the James/lib directory it made James a lot happier and it now > "appears" to be coming up OK. First of all I'm not being an appologist for avalon-phoenix here, and I'll admit straight away that this is a woefully inadequate situation as it stands, but we have good reason for not going at this problem like a bull at a gate; It is a new "feature" of Phoenix (the runtime environment we use, from jakarta-avalon), and one we will be addressing in the next cycle. Phoenix expects its applications to package all the required jars in the .sar file, from where they are unpacked at run-time. This leads to a problem for mailet deployment, you have to add your mailet jars to the .sar file. Putting them in the /lib directory means that you also have to move a ton of other stuff, or the classloader delegation fails to find dependancies of classes found in /lib which (the dependancies) are in /SAR-INF/lib Moving everything (or enough) into /lib breaks down the classloader seperation of Phoenix. I'll accept that most James users are highly unlikely to be running more than one Phoenix app in their James phoenix instance, but the theory at least is sound, and if we approach a modular deployment system for mailet apps we will want to enforce strict classloader separation. The solution is for the James spoolmanager to have its own classloader which will look in a third location for mailet application jars, Peter Donald has added a potential solution to this to Phoenix, but its still alpha, and not suitable for this (upcoming) release. One of the tabled actions for the next release is to sort out the library locations, My own view is that there will be three locations, much like tomcat, server/lib for James internals, common/lib for libraries which can safely be shared between mailets, and used by James, and mailets/lib which will contain your mailet jars. In the fullness of time I hope we can create a simple deployment system for mailet applications, which would include configuration snippets as well as all resources, in a way very analogous to that by which Tomcat deploys servlet applications. > > This was a tough problem to track down as the stack walkbacks one > gets are very misleading. SO I might suggest that before you > release the next version of James this configuration ought to be > cleaned up, or at least well documented! (and IMHO that is a > horrible name for a directory that James is placing these jar > file in!!! I refer to James-1038102691318.) ;-) Cold comfort I'm sure, but its not meant to be seen by the human eye. > 2. Even though James is appearing to come up OK now, it is still > not functioning OK. I tried to telnet to port 4555 and the telnet > session hangs and eventually times out without succeeding. When I > bring up a mail client to try and receive mail, I get a popup > dialog asking me to enter my user id and password. I am using > SMTP authorization, but it is not accepting the user id or password > even though I know them to be correct. Telneting to the POP3 port > on 110, or the SMTP port on 25 also fails to make a connection. Of > note, I do use MySQL for a database for James, and I think it is > working OK... I am able to connect to it from across my LAN using > dbVisualizer and it responds as expected. Am I facing some > Win2000 issues here that I don't understand? Any help would be much > appreciated, and I will continue to poke around at it... Ok, my initial suggestion is that you abandon your custom mailets and try to run James "out-of-the-box" If that fails, let us know what happened. Next copy the diff between your desired config and the /SAR-INF/configuration.xml, note that there are important differences in a number of the elements. Ones you would be unlikely to need to alter. Then try again, No joy? get in touch.. Now try adding your mailet jars to james.sar and run james again, *then* try configuring james to actually use your mailets. And if you still dont win.. get in touch. > 3. One last item of note... I noticed that when I close James > down (BTW much much cleaner now!) I am getting a stack walkback in the > phoenix.log file which I include below.... Another phoenix issue, on win2k phoenix can't delete the working directory it created, it tries again at startup, for some reason the NT filesystem believes that there is a lock held, and it isn't released until Phoenix has stopped, by which time it is (naturally) too late. I'm sensitive to the fact that these comments don't really address the issue you have, but hope that you will now at least understand our reluctance to move too fast on this. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
