David Jencks [mailto:david_jen...@yahoo.com] wrote on: 25 March 2010 00:15 Hi David
Comments below. Cheers -- Steve > On Mar 24, 2010, at 1:08 PM, Steve Brewin wrote: > > > Hi David > > > > In OSGi, aren't the instantiations torn down and recreated when the > > configuration is changed, even via admin? This is what I meant by > > 'immutable', though on rereading my post I can see it was > badly phrased. > > I'm not a config admin expert, but IIUC no. The blueprint > config admin namespace handler code I looked at has a bunch > of stuff to distinguish between beans that can be updated > dynamically and beans that need to be recreated. Depending > on how your bean dependencies are set up this might or might > not result in a bunch of other beans getting recreated. I > have yet to figure out why anyone expects people to be able > to write thread safe beans that can be dynamically updated, > but that's a different question.... ....a different but very interesting question. To me a system in which an assembly might or might not work in a certain way is worrying and raises concerns, just one of which is the concern that you raise about thread safety. But this is me talking with an enterprise software hat on. OSGi addresses a broader community, including mobile phone software. Here, the components are tightly managed and hot redploy would be very valuable and much more easily achieved. I don't know enough to understand if our concerns are addressed in the work of the relevant projects, but I doubt that they were introduced thoughtlessly. As time allows, I'll pop over to them and investigate to learn more before further postings here. > > thanks > david jencks > > > > > As you say, and I tried to suggest, modifying (my transforming) the > > Blueprint plan seems to be the way to go. There doesn't > seem to be a need > > for something more dynamic to meet my understanding of the use-case > > described. > > > > Cheers > > -- Steve > > > >> -----Original Message----- > >> From: David Jencks [mailto:david_jen...@yahoo.com] > >> Sent: 24 March 2010 19:17 > >> To: James Developers List > >> Subject: Re: James and Spring / Osgi > >> > >> > >> > >> On Mar 22, 2010, at 2:27 PM, Steve Brewin wrote: > >> > >>> Hi > >>> > >>> You might want to talk to the guys over at Aries - > >>> http://incubator.apache.org/aries/blueprint.html - an > >> implementation > >>> of > >>> Blueprint, which is OSGI's implementation of Spring DM as > >> an OSGi R4 > >>> V4.2 > >>> standard. > >>> > >>> Both OSGI and Blueprint configurations are immutable after > >>> instantiation. > >> > >> That's not really true. Plain osgi has config admin. It > >> hasn't made > >> it into a spec yet but rfc 156 is specifying how osgi config admin > >> relates to blueprint, and aries blueprint has support now, and I'm > >> pretty sure spring blueprint does too (they are building the > >> ri). (I > >> don't know if there are other blueprint implementations out). > >> > >> However, this kind of config support doesn't sound like > what you are > >> looking for -- I think you just want to deploy more than one > >> blueprint > >> plan, one for each mail server instance. > >> > >> thanks > >> david jencks > >> > >>> > >>> To satisfy this usecase, if I have understood it correctly, > >> why not > >>> apply > >>> transforms to a default configuration in a start up script > >> to set the > >>> configuration specifics prior to start-up? > >>> > >>> Cheers > >>> > >>> -- Steve > >>> > >>>> -----Original Message----- > >>>> From: Martin Reisenhofer [mailto:mar...@meinstein.at] > >>>> Sent: 22 March 2010 08:39 > >>>> To: James Developers List > >>>> Subject: Re: James and Spring / Osgi > >>>> > >>>> > >>>> No problem > >>>> > >>>> Thx > >>>> > >>>> Martin > >>>> > >>>> Norman Maurer schrieb: > >>>>> Uff.. > >>>>> > >>>>> I think I have not enough expirience with OSGI to answer > >>>> this.. Maybe > >>>>> the spring dynamic modules docs can bring in some lights.. > >>>>> > >>>>> Sorry, > >>>>> Norman > >>>>> > >>>>> > >>>>> 2010/3/22 Martin Reisenhofer <mar...@meinstein.at>: > >>>>> > >>>>>> Dear Norman, > >>>>>> > >>>>>> I mean is there any Spring-Osgi-Configuration Project to change > >>>>>> configuration of server instances dynamically, without rebundle > >>>>>> configuration. For example, i provide james server as > >>>> osgi bundle, and i > >>>>>> want to start two instances of the server, at first i have > >>>> to install the > >>>>>> james server osgi bundle, the second step is to install a > >>>> bundle which > >>>>>> import the james server osgi bundle and two spring > >>>> configurations for > >>>>>> creating the two instances. I am not sure if this is the > >>>> right way? > >>>>>> > >>>>>> Thx > >>>>>> > >>>>>> Martin > >>>>>> > >>>>>> > >>>>>> Norman Maurer schrieb: > >>>>>> > >>>>>>> Hi Martin, > >>>>>>> > >>>>>>> I don't understand this question "Do you know a > >>>> extension project, > >>>>>>> to configure spring supported server instances without install > >>>>>>> bundles with configuration ?" > >>>>>>> > >>>>>>> Could you rephrase it and give some more details.. > >>>>>>> > >>>>>>> Thx, > >>>>>>> Norman > >>>>>>> > >>>>>>> > >>>>>>> 2010/3/22 Martin Reisenhofer <mar...@meinstein.at>: > >>>>>>> > >>>>>>> > >>>>>>>> Dear Norman, > >>>>>>>> > >>>>>>>> I started with the osgi project now. The reason i will > >>>> use james in osgi > >>>>>>>> environment, is to build up an environment with more > >>>> different servers > >>>>>>>> are > >>>>>>>> easy to configure. For example: use apacheds + james in > >>>> one application > >>>>>>>> server. > >>>>>>>> You have to build an feature or other bundle with the > >>>> configuration for > >>>>>>>> the > >>>>>>>> servers. That is nothing i call fast and easy. Do you > >>>> know a extension > >>>>>>>> project, to configure spring supported server instances > >>>> without install > >>>>>>>> bundles with configuration. > >>>>>>>> > >>>>>>>> Thx, > >>>>>>>> > >>>>>>>> martin > >>>>>>>> > >>>>>>>> > >>>>>>>> Norman Maurer schrieb: > >>>>>>>> > >>>>>>>> > >>>>>>>>> Hi Martin, > >>>>>>>>> > >>>>>>>>> just to follow up on this. Have you started to work on > >>>> this already ? > >>>>>>>>> If so, is there some code already so I could have a > >>>> look ? I would be > >>>>>>>>> really interested in see your progress .. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thx, > >>>>>>>>> Norman > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 2010/3/1 Norman Maurer <norman.mau...@googlemail.com>: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Hi Martin, > >>>>>>>>>> > >>>>>>>>>> I think the important think is to actual do stuff ;) > >>>> So if you feel > >>>>>>>>>> more comfortable with spring-dm just go ahead, If > >>>> someone feels that > >>>>>>>>>> blueprint is the way to go later, he could just > >>>> contribute a patch.. > >>>>>>>>>> > >>>>>>>>>> Bye, > >>>>>>>>>> Norman > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 2010/2/28 Martin Reisenhofer <mar...@meinstein.at>: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> It is so hard today there are so many > >>>> standards/libraries for the same > >>>>>>>>>>> thing > >>>>>>>>>>> ( see about java logging) , everything has advantages > >>>> was the other > >>>>>>>>>>> not > >>>>>>>>>>> has > >>>>>>>>>>> and vice versa. You are right, the ideal way is it to > >>>> implement james > >>>>>>>>>>> osgi > >>>>>>>>>>> support based on blueprint because it is a standard, > >>>> but the ideal way > >>>>>>>>>>> is > >>>>>>>>>>> not ever the way which was gone ( the old example VHS > >>>> and VIDEO2000 ). > >>>>>>>>>>> At > >>>>>>>>>>> now i am not familiar with blueprint, but i don't > >>>> want ignore this > >>>>>>>>>>> good > >>>>>>>>>>> standard, i try to do my best to find a solution. I > >>>> will you inform > >>>>>>>>>>> about my > >>>>>>>>>>> steps of implementing. > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> > >>>>>>>>>>> Martin > >>>>>>>>>>> > >>>>>>>>>>> Am 27.02.2010 21:42, schrieb David Jencks: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> On Feb 27, 2010, at 12:02 PM, Martin Reisenhofer wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Dear David, > >>>>>>>>>>>>> > >>>>>>>>>>>>> blueprint is similar to spring-dm, and also > >> supported by the > >>>>>>>>>>>>> spring-dm > >>>>>>>>>>>>> server. But spring configuration for now has more > >>>> features than > >>>>>>>>>>>>> blueprint. > >>>>>>>>>>>>> Why do you prefer blueprint instead of spring-dm? > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> Blueprint is a standard and gives you a choice of > >>>> platfoms to run on, > >>>>>>>>>>>> such > >>>>>>>>>>>> as apache aries. I'm not familiar with the features > >>>> in spring-dm > >>>>>>>>>>>> that > >>>>>>>>>>>> are > >>>>>>>>>>>> missing from blueprint: if they aren't too important > >>>> for james, I > >>>>>>>>>>>> think > >>>>>>>>>>>> using the standard would be worthwhile. > >>>>>>>>>>>> > >>>>>>>>>>>> From another point of view, my understanding is > that Spring > >>>>>>>>>>>> positioned > >>>>>>>>>>>> blueprint as the better, standardized version of > >>>> spring-dm. If it > >>>>>>>>>>>> isn't, > >>>>>>>>>>>> better to find out now and start trying to fix the > >>>> blueprint spec. > >>>>>>>>>>>> > >>>>>>>>>>>> thanks > >>>>>>>>>>>> david jencks > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> thanks > >>>>>>>>>>>>> > >>>>>>>>>>>>> Martin > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I watched out now the blueprint. The first i see, > >>>>>>>>>>>>> I am also agree that xbean-bluepring is great, > but the are > >>>>>>>>>>>>> > >>>>>>>>>>>>> David Jencks wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> I still think that if you are going to go to the > >>>> work of making > >>>>>>>>>>>>>> james > >>>>>>>>>>>>>> run well under osgi then it is worth the small > >>>> additional work of > >>>>>>>>>>>>>> using > >>>>>>>>>>>>>> blueprint instead of spring-dm so as to not be > tied to a > >>>>>>>>>>>>>> proprietary > >>>>>>>>>>>>>> api. I > >>>>>>>>>>>>>> got activemq running under xbean-blueprint and > >> it basically > >>>>>>>>>>>>>> consisted > >>>>>>>>>>>>>> of > >>>>>>>>>>>>>> removing some unneeded use of obsolete spring > >>>> lifecycle interfaces > >>>>>>>>>>>>>> from a > >>>>>>>>>>>>>> few classes and making sure the spring-isms needed > >>>> for startup in > >>>>>>>>>>>>>> spring > >>>>>>>>>>>>>> were in a few classes not needed in blueprint. > >>>> Translating a plan > >>>>>>>>>>>>>> from > >>>>>>>>>>>>>> spring to blueprint is pretty easy, there are > >>>> basically just a few > >>>>>>>>>>>>>> element > >>>>>>>>>>>>>> name changes. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I think xbean-blueprint is great but I know not > >>>> everyone agrees and > >>>>>>>>>>>>>> it > >>>>>>>>>>>>>> is certainly experimental at this point. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> thanks > >>>>>>>>>>>>>> david jencks > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Feb 27, 2010, at 10:33 AM, Norman Maurer wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> we are talkin about spring-dm (the modules) not the > >>>>>>>>>>>>>>> spring-dm-server. > >>>>>>>>>>>>>>> I just think using spring-dm is the easiest way > >>>> cause we already > >>>>>>>>>>>>>>> use > >>>>>>>>>>>>>>> spring for DI. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Bye, > >>>>>>>>>>>>>>> Norman > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 2010/2/27 David Jencks <david_jen...@yahoo.com>: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I'd suggest using blueprint rather than > >>>> spring-dm as it is a > >>>>>>>>>>>>>>>> standard. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> If you want to poke into experimental territory > >>>> you could try > >>>>>>>>>>>>>>>> xbean-blueprint which, although it currently > >>>> only works with > >>>>>>>>>>>>>>>> aries' > >>>>>>>>>>>>>>>> blueprint implementation lets you use a schema > >>>> adapted to the > >>>>>>>>>>>>>>>> beans > >>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>> configuration. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> thanks > >>>>>>>>>>>>>>>> david jencks > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Feb 27, 2010, at 9:21 AM, Martin > Reisenhofer wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Dear Norman, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks for the answer, i have cycles to > >>>> integrate james with > >>>>>>>>>>>>>>>>> spring-dm, > >>>>>>>>>>>>>>>>> after i finished i publish the sources. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Best Regards > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Martin > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Norman Maurer wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Hi Martin, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> we using spring as container in current trunk. > >>>> (development > >>>>>>>>>>>>>>>>>> version). > >>>>>>>>>>>>>>>>>> I would love to see some osgi deployment too > >>>> (using spring-dm) > >>>>>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>> noone had the cycles yet to implement it. > >>>> Contributions are > >>>>>>>>>>>>>>>>>> welcome > >>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>> course :) > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Bye, > >>>>>>>>>>>>>>>>>> Norman > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 2010/2/27 Martin Reisenhofer <mar...@meinstein.at>: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Dear James development Team, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> there are plans to makes james based on > >>>> spring and osgi in > >>>>>>>>>>>>>>>>>>> future? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: > >>>>>>>>>>>>>>>>>>> server-dev-unsubscr...@james.apache.org > >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: > >>>>>>>>>>>>>>>>>>> server-dev-h...@james.apache.org > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: > >>>> server-dev-unsubscr...@james.apache.org > >>>>>>>>>>>>>>>>>> For additional commands, e-mail: > >>>>>>>>>>>>>>>>>> server-dev-h...@james.apache.org > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: > >>>> server-dev-unsubscr...@james.apache.org > >>>>>>>>>>>>>>>>> For additional commands, e-mail: > >>>>>>>>>>>>>>>>> server-dev-h...@james.apache.org > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>>>>>>>>> To unsubscribe, e-mail: > >>>> server-dev-unsubscr...@james.apache.org > >>>>>>>>>>>>>>>> For additional commands, e-mail: > >>>> server-dev-h...@james.apache.org > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>>>>>>>> To unsubscribe, e-mail: > >>>> server-dev-unsubscr...@james.apache.org > >>>>>>>>>>>>>>> For additional commands, e-mail: > >>>> server-dev-h...@james.apache.org > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>>>>>>> To unsubscribe, e-mail: > >>>> server-dev-unsubscr...@james.apache.org > >>>>>>>>>>>>>> For additional commands, e-mail: > >>>> server-dev-h...@james.apache.org > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>>>>>> To unsubscribe, e-mail: > >>>> server-dev-unsubscr...@james.apache.org > >>>>>>>>>>>>> For additional commands, e-mail: > >>>> server-dev-h...@james.apache.org > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>>>>> To unsubscribe, e-mail: > >>>> server-dev-unsubscr...@james.apache.org > >>>>>>>>>>>> For additional commands, e-mail: > >>>> server-dev-h...@james.apache.org > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>>>> To unsubscribe, e-mail: > >>>> server-dev-unsubscr...@james.apache.org > >>>>>>>>>>> For additional commands, e-mail: > >>>> server-dev-h...@james.apache.org > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>>>> To unsubscribe, e-mail: > >> server-dev-unsubscr...@james.apache.org > >>>>>>>>> For additional commands, e-mail: > >>>> server-dev-h...@james.apache.org > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> -- > >>>>>>>> Martin Reisenhofer > >>>>>>>> Unterrohr 10 > >>>>>>>> 8294 Rohr bei Hartberg > >>>>>>>> Austria > >>>>>>>> > >>>>>>>> Tel +43 (0) 664 101 44 65 > >>>>>>>> Mail mar...@meinstein.at > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: > server-dev-unsubscr...@james.apache.org > >>>>>>> For additional commands, e-mail: > >> server-dev-h...@james.apache.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> -- > >>>>>> Martin Reisenhofer > >>>>>> Unterrohr 10 > >>>>>> 8294 Rohr bei Hartberg > >>>>>> Austria > >>>>>> > >>>>>> Tel +43 (0) 664 101 44 65 > >>>>>> Mail mar...@meinstein.at > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >> > --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > >>>>> For additional commands, e-mail: > server-dev-h...@james.apache.org > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Martin Reisenhofer > >>>> Unterrohr 10 > >>>> 8294 Rohr bei Hartberg > >>>> Austria > >>>> > >>>> Tel +43 (0) 664 101 44 65 > >>>> Mail mar...@meinstein.at > >>>> > >>>> > >>> > >>> > >>> > >> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > >>> For additional commands, e-mail: server-dev-h...@james.apache.org > >>> > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > >> For additional commands, e-mail: server-dev-h...@james.apache.org > >> > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > > For additional commands, e-mail: server-dev-h...@james.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
