I can happily review a patch if you're fancy writing one... And I disagree with the 'blueprint is dead and nobody cares about it anymore'. What's dead is the blueprint osgi specification for blueprint, not the Aries Blueprint project. I've recently added a bunch of important features related to spring in blueprint.
DS also has some drawbacks as it's not extensible at all : this is leading the OSGi Alliance to write a new spec for transaction support !!! I think the CDI+DS extension I've been working on those past weeks could bring the best of both world : strong DS semantics for the OSGi bits, but extensibility and support for proxies provided by CDI ;-) 2016-07-12 17:24 GMT+02:00 Brad Johnson <[email protected]>: > David, > > I'm all for multilocation support in blueprint. Can't wait for it. But > it sounds like your saying blueprint is dead and nobody cares about it > anymore so it doesn't seem likely to happen anytime soon. It certainly > wouldn't be relevant to Fuse which uses R4 in any case. > > On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson < > [email protected]> wrote: > >> The features file can have statements like this: >> >> >> <configfile finalname="/etc/com.foo.cfg" >> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile> >> <configfile finalname="/etc/com.bar.cfg" >> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile> >> ....etc.... >> That's off the top of my head so take it with a grain of salt for syntax. >> >> When you run the features install it will overwrite the files in the etc >> directory with the ones in the maven bundle which have now been updated. So >> instead of modifying configuration files in the etc directory you modifying >> them in your Maven configuration project and recompile the bundle and then >> pull it from the repo >> in order to update the values. >> >> But you can still modify them in the etc if you wanted. You just have to >> make sure you have the cm properties set to reload. >> >> <cm:property-placeholder persistent-id="com.foo" update-strategy="reload"> >> >> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez < >> [email protected]> wrote: >> >>> Brad, if I understand your approach too that would lead to not being >>> able to dynamically change common properties in a single config place >>> during runtime, as the fill made by maven would be only done once at build >>> time right? But at runtime I would need to that as David mention, still n >>> times right? >>> >>> as a use case for instance, with blueprint:cm update-strategy configured >>> as 'reload' in combination with felix-fileinstall as directory watcher, >>> bundles are reloaded automatically so that when I modify at anytime during >>> runtime a property e.g with just a text editor the bundle is initiated >>> again with the new property values which is a quite nice feature >>> >>> best >>> >>> Pablo >>> >>> On 12/07/2016 12:31 AM, David Jencks wrote: >>> >>> I’d like to make sure I understand what you are doing here…. IIUC >>> during the build of your project you are generating multiple configuration >>> files with the same or similar content, and each of these is loaded into a >>> configuration which is bound to a particular bundle location? So, at build >>> time you can change all the duplicate properties at once but if you need to >>> change them later you have to alter n (== number of duplicate configs) >>> independently? Whereas if you had multi-location support (and possibly >>> multi-pid support such as DS provides) you could share a single >>> Configuration and change the property while the framework was running in >>> one place? >>> >>> thanks >>> david jencks >>> >>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <[email protected]> >>> wrote: >>> >>> Pablo, >>> >>> One possible solution to this problem that I'm currently looking at is >>> using a configuration bundle along with my features bundle. In the >>> configuration bundle I have all the cfg files and use properties >>> placeholders ${value} to set the value for key/value. >>> >>> In the POM I load properties files using the Maven properties plugin and >>> that lets me set a global set of properties values that can be used in >>> filling in the cfg values. So if a port or URI is shared across a large >>> number of them that automatically gets filled in. The features file can >>> then specify the cfg files to install and what name to install them with. >>> >>> This gets rid of a lot of tedium and by using profiles I should be able >>> to switch dev, test and production, and have the properties automatically >>> set correctly. >>> >>> I'd like to modify this a bit so that dev, test and product cfg files >>> are all created simultaneously and simply installed in different >>> directories inside the configuration bundle. Then by using different >>> features installs I can easily switch between the different configurations >>> without having to tediously edit each configuration file. >>> >>> Brad >>> >>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <[email protected]> wrote: >>> >>>> Does Camel/Fuse even support DS? I haven't found any documentation >>>> saying otherwise. I've only found camel-scr which uses Felix-specific >>>> annotations and not DS. >>>> >>>> On 7 July 2016 at 14:32, Brad Johnson <[email protected]> >>>> wrote: >>>> >>>>> David, >>>>> >>>>> That is some pretty extreme and wild speculation alright. How does >>>>> one use blueprint to not use OSGi appropriately? In the 5 years I've been >>>>> consulting with Fuse/Karaf/OSGi and going to various clients not one of >>>>> them used or uses DS. Not one. They all use bundles, services, and Camel >>>>> with blueprint. The last time I worked with DS I didn't find it provided >>>>> any serious advantage and added another layer that I'd have to teach my >>>>> clients. Not that I wouldn't consider it or use it if I found a real >>>>> advantage but I haven't. >>>>> >>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi >>>>> 4.x land much less 5 or 6. >>>>> >>>>> So for Camel are you using the Java DSL? >>>>> >>>>> Brad >>>>> >>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <[email protected]> >>>>> wrote: >>>>> >>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look at >>>>>> the osgi R5 or R6 config admin spec for “multi location”. >>>>>> >>>>>> You guys might be using blueprint every day, but there is no OSGI >>>>>> spec work to keep it up to date or even specify obviously necessary >>>>>> features such as config admin integration. If blueprint is so great why >>>>>> aren’t the proponents keeping the spec related to current OSGI? This is >>>>>> a >>>>>> part of my, admittedly extreme, theory that use of blueprint is related >>>>>> to >>>>>> not wanting to make the app actually use osgi appropriately. >>>>>> >>>>>> And, the project I work on every day uses DS exclusively and still >>>>>> finds plenty of ways to abuse osgi in all sorts of inventive ways :-) >>>>>> >>>>>> david jencks >>>>>> >>>>>> >>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <[email protected]> wrote: >>>>>> >>>>>> It is in here; >>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html >>>>>> >>>>>> A bundle is in aries bound to the pid. So it is actually working as >>>>>> expected, bit of >>>>>> a hassle since spring-dm allowed it. >>>>>> >>>>>> And yes selling DS into “regular" organizations is about as easy as >>>>>> selling snow in Alaska. >>>>>> >>>>>> /je >>>>>> >>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson < >>>>>> [email protected]> wrote: >>>>>> >>>>>> David, >>>>>> >>>>>> You live in a very different world than I do. In all the consulting >>>>>> I do with Fuse/karaf blueprint is used almost exclusively. I understand >>>>>> DS >>>>>> and its uses but also its limits and overhead. It's like telling me one >>>>>> should only use Camel Java DSL. That may be one's perspective but that >>>>>> isn't everyone's. >>>>>> >>>>>> Brad >>>>>> >>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> IMNSHO blueprint is only really plausible if you have a large amount >>>>>>> of Spring based code and you need to convert it to be sort of >>>>>>> osgi-compatible really quickly without understanding osgi or the code. >>>>>>> Otherwise taking the time to understand DS and use it is much more >>>>>>> satisfactory. DS provides this configuration override ability with >>>>>>> support >>>>>>> for multiple pids, although only one of the pids can turn out to be a >>>>>>> factory configuration. There’s no obvious way of correlating factory >>>>>>> configurations, so this restriction makes some sense. >>>>>>> >>>>>>> I don’t think there really are any blueprint folks. The cm stuff, >>>>>>> while obviously required to make the spec remotely plausible, hasn’t >>>>>>> made >>>>>>> it into the spec in the many many years it’s been sitting around. >>>>>>> >>>>>>> david jencks >>>>>>> >>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> If I were to sit down with the blueprint folks today to create a >>>>>>> wish list one thing I'd like to see is for an ability to have a >>>>>>> configuration hierarchy specified with parent/child relationships much >>>>>>> like >>>>>>> one has in Maven. Have a base configuration file and be able to have >>>>>>> another cfg file specify that one as its parent. Override properties or >>>>>>> add >>>>>>> them to the child. When the configuration admin fires up it would read >>>>>>> up >>>>>>> the chain and construct the properties. >>>>>>> >>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Ray, >>>>>>>> >>>>>>>> If I understand your question right the answer is the Aries >>>>>>>> extension is referencing configuration. In karaf/fuse for example the >>>>>>>> following: >>>>>>>> >>>>>>>> <cm:property-placeholder persistent-id="com.my.foo" >>>>>>>> update-strategy="reload"> >>>>>>>> >>>>>>>> will load properties from etc/com.my.foo.cfg >>>>>>>> >>>>>>>> Installing that file is done either manually or by use of a >>>>>>>> features file. >>>>>>>> >>>>>>>> Whenever I've attempted to use the PID in more than one bundle it >>>>>>>> has failed and I don't think it is permitted. That's a problem I >>>>>>>> think and >>>>>>>> something that should be fixed through some other configuration >>>>>>>> management >>>>>>>> mechanism. Making microservices that might share common properties, >>>>>>>> for >>>>>>>> example, becomes problematic in that regard and I've resorted to using >>>>>>>> my >>>>>>>> own OSGi services to overcome that problem. >>>>>>>> >>>>>>>> Brad >>>>>>>> >>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Ok, so after a brief review the cm schema is an Aries extension >>>>>>>>> and it doesn't appear to support the location binding. >>>>>>>>> >>>>>>>>> However, it's unclear to me whether this extension is creating the >>>>>>>>> configuration or merely referencing one from outside. >>>>>>>>> >>>>>>>>> Any Aries gurus can answer that? >>>>>>>>> >>>>>>>>> - Ray >>>>>>>>> >>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect that to >>>>>>>>>> indicate which pid to use to fetch the config from config admin and >>>>>>>>>> in the >>>>>>>>>> ... how to map configuration propertiething blueprint substitution >>>>>>>>>> knows >>>>>>>>>> about. Is that really instructions to create a new configuration and >>>>>>>>>> populate it with data (what a management agent does)? >>>>>>>>>> >>>>>>>>>> david jencks >>>>>>>>>> >>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>> David, I agree with everything you've said, however this looks >>>>>>>>>> like blueprint being the agent here: >>>>>>>>>> >>>>>>>>>> <cm:property-placeholder persistent-id="my.id" >>>>>>>>>> update-strategy="reload"> >>>>>>>>>> ... >>>>>>>>>> </cm:property-placeholder> >>>>>>>>>> >>>>>>>>>> - Ray >>>>>>>>>> >>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> No, blueprint cm shouldn’t really know about the >>>>>>>>>>> multi-location. The management agent that is creating the >>>>>>>>>>> configuration >>>>>>>>>>> should be setting the bundle location to the multi-location ”?”. >>>>>>>>>>> >>>>>>>>>>> david jencks >>>>>>>>>>> >>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> I see and would it possible to configure which method is invoked >>>>>>>>>>> from Blueprint? >>>>>>>>>>> >>>>>>>>>>> This is how I do it: >>>>>>>>>>> >>>>>>>>>>> <cm:property-placeholder persistent-id="my.id" >>>>>>>>>>> update-strategy="reload"> >>>>>>>>>>> ... >>>>>>>>>>> </cm:property-placeholder> >>>>>>>>>>> >>>>>>>>>>> is there perhaps some blueprint property where I can tune the >>>>>>>>>>> second argument in the createFactoryConfiguration? >>>>>>>>>>> >>>>>>>>>>> Because it looks like the fact of using config admin through >>>>>>>>>>> blueprint binds the PID to the first bundle using it >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> best >>>>>>>>>>> Pablo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote: >>>>>>>>>>> >>>>>>>>>>> As long as configurations are not bound to a bundle they can be >>>>>>>>>>> used by any bundle. >>>>>>>>>>> >>>>>>>>>>> The exception clearly shows that the configuration is bound to a >>>>>>>>>>> bundle. >>>>>>>>>>> >>>>>>>>>>> Creating an unbound configuration requires passing a "?" as the >>>>>>>>>>> second arguments to getConfiguration/createFactoryConfiguration >>>>>>>>>>> methods of >>>>>>>>>>> CM. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> HTH, >>>>>>>>>>> - Ray >>>>>>>>>>> >>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> I don't think that's possible. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello All, >>>>>>>>>>>>> >>>>>>>>>>>>> Is it possible to use same config file from multiple >>>>>>>>>>>>> bundles while using Config Admin with blueprint Blueprint? >>>>>>>>>>>>> Because, I can't >>>>>>>>>>>>> manage to do that, I get the following error: >>>>>>>>>>>>> >>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [ >>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214, >>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility >>>>>>>>>>>>> to configuration bound to initial@reference:file:../plugin-2/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I saw in this jira a bug opened: >>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> However, I fear that this is a problem in the aries blueprint >>>>>>>>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi >>>>>>>>>>>>> container. Either that or I'm missing some blueprint >>>>>>>>>>>>> configuration. I'm >>>>>>>>>>>>> basically using blueprint:cm >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> As a workaround I can make a config file per bundle that needs >>>>>>>>>>>>> it.... >>>>>>>>>>>>> >>>>>>>>>>>>> As follows the versions and bundles that I'm using related to >>>>>>>>>>>>> the container (Running on top of Equinox 3.11): >>>>>>>>>>>>> >>>>>>>>>>>>> ID|State |Level|Name >>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for >>>>>>>>>>>>> JMX DynamicMBean services (1.1.5)|1.1.5 >>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2 >>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology >>>>>>>>>>>>> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT >>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2 >>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0 >>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery >>>>>>>>>>>>> Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT >>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7 >>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core >>>>>>>>>>>>> (1.1.5)|1.1.5 >>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler >>>>>>>>>>>>> (1.1.0)|1.1.0 >>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5 >>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core >>>>>>>>>>>>> (1.5.0)|1.5.0 >>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core >>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0 >>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1 >>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts >>>>>>>>>>>>> (1.0.4)|1.0.4 >>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1 >>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service >>>>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT >>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint >>>>>>>>>>>>> (1.1.1)|1.1.1 >>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2 >>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy >>>>>>>>>>>>> Runtimes (1.0.0)|1.0.0 >>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API >>>>>>>>>>>>> (1.1.5)|1.1.5 >>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager >>>>>>>>>>>>> (1.3.0)|1.3.0 >>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery >>>>>>>>>>>>> Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT >>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider >>>>>>>>>>>>> TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT >>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API >>>>>>>>>>>>> (1.0.1)|1.0.1 >>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint >>>>>>>>>>>>> (2.1.0)|2.1.0 >>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5 >>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl >>>>>>>>>>>>> (1.0.1)|1.0.1 >>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery >>>>>>>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT >>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery >>>>>>>>>>>>> Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT >>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core >>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT >>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler >>>>>>>>>>>>> (1.0.0)|1.0.0 >>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service >>>>>>>>>>>>> (1.0.4)|1.0.4 >>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving >>>>>>>>>>>>> Bundle (1.0.8)|1.0.8 >>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint >>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4 >>>>>>>>>>>>> >>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4 >>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0 >>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command >>>>>>>>>>>>> (0.16.0)|0.16.0 >>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service >>>>>>>>>>>>> (1.0.2)|1.0.2 >>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime >>>>>>>>>>>>> (0.16.2)|0.16.2 >>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console >>>>>>>>>>>>> (1.2.8)|1.2.8 >>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin >>>>>>>>>>>>> Service (1.8.8)|1.8.8 >>>>>>>>>>>>> >>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle >>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The >>>>>>>>>>>>> recipient should check this email and any attachments for the >>>>>>>>>>>>> presence of >>>>>>>>>>>>> viruses. The company accepts no liability for any damage caused >>>>>>>>>>>>> by any >>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be >>>>>>>>>>>>> guaranteed >>>>>>>>>>>>> to be secure or error-free as information could be intercepted, >>>>>>>>>>>>> corrupted, >>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. >>>>>>>>>>>>> The sender >>>>>>>>>>>>> therefore does not accept liability for any errors or omissions >>>>>>>>>>>>> in the >>>>>>>>>>>>> contents of this message, which arise as a result of e-mail >>>>>>>>>>>>> transmission. >>>>>>>>>>>>> >>>>>>>>>>>>> Warning: Although the company has taken reasonable precautions >>>>>>>>>>>>> to ensure no viruses are present in this email, the company >>>>>>>>>>>>> cannot accept >>>>>>>>>>>>> responsibility for any loss or damage arising from the use of >>>>>>>>>>>>> this email or >>>>>>>>>>>>> attachments. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>>>>>>> (@rotty3000) >>>>>>>>>>> Senior Software Architect *Liferay, Inc.* >>>>>>>>>>> <http://www.liferay.com/> (@Liferay) >>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> >>>>>>>>>>> (@OSGiAlliance) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>>>>>> (@rotty3000) >>>>>>>>>> Senior Software Architect *Liferay, Inc.* >>>>>>>>>> <http://www.liferay.com/> (@Liferay) >>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> >>>>>>>>>> (@OSGiAlliance) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>>>>> (@rotty3000) >>>>>>>>> Senior Software Architect *Liferay, Inc.* >>>>>>>>> <http://www.liferay.com/> (@Liferay) >>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> >>>>>>>>> (@OSGiAlliance) >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Matt Sicker <[email protected]> >>>> >>> >>> >>> >>> >> > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
