felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david.a.jen...@gmail.com>
Subject Re: scr:info missing info
Date Thu, 03 Dec 2015 17:59:57 GMT
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.auge@liferay.com> wrote:
> 
> On Thu, Dec 3, 2015 at 12:31 PM, David Jencks <david.a.jencks@gmail.com <mailto:david.a.jencks@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.auge@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.jencks@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.auge@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.auge@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.jencks@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.auge@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-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@felix.apache.org <mailto:users-unsubscribe@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org <mailto:users-help@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)


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message