avalon and onwards [WAS Re: [server] imap function?]

[Robert Burrell Donkin <ro...@gmail.com>]

On Sun, Sep 7, 2008 at 7:01 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Sun, Sep 7, 2008 at 6:22 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Doens't imap classes
>> (ImapHandler/ImapServer/DefaultMailboxManagerProvider/PhoenixUserManager/PosterMailboxAdapter)
>> deserve a function like the activemq and jcr stuff so to be able to publish
>> imap also in the spring deployment?
>
> quite possibly
>
>> Shouldn't PhoenixUserManager be named "DefaultUserManager" as it is not
>> specific to Phoenix at all and should also be used by the spring deployment?
>
> quite possibly

imapserver-function has turned out to be (at best) a very mixed bag :-/

one of the reasons why i just dumped stuff into pheonix deployment was
ATM i don't think it's possible to fix things properly. the problem is
that in order to make IMAP theoretically (but not practically)
available to the spring deployment, a lot of stuff is being fudged or
regressed in terms of coupling. at least dumping everything in pheonix
means that it's easier to see the problems. dumping everything in
imapserver-function just hides the unaddressed problems and introduces
unnatural couplings into the modules.

i think this probably indicates some misunderstandings of my
underlying reasoning. i'll try to outline them more clearly now.
please forgive the length (i think that we all understand but use
different language and terminology).

avalon is an old, intrusive IoC container. this has some very major
negative consequences for the james server codebase.

Separating Services from Assembly
------------------------------------------------

by a service, i mean a discrete facade independent of the current
component. for example, for SMTP, DNS is a service. by assambly, i
mean the act of assembling an application-scale component from
constituent sub-components. for example, IMAP is an application scale
component composed from many sub-components. it is possible to
assemble IMAP using different sub-components allowing pluggable
customisation of the component. so, assembly is about pluggable
extension.

avalon does not allow a clean separation between the assembly of an
(application-scale) component and the provision of services to that
component. more modern approaches encourage separate service
provision. one promising future for james would be to use OSGi to
replace avalon service provision and spring (or pico) for component
assembly. this will require adopting a clean and clear separation of
service and assembly concerns.

there are various solutions in the codebase which have been adopted to
workaround this basic problem at various times including creating lots
of small services for assembly and loading classes by name based on
the configuration. preserving configuration file compatibility is
important. assembly details needs to be mutable in the short or medium
term. they should therefore not be included directly in the
configuration file.

the solution i propose is to create fully assembled default classes.
however, these are just workarounds for the limitations of avalon and
really shouldn't be used in more expressive containers. moving these
defaults from pheonix-deployment typically causes unfortunate and
unwanted direct coupling in modules.

Avalon Services
---------------------

Setting aside assembly concerns and focussing on interactions between
high level components within james,  let's consider the avalon
approach to services.

Configuration
------------------

in addition to pluggable extension through assembly, the james server
uses a configuration which allows components to take runtime
configuration from a central document. (ATM this is a file but i see
no reason why any general resource could not be used.)

avalon has an intrusive approach to configuration: component require
facades which interpret configurations from avalon specific input. it
does mean that components are tightly coupled to avalon.

this is an excellent fit with the james approach to configuration: a
single canonical configuration document. modern container approaches
tend to use per-service configuration documents. this allows radically
different extensions to be created and configured.

going forward, configuration compatibility is important for james
users. avalon makes it difficult to add new components. once this
limitation starts to ease, allowing configuration of pluggable
elements in the primary configuration will make maintaining
compatibility increasingly difficult.

the most promising solution would be (i think) to both start codifying
a schema for james which can be preserved between upgrades.
configuring pluggable components would not be supported though avalon
but though the native configuration systems of alternative assemblers.
so (for example) if someone wanted to customise the default SMTP
beyond the limited settings available through the james configuration,
they would need to use spring (for example) for assembly of the SMPT
service.

classes implementing Configurable belong in pheonix-deployment.
protocols should include clean, avalon indendent classes.

Service Provision
------------------------

like configuration, service provision using avalon is intrusive. any
class which implements Serviceable is tightly coupled to avalon and
cannot correctly be used with more modern IoC containers.

