For what it’s worth, I’ve long had in the back of my mind an idea to develop a DS diagnostic command that could try to work out for you exactly why a DS component is inactive.
For example it could look at the Configuration Policy and then the set of available PIDs in Config Admin and report that the configuration seems to be missing. Or it could notice unsatisfied service references, and follow those to some other component that should provide the service but is inactive… and so on, down the chain. Of course this would not work with services that are published programmatically but it would still provide a lot of useful information. It wouldn’t even be too hard to code this, given the existence of ScrService for introspection. Neil > On 3 Dec 2015, at 18:06, Raymond Auge <raymond.a...@liferay.com> wrote: > > On Thu, Dec 3, 2015 at 12:59 PM, David Jencks <david.a.jen...@gmail.com> > wrote: > >> Since the Component Configuration: header appears for each component >> configuration, I might prefer >> … >> (No Component Configuration) >> >> I think I’d leave this out when the component is disabled as an additional >> clue about the state. >> >> WDYT? >> > > I'd be totally cool with that! > > - Ray > > >> >> thanks >> david jencks >> >>> On Dec 3, 2015, at 9:50 AM, Raymond Auge <raymond.a...@liferay.com> >> wrote: >>> >>> On Thu, Dec 3, 2015 at 12:31 PM, David Jencks <david.a.jen...@gmail.com >> <mailto:david.a.jen...@gmail.com>> >>> wrote: >>> >>>> well, to me it did state that quite plainly: >>>> >>>>>>>> Configuration Policy: require >>>> >>> >>> >>> but that's not showing that it's "waiting" for something... only that one >>> is required... Does it have any right now? >>> >>> In your configuration list maybe all you need is: >>> >>> ----------------- >>> ... >>> Configuration Policy: require >>> ... >>> Component Configuration: none >>> ----------------- >>> >>> That's not redundant. >>> >>> It's a) indicating that it does indeed need something before it does >>> anything b) it doesn't have anything right now. >>> >>> I'd be totally satisfied with that. At least it would allow for a quick >>> scan of the output to observe that it's just not configured!! >>> >>> >>> >>>> I look forward to your suggestions. >>>> >>>> thanks >>>> david jencks >>>> >>>>> On Dec 3, 2015, at 9:12 AM, Raymond Auge <raymond.a...@liferay.com> >>>> wrote: >>>>> >>>>> The point is that it took me and a technical support person about 15 >>>>> minutes to figure out (this is not a module I wrote) why the component >>>>> wasn't "activating". >>>>> >>>>> If scr:info had inferred that "hey, this thing won't do anything until >> it >>>>> receives at least ONE configuration" it would have really helped us, >> and >>>> I >>>>> would have had more encouraging response than ... I guess you need to >>>> infer >>>>> from the obscure messaging that it's in a "waiting" state. >>>>> >>>>> I'll see what I can come up with. >>>>> >>>>> - Ray >>>>> >>>>> On Thu, Dec 3, 2015 at 11:56 AM, David Jencks < >> david.a.jen...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi Ray, >>>>>> >>>>>> You are confusing a lot of terms :-) >>>>>> >>>>>> “enabled” is a component description state. If the component is >>>> disabled, >>>>>> whether there are CA configurations for it and required dependencies >>>>>> present or missing is completely irrelevant because DS isn’t even >>>> looking >>>>>> at that yet. >>>>>> >>>>>> Once the component is enabled, then there’s a chance that you might >> bet >>>>>> one or more instances of the component….. component configurations, >> not >>>> to >>>>>> be confused with CA configurations. >>>>>> >>>>>> Depending on the configuration policy…. >>>>>> ignored >> one component configuration. This will be satisfied if all >>>> the >>>>>> required references are satisfied and result in (one or more) >> instances >>>>>> depending on the scope, immediate setting, and whether there are any >>>> users >>>>>> of the exposed service (if any) >>>>>> >>>>>> optionsl >> one or more component configurations depending on CA >>>>>> configurations. Each one will be satisfied or not depending on it’s >>>>>> references, and again instances depend on scope, etc etc. You can see >>>>>> whether the one configuration is configured from CA by looking at the >>>>>> properties for a pid/factory pid. >>>>>> >>>>>> required >> 0 or more component configurations, one per CA >>>> configuration. >>>>>> Each one will be satisfied or not depending on its references etc etc. >>>>>> >>>>>> So, there are a lot of moving parts here. I’m not sure it’s practical >>>> to >>>>>> explain the entire DS model in the output of scr:info, which I think >> is >>>>>> what you’re aiming for. However I’m happy to consider suggestions >> that >>>> are >>>>>> actually in line with the model. I haven’t been able to figure out >>>>>> improvements to what is there that actually seem to me to provide more >>>>>> information without being very redundant and more confusing. Maybe >> you >>>>>> will have better luck. >>>>>> >>>>>> thanks >>>>>> david jencks >>>>>> >>>>>>> On Dec 3, 2015, at 8:19 AM, Raymond Auge <raymond.a...@liferay.com> >>>>>> wrote: >>>>>>> >>>>>>> Furthermore in looking at the >>>>>>> >>>>>>> scr:list | grep <component_name> >>>>>>> >>>>>>> it produces >>>>>>> >>>>>>> [com.liferay.portal.http.tunnel.extender.HttpTunnelExtender] [ 60] >>>>>> [true] >>>>>>> >>>>>>> which seems to indicate that it's enabled... which it's not really. >>>>>>> >>>>>>> - Ray >>>>>>> >>>>>>> On Thu, Dec 3, 2015 at 11:10 AM, Raymond Auge < >>>> raymond.a...@liferay.com> >>>>>>> wrote: >>>>>>> >>>>>>>> The point is that if you start with no configuration, and you view >> the >>>>>>>> component scr:info it's hard for a less knowledgeable person to >>>>>> recognize >>>>>>>> that it's missing a configuration? >>>>>>>> >>>>>>>> I would hope to see something like this: >>>>>>>> >>>>>>>> -------------------------------- >>>>>>>> g! scr:info >> com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>> *** Bundle: com.liferay.portal.http.tunnel.extender (60) >>>>>>>> Component Description: >>>>>>>> Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>> Default State: enabled >>>>>>>> Activation: immediate >>>>>>>> Configuration Policy: require >>>>>>>> Activate Method: activate >>>>>>>> Deactivate Method: deactivate >>>>>>>> Modified Method: modified >>>>>>>> Configuration Pid: >>>>>>>> >>>>>> >>>> >> [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] >>>>>>>> Services: Service Scope: null >>>>>>>> Properties: >>>>>>>> Component Configuration: >>>>>>>> State: missing >>>>>>>> g! >>>>>>>> -------------------------------- >>>>>>>> >>>>>>>> make sense now? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 3, 2015 at 11:03 AM, David Jencks < >>>> david.a.jen...@gmail.com >>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> It looks pretty blatant to me that the reason there are no >> component >>>>>>>>> configurations is that there is no CA configuration. What kind of >>>>>>>>> notification do you want? >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> david jencks >>>>>>>>> >>>>>>>>>> On Dec 3, 2015, at 7:57 AM, Raymond Auge < >> raymond.a...@liferay.com> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hey all, >>>>>>>>>> >>>>>>>>>> It seems that scr:info report is not clearly indicating when a >>>>>> required >>>>>>>>>> configuration is not available. It is showing good info when the >>>>>>>>> component >>>>>>>>>> has a configuration: >>>>>>>>>> >>>>>>>>>> Here is the report WITH required configuration: >>>>>>>>>> ---------------------------------- >>>>>>>>>> g! scr:info >>>> com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> *** Bundle: com.liferay.portal.http.tunnel.extender (60) >>>>>>>>>> Component Description: >>>>>>>>>> Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> Default State: enabled >>>>>>>>>> Activation: immediate >>>>>>>>>> Configuration Policy: require >>>>>>>>>> Activate Method: activate >>>>>>>>>> Deactivate Method: deactivate >>>>>>>>>> Modified Method: modified >>>>>>>>>> Configuration Pid: >>>>>>>>>> >>>>>>>>> >>>>>> >>>> >> [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] >>>>>>>>>> Services: Service Scope: null >>>>>>>>>> Properties: >>>>>>>>>> Component Configuration: >>>>>>>>>> ComponentId: 1936 >>>>>>>>>> State: active >>>>>>>>>> Properties: >>>>>>>>>> component.id = 1936 >>>>>>>>>> component.name = >>>>>>>>>> com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> hostsAllowed = [127.0.0.1] >>>>>>>>>> service.pid = >>>>>>>>>> >>>>>>>>> >>>>>> >>>> >> com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration >>>>>>>>>> g! >>>>>>>>>> ---------------------------------- >>>>>>>>>> >>>>>>>>>> And here is the report when NO required configuration is >> available: >>>>>>>>>> >>>>>>>>>> ---------------------------------- >>>>>>>>>> g! scr:info >>>> com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> *** Bundle: com.liferay.portal.http.tunnel.extender (60) >>>>>>>>>> Component Description: >>>>>>>>>> Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> Default State: enabled >>>>>>>>>> Activation: immediate >>>>>>>>>> Configuration Policy: require >>>>>>>>>> Activate Method: activate >>>>>>>>>> Deactivate Method: deactivate >>>>>>>>>> Modified Method: modified >>>>>>>>>> Configuration Pid: >>>>>>>>>> >>>>>>>>> >>>>>> >>>> >> [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] >>>>>>>>>> Services: Service Scope: null >>>>>>>>>> Properties: >>>>>>>>>> g! >>>>>>>>>> ---------------------------------- >>>>>>>>>> >>>>>>>>>> As you can see it's not clear at all that the component is missing >>>> the >>>>>>>>>> configuration it requires. >>>>>>>>>> >>>>>>>>>> Can we fix this? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *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) >>>>>>>>> >>>>>>>>> >>>>>>>>> >> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *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) >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *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) >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org <mailto: >> users-unsubscr...@felix.apache.org> >>>> For additional commands, e-mail: users-h...@felix.apache.org <mailto: >> users-h...@felix.apache.org> >>>> >>>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile < >> http://www.liferay.com/web/raymond.auge/profile>> >>> (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com < >> http://www.liferay.com/>> >>> (@Liferay) >>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org < >> 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) > > On Thu, Dec 3, 2015 at 12:59 PM, David Jencks <david.a.jen...@gmail.com> > wrote: > >> Since the Component Configuration: header appears for each component >> configuration, I might prefer >> … >> (No Component Configuration) >> >> I think I’d leave this out when the component is disabled as an additional >> clue about the state. >> >> WDYT? >> >> thanks >> david jencks >> >>> On Dec 3, 2015, at 9:50 AM, Raymond Auge <raymond.a...@liferay.com> >> wrote: >>> >>> On Thu, Dec 3, 2015 at 12:31 PM, David Jencks <david.a.jen...@gmail.com >> <mailto:david.a.jen...@gmail.com>> >>> wrote: >>> >>>> well, to me it did state that quite plainly: >>>> >>>>>>>> Configuration Policy: require >>>> >>> >>> >>> but that's not showing that it's "waiting" for something... only that one >>> is required... Does it have any right now? >>> >>> In your configuration list maybe all you need is: >>> >>> ----------------- >>> ... >>> Configuration Policy: require >>> ... >>> Component Configuration: none >>> ----------------- >>> >>> That's not redundant. >>> >>> It's a) indicating that it does indeed need something before it does >>> anything b) it doesn't have anything right now. >>> >>> I'd be totally satisfied with that. At least it would allow for a quick >>> scan of the output to observe that it's just not configured!! >>> >>> >>> >>>> I look forward to your suggestions. >>>> >>>> thanks >>>> david jencks >>>> >>>>> On Dec 3, 2015, at 9:12 AM, Raymond Auge <raymond.a...@liferay.com> >>>> wrote: >>>>> >>>>> The point is that it took me and a technical support person about 15 >>>>> minutes to figure out (this is not a module I wrote) why the component >>>>> wasn't "activating". >>>>> >>>>> If scr:info had inferred that "hey, this thing won't do anything until >> it >>>>> receives at least ONE configuration" it would have really helped us, >> and >>>> I >>>>> would have had more encouraging response than ... I guess you need to >>>> infer >>>>> from the obscure messaging that it's in a "waiting" state. >>>>> >>>>> I'll see what I can come up with. >>>>> >>>>> - Ray >>>>> >>>>> On Thu, Dec 3, 2015 at 11:56 AM, David Jencks < >> david.a.jen...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi Ray, >>>>>> >>>>>> You are confusing a lot of terms :-) >>>>>> >>>>>> “enabled” is a component description state. If the component is >>>> disabled, >>>>>> whether there are CA configurations for it and required dependencies >>>>>> present or missing is completely irrelevant because DS isn’t even >>>> looking >>>>>> at that yet. >>>>>> >>>>>> Once the component is enabled, then there’s a chance that you might >> bet >>>>>> one or more instances of the component….. component configurations, >> not >>>> to >>>>>> be confused with CA configurations. >>>>>> >>>>>> Depending on the configuration policy…. >>>>>> ignored >> one component configuration. This will be satisfied if all >>>> the >>>>>> required references are satisfied and result in (one or more) >> instances >>>>>> depending on the scope, immediate setting, and whether there are any >>>> users >>>>>> of the exposed service (if any) >>>>>> >>>>>> optionsl >> one or more component configurations depending on CA >>>>>> configurations. Each one will be satisfied or not depending on it’s >>>>>> references, and again instances depend on scope, etc etc. You can see >>>>>> whether the one configuration is configured from CA by looking at the >>>>>> properties for a pid/factory pid. >>>>>> >>>>>> required >> 0 or more component configurations, one per CA >>>> configuration. >>>>>> Each one will be satisfied or not depending on its references etc etc. >>>>>> >>>>>> So, there are a lot of moving parts here. I’m not sure it’s practical >>>> to >>>>>> explain the entire DS model in the output of scr:info, which I think >> is >>>>>> what you’re aiming for. However I’m happy to consider suggestions >> that >>>> are >>>>>> actually in line with the model. I haven’t been able to figure out >>>>>> improvements to what is there that actually seem to me to provide more >>>>>> information without being very redundant and more confusing. Maybe >> you >>>>>> will have better luck. >>>>>> >>>>>> thanks >>>>>> david jencks >>>>>> >>>>>>> On Dec 3, 2015, at 8:19 AM, Raymond Auge <raymond.a...@liferay.com> >>>>>> wrote: >>>>>>> >>>>>>> Furthermore in looking at the >>>>>>> >>>>>>> scr:list | grep <component_name> >>>>>>> >>>>>>> it produces >>>>>>> >>>>>>> [com.liferay.portal.http.tunnel.extender.HttpTunnelExtender] [ 60] >>>>>> [true] >>>>>>> >>>>>>> which seems to indicate that it's enabled... which it's not really. >>>>>>> >>>>>>> - Ray >>>>>>> >>>>>>> On Thu, Dec 3, 2015 at 11:10 AM, Raymond Auge < >>>> raymond.a...@liferay.com> >>>>>>> wrote: >>>>>>> >>>>>>>> The point is that if you start with no configuration, and you view >> the >>>>>>>> component scr:info it's hard for a less knowledgeable person to >>>>>> recognize >>>>>>>> that it's missing a configuration? >>>>>>>> >>>>>>>> I would hope to see something like this: >>>>>>>> >>>>>>>> -------------------------------- >>>>>>>> g! scr:info >> com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>> *** Bundle: com.liferay.portal.http.tunnel.extender (60) >>>>>>>> Component Description: >>>>>>>> Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>> Default State: enabled >>>>>>>> Activation: immediate >>>>>>>> Configuration Policy: require >>>>>>>> Activate Method: activate >>>>>>>> Deactivate Method: deactivate >>>>>>>> Modified Method: modified >>>>>>>> Configuration Pid: >>>>>>>> >>>>>> >>>> >> [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] >>>>>>>> Services: Service Scope: null >>>>>>>> Properties: >>>>>>>> Component Configuration: >>>>>>>> State: missing >>>>>>>> g! >>>>>>>> -------------------------------- >>>>>>>> >>>>>>>> make sense now? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 3, 2015 at 11:03 AM, David Jencks < >>>> david.a.jen...@gmail.com >>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> It looks pretty blatant to me that the reason there are no >> component >>>>>>>>> configurations is that there is no CA configuration. What kind of >>>>>>>>> notification do you want? >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> david jencks >>>>>>>>> >>>>>>>>>> On Dec 3, 2015, at 7:57 AM, Raymond Auge < >> raymond.a...@liferay.com> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hey all, >>>>>>>>>> >>>>>>>>>> It seems that scr:info report is not clearly indicating when a >>>>>> required >>>>>>>>>> configuration is not available. It is showing good info when the >>>>>>>>> component >>>>>>>>>> has a configuration: >>>>>>>>>> >>>>>>>>>> Here is the report WITH required configuration: >>>>>>>>>> ---------------------------------- >>>>>>>>>> g! scr:info >>>> com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> *** Bundle: com.liferay.portal.http.tunnel.extender (60) >>>>>>>>>> Component Description: >>>>>>>>>> Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> Default State: enabled >>>>>>>>>> Activation: immediate >>>>>>>>>> Configuration Policy: require >>>>>>>>>> Activate Method: activate >>>>>>>>>> Deactivate Method: deactivate >>>>>>>>>> Modified Method: modified >>>>>>>>>> Configuration Pid: >>>>>>>>>> >>>>>>>>> >>>>>> >>>> >> [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] >>>>>>>>>> Services: Service Scope: null >>>>>>>>>> Properties: >>>>>>>>>> Component Configuration: >>>>>>>>>> ComponentId: 1936 >>>>>>>>>> State: active >>>>>>>>>> Properties: >>>>>>>>>> component.id = 1936 >>>>>>>>>> component.name = >>>>>>>>>> com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> hostsAllowed = [127.0.0.1] >>>>>>>>>> service.pid = >>>>>>>>>> >>>>>>>>> >>>>>> >>>> >> com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration >>>>>>>>>> g! >>>>>>>>>> ---------------------------------- >>>>>>>>>> >>>>>>>>>> And here is the report when NO required configuration is >> available: >>>>>>>>>> >>>>>>>>>> ---------------------------------- >>>>>>>>>> g! scr:info >>>> com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> *** Bundle: com.liferay.portal.http.tunnel.extender (60) >>>>>>>>>> Component Description: >>>>>>>>>> Name: com.liferay.portal.http.tunnel.extender.HttpTunnelExtender >>>>>>>>>> Default State: enabled >>>>>>>>>> Activation: immediate >>>>>>>>>> Configuration Policy: require >>>>>>>>>> Activate Method: activate >>>>>>>>>> Deactivate Method: deactivate >>>>>>>>>> Modified Method: modified >>>>>>>>>> Configuration Pid: >>>>>>>>>> >>>>>>>>> >>>>>> >>>> >> [com.liferay.portal.http.tunnel.configuration.HttpTunnelExtenderConfiguration] >>>>>>>>>> Services: Service Scope: null >>>>>>>>>> Properties: >>>>>>>>>> g! >>>>>>>>>> ---------------------------------- >>>>>>>>>> >>>>>>>>>> As you can see it's not clear at all that the component is missing >>>> the >>>>>>>>>> configuration it requires. >>>>>>>>>> >>>>>>>>>> Can we fix this? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *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) >>>>>>>>> >>>>>>>>> >>>>>>>>> >> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *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) >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>>>> For additional commands, e-mail: users-h...@felix.apache.org >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *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) >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org <mailto: >> users-unsubscr...@felix.apache.org> >>>> For additional commands, e-mail: users-h...@felix.apache.org <mailto: >> users-h...@felix.apache.org> >>>> >>>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile < >> http://www.liferay.com/web/raymond.auge/profile>> >>> (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com < >> http://www.liferay.com/>> >>> (@Liferay) >>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org < >> 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) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
