You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Benson Margulies <be...@basistech.com> on 2014/11/18 03:04:37 UTC
org.osgi.framework version range chosen by plugin
the maven-bundle-plugin decided to put the following into the
manifest, even though I'm using a much newer version of OSGi. Should I
just add an instruction to set a version I like better, or is there
something more subtle I've missed that would clue it in?
org.osgi.framework;version="[1.4,2)"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo shell - don't call getXXX on each object
Posted by Bulu <bu...@romandie.com>.
Thanks
Philipp
On 19.11.2014 11:30, Derek Baum wrote:
> Two things are happening here:
>
> 1. By default gogo prints the result of commands (including assignments)
>
> g! lb -s | grep gogo
> 2|Active | 1|org.apache.felix.gogo.command (0.12.0)
> 3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
> 4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
> true
>
> The ‘true’ in the output above is the result of the grep command, printed by the togo console.
>
>
> 2. The result is printed using registered converters for the type, not just toString().
>
> This means that multiple methods may be invoked by the converter to print the type - as you have found.
>
> The rationale behind this, was that it allowed commands to be constructed directly from api calls.
> For example, the ‘bundle’ command is a direct call to BundleContext.getBundle():
>
> g! b1 = bundle 1
>
> produces a pretty formatted bundle listing - which is done by the registered converter for Bundle - the value assigned to b1 is the bundle imll:
>
> g! set b1
> BundleImpl b1 org.apache.felix.bundlerepository [1]
>
> This behaviour can be disabled by setting:
>
> g! .Gogo.format=false
>
> Note: although this solves your issue, some commands such as ‘bundle’ will no longer produce the expected output.
>
> In this case you can invoke the converter explicitly using the format command:
>
> g! bundle 1
> g! format
> Bundle 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
> ...
>
> —
> Derek
>
> On 19 Nov 2014, at 09:44, Bulu <bu...@romandie.com> wrote:
>
>> Hello all
>>
>> When I assign variables in Gogo Shell like so:
>> g! _srefs = $.context getServiceReferences "com.example.Class" "(some=filter)"
>> the shell automatically calls all getXXX methods on the returned object and prints the result out.
>>
>> How can I avoid this?
>> I have some long running getXXX methods which I don't want to be called unless needed.
>>
>> Thanks Phil
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo shell - don't call getXXX on each object
Posted by Derek Baum <de...@baums.org.uk>.
Two things are happening here:
1. By default gogo prints the result of commands (including assignments)
g! lb -s | grep gogo
2|Active | 1|org.apache.felix.gogo.command (0.12.0)
3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
true
The ‘true’ in the output above is the result of the grep command, printed by the togo console.
2. The result is printed using registered converters for the type, not just toString().
This means that multiple methods may be invoked by the converter to print the type - as you have found.
The rationale behind this, was that it allowed commands to be constructed directly from api calls.
For example, the ‘bundle’ command is a direct call to BundleContext.getBundle():
g! b1 = bundle 1
produces a pretty formatted bundle listing - which is done by the registered converter for Bundle - the value assigned to b1 is the bundle imll:
g! set b1
BundleImpl b1 org.apache.felix.bundlerepository [1]
This behaviour can be disabled by setting:
g! .Gogo.format=false
Note: although this solves your issue, some commands such as ‘bundle’ will no longer produce the expected output.
In this case you can invoke the converter explicitly using the format command:
g! bundle 1
g! format
Bundle 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
...
—
Derek
On 19 Nov 2014, at 09:44, Bulu <bu...@romandie.com> wrote:
> Hello all
>
> When I assign variables in Gogo Shell like so:
> g! _srefs = $.context getServiceReferences "com.example.Class" "(some=filter)"
> the shell automatically calls all getXXX methods on the returned object and prints the result out.
>
> How can I avoid this?
> I have some long running getXXX methods which I don't want to be called unless needed.
>
> Thanks Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Gogo shell - don't call getXXX on each object
Posted by Bulu <bu...@romandie.com>.
Hello all
When I assign variables in Gogo Shell like so:
g! _srefs = $.context getServiceReferences "com.example.Class"
"(some=filter)"
the shell automatically calls all getXXX methods on the returned object
and prints the result out.
How can I avoid this?
I have some long running getXXX methods which I don't want to be called
unless needed.
Thanks Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: org.osgi.framework version range chosen by plugin
Posted by Benson Margulies <be...@basistech.com>.
On Tue, Nov 18, 2014 at 3:59 AM, Neil Bartlett <nj...@gmail.com> wrote:
> You probably shouldn’t change this. The version range is wide, which allows people to use your bundle if they are running an older framework. It does not prevent you from using a higher version if you wish.
I confess: I'd made dumb error in my launcher of setting system
packages instead of extra system packages (by leakage from pax-exam) ,
and caused the framework package not to wire, and so I got mistakenly
concerned about the version. It's all working now.
>
> You should only change the import to use a higher version (e.g. 1.5) if your bundle *cannot* work with version 1.4 of the package. You do this by explicitly compiling against the lowest version of the library your bundle can work with.
>
> Neil
>
>> On 18 Nov 2014, at 02:04, Benson Margulies <be...@basistech.com> wrote:
>>
>> the maven-bundle-plugin decided to put the following into the
>> manifest, even though I'm using a much newer version of OSGi. Should I
>> just add an instruction to set a version I like better, or is there
>> something more subtle I've missed that would clue it in?
>>
>> org.osgi.framework;version="[1.4,2)"
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: org.osgi.framework version range chosen by plugin
Posted by Neil Bartlett <nj...@gmail.com>.
You probably shouldn’t change this. The version range is wide, which allows people to use your bundle if they are running an older framework. It does not prevent you from using a higher version if you wish.
You should only change the import to use a higher version (e.g. 1.5) if your bundle *cannot* work with version 1.4 of the package. You do this by explicitly compiling against the lowest version of the library your bundle can work with.
Neil
> On 18 Nov 2014, at 02:04, Benson Margulies <be...@basistech.com> wrote:
>
> the maven-bundle-plugin decided to put the following into the
> manifest, even though I'm using a much newer version of OSGi. Should I
> just add an instruction to set a version I like better, or is there
> something more subtle I've missed that would clue it in?
>
> org.osgi.framework;version="[1.4,2)"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: org.osgi.framework version range chosen by plugin
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
> Am 18.11.2014 um 03:04 schrieb Benson Margulies <be...@basistech.com>:
>
> the maven-bundle-plugin decided to put the following into the
> manifest, even though I'm using a much newer version of OSGi. Should I
> just add an instruction to set a version I like better, or is there
> something more subtle I've missed that would clue it in?
>
> org.osgi.framework;version="[1.4,2)“
If you have an explicit OSGi Core dependency in your Maven project but the bundle plugin still uses a different version, it may be that through transitive dependencies (I generally switch this off by using scope=provided in bundles) Maven pulls a different OSGi core library version into the class path in front of your explicit declaration.
Regards
Felix
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org