Hi,
I understand the confusion, because the current wording used there is kind of
misleading.
@Component actually defines a component factory, use to create component
instance (container and content). But it does not create an instance of it. To
create an instance, use @Instantiate, or one of
Renato,
Thanks for the response. You actually made me feel a lot better about
myself! I have been struggling to understand how to use OSGi (and
continue to). It's not what I thought it was when I started out; it is
indeed low-level - much lower level than I anticipated. I do intend to
move on
Hello,
I would like to understand something about @components and instances.
If I have a service @Component Foo with a strategy of INSTANCE and I have
a @Component consumer Bar with a field @Requires Foo, why is the instance
not created automatically by iPojo? there is a valid factory for Foo re
Hello,
I would like to understand something about @components and instances.
If I have a service @Component Foo with a strategy of INSTANCE and I have
a @Component consumer Bar with a field @Requires Foo, why is the instance
not created automatically by iPojo? there is a valid factory for Foo re
I think he meant the package imports in the MANIFEST file.
You need to make sure you are importing the package where RepositoryAdmin is
(which should be in an API bundle) with the exact same version in both the
consumer bundle of the service and the implementator bundle of the service.
Look out
This is fairly complicated to explain, but here goes.
I am trying to understand what the behaviour should be in the
following circumstance:
- bundle A exports a package and is used by bundles B, C and D
- bundle E exports a package with the same name and is not used by any bundle
- A new reposito
Neil,
Thanks for your reply. Here are the OSGi/Felix -related imports I have
in the class that contains the code that I included in the original
email (below):
import org.apache.felix.bundlerepository.Resource;
import org.apache.felix.framework.Felix;
import org.apache.felix.framework.util.Felix
David,
Thanks for the reply. I figured it had to do with Class loaders but I'm
at a loss as to how this is happening; I don't know a lot about class
loaders.
Here's some more detail on my situation: as I said we're using Felix in
an embedded fashion; we instantiate a Felix object and start it fr
Tim, you don’t really need to know anything about classloaders! The important
part from David’s email was the second paragraph. Make sure you import the same
package that the provider of the service uses, and you will be okay.
By the way, how did you open your ServiceTracker? Did you call open(t
To register a service: BundleContext.registerService()
The returned object from that method is a ServiceRegistration. When you want to
unregister, call ServiceRegistration.unregister().
Regards,
Neil
On 6 August 2014 at 14:49:40, Dean Schulze (dean.w.schu...@gmail.com) wrote:
The remote proce
The remote process sends a heartbeat over the socket periodically. If
the heartbeat is missing we need to re-establish the socket by waiting
for the remote process to come back up and connect.
I could register a proxy service when there is a connection and
unregister it when the connection is
David, what you are saying is probably exactly what Neil meant in his
brief post - by "representing the remote process as a service", it could
be assumed that one writes a service that publishes / unpublishes an
OSGi service as the connection to the remote process comes and goes.
We do exactly thi
Hi Tim,
> java.lang.ClassCastException:
> org.apache.felix.bundlerepository.impl.RepositoryAdminImpl cannot be
> cast to org.apache.felix.bundlerepository.RepositoryAdmin
This happens when the RepositoryAdmin interface is loaded from a
different classloader than where the RepositoryAdminImpl load
13 matches
Mail list logo