james makes use of many excalibur components design for use with
avalon. it is perfectly reasonable for these to be tightly couple to
avalon.  i hope that it will be possible to correctly separate
concerns by introducing intermediary interfaces and so avoid direct
coupling outside deployment. this may well mean duplicating some small
amounts of glue code between deployments but i think that this is a
price well worth paying.

many services should need no coupling to excalibur. in the medium
term, these services should be refactored into POJOs in the modules
and avalon-coupled adapters in pheonix-deployment. these adapters are
likely but again, reusing trivial glue code is likely to come at a
high cost in terms of correct modularity.

Service Definition
------------------------

services are defined in xinfo and assembly configuration files. there
are avalon specific and belong in pheonix-deployment.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: avalon and onwards [WAS Re: [server] imap function?]

[Robert Burrell Donkin <ro...@gmail.com>]

On Sun, Sep 14, 2008 at 4:50 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Sun, Sep 7, 2008 at 7:01 PM, Robert Burrell Donkin
>> <ro...@gmail.com> wrote:
>>>
>>> On Sun, Sep 7, 2008 at 6:22 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>>
>>>> Doens't imap classes
>>>>
>>>> (ImapHandler/ImapServer/DefaultMailboxManagerProvider/PhoenixUserManager/PosterMailboxAdapter)
>>>> deserve a function like the activemq and jcr stuff so to be able to
>>>> publish
>>>> imap also in the spring deployment?
>>>
>>> quite possibly
>>>
>>>> Shouldn't PhoenixUserManager be named "DefaultUserManager" as it is not
>>>> specific to Phoenix at all and should also be used by the spring
>>>> deployment?
>>>
>>> quite possibly
>>
>> imapserver-function has turned out to be (at best) a very mixed bag :-/
>
> Like most of the other modules...
> E.g: I feel less comfortable with domain-api being mixed bad than
> imapserver-function.
>
>> one of the reasons why i just dumped stuff into pheonix deployment was
>> ATM i don't think it's possible to fix things properly. the problem is
>> that in order to make IMAP theoretically (but not practically)
>> available to the spring deployment, a lot of stuff is being fudged or
>> regressed in terms of coupling. at least dumping everything in pheonix
>> means that it's easier to see the problems. dumping everything in
>> imapserver-function just hides the unaddressed problems and introduces
>> unnatural couplings into the modules.
>
> I totally disagree :-)
>
> phoenix-deployment is a module like imapserver-function.
> dumping things in one or another does not hide or show anything. Instead of
> you put that code in phoenix-deployment then we have a non functional
> spring-deployment.

spring-deployment is unlikely to work with the current stuff

> IMO avalon code does not belong to phoenix-deployment until we have a pring
> deployment using an avalon-spring bridge and we don't have alternative
> avalon-free implementations.
> Code should be moved to phoenix-deployment when the same very feature is
> already available in the spring deployment by using specific wrappers or
> spring-features, otherwise they need to be in a function. This is a limit
> (you already said this was done by purpose, and I may agree) of the ant
> build. We only have api/util, library, function, deployment layers.
> Currently we would need an "avalon-deployment" and then having the
> phoenix-deployment and spring-deployment as phoenix-package and
> spring-package because both of them are deployments of the avalon stuff.

the current spring-deployment as proposed was never going to be a peer
of pheonix-deployment but a dependent module. trying to make it
anything else will just prevent progress elsewhere. what'll end up
happening is that is that an additional avalon-compatibility layer
will be required between function and deployment or nasty coupling
resulting in hotch-potch modules (such as imapserver-function) and
nothing at all in pheonix-deployment.

