> We're already close. The linkages between SMTP, NNTP, POP3,
> IMAP and the pipeline are all through the spooler or the
> repositories. I've been toying with the idea of a
> distributed spooler for most of the year. The problem is
> that we have to synchronize access to items (only one
>
Noel J. Bergman wrote:
Nitpick: JMS is a J2EE technology, not an EJB technology. I have no
experience using JMS, but it seems overkill for many purposes. I've always
had a fondness for the COS Event Service, myself.
Umm, blush - me too!
Stephen.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED
Noel:
I'm cc'ing Avalon dev. Perhaps we can try to get some assistance
on this - after all, the upside is certainly interesting.
Stephen.
Noel J. Bergman wrote:
Stephen McConnell wrote:
Noel J. Bergman wrote:
But something I'm still not clear on. Under a unit test
the BSF mailet wo
Stephen McConnell wrote:
> Noel J. Bergman wrote:
>>>But something I'm still not clear on. Under a unit test
>>>the BSF mailet would be declared under the James
>>>configuration.
>>I was just using those matchers as examples. For testing, I think you
want
>>to have similar code available within
> we might consider adopt a technology which would allow us
> to distribute James in the same manner as EJB's deployed
> in different containers connecting to each other using
> JNDI and RMI.
We're already close. The linkages between SMTP, NNTP, POP3, IMAP and the
pipeline are all through the spo
Danny Angus wrote:
Danny contributed the Mailet API changes. Stephen did the Avalon changes.
Other than that, I think I committed most of the changes to MAIN. And I
kept them in since until sometime this summer, IIRC. I don't know of any
features present in MAIN that are not in v2.
I f
Serge,
>Since EJB is a rather "loaded?" term, could you give specifics on what
>migrating to EJB means?
Simply meant that we might consider adopt a technology which would allow us
to distribute James in the same manner as EJB's deployed in different
containers connecting to each other using J
Danny Angus wrote:
In fact the more I look at this the more tempted I am to suggest we go one
step further and implement all of our services as EJB's (or explore what
avenues Avalon provides for distributing our services) as this would give
admins the choice of installing James as a single local ap
>Danny contributed the Mailet API changes. Stephen did the Avalon changes.
>Other than that, I think I committed most of the changes to MAIN. And I
>kept them in since until sometime this summer, IIRC. I don't know of any
>features present in MAIN that are not in v2.
I feel that it's imp
__
>> So to just get to a merged 3.0 release, we could do the following
>Are you proposing that what is currently v2.2.0 test builds be released as
>v3?
Seems to me we should merge what we want going forwards from the HEAD into
the tip of the 2 branch and swap the HEAD an
>>Further changes are minimal as far as I can recall, but I'm happy to be
>>corrected.
>All of the migration from ComponentManager to ServiceManager,
>ComponentException to ServiceException, Composable to Servicable,
>removal of Component - and some tweaking
>related to datasources (as oppo
Noel J. Bergman wrote:
But something I'm still not clear on. Under a unit test
the BSF mailet would be declared under the James
configuration.
I was just using those matchers as examples. For testing, I think you want
to have similar code available within Merlin, itself, able to access
wha
> But something I'm still not clear on. Under a unit test
> the BSF mailet would be declared under the James
> configuration.
I was just using those matchers as examples. For testing, I think you want
to have similar code available within Merlin, itself, able to access
whatever needs testing. Ba
Noel J. Bergman wrote:
Can you fill me in on BSF?
I'm not Steve, but ...
http://jakarta.apache.org/bsf/
Also:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=9147
That has a BSF matcher and a BSF mailet written by Steve. We want to get
them into v3.
Thanks - penny has dropped
Noel J. Bergman wrote:
Excalibur IO is depricated in favour of Commons IO. However, the
cornerstone-store package used a number of IO utilities not available
within the commons-io package
So we need commons-io,
No - you don't need commons-io (I just mentioned that Excalibur IO
was depric
Noel J. Bergman wrote:
2. Do an api/impl split (which will make me happy)
Where do you see that we don't?
[warning - I'm probably rambling]
I'm talking about a physical split that would result in the following
artifacts:
* james-server-api-VERSION.jar
* james-server-impl-VERSION.jar
*
> Can you fill me in on BSF?
I'm not Steve, but ...
http://jakarta.apache.org/bsf/
Also:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
.org&msgNo=9147
That has a BSF matcher and a BSF mailet written by Steve. We want to get
them into v3.
In terms of what I'm proposing, think of Phoen
> Excalibur IO is depricated in favour of Commons IO. However, the
> cornerstone-store package used a number of IO utilities not available
> within the commons-io package
So we need commons-io, plus the additional set of classes necessary to
support Cornerstone Store, and you've moved the latter
> 2. Do an api/impl split (which will make me happy)
Where do you see that we don't? I'm not saying that there aren't such
cases, but I'm curious as to what you see as concerns.
> 3. Use the AbstractMerlinTestCase to deploy james in a container with
>services accessible to your unit test - y
Noel J. Bergman wrote:
As for formal testing, we still don't have much. Bench and live testing,
basically. For example, when I get home, I'll test Soren's patch by setting
up a schedule, and sending mail to a dead gateway. I don't know what Avalon
has done in terms of facilitating component t
>>> So to just get to a merged 3.0 release, we could do the following
>> Are you proposing that what is currently v2.2.0 test builds be
>> released as v3?
> Err, no... I mean merge from a codebase perspective, not overwrite.
> Feature-wise, I don't believe there is much in 3.0 that isn't in 2.2.
I
Serge Knystautas wrote:
I think that will be messy since there has been so much changes on
each, but I don't have a better suggestion. grunt grunt grunt.
This really could expose our Archiles heel though, which is a lack of
adequate testing to make sure the merged version works well. Have w
Noel J. Bergman wrote:
So to just get to a merged 3.0 release, we could do the following
Are you proposing that what is currently v2.2.0 test builds be released as
v3?
Err, no... I mean merge from a codebase perspective, not overwrite.
Feature-wise, I don't believe there is much in 3.0 that isn't
Noel J. Bergman wrote:
Everything from Avalon on which James is dependent has gone though an
official release.
Your list (Freudian slip? :-)) is missing Phoenix, although I believe that
there is a release later than we are using.
Woops!
Honestly - it just didn't occur to me.
Possibly Freudi
> So to just get to a merged 3.0 release, we could do the following
Are you proposing that what is currently v2.2.0 test builds be released as
v3?
> 1. Move to latest release packages from Avalon.
I think that we already have them in the MAIN branch. If not, we should.
Steve is running James wi
> Everything from Avalon on which James is dependent has gone though an
> official release.
Your list (Freudian slip? :-)) is missing Phoenix, although I believe that
there is a release later than we are using.
I assume that all of the new ones are currently in our MAIN branch?
> James is curren
Danny Angus wrote:
2. Discuss and resolve the mailet API changes.
I propose we abandon many of the changes made to the HEAD, and adopt only
those changes made to the branch as well.
The repository access and database access is likely to be superceded by
JNDI.
I propose that we keep whatever
2. Discuss and resolve the mailet API changes.
I propose we abandon many of the changes made to the HEAD, and adopt only
those changes made to the branch as well.
The repository access and database access is likely to be superceded by
JNDI.
I propose that we keep whatever additional defin
Serge Knystautas wrote:
Noel J. Bergman wrote:
Really the biggest hurdle is a stable Avalon release. :)
I would use the latest release packages from Avalon, and once we get
merged,
I think it makes sense for Stephen to add configuration files for a
James
package using Merlin as well as our
Noel J. Bergman wrote:
Really the biggest hurdle is a stable Avalon release. :)
I would use the latest release packages from Avalon, and once we get merged,
I think it makes sense for Stephen to add configuration files for a James
package using Merlin as well as our Phoenix packaging.
So to just ge
30 matches
Mail list logo
