Fairouz,
I'd like to move this discussion to the users mailing list since you have
usage concerns.
I'm not exactly an expert, but I have successfully deployed iPOJO
components in an OSGi environment without those errors. I'm not sure if
you're using java annotations or XML, but I prefer annotati
I see your point, but if you cannot be assured that your machine is
secure, then all bets are pretty much off anyway.
-> richard
On 3/22/12 11:20 , Guillaume Nodet wrote:
What I mean is that the URLClassloader does the check each time a resource
is loaded using the JarFile, and I think Felix s
What I mean is that the URLClassloader does the check each time a resource
is loaded using the JarFile, and I think Felix should somehow do the same
in order to be secured.
On Thu, Mar 22, 2012 at 16:17, Guillaume Nodet wrote:
> THat's my point, it only happen at install time, which means it's n
THat's my point, it only happen at install time, which means it's not
really secured. I think it has to be done each time a class or resource is
loaded else, anyone can change the jar file in the cache folder after it
has been installed and no verification is done.
I think that's not really good,
Hi,
Am 22.03.2012 um 15:00 schrieb Marcel Offermans:
> AFAICT the new spec is backwards compatible. As long as you don't use new
> functionality, nothing changes.
>
Probably true. The reason we went for the backport instead of using
the snapshot (besides maven releas
On Mar 22, 2012, at 14:30 PM, Felix Meschberger wrote:
> Hi,
>
> Am 21.03.2012 um 21:01 schrieb Marcel Offermans:
>
>> On Mar 21, 2012, at 17:07 PM, Bram de Kruijff wrote:
>>
>>> On Wed, Mar 21, 2012 at 2:55 PM, Felix Meschberger
>>> wrote:
Hi,
Am 20.03.2012 um 21:47 schrieb M
Hi,
Am 21.03.2012 um 21:01 schrieb Marcel Offermans:
> On Mar 21, 2012, at 17:07 PM, Bram de Kruijff wrote:
>
>> On Wed, Mar 21, 2012 at 2:55 PM, Felix Meschberger
>> wrote:
>>> Hi,
>>>
>>> Am 20.03.2012 um 21:47 schrieb Marcel Offermans:
>>>
Within a different open source project (Amda
The verfication is done in the security provider (only happens if installed).
regards,
Karl
On Thu, Mar 22, 2012 at 1:24 PM, Guillaume Nodet wrote:
> I'm trying to understand how Felix verify the classes signatures but I
> don't see anything around that.
> It seems to me that in a non OSGi envi
[
https://issues.apache.org/jira/browse/FELIX-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Offermans reassigned FELIX-3402:
---
Assignee: Marcel Offermans
> DependencyManager stop can trigger IndexOutOfBoundsE
I'm trying to understand how Felix verify the classes signatures but I
don't see anything around that.
It seems to me that in a non OSGi environment, the classes will be verified
by the class loader when loaded from a jar mainly because the
java.util.jar.JarFile does the signature verification when
[
https://issues.apache.org/jira/browse/FELIX-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bram de Kruijff updated FELIX-3402:
---
Attachment: FELIX-3402-sync.patch
> DependencyManager stop can trigger IndexOutOfBoundsEx
DependencyManager stop can trigger IndexOutOfBoundsException
Key: FELIX-3402
URL: https://issues.apache.org/jira/browse/FELIX-3402
Project: Felix
Issue Type: Bug
Affects Versio
The semantic versioning tool only check APIs and while those have not
changed, new configuration properties and new behaviors have been added
while still being compatible, so I think it warrant a change of the minor
version, and that would still be inlined with the real meaning of semantic
versioni
13 matches
Mail list logo