>> i think this probably indicates some misunderstandings of my
>> underlying reasoning. i'll try to outline them more clearly now.
>> please forgive the length (i think that we all understand but use
>> different language and terminology).
>>
>> avalon is an old, intrusive IoC container. this has some very major
>> negative consequences for the james server codebase.
>>
>> Separating Services from Assembly
>> ------------------------------------------------
>>
>> by a service, i mean a discrete facade independent of the current
>> component. for example, for SMTP, DNS is a service. by assambly, i
>> mean the act of assembling an application-scale component from
>> constituent sub-components. for example, IMAP is an application scale
>> component composed from many sub-components. it is possible to
>> assemble IMAP using different sub-components allowing pluggable
>> customisation of the component. so, assembly is about pluggable
>> extension.
>>
>> avalon does not allow a clean separation between the assembly of an
>> (application-scale) component and the provision of services to that
>> component. more modern approaches encourage separate service
>> provision. one promising future for james would be to use OSGi to
>> replace avalon service provision and spring (or pico) for component
>> assembly. this will require adopting a clean and clear separation of
>> service and assembly concerns.
>
> This is not an avalon limit but a phoenix limit. AFAICT plexus supports
> distributed assembly configuration.

plexus is a post-avalon container with avalon compatibility

> But I agree in general on your
> statement. While I evaluated moving to newer avalon containers multiple
> times (in fact I also have a loom based james deployed and one year ago I
> evaluated plexus for this) I don't think this is a good option for james
> anymore.

the problem isn't really the container but the component system that
avalon has imposed on james

<snip>

