Re: gogo command descriptions as properties

2019-02-17 Thread Thomas Watson 
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  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  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  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 
> >> 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  >
> >>> 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.
>  - @Descriptor on PARAMETER = osgi.command.function..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é* 
>  (@rotty3000)
>  Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
>  Board Member & EEG Co-Chair, OSGi Alliance 
>  (@OSGiAlliance)
> 
> >>>
> >>>
> >>> --
> >>> *Raymond Augé* 
> >>> (@rotty3000)
> >>> Senior Software Architect *Liferay, Inc.* 
> >>> (@Liferay)
> >>> Board Member & EEG Co-Chair, OSGi Alliance 
> >> (@OSGiAlliance)
> >>
>
>

Re: gogo command descriptions as properties

2019-02-17 Thread David Jencks 
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  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  
>> 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 
>> 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 
>>> 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.
 - @Descriptor on PARAMETER = osgi.command.function..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é* 
 (@rotty3000)
 Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
 Board Member & EEG Co-Chair, OSGi Alliance 
 (@OSGiAlliance)
 
>>> 
>>> 
>>> --
>>> *Raymond Augé* 
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* 
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance 
>> (@OSGiAlliance)
>>

[jira] [Commented] (FELIX-6021) Remote shell doesn't work with Gogo

2019-02-17 Thread Tobias Gunkel (JIRA) 


[ 
https://issues.apache.org/jira/browse/FELIX-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16770619#comment-16770619
 ] 

Tobias Gunkel commented on FELIX-6021:
--

[~ALemmer]: Same problem here.

Replacing the Manifest line
{code:java}
DynamicImport-Package: org.apache.felix.service.command; 
status="provisional",org.apache.felix.shell,org.osgi.service.log
{code}
with
{code:java}
DynamicImport-Package: org.osgi.service.log
Require-Bundle: org.apache.felix.gogo.runtime;resolution:=optional
{code}
helps that {{NoClassDefFoundError: 
org/apache/felix/service/command/CommandProcessor}} goes away but then another 
exception occurs:
{code:java}
Exception in thread "telnetconsole.shell remote=/127.0.0.1:32827" 
java.lang.NoSuchMethodError: 
org.apache.felix.service.command.CommandProcessor.createSession(Ljava/io/InputStream;Ljava/io/PrintStream;Ljava/io/PrintStream;)Lorg/apache/felix/service/command/CommandSession;
at org.apache.felix.shell.remote.Shell.run(Shell.java:79)
{code}
Although the exception states that the method was not found, the API interface 
{{org.apache.felix.service.command.CommandProcessor}} still seems to be 
compatible:

{{public abstract org.apache.felix.service.command.CommandSession 
createSession(java.io.InputStream arg0, java.io.OutputStream arg1, 
java.io.OutputStream arg2)}}.

At least the proposed workaround {{-Dgosh.args="-sc telnetd -p2323 start"}} 
works fine here.

> Remote shell doesn't work with Gogo
> ---
>
> Key: FELIX-6021
> URL: https://issues.apache.org/jira/browse/FELIX-6021
> Project: Felix
>  Issue Type: Bug
>  Components: Remote Shell
>Affects Versions: shell.remote-1.1.2
>Reporter: Andreas Lemmer
>Priority: Critical
>  Labels: gogo, remote, shell
>
> The shell.remote bundle doesn't work together with the Gogo shell, neither 
> with gogo.shell nor with gogo.jline. When trying to connect, there is an
> {{Exception in thread "telnetconsole.shell remote=/127.0.0.1:60679" 
> java.lang.NoClassDefFoundError: 
> org/apache/felix/service/command/CommandProcessor}}
> {{at org.apache.felix.shell.remote.Shell.run(Shell.java:78)}}
> {{at java.lang.Thread.run(Thread.java:748)}}
> {{Caused by: java.lang.ClassNotFoundException: 
> org.apache.felix.service.command.CommandProcessor not found by 
> org.apache.felix.shell.remote [16]}}
> {{at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1597)}}
> {{at 
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)}}
> {{at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)}}
> {{at java.lang.ClassLoader.loadClass(ClassLoader.java:357)}}
> {{... 2 more}}
> When changing the Manifest.MF and removing the status requirement in
> {{DynamicImport-Package: 
> org.apache.felix.service.command;status="provisional"}}
> then it seems to find the class, but the method arguments don't seem to match.
> Currently, the only method to open a telnet server seems to be setting the 
> system property
> -Dgosh.args="-sc telnetd -p2323 start"
> but this works only with gogo.shell and not with gogo.jline (in fact, there 
> is always an exception when specifying -Dgosh.args with gogo.jline). JLine 
> has an embedded telnet daemon (which seems to be the same like gogo.shell 
> has), but it isn't used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: gogo command descriptions as properties

2019-02-17 Thread Thomas Watson 
+1 from me.  We struggle with this in Open Liberty.  It should affect any
environment that wants to have core bundles that provide functions to gogo
with help desciptions but do not want to forced gogo to be installed.

Tom

On Sat, Feb 16, 2019, 5:44 PM Raymond Auge  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 
> 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.
> > - @Descriptor on PARAMETER = osgi.command.function..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é* 
> >  (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* 
> >  (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance 
> > (@OSGiAlliance)
> >
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: gogo command descriptions as properties

2019-02-17 Thread Thomas Watson 
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  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 
> 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 
> > 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.
> >> - @Descriptor on PARAMETER = osgi.command.function..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é* 
> >> (@rotty3000)
> >> Senior Software Architect *Liferay, Inc.* 
> >> (@Liferay)
> >> Board Member & EEG Co-Chair, OSGi Alliance 
> >> (@OSGiAlliance)
> >>
> >
> >
> > --
> > *Raymond Augé* 
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* 
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: [VOTE] Release Felix Converter version 1.0.4

2019-02-17 Thread clement escoffier 
+1,

Clement

> On 17 Feb 2019, at 10:03, Carsten Ziegeler  wrote:
> 
> +1
> 
> 
> Raymond Auge wrote
>> I'd like to call a vote for the release of Felix Converter 1.0.4
>> The release notes are here:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344669
>> The staging repository is here:
>> https://repository.apache.org/content/repositories/orgapachefelix-1284
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> Usage:
>> sh check_staged_release.sh 1284 /tmp/felix-staging
>> Please vote to approve this release:
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> This vote will be open for 72 hours.
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Felix Converter version 1.0.4

2019-02-17 Thread David Bosschaert 
+1

David

On Sat, 16 Feb 2019 at 23:57, Raymond Auge  wrote:

> I'd like to call a vote for the release of Felix Converter 1.0.4
>
> The release notes are here:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344669
>
> The staging repository is here:
> https://repository.apache.org/content/repositories/orgapachefelix-1284
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1284 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: [VOTE] Release Felix Converter version 1.0.4

2019-02-17 Thread Carsten Ziegeler 

+1


Raymond Auge wrote

I'd like to call a vote for the release of Felix Converter 1.0.4

The release notes are here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344669

The staging repository is here:
https://repository.apache.org/content/repositories/orgapachefelix-1284

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1284 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.


--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org