[ http://issues.apache.org/jira/browse/JAMES-522?page=all ]
Noel J. Bergman updated JAMES-522:
--
Priority: Trivial (was: Minor)
> Having the ClamAVScan mailet configured, but clamd unavailable when JAMES
> starts, keeps JAMES from starting.
> -
[
http://issues.apache.org/jira/browse/JAMES-522?page=comments#action_12414615 ]
Noel J. Bergman commented on JAMES-522:
---
In the mailet config, adding 0 will disable the check, and
the error, so this is arguably a "trivial" error. Still, it presents
Having the ClamAVScan mailet configured, but clamd unavailable when JAMES
starts, keeps JAMES from starting.
Key: JAMES-522
URL: http://issues.apache.org/jira/browse/JAME
Am Samstag, den 03.06.2006, 16:32 -0400 schrieb Noel J. Bergman:
> Norman Maurer wrote:
>
> > Noel J. Bergman:
>
> > > - Each processor is a named queue entry.
> > Not can say much about this. Not have a closer look at [JMS]
>
> The first line is the key idea. The fact that it *might* be a JM
Norman Maurer wrote:
> Noel J. Bergman:
> > - Each processor is a named queue entry.
> Not can say much about this. Not have a closer look at [JMS]
The first line is the key idea. The fact that it *might* be a JMS queue
should not really be a change, and we should support other implementation
Am Samstag, den 03.06.2006, 16:04 -0400 schrieb Noel J. Bergman:
> Norman Maurer wrote:
>
> > It is from the 28.06 - 30.06 . Right ?
>
> Actually, the hack-a-thon will be 26-27/6, although we'll have things going
> the whole time. Hack-a-thon's don't get put on a schedule, and BOFs will be
> put
Norman Maurer wrote:
> It is from the 28.06 - 30.06 . Right ?
Actually, the hack-a-thon will be 26-27/6, although we'll have things going
the whole time. Hack-a-thon's don't get put on a schedule, and BOFs will be
put on the Wiki later. There is a JAMES tutorial on fast-fail offered, if
people
Just to get sure... It is from the 28.06 - 30.06 . Right ? I also not
seen the JAMES session anywere in the plan... Im wrong ?
bye
Norman
Am Samstag, den 03.06.2006, 19:20 +0200 schrieb Norman Maurer:
> Am Samstag, den 03.06.2006, 13:16 -0400 schrieb Noel J. Bergman:
> > Norman Maurer wrote:
> >
Am Samstag, den 03.06.2006, 14:18 -0400 schrieb Noel J. Bergman:
> Concepts:
>
> - Each processor is a named queue entry. This is
> not a change from today, except that these may
> be real queues in the JMS sense of the word if
> the underlying queue manager uses JMS. But the
>
Concepts:
- Each processor is a named queue entry. This is
not a change from today, except that these may
be real queues in the JMS sense of the word if
the underlying queue manager uses JMS. But the
approach should NOT be JSM/MQ specific. It
should work just fine with JDB
Author: norman
Date: Sat Jun 3 10:54:37 2006
New Revision: 411449
URL: http://svn.apache.org/viewvc?rev=411449&view=rev
Log:
-refactoring for using abstract class
Added:
james/server/trunk/src/test/org/apache/james/transport/matchers/AbstractRecipientIsTest.java
Modified:
james/server/
Am Samstag, den 03.06.2006, 13:16 -0400 schrieb Noel J. Bergman:
> Norman Maurer wrote:
>
> > It will be nice to meet you :-)
>
> I'm looking forward to it. :-)
>
> > You will also sign keys then ?
>
> We should have a key signing party, but regardless, if you bring your key
> and your photo I
Norman Maurer wrote:
> It will be nice to meet you :-)
I'm looking forward to it. :-)
> You will also sign keys then ?
We should have a key signing party, but regardless, if you bring your key
and your photo ID, three parents, and two gov't witnesses, I'll sign your
key.
> Anythings you know
Hi Noel,
thx for the info. It will be nice to meet you :-) You will also sign
keys then ? Anythings you know yet we all should talk about ?
bye
Norman
Am Samstag, den 03.06.2006, 01:36 -0400 schrieb Noel J. Bergman:
> Norman,
>
> As far as I know, it will be you, me, Danny and Vincenzo. I will
This roadmap makes sense to me.
When I wrote it I thought about writing a JDBC Javamail Store because we
already have the specification and we don't need too much discussion,
and using it with your wrapper we could start using it.
But as we already agreed, our hierarchical message repository
Joachim Draeger wrote:
- MessageKey created while storing, and not userprovided.
This would make implementation of existing standard a lot easier. Are
there disadvantages? When I store the same message into different
repositories I've to care about the repository keys myself when I want
to
Joachim Draeger wrote:
Serge Knystautas schrieb:
The biggest design deficiency of Javamail is the lack of interfaces.
That's why
using javamail means being limited in hierarchy, and being unable to
completely
replace implementations.
This is an interesting point... should we create interfac
Hi,
just create a lib folder in the SAR-INF and place it there.
For example:
/james-xxx/apps/james/SAR-INF/lib/your.jar
bye
Norman
Am Samstag, den 03.06.2006, 10:29 +0200 schrieb Joachim Draeger:
> Hi!
>
> "There should be a more convenient way. Is there?"
>
> Is there? :-) How to add a Jar
Hi!
"There should be a more convenient way. Is there?"
Is there? :-) How to add a Jar to the core of James without going so deep? Maybe
just as easy as placing a custom Mailet into the ext folder.
Joachim
Joachim Draeger (JIRA) schrieb:
To setup a Javamail store MailRepository you have t
Serge Knystautas schrieb:
The biggest design deficiency of Javamail is the lack of interfaces.
That's why
using javamail means being limited in hierarchy, and being unable to
completely
replace implementations.
This is an interesting point... should we create interfaces that
mirror the metho
20 matches
Mail list logo
