On Thu, Dec 3, 2015 at 12:31 PM, David Jencks <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
> 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)

Reply via email to