This could have something to do with the way you instantiate your framework,
_or_ with the way your bundle is packaged.
Could you post (a) your framework instantiation code, and (b) the manifest of
your bundle?
Angelo
On Apr 2, 2012, at 10:18 AM, M. van Ree wrote:
Hello all,
I have a
Hello Angelo,
Thank you for your fast response!
Here is some more info:
a:
public FelixManager(String rootPath)
{
this.rootPath = rootPath;
felixProperties = new FelixProperties(this.rootPath);
bundlesDir = new File(rootPath+/felix/bundle);
if (!bundlesDir.exists()) {
Right.
I'm not entirely sure what's up, but some things come to mind,
- in stead of building the manifest by hand, you should consider using
something like BND (perhaps with BNDTools, if you're an Eclipse user) to handle
that for you. If you don't need to use DynamicImport, stick with 'regular'
I was considering the use of BNDTools indeed, and will look into that for
sure now.
I didn't know about the Bundle-ManifestVersion, will look into that too!
The comma is indeed a copy-paste error, as you can see in the bottom import
statement, I closed the last one without a comma. But, sharp to
Hi Maurice,
See inline.
On Apr 2, 2012, at 11:51 AM, M. van Ree wrote:
I was considering the use of BNDTools indeed, and will look into that for
sure now.
I didn't know about the Bundle-ManifestVersion, will look into that too!
The comma is indeed a copy-paste error, as you can see in the
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me resolve bundle deployment. Everything works
great and as expected but I'm facing a situation I don't know how to
solve.
---
Here is my test scenario:
I have the following bundles in
Hi,
I'm currently have a problem with Felix and or IPojo.
Basically the problem is when Felix is starting up and services are still
registering while and in the meantime a stop Felix is request.
The code to stop is simple : getBundle(0).stop();
If I have a look at the thread dump on JVisualVM,
Apologies for the blatant advertisement, but want to let you all know that my
book, Java Application Architecture: Modularity Patterns with Examples Using
OSGi is now available. The book's homepage is http://modularity.kirkk.com.
Ironically, the book may not be an ideal fit for those of you
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me resolve bundle deployment. Everything works
great and as expected but I'm facing a situation I don't know how to
I don't know if that may be your issue but in the book OSGi in action
[1] they recommend that if a bundle want to stop itself, it should do so
in a different thread. This is to avoid possible deadlocks if as part of
the bundle finalization there is any waiting for the calls to finish.
You can
On 4/2/12 15:42, Matias SM wrote:
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me resolve bundle deployment. Everything works
great and as expected but I'm
This is not related to FELIX-3393, although it appears related to the
Aries Blueprint comment on FELIX-3393, which is also unrelated to
FELIX-3393.
It appears in both situations the component framework (Aries Blueprint
and/or iPOJO) is synchronously dealing with a bundle being stopped while
On 02/04/12 17:31, Richard S. Hall wrote:
On 4/2/12 15:42, Matias SM wrote:
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me resolve bundle deployment.
On 4/2/12 17:05, Matias SM wrote:
On 02/04/12 17:31, Richard S. Hall wrote:
On 4/2/12 15:42, Matias SM wrote:
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help
On 02/04/12 18:32, Richard S. Hall wrote:
On 4/2/12 17:05, Matias SM wrote:
On 02/04/12 17:31, Richard S. Hall wrote:
On 4/2/12 15:42, Matias SM wrote:
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM
Hi,
It looks like there are some issues while refreshing gogo bundles
This is what you get when updating gogo runtime
Welcome to Apache Felix Gogo
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active |0|System Bundle (4.0.2)
1|Active |
Yes, you are using the same path when you try to install the first bundle the
second time and this will not work since that path is used as a unique key,
which is why it returns the same bundle id as printed in your session since it
did not install anything the second time.
As I suggest you
Ok, I see. Shouldn't the location string be replaced (with the updated
version location) when the bundle is updated? It seems a little confusing.
Thank you very much for the clarification, I will do some more
experimentation keeping in mind what we discussed.
On 02/04/12 19:25, Richard S.
The location string is a deployer assigned persistent identifier, so it cannot
change. Your confusion arises because frameworks use the URL as the default
location string for simple installs, but the two are unrelated in reality.
Matias SM matias...@yahoo.com.ar wrote:
Ok, I see. Shouldn't the
19 matches
Mail list logo