>> Avalon Services
>> ---------------------
>>
>> Setting aside assembly concerns and focussing on interactions between
>> high level components within james,  let's consider the avalon
>> approach to services.
>>
>> Configuration
>> ------------------
>>
>> in addition to pluggable extension through assembly, the james server
>> uses a configuration which allows components to take runtime
>> configuration from a central document. (ATM this is a file but i see
>> no reason why any general resource could not be used.)
>>
>> avalon has an intrusive approach to configuration: component require
>> facades which interpret configurations from avalon specific input. it
>> does mean that components are tightly coupled to avalon.
>>
>> this is an excellent fit with the james approach to configuration: a
>> single canonical configuration document. modern container approaches
>> tend to use per-service configuration documents. this allows radically
>> different extensions to be created and configured.
>
> IIRC in phoenix we could use a config file per block strategy too (but maybe
> I'm confusing this with loom).
> This depends more on the avalon container than on avalon itself.
> Plexus, as an example, makes the configurability and the assembly
> distributed and autodiscovered.

plexus is post-avalon

> But back on Avalon Configuration I think that a hierarchical configuration
> object is not needed by most components. Setters/fields based configuration
> or a POJO configuration bean is often more appropriate these days.
> This simply require effort: split avalon specific classes in 2 separating
> the component logic from the avalon stuff.
> In some case (like the spoolmanager/stateawareprocessorlist/linearprocessor
> stuff we discussed recently, or the jamesserver/jameshandler stuff) it is
> more difficult than this, but in many cases it is a matter of simple
> refactorings.

from the difficult cases i've reviewed, there are problems which
should be fixed at the component level

>> going forward, configuration compatibility is important for james
>> users. avalon makes it difficult to add new components. once this
>> limitation starts to ease, allowing configuration of pluggable
>> elements in the primary configuration will make maintaining
>> compatibility increasingly difficult.
>>
>> the most promising solution would be (i think) to both start codifying
>> a schema for james which can be preserved between upgrades.
>> configuring pluggable components would not be supported though avalon
>> but though the native configuration systems of alternative assemblers.
>> so (for example) if someone wanted to customise the default SMTP
>> beyond the limited settings available through the james configuration,
>> they would need to use spring (for example) for assembly of the SMPT
>> service.
>
> I'm interested in this. Expecially wrt mailet/matcher configuration or the
> smtp handlers configuration. The standard user is expected to deal with that
> configurations.. do you want him to work with that in the spring (for
> example) assembly? Otherwise, what kind of configuration do you propose
> (this is not a simple "properties" configuration)?

i see two distinct categories of use case matching the dual nature of
james as both a mail application similar to sendmail and a platform
for running advanced mail processors

a user with an administrator hat on may want to switch ports or fine
tune a mailet processing chain. this should be done by editing the
standard main configuration document.

a user with a mail processor hat on may want to customise IMAP (say)
by plugging in a custom command. this should be done by creating a
custom independent assembly configuration.

>> classes implementing Configurable belong in pheonix-deployment.
>> protocols should include clean, avalon indendent classes.
>
> I agree. But this does not mean that I think that imapserver content is
> ready to be moved in phoenix-deployment, at least until spring-deployment is
> not able to run imap without using that code.

i doubt spring-deployment will run IMAP anyway. my narrow aim is to
allow james server application to ship a milestone sometime before
IMAP is finished. i see no reason to ship anything other than the
pheonix container as the milestone.

<snip>

>> james makes use of many excalibur components design for use with
>> avalon. it is perfectly reasonable for these to be tightly couple to
>> avalon.  i hope that it will be possible to correctly separate
>> concerns by introducing intermediary interfaces and so avoid direct
>> coupling outside deployment. this may well mean duplicating some small
>> amounts of glue code between deployments but i think that this is a
>> price well worth paying.
>
> This is true for excalibur components, but not for cornerstone stuff.
> Isolating cornerstone would mean writing alternative implementations.

i meant isolating coupled components and factoring out good APIs
rather than creating replacements

>> many services should need no coupling to excalibur. in the medium
>> term, these services should be refactored into POJOs in the modules
>> and avalon-coupled adapters in pheonix-deployment. these adapters are
>> likely but again, reusing trivial glue code is likely to come at a
>> high cost in terms of correct modularity.
>
> I'm in favor of moving avalon-coupled code to phoenix-deployment, but once
> spring-deployment can run the same component the same way.
> ATM spring-deployment has been written to read the standard config.xml and
> this make it more coupled to the avalon stuff.
> I don't know what is the best evolutionary/revolutionary approach to deal
> with this.

i'm not sure what the aim of the current spring-deployment is other
than the very useful proof of concept. i don't want worries about this
to stop progress elsewhere which it seems to be doing.

>> Service Definition
>> ------------------------
>>
>> services are defined in xinfo and assembly configuration files. there
>> are avalon specific and belong in pheonix-deployment.
>
> Most times xinfo are for avalon specific classes. In this case they belong
> to the same modules of the class they declare. Once the avalon-specific
> wrappers will be moved to phoenix-deployment (because spring will be able to
> run the components without that classes) the xinfo will follow the classes.
> assembly is already in phoenix-deployment.
> it also is in spring-deployment because that's the way spring-deployment has
> been built: it parses the assembly and use it as its own configuration file.
>
> I find the double deployment module a critical issue much more than the
> ant+m2 duplication issue Bernd raised previously. Mainly because it seems we
> have active mantainers for the 2 builds while we don't have active
> mantainers for the spring-deployment that is broken more often than not
> since we started major refactorings. Having no automated tests to know that
> the server is at least able to start with both deployments made us ignoring
> the spring-deployment at all.
>
> ATM the spring-deployment is an alternative avalon container and not an
> avalon-free deployment. I think this is the main difficult in understanding
> each other about what belongs to functions and what belongs to
> phoenix-deployment.

i'm not sure it's an alternative container. when it was mooted, the
idea was proposed that the spring deployment would depend on pheonix
at least for a while. i'm not sure what's changed since then.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: avalon and onwards [WAS Re: [server] imap function?]

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Sun, Sep 7, 2008 at 7:01 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> On Sun, Sep 7, 2008 at 6:22 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>> Doens't imap classes
>>> (ImapHandler/ImapServer/DefaultMailboxManagerProvider/PhoenixUserManager/PosterMailboxAdapter)
>>> deserve a function like the activemq and jcr stuff so to be able to publish
>>> imap also in the spring deployment?
>> quite possibly
>>
>>> Shouldn't PhoenixUserManager be named "DefaultUserManager" as it is not
>>> specific to Phoenix at all and should also be used by the spring deployment?
>> quite possibly
> 
> imapserver-function has turned out to be (at best) a very mixed bag :-/

Like most of the other modules...
E.g: I feel less comfortable with domain-api being mixed bad than 
imapserver-function.

> one of the reasons why i just dumped stuff into pheonix deployment was
> ATM i don't think it's possible to fix things properly. the problem is
> that in order to make IMAP theoretically (but not practically)
> available to the spring deployment, a lot of stuff is being fudged or
> regressed in terms of coupling. at least dumping everything in pheonix
> means that it's easier to see the problems. dumping everything in
> imapserver-function just hides the unaddressed problems and introduces
> unnatural couplings into the modules.

I totally disagree :-)

