You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bernd Fondermann <bf...@brainlounge.de> on 2007/07/16 14:00:09 UTC
Re: Spring deployment
Bernd Fondermann wrote:
> ATM, we have to translate james-assembly.xml into Spring beans
> definition. I want to reuse james-assembly.xml in Spring by writing a
> "mapper bean factory". Switching between deployments would be rather
> easy then.
The very first step is committed.
There is much more to be done but the general direction is to have
+ a master bean xml configuration, containing the "bootstrapping beans"
(named "beans-base-config.xml")
+ an james-assembly.xml which is referenced from the master and is read
into a spring bean definition
+ optionally add additional spring beans by importing in master, or just
by adding beans there directly, or by adding to the avalon assembly.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Spring deployment
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin ha scritto:
> On 7/17/07, Stefano Bagnara <ap...@bago.org> wrote:
>> IMHO it is not spring support to justify a milestone or not. It is a
>> cool, long awaited feature, for sure (and kudos to Bernd for this) but
>> Spring support will be only one more of the *127* bugs fixes/features we
>> already have in trunk:
>> https://issues.apache.org/jira/browse/JAMES?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
> often having a bit of cool new functionality to aim at helps to
> concentrate the mind and it's easier to get excited about one cool
> feature than hundreds of minor fixes and changes...
Sure, FYI here is a list of new features already in trunk:
- SMTP Server
- 8bitmime support
- Greylisting support
- SPF support
- Better SpamAssassin support
- Support for POP-before-SMTP (roaming users)
- URI blacklist support
- URIRBLHandler for fastfail
- Add reverse lookup checks and HELO/EHLO checks in SMTP
- Support Connection Limit per IP
- Virtual hosting / Dynamic reloading / JMX+RemoteManager management
- introduced the VirtualUserTable (VUT) Service
- Support dynamic reload of servernames
- Added JMX+RM operations for spool/mail repositories and user management.
- Support the use of VUT to extract servernames.
- Added management for the new VUT store/repository.
- Added management interfaces and remotemanager commands to manage the
servername list
- Critical Issues
- Almost fully rewritten DNSServer to fix OOM issues and some critical
caching bug.
- Added search-domain configurability to DNSServer
- Introduced Commons Daemon to run james as non root.
- Furthermore we have now 2 experimental "IMAP servers".
IMHO some of them is at least as cool as spring support. Of course this
is only a personal opinion: I wrote the list only to update you on
what's in trunk, as you wasn't here when we worked there. I have to
admit that I had forgotten most of them in this months, too.
My personal pick is the much better support for virtual hosting that
come out from some of the VUT-related features (mainly because fastfail
and imap are not yet mature enough).
>> My question was about the plan details: I was curious about how do you
>> propose to manage the milestone cut.
>
> dunno :-)
same here :-) ... or better :-/
> i'm not proposing anything ATM just posing the question: would a
> milestone from trunk containing spring integration be a good idea?
>
>> While I'm here, I've a doubt: is there any limitation in packaging an
>> early access version of javamail in a official release (even if it is
>> only a milestone ?).
>
> this is a question of policy
>
> in terms of apache policy, it's really a question of licensing. before
> thinking about a release, all the licenses need to be checked anyway
> so it's no real extra work.
>
> in terms of JAMES policy, that depends on what we collectively decide
> is appropriate for a milestone release
Ok. Then I'm fine with the use of SNAPSHOT/ea/beta dependencies in
milestones/alpha/beta releases (as long as their license allow this).
>> I remember in past the SUN "ea" releases had a
>> special license (that wouldn't have allowed a release), but now in the
>> jar LICENSE file I can't find any pointer but a standard CDDL.
>
> AIUI sun have significantly rationalised their licensing policy recently
>
> - robert
Right. I was referencing it to make a concrete example of a license (the
old early access license) that would have not allowed us to make an
ASLv2 release distributing that code.
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Spring deployment
Posted by robert burrell donkin <ro...@gmail.com>.
On 7/17/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:
> > On 7/16/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> robert burrell donkin ha scritto:
> >> > On 7/16/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
> >> >> Bernd Fondermann wrote:
> >> >> > ATM, we have to translate james-assembly.xml into Spring beans
> >> >> > definition. I want to reuse james-assembly.xml in Spring by
> >> writing a
> >> >> > "mapper bean factory". Switching between deployments would be rather
> >> >> > easy then.
> >> >>
> >> >> The very first step is committed.
> >> >
> >> > cool :-)
> >> >
> >> > maybe we should think about a plan for cutting milestones...?
> >> >
> >> > - robert
> >>
> >> What are you thinking about?
> >
> > if some measure of support for spring were patched into trunk then
> > this might justify a milestone
> >
> > - robert
>
> IMHO it is not spring support to justify a milestone or not. It is a
> cool, long awaited feature, for sure (and kudos to Bernd for this) but
> Spring support will be only one more of the *127* bugs fixes/features we
> already have in trunk:
> https://issues.apache.org/jira/browse/JAMES?report=com.atlassian.jira.plugin.system.project:roadmap-panel
often having a bit of cool new functionality to aim at helps to
concentrate the mind and it's easier to get excited about one cool
feature than hundreds of minor fixes and changes...
> My question was about the plan details: I was curious about how do you
> propose to manage the milestone cut.
dunno :-)
i'm not proposing anything ATM just posing the question: would a
milestone from trunk containing spring integration be a good idea?
> While I'm here, I've a doubt: is there any limitation in packaging an
> early access version of javamail in a official release (even if it is
> only a milestone ?).
this is a question of policy
in terms of apache policy, it's really a question of licensing. before
thinking about a release, all the licenses need to be checked anyway
so it's no real extra work.
in terms of JAMES policy, that depends on what we collectively decide
is appropriate for a milestone release
> I remember in past the SUN "ea" releases had a
> special license (that wouldn't have allowed a release), but now in the
> jar LICENSE file I can't find any pointer but a standard CDDL.
AIUI sun have significantly rationalised their licensing policy recently
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Spring deployment
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin ha scritto:
> On 7/16/07, Stefano Bagnara <ap...@bago.org> wrote:
>> robert burrell donkin ha scritto:
>> > On 7/16/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
>> >> Bernd Fondermann wrote:
>> >> > ATM, we have to translate james-assembly.xml into Spring beans
>> >> > definition. I want to reuse james-assembly.xml in Spring by
>> writing a
>> >> > "mapper bean factory". Switching between deployments would be rather
>> >> > easy then.
>> >>
>> >> The very first step is committed.
>> >
>> > cool :-)
>> >
>> > maybe we should think about a plan for cutting milestones...?
>> >
>> > - robert
>>
>> What are you thinking about?
>
> if some measure of support for spring were patched into trunk then
> this might justify a milestone
>
> - robert
IMHO it is not spring support to justify a milestone or not. It is a
cool, long awaited feature, for sure (and kudos to Bernd for this) but
Spring support will be only one more of the *127* bugs fixes/features we
already have in trunk:
https://issues.apache.org/jira/browse/JAMES?report=com.atlassian.jira.plugin.system.project:roadmap-panel
My question was about the plan details: I was curious about how do you
propose to manage the milestone cut.
While I'm here, I've a doubt: is there any limitation in packaging an
early access version of javamail in a official release (even if it is
only a milestone ?). I remember in past the SUN "ea" releases had a
special license (that wouldn't have allowed a release), but now in the
jar LICENSE file I can't find any pointer but a standard CDDL.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Spring deployment
Posted by robert burrell donkin <ro...@gmail.com>.
On 7/16/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:
> > On 7/16/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
> >> Bernd Fondermann wrote:
> >> > ATM, we have to translate james-assembly.xml into Spring beans
> >> > definition. I want to reuse james-assembly.xml in Spring by writing a
> >> > "mapper bean factory". Switching between deployments would be rather
> >> > easy then.
> >>
> >> The very first step is committed.
> >
> > cool :-)
> >
> > maybe we should think about a plan for cutting milestones...?
> >
> > - robert
>
> What are you thinking about?
if some measure of support for spring were patched into trunk then
this might justify a milestone
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Spring deployment
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin ha scritto:
> On 7/16/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
>> Bernd Fondermann wrote:
>> > ATM, we have to translate james-assembly.xml into Spring beans
>> > definition. I want to reuse james-assembly.xml in Spring by writing a
>> > "mapper bean factory". Switching between deployments would be rather
>> > easy then.
>>
>> The very first step is committed.
>
> cool :-)
>
> maybe we should think about a plan for cutting milestones...?
>
> - robert
What are you thinking about?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Spring deployment
Posted by robert burrell donkin <ro...@gmail.com>.
On 7/16/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Bernd Fondermann wrote:
> > ATM, we have to translate james-assembly.xml into Spring beans
> > definition. I want to reuse james-assembly.xml in Spring by writing a
> > "mapper bean factory". Switching between deployments would be rather
> > easy then.
>
> The very first step is committed.
cool :-)
maybe we should think about a plan for cutting milestones...?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org