Re: Unable to resolve 'org.osgi.service.component.annotations'

[David Jencks]

Why? these are the OSGI spec annotations processed by bnd.

They are not used at runtime and there should be no such wiring requirement.  
Perhaps the bnd instructions say to import the package?

david jencks

> On Oct 17, 2016, at 7:31 AM, Christian Schneider  
> wrote:
> 
> You need to install the scr feature.
> 
> Christian
> 
> On 17.10.2016 15:05, Jens Reimann wrote:
>> Hi,
>> 
>> using the SCR annotations and trying perform "mvn verify" on a feature 
>> referencing this bundle results in the following resolution error:
>> 
>> ---
>> osgi.wiring.package; 
>> filter:="(&(osgi.wiring.package=org.osgi.service.component.annotations)(version>=1.2.0))"
>> ---
>> 
>> Having a look at a possible candidate for this (org.apache.felix : 
>> org.apache.felix.scr.annotations : 1.11.0) I find that this bundle is not a 
>> bundle and has no OSGi metadata.
>> 
>> I am probably doing something wrong. But what is it?
>> 
>> Thanks for your help
>> 
>> Cheers
>> 
>> Jens
>> 
>> -- 
>> Jens Reimann
>> Senior Software Engineer / EMEA ENG Middleware
>> Werner-von-Siemens-Ring 14
>> 85630 Grasbrunn
>> Germany
>> phone: +49 89 2050 71286
>> _
>> 
>> Red Hat GmbH, www.de.redhat.com ,
>> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 
>> 153243,
>> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, 
>> Michael O'Neill
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de 
> 
> Open Source Architect
> http://www.talend.com 

java.lang.SecurityException: Insufficient roles/credentials for operation

[Andrew Hughes]

Hi All,

In advance, I will apologies for my lack of knowledge of karaf.

I am trying profile a (closed source) third party application, it uses
karaf v3.0.3 using visualvm (jdk 1.8 on windows 64bit).

I managed to successfully/easily connect visualvm with an older version of
the software that used karaf v2.x and there's a far bit of information that
suggests something was introduced in v3.x that  may have changed this.

The visualvm exception I am seeing which appears to be the source of the
problems is as below. If anyone might be able to help explain what's going
on and just maybe how it could be resolved I'd greatly appreciate it.

Huge thanks,
Andrew

-:


SEVERE [org.openide.util.RequestProcessor]: Error in RequestProcessor
com.sun.tools.visualvm.jmx.impl.AddJMXConnectionAction$1
java.lang.SecurityException: Insufficient roles/credentials for operation
at
org.apache.karaf.management.KarafMBeanServerGuard.handleInvoke(KarafMBeanServerGuard.java:289)
at
org.apache.karaf.management.KarafMBeanServerGuard.handleGetAttribute(KarafMBeanServerGuard.java:209)
at
org.apache.karaf.management.KarafMBeanServerGuard.invoke(KarafMBeanServerGuard.java:77)
at
org.apache.karaf.management.boot.KarafMBeanServerBuilder$MBeanInvocationHandler.invoke(KarafMBeanServerBuilder.java:63)
at com.sun.proxy.$Proxy0.getAttribute(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1445)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
at
javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:639)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$256(TCPTransport.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:253)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl_Stub.getAttribute(Unknown
Source)
at
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.getAttribute(RMIConnector.java:903)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.sun.tools.visualvm.jmx.impl.JmxModelImpl$CheckerInvocationHandler.invoke(JmxModelImpl.java:651)
at com.sun.proxy.$Proxy7.getAttribute(Unknown Source)
at
com.sun.jmx.mbeanserver.MXBeanProxy$GetHandler.invoke(MXBeanProxy.java:122)
at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:167)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:258)
at com.sun.proxy.$Proxy8.getName(Unknown Source)
at
com.sun.tools.visualvm.jmx.impl.JmxApplication.getPid(JmxApplication.java:66)
at
com.sun.tools.visualvm.jvmstat.JvmstatModelProvider.getMonitoredVm(JvmstatModelProvider.java:29)
at
com.sun.tools.visualvm.jvmstat.JvmstatModelProvider.createModelFor(JvmstatModelProvider.java:51)
at
com.sun.tools.visualvm.jvmstat.JvmstatModelProvider.createModelFor(JvmstatModelProvider.java:25)
at
com.sun.tools.visualvm.core.model.ModelFactory.getModel(ModelFactory.java:91)
at
com.sun.tools.visualvm.tools.jvmstat.JvmstatModelFactory.getJvmstatFor(JvmstatModelFactory.java:45)
at
com.sun.tools.visualvm.jvm.JRockitJvmProvider.createModelFor(JRockitJvmProvider.java:29)
at