phoenix-deployment is a module like imapserver-function.
dumping things in one or another does not hide or show anything. Instead 
of you put that code in phoenix-deployment then we have a non functional 
spring-deployment.
IMO avalon code does not belong to phoenix-deployment until we have a 
pring deployment using an avalon-spring bridge and we don't have 
alternative avalon-free implementations.
Code should be moved to phoenix-deployment when the same very feature is 
already available in the spring deployment by using specific wrappers or 
spring-features, otherwise they need to be in a function. This is a 
limit (you already said this was done by purpose, and I may agree) of 
the ant build. We only have api/util, library, function, deployment 
layers. Currently we would need an "avalon-deployment" and then having 
the phoenix-deployment and spring-deployment as phoenix-package and 
spring-package because both of them are deployments of the avalon stuff.

> i think this probably indicates some misunderstandings of my
> underlying reasoning. i'll try to outline them more clearly now.
> please forgive the length (i think that we all understand but use
> different language and terminology).
> 
> avalon is an old, intrusive IoC container. this has some very major
> negative consequences for the james server codebase.
> 
> Separating Services from Assembly
> ------------------------------------------------
> 
> by a service, i mean a discrete facade independent of the current
> component. for example, for SMTP, DNS is a service. by assambly, i
> mean the act of assembling an application-scale component from
> constituent sub-components. for example, IMAP is an application scale
> component composed from many sub-components. it is possible to
> assemble IMAP using different sub-components allowing pluggable
> customisation of the component. so, assembly is about pluggable
> extension.
> 
> avalon does not allow a clean separation between the assembly of an
> (application-scale) component and the provision of services to that
> component. more modern approaches encourage separate service
> provision. one promising future for james would be to use OSGi to
> replace avalon service provision and spring (or pico) for component
> assembly. this will require adopting a clean and clear separation of
> service and assembly concerns.

This is not an avalon limit but a phoenix limit. AFAICT plexus supports 
distributed assembly configuration. But I agree in general on your 
statement. While I evaluated moving to newer avalon containers multiple 
times (in fact I also have a loom based james deployed and one year ago 
I evaluated plexus for this) I don't think this is a good option for 
james anymore.

> there are various solutions in the codebase which have been adopted to
> workaround this basic problem at various times including creating lots
> of small services for assembly and loading classes by name based on
> the configuration. preserving configuration file compatibility is
> important. assembly details needs to be mutable in the short or medium
> term. they should therefore not be included directly in the
> configuration file.

Yes, that's happened mainly to increase modularity while preserving 
configuration compatibility 
(org.apache.james.impl.jamesuser.LocalJamesUsersRepository and 
org.apache.james.mailrepository.MailStoreSpoolRepository are 2 clear 
examples of this).

> the solution i propose is to create fully assembled default classes.
> however, these are just workarounds for the limitations of avalon and
> really shouldn't be used in more expressive containers. moving these
> defaults from pheonix-deployment typically causes unfortunate and
> unwanted direct coupling in modules.

If I understand, I agree.

> Avalon Services
> ---------------------
> 
> Setting aside assembly concerns and focussing on interactions between
> high level components within james,  let's consider the avalon
> approach to services.
> 
> Configuration
> ------------------
> 
> in addition to pluggable extension through assembly, the james server
> uses a configuration which allows components to take runtime
> configuration from a central document. (ATM this is a file but i see
> no reason why any general resource could not be used.)
> 
> avalon has an intrusive approach to configuration: component require
> facades which interpret configurations from avalon specific input. it
> does mean that components are tightly coupled to avalon.
> 
> this is an excellent fit with the james approach to configuration: a
> single canonical configuration document. modern container approaches
> tend to use per-service configuration documents. this allows radically
> different extensions to be created and configured.

