Hello Maksim.
This is a classical example of technical details of a specific implementation
leaking in the API and preventing other implementations for being fully spec
compliant.
You are right, with JMS backend we might not be able to support more than 10
priority levels (I wasn't aware of th
Sorry to bother you. Yes, but merely extending the range in the
MailPrioritySupport interface will not guarantee that the
PriorityMailQueueContract and PriorityManageableMailQueueContract contracts
are adhered to for negative priority values. For instance, the
MailPrioritySupport implementation, JM
Hello,
As said on github, +1
I believe the range 0-9 is defined within the Mail interface which is a James
class.
My understanding is that we are fully able to increase this range without third
party library impacting us.
BTW by moving to a larger range we are causing no breaking change as b
looks like my reploy below never reached the list
Le lun. 27 nov. 2023 à 15:04, Jean Helou a écrit :
> I'm all for it as long as we give a fighting chance to users :)
>
> I see 3 different user population with regard to spring support
>
> - basic users who want an pre-assembled email server to r
Hi,
Just wanted sharing my developer experience today, that is so well
summarized below...
So, after
https://www.mail-archive.com/server-user@james.apache.org/msg16880.html
discussion on the mailing list it seems that there is a consensus to
upgrade to Java 21 (yey!).
I decided to start P
Hi,
+1 on the Spring deprecation with caution.
Regards,
Quan
Vào Th 2, 27 thg 11, 2023 vào lúc 14:30 Benoit TELLIER <
btell...@apache.org> đã viết:
> +1 on my side.
>
> I agree deprecating Spring implementation in James as of 3.9.0 and drop
> it afterward.
>
> On 24/11/2023 17:30, Matthieu B
+1 on my side.
I agree deprecating Spring implementation in James as of 3.9.0 and drop
it afterward.
On 24/11/2023 17:30, Matthieu Baechler wrote:
Hi,
I had a hack session with Benoit today and the sentence "this would break
Spring" came many times along the day.
As I'm less active on Jame
Hi Matthieu,
I think some people in the community are probably using the Spring
version because the official documentation was never really clear about
our intentions of potentially deprecating and removing this part.
I'm totally for deprecating and removing that part, and I'm very happy
tha
Dear all,
Here are the notes taken during our first community call:
```
Apache James community meeting 25 June 2020
## Turn table & presentations
IEugen Stan
Start with a Google Summer of Code implements Hbase mailbox.
Want to get back into the project because he will use James as a mail
server
Hello,
I am unaware of Eugen speaking French.
Also, some of my Vietnamese coworker are curious and want to join.
I think we will have to go with it in English.
Cheers,
Benoit
Le 25/06/2020 à 11:21, David Leangen a écrit :
>
> Hi,
>
> I get the impression that everybody here speaks French.
>
Hi,
I get the impression that everybody here speaks French.
Would it be ok to do the call in French instead of English?
Cheers,
=David
> On Jun 24, 2020, at 20:41, Tellier Benoit wrote:
>
> Reminder ;-)
>
> Time: Thursday 25th June 2020, from 8am UTC to 9am UTC
>
> Location: https://mee
Reminder ;-)
Time: Thursday 25th June 2020, from 8am UTC to 9am UTC
Location: https://meet.jit.si/apacheJames
Agenda:
- Turn table & presentation (10 minutes - 1 each)
- Documentation effort & James project server offering (15 minutes)
- Improve the developer experience (15 minutes)
- Build
+1,
Looking forward to this as well.
For the agenda, I propose we look at the things we discussed about.
- Getting to know each other - 1 minute each ?!
- Current documentation process
- Improve the developer experience - faster builds Gradle migration -
- Automated builds - on Apache infrast
Hi,
I will be really pleased to exchange some sight with you during my coffee
time.
Antoine
Le jeu. 18 juin 2020 à 12:06, Tellier Benoit a écrit :
> Le 18/06/2020 à 17:02, Tellier Benoit a écrit :
> > Hello all,
> >
> > Eugen suggested me to be having a community call.
> >
> > We have been dis
Le 18/06/2020 à 17:02, Tellier Benoit a écrit :
> Hello all,
>
> Eugen suggested me to be having a community call.
>
> We have been discussing a lot lately, this could be the occasion to know
> each others better, and find some common ground between community members.
>
> I know that live meetin
Here is the JIRA: https://issues.apache.org/jira/projects/JAMES/issues/JAMES
You are free to create an account on it.
Cheers,
Benoit
On 08/10/2019 13:16, Jerry Malcolm wrote:
> I will do that. But I need a bit of direction first. I know what
> JIRA does. But what do I need to do in order to
I will do that. But I need a bit of direction first. I know what JIRA
does. But what do I need to do in order to get a JIRA account set up?
And is there a home page for JAMES JIRA?
On 10/7/2019 9:34 PM, Tellier Benoit wrote:
Sounds like a great proposal!
Don't you mind opening a JIRA tick
Sounds like a great proposal!
Don't you mind opening a JIRA ticket about this?
Best regards,
Benoit
On 08/10/2019 01:53, Jerry Malcolm wrote:
> As a bit of background for this proposal, I personally have no problem
> trading a small overhead of some additional headers in a delivered
> email if
+1
--
Antoine
Hi every one !
I just committed my patches about QUOTA handling in James.
Next step of the two hours I dedicate to James today is to have a look
to patches attached to the JIRA by Matthieu Baechler and his team.
And I fill like it is hard to retrieve contributions in JIRA. I
On 2015-09-03 15:13, Matthieu Baechler wrote:
On 03/09/2015 11:48, Eric Charles wrote:
On 2015-09-03 11:04, Matthieu Baechler wrote:
Hi Eric,
On 03/09/2015 10:16, Eric Charles wrote:
I like Matthieu proposal (merge without mime4...), but this will open
the door to more refactoring that w
On 03/09/2015 11:48, Eric Charles wrote:
On 2015-09-03 11:04, Matthieu Baechler wrote:
Hi Eric,
On 03/09/2015 10:16, Eric Charles wrote:
I like Matthieu proposal (merge without mime4...), but this will open
the door to more refactoring that would maybe go against the initial
requirement of
On 2015-09-01 14:29, Benoit Tellier wrote:
(snip...)
- Finally, there is the issue that started this thread. There might be
duplication between mailbox code and james-server-data-* one. In the
Cassandra example, we developed tools for creating tables, index, custom
types... That we want to
On 2015-09-03 11:04, Matthieu Baechler wrote:
Hi Eric,
On 03/09/2015 10:16, Eric Charles wrote:
I like Matthieu proposal (merge without mime4...), but this will open
the door to more refactoring that would maybe go against the initial
requirement of being able to embed some mailbox without th
Hi Eric,
On 03/09/2015 10:16, Eric Charles wrote:
I like Matthieu proposal (merge without mime4...), but this will open
the door to more refactoring that would maybe go against the initial
requirement of being able to embed some mailbox without the full server.
Of course, as the mailbox API wi
I like Matthieu proposal (merge without mime4...), but this will open
the door to more refactoring that would maybe go against the initial
requirement of being able to embed some mailbox without the full server.
Maybe we should write to guidelines we can refer when working in that
single repos
On 2015-08-27 11:11, Stephen Brewin wrote:
Hi
As I recall, the intent of having separate projects for many of the
components developed under the James umbrella was to satisfy the
requirement that they should be independent of James Server. While this
remains a requirement, separate repositories
On 2015-08-28 20:40, Stephen Brewin wrote:
Hi Vincenzo and Ioan
While Mattiheu's proposal does mention switching to GIT and I agree that
GIT is superior to SVN and I support this, the most important part is
the restructuring of our projects.
James structure should be independent of any versi
Hi Benoit
There appears to be consensus that our project layout should be
refactored along the lines suggested by Matthieu. You seem to be
suggesting that we go further, which I believe we should hold off on.
With Matthieu's refactored structure a mulit-module Maven build that
uses a BOM (a
In my opinion this decision belongs to active developers: they are the
users of the source tree and the build tools, so they are entitled to
make the changes to feel confortable.
So, if active developers prefer to have a single branch, then you have
my +1 for this.
IIRC Robert was the main suppor
For me this is a +1.
I think there is several issue with today organization :
- Some projects are not really separated. For instance, if I want to
add QUOTA support, I will modify Mailbox interfaces, but also change
things in protocols.
- Having separated modules that are eavily change
On 01/09/2015 08:18, Matthieu Baechler wrote:
Thank you for your answer Stephen. It looks like we agree one this
proposal.
Can I take your answer for a +1 ?
+1 for restructuring
We should discuss transitioning to GIT separately
--Steve
---
Thank you for your answer Stephen. It looks like we agree one this proposal.
Can I take your answer for a +1 ?
Eric : you didn't gave your opinion yet, WDYT ?
--
Matthieu Baechler
On 27/08/2015 20:02, Stephen Brewin wrote:
My previous post corrected for copy/paste issues on phone!
On 27/08/2
Thank you Stephen for clarifying this, I totally agree but didn't find
time to answer, you just beat me at answering !
Cheers,
--
Matthieu Baechler
On 28/08/2015 20:40, Stephen Brewin wrote:
Hi Vincenzo and Ioan
While Mattiheu's proposal does mention switching to GIT and I agree that
GIT is s
Hi Vincenzo and Ioan
While Mattiheu's proposal does mention switching to GIT and I agree that
GIT is superior to SVN and I support this, the most important part is
the restructuring of our projects.
As I have explained in an earlier post the proposed change abandons the
façade that component
Hi all,
sorry for not having been active at all in the last period.
Anyway, I agree with Ioan that using GIT is *much* more productive than
using SVN, so I cast here my +1.
Regards,
Vincenzo
Il giorno lun 24 ago 2015 alle ore 21:51 Ioan Eugen Stan <
stan.ieu...@gmail.com> ha scritto:
> Hi,
>
>
My previous post corrected for copy/paste issues on phone!
On 27/08/2015 17:17, Stephen Brewin wrote:
On 27/08/2015 10:24, Matthieu Baechler wrote:
Hi Steve,
Thanks for your feedback.
On 27/08/2015 11:11, Stephen Brewin wrote:
Hi
As I recall, the intent of having separate projects for many
On 27/08/2015 10:24, Matthieu Baechler wrote:
Hi Steve,
Thanks for your feedback.
On 27/08/2015 11:11, Stephen Brewin wrote:
Hi
As I recall, the intent of having separate projects for many of the
components developed under the James umbrella was to satisfy the
requirement that they should be
Hi Steve,
Thanks for your feedback.
On 27/08/2015 11:11, Stephen Brewin wrote:
Hi
As I recall, the intent of having separate projects for many of the
components developed under the James umbrella was to satisfy the
requirement that they should be independent of James Server. While this
remains
Hi
As I recall, the intent of having separate projects for many of the
components developed under the James umbrella was to satisfy the
requirement that they should be independent of James Server. While this
remains a requirement, separate repositories are needed for each project
to allow sep
+1
On Mon, Aug 24, 2015 at 3:37 PM, Matthieu Baechler
wrote:
> Hi all,
>
> For some months, Antoine Duprat, Benoit Tellier and myself are working
> daily on James 3.
>
> We tried hard to make our development workflow as simple as possible.
>
> One thing that's very annoying right now is that Jam
Hi,
Yes, the work flow is not the best with SVN. There is an option to
migrate James to git hosting and personally I think it will be a good
thing.
In order to make this a reality we have to raise a vote and raise a JIRA
issue to Apache Infra. The vote has to run for 72h.
You have my +1.
p.s. O
Hi,
Sounds great to me. Anything I can do to help just let me know.
Cheers,
--
Ioan Eugen Stan
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Hi Ioan,
mailbox-integration-test is now part of mpt.
We need a up-to-date postage to help tackle down server issues (eg.
mails stuck in queue...), so I will continue to work on POSTAGE-23.
In the (near) future, postage being removed as a James sub-projects and
integrated as a stress-module
Hello,
On Thu, Mar 7, 2013 at 9:56 AM, Eric Charles wrote:
> I hope to be able to finish MPT-4 in a the coming week.
Cool.
> mailbox-integration-tester is orphan for now (No web site, no release...)
> which is tricky since a lot time.
>
> I wonder if mpt would be a good home for this orphan.
>
I hope to be able to finish MPT-4 in a the coming week.
mailbox-integration-tester is orphan for now (No web site, no
release...) which is tricky since a lot time.
I wonder if mpt would be a good home for this orphan.
mailbox-integration-tester is just a pratical usecase/application of the
Hi,
MPT is a generic protocol test tool and mailbox-integration-tester aims
to test imap agains mailbox.
It's true that work need to be done to avoid class duplication (see
MPT-4), but in no way they should be merged.
MPT (generic protocol testing), Postage (specific james server testing)
On Sun, Sep 11, 2011 at 6:44 PM, Norman Maurer
wrote:
> Hi there,
>
> I think its time to finally get rid of javamail for sending emails via
> SMTP / SMTPS and use something more performant / better suited for
> heavy usage. javamail just sucks in many ways for SMTP Delivery in a
> way that a real
Hi Eric,
comments inline...
2011/9/14 Eric Charles :
> Hi Norman,
>
> I was wondering if it would be possible to have a adapter layer so we can
> simply replace the current javamail with the niosmtp jar without changing
> server code. Thinking more about, I don't think it makes sense as we will
>
Hi Norman,
I was wondering if it would be possible to have a adapter layer so we
can simply replace the current javamail with the niosmtp jar without
changing server code. Thinking more about, I don't think it makes sense
as we will have to add new function to that layer to support the new
fe
On Mon, Sep 12, 2011 at 12:07, Norman Maurer
wrote:
> Hi Bernd,
>
> I'm currently thinking about it, yeah. Github was the quickest way for
> me to get started and also learn a bit more about git so I started it
> there. But I agree it would make sense to move it to james sometimes
> as it is reall
Hi Bernd,
I'm currently thinking about it, yeah. Github was the quickest way for
me to get started and also learn a bit more about git so I started it
there. But I agree it would make sense to move it to james sometimes
as it is really related..
Bye,
Norman
2011/9/12 Bernd Fondermann :
> On Sun
On Sun, Sep 11, 2011 at 19:44, Norman Maurer
wrote:
> Hi there,
>
> I think its time to finally get rid of javamail for sending emails via
> SMTP / SMTPS and use something more performant / better suited for
> heavy usage. javamail just sucks in many ways for SMTP Delivery in a
> way that a real s
>> Reducing the number of modules from 43 to 35 brings our average to 10
>> classes per module and it's clear we are still far lower than the
>> average "new" java project.
> When you say module what exactly you count ? It sound like you not
> count the " in the pom.xml..
Yes, in james-server/trun
Hi,
comments inside again :)
2011/1/11 Stefano Bagnara :
> 2011/1/11 Eric Charles :
>> (quick answer)
>>
>> - Yes, 43 is much... The idea behind was the osgi track (can't find the
>> articles from pax project where they argue to have real small modules, even
>> micro modules, rather than larger o
2011/1/11 Eric Charles :
> (quick answer)
>
> - Yes, 43 is much... The idea behind was the osgi track (can't find the
> articles from pax project where they argue to have real small modules, even
> micro modules, rather than larger one).
Yes, depending on how you read "micro". I'd say micro is 10
Comments inside..
2011/1/11 Eric Charles :
> (quick answer)
>
> - Yes, 43 is much... The idea behind was the osgi track (can't find the
> articles from pax project where they argue to have real small modules, even
> micro modules, rather than larger one).
> - Your proposal to have persistence-* is
I think move stuff out of server should not get done.. Also I think we
would make better just call it "jpa", "jcr" ... No need to prefix it
with persistence.
Bye,
Norman
2011/1/11 Eric Charles :
> Commenting while thinking:
> - moving persistence-* out-of- server sounded good to me, but we will f
Hi Stefano,
the idea was to make it easy to use and deploy them in an osgi
container without the need to not needed dependencies.. You know in
OSGI you will see a dependency hell really fast ;)
For details see inline..
2011/1/11 Stefano Bagnara :
> You know I finally had some time to review cur
Commenting while thinking:
- moving persistence-* out-of- server sounded good to me, but we will
face release issue (a release is some work), so it should be forgotten.
- 'persistence' naming is well representative, but we also have the
'mailbox' which is the mail persistence: I expect confusion
(quick answer)
- Yes, 43 is much... The idea behind was the osgi track (can't find the
articles from pax project where they argue to have real small modules,
even micro modules, rather than larger one).
- Your proposal to have persistence-* is good because it will not oblige
to load unneeded d
+1
Eric
On 10/01/2011 13:10, Norman Maurer wrote:
Thx for all your input (both of you). Maybe I should just go ahead and
write some code to show how exactly it will look like.. It's most
times easy to get the point when looking at some "real code".
WDYT ?
Bye,
Norman
2011/1/10 Stefano Bagnar
Thx for all your input (both of you). Maybe I should just go ahead and
write some code to show how exactly it will look like.. It's most
times easy to get the point when looking at some "real code".
WDYT ?
Bye,
Norman
2011/1/10 Stefano Bagnara :
> 2011/1/10 Eric Charles :
>> What about the jsie
The jsieve stuff would be need to get moved to the "core" service too.
Bye,
Norman
2011/1/10 Eric Charles :
> Hi,
> Tks for the information.
> What about the jsieve functions? We'll we reimplement it or reuse the
> existing mailet?
> Tks,
> Eric
>
> On 10/01/2011 10:54, Stefano Bagnara wrote:
>>
2011/1/10 Eric Charles :
> What about the jsieve functions? We'll we reimplement it or reuse the
> existing mailet?
I have to make more clear that my previous comment was about the
Remote delivery which I know well as it didn't change in the last 2
years.
I don't have a good knowledge of the loca
Hi,
Tks for the information.
What about the jsieve functions? We'll we reimplement it or reuse the
existing mailet?
Tks,
Eric
On 10/01/2011 10:54, Stefano Bagnara wrote:
2011/1/10 Eric Charles:
So configuration and code would the same for now, simply export them to
separate components (additi
2011/1/10 Eric Charles :
> So configuration and code would the same for now, simply export them to
> separate components (additional conf file and maven module I guess) ?
>
> As side effect, we should have in mind:
> - More resources (memory / cpu / I/O) for the delivery threads and queues.
> - Add
Kind of.. I would try to refactor the code a bit more to make it easy
to replace javamail Transport usage for SMTP later etc. Also I would
try to hook in kind of plugins for postprocessing and jmx stats.
I think the memory/cpu is not really a problem. It should not be
notable. The IO should also n
So configuration and code would the same for now, simply export them to
separate components (additional conf file and maven module I guess) ?
As side effect, we should have in mind:
- More resources (memory / cpu / I/O) for the delivery threads and queues.
- Additional delay for the mails to be
Hi there,
comments inside...
2011/1/10 Eric Charles :
> Hi Norman,
>
> I see two attention points there:
> - Additional operational components to be managed/monitored (the
> intermediate delivery queues, jms or whatever), but I see you already began
> to take it into account with JAMES-1180 (All
Hi Norman,
I see two attention points there:
- Additional operational components to be managed/monitored (the
intermediate delivery queues, jms or whatever), but I see you already
began to take it into account with JAMES-1180 (Allow to browse MaillQueue)
- Which configuration/processing framewo
Could you explain what Problems you See here?
Also the Queues would Be of the type MailQueue, so its not limited to
jms. The configuration of the Services would Be Done by seperate
config Files
Bye
Norman
Am Sonntag, 9. Januar 2011 schrieb Eric Charles :
> Hi,
>
> I also like the idea to ha
Hi,
I also like the idea to have remote/local delivery as core service
implemented via JMS queues.
The decision to deliver should remain in the mailet processor.
The way the local/remote delivery queues will be consumed will be
configured via separate mechanisms (xml files).
The question is
Well I thought more about doing the splitting in the Delivery
dispatcher.. something like:
* retrieve mail from queue
* check if mail attribute "prepared" set
* attribute not found:
* do the splitting if needed
* set attribute "prepared"
* store back in queue
* attribute
2011/1/7 Norman Maurer :
> Hi there,
>
> I spend the last weeks to think about RemoteDelivery and how it is
> implemented. I think putting the remote deliver code in a Mailet is
> not a good idea. It does not give us much control about it and makes
> it harder to customize or extend. I think it wou
Just to complete this idea, I think the same is true for the
"LocalDelivery" stuff. We should just put it in the right queue
(local) and then have a core service which does the delivery. Maybe
the remote and local delivery could even share the same interface..
Bye,
Norman
2011/1/7 Norman Maurer
If OK to everyone, I will commit/document enableVirtualHosting=true and
JPADomainList configs.
Tks,
Eric
On 20/12/2010 21:23, Norman Maurer wrote:
+1,
Makes sense in most cases.
Bye,
Norman
2010/12/20 Eric Charles:
Most users also expect to add/remove domains via management interfaces.
JPAD
+1,
Makes sense in most cases.
Bye,
Norman
2010/12/20 Eric Charles :
> Most users also expect to add/remove domains via management interfaces.
> JPADomainList could be shipped as default if we want to cover users'
> expectations.
>
> Tks,
>
> Eric
>
>
> On 19/12/2010 20:05, Norman Maurer wrote:
Most users also expect to add/remove domains via management interfaces.
JPADomainList could be shipped as default if we want to cover users'
expectations.
Tks,
Eric
On 19/12/2010 20:05, Norman Maurer wrote:
2010/12/17 Norman Maurer:
2010/12/16 Stefano Bagnara:
2010/12/16 Eric Charles:
Hi
2010/12/17 Norman Maurer :
> 2010/12/16 Stefano Bagnara :
>> 2010/12/16 Eric Charles :
>>> Hi,
>>> We also need to cover James used as simple MTA/mail-relay/honeypot without
>>> any users defined (for example, in an internal network when processing mails
>>> for virus/spam detection,...).
>>> In th
2010/12/16 Stefano Bagnara :
> 2010/12/16 Eric Charles :
>> Hi,
>> We also need to cover James used as simple MTA/mail-relay/honeypot without
>> any users defined (for example, in an internal network when processing mails
>> for virus/spam detection,...).
>> In this case, we could use in this case
Hi Stefano,
comments inside...
2010/12/17 Stefano Bagnara :
> I find useful to have automatic search of mailets and the current way
> is not so bad (as we only do this once at the start). But we don't use
> the same method for other components (like the protocol handlers) and
> maybe the current
I find useful to have automatic search of mailets and the current way
is not so bad (as we only do this once at the start). But we don't use
the same method for other components (like the protocol handlers) and
maybe the current method is not OSGi friendly (is this a motivation
for your proposal?).
+1
Eric
On 17/12/2010 08:13, Norman Maurer wrote:
Hi there,
I know many proposal this week but its time to "break" stuff now ;)
I would like to propose that we remove the "mailetpackages" and
"matcherpackages" configuration option from the mailetcontainer.xml
file. This would force the users t
Hi,
I remember Raju tried the mailing-lists functionality on 3.0M2 (don't
know the status of it)
Upon the UsersRepo removal from mailing list mailets, there's we could
also upgrade the database access from JDBC to JPA.
We have http://svn.apache.org/viewvc/james/server/tags/with_mailinglist/
2010/12/16 Eric Charles :
> Hi,
> We also need to cover James used as simple MTA/mail-relay/honeypot without
> any users defined (for example, in an internal network when processing mails
> for virus/spam detection,...).
> In this case, we could use in this case the "localhost" domain.
>
> I'm also
Hi,
We also need to cover James used as simple MTA/mail-relay/honeypot
without any users defined (for example, in an internal network when
processing mails for virus/spam detection,...).
In this case, we could use in this case the "localhost" domain.
I'm also in favor of having only the virtua
2010/12/16 Norman Maurer :
> 2010/12/16 Stefano Bagnara :
>> 2010/12/16 Norman Maurer :
>>> Hi there,
>>>
>>> as we are currently doing last changes in the API before the next
>>> release I would like to get rid of the UsersStore interface and
>>> implementation.
>>>
>>> Here some background:
>>>
>
2010/12/16 Stefano Bagnara :
> 2010/12/16 Norman Maurer :
>> Hi there,
>>
>> as we are currently doing last changes in the API before the next
>> release I would like to get rid of the UsersStore interface and
>> implementation.
>>
>> Here some background:
>>
>> In previous version of James Server
2010/12/16 Norman Maurer :
> Hi there,
>
> as we are currently doing last changes in the API before the next
> release I would like to get rid of the UsersStore interface and
> implementation.
>
> Here some background:
>
> In previous version of James Server we allowed to configure more then
> one
2010/12/15 Stefano Bagnara :
>>> What about moving to virtual hosting as the default (and maybe the ONLY)
>>> option?
>>> When you setup a mailserver you have a domain, I think it is easier to
>>> understand for newbies if they create users with their full email
>>> address instead of using simple
>> What about moving to virtual hosting as the default (and maybe the ONLY)
>> option?
>> When you setup a mailserver you have a domain, I think it is easier to
>> understand for newbies if they create users with their full email
>> address instead of using simple "usernames" and receive email for
Hi Stefano,
thanks for the feedback.. Just some minor comments inline
2010/12/15 Stefano Bagnara :
> 2010/12/14 Norman Maurer :
>> Hi there,
>>
>> after spending some thoughts about last optimization before the next
>> release, I stumpled again over the MailServer interface.
>> The Mailserver int
2010/12/14 Norman Maurer :
> Hi there,
>
> after spending some thoughts about last optimization before the next
> release, I stumpled again over the MailServer interface.
> The Mailserver interface has corrently 5 methods listed. I think a few
> of them should be moved and a few should get removed
I created an issue which has a patch attached..
https://issues.apache.org/jira/browse/JAMES-1147
If I hear nothing against it I will commit the changes..
Bye,
Norman
2010/12/14 Norman Maurer :
> Hi there,
>
> after spending some thoughts about last optimization before the next
> release, I stum
My web app project uses JSF and Hibernate to manage a James instance
via the database. It can add users, delete users, get stats on how many
messages are waiting to be read, and delete messages in the deadletter
table. It uses the current James schema. I don't know if the schema will
change in
As others seems to agree I will target it for after M1.
Thx,
Norman
2010/10/24 Norman Maurer :
> Exactly... Like JMX.
>
> Bye
> Norman
>
> 2010/10/24, Dhrubo :
>> Robert,
>> Not sure if I have got you right. Independent management product -
>> you mean say an web app deployed on tomcat
Exactly... Like JMX.
Bye
Norman
2010/10/24, Dhrubo :
> Robert,
> Not sure if I have got you right. Independent management product -
> you mean say an web app deployed on tomcat using some kind of remoting to
> manage james?
>
> Kind Regards... Dhrubo
>
>
>
> On Sun, Oct 24, 2010 at 12:4
Yes that's why I was working on JMX. With JMX we can expose management
functions via a standard and if someone want to write a management
frontend he can just use them.
Anyway I think ship a command line client with JAMES makes sense .
Bye
Norman
2010/10/24, Stefano Bagnara :
> 2010/10/24 Robert
Robert,
Not sure if I have got you right. Independent management product -
you mean say an web app deployed on tomcat using some kind of remoting to
manage james?
Kind Regards... Dhrubo
On Sun, Oct 24, 2010 at 12:43 PM, Robert Burrell Donkin <
robertburrelldon...@gmail.com> wrote:
>
2010/10/24 Robert Burrell Donkin :
> On Sat, Oct 23, 2010 at 7:06 PM, Norman Maurer wrote:
>> Sounds good :) I think using JMX calls would be preferable ..
>
> IIRC RemoteManager has issues which prevent the rest of james moving
> forward. though i find RemoteManager useful and had some plans, i
>
1 - 100 of 374 matches
Mail list logo