Unable to resolve 'org.osgi.service.component.annotations'

[Jens Reimann]

Hi,

using the SCR annotations and trying perform "mvn verify" on a feature
referencing this bundle results in the following resolution error:

---
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.osgi.service.component.annotations)(version>=1.2.0))"
---

Having a look at a possible candidate for this (org.apache.felix :
org.apache.felix.scr.annotations : 1.11.0) I find that this bundle is not a
bundle and has no OSGi metadata.

I am probably doing something wrong. But what is it?

Thanks for your help

Cheers

Jens

-- 
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill

Re: Unable to resolve 'org.osgi.service.component.annotations'

[Christian Schneider]

You need to install the scr feature.

Christian

On 17.10.2016 15:05, Jens Reimann wrote:

Hi,

using the SCR annotations and trying perform "mvn verify" on a feature 
referencing this bundle results in the following resolution error:


---
osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.osgi.service.component.annotations)(version>=1.2.0))"

---

Having a look at a possible candidate for this (org.apache.felix : 
org.apache.felix.scr.annotations : 1.11.0) I find that this bundle is 
not a bundle and has no OSGi metadata.


I am probably doing something wrong. But what is it?

Thanks for your help

Cheers

Jens

--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_

Red Hat GmbH, www.de.redhat.com ,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, 
HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, 
Michael O'Neill



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Unable to resolve 'org.osgi.service.component.annotations'

[Toni Menzel]

Sure to make it work but are the annotations processed at runtime? Don't
hope so.

On Monday, 17 October 2016, Christian Schneider 
wrote:

> You need to install the scr feature.
>
> Christian
>
> On 17.10.2016 15:05, Jens Reimann wrote:
>
> Hi,
>
> using the SCR annotations and trying perform "mvn verify" on a feature
> referencing this bundle results in the following resolution error:
>
> ---
> osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.
> component.annotations)(version>=1.2.0))"
> ---
>
> Having a look at a possible candidate for this (org.apache.felix :
> org.apache.felix.scr.annotations : 1.11.0) I find that this bundle is not
> a bundle and has no OSGi metadata.
>
> I am probably doing something wrong. But what is it?
>
> Thanks for your help
>
> Cheers
>
> Jens
>
> --
> Jens Reimann
> Senior Software Engineer / EMEA ENG Middleware
> Werner-von-Siemens-Ring 14
> 85630 Grasbrunn
> Germany
> phone: +49 89 2050 71286
> 
> _
>
> Red Hat GmbH, www.de.redhat.com,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
> 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
> Michael O'Neill
>
>
>
> --
> Christian Schneiderhttp://www.liquid-reality.de
>
> Open Source Architecthttp://www.talend.com
>
>

-- 

*Toni Menzel*


*Developer Advocates - The Rebaze Way *

*www.rebaze.de  | www.rebaze.com
 | @rebazeio *

Re: Unable to resolve 'org.osgi.service.component.annotations'

[Toni Menzel]

Hi Jens,

org.osgi.service.component.annotations are compile time annotations that
should result in a DS xml file in your bundle.
To make it more clear: they are processed by your build process and should
never appear in your imports.

Can you give an example of your project? What bundle plugin are you using?
Whats your bnd file like?

*Toni Menzel*


*Developer Advocates - The Rebaze Way *

*www.rebaze.de  | www.rebaze.com
 | @rebazeio *

On Mon, Oct 17, 2016 at 3:05 PM, Jens Reimann  wrote:

> Hi,
>
> using the SCR annotations and trying perform "mvn verify" on a feature
> referencing this bundle results in the following resolution error:
>
> ---
> osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.
> component.annotations)(version>=1.2.0))"
> ---
>
> Having a look at a possible candidate for this (org.apache.felix :
> org.apache.felix.scr.annotations : 1.11.0) I find that this bundle is not
> a bundle and has no OSGi metadata.
>
> I am probably doing something wrong. But what is it?
>
> Thanks for your help
>
> Cheers
>
> Jens
>
> --
> Jens Reimann
> Senior Software Engineer / EMEA ENG Middleware
> Werner-von-Siemens-Ring 14
> 85630 Grasbrunn
> Germany
> phone: +49 89 2050 71286
> 
> _
>
> Red Hat GmbH, www.de.redhat.com,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
> 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
> Michael O'Neill
>