Hi
I can reproduce this. And worse still, it actually prevents the framework from
starting under Linux.
The situation is that the ExtensionManager wants to parse the os.version system
property into an OSGi Version. the os.version seems to be based on the kernel
version, which in my case of
Tuomas Kiviaho created FELIX-4694:
-
Summary: Support binding configuration to all registrations with
the corresponding PID
Key: FELIX-4694
URL: https://issues.apache.org/jira/browse/FELIX-4694
Hi Felix,
You are correct; it looks like the ExtensionManager is trying to parse my
os version.
In the initial mail I sent, I attached the logs, but it seems that @dev
list does like attachments ?
Here is a copy/past of the compile error logs (i don't have applied your
patch from the FELIX-4692
Hi
Ok, there seems to be a larger problem to this, it seems.
The ExtensionManager creates native capabilities in the
ExtensionManager.buildNativeCapabilites() method. This method gets the
PROCESSOR, OS_NAME, and OS_VERSION framework properties to build this
capability.
On the other hand the
Felix Meschberger created FELIX-4695:
Summary: Normalize os.version system property in framework
properties
Key: FELIX-4695
URL: https://issues.apache.org/jira/browse/FELIX-4695
Project: Felix
Felix Meschberger created FELIX-4696:
Summary: Improve native OS version sanitation
Key: FELIX-4696
URL: https://issues.apache.org/jira/browse/FELIX-4696
Project: Felix
Issue Type:
[
https://issues.apache.org/jira/browse/FELIX-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-4696:
-
Attachment: FELIX-4696.patch
Proposed patch taking code from the
Hi
I have reported FELIX-4695 [1] with two potential patches. I think the Felix
class patch is correct, while the ExtensionManager patch is probably sufficient
for this problem.
I would prefer to patch the Felix class at the expense of the
org.osgi.framework.os.version property not exposing
Hi Marcel,
I very much like the idea of a separate builder class. It will make the
transition very smooth. We can also package it in an extra bundle but I
do not think there is a technical need for it. So I propose to simply
add the new syntax in a separate package.
if we want to remove the
J.W. Janssen created FELIX-4697:
---
Summary: Error parsing the default gosh_profile.
Key: FELIX-4697
URL: https://issues.apache.org/jira/browse/FELIX-4697
Project: Felix
Issue Type: Bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/10/14 13:38, Guillaume Nodet wrote:
Closing this vote with 5 +1s.
Is it me, or are the artifacts for this release missing? Can't seem to
find them in felix-dist?!
- --
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software
[
https://issues.apache.org/jira/browse/FELIX-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14209950#comment-14209950
]
Marcel Offermans commented on FELIX-4697:
-
Should we re-open that issue and figure
Hello Christian,
On 13 Nov 2014 at 14:16:01 , Christian Schneider (ch...@die-schneider.net)
wrote:
I very much like the idea of a separate builder class. It will make the
transition very smooth. We can also package it in an extra bundle but I
do not think there is a technical need for it. So
[
https://issues.apache.org/jira/browse/FELIX-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho updated FELIX-4694:
--
Component/s: File Install
Support binding configuration to all registrations with the
[
https://issues.apache.org/jira/browse/FELIX-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-4685.
--
Resolution: Fixed
Assignee: Clement Escoffier
I've re-deployed the handler on
15 matches
Mail list logo
