The problem with loading the class at all, even later as a dynamic import, is then it creates a wire with the go go bundle. That means when go-go is uninstalled then scr would need to be refreshed. While that should work in a perfectly executed osgi system, it still would require all service components to be restarted which is very disruptive.
Tom On Sun, Feb 17, 2019, 3:05 PM David Jencks <[email protected] wrote: > That was the problem I left the code base with:-) I think I recall seeing > one of my failed attempts to solve it removed with a comment that made me > hope someone had found a way to successfully deal with the situation; > apparently not. I had thought that if the command class was loaded only > after the annotations were available then they’d get imported and used, but > couldn’t figure out a way to make that happen. > > A couple of questions about the proposal…. > > Is gogo related to an osgi spec? I thought not…. in which case using > osgi.command.function in the property name is perhaps not appropriate. > > How about including the method signature in the property name rather than > just the method name? I think this would make the properties approach as > powerful as annotations. How about preprocessing the annotations into > properties? > > In whatever form, I still think this is a good idea… > > David Jencks > > > On Feb 17, 2019, at 8:37 AM, Thomas Watson <[email protected]> wrote: > > > > The problem is if scr is not resolved against the optional import for the > > command package then the annotations are unrecognized by the gogo > runtime. > > So if scr is resolved before the gogo bundles are installed we get no > help. > > > > Tom > > > > On Sat, Feb 16, 2019, 7:20 PM David Jencks <[email protected] > wrote: > > > >> Well, I like this idea. > >> > >> To dilute the thread,.... when I worked on the ds gogo commands, if ds > >> started before the gogo annotations were available the gogo commands > worked > >> but had no “help”. Has anyone succeeded in solving this problem? Is this > >> the sort of problem you’re proposing to solve here? > >> > >> Thanks > >> David Jencks > >> > >> Sent from my iPhone > >> > >>> On Feb 16, 2019, at 3:44 PM, Raymond Auge <[email protected]> > >> wrote: > >>> > >>> I'll take the resounding silence as everyone holding their breath in > >>> anticipation. > >>> > >>> Thx, > >>> - Ray > >>> > >>> On Wed, Feb 13, 2019 at 9:45 AM Raymond Auge <[email protected] > > > >>> wrote: > >>> > >>>> Hello everyone, > >>>> > >>>> A few months ago we discussed a way of describing Gogo Command > functions > >>>> without being bound by the gogo APIs (i.e. using the annotations). > >>>> > >>>> Recently the issue of being optionally bound to the Gogo runtime API > >>>> actually caused the Equinox project some issues with their adoption of > >>>> Felix SCR as its DS implementation. > >>>> > >>>> I've personally struggled with the issue at my company as well. > >>>> > >>>> In order to aleviate this coupling, Tom Watson and I have a proposal > to > >>>> simplify the common case (i.e. NOT as a full replacement for the > >>>> annotations): > >>>> > >>>> The proposal is to support a _fall back to service properties_ for > >> missing > >>>> @Descriptor annotation, like so: > >>>> > >>>> - @Descriptor on TYPE = service.description > >>>> - @Descriptor on METHOD = osgi.command.function.<name> > >>>> - @Descriptor on PARAMETER = osgi.command.function.<name>.param.# > >> (indexed > >>>> from 0) > >>>> > >>>> Note that overloaded methods lead to ambiguity in this model. Our > >> proposal > >>>> is NOT to solve that. Rather, if you have such a complex case, use the > >>>> annotations. > >>>> > >>>> Thoughts? Anyone object to making this enhancement? > >>>> > >>>> -- > >>>> *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) > >> > >
