Thanx for the clarification on refreshPackages(). As bundle life cycle
is an important aspect of OSGi I would expect a consistent approach
from all framework implementations and the specs should not leave
space for interpretations. So, looks like Equinox is not following the
specs then as in Equino
Alin Dreghiciu wrote:
I wanted to say something like you explained that you don't do: I
expected that Felix will do something like this:
If I have a bundle A that is exporting a package P that is used by
bundle B, when I uninstall the bundle A, package P will still be
available. But when I uninst
I wanted to say something like you explained that you don't do: I
expected that Felix will do something like this:
If I have a bundle A that is exporting a package P that is used by
bundle B, when I uninstall the bundle A, package P will still be
available. But when I uninstall bundle B the package
Alin Dreghiciu wrote:
You are right. The citation was from 4.0.1. I looked into 4.1.0 and
there this statement is gone and has been replaced by "If none of the
old exports are used, then the old exports must be removed. Otherwise,
all old exports must remain available for existing bundles and fut
You are right. The citation was from 4.0.1. I looked into 4.1.0 and
there this statement is gone and has been replaced by "If none of the
old exports are used, then the old exports must be removed. Otherwise,
all old exports must remain available for existing bundles and future
resolves until the r
Alin Dreghiciu wrote:
Indeed the complete refresh worked as can be seen bellow on . But that still does not comply to the specs in my view as on doing
refresh on a bundle the framework should re-resolve the bundle. At
least that is what I got from the specs, but the specs are not very
clear about
From my interpretation of the spec, a bundle is only refreshed if it is
pending removal. In this case OBR, is not pending removal.
For your example 2, I am pretty sure that this has been changed and that
you are free to use uninstalled packages to resolve new dependencies. I
am not sure if thi
Indeed the complete refresh worked as can be seen bellow on . But that still does not comply to the specs in my view as on doing
refresh on a bundle the framework should re-resolve the bundle. At
least that is what I got from the specs, but the specs are not very
clear about this. Maybe I should po
Karl Pauls wrote:
I think the issue is that you did only refresh the obr bundle. The
other bundle is still around and can be used until the framework is
refreshed. Can you try whether doing a complete refresh makes a
difference?
Yes, that is what I was going to say too. You don't need to refr
Yes, I guess you are doing something incorrectly, but I don't think you
are giving me enough information to figure out your mistake. I have
created a bundle with the following content:
heavy:~/tmp/craig$ jar tf craig.jar
META-INF/
META-INF/MANIFEST.MF
craig/
craig/Activator.class
craig/Command0
Hi,
I removed declarative services from the mix, pretty much reducing my
example to the straight sample as provided by the felix documentation,
still to no avail (meaning, exact same results/symptoms as with the
SCR/DS in the mix); As in original post, I am providing some sample
snippets for your/
I think the issue is that you did only refresh the obr bundle. The
other bundle is still around and can be used until the framework is
refreshed. Can you try whether doing a complete refresh makes a
difference?
regards,
Karl
Von meinem iPhone gesendet
Am 28.07.2008 um 18:58 schrieb "Alin
[
https://issues.apache.org/jira/browse/FELIX-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-649.
-
Resolution: Fixed
Nice catch !
The issue comes from the super constructor arguments that w
Hi guys,
While working on FELIX-482 I had the following (interesting) situation:
1. I had obr bundle importing org.osgi.service.log package (not optional import)
2. On a new felix instance I installed the the osgi compendium bundle
that exports the log package
3. Installed obr bundle. The obr bun
Okay. Thanx.
On Mon, Jul 28, 2008 at 5:01 PM, Richard S. Hall <[EMAIL PROTECTED]> wrote:
> FYI, we have two issues for core and compendium:
>
> http://issues.apache.org/jira/browse/FELIX-514
> http://issues.apache.org/jira/browse/FELIX-595
>
> -> richard
>
> Alin Dreghiciu wrote:
>>
>> Hi guys
[
https://issues.apache.org/jira/browse/FELIX-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alin Dreghiciu updated FELIX-482:
-
Attachment: FELIX-482.patch
I attached a patch that changes the System.errr/System.out/printStackT
Hi,
I have a feeling this is another "oh by the way" by incorporating
declarative services into the mix... I'm attempting to implement a
"command" (as in org.apache.felix.shell.Command), but the actual
execute() method is not being invoked... I'll put some snippets and
some run time output in her
[
https://issues.apache.org/jira/browse/FELIX-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617457#action_12617457
]
Richard S. Hall commented on FELIX-595:
---
I have updated my local workspace to the R4.1
[
https://issues.apache.org/jira/browse/FELIX-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier reassigned FELIX-649:
---
Assignee: Clement Escoffier
> "Expecting to find object/array on stack" Error when ask
"Expecting to find object/array on stack" Error when asking for instance of an
iPOJO component
--
Key: FELIX-649
URL: https://issues.apache.org/jira/browse/FELIX-649
Marcel Offermans wrote:
Niclas Hedhman wrote:
On Monday 28 July 2008 14:33, Marcel Offermans wrote:
I'd prefer a name that reflects the main features of this logger. Something
like plugable logger, or log adapter.
Main feature; Interception of calls to many/most existing
Niclas Hedhman wrote:
> On Monday 28 July 2008 14:33, Marcel Offermans wrote:
>
>> I'd prefer a name that reflects the main features of this logger. Something
>> like plugable logger, or log adapter.
>>
>
> Main feature; Interception of calls to many/most existing Log framework in
> legac
FYI, we have two issues for core and compendium:
http://issues.apache.org/jira/browse/FELIX-514
http://issues.apache.org/jira/browse/FELIX-595
-> richard
Alin Dreghiciu wrote:
Hi guys,
Are there any plans when Felix will implement the 4.1.0 OSGi core
specs? For me important will be the
Niclas Hedhman wrote:
On Monday 28 July 2008 14:33, Marcel Offermans wrote:
I'd prefer a name that reflects the main features of this logger. Something
like plugable logger, or log adapter.
Main feature; Interception of calls to many/most existing Log framework in
legacy code that is
On Monday 28 July 2008 14:33, Marcel Offermans wrote:
> I'd prefer a name that reflects the main features of this logger. Something
> like plugable logger, or log adapter.
Main feature; Interception of calls to many/most existing Log framework in
legacy code that is OSGi-enabled without being OS
Marcel Offermans wrote:
I'd prefer a name that reflects the main features of this logger. Something
like plugable logger, or log adapter. We have not made up these type of names
for our other components, so why start here?
That is not true, we have iPOJO, for example, but I supposed we could
26 matches
Mail list logo
