On Mon, May 12, 2008 at 3:03 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > > On Mon, May 12, 2008 at 11:30 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > > > > Robert Burrell Donkin ha scritto: > > > > > > > > > > > > > > > > hopefully we'll see some JAMES libraries released this month or next. > > > > i've been wondering whether we should investigate including OSGi > > > > meta-data so that our libraries are OSGi-enabled out of the box. > > > > > > > > > > > > (http://www.google.co.uk/search?hl=en&q=commons+osgi&btnG=Google+Search&meta= > > > > > > > for reasons to OSGi enable) > > > > > > > > opinions? > > > > > > > > > > > it is a good to have thing, not a big priority because no one asked for > > > them yet. > > > > > > > i've been staring very hard at coupling in the mailet code recently > > and wondering about mechanisms for configuring and installing mailets > > > > There are probably many "levels" of OSGi support: > 1) Create a single bundle for the whole JAMES Server > 2) Create one bundle for each function > 3) Create one bundle for each library > 4) Create one bundle for each module
AIUI libraries used by OSGi require appropriate MANIFEST entries on a per jar basis > IMHO the really needed things would be to be able to undeploy the whole > spoolmanager (and by result all the processors/mailets) and redeploy an > updated version. In the mean times JAMES would be fully working because the > incoming channel do not block (because of the spool existence). So I think > the "level" that will bring us more advantages with less work in #2. Of > course #4 would be good, but it won't add too much to #2. #1 alone does not > give many advantages over what we already do with current standalone james. > > I don't really know how complex would be to create a single bundle for each > of our functions and then to have an OSGi-deployment that do something > similar to the spring-deployment method (by emulating an avalon container > for OSGi). > > I read something about OSGi and if IIRC OSGi would be very unhappy when the > same package exists in 2 different bundles, and we know we have a bit of > chaos about packages. Is this a blocker? OSGi does indeed forwn upon this i wasn't thinking of using OSGi to assemble the whole of JAMES ATM, just mailets. configuration is the main issues with mailets but i wonder whether the specification should really concern itself with configuration at all. i think JAMES would benefit from supporting new mailet loading engines. OSGi enabling our mailets would open up the possibility of using OSGi as a mailet loader. > > > It should be done by someone with OSGi knowledge in order to avoid > > > releasing artifacts with wrong/bad metadata. > > > > > > > maybe some people from felix would volunteer to help out > > > > This would be cool! Do you think there is someone interested in james in > the felix community? the felix community are sometimes interested in OSGi enabling libraries and may be willing to help us enable ours - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
