You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2008/06/15 20:31:20 UTC
Geronimo-JAMES integration
I've been hoping for a Geronimo-JAMES integration since the start of
the Geronimo project. Two fairly recent developments in JAMES have
now made this a relatively simple task: the maven build and the
spring integration code.
- the maven build enables painless connection between the build
systems of the two projects, so changes in JAMES get picked up
immediately by the geronimo plugin under development
- the spring integration enables a non-avalon expert to construct and
start a JAMES server
After a couple days work and fixing a few problems in JAMES I now have
a geronimo james plugin that runs a james server inside geronimo.
Instructions:
1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get all
the jars needed for the build into the private stage repository
(JAMES-840). (I realize these instructions are unclear but they are
the best I have at the moment)
2. Build JAMES with maven
mvn clean install -Plocal
3. Build geronimo trunk (I haven't checked to see if sufficiently up
to date geronimo snapshots are available. We also have some private
repo issues that may make at least one local build of geronimo
necessary).
4. check out
svn co https://svn.apache.org/repos/asf/geronimo/plugins/james/trunk
5. build james plugin
mvn clean install -Pwith-assembly
6. Fire up the sample server
cd james-server/target
tar xzf james-server-1.0-SNAPSHOT-bin.tar.gz
./james-server-1.0-SNAPSHOT/bin/gsh geronimo/start-server
I've put the james config files in a geronimo-standard location of var/
james/config. I changed the ports so the server would start without
superuser permissions. So far I just know the server starts without
errors: I haven't figure out how to test if it can actually do anything.
-----------------------------------
Future directions
Even in its current state this plugin/integration is only viable if
the JAMES community
- works to resolve the issues noted in JAMES-840, 841, 842
- continues to maintain the maven build
Currently there is minimal integration between geronimo and JAMES.
One really obvious integration point would be to use geroniimo
supplied datasources. However glancing at the code there appears to
be a certain amount of fishing for configuration rather than
dependency injection. I'm wondering whether there is any interest in
moving to JPA based database access, and whether this would be
significantly harder than just changing the datasource source.
Obviously this would imply moving JAMES to java 5.
Another issue I came across is use of com.sun mail classes (I started
by trying to use the geronimo mail provider before I understood why
the stage repo wasn't working for me). Is this intentional? Are you
interested in also supporting the geronimo mail implementation?
Finally I came across some comments that DNS is needed (as you can
probably tell I know almost nothing about mail). I wondered if any
thought had been given to using apacheds in-vm for this.
thanks
david jencks
Re: Geronimo Javamail (Was: Geronimo-JAMES integration)
Posted by Rick McGuire <ri...@gmail.com>.
Stefano Bagnara wrote:
> Rick McGuire ha scritto:
>> Stefano Bagnara wrote:
>>> Rick McGuire ha scritto:
>>>> The binary can be found here:
>>>>
>>>> http://people.apache.org/~rickmcguire/javamail/
>>>
>>> ---
>>> You don't have permission to access
>>> /~rickmcguire/javamail/geronimo-javamail_1.4_mail-1.5-SNAPSHOT.jar
>>> on this server.
>>> ---
>> Ok, the permission problem should be fixed now. I also forgot that
>> you'll probably want to use the matching Geronimo activation jar as
>> well. I placed that one in the same location.
>
>
> Another NPE:
>
> java.lang.NullPointerException
> at javax.mail.internet.MimeMessage.getFlags(MimeMessage.java:1296)
> at
> org.apache.james.core.MimeMessageWrapper.<init>(MimeMessageWrapper.java:116)
>
> at
> org.apache.james.core.MimeMessageCopyOnWriteProxy.getWrappedMessageForWriting(MimeMessageCopyOnWriteProxy.java:165)
>
> at
> org.apache.james.core.MimeMessageCopyOnWriteProxy.setHeader(MimeMessageCopyOnWriteProxy.java:671)
>
> at
> org.apache.james.core.MimeMessageTest.testMessageCloningViaCoWSubjectLost(MimeMessageTest.java:398)
>
I think I spotted the cause of this. I opened a Jira for the issue at
https://issues.apache.org/jira/browse/GERONIMO-4122
Any there's an updated jar file out on my people account. You might
want to just go ahead and open new Jiras against the Geronimo mail
component when you spot new problems. Go ahead and just assign them to
me when you open them.
Rick
>
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo Javamail (Was: Geronimo-JAMES integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Rick McGuire ha scritto:
> Stefano Bagnara wrote:
>> Rick McGuire ha scritto:
>>> The binary can be found here:
>>>
>>> http://people.apache.org/~rickmcguire/javamail/
>>
>> ---
>> You don't have permission to access
>> /~rickmcguire/javamail/geronimo-javamail_1.4_mail-1.5-SNAPSHOT.jar on
>> this server.
>> ---
> Ok, the permission problem should be fixed now. I also forgot that
> you'll probably want to use the matching Geronimo activation jar as
> well. I placed that one in the same location.
Another NPE:
java.lang.NullPointerException
at javax.mail.internet.MimeMessage.getFlags(MimeMessage.java:1296)
at
org.apache.james.core.MimeMessageWrapper.<init>(MimeMessageWrapper.java:116)
at
org.apache.james.core.MimeMessageCopyOnWriteProxy.getWrappedMessageForWriting(MimeMessageCopyOnWriteProxy.java:165)
at
org.apache.james.core.MimeMessageCopyOnWriteProxy.setHeader(MimeMessageCopyOnWriteProxy.java:671)
at
org.apache.james.core.MimeMessageTest.testMessageCloningViaCoWSubjectLost(MimeMessageTest.java:398)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo Javamail (Was: Geronimo-JAMES integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Trying again to pass the antispam filter.
I and Rick had some off-list conversation about failures in our
testsuite when using geronimo javamail.
He already fixed the first NPEs I found, now I opened a few more issue
on the basic use of MimeMessage and our MimeMessageWrapper object:
GERONIMO-4127 - Problems generating a new simple/basic mail (both from
API and from InputStream)
https://issues.apache.org/jira/browse/GERONIMO-4127
GERONIMO-4129 - genorimo MimeMessage extensibility internal behaviour vs
sun implementation OOM issue.
https://issues.apache.org/jira/browse/GERONIMO-4129
GERONIMO-4128 - geronimo javamail uses Message-Id instead of Message-ID
https://issues.apache.org/jira/browse/GERONIMO-4128
I also see some infinite loops when our MimeMessageCopyOnWriteProxy try
to clone a message because of a write and it tries to clone a message
using MimeMessageWrapper and a sharedInputStream as the source of the
message, but this is not easy to isolate in a simple test.
If you want to give it a try you will need the classes from our
"core-library" module in the org.apache.james.core package and the tests
from "phoenix-deployment" module in the org.apache.james.core package.
Stefano
Rick McGuire ha scritto:
> Stefano Bagnara wrote:
>> Rick McGuire ha scritto:
>>> Stefano Bagnara wrote:
>>>> (this previously bounced as spam, I post it again with few changes,
>>>> but I'll take care to open JIRA issues in the geronimo project for
>>>> them)
>>>>
>>>> Rick McGuire ha scritto:
>>>>> Ok, the permission problem should be fixed now. I also forgot that
>>>>> you'll probably want to use the matching Geronimo activation jar as
>>>>> well. I placed that one in the same location.
>>>>
>>>> I gave it a first try, but it didn't run tests because you compiled to
>>>> java 1.5 and james is 1.4.
>>>>
>>>> I changed our JVM specification and run the tests again. Many of them
>>>> fails, just the first:
>>> Stefano, I don't think I can fix any/most of these just by
>>> eye-balling the exceptions. If you can give me a set of instructions
>>> for how to build James and run the tests with the geronimo javamail
>>> in use, I'll just start working through the problems until things run
>>> cleanly.
>>
>> Sure, sorry. The problem is I didn't have much time now, so I anyway
>> tried to give you some feedback.
>>
>> To use geronimo I had to run a search/replace in poms, to replace
>> CRLFOutputStream with commons-net ToNetASCIIOutputStream, to change
>> the package for SMTPTransport/and its implementation exceptions checks
>> (I then used m2clipse and eclipse to import it as a single project in
>> eclipse and to run unit tests).
>>
>> I think I should extract our "core" tests (mainly aimed at checking
>> our wrapper/extension of MimeMessage) and its constructors, copy,
>> writeTo methods and create a test suite to attach to JIRA for you as a
>> first step.
>>
>> I'll see what I can do as soon as I find the time :-)
>> In the mean time let me know if you do some progress before I get there!
> I believe I've fixed the Return-Path header name mismatch (and a problem
> with some other headers as well). I believe I know the problem with the
> NPEs in the InternetHeaders matchHeader() method...working on a fix to
> that one now. The big mystery one is the OOM exception in the
> MimeMessage parse() method. That one, I believe, will require hands on
> debugging.
> Rick
>
>
>>
>> Thank you!
>>
>> Stefano
>>
>>>> MimeMessageCopyOnWriteProxyTest
>>>>
>>>> - testMessageCloning1 gets an OOM:
>>>> java.lang.OutOfMemoryError: Java heap space
>>>> at java.util.Arrays.copyOf(Arrays.java:2786)
>>>> at
>>>> java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
>>>> at javax.mail.internet.MimeMessage.parse(MimeMessage.java:270)
>>>> at
>>>> org.apache.james.core.MimeMessageWrapper.parse(MimeMessageWrapper.java:479)
>>>>
>>>> at
>>>> org.apache.james.core.MimeMessageWrapper.loadMessage(MimeMessageWrapper.java:207)
>>>>
>>>> at
>>>> org.apache.james.core.MimeMessageWrapper.getSize(MimeMessageWrapper.java:294)
>>>>
>>>> at
>>>> org.apache.james.core.MimeMessageWrapper.<init>(MimeMessageWrapper.java:136)
>>>>
>>>> at
>>>> org.apache.james.core.MimeMessageCopyOnWriteProxy.getWrappedMessageForWriting(MimeMessageCopyOnWriteProxy.java:165)
>>>>
>>>> at
>>>> org.apache.james.core.MimeMessageCopyOnWriteProxy.setText(MimeMessageCopyOnWriteProxy.java:642)
>>>>
>>>> at
>>>> org.apache.james.core.MimeMessageCopyOnWriteProxyTest.testMessageCloning1(MimeMessageCopyOnWriteProxyTest.java:64)
>>>>
>>>>
>>>> - testMessageCloning2 do the same
>>>> - testMessageAvoidCloning do the same
>>>> - testMessageCloningViaCoW3 die in an infinite loop
>>>> - testMessageCloningViaCow2 do the same (infinite loop)
>>>>
>>>>
>>>> MailHeadersTest
>>>> - testHeadersOrder fails:
>>>> junit.framework.AssertionFailedError: expected:<Return-path:
>>>> <te...@test>> but was:<Return-Path: <te...@test>>
>>>> at junit.framework.Assert.fail(Assert.java:47)
>>>> at junit.framework.Assert.failNotEquals(Assert.java:282)
>>>> at junit.framework.Assert.assertEquals(Assert.java:64)
>>>> at junit.framework.Assert.assertEquals(Assert.java:71)
>>>> at
>>>> org.apache.james.core.MailHeadersTest.testHeadersOrder(MailHeadersTest.java:40)
>>>>
>>>> (the problem is "Return-path" "Return-Path"
>>>>
>>>> MimeMessageUtilTest
>>>> - testWriteMimeMessageMultipartWithMessageID fails:
>>>> java.lang.NullPointerException
>>>> at
>>>> javax.mail.internet.InternetHeaders.matchHeader(InternetHeaders.java:464)
>>>>
>>>> at
>>>> javax.mail.internet.InternetHeaders.getNonMatchingHeaders(InternetHeaders.java:504)
>>>>
>>>> at
>>>> javax.mail.internet.InternetHeaders.getNonMatchingHeaderLines(InternetHeaders.java:562)
>>>>
>>>> at
>>>> javax.mail.internet.MimeMessage.getNonMatchingHeaderLines(MimeMessage.java:1285)
>>>>
>>>> at
>>>> org.apache.james.core.MimeMessageUtil.writeHeadersTo(MimeMessageUtil.java:213)
>>>>
>>>> at
>>>> org.apache.james.core.MimeMessageUtil.writeToInternal(MimeMessageUtil.java:103)
>>>>
>>>> at
>>>> org.apache.james.core.MimeMessageUtil.writeTo(MimeMessageUtil.java:85)
>>>> at
>>>> org.apache.james.core.MimeMessageUtil.writeTo(MimeMessageUtil.java:58)
>>>> at
>>>> org.apache.james.core.MimeMessageUtilTest.testWriteMimeMessageMultipartWithMessageID(MimeMessageUtilTest.java:66)
>>>>
>>>> I see this NPE in many other tests.
>>>>
>>>> MimeMessageFromMimeMessageTest
>>>> - testSimpleMessage fails
>>>> junit.framework.ComparisonFailure: expected:<Subject: test
>>>> MIME-Version: 1.0
>>>> Content-Type: text/plain; charset=us-ascii
>>>> Content-Transfer-Encoding: 7bit
>>>> ...> but was:<...>
>>>> at junit.framework.Assert.assertEquals(Assert.java:81)
>>>> at junit.framework.Assert.assertEquals(Assert.java:87)
>>>> at
>>>> org.apache.james.core.MimeMessageTest.testSimpleMessage(MimeMessageTest.java:91)
>>>>
>>>> (we expect an header, instead we find only "<CRLF>body".
>>>>
>>>> - testMultiPartMessageChanges fails
>>>> the first assert fail because the resulting mail has no more a
>>>> multipart
>>>> content type.
>>>>
>>>> MimeMessageFromStreamTest fails almost on the same as
>>>> MimeMessageFromMimeMessageTest.
>>>>
>>>> MimeMessageWrapperTest most tests fails with the OOM I already reported
>>>> above.
>>>>
>>>>
>>>> The result of running all the org.apache.james.core.* tests is 10
>>>> failures, 24 errors, 2 infinite loops (for a total 72 tests)
>>>>
>>>> I didn't even try the 8bitmime, because there is for sure something to
>>>> fix, first ;-)
>>>>
>>>> Maybe we was "abusing" sun javamail bugs, I don't know.
>>>>
>>>> Stefano
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo Javamail (Was: Geronimo-JAMES integration)
Posted by Rick McGuire <ri...@gmail.com>.
Stefano Bagnara wrote:
> Rick McGuire ha scritto:
>> The binary can be found here:
>>
>> http://people.apache.org/~rickmcguire/javamail/
>
> ---
> You don't have permission to access
> /~rickmcguire/javamail/geronimo-javamail_1.4_mail-1.5-SNAPSHOT.jar on
> this server.
> ---
Ok, the permission problem should be fixed now. I also forgot that
you'll probably want to use the matching Geronimo activation jar as
well. I placed that one in the same location.
Rick
>
>> The source is split into two pieces, a spec component (essentially
>> the javax.mail.* classes) and the providers. Part of the providers
>> build creates a merged jar file containing both the spec and the
>> providers. The specs can be found here:
>>
>> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-javamail_1.4_spec
>>
>>
>> The providers code is in this subproject:
>>
>> https://svn.apache.org/repos/asf/geronimo/javamail/trunk/geronimo-javamail_1.4
>>
>>
>> You'll need to build specs first, then run an mvn build from the root
>> of the second tree, which will build both the providers and the uber
>> jar.
>
> Ok. For now I think I only will check it for sources :-)
>
>> One thing I've been very frustrated with in the javamail client code
>> has been the difficulty in setting up automated unit tests because of
>> the dependency on another target server. It would be really great if
>> we could get the James test suite running with the Geronimo API and
>> give it a real shakeout. One of the problems I had run into with
>> developing the different providers originally was James didn't
>> support all of the authentication mechanisms I needed to test out for
>> all of the server types. It's been a while since I looked....has
>> additional support been added?
>>
>> Rick
>
> No. There are no new smtp features since 2 years :-(
> Last time I checked our tests for this 8bitmime stuff is 1.5 years
> ago, so I don't really remember what kind of tests we have.. I'll tell
> you something more once I'll have ran the tests!
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo Javamail (Was: Geronimo-JAMES integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Rick McGuire ha scritto:
> The binary can be found here:
>
> http://people.apache.org/~rickmcguire/javamail/
---
You don't have permission to access
/~rickmcguire/javamail/geronimo-javamail_1.4_mail-1.5-SNAPSHOT.jar on
this server.
---
> The source is split into two pieces, a spec component (essentially the
> javax.mail.* classes) and the providers. Part of the providers build
> creates a merged jar file containing both the spec and the providers.
> The specs can be found here:
>
> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-javamail_1.4_spec
>
>
> The providers code is in this subproject:
>
> https://svn.apache.org/repos/asf/geronimo/javamail/trunk/geronimo-javamail_1.4
>
>
> You'll need to build specs first, then run an mvn build from the root of
> the second tree, which will build both the providers and the uber jar.
Ok. For now I think I only will check it for sources :-)
> One thing I've been very frustrated with in the javamail client code has
> been the difficulty in setting up automated unit tests because of the
> dependency on another target server. It would be really great if we
> could get the James test suite running with the Geronimo API and give it
> a real shakeout. One of the problems I had run into with developing the
> different providers originally was James didn't support all of the
> authentication mechanisms I needed to test out for all of the server
> types. It's been a while since I looked....has additional support been
> added?
>
> Rick
No. There are no new smtp features since 2 years :-(
Last time I checked our tests for this 8bitmime stuff is 1.5 years ago,
so I don't really remember what kind of tests we have.. I'll tell you
something more once I'll have ran the tests!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo Javamail (Was: Geronimo-JAMES integration)
Posted by Rick McGuire <ri...@gmail.com>.
Stefano Bagnara wrote:
> Rick McGuire ha scritto:
>> Stefano Bagnara wrote:
>>> IIRC few months ago: the issue was with the smtpclient (to deliver
>>> mail) and the "hidden" features (e.g: 8BITMIME) and specific
>>> exceptions (on delivery failure for partial deliveries). We make use
>>> of many internal things and we check for sun specific exceptions
>>> because the specification itself is thought with MUA (mail clients)
>>> in mind and not MDA (servers).
>> I believe I finally got the 8BIT MIME support figured out and
>> implemented. The Geronimo SMTPTransport implementation should
>> implement most, if not all, of Sun extension properties. I'm
>> certainly willing to consider adding any that you find missing.
>
> Hi Rick,
>
> you are *fast* :-)
It wasn't that big of a change, once I finally figured out what I was
supposed to implement. The spec source is here:
>
> can you make a build of the latest geronimo javamail implementation
> (and tell me where I can see the sources, too)? If so I can try to at
> least run our unit tests with geronimo javamail instead of sun
> javamail. We don't have many tests, but at least 8bitmite have few
> tests because until 1.4.1 the sun implementation was very buggy and we
> never enabled 8bitmime support because of failing tests.
The binary can be found here:
http://people.apache.org/~rickmcguire/javamail/
The source is split into two pieces, a spec component (essentially the
javax.mail.* classes) and the providers. Part of the providers build
creates a merged jar file containing both the spec and the providers.
The specs can be found here:
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-javamail_1.4_spec
The providers code is in this subproject:
https://svn.apache.org/repos/asf/geronimo/javamail/trunk/geronimo-javamail_1.4
You'll need to build specs first, then run an mvn build from the root of
the second tree, which will build both the providers and the uber jar.
One thing I've been very frustrated with in the javamail client code has
been the difficulty in setting up automated unit tests because of the
dependency on another target server. It would be really great if we
could get the James test suite running with the Geronimo API and give it
a real shakeout. One of the problems I had run into with developing the
different providers originally was James didn't support all of the
authentication mechanisms I needed to test out for all of the server
types. It's been a while since I looked....has additional support been
added?
Rick
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Geronimo Javamail (Was: Geronimo-JAMES integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Rick McGuire ha scritto:
> Stefano Bagnara wrote:
>> IIRC few months ago: the issue was with the smtpclient (to deliver
>> mail) and the "hidden" features (e.g: 8BITMIME) and specific
>> exceptions (on delivery failure for partial deliveries). We make use
>> of many internal things and we check for sun specific exceptions
>> because the specification itself is thought with MUA (mail clients) in
>> mind and not MDA (servers).
> I believe I finally got the 8BIT MIME support figured out and
> implemented. The Geronimo SMTPTransport implementation should implement
> most, if not all, of Sun extension properties. I'm certainly willing to
> consider adding any that you find missing.
Hi Rick,
you are *fast* :-)
can you make a build of the latest geronimo javamail implementation (and
tell me where I can see the sources, too)? If so I can try to at least
run our unit tests with geronimo javamail instead of sun javamail. We
don't have many tests, but at least 8bitmite have few tests because
until 1.4.1 the sun implementation was very buggy and we never enabled
8bitmime support because of failing tests.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Rick McGuire <ri...@gmail.com>.
Stefano Bagnara wrote:
> David Jencks ha scritto:
>> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
>>> David Jencks ha scritto:
>>>> Another issue I came across is use of com.sun mail classes (I
>>>> started by trying to use the geronimo mail provider before I
>>>> understood why the stage repo wasn't working for me). Is this
>>>> intentional? Are you interested in also supporting the geronimo
>>>> mail implementation?
>>>
>>> It is intentional. Last time I checked it geronimo mail
>>> implementation was not enough for our delivery needs. There is a lot
>>> to change and we would probably stop using javamail at all, instead
>>> of supporting geronimo implementation for the remote delivery task.
>>> This is only my opinion, of course.
>>
>> When did you look :-) ? I think its had a lot of bugs fixed and a
>> lot more stuff implemented but I haven't followed it closely.
>
> IIRC few months ago: the issue was with the smtpclient (to deliver
> mail) and the "hidden" features (e.g: 8BITMIME) and specific
> exceptions (on delivery failure for partial deliveries). We make use
> of many internal things and we check for sun specific exceptions
> because the specification itself is thought with MUA (mail clients) in
> mind and not MDA (servers).
I believe I finally got the 8BIT MIME support figured out and
implemented. The Geronimo SMTPTransport implementation should implement
most, if not all, of Sun extension properties. I'm certainly willing to
consider adding any that you find missing.
Rick
>
> We also depend on com.sun.mail.util.CRLFOutputStream but we should
> definitely replace this with some james class (maybe copied from
> geronimo?)
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Jun 21, 2008 at 3:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On 6/20/08, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Stefano Bagnara ha scritto:
>>>>
>>>> Robert Burrell Donkin ha scritto:
>>>>>
>>>>> On 6/20/08, Stefano Bagnara <ap...@bago.org> wrote:
>>>>>>
>>>>>> Robert Burrell Donkin ha scritto:
>>>>>>>
>>>>>>> On Thu, Jun 19, 2008 at 7:20 AM, Bernd Fondermann
>>>>>>> <be...@googlemail.com> wrote:
>>>>>>>>
>>>>>>>> On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class
>>>>>>>>> in
>>>>>>>>> commons-net, should we use it instead of
>>>>>>>>> com.sun.mail.util.CRLFOutputStream?
>>>>>>>>> We currently have almost 10 classes in various modules depending
>>>>>>>>> on
>>>>>>>>> CRLFOutputStream.
>>>>>>>>>
>>>>>>>>> Stefano
>>>>>>>>
>>>>>>>> Its worth giving a try.
>>>>>>>> +1
>>>>>>>
>>>>>>> hmmm...
>>>>>>>
>>>>>>> shouldn't creating this be very straightforward? what am i missing?
>>>>>>>
>>>>>>> - robert
>>>>>>
>>>>>> True. I'm not in a "coding" period and this is the kind of code I
>>>>>> should
>>>>>> not really write in days like this because my bugs x line ratio is too
>>>>>> high... I can try to give it a slot, but I warned you! ;-)
>>>>>
>>>>> Sounds good to me
>>>>
>>>> Done, please review.
>>
>> That'll have to wait till I'm back at home
>>
>>>> Maybe we should also implement the methods for buffers "filters" and not
>>>> only the byte per byte method.
>>
>> Yes
>
> I just committed a new version, with optimized code for buffer operations.
> I also improved ExtraDotOutputStream to use CRLFOutputStream as the base
> class and support buffer operations.
>
>>>> I can do this, but is there a good way to test it with specific chunk
>>>> sizes?
>>
>> (not sure if this anwsers your question or not but I'm sure you'll
>> shout if it doesn't)
>>
>> I think it's best to focus on boundary conditions (corner cases) then
>> construct integratuon tests based on bulk real life data (I like
>> sonnets by the bard from Project Gutenburg).
>
> I added a byte per byte test and a test with mixed sizes for the chunks and
> having buffers ending/starting/splitting with CR LF or CRLF to both the
> CRLFOutputStream and the improved ExtraDotOutputStream.
>
>>> I also have another doubt.
>>> Currently the CRLFOutputStream needs a checkCRLFTerminator call before
>>> closing or it will not correctly fix a sequence ending in "\r" alone.
>>>
>>> This is an issue because you have to take care of this call that is not
>>> a standard for filteroutputstreams.
>>
>> I think this should be addressed
>
> I did the change but I left the checkCRLFTerminator call in place because it
> is also used to add a final CRLF when there is no newline char at the end of
> the stream. But at least even if you don't call it the resulting stream will
> always have good CRLF.
>
>>> I could change the algorythm so to replace "\r" with "\r\n", ignore "\n"
>>> if the previous one was "\r" and replace "\n" with "\r\n" otherwise.
>>>
>>> This wouldn't need the final check method call but this would mean that
>>> we pass \r\n when we only received \r: any drawback with this?
>>
>> I think I've used this strategy in the past. Anyone else see anything
>> wrong?
>
> Implemented and committed.
looks good to me :-)
does anyone have any suggestions for improvements?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On 6/20/08, Stefano Bagnara <ap...@bago.org> wrote:
>> Stefano Bagnara ha scritto:
>>> Robert Burrell Donkin ha scritto:
>>>> On 6/20/08, Stefano Bagnara <ap...@bago.org> wrote:
>>>>> Robert Burrell Donkin ha scritto:
>>>>>> On Thu, Jun 19, 2008 at 7:20 AM, Bernd Fondermann
>>>>>> <be...@googlemail.com> wrote:
>>>>>>> On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org>
>>>>>>> wrote:
>>>>>>>> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
>>>>>>>> commons-net, should we use it instead of
>>>>>>>> com.sun.mail.util.CRLFOutputStream?
>>>>>>>> We currently have almost 10 classes in various modules depending on
>>>>>>>> CRLFOutputStream.
>>>>>>>>
>>>>>>>> Stefano
>>>>>>> Its worth giving a try.
>>>>>>> +1
>>>>>> hmmm...
>>>>>>
>>>>>> shouldn't creating this be very straightforward? what am i missing?
>>>>>>
>>>>>> - robert
>>>>> True. I'm not in a "coding" period and this is the kind of code I should
>>>>> not really write in days like this because my bugs x line ratio is too
>>>>> high... I can try to give it a slot, but I warned you! ;-)
>>>> Sounds good to me
>>> Done, please review.
>
> That'll have to wait till I'm back at home
>
>>> Maybe we should also implement the methods for buffers "filters" and not
>>> only the byte per byte method.
>
> Yes
I just committed a new version, with optimized code for buffer operations.
I also improved ExtraDotOutputStream to use CRLFOutputStream as the base
class and support buffer operations.
>>> I can do this, but is there a good way to test it with specific chunk
>>> sizes?
>
> (not sure if this anwsers your question or not but I'm sure you'll
> shout if it doesn't)
>
> I think it's best to focus on boundary conditions (corner cases) then
> construct integratuon tests based on bulk real life data (I like
> sonnets by the bard from Project Gutenburg).
I added a byte per byte test and a test with mixed sizes for the chunks
and having buffers ending/starting/splitting with CR LF or CRLF to both
the CRLFOutputStream and the improved ExtraDotOutputStream.
>> I also have another doubt.
>> Currently the CRLFOutputStream needs a checkCRLFTerminator call before
>> closing or it will not correctly fix a sequence ending in "\r" alone.
>>
>> This is an issue because you have to take care of this call that is not
>> a standard for filteroutputstreams.
> I think this should be addressed
I did the change but I left the checkCRLFTerminator call in place
because it is also used to add a final CRLF when there is no newline
char at the end of the stream. But at least even if you don't call it
the resulting stream will always have good CRLF.
>> I could change the algorythm so to replace "\r" with "\r\n", ignore "\n"
>> if the previous one was "\r" and replace "\n" with "\r\n" otherwise.
>>
>> This wouldn't need the final check method call but this would mean that
>> we pass \r\n when we only received \r: any drawback with this?
>
> I think I've used this strategy in the past. Anyone else see anything wrong?
Implemented and committed.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 6/20/08, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
>> Robert Burrell Donkin ha scritto:
>>> On 6/20/08, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>>>>> On Thu, Jun 19, 2008 at 7:20 AM, Bernd Fondermann
>>>>> <be...@googlemail.com> wrote:
>>>>>> On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org>
>>>>>> wrote:
>>>>>>> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
>>>>>>> commons-net, should we use it instead of
>>>>>>> com.sun.mail.util.CRLFOutputStream?
>>>>>>> We currently have almost 10 classes in various modules depending on
>>>>>>> CRLFOutputStream.
>>>>>>>
>>>>>>> Stefano
>>>>>> Its worth giving a try.
>>>>>> +1
>>>>> hmmm...
>>>>>
>>>>> shouldn't creating this be very straightforward? what am i missing?
>>>>>
>>>>> - robert
>>>> True. I'm not in a "coding" period and this is the kind of code I should
>>>> not really write in days like this because my bugs x line ratio is too
>>>> high... I can try to give it a slot, but I warned you! ;-)
>>>
>>> Sounds good to me
>>
>> Done, please review.
That'll have to wait till I'm back at home
>>
>> Maybe we should also implement the methods for buffers "filters" and not
>> only the byte per byte method.
Yes
>> I can do this, but is there a good way to test it with specific chunk
>> sizes?
(not sure if this anwsers your question or not but I'm sure you'll
shout if it doesn't)
I think it's best to focus on boundary conditions (corner cases) then
construct integratuon tests based on bulk real life data (I like
sonnets by the bard from Project Gutenburg).
> I also have another doubt.
> Currently the CRLFOutputStream needs a checkCRLFTerminator call before
> closing or it will not correctly fix a sequence ending in "\r" alone.
>
> This is an issue because you have to take care of this call that is not
> a standard for filteroutputstreams.
I think this should be addressed
> I could change the algorythm so to replace "\r" with "\r\n", ignore "\n"
> if the previous one was "\r" and replace "\n" with "\r\n" otherwise.
>
> This wouldn't need the final check method call but this would mean that
> we pass \r\n when we only received \r: any drawback with this?
I think I've used this strategy in the past. Anyone else see anything wrong?
Robert
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> Robert Burrell Donkin ha scritto:
>> On 6/20/08, Stefano Bagnara <ap...@bago.org> wrote:
>>> Robert Burrell Donkin ha scritto:
>>>> On Thu, Jun 19, 2008 at 7:20 AM, Bernd Fondermann
>>>> <be...@googlemail.com> wrote:
>>>>> On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org>
>>>>> wrote:
>>>>>> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
>>>>>> commons-net, should we use it instead of
>>>>>> com.sun.mail.util.CRLFOutputStream?
>>>>>> We currently have almost 10 classes in various modules depending on
>>>>>> CRLFOutputStream.
>>>>>>
>>>>>> Stefano
>>>>> Its worth giving a try.
>>>>> +1
>>>> hmmm...
>>>>
>>>> shouldn't creating this be very straightforward? what am i missing?
>>>>
>>>> - robert
>>> True. I'm not in a "coding" period and this is the kind of code I should
>>> not really write in days like this because my bugs x line ratio is too
>>> high... I can try to give it a slot, but I warned you! ;-)
>>
>> Sounds good to me
>
> Done, please review.
>
> Maybe we should also implement the methods for buffers "filters" and not
> only the byte per byte method.
>
> I can do this, but is there a good way to test it with specific chunk
> sizes?
I also have another doubt.
Currently the CRLFOutputStream needs a checkCRLFTerminator call before
closing or it will not correctly fix a sequence ending in "\r" alone.
This is an issue because you have to take care of this call that is not
a standard for filteroutputstreams.
I could change the algorythm so to replace "\r" with "\r\n", ignore "\n"
if the previous one was "\r" and replace "\n" with "\r\n" otherwise.
This wouldn't need the final check method call but this would mean that
we pass \r\n when we only received \r: any drawback with this?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On 6/20/08, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Thu, Jun 19, 2008 at 7:20 AM, Bernd Fondermann
>>> <be...@googlemail.com> wrote:
>>>> On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>>> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
>>>>> commons-net, should we use it instead of
>>>>> com.sun.mail.util.CRLFOutputStream?
>>>>> We currently have almost 10 classes in various modules depending on
>>>>> CRLFOutputStream.
>>>>>
>>>>> Stefano
>>>> Its worth giving a try.
>>>> +1
>>> hmmm...
>>>
>>> shouldn't creating this be very straightforward? what am i missing?
>>>
>>> - robert
>> True. I'm not in a "coding" period and this is the kind of code I should
>> not really write in days like this because my bugs x line ratio is too
>> high... I can try to give it a slot, but I warned you! ;-)
>
> Sounds good to me
Done, please review.
Maybe we should also implement the methods for buffers "filters" and not
only the byte per byte method.
I can do this, but is there a good way to test it with specific chunk sizes?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 6/20/08, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> On Thu, Jun 19, 2008 at 7:20 AM, Bernd Fondermann
>> <be...@googlemail.com> wrote:
>>> On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
>>>> commons-net, should we use it instead of
>>>> com.sun.mail.util.CRLFOutputStream?
>>>> We currently have almost 10 classes in various modules depending on
>>>> CRLFOutputStream.
>>>>
>>>> Stefano
>>> Its worth giving a try.
>>> +1
>>
>> hmmm...
>>
>> shouldn't creating this be very straightforward? what am i missing?
>>
>> - robert
>
> True. I'm not in a "coding" period and this is the kind of code I should
> not really write in days like this because my bugs x line ratio is too
> high... I can try to give it a slot, but I warned you! ;-)
Sounds good to me
Robert
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Thu, Jun 19, 2008 at 7:20 AM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
>>> commons-net, should we use it instead of com.sun.mail.util.CRLFOutputStream?
>>> We currently have almost 10 classes in various modules depending on
>>> CRLFOutputStream.
>>>
>>> Stefano
>> Its worth giving a try.
>> +1
>
> hmmm...
>
> shouldn't creating this be very straightforward? what am i missing?
>
> - robert
True. I'm not in a "coding" period and this is the kind of code I should
not really write in days like this because my bugs x line ratio is too
high... I can try to give it a slot, but I warned you! ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives (was: Geronimo-JAMES integration)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Jun 19, 2008 at 7:20 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>>
>>> On Mon, Jun 16, 2008 at 9:38 PM, Rick McGuire <ri...@gmail.com> wrote:
>>>>
>>>> Stefano Bagnara wrote:
>>>>>
>>>>> We also depend on com.sun.mail.util.CRLFOutputStream but we should
>>>>> definitely replace this with some james class (maybe copied from
>>>>> geronimo?)
>>>>
>>>> Not sure what this class does, so I don't know if Geronimo has a
>>>> replacement. I suspect you'd be better off implementing your own though,
>>>> just for implementation independence.
>>>
>>> if the class does what it says on the tin then JAMES already has at
>>> least one replacement
>>
>> I cannot find an OutputStream class for that in JAMES: we have
>> inputstream/reader stuff and we have imap utils to take care of this in byte
>> arrays.
>>
>> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
>> commons-net, should we use it instead of com.sun.mail.util.CRLFOutputStream?
>> We currently have almost 10 classes in various modules depending on
>> CRLFOutputStream.
>>
>> Stefano
>
> Its worth giving a try.
> +1
hmmm...
shouldn't creating this be very straightforward? what am i missing?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives
Posted by Norman Maurer <no...@apache.org>.
Am Donnerstag, den 19.06.2008, 13:38 +0200 schrieb Stefano Bagnara:
> Bernd Fondermann ha scritto:
> > On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >>> On Mon, Jun 16, 2008 at 9:38 PM, Rick McGuire <ri...@gmail.com> wrote:
> >>>> Stefano Bagnara wrote:
> >>>>> We also depend on com.sun.mail.util.CRLFOutputStream but we should
> >>>>> definitely replace this with some james class (maybe copied from
> >>>>> geronimo?)
> >>>> Not sure what this class does, so I don't know if Geronimo has a
> >>>> replacement. I suspect you'd be better off implementing your own though,
> >>>> just for implementation independence.
> >>> if the class does what it says on the tin then JAMES already has at
> >>> least one replacement
> >> I cannot find an OutputStream class for that in JAMES: we have
> >> inputstream/reader stuff and we have imap utils to take care of this in byte
> >> arrays.
> >>
> >> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
> >> commons-net, should we use it instead of com.sun.mail.util.CRLFOutputStream?
> >> We currently have almost 10 classes in various modules depending on
> >> CRLFOutputStream.
> >>
> >> Stefano
> >
> > Its worth giving a try.
> > +1
>
>
> I think the main difference is that CRLFOutputStream replace single \r
> AND \n in \r\n, while ToNetASCIIOutputStream simply replace \n with
> \r\n while it leave lonely \r as is.
>
> AFAICT this will be ok 99.9% of times with issues only when trying to
> use telnet like applications on old apple os, but it is a little less
> compliant.
>
> In order to avoid coupling to com.sun I would probably favor moving to
> ToNetASCIIOutputStream anyway. If anyone volounteer for writing a
> "complete" CRLFOutputStream this would be the best, but in the mean time...
>
> Stefano
>
+1
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Mon, Jun 16, 2008 at 9:38 PM, Rick McGuire <ri...@gmail.com> wrote:
>>>> Stefano Bagnara wrote:
>>>>> We also depend on com.sun.mail.util.CRLFOutputStream but we should
>>>>> definitely replace this with some james class (maybe copied from
>>>>> geronimo?)
>>>> Not sure what this class does, so I don't know if Geronimo has a
>>>> replacement. I suspect you'd be better off implementing your own though,
>>>> just for implementation independence.
>>> if the class does what it says on the tin then JAMES already has at
>>> least one replacement
>> I cannot find an OutputStream class for that in JAMES: we have
>> inputstream/reader stuff and we have imap utils to take care of this in byte
>> arrays.
>>
>> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
>> commons-net, should we use it instead of com.sun.mail.util.CRLFOutputStream?
>> We currently have almost 10 classes in various modules depending on
>> CRLFOutputStream.
>>
>> Stefano
>
> Its worth giving a try.
> +1
I think the main difference is that CRLFOutputStream replace single \r
AND \n in \r\n, while ToNetASCIIOutputStream simply replace \n with
\r\n while it leave lonely \r as is.
AFAICT this will be ok 99.9% of times with issues only when trying to
use telnet like applications on old apple os, but it is a little less
compliant.
In order to avoid coupling to com.sun I would probably favor moving to
ToNetASCIIOutputStream anyway. If anyone volounteer for writing a
"complete" CRLFOutputStream this would be the best, but in the mean time...
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: com.sun.mail.util.CRLFOutputStream alternatives (was: Geronimo-JAMES integration)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Jun 18, 2008 at 1:34 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Jun 16, 2008 at 9:38 PM, Rick McGuire <ri...@gmail.com> wrote:
>>>
>>> Stefano Bagnara wrote:
>>>>
>>>> We also depend on com.sun.mail.util.CRLFOutputStream but we should
>>>> definitely replace this with some james class (maybe copied from
>>>> geronimo?)
>>>
>>> Not sure what this class does, so I don't know if Geronimo has a
>>> replacement. I suspect you'd be better off implementing your own though,
>>> just for implementation independence.
>>
>> if the class does what it says on the tin then JAMES already has at
>> least one replacement
>
> I cannot find an OutputStream class for that in JAMES: we have
> inputstream/reader stuff and we have imap utils to take care of this in byte
> arrays.
>
> I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
> commons-net, should we use it instead of com.sun.mail.util.CRLFOutputStream?
> We currently have almost 10 classes in various modules depending on
> CRLFOutputStream.
>
> Stefano
Its worth giving a try.
+1
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
com.sun.mail.util.CRLFOutputStream alternatives (was: Geronimo-JAMES
integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Jun 16, 2008 at 9:38 PM, Rick McGuire <ri...@gmail.com> wrote:
>> Stefano Bagnara wrote:
>>> We also depend on com.sun.mail.util.CRLFOutputStream but we should
>>> definitely replace this with some james class (maybe copied from geronimo?)
>> Not sure what this class does, so I don't know if Geronimo has a
>> replacement. I suspect you'd be better off implementing your own though,
>> just for implementation independence.
>
> if the class does what it says on the tin then JAMES already has at
> least one replacement
I cannot find an OutputStream class for that in JAMES: we have
inputstream/reader stuff and we have imap utils to take care of this in
byte arrays.
I found the org.apache.commons.net.io.ToNetASCIIOutputStream class in
commons-net, should we use it instead of
com.sun.mail.util.CRLFOutputStream? We currently have almost 10 classes
in various modules depending on CRLFOutputStream.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jun 16, 2008 at 9:38 PM, Rick McGuire <ri...@gmail.com> wrote:
> Stefano Bagnara wrote:
>>
>> David Jencks ha scritto:
>>>
>>> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
>>>>
>>>> David Jencks ha scritto:
>>>>>
>>>>> Another issue I came across is use of com.sun mail classes (I started
>>>>> by trying to use the geronimo mail provider before I understood why the
>>>>> stage repo wasn't working for me). Is this intentional? Are you interested
>>>>> in also supporting the geronimo mail implementation?
>>>>
>>>> It is intentional. Last time I checked it geronimo mail implementation
>>>> was not enough for our delivery needs. There is a lot to change and we would
>>>> probably stop using javamail at all, instead of supporting geronimo
>>>> implementation for the remote delivery task. This is only my opinion, of
>>>> course.
>>>
>>> When did you look :-) ? I think its had a lot of bugs fixed and a lot
>>> more stuff implemented but I haven't followed it closely.
>>
>> IIRC few months ago: the issue was with the smtpclient (to deliver mail)
>> and the "hidden" features (e.g: 8BITMIME) and specific exceptions (on
>> delivery failure for partial deliveries). We make use of many internal
>> things and we check for sun specific exceptions because the specification
>> itself is thought with MUA (mail clients) in mind and not MDA (servers).
>
> We still don't have 8BITMIME support, but I don't think it would be
> difficult to add it. My biggest problem was finding some definition of what
> supporting 8BITMIME actually means. I'm still not sure what the contract
> between the client and the server is in that situation, but if somebody
> understands that enough to give me an explanation, I'll take a crack at
> adding it.
should be http://tools.ietf.org/html/rfc1652, i think. one of the SMTP
experts will probably give you more details.
(BTW it's great to see you all on list)
>> We also depend on com.sun.mail.util.CRLFOutputStream but we should
>> definitely replace this with some james class (maybe copied from geronimo?)
>
> Not sure what this class does, so I don't know if Geronimo has a
> replacement. I suspect you'd be better off implementing your own though,
> just for implementation independence.
if the class does what it says on the tin then JAMES already has at
least one replacement
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Rick McGuire <ri...@gmail.com>.
Stefano Bagnara wrote:
> David Jencks ha scritto:
>> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
>>> David Jencks ha scritto:
>>>> Another issue I came across is use of com.sun mail classes (I
>>>> started by trying to use the geronimo mail provider before I
>>>> understood why the stage repo wasn't working for me). Is this
>>>> intentional? Are you interested in also supporting the geronimo
>>>> mail implementation?
>>>
>>> It is intentional. Last time I checked it geronimo mail
>>> implementation was not enough for our delivery needs. There is a lot
>>> to change and we would probably stop using javamail at all, instead
>>> of supporting geronimo implementation for the remote delivery task.
>>> This is only my opinion, of course.
>>
>> When did you look :-) ? I think its had a lot of bugs fixed and a
>> lot more stuff implemented but I haven't followed it closely.
>
> IIRC few months ago: the issue was with the smtpclient (to deliver
> mail) and the "hidden" features (e.g: 8BITMIME) and specific
> exceptions (on delivery failure for partial deliveries). We make use
> of many internal things and we check for sun specific exceptions
> because the specification itself is thought with MUA (mail clients) in
> mind and not MDA (servers).
We still don't have 8BITMIME support, but I don't think it would be
difficult to add it. My biggest problem was finding some definition of
what supporting 8BITMIME actually means. I'm still not sure what the
contract between the client and the server is in that situation, but if
somebody understands that enough to give me an explanation, I'll take a
crack at adding it.
>
> We also depend on com.sun.mail.util.CRLFOutputStream but we should
> definitely replace this with some james class (maybe copied from
> geronimo?)
Not sure what this class does, so I don't know if Geronimo has a
replacement. I suspect you'd be better off implementing your own
though, just for implementation independence.
Rick
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Stefano Bagnara <ap...@bago.org>.
David Jencks ha scritto:
> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
>> David Jencks ha scritto:
>>> Another issue I came across is use of com.sun mail classes (I started
>>> by trying to use the geronimo mail provider before I understood why
>>> the stage repo wasn't working for me). Is this intentional? Are you
>>> interested in also supporting the geronimo mail implementation?
>>
>> It is intentional. Last time I checked it geronimo mail implementation
>> was not enough for our delivery needs. There is a lot to change and we
>> would probably stop using javamail at all, instead of supporting
>> geronimo implementation for the remote delivery task. This is only my
>> opinion, of course.
>
> When did you look :-) ? I think its had a lot of bugs fixed and a lot
> more stuff implemented but I haven't followed it closely.
IIRC few months ago: the issue was with the smtpclient (to deliver mail)
and the "hidden" features (e.g: 8BITMIME) and specific exceptions (on
delivery failure for partial deliveries). We make use of many internal
things and we check for sun specific exceptions because the
specification itself is thought with MUA (mail clients) in mind and not
MDA (servers).
We also depend on com.sun.mail.util.CRLFOutputStream but we should
definitely replace this with some james class (maybe copied from geronimo?)
Stefano
Re: Geronimo-JAMES integration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Jun 17, 2008 at 1:10 AM, David Jencks <da...@yahoo.com> wrote:
>
> On Jun 16, 2008, at 12:24 PM, Stefano Bagnara wrote:
>
>> David Jencks ha scritto:
>>>
>>> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
>>>>
>>>> David Jencks ha scritto:
>>>> At the moment the geronimo-james integration is simply a single gbean
>>>> for the whole james application: do you think it would be hard to support 1
>>>> gbean per function? JAMES is composed by api modules, library modules and
>>>> function modules. functions only depends on libraries and api, libraries
>>>> only on apis, and api have no internal dependencies.
>>>> deployments simply aggregate functions. Is it possible to create
>>>> separate GBean for functions only when functions depends on shared services
>>>> or the only solution is to publish 1 gbean for each of our services? I don't
>>>> know geronimo, but it would be a great deployment alternative if it allow us
>>>> to undeploy 1 single function (e.g: the spoolmanager), alter its
>>>> configuration and redeploy it without stopping the smtp/pop3 servers.
>>>
>>> This was the original idea I had when I first looked into this
>>> integration several years ago. However I don't think it will be practical
>>> until James adopts a more conventional IOC approach in which the components
>>> have their properties configured by the IOC container rather than through a
>>> initialize(configuration) method. I could have seriously misjudged the
>>> situation however.
>>> I have basically no idea of the internal threading structure of James.
>>> Is adding and removing components reasonably possible to do in a
>>> thread-safe way without a large synchronization overhead?
>>
>> e.g: no component depends on the spoolmanager component. so it can be
>> stopped and started as you like. The same is for servers (smtpserver,
>> pop3server, nntpserver, remotemanager) and for the fetchmail function. They
>> have dependencies on core services (e.g: the repositories) but they don't
>> depend on each other. Their interaction is mainly via the spool repository
>> or via the "James" component (implementing various core services).
>>
>> james block, smtpserver, spoolmanager receive the spoolrepository service
>> via IoC (ATM they receive the ServiceManager and they ask the spoolmanager
>> to the ServiceManager in their "service" method, but we already changed most
>> of them to be able to inject dependencies without a ServiceManager, if
>> needed).
>> the spoolrepository service is implemented by the MailStoreSpoolRepository
>> block that depends on the mailstore service. The mailstore service is
>> implemented by the AvalonMailStore component that in turn depends on the
>> cornerstone's DataSourceSelector and our FileSystem service)
>>
>> You can find the "runtime" service dependency graph in the
>> james-assembly.xml file.
>>
>> ATM you could remove only top level components or otherwise you would have
>> to remove every dependent component first.
>>
>> smtpserver, pop3server, spoolmanager, nntpserver, imapserver, fetchmail,
>> and remotemanager are top level compoenents and they are the one
>> starting/stopping threads. Synchronization happens in lower/shared
>> components/services.
>
> This sounds promising but I'd have to look much harder before saying
> anything more concrete.
>
> I did work on using a datasource from jndi rather than a directly configured
> one... I found two places with jndi configuration, the
> TorqueMailboxManagerFactory
this is due a radical overhall sometime soon
- robt
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by David Jencks <da...@yahoo.com>.
On Jun 16, 2008, at 12:24 PM, Stefano Bagnara wrote:
> David Jencks ha scritto:
>> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
>>> David Jencks ha scritto:
>>> At the moment the geronimo-james integration is simply a single
>>> gbean for the whole james application: do you think it would be
>>> hard to support 1 gbean per function? JAMES is composed by api
>>> modules, library modules and function modules. functions only
>>> depends on libraries and api, libraries only on apis, and api have
>>> no internal dependencies.
>>> deployments simply aggregate functions. Is it possible to create
>>> separate GBean for functions only when functions depends on shared
>>> services or the only solution is to publish 1 gbean for each of
>>> our services? I don't know geronimo, but it would be a great
>>> deployment alternative if it allow us to undeploy 1 single
>>> function (e.g: the spoolmanager), alter its configuration and
>>> redeploy it without stopping the smtp/pop3 servers.
>> This was the original idea I had when I first looked into this
>> integration several years ago. However I don't think it will be
>> practical until James adopts a more conventional IOC approach in
>> which the components have their properties configured by the IOC
>> container rather than through a initialize(configuration) method.
>> I could have seriously misjudged the situation however.
>> I have basically no idea of the internal threading structure of
>> James. Is adding and removing components reasonably possible to do
>> in a thread-safe way without a large synchronization overhead?
>
> e.g: no component depends on the spoolmanager component. so it can
> be stopped and started as you like. The same is for servers
> (smtpserver, pop3server, nntpserver, remotemanager) and for the
> fetchmail function. They have dependencies on core services (e.g:
> the repositories) but they don't depend on each other. Their
> interaction is mainly via the spool repository or via the "James"
> component (implementing various core services).
>
> james block, smtpserver, spoolmanager receive the spoolrepository
> service via IoC (ATM they receive the ServiceManager and they ask
> the spoolmanager to the ServiceManager in their "service" method,
> but we already changed most of them to be able to inject
> dependencies without a ServiceManager, if needed).
> the spoolrepository service is implemented by the
> MailStoreSpoolRepository block that depends on the mailstore
> service. The mailstore service is implemented by the AvalonMailStore
> component that in turn depends on the cornerstone's
> DataSourceSelector and our FileSystem service)
>
> You can find the "runtime" service dependency graph in the james-
> assembly.xml file.
>
> ATM you could remove only top level components or otherwise you
> would have to remove every dependent component first.
>
> smtpserver, pop3server, spoolmanager, nntpserver, imapserver,
> fetchmail, and remotemanager are top level compoenents and they are
> the one starting/stopping threads. Synchronization happens in lower/
> shared components/services.
This sounds promising but I'd have to look much harder before saying
anything more concrete.
I did work on using a datasource from jndi rather than a directly
configured one... I found two places with jndi configuration, the
TorqueMailboxManagerFactory and inside the <database-connections>
element. These look easy to convert. Are there other places database
connections are configured?
thanks
david jencks
>
>
> HTH,
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Norman Maurer <no...@apache.org>.
Am Sonntag, den 22.06.2008, 08:54 +0100 schrieb Robert Burrell Donkin:
> On Mon, Jun 16, 2008 at 8:24 PM, Stefano Bagnara <ap...@bago.org> wrote:
> > David Jencks ha scritto:
> >>
> >> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
> >>>
> >>> David Jencks ha scritto:
> >>> At the moment the geronimo-james integration is simply a single gbean for
> >>> the whole james application: do you think it would be hard to support 1
> >>> gbean per function? JAMES is composed by api modules, library modules and
> >>> function modules. functions only depends on libraries and api, libraries
> >>> only on apis, and api have no internal dependencies.
> >>> deployments simply aggregate functions. Is it possible to create separate
> >>> GBean for functions only when functions depends on shared services or the
> >>> only solution is to publish 1 gbean for each of our services? I don't know
> >>> geronimo, but it would be a great deployment alternative if it allow us to
> >>> undeploy 1 single function (e.g: the spoolmanager), alter its configuration
> >>> and redeploy it without stopping the smtp/pop3 servers.
> >>
> >> This was the original idea I had when I first looked into this integration
> >> several years ago. However I don't think it will be practical until James
> >> adopts a more conventional IOC approach in which the components have their
> >> properties configured by the IOC container rather than through a
> >> initialize(configuration) method. I could have seriously misjudged the
> >> situation however.
> >>
> >> I have basically no idea of the internal threading structure of James. Is
> >> adding and removing components reasonably possible to do in a thread-safe
> >> way without a large synchronization overhead?
> >
> > e.g: no component depends on the spoolmanager component. so it can be
> > stopped and started as you like. The same is for servers (smtpserver,
> > pop3server, nntpserver, remotemanager) and for the fetchmail function. They
> > have dependencies on core services (e.g: the repositories) but they don't
> > depend on each other. Their interaction is mainly via the spool repository
> > or via the "James" component (implementing various core services).
> >
> > james block, smtpserver, spoolmanager receive the spoolrepository service
> > via IoC (ATM they receive the ServiceManager and they ask the spoolmanager
> > to the ServiceManager in their "service" method, but we already changed most
> > of them to be able to inject dependencies without a ServiceManager, if
> > needed).
> > the spoolrepository service is implemented by the MailStoreSpoolRepository
> > block that depends on the mailstore service. The mailstore service is
> > implemented by the AvalonMailStore component that in turn depends on the
> > cornerstone's DataSourceSelector and our FileSystem service)
> >
> > You can find the "runtime" service dependency graph in the
> > james-assembly.xml file.
> >
> > ATM you could remove only top level components or otherwise you would have
> > to remove every dependent component first.
> >
> > smtpserver, pop3server, spoolmanager, nntpserver, imapserver, fetchmail,
> > and remotemanager are top level compoenents and they are the one
> > starting/stopping threads. Synchronization happens in lower/shared
> > components/services.
>
> JAMES is too hard to understand and that's why i think we need to pull
> out the protocols (smtp, nntp, pop3, imap) into independent,
> embeddable libraries with no coupling to avalon (or to the JAMES
> socket handling layer). i think that this would be good for the JAMES
> application server since the application server build would be
> smaller, quicker and lighter. i discovered at apachecon that there are
> quite a number of projects that are interested in mail integration
> libraries providing it came without the burden of a heavyweight
> application server.
>
> - robert
+1
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Bernd Fondermann <be...@googlemail.com>.
On Sun, Jun 22, 2008 at 9:54 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
>
> JAMES is too hard to understand and that's why i think we need to pull
> out the protocols (smtp, nntp, pop3, imap) into independent,
> embeddable libraries with no coupling to avalon (or to the JAMES
> socket handling layer). i think that this would be good for the JAMES
> application server since the application server build would be
> smaller, quicker and lighter. i discovered at apachecon that there are
> quite a number of projects that are interested in mail integration
> libraries providing it came without the burden of a heavyweight
> application server.
>
> - robert
+1, this very much reflects my own thoughts.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jun 16, 2008 at 8:24 PM, Stefano Bagnara <ap...@bago.org> wrote:
> David Jencks ha scritto:
>>
>> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
>>>
>>> David Jencks ha scritto:
>>> At the moment the geronimo-james integration is simply a single gbean for
>>> the whole james application: do you think it would be hard to support 1
>>> gbean per function? JAMES is composed by api modules, library modules and
>>> function modules. functions only depends on libraries and api, libraries
>>> only on apis, and api have no internal dependencies.
>>> deployments simply aggregate functions. Is it possible to create separate
>>> GBean for functions only when functions depends on shared services or the
>>> only solution is to publish 1 gbean for each of our services? I don't know
>>> geronimo, but it would be a great deployment alternative if it allow us to
>>> undeploy 1 single function (e.g: the spoolmanager), alter its configuration
>>> and redeploy it without stopping the smtp/pop3 servers.
>>
>> This was the original idea I had when I first looked into this integration
>> several years ago. However I don't think it will be practical until James
>> adopts a more conventional IOC approach in which the components have their
>> properties configured by the IOC container rather than through a
>> initialize(configuration) method. I could have seriously misjudged the
>> situation however.
>>
>> I have basically no idea of the internal threading structure of James. Is
>> adding and removing components reasonably possible to do in a thread-safe
>> way without a large synchronization overhead?
>
> e.g: no component depends on the spoolmanager component. so it can be
> stopped and started as you like. The same is for servers (smtpserver,
> pop3server, nntpserver, remotemanager) and for the fetchmail function. They
> have dependencies on core services (e.g: the repositories) but they don't
> depend on each other. Their interaction is mainly via the spool repository
> or via the "James" component (implementing various core services).
>
> james block, smtpserver, spoolmanager receive the spoolrepository service
> via IoC (ATM they receive the ServiceManager and they ask the spoolmanager
> to the ServiceManager in their "service" method, but we already changed most
> of them to be able to inject dependencies without a ServiceManager, if
> needed).
> the spoolrepository service is implemented by the MailStoreSpoolRepository
> block that depends on the mailstore service. The mailstore service is
> implemented by the AvalonMailStore component that in turn depends on the
> cornerstone's DataSourceSelector and our FileSystem service)
>
> You can find the "runtime" service dependency graph in the
> james-assembly.xml file.
>
> ATM you could remove only top level components or otherwise you would have
> to remove every dependent component first.
>
> smtpserver, pop3server, spoolmanager, nntpserver, imapserver, fetchmail,
> and remotemanager are top level compoenents and they are the one
> starting/stopping threads. Synchronization happens in lower/shared
> components/services.
JAMES is too hard to understand and that's why i think we need to pull
out the protocols (smtp, nntp, pop3, imap) into independent,
embeddable libraries with no coupling to avalon (or to the JAMES
socket handling layer). i think that this would be good for the JAMES
application server since the application server build would be
smaller, quicker and lighter. i discovered at apachecon that there are
quite a number of projects that are interested in mail integration
libraries providing it came without the burden of a heavyweight
application server.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Stefano Bagnara <ap...@bago.org>.
David Jencks ha scritto:
> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
>> David Jencks ha scritto:
>> At the moment the geronimo-james integration is simply a single gbean
>> for the whole james application: do you think it would be hard to
>> support 1 gbean per function? JAMES is composed by api modules,
>> library modules and function modules. functions only depends on
>> libraries and api, libraries only on apis, and api have no internal
>> dependencies.
>> deployments simply aggregate functions. Is it possible to create
>> separate GBean for functions only when functions depends on shared
>> services or the only solution is to publish 1 gbean for each of our
>> services? I don't know geronimo, but it would be a great deployment
>> alternative if it allow us to undeploy 1 single function (e.g: the
>> spoolmanager), alter its configuration and redeploy it without
>> stopping the smtp/pop3 servers.
> This was the original idea I had when I first looked into this
> integration several years ago. However I don't think it will be
> practical until James adopts a more conventional IOC approach in which
> the components have their properties configured by the IOC container
> rather than through a initialize(configuration) method. I could have
> seriously misjudged the situation however.
>
> I have basically no idea of the internal threading structure of James.
> Is adding and removing components reasonably possible to do in a
> thread-safe way without a large synchronization overhead?
e.g: no component depends on the spoolmanager component. so it can be
stopped and started as you like. The same is for servers (smtpserver,
pop3server, nntpserver, remotemanager) and for the fetchmail function.
They have dependencies on core services (e.g: the repositories) but they
don't depend on each other. Their interaction is mainly via the spool
repository or via the "James" component (implementing various core
services).
james block, smtpserver, spoolmanager receive the spoolrepository
service via IoC (ATM they receive the ServiceManager and they ask the
spoolmanager to the ServiceManager in their "service" method, but we
already changed most of them to be able to inject dependencies without a
ServiceManager, if needed).
the spoolrepository service is implemented by the
MailStoreSpoolRepository block that depends on the mailstore service.
The mailstore service is implemented by the AvalonMailStore component
that in turn depends on the cornerstone's DataSourceSelector and our
FileSystem service)
You can find the "runtime" service dependency graph in the
james-assembly.xml file.
ATM you could remove only top level components or otherwise you would
have to remove every dependent component first.
smtpserver, pop3server, spoolmanager, nntpserver, imapserver, fetchmail,
and remotemanager are top level compoenents and they are the one
starting/stopping threads. Synchronization happens in lower/shared
components/services.
HTH,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Stefano Bagnara <ap...@bago.org>.
David Jencks ha scritto:
> On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
>> David Jencks ha scritto:
>>> Another issue I came across is use of com.sun mail classes (I started
>>> by trying to use the geronimo mail provider before I understood why
>>> the stage repo wasn't working for me). Is this intentional? Are you
>>> interested in also supporting the geronimo mail implementation?
>>
>> It is intentional. Last time I checked it geronimo mail implementation
>> was not enough for our delivery needs. There is a lot to change and we
>> would probably stop using javamail at all, instead of supporting
>> geronimo implementation for the remote delivery task. This is only my
>> opinion, of course.
>
> When did you look :-) ? I think its had a lot of bugs fixed and a lot
> more stuff implemented but I haven't followed it closely.
IIRC few months ago: the issue was with the smtpclient (to deliver mail)
and the "hidden" features (e.g: 8BITMIME) and specific exceptions (on
delivery failure for partial deliveries). We make use of many internal
things and we check for sun specific exceptions because the
specification itself is thought with MUA (mail clients) in mind and not
MDA (servers).
We also depend on com.sun.mail.util.CRLFOutputStream but we should
definitely replace this with some james class (maybe copied from geronimo?)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by David Jencks <da...@yahoo.com>.
On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
> David Jencks ha scritto:
>> I've been hoping for a Geronimo-JAMES integration since the start
>> of the Geronimo project. Two fairly recent developments in JAMES
>> have now made this a relatively simple task: the maven build and
>> the spring integration code.
>> [...]
>> Instructions:
>> 1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get
>> all the jars needed for the build into the private stage repository
>> (JAMES-840). (I realize these instructions are unclear but they
>> are the best I have at the moment)
>
> I really hope we can tweak them and apply all of them. I commented
> each issue on JIRA.
>
>> 2. Build JAMES with maven
>> mvn clean install -Plocal
>
> If the maven build is not acceptable to our PMC another approach
> could be to add a maven repository install script to the ant build.
> Of course I would prefer if our PMC accept that people may prefer
> maven to build our products.
>
>> 3. Build geronimo trunk (I haven't checked to see if sufficiently
>> up to date geronimo snapshots are available. We also have some
>> private repo issues that may make at least one local build of
>> geronimo necessary).
>
> Interesting.
>
>> 4. check out
>> svn co https://svn.apache.org/repos/asf/geronimo/plugins/james/trunk
>
> I see there are 3 modules for that project:
> geronimo-james/
> james/
> james-server/
>
> can you explain (I don't know anything about "car" module type) ?
geronimo-james has the java integration code
james builds a geronimo plugin, using that code. When you build it
it's installed in your local geronimo plugin repository (i.e. the
local maven repo + listed in a geronimo metadata file). At this point
it's available to the geronimo plugin system, so you can add it to an
existing server using the admin console or command line tools. or...
james-server is a minimal server assembly that has the geroniimo
kernel, a bit of other supporting stuff, and the james plugin.
>
>
> Is there anything you think should be moved to james project instead
> of geronimo?
It would be great if the james project wanted to take over this
plugin, but I think we should make sure it works and is stable and
doesn't have too many issues with deploying on different geronimo
versions first.
>
>
>> 5. build james plugin
>> mvn clean install -Pwith-assembly
>> 6. Fire up the sample server
>> cd james-server/target
>> tar xzf james-server-1.0-SNAPSHOT-bin.tar.gz
>> ./james-server-1.0-SNAPSHOT/bin/gsh geronimo/start-server
>> I've put the james config files in a geronimo-standard location of
>> var/james/config. I changed the ports so the server would start
>> without superuser permissions. So far I just know the server
>> starts without errors: I haven't figure out how to test if it can
>> actually do anything.
>
> Cool!
> It looks like really simple!
>
>> -----------------------------------
>> Future directions
>> Even in its current state this plugin/integration is only viable if
>> the JAMES community
>> - works to resolve the issues noted in JAMES-840, 841, 842
>> - continues to maintain the maven build
>
> +1
>
>> Currently there is minimal integration between geronimo and
>> JAMES. One really obvious integration point would be to use
>> geroniimo supplied datasources. However glancing at the code there
>> appears to be a certain amount of fishing for configuration rather
>> than dependency injection. I'm wondering whether there is any
>> interest in moving to JPA based database access, and whether this
>> would be significantly harder than just changing the datasource
>> source. Obviously this would imply moving JAMES to java 5.
>
> +1
>
> Moving to java 5 IMHO is no more an issue: as soon as a feature will
> require java 5 we should simply stop declaring 1.4 compatibility: I
> don't know anyone using an 1.4 jvm at this point.
>
>> Another issue I came across is use of com.sun mail classes (I
>> started by trying to use the geronimo mail provider before I
>> understood why the stage repo wasn't working for me). Is this
>> intentional? Are you interested in also supporting the geronimo
>> mail implementation?
>
> It is intentional. Last time I checked it geronimo mail
> implementation was not enough for our delivery needs. There is a lot
> to change and we would probably stop using javamail at all, instead
> of supporting geronimo implementation for the remote delivery task.
> This is only my opinion, of course.
When did you look :-) ? I think its had a lot of bugs fixed and a lot
more stuff implemented but I haven't followed it closely.
>
>
>> Finally I came across some comments that DNS is needed (as you can
>> probably tell I know almost nothing about mail). I wondered if any
>> thought had been given to using apacheds in-vm for this.
>
> We don't need a DNS server, just DNS lookup capabilities. We don't
> use the JVM built-in DNS lookup mechanism because of issues in the
> caching and expiration support. apacheds does not provide a dns
> client library.
>
> At the moment the geronimo-james integration is simply a single
> gbean for the whole james application: do you think it would be hard
> to support 1 gbean per function? JAMES is composed by api modules,
> library modules and function modules. functions only depends on
> libraries and api, libraries only on apis, and api have no internal
> dependencies.
> deployments simply aggregate functions. Is it possible to create
> separate GBean for functions only when functions depends on shared
> services or the only solution is to publish 1 gbean for each of our
> services? I don't know geronimo, but it would be a great deployment
> alternative if it allow us to undeploy 1 single function (e.g: the
> spoolmanager), alter its configuration and redeploy it without
> stopping the smtp/pop3 servers.
This was the original idea I had when I first looked into this
integration several years ago. However I don't think it will be
practical until James adopts a more conventional IOC approach in which
the components have their properties configured by the IOC container
rather than through a initialize(configuration) method. I could have
seriously misjudged the situation however.
I have basically no idea of the internal threading structure of
James. Is adding and removing components reasonably possible to do in
a thread-safe way without a large synchronization overhead?
thanks
david jencks
>
>
> Stefano
>
Re: Geronimo-JAMES integration
Posted by David Jencks <da...@yahoo.com>.
On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
> David Jencks ha scritto:
>> I've been hoping for a Geronimo-JAMES integration since the start
>> of the Geronimo project. Two fairly recent developments in JAMES
>> have now made this a relatively simple task: the maven build and
>> the spring integration code.
>> [...]
>> Instructions:
>> 1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get
>> all the jars needed for the build into the private stage repository
>> (JAMES-840). (I realize these instructions are unclear but they
>> are the best I have at the moment)
>
> I really hope we can tweak them and apply all of them. I commented
> each issue on JIRA.
>
>> 2. Build JAMES with maven
>> mvn clean install -Plocal
>
> If the maven build is not acceptable to our PMC another approach
> could be to add a maven repository install script to the ant build.
> Of course I would prefer if our PMC accept that people may prefer
> maven to build our products.
>
>> 3. Build geronimo trunk (I haven't checked to see if sufficiently
>> up to date geronimo snapshots are available. We also have some
>> private repo issues that may make at least one local build of
>> geronimo necessary).
>
> Interesting.
>
>> 4. check out
>> svn co https://svn.apache.org/repos/asf/geronimo/plugins/james/trunk
>
> I see there are 3 modules for that project:
> geronimo-james/
> james/
> james-server/
>
> can you explain (I don't know anything about "car" module type) ?
geronimo-james has the java integration code
james builds a geronimo plugin, using that code. When you build it
it's installed in your local geronimo plugin repository (i.e. the
local maven repo + listed in a geronimo metadata file). At this point
it's available to the geronimo plugin system, so you can add it to an
existing server using the admin console or command line tools. or...
james-server is a minimal server assembly that has the geroniimo
kernel, a bit of other supporting stuff, and the james plugin.
>
>
> Is there anything you think should be moved to james project instead
> of geronimo?
It would be great if the james project wanted to take over this
plugin, but I think we should make sure it works and is stable and
doesn't have too many issues with deploying on different geronimo
versions first.
>
>
>> 5. build james plugin
>> mvn clean install -Pwith-assembly
>> 6. Fire up the sample server
>> cd james-server/target
>> tar xzf james-server-1.0-SNAPSHOT-bin.tar.gz
>> ./james-server-1.0-SNAPSHOT/bin/gsh geronimo/start-server
>> I've put the james config files in a geronimo-standard location of
>> var/james/config. I changed the ports so the server would start
>> without superuser permissions. So far I just know the server
>> starts without errors: I haven't figure out how to test if it can
>> actually do anything.
>
> Cool!
> It looks like really simple!
>
>> -----------------------------------
>> Future directions
>> Even in its current state this plugin/integration is only viable if
>> the JAMES community
>> - works to resolve the issues noted in JAMES-840, 841, 842
>> - continues to maintain the maven build
>
> +1
>
>> Currently there is minimal integration between geronimo and
>> JAMES. One really obvious integration point would be to use
>> geroniimo supplied datasources. However glancing at the code there
>> appears to be a certain amount of fishing for configuration rather
>> than dependency injection. I'm wondering whether there is any
>> interest in moving to JPA based database access, and whether this
>> would be significantly harder than just changing the datasource
>> source. Obviously this would imply moving JAMES to java 5.
>
> +1
>
> Moving to java 5 IMHO is no more an issue: as soon as a feature will
> require java 5 we should simply stop declaring 1.4 compatibility: I
> don't know anyone using an 1.4 jvm at this point.
>
>> Another issue I came across is use of com.sun mail classes (I
>> started by trying to use the geronimo mail provider before I
>> understood why the stage repo wasn't working for me). Is this
>> intentional? Are you interested in also supporting the geronimo
>> mail implementation?
>
> It is intentional. Last time I checked it geronimo mail
> implementation was not enough for our delivery needs. There is a lot
> to change and we would probably stop using javamail at all, instead
> of supporting geronimo implementation for the remote delivery task.
> This is only my opinion, of course.
When did you look :-) ? I think its had a lot of bugs fixed and a lot
more stuff implemented but I haven't followed it closely.
>
>
>> Finally I came across some comments that DNS is needed (as you can
>> probably tell I know almost nothing about mail). I wondered if any
>> thought had been given to using apacheds in-vm for this.
>
> We don't need a DNS server, just DNS lookup capabilities. We don't
> use the JVM built-in DNS lookup mechanism because of issues in the
> caching and expiration support. apacheds does not provide a dns
> client library.
>
> At the moment the geronimo-james integration is simply a single
> gbean for the whole james application: do you think it would be hard
> to support 1 gbean per function? JAMES is composed by api modules,
> library modules and function modules. functions only depends on
> libraries and api, libraries only on apis, and api have no internal
> dependencies.
> deployments simply aggregate functions. Is it possible to create
> separate GBean for functions only when functions depends on shared
> services or the only solution is to publish 1 gbean for each of our
> services? I don't know geronimo, but it would be a great deployment
> alternative if it allow us to undeploy 1 single function (e.g: the
> spoolmanager), alter its configuration and redeploy it without
> stopping the smtp/pop3 servers.
This was the original idea I had when I first looked into this
integration several years ago. However I don't think it will be
practical until James adopts a more conventional IOC approach in which
the components have their properties configured by the IOC container
rather than through a initialize(configuration) method. I could have
seriously misjudged the situation however.
I have basically no idea of the internal threading structure of
James. Is adding and removing components reasonably possible to do in
a thread-safe way without a large synchronization overhead?
thanks
david jencks
>
>
> Stefano
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Rick McGuire <ri...@gmail.com>.
Stefano Bagnara wrote:
> David Jencks ha scritto:
>> I've been hoping for a Geronimo-JAMES integration since the start of
>> the Geronimo project. Two fairly recent developments in JAMES have
>> now made this a relatively simple task: the maven build and the
>> spring integration code.
>> [...]
>> Instructions:
>>
>> 1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get all
>> the jars needed for the build into the private stage repository
>> (JAMES-840). (I realize these instructions are unclear but they are
>> the best I have at the moment)
>
> I really hope we can tweak them and apply all of them. I commented
> each issue on JIRA.
>
>> 2. Build JAMES with maven
>> mvn clean install -Plocal
>
> If the maven build is not acceptable to our PMC another approach could
> be to add a maven repository install script to the ant build.
> Of course I would prefer if our PMC accept that people may prefer
> maven to build our products.
>
>> 3. Build geronimo trunk (I haven't checked to see if sufficiently up
>> to date geronimo snapshots are available. We also have some private
>> repo issues that may make at least one local build of geronimo
>> necessary).
>
> Interesting.
>
>> 4. check out
>> svn co https://svn.apache.org/repos/asf/geronimo/plugins/james/trunk
>
> I see there are 3 modules for that project:
> geronimo-james/
> james/
> james-server/
>
> can you explain (I don't know anything about "car" module type) ?
>
> Is there anything you think should be moved to james project instead
> of geronimo?
>
>> 5. build james plugin
>> mvn clean install -Pwith-assembly
>>
>> 6. Fire up the sample server
>> cd james-server/target
>> tar xzf james-server-1.0-SNAPSHOT-bin.tar.gz
>> ./james-server-1.0-SNAPSHOT/bin/gsh geronimo/start-server
>>
>> I've put the james config files in a geronimo-standard location of
>> var/james/config. I changed the ports so the server would start
>> without superuser permissions. So far I just know the server starts
>> without errors: I haven't figure out how to test if it can actually
>> do anything.
>
> Cool!
> It looks like really simple!
>
>> -----------------------------------
>>
>> Future directions
>>
>> Even in its current state this plugin/integration is only viable if
>> the JAMES community
>> - works to resolve the issues noted in JAMES-840, 841, 842
>> - continues to maintain the maven build
>
> +1
>
>> Currently there is minimal integration between geronimo and JAMES.
>> One really obvious integration point would be to use geroniimo
>> supplied datasources. However glancing at the code there appears to
>> be a certain amount of fishing for configuration rather than
>> dependency injection. I'm wondering whether there is any interest in
>> moving to JPA based database access, and whether this would be
>> significantly harder than just changing the datasource source.
>> Obviously this would imply moving JAMES to java 5.
>
> +1
>
> Moving to java 5 IMHO is no more an issue: as soon as a feature will
> require java 5 we should simply stop declaring 1.4 compatibility: I
> don't know anyone using an 1.4 jvm at this point.
>
>> Another issue I came across is use of com.sun mail classes (I started
>> by trying to use the geronimo mail provider before I understood why
>> the stage repo wasn't working for me). Is this intentional? Are you
>> interested in also supporting the geronimo mail implementation?
>
> It is intentional. Last time I checked it geronimo mail implementation
> was not enough for our delivery needs. There is a lot to change and we
> would probably stop using javamail at all, instead of supporting
> geronimo implementation for the remote delivery task. This is only my
> opinion, of course.
When was the last time you checked? The Geronimo javamail
implementation has underdone quite a bit of upgrade over the last couple
of years. We now have support for POP3, IMAP, NNTP (Store and
Transport). We also take requests, if there are particular features
missing. It's difficult for us to add those when we don't even know
people think there's something missing.
Rick
>
>> Finally I came across some comments that DNS is needed (as you can
>> probably tell I know almost nothing about mail). I wondered if any
>> thought had been given to using apacheds in-vm for this.
>
> We don't need a DNS server, just DNS lookup capabilities. We don't use
> the JVM built-in DNS lookup mechanism because of issues in the caching
> and expiration support. apacheds does not provide a dns client library.
>
> At the moment the geronimo-james integration is simply a single gbean
> for the whole james application: do you think it would be hard to
> support 1 gbean per function? JAMES is composed by api modules,
> library modules and function modules. functions only depends on
> libraries and api, libraries only on apis, and api have no internal
> dependencies.
> deployments simply aggregate functions. Is it possible to create
> separate GBean for functions only when functions depends on shared
> services or the only solution is to publish 1 gbean for each of our
> services? I don't know geronimo, but it would be a great deployment
> alternative if it allow us to undeploy 1 single function (e.g: the
> spoolmanager), alter its configuration and redeploy it without
> stopping the smtp/pop3 servers.
>
> Stefano
>
>
Re: Geronimo-JAMES integration
Posted by Stefano Bagnara <ap...@bago.org>.
David Jencks ha scritto:
> I've been hoping for a Geronimo-JAMES integration since the start of the
> Geronimo project. Two fairly recent developments in JAMES have now made
> this a relatively simple task: the maven build and the spring
> integration code.
> [...]
> Instructions:
>
> 1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get all
> the jars needed for the build into the private stage repository
> (JAMES-840). (I realize these instructions are unclear but they are the
> best I have at the moment)
I really hope we can tweak them and apply all of them. I commented each
issue on JIRA.
> 2. Build JAMES with maven
> mvn clean install -Plocal
If the maven build is not acceptable to our PMC another approach could
be to add a maven repository install script to the ant build.
Of course I would prefer if our PMC accept that people may prefer maven
to build our products.
> 3. Build geronimo trunk (I haven't checked to see if sufficiently up to
> date geronimo snapshots are available. We also have some private repo
> issues that may make at least one local build of geronimo necessary).
Interesting.
> 4. check out
> svn co https://svn.apache.org/repos/asf/geronimo/plugins/james/trunk
I see there are 3 modules for that project:
geronimo-james/
james/
james-server/
can you explain (I don't know anything about "car" module type) ?
Is there anything you think should be moved to james project instead of
geronimo?
> 5. build james plugin
> mvn clean install -Pwith-assembly
>
> 6. Fire up the sample server
> cd james-server/target
> tar xzf james-server-1.0-SNAPSHOT-bin.tar.gz
> ./james-server-1.0-SNAPSHOT/bin/gsh geronimo/start-server
>
> I've put the james config files in a geronimo-standard location of
> var/james/config. I changed the ports so the server would start without
> superuser permissions. So far I just know the server starts without
> errors: I haven't figure out how to test if it can actually do anything.
Cool!
It looks like really simple!
> -----------------------------------
>
> Future directions
>
> Even in its current state this plugin/integration is only viable if the
> JAMES community
> - works to resolve the issues noted in JAMES-840, 841, 842
> - continues to maintain the maven build
+1
> Currently there is minimal integration between geronimo and JAMES. One
> really obvious integration point would be to use geroniimo supplied
> datasources. However glancing at the code there appears to be a certain
> amount of fishing for configuration rather than dependency injection.
> I'm wondering whether there is any interest in moving to JPA based
> database access, and whether this would be significantly harder than
> just changing the datasource source. Obviously this would imply moving
> JAMES to java 5.
+1
Moving to java 5 IMHO is no more an issue: as soon as a feature will
require java 5 we should simply stop declaring 1.4 compatibility: I
don't know anyone using an 1.4 jvm at this point.
> Another issue I came across is use of com.sun mail classes (I started by
> trying to use the geronimo mail provider before I understood why the
> stage repo wasn't working for me). Is this intentional? Are you
> interested in also supporting the geronimo mail implementation?
It is intentional. Last time I checked it geronimo mail implementation
was not enough for our delivery needs. There is a lot to change and we
would probably stop using javamail at all, instead of supporting
geronimo implementation for the remote delivery task. This is only my
opinion, of course.
> Finally I came across some comments that DNS is needed (as you can
> probably tell I know almost nothing about mail). I wondered if any
> thought had been given to using apacheds in-vm for this.
We don't need a DNS server, just DNS lookup capabilities. We don't use
the JVM built-in DNS lookup mechanism because of issues in the caching
and expiration support. apacheds does not provide a dns client library.
At the moment the geronimo-james integration is simply a single gbean
for the whole james application: do you think it would be hard to
support 1 gbean per function? JAMES is composed by api modules, library
modules and function modules. functions only depends on libraries and
api, libraries only on apis, and api have no internal dependencies.
deployments simply aggregate functions. Is it possible to create
separate GBean for functions only when functions depends on shared
services or the only solution is to publish 1 gbean for each of our
services? I don't know geronimo, but it would be a great deployment
alternative if it allow us to undeploy 1 single function (e.g: the
spoolmanager), alter its configuration and redeploy it without stopping
the smtp/pop3 servers.
Stefano
Re: Geronimo-JAMES integration
Posted by Stefano Bagnara <ap...@bago.org>.
David Jencks ha scritto:
> I've been hoping for a Geronimo-JAMES integration since the start of the
> Geronimo project. Two fairly recent developments in JAMES have now made
> this a relatively simple task: the maven build and the spring
> integration code.
> [...]
> Instructions:
>
> 1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get all
> the jars needed for the build into the private stage repository
> (JAMES-840). (I realize these instructions are unclear but they are the
> best I have at the moment)
I really hope we can tweak them and apply all of them. I commented each
issue on JIRA.
> 2. Build JAMES with maven
> mvn clean install -Plocal
If the maven build is not acceptable to our PMC another approach could
be to add a maven repository install script to the ant build.
Of course I would prefer if our PMC accept that people may prefer maven
to build our products.
> 3. Build geronimo trunk (I haven't checked to see if sufficiently up to
> date geronimo snapshots are available. We also have some private repo
> issues that may make at least one local build of geronimo necessary).
Interesting.
> 4. check out
> svn co https://svn.apache.org/repos/asf/geronimo/plugins/james/trunk
I see there are 3 modules for that project:
geronimo-james/
james/
james-server/
can you explain (I don't know anything about "car" module type) ?
Is there anything you think should be moved to james project instead of
geronimo?
> 5. build james plugin
> mvn clean install -Pwith-assembly
>
> 6. Fire up the sample server
> cd james-server/target
> tar xzf james-server-1.0-SNAPSHOT-bin.tar.gz
> ./james-server-1.0-SNAPSHOT/bin/gsh geronimo/start-server
>
> I've put the james config files in a geronimo-standard location of
> var/james/config. I changed the ports so the server would start without
> superuser permissions. So far I just know the server starts without
> errors: I haven't figure out how to test if it can actually do anything.
Cool!
It looks like really simple!
> -----------------------------------
>
> Future directions
>
> Even in its current state this plugin/integration is only viable if the
> JAMES community
> - works to resolve the issues noted in JAMES-840, 841, 842
> - continues to maintain the maven build
+1
> Currently there is minimal integration between geronimo and JAMES. One
> really obvious integration point would be to use geroniimo supplied
> datasources. However glancing at the code there appears to be a certain
> amount of fishing for configuration rather than dependency injection.
> I'm wondering whether there is any interest in moving to JPA based
> database access, and whether this would be significantly harder than
> just changing the datasource source. Obviously this would imply moving
> JAMES to java 5.
+1
Moving to java 5 IMHO is no more an issue: as soon as a feature will
require java 5 we should simply stop declaring 1.4 compatibility: I
don't know anyone using an 1.4 jvm at this point.
> Another issue I came across is use of com.sun mail classes (I started by
> trying to use the geronimo mail provider before I understood why the
> stage repo wasn't working for me). Is this intentional? Are you
> interested in also supporting the geronimo mail implementation?
It is intentional. Last time I checked it geronimo mail implementation
was not enough for our delivery needs. There is a lot to change and we
would probably stop using javamail at all, instead of supporting
geronimo implementation for the remote delivery task. This is only my
opinion, of course.
> Finally I came across some comments that DNS is needed (as you can
> probably tell I know almost nothing about mail). I wondered if any
> thought had been given to using apacheds in-vm for this.
We don't need a DNS server, just DNS lookup capabilities. We don't use
the JVM built-in DNS lookup mechanism because of issues in the caching
and expiration support. apacheds does not provide a dns client library.
At the moment the geronimo-james integration is simply a single gbean
for the whole james application: do you think it would be hard to
support 1 gbean per function? JAMES is composed by api modules, library
modules and function modules. functions only depends on libraries and
api, libraries only on apis, and api have no internal dependencies.
deployments simply aggregate functions. Is it possible to create
separate GBean for functions only when functions depends on shared
services or the only solution is to publish 1 gbean for each of our
services? I don't know geronimo, but it would be a great deployment
alternative if it allow us to undeploy 1 single function (e.g: the
spoolmanager), alter its configuration and redeploy it without stopping
the smtp/pop3 servers.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Bernd Fondermann <bf...@brainlounge.de>.
David Jencks wrote:
> I've been hoping for a Geronimo-JAMES integration since the start of the
> Geronimo project. Two fairly recent developments in JAMES have now made
> this a relatively simple task: the maven build and the spring
> integration code.
Me too. :-)
It was one of the major motivations for starting the JAMES Spring
Deployment.
> - the maven build enables painless connection between the build systems
> of the two projects, so changes in JAMES get picked up immediately by
> the geronimo plugin under development
> - the spring integration enables a non-avalon expert to construct and
> start a JAMES server
>
> After a couple days work and fixing a few problems in JAMES I now have a
> geronimo james plugin that runs a james server inside geronimo.
:-)))
Thanks, Mr Jencks!! (Sorry for stealing the obvious pun from your sig.)
That's great news!!
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Stefano Bagnara wrote:
> Robert Burrell Donkin ha scritto:
>> On Mon, Jun 16, 2008 at 1:22 AM, Noel J. Bergman <no...@devtech.com>
>> wrote:
>>>> rewriting the JAMES spool using JMS would be good
>>> Why?
>>
>> specifically: restarting my JAMES instance every couple of days has
>> started to irritate
>
> Do you think that the current spoolrepository implementation has
> something to do with your restarts?
> I'm not aware of issues in this and I don't restart my james since the
> last reboot almost 3 months ago.
>
>> generally: we've talked before and the whole design around that area
>> of the system could be so much better
>>
>> technology: actually support for any distributable messaging solution
>> but i can see no reason not to use a standard
>
> I agree.
>
> FYI I had an interesting discussion with James Strachan few weeks ago,
> here:
> http://markmail.org/message/mp2pafe77efwczbb
>
> Stefano
Great thread, thanks for sharing!
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fetchmail issues? (Was: Geronimo-JAMES integration)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jun 16, 2008 at 9:19 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Jun 16, 2008 at 8:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> i'm pretty sure that it fetchmail is the direct cause but i believe
>>>> that it's indirectly related to the spool design. do you run
>>>> fetchmail?
>>>
>>> I run fetchmail with few (<10) remote pop3 mailboxes and a limited number
>>> of
>>> messages (<1000/day).
>>
>> about the same as me :-/
>
> I don't understand how fetchmail and the spool can cooperate in an OOM:
> FetchMail send messages to the "spool" via the MailServer service, the same
> way the SMTPServer does, so it should not make any difference in this
> "spool" aspect.
the only thing that i can think of is that FetchMail uses vanilla
JavaMail whereas AIUI SMTP uses that tricky streaming stuff
the spool API insists on javamail. i would prefer the spool to offer a
bio or nio interface
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fetchmail issues? (Was: Geronimo-JAMES integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Jun 16, 2008 at 8:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> i'm pretty sure that it fetchmail is the direct cause but i believe
>>> that it's indirectly related to the spool design. do you run
>>> fetchmail?
>> I run fetchmail with few (<10) remote pop3 mailboxes and a limited number of
>> messages (<1000/day).
>
> about the same as me :-/
I don't understand how fetchmail and the spool can cooperate in an OOM:
FetchMail send messages to the "spool" via the MailServer service, the
same way the SMTPServer does, so it should not make any difference in
this "spool" aspect.
>> Is it a deadlock issue, an OOM issue or what else?
>
> OOM
>
> i should probably profile
you should :-)
at least an -XX:+HeapDumpOnOutOfMemoryError or jinfo -flag
+HeapDumpOnOutOfMemoryError <pid> !
>> I made a refactoring for fetchmail almost 2 years ago. It is attached to a
>> JIRA issue because it started a flame [...]
>
> i was planning a complete rewrite: i would prefer to use a direct POP3
> client plus messaging
This would be a better option, for sure!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fetchmail issues? (Was: Geronimo-JAMES integration)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jun 16, 2008 at 8:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Jun 16, 2008 at 1:01 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> On Mon, Jun 16, 2008 at 1:22 AM, Noel J. Bergman <no...@devtech.com>
>>>> wrote:
>>>>>>
>>>>>> rewriting the JAMES spool using JMS would be good
>>>>>
>>>>> Why?
>>>>
>>>> specifically: restarting my JAMES instance every couple of days has
>>>> started to irritate
>>>
>>> Do you think that the current spoolrepository implementation has
>>> something
>>> to do with your restarts?
>>> I'm not aware of issues in this and I don't restart my james since the
>>> last
>>> reboot almost 3 months ago.
>>
>> i'm pretty sure that it fetchmail is the direct cause but i believe
>> that it's indirectly related to the spool design. do you run
>> fetchmail?
>
> I run fetchmail with few (<10) remote pop3 mailboxes and a limited number of
> messages (<1000/day).
about the same as me :-/
> Is it a deadlock issue, an OOM issue or what else?
OOM
i should probably profile
> I made a refactoring for fetchmail almost 2 years ago. It is attached to a
> JIRA issue because it started a flame:
> https://issues.apache.org/jira/browse/JAMES-509
>
> I don't remember much of that changes but I remember that I also removed the
> StoreProcessor/FolderProcessor/MessageProcessor granular creation by
> refactoring them to top level reentrant objects that take things to process
> as arguments to their "process" method. This could have an impact with
> memory.
>
> If you want to give it a try I could update it to current trunk and put it
> in a fetchmail2-function module, but it is untested code, so I'll do my part
> only if you have interest in trying it. (you can also enjoy the complaints
> here: http://markmail.org/message/sd4zyzt7sbdkm6qz)
i was planning a complete rewrite: i would prefer to use a direct POP3
client plus messaging
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Fetchmail issues? (Was: Geronimo-JAMES integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Jun 16, 2008 at 1:01 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Mon, Jun 16, 2008 at 1:22 AM, Noel J. Bergman <no...@devtech.com> wrote:
>>>>> rewriting the JAMES spool using JMS would be good
>>>> Why?
>>> specifically: restarting my JAMES instance every couple of days has
>>> started to irritate
>> Do you think that the current spoolrepository implementation has something
>> to do with your restarts?
>> I'm not aware of issues in this and I don't restart my james since the last
>> reboot almost 3 months ago.
>
> i'm pretty sure that it fetchmail is the direct cause but i believe
> that it's indirectly related to the spool design. do you run
> fetchmail?
I run fetchmail with few (<10) remote pop3 mailboxes and a limited
number of messages (<1000/day).
Is it a deadlock issue, an OOM issue or what else?
I made a refactoring for fetchmail almost 2 years ago. It is attached to
a JIRA issue because it started a flame:
https://issues.apache.org/jira/browse/JAMES-509
I don't remember much of that changes but I remember that I also removed
the StoreProcessor/FolderProcessor/MessageProcessor granular creation by
refactoring them to top level reentrant objects that take things to
process as arguments to their "process" method. This could have an
impact with memory.
If you want to give it a try I could update it to current trunk and put
it in a fetchmail2-function module, but it is untested code, so I'll
do my part only if you have interest in trying it. (you can also enjoy
the complaints here: http://markmail.org/message/sd4zyzt7sbdkm6qz)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MOM and spooling (Was: Geronimo-JAMES integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Fri, Jun 27, 2008 at 9:19 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Jun 24, 2008 at 7:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
> <snip>
>
>>>> Sometimes my JAMES deal with around a million email in a day and I had to
>>>> "hack" some JAMES code to avoid writing to disk/jdbc on each status
>>>> change
>>>> (custom processorClass for the spoolmanager).
>>>>
>>>> A performance oriented approach would be to directly use the KAHA engine
>>>> [1] (or maybe the AMQ Message Stores [2]) o to write stuff only for
>>>> reliability but keep using memory operations unless the queue grow too
>>>> much,
>>>> but I think this should be kept in our mind when we'll refactor the
>>>> repository APIs (let's not close this door when we change the api)
>>> should be easy enough if we go down the MOM route: messaging intefaces
>>> tend to be concise which allows multiple implementations
>> Issues:
>> It would be cool to be able to declare some processing to be done before
>> finally declaring the mail as accepted. Specification say we should reply as
>> fast as possible after the DATA ending "CRLF.CRLF" to avoid duplicate sent,
>> but I think many times 0.1 seconds are enough to run some processing and
>> "fast fail" instead of spooling.
>> It would be even better to say: start the spooling process, track the status
>> for 0.1 seconds and then replies to the DATA.
>
> IMHO the simple spool-accept-fail paradigm needs to be re-considered.
> MOM would allow more flexible and finely grained processing.
>
> a lot of processing could be done using only the information in the
> headers. once the headers have been received then processing could
> start whilst the rest of the message is being read.
++++1 but this will require mailet api changes (or it will not use
mailet api).
We had a long thread about this issue, the "fast fail apis" and how they
related to the mailet api. Unfortunately there was no clear direction/ideas.
>> I say this because I think that we need message tracking during the spool in
>> order to support delivery status notification at the container level. JAMES
>> currently support a limited part of DSNs (bounces) at the mailet level but
>> this is not enough (IMHO).
>>
>> The container should be made aware of messages being delivered, messages
>> being expanded, delayed, failed, aliased in order to provide better tracking
>> (both for DSN and logging purposes).
>>
>> They're 3 years I think to this from time to time, but I never found a
>> satisfying solution, yet.
>
> there are some basic verbs associated with mail processing. some of
> these i think would be more better represented by queues. for example,
> remote delivery or local delivery could be managed by queues rather
> than mailets directly. i think that this approach should allow high
> level tracking without sacrificing the flexibility that mailets bring.
Remote delivery is already managed by a queue.
RemoteDelivery service method is very similar to the "ToRepository"
mailet. In the mean time the RemoteDelivery instantiate the processing
threads to process its own spoolrepository (queue).
In my custom build the RemoteDelivery is simply a ToRepository and I
moved the outgoing processing logic to its own avalon component
(https://issues.apache.org/jira/browse/JAMES-520).
My RemoteDeliveryService is an extension of the SpoolManager supporting
retry/delay logic.
Last time I proposed something similar there was no consensus on this
approach.
>>>> It would be cool if a standard SMTP=>MultipleMailets=>RemoteDelivery
>>>> processing could be done with a single write to disk when the mail is
>>>> accepted and no other read/write (unless memory/queues are full).
>>> unless you're willing to risk losing messages, i don't see how this
>>> can be done. it should be possible to just write twice: once when the
>>> message arrives and once when processing is done.
>> "done marks" could be applied in batches when the traffic is really high.
>> But maybe this is premature optimization.
>
> yes
;-)
>> If we can get it writing twice it would be already a big improvement.
>
> i think two writes would a realistic goal to target
+1
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MOM and spooling (Was: Geronimo-JAMES integration)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jun 27, 2008 at 9:19 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Tue, Jun 24, 2008 at 7:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
>>> Sometimes my JAMES deal with around a million email in a day and I had to
>>> "hack" some JAMES code to avoid writing to disk/jdbc on each status
>>> change
>>> (custom processorClass for the spoolmanager).
>>>
>>> A performance oriented approach would be to directly use the KAHA engine
>>> [1] (or maybe the AMQ Message Stores [2]) o to write stuff only for
>>> reliability but keep using memory operations unless the queue grow too
>>> much,
>>> but I think this should be kept in our mind when we'll refactor the
>>> repository APIs (let's not close this door when we change the api)
>>
>> should be easy enough if we go down the MOM route: messaging intefaces
>> tend to be concise which allows multiple implementations
>
> Issues:
> It would be cool to be able to declare some processing to be done before
> finally declaring the mail as accepted. Specification say we should reply as
> fast as possible after the DATA ending "CRLF.CRLF" to avoid duplicate sent,
> but I think many times 0.1 seconds are enough to run some processing and
> "fast fail" instead of spooling.
> It would be even better to say: start the spooling process, track the status
> for 0.1 seconds and then replies to the DATA.
IMHO the simple spool-accept-fail paradigm needs to be re-considered.
MOM would allow more flexible and finely grained processing.
a lot of processing could be done using only the information in the
headers. once the headers have been received then processing could
start whilst the rest of the message is being read.
> I say this because I think that we need message tracking during the spool in
> order to support delivery status notification at the container level. JAMES
> currently support a limited part of DSNs (bounces) at the mailet level but
> this is not enough (IMHO).
>
> The container should be made aware of messages being delivered, messages
> being expanded, delayed, failed, aliased in order to provide better tracking
> (both for DSN and logging purposes).
>
> They're 3 years I think to this from time to time, but I never found a
> satisfying solution, yet.
there are some basic verbs associated with mail processing. some of
these i think would be more better represented by queues. for example,
remote delivery or local delivery could be managed by queues rather
than mailets directly. i think that this approach should allow high
level tracking without sacrificing the flexibility that mailets bring.
>>> It would be cool if a standard SMTP=>MultipleMailets=>RemoteDelivery
>>> processing could be done with a single write to disk when the mail is
>>> accepted and no other read/write (unless memory/queues are full).
>>
>> unless you're willing to risk losing messages, i don't see how this
>> can be done. it should be possible to just write twice: once when the
>> message arrives and once when processing is done.
>
> "done marks" could be applied in batches when the traffic is really high.
> But maybe this is premature optimization.
yes
> If we can get it writing twice it would be already a big improvement.
i think two writes would a realistic goal to target
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MOM and spooling (Was: Geronimo-JAMES integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Tue, Jun 24, 2008 at 7:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> About my concern it still applies also to the scenario where only the
>> "Envelope" (to be defined) is written on every queue change, but this cannot
>> be avoided with the suggested approach unless we switch to non-persistent
>> queues.
>
> i think a mixture of persistent and non-persistent would probably work best.
>
> but there should be no need to hardwire which queues are persistent:
> the configuration should build this at run time
I agree.
>> Sometimes my JAMES deal with around a million email in a day and I had to
>> "hack" some JAMES code to avoid writing to disk/jdbc on each status change
>> (custom processorClass for the spoolmanager).
>>
>> A performance oriented approach would be to directly use the KAHA engine
>> [1] (or maybe the AMQ Message Stores [2]) o to write stuff only for
>> reliability but keep using memory operations unless the queue grow too much,
>> but I think this should be kept in our mind when we'll refactor the
>> repository APIs (let's not close this door when we change the api)
>
> should be easy enough if we go down the MOM route: messaging intefaces
> tend to be concise which allows multiple implementations
Issues:
It would be cool to be able to declare some processing to be done before
finally declaring the mail as accepted. Specification say we should
reply as fast as possible after the DATA ending "CRLF.CRLF" to avoid
duplicate sent, but I think many times 0.1 seconds are enough to run
some processing and "fast fail" instead of spooling.
It would be even better to say: start the spooling process, track the
status for 0.1 seconds and then replies to the DATA.
I say this because I think that we need message tracking during the
spool in order to support delivery status notification at the container
level. JAMES currently support a limited part of DSNs (bounces) at the
mailet level but this is not enough (IMHO).
The container should be made aware of messages being delivered, messages
being expanded, delayed, failed, aliased in order to provide better
tracking (both for DSN and logging purposes).
They're 3 years I think to this from time to time, but I never found a
satisfying solution, yet.
>> It would be cool if a standard SMTP=>MultipleMailets=>RemoteDelivery
>> processing could be done with a single write to disk when the mail is
>> accepted and no other read/write (unless memory/queues are full).
>
> unless you're willing to risk losing messages, i don't see how this
> can be done. it should be possible to just write twice: once when the
> message arrives and once when processing is done.
"done marks" could be applied in batches when the traffic is really
high. But maybe this is premature optimization.
If we can get it writing twice it would be already a big improvement.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: MOM and spooling (Was: Geronimo-JAMES integration)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Jun 24, 2008 at 7:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Jun 16, 2008 at 8:37 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> On Mon, Jun 16, 2008 at 1:01 PM, Stefano Bagnara <ap...@bago.org>
>>>> wrote:
>>>>>
>>>>> Robert Burrell Donkin ha scritto:
>>>>>>
>>>>>> generally: we've talked before and the whole design around that area
>>>>>> of the system could be so much better
>>>>>>
>>>>>> technology: actually support for any distributable messaging solution
>>>>>> but i can see no reason not to use a standard
>>>>>
>>>>> I agree.
>>>>>
>>>>> FYI I had an interesting discussion with James Strachan few weeks ago,
>>>>> here:
>>>>> http://markmail.org/message/mp2pafe77efwczbb
>>>>
>>>> it's always interesting talking to james :-)
>>>>
>>>> he's definitely thinking in the same directions as me
>>>>
>>>> - robert
>>>
>>> I had no time yet to check CAMEL, and there are few issues we already
>>> found
>>> discussing the JMS solution (no way to avoid writing the full message
>>> over
>>> and over again when moving from one queue to another is my main concern),
>>> but I bookmarked the thread and camel for my next "meditation" weekend
>>> (unfortunately not so frequent lately).
>>
>> MOM works surprisingly well provided that the message sizes are small.
>> IMHO JAMES should not be attempting to load large bodies into memory.
>> instead, a limited buffer should be used initially: big enough to hold
>> the headers (and small messages). once this is filled, the message
>> should be streamed directly to storage. the message would contain the
>> headers plus a reference URL for the body.
>
> About my concern it still applies also to the scenario where only the
> "Envelope" (to be defined) is written on every queue change, but this cannot
> be avoided with the suggested approach unless we switch to non-persistent
> queues.
i think a mixture of persistent and non-persistent would probably work best.
but there should be no need to hardwire which queues are persistent:
the configuration should build this at run time
> Sometimes my JAMES deal with around a million email in a day and I had to
> "hack" some JAMES code to avoid writing to disk/jdbc on each status change
> (custom processorClass for the spoolmanager).
>
> A performance oriented approach would be to directly use the KAHA engine
> [1] (or maybe the AMQ Message Stores [2]) o to write stuff only for
> reliability but keep using memory operations unless the queue grow too much,
> but I think this should be kept in our mind when we'll refactor the
> repository APIs (let's not close this door when we change the api)
should be easy enough if we go down the MOM route: messaging intefaces
tend to be concise which allows multiple implementations
> It would be cool if a standard SMTP=>MultipleMailets=>RemoteDelivery
> processing could be done with a single write to disk when the mail is
> accepted and no other read/write (unless memory/queues are full).
unless you're willing to risk losing messages, i don't see how this
can be done. it should be possible to just write twice: once when the
message arrives and once when processing is done.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
MOM and spooling (Was: Geronimo-JAMES integration)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Jun 16, 2008 at 8:37 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Mon, Jun 16, 2008 at 1:01 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>>>>> generally: we've talked before and the whole design around that area
>>>>> of the system could be so much better
>>>>>
>>>>> technology: actually support for any distributable messaging solution
>>>>> but i can see no reason not to use a standard
>>>> I agree.
>>>>
>>>> FYI I had an interesting discussion with James Strachan few weeks ago,
>>>> here:
>>>> http://markmail.org/message/mp2pafe77efwczbb
>>> it's always interesting talking to james :-)
>>>
>>> he's definitely thinking in the same directions as me
>>>
>>> - robert
>> I had no time yet to check CAMEL, and there are few issues we already found
>> discussing the JMS solution (no way to avoid writing the full message over
>> and over again when moving from one queue to another is my main concern),
>> but I bookmarked the thread and camel for my next "meditation" weekend
>> (unfortunately not so frequent lately).
>
> MOM works surprisingly well provided that the message sizes are small.
> IMHO JAMES should not be attempting to load large bodies into memory.
> instead, a limited buffer should be used initially: big enough to hold
> the headers (and small messages). once this is filled, the message
> should be streamed directly to storage. the message would contain the
> headers plus a reference URL for the body.
About my concern it still applies also to the scenario where only the
"Envelope" (to be defined) is written on every queue change, but this
cannot be avoided with the suggested approach unless we switch to
non-persistent queues.
Sometimes my JAMES deal with around a million email in a day and I had
to "hack" some JAMES code to avoid writing to disk/jdbc on each status
change (custom processorClass for the spoolmanager).
A performance oriented approach would be to directly use the KAHA engine
[1] (or maybe the AMQ Message Stores [2]) o to write stuff only for
reliability but keep using memory operations unless the queue grow too
much, but I think this should be kept in our mind when we'll refactor
the repository APIs (let's not close this door when we change the api)
It would be cool if a standard SMTP=>MultipleMailets=>RemoteDelivery
processing could be done with a single write to disk when the mail is
accepted and no other read/write (unless memory/queues are full).
Stefano
[1] http://activemq.apache.org/kaha-persistence.html
[2] http://activemq.apache.org/amq-message-store.html
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jun 16, 2008 at 8:37 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Jun 16, 2008 at 1:01 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> generally: we've talked before and the whole design around that area
>>>> of the system could be so much better
>>>>
>>>> technology: actually support for any distributable messaging solution
>>>> but i can see no reason not to use a standard
>>>
>>> I agree.
>>>
>>> FYI I had an interesting discussion with James Strachan few weeks ago,
>>> here:
>>> http://markmail.org/message/mp2pafe77efwczbb
>>
>> it's always interesting talking to james :-)
>>
>> he's definitely thinking in the same directions as me
>>
>> - robert
>
> I had no time yet to check CAMEL, and there are few issues we already found
> discussing the JMS solution (no way to avoid writing the full message over
> and over again when moving from one queue to another is my main concern),
> but I bookmarked the thread and camel for my next "meditation" weekend
> (unfortunately not so frequent lately).
MOM works surprisingly well provided that the message sizes are small.
IMHO JAMES should not be attempting to load large bodies into memory.
instead, a limited buffer should be used initially: big enough to hold
the headers (and small messages). once this is filled, the message
should be streamed directly to storage. the message would contain the
headers plus a reference URL for the body.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Jun 16, 2008 at 1:01 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> generally: we've talked before and the whole design around that area
>>> of the system could be so much better
>>>
>>> technology: actually support for any distributable messaging solution
>>> but i can see no reason not to use a standard
>> I agree.
>>
>> FYI I had an interesting discussion with James Strachan few weeks ago, here:
>> http://markmail.org/message/mp2pafe77efwczbb
>
> it's always interesting talking to james :-)
>
> he's definitely thinking in the same directions as me
>
> - robert
I had no time yet to check CAMEL, and there are few issues we already
found discussing the JMS solution (no way to avoid writing the full
message over and over again when moving from one queue to another is my
main concern), but I bookmarked the thread and camel for my next
"meditation" weekend (unfortunately not so frequent lately).
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jun 16, 2008 at 1:01 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Jun 16, 2008 at 1:22 AM, Noel J. Bergman <no...@devtech.com> wrote:
>>>>
>>>> rewriting the JAMES spool using JMS would be good
>>>
>>> Why?
>>
>> specifically: restarting my JAMES instance every couple of days has
>> started to irritate
>
> Do you think that the current spoolrepository implementation has something
> to do with your restarts?
> I'm not aware of issues in this and I don't restart my james since the last
> reboot almost 3 months ago.
i'm pretty sure that it fetchmail is the direct cause but i believe
that it's indirectly related to the spool design. do you run
fetchmail?
>> generally: we've talked before and the whole design around that area
>> of the system could be so much better
>>
>> technology: actually support for any distributable messaging solution
>> but i can see no reason not to use a standard
>
> I agree.
>
> FYI I had an interesting discussion with James Strachan few weeks ago, here:
> http://markmail.org/message/mp2pafe77efwczbb
it's always interesting talking to james :-)
he's definitely thinking in the same directions as me
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Jun 16, 2008 at 1:22 AM, Noel J. Bergman <no...@devtech.com> wrote:
>>> rewriting the JAMES spool using JMS would be good
>> Why?
>
> specifically: restarting my JAMES instance every couple of days has
> started to irritate
Do you think that the current spoolrepository implementation has
something to do with your restarts?
I'm not aware of issues in this and I don't restart my james since the
last reboot almost 3 months ago.
> generally: we've talked before and the whole design around that area
> of the system could be so much better
>
> technology: actually support for any distributable messaging solution
> but i can see no reason not to use a standard
I agree.
FYI I had an interesting discussion with James Strachan few weeks ago, here:
http://markmail.org/message/mp2pafe77efwczbb
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Jun 16, 2008 at 1:22 AM, Noel J. Bergman <no...@devtech.com> wrote:
>> rewriting the JAMES spool using JMS would be good
>
> Why?
specifically: restarting my JAMES instance every couple of days has
started to irritate
generally: we've talked before and the whole design around that area
of the system could be so much better
technology: actually support for any distributable messaging solution
but i can see no reason not to use a standard
> You do realize that rewriting the spool for JMS actually means introducing a
> spool broker service, right?
i think so but please elaborate
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Geronimo-JAMES integration
Posted by "Noel J. Bergman" <no...@devtech.com>.
> rewriting the JAMES spool using JMS would be good
Why?
You do realize that rewriting the spool for JMS actually means introducing a
spool broker service, right?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Jun 15, 2008 at 9:37 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> David Jencks wrote:
<snip>
>> -----------------------------------
>>
>> Future directions
>>
>> Currently there is minimal integration between geronimo and JAMES. One
>> really obvious integration point would be to use geroniimo supplied
>> datasources.
>
> There is experimental code for JMS integration. Maybe worth taking a look
> at.
rewriting the JAMES spool using JMS would be good
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Bernd Fondermann <bf...@brainlounge.de>.
David Jencks wrote:
> I've put the james config files in a geronimo-standard location of
> var/james/config. I changed the ports so the server would start without
> superuser permissions. So far I just know the server starts without
> errors: I haven't figure out how to test if it can actually do anything.
You can use telnet at the SMTP port for this.
After the server greets you, type this (out of my head):
HELO localhost
MAIL FROM:<se...@localhost>
RCPT TO:<re...@localhost>
DATA
This is a test message body
You end your message with a
<CRLF>.<CRLF>
sequence.
> -----------------------------------
>
> Future directions
>
> Currently there is minimal integration between geronimo and JAMES. One
> really obvious integration point would be to use geroniimo supplied
> datasources.
There is experimental code for JMS integration. Maybe worth taking a
look at.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Jun 15, 2008 at 7:31 PM, David Jencks <da...@yahoo.com> wrote:
> I've been hoping for a Geronimo-JAMES integration since the start of the
> Geronimo project.
cool
i have as well but not quite that long ;-)
> Two fairly recent developments in JAMES have now made
> this a relatively simple task: the maven build and the spring integration
> code.
>
> - the maven build enables painless connection between the build systems of
> the two projects, so changes in JAMES get picked up immediately by the
> geronimo plugin under development
> - the spring integration enables a non-avalon expert to construct and start
> a JAMES server
bernd deserves kudos for this
> After a couple days work and fixing a few problems in JAMES I now have a
> geronimo james plugin that runs a james server inside geronimo.
>
> Instructions:
>
> 1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get all the
> jars needed for the build into the private stage repository (JAMES-840). (I
> realize these instructions are unclear but they are the best I have at the
> moment)
>
> 2. Build JAMES with maven
> mvn clean install -Plocal
>
> 3. Build geronimo trunk (I haven't checked to see if sufficiently up to date
> geronimo snapshots are available. We also have some private repo issues
> that may make at least one local build of geronimo necessary).
>
> 4. check out
> svn co https://svn.apache.org/repos/asf/geronimo/plugins/james/trunk
>
> 5. build james plugin
> mvn clean install -Pwith-assembly
>
> 6. Fire up the sample server
> cd james-server/target
> tar xzf james-server-1.0-SNAPSHOT-bin.tar.gz
> ./james-server-1.0-SNAPSHOT/bin/gsh geronimo/start-server
>
> I've put the james config files in a geronimo-standard location of
> var/james/config. I changed the ports so the server would start without
> superuser permissions. So far I just know the server starts without errors:
> I haven't figure out how to test if it can actually do anything.
send it some mail :-)
> -----------------------------------
>
> Future directions
>
> Even in its current state this plugin/integration is only viable if the
> JAMES community
> - works to resolve the issues noted in JAMES-840, 841, 842
> - continues to maintain the maven build
i hope we can do that
fancy moving the code here in the long run?
> Currently there is minimal integration between geronimo and JAMES. One
> really obvious integration point would be to use geroniimo supplied
> datasources. However glancing at the code there appears to be a certain
> amount of fishing for configuration rather than dependency injection.
JAMES is mostly IoC but the injection is hard to understand and inconsistent
(one of my motivations for trying to split JAMES into reusable
components is to address this)
> I'm wondering whether there is any interest in moving to JPA based database
> access, and whether this would be significantly harder than just changing
> the datasource source. Obviously this would imply moving JAMES to java 5.
(i was planning to add JPA-based data access for IMAP once i get round
to sorting out the data access layer)
not necessarily: adding new JPA based database acccess is very doable.
a new java 5 module for JPA would be fine.
IMHO it would clean and clearer to implement this as a separate
component dependent only on the API (but would need some changes)
> Another issue I came across is use of com.sun mail classes (I started by
> trying to use the geronimo mail provider before I understood why the stage
> repo wasn't working for me). Is this intentional?
consequential
> Are you interested in also supporting the geronimo mail implementation?
i would prefer to use geronimo (i find the sun implementation slow and
buggy but then again, i'm not a javamail fan) but others prefer sun
> Finally I came across some comments that DNS is needed (as you can probably
> tell I know almost nothing about mail).
depends on the protocol. AIUI SMTP requires correct that DNS is set up
appropriate for the machine.
> I wondered if any thought had been
> given to using apacheds in-vm for this.
(hopefully one of the SMTP experts will jump in an answer this)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Stefano Bagnara <ap...@bago.org>.
David Jencks ha scritto:
>
> On Jun 29, 2008, at 11:39 AM, Stefano Bagnara wrote:
>
>> David Jencks ha scritto:
>>> I've been hoping for a Geronimo-JAMES integration since the start of
>>> the Geronimo project. Two fairly recent developments in JAMES have
>>> now made this a relatively simple task: the maven build and the
>>> spring integration code.
>>> - the maven build enables painless connection between the build
>>> systems of the two projects, so changes in JAMES get picked up
>>> immediately by the geronimo plugin under development
>>> - the spring integration enables a non-avalon expert to construct and
>>> start a JAMES server
>>> After a couple days work and fixing a few problems in JAMES I now
>>> have a geronimo james plugin that runs a james server inside geronimo.
>>> Instructions:
>>> 1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get all
>>> the jars needed for the build into the private stage repository
>>> (JAMES-840). (I realize these instructions are unclear but they are
>>> the best I have at the moment)
>>
>> Hi David, I think I applied the 3 issues above.
>> Can you please check everything is working in geronimo?
>
> I like the idea of using ResourceLoader but I don't think the current
> implementation works properly. I believe
> AvalonConfigurationFileProvider is assigned the AvalolApplicationContext
> as it's ResourceLoader and never gets to use the JamesResourceLoader. I
> implemented one solution that works for me in geronimo and attached a
> patch to JAMES-842 (with some more discusssion). I think it's possible
> that making AvalonConfigurationFileProvider NOT implement
> ResourceLoaderAware and explicitly configuring it's ResourceLoader
> reference might also work and be more flexible, but I haven't tried it
> in geronimo yet. Let me know if you prefer this approach.
>
> thanks
> david jencks
Hi David,
at a first glance I would prefer the second solution because it does not
tie the "generic" avalon-spring bridge to james logics (filesystembridge
/ resource urls conventions), but I don't have the knowledge to
understand the potential issues of having ResourceLoaderAware components
receiving a different ResourceLoader...
I will review the 2 patches as soon as you upload JAMES-842-2.patch
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by David Jencks <da...@yahoo.com>.
On Jun 29, 2008, at 11:39 AM, Stefano Bagnara wrote:
> David Jencks ha scritto:
>> I've been hoping for a Geronimo-JAMES integration since the start
>> of the Geronimo project. Two fairly recent developments in JAMES
>> have now made this a relatively simple task: the maven build and
>> the spring integration code.
>> - the maven build enables painless connection between the build
>> systems of the two projects, so changes in JAMES get picked up
>> immediately by the geronimo plugin under development
>> - the spring integration enables a non-avalon expert to construct
>> and start a JAMES server
>> After a couple days work and fixing a few problems in JAMES I now
>> have a geronimo james plugin that runs a james server inside
>> geronimo.
>> Instructions:
>> 1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get
>> all the jars needed for the build into the private stage repository
>> (JAMES-840). (I realize these instructions are unclear but they
>> are the best I have at the moment)
>
> Hi David, I think I applied the 3 issues above.
> Can you please check everything is working in geronimo?
I like the idea of using ResourceLoader but I don't think the current
implementation works properly. I believe
AvalonConfigurationFileProvider is assigned the
AvalolApplicationContext as it's ResourceLoader and never gets to use
the JamesResourceLoader. I implemented one solution that works for me
in geronimo and attached a patch to JAMES-842 (with some more
discusssion). I think it's possible that making
AvalonConfigurationFileProvider NOT implement ResourceLoaderAware and
explicitly configuring it's ResourceLoader reference might also work
and be more flexible, but I haven't tried it in geronimo yet. Let me
know if you prefer this approach.
thanks
david jencks
>
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Geronimo-JAMES integration
Posted by Stefano Bagnara <ap...@bago.org>.
David Jencks ha scritto:
> I've been hoping for a Geronimo-JAMES integration since the start of the
> Geronimo project. Two fairly recent developments in JAMES have now made
> this a relatively simple task: the maven build and the spring
> integration code.
>
> - the maven build enables painless connection between the build systems
> of the two projects, so changes in JAMES get picked up immediately by
> the geronimo plugin under development
> - the spring integration enables a non-avalon expert to construct and
> start a JAMES server
>
> After a couple days work and fixing a few problems in JAMES I now have a
> geronimo james plugin that runs a james server inside geronimo.
>
> Instructions:
>
> 1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get all
> the jars needed for the build into the private stage repository
> (JAMES-840). (I realize these instructions are unclear but they are the
> best I have at the moment)
Hi David, I think I applied the 3 issues above.
Can you please check everything is working in geronimo?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org