As an alternative to translating the annotations to service properties, would it work to scan the bytecode, perhaps using asm or code from bnd, to extract the annotation content without loading the annotation classes, and perhaps even stop exporting the annotations? Are there problems with this approach?
David Jencks Sent from my iPhone > On Feb 17, 2019, at 2:46 PM, Thomas Watson <[email protected]> wrote: > > 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) >>>> >> >>
