james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834) Webcontainer Deployment (WAR)]
Date Sun, 01 Mar 2009 10:27:15 GMT
On Sun, Mar 1, 2009 at 9:10 AM, Bernd Fondermann <bf_jak@brainlounge.de> wrote:
> Robert Burrell Donkin (JIRA) wrote:
>>
>>    [
>> https://issues.apache.org/jira/browse/JAMES-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677677#action_12677677
>> ]
>> Robert Burrell Donkin commented on JAMES-834:
>> ---------------------------------------------
>>
>> AIUI these are phoenix container dependencies
>>
>> (I'm still a little hazy about the way that the Spring stuff works)
>>
>> Why are they needed for spring?
>
> There are two separate issues here:
>
> 1. Broken manifests in some libs
>
> This has nothing to do with spring. It's a problem of deploying libs with
> broken manifests in a web container.
> There are multiple solutions to it:
> a. Fix the Manifests
> b. Upgrade to a later release of the libs
> c. Don't deploy the libs at all
>
> I favor a., because the impact of b. and c. is not so easy to test, isn't
> it?

the smoke tests work well enough

i plan to have a play with hudson this afternoon so maybe i'll have
more to report then

> 2. Inclusion of any lib from phoenix-depl in spring-depl
>
> When creating spring-depl I tried to follow a very canonical approach of
> deriving spring-depl from phoenix-depl because we saw spring-depl only as a
> supplemental deployment. That meant taking all of phoenix, inluding libs and
> configs, not asking any questions and adopt that to spring.

i think using phoenix blocks to wire the spring version together seems
unnatural. i suspect that if we drop support for phoenix block wiring
in the spring deployment then these libraries would not be necessary.
can anyone see any problems with this approach?

IMHO phoenix and the avalon framework are holding the server back

i would like to be able to run james on the phoenix container but
don't want the server architecture to be determined by it. my
preference would be to replace the intrusive Avalon interfaces with
JSR-250 annotations. this would provide a natural path toward smoother
integration with JEE containers whilst providing an easy route to
retain phoenix compatibility. if this sounds like an idea would
exploring, i'll open a JIRA with more details.

in the medium term, i think the best approach for james would be a
blended micro-kernel approach (like service-mix, for example) with a
top level service locator layer for coursely grained services (with
internal structure below that assembled by any supported dependency
injection mechanism).

- robert

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


Mime
View raw message