IIRC in phoenix we could use a config file per block strategy too (but 
maybe I'm confusing this with loom).
This depends more on the avalon container than on avalon itself.
Plexus, as an example, makes the configurability and the assembly 
distributed and autodiscovered.
But back on Avalon Configuration I think that a hierarchical 
configuration object is not needed by most components. Setters/fields 
based configuration or a POJO configuration bean is often more 
appropriate these days.
This simply require effort: split avalon specific classes in 2 
separating the component logic from the avalon stuff.
In some case (like the 
spoolmanager/stateawareprocessorlist/linearprocessor stuff we discussed 
recently, or the jamesserver/jameshandler stuff) it is more difficult 
than this, but in many cases it is a matter of simple refactorings.

> going forward, configuration compatibility is important for james
> users. avalon makes it difficult to add new components. once this
> limitation starts to ease, allowing configuration of pluggable
> elements in the primary configuration will make maintaining
> compatibility increasingly difficult.
> 
> the most promising solution would be (i think) to both start codifying
> a schema for james which can be preserved between upgrades.
> configuring pluggable components would not be supported though avalon
> but though the native configuration systems of alternative assemblers.
> so (for example) if someone wanted to customise the default SMTP
> beyond the limited settings available through the james configuration,
> they would need to use spring (for example) for assembly of the SMPT
> service.

I'm interested in this. Expecially wrt mailet/matcher configuration or 
the smtp handlers configuration. The standard user is expected to deal 
with that configurations.. do you want him to work with that in the 
spring (for example) assembly? Otherwise, what kind of configuration do 
you propose (this is not a simple "properties" configuration)?

> classes implementing Configurable belong in pheonix-deployment.
> protocols should include clean, avalon indendent classes.

I agree. But this does not mean that I think that imapserver content is 
ready to be moved in phoenix-deployment, at least until 
spring-deployment is not able to run imap without using that code.

> Service Provision
> ------------------------
> 
> like configuration, service provision using avalon is intrusive. any
> class which implements Serviceable is tightly coupled to avalon and
> cannot correctly be used with more modern IoC containers.

In past we refactored many of the services to make "service" call 
setters for any dependencies so to allow its use in other containers and 
improve testability. In fact we mainly did that to start adding some 
junit tests (james did not have junit tests until 2005).

> james makes use of many excalibur components design for use with
> avalon. it is perfectly reasonable for these to be tightly couple to
> avalon.  i hope that it will be possible to correctly separate
> concerns by introducing intermediary interfaces and so avoid direct
> coupling outside deployment. this may well mean duplicating some small
> amounts of glue code between deployments but i think that this is a
> price well worth paying.

This is true for excalibur components, but not for cornerstone stuff.
Isolating cornerstone would mean writing alternative implementations.

> many services should need no coupling to excalibur. in the medium
> term, these services should be refactored into POJOs in the modules
> and avalon-coupled adapters in pheonix-deployment. these adapters are
> likely but again, reusing trivial glue code is likely to come at a
> high cost in terms of correct modularity.

I'm in favor of moving avalon-coupled code to phoenix-deployment, but 
once spring-deployment can run the same component the same way.
ATM spring-deployment has been written to read the standard config.xml 
and this make it more coupled to the avalon stuff.
I don't know what is the best evolutionary/revolutionary approach to 
deal with this.

> Service Definition
> ------------------------
> 
> services are defined in xinfo and assembly configuration files. there
> are avalon specific and belong in pheonix-deployment.

Most times xinfo are for avalon specific classes. In this case they 
belong to the same modules of the class they declare. Once the 
avalon-specific wrappers will be moved to phoenix-deployment (because 
spring will be able to run the components without that classes) the 
xinfo will follow the classes.
assembly is already in phoenix-deployment.
it also is in spring-deployment because that's the way spring-deployment 
has been built: it parses the assembly and use it as its own 
configuration file.

I find the double deployment module a critical issue much more than the 
ant+m2 duplication issue Bernd raised previously. Mainly because it 
seems we have active mantainers for the 2 builds while we don't have 
active mantainers for the spring-deployment that is broken more often 
than not since we started major refactorings. Having no automated tests 
to know that the server is at least able to start with both deployments 
made us ignoring the spring-deployment at all.

ATM the spring-deployment is an alternative avalon container and not an 
avalon-free deployment. I think this is the main difficult in 
understanding each other about what belongs to functions and what 
belongs to phoenix-deployment.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org