Thank you for your answer Richard.
Is that API available as a bundle to download?
I see in the Felix svn trunk that the RepositoryAdmin has a new method:
Resource[] discoverResources(Requirement[] requirements);
Is that what you mean?
Also, I need to ask for the resource (bundle) in other
Thank you very much for your help Richard.
I will start another thread about my distribution problem to set a
context and hopefully get some insights about other possible approaches
to the problem.
Regards and thanks again.
On 18/03/12 00:13, Richard S. Hall wrote:
On 3/17/12 20:59 , Matias
Hi everybody,
I'm trying to implement some logic that allows a network node to fetch
some bundles from other and install them into its own OBR service.
I will try to explain the problem better. Lets say I have two network
nodes (i.e. servers in some place of a network), each one has an OBR
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 an OBR repository:
* SymbolicName: A
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
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 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 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
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.
Ok, thank you very much for your comments Richard.
I will keep them in mind and do further experimentation.
On 02/04/12 21:25, Richard S. Hall wrote:
The location string is a deployer assigned persistent identifier, so it cannot
change. Your confusion arises because frameworks use the URL as
for ease of reading ...]
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
solve
, Matias SM wrote:
Hi Richard,
I've given this issue some more thought and I realized that my
starting point stands (a copy of the original mail is at the end of
this one).
If I try to execute these steps:
g! deploy -s DA
g! deploy -s A@1.0.0.1
g! refresh
g! deploy -s DexA
The deployment of DexA
I will, thank you
On 05/04/12 16:12, Richard S. Hall wrote:
Ok, great...watch the issue for any updates...
- richard
On 4/5/12 15:01 , Matias SM wrote:
I just created it:
Key: FELIX-3446
URL:https://issues.apache.org/jira/browse/FELIX-3446
HTH, Kind Regards
On 05/04/12 15:15, Richard S
Hi Richard,
I know I'm resurrecting a little old thread, but I'm reading the core
specification (Release 4, Version 4.3) and it says (section 7.3 Wiring):
/Refreshing happens on a per bundle basis but takes any Bundle
Wirings into account that depend on the refreshed bundle. In the
On 06/04/12 16:09, Matias SM wrote:
Hi Richard,
I know I'm resurrecting a little old thread, but I'm reading the core
specification (Release 4, Version 4.3) and it says (section 7.3
Wiring):
/Refreshing happens on a per bundle basis but takes any Bundle
Wirings into account
On 06/04/12 17:22, Richard S. Hall wrote:
On 4/6/12 15:09 , Matias SM wrote:
Hi Richard,
I know I'm resurrecting a little old thread, but I'm reading the core
specification (Release 4, Version 4.3) and it says (section 7.3
Wiring):
/Refreshing happens on a per bundle basis but takes
On 06/04/12 19:27, Richard S. Hall wrote:
On 4/6/12 5:14 PM, Matias SM wrote:
On 06/04/12 17:22, Richard S. Hall wrote:
On 4/6/12 15:09 , Matias SM wrote:
Hi Richard,
I know I'm resurrecting a little old thread, but I'm reading the
core specification (Release 4, Version 4.3) and it says
Hi everybody,
I'm trying to get a bundle's dependency closure by using the method
getDependencyClosure. However if I do sth like:
context.getBundle(0).adapt(FrameworkWiring.class).getDependencyClosure(Arrays.asList(myBundle));
to get myBundle's closure, all this call is returning is the bundle
by getDependencyClosure that only
contains myBundle.
I would be happy to give you any other information you need to help me
understand what is going wrong.
Kind regards
On 10/05/12 20:25, Richard S. Hall wrote:
Should work. Are you sure your bundle is resolved?
- richard
On 5/10/12 19:19 , Matias SM wrote:
Hi
be bugs, I guess.
- richard
On 5/10/12 19:19 , Matias SM wrote:
Hi everybody,
I'm trying to get a bundle's dependency closure by using the method
getDependencyClosure. However if I do sth like:
context.getBundle(0).adapt(FrameworkWiring.class).getDependencyClosure(Arrays.asList(myBundle));
to get
Hi everybody,
I'm wondering about a difference in the behavior of OBR when using a
Felix framework from gogo with respect to an embedded one.
Using gogo, if I install and start a bundle through the command line
(gogo), If another bundle queries the (OBR) repositoryAdmin, it would be
able to
On 29/05/12 20:42, Richard S. Hall wrote:
On 5/29/12 18:31 , Matias SM wrote:
On 29/05/12 13:58, Richard S. Hall wrote:
On 5/29/12 12:49 , matias san martin wrote:
De: Richard S. Hallhe...@ungoverned.org
Para: users@felix.apache.org
Enviado: martes, 29 de
On 29/05/12 23:50, Richard S. Hall wrote:
On 5/29/12 20:46 , Matias SM wrote:
On 29/05/12 20:42, Richard S. Hall wrote:
On 5/29/12 18:31 , Matias SM wrote:
On 29/05/12 13:58, Richard S. Hall wrote:
On 5/29/12 12:49 , matias san martin wrote:
De
23 matches
Mail list logo
