from:"Richard S. Hall"

Re: Felix-Resolver: Fragment was not selected for attachment

2018-08-07 Thread Richard S. Hall





On 7/24/18 07:35 , patrick.pus...@telekom.de wrote:

Hi all,

during resolving of several bundles with the felixResolver I get a 
ResolutionException: org.apache.felix.resolver.reason.ReasonException: Fragment 
was not selected for attachment: com.xx.yy version=1.7.0.201806111251

But the unresolvedRequirments are 0 in the exception. This confuses me, why an 
exception is thrown but no unresolved Req. are there?

I found the origin of the error in that class: 
https://github.com/eclipse/rt.equinox.framework/blob/eb0f2a037d2e03d66f0eca857b16838745bbb2a2/bundles/org.eclipse.osgi/felix/src/org/apache/felix/resolver/Candidates.java
but it's hard for me to understand the comment:
  // For any fragment that wasn't selected, remove the
  // current host as a potential host for it and remove it
  // as a dependent on the host. If there are no more
// potential hosts for the fragment, then mark it as
// unselected for later removal.

Could someone explain me what happens during resolving here or even explain the 
code comment to me?


I'm not sure what's going on, but the only time the "else" should get 
triggered is if you are installing multiple versions of a given 
fragment. In that case, only the highest version of that fragment is 
"selected" and every other lower version hits the "else" and is removed 
as the comment above describes. So, first of all, are you installing 
multiple versions of the same fragment (i.e., same symbolic name)?


What it sounds like is happening, is that some module you are trying to 
resolve has a dependency (directly or indirectly) on something provided 
by an older version of the fragment, but that fragment isn't selected 
for merging into a host because there is a newer version of the fragment.


Whether or not that makes sense with respect to your use case, I have no 
idea, but that appears to be the only plausible explanation with the 
info provided.


-> richard



I tested with bndtools 3.5.0, 4.0.0 and 4.1.0-SNAPSHOT. All are producing the 
same ResolutionException.

Thanks and best regards,
Patrick





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: About config properties: felix.auto.install

2017-08-31 Thread Richard S. Hall


The value's format is just a space-delimited list of URLs.

To install exploded bundles, the Felix framework supports a URL in the 
form of:


    reference:file:/path/to/exploded/bundle/directory

-> richard


On 8/30/17 22:11 , duxiutao wrote:

Hello felix guys:
I have read this from this link 
[http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.html]

"felix.auto.install. - Space-delimited list of bundle URLs to automatically install 
when Felix is started, where  is the start level into which the bundle will be installed 
(e.g., felix.auto.install.2)."

Felix.auto.install will install the url automatically, but the doc doesn't 
describe the value's format, can I specify a directory rather than a war file?

Thanks.




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix: bundle double update with osgi refresh

2017-05-12 Thread Richard S. Hall


On 5/12/17 07:38 , Karl Pauls wrote:

For example I have a running osgi framework with two bundles: bundleA and 
bundleB
which jars are in JARS folder. BundleB depends on BundleA. Now I replace 
bundleA jar
in JARS folder.

Is there any way to refresh framework (there is new version of bundleA in JARS 
folder)
and not to start/stop bundleA twice?

Yes, you basically don't just update() but call stop() then update()
and finally start() on bundleA again.


Yes, that's what I was going to say, but what Karl really meant was 
stop, update, refresh, then start on bundle A.


It's the only way.

-> richard


regards,

Karl


Best regards, Alex



Среда, 10 мая 2017, 16:55 +03:00 от "Richard S. Hall" <he...@ungoverned.org>:

On 5/10/17 08:16 , Alex Sviridov wrote:

Hi all

I use Apache Felix 5.4.0 and I have two bundles: bundleA and bundleB. BundleB 
depends on bundleA.

I update bundleA and after that run the following code to do osgi refresh:

Bundle systemBundle  = bcx . getBundle ( 0 );
FrameworkWiring frameworkWiring  = systemBundle . adapt ( FrameworkWiring . 
class );
frameworkWiring . refreshBundles ( null );
(from here  http://stackoverflow.com/a/23361835/5057736 )

This code does the following: it stops and starts bundleA and stops and starts 
bundleB.

But why bundleA? I am asking because in result bundleA is two times updated. Is 
this a bug or what?

The first stop/start is when you do the update, the second is when you
do the refresh. The former is historical, since that is the way update()
was defined in the first version of the spec (I believe). Later versions
of the spec where refreshing was introduced didn't change this behavior
for backward compatibility reasons.

If refresh were there from the beginning, then it would have likely been
better to have update() simply prepare the updated version and refresh
enact it.

-> richard


Best regards, Alex


-
To unsubscribe, e-mail:  users-unsubscr...@felix.apache.org
For additional commands, e-mail:  users-h...@felix.apache.org



--
Alex Sviridov






-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix: bundle double update with osgi refresh

2017-05-10 Thread Richard S. Hall


On 5/10/17 08:16 , Alex Sviridov wrote:

Hi all

I use Apache Felix 5.4.0 and I have two bundles: bundleA and bundleB. BundleB 
depends on bundleA.

I update bundleA and after that run the following code to do osgi refresh:

Bundle systemBundle  = bcx . getBundle ( 0 );
FrameworkWiring frameworkWiring  = systemBundle . adapt ( FrameworkWiring . 
class );
frameworkWiring . refreshBundles ( null );
(from here http://stackoverflow.com/a/23361835/5057736 )

This code does the following: it stops and starts bundleA and stops and starts 
bundleB.

But why bundleA? I am asking because in result bundleA is two times updated. Is 
this a bug or what?


The first stop/start is when you do the update, the second is when you 
do the refresh. The former is historical, since that is the way update() 
was defined in the first version of the spec (I believe). Later versions 
of the spec where refreshing was introduced didn't change this behavior 
for backward compatibility reasons.


If refresh were there from the beginning, then it would have likely been 
better to have update() simply prepare the updated version and refresh 
enact it.


-> richard



Best regards, Alex



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix not behaving as per tutorial

2017-05-04 Thread Richard S. Hall

On 5/3/17 15:23 , Dan Hartman wrote:

Hi there,

I followed the tutorial here:

http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.html

I can't find any felix-1.0.3 directory (nor one appropriately named
like that, according to the version current to the tutorial page).

When I search the tutorial folder, there are quite a number of
"bin/felix.jar" occurrences scattered around, but none of them behave
like the tutorial. A prompt does start, but instead of having a "->"
sigil, it's "g!". The "hello iPOJO" message starts emitting every so
often.

After typing "java -jar bin/felix.java", I didn't have to do anything
to start the hello example emitting a message. There's no ps command,
and when I type help, I get a LOT of choices, and there are three
categories of them, felix, ipojo, and obr.

See the attached screenshot.

What am I doing wrong? It seems like the tutorial is not up to date
with the tutorial archive zip.

You aren't doing anything wrong, I would guess. It just sounds like the
tutorial is woefully out of date.

Felix now has a new command shell, called Gogo, which is why you see so
much of a difference between the prompts and commands. You should use
"lb" to list the bundles. Commands for starting/stopping are the same,
although it is doubtful the "arch" command would be working with the
newer shell, since that is provided by iPOJO for the old shell.

I think in the original tutorial the bundles also auto-started, so that
part works the same.

-> richard

Thanks in advance!

Dan

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: may have found a resolver bug

2016-05-26 Thread Richard S. Hall


On 5/26/16 08:48 , Raymond Auge wrote:

I didn't because I wasn't sure it was even a real issue.

but I can if you like.


Always a good idea, since it is more likely to get seen. Thanks.

-> richard



On Thu, May 26, 2016 at 8:06 AM, Richard S. Hall <he...@ungoverned.org>
wrote:


Did you open an issue in JIRA?


On 5/25/16 23:21 , Raymond Auge wrote:


Hello everyone,

I'm not completely sure, but I think I have found a bug in the felix
resolver.

It's a little hard to reproduce, but I have done so in a test I've
submitted in this PR [1] to bnd (because I was trying to use the resolver
through bndlib and so it was far simpler to reproduce there).

You'll note that the travis failure is actually the test reproducing the
exact failure scenario.

The problem "seems" to stem from a scenario where a set of duplicated
resources results in miss handling of a capability index (I speculate
during the second iteration of the duplicated resource).

The issue is in resolver code that is far more complex than I have a
stomach for, but I would appreciate if someone could take a look at it.

Sincerely,
- Ray

[1] https://github.com/bndtools/bnd/pull/1472



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: may have found a resolver bug

2016-05-26 Thread Richard S. Hall


Did you open an issue in JIRA?

On 5/25/16 23:21 , Raymond Auge wrote:

Hello everyone,

I'm not completely sure, but I think I have found a bug in the felix
resolver.

It's a little hard to reproduce, but I have done so in a test I've
submitted in this PR [1] to bnd (because I was trying to use the resolver
through bndlib and so it was far simpler to reproduce there).

You'll note that the travis failure is actually the test reproducing the
exact failure scenario.

The problem "seems" to stem from a scenario where a set of duplicated
resources results in miss handling of a capability index (I speculate
during the second iteration of the duplicated resource).

The issue is in resolver code that is far more complex than I have a
stomach for, but I would appreciate if someone could take a look at it.

Sincerely,
- Ray

[1] https://github.com/bndtools/bnd/pull/1472




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Issue with BundleListener/Resolved events

2016-01-12 Thread Richard S. Hall



On 1/12/16 11:59 , Thomas Draier wrote:

On Tue, Jan 12, 2016 at 5:45 PM Richard S. Hall <he...@ungoverned.org>
wrote:


So, are you saying that when you get a resolved event for some arbitrary
bundle, you are running into issues because some of its dependencies are
not yet treated as if they are resolved? What is the symptom you see?


Well, I just did receive the resolved event for the dependencies (Y,Z)
after receiving the event for the bundle having the dependencies (X),
instead of the opposite. Of course, it's not always the case, it happens
for some bundles only, as the order is random. But yes, all of them are
marked as resolved when I get the first event, and all events will
eventually be sent.


What I'm trying to get at is, why is this problematic for you if you get 
them out of order? Are you try to load a class and it fails, for 
example. Or does it just make you uncomfortable?


-> richard





Yes, that's the reverse order, not that this terminology is super
important.


Ok, whatever, just to be sure we were talking of the same order.

Thomas




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Issue with BundleListener/Resolved events

2016-01-12 Thread Richard S. Hall

I think you may be reading more into the spec than what is there. 
Technically, a resolve is atomic so all bundles are effectively resolved 
at the same time, which means the events occur at the same time, but 
since we can only deliver one at a time, then you receive them in some 
arbitrary order with respect to dependencies. I don't think the spec 
requires events to be delivered in reverse dependency order. Further, it 
is fully possible since dependencies can be in the form of [really 
large] cycles, thus ordering is not clear.


Why do you care about this ordering?

-> richard

On 1/12/16 09:26 , Thomas Draier wrote:

Hi there,

I have an issue when listening to resolved event - my BundleListener
actually doesn't receive the events in the correct order, where the bundle
resolution really happened.
Let's say we have bundle X , which has a Import-Package: org.aPackage , and
a bundle Y , which Export-Package: org.aPackage . I install both (they goes
to installed state), and then try to start X. X and Y can be resolved, but
Y should be resolved first - however, the events are sent in random order.

More precisely, Felix tries to resolve X by calling
StatefulResolver.resolve(), which then delegates to ResolverImpl.resolve()
- this one will detect that Y needs to be resolved first . Y is then
resolved and added to the wireMap. At the end of StatefulResolver
.resolve(), all resolved events are sent by fireResolvedEvents(wireMap) .
Unfortunately, the order in which the wireMap has been filled is lost, so
the order of bundle resolution - I can receive a resolved event for X
before Y or the opposite, randomly.

Is this something that should/could be fixed ? It should be ok to change
the type of the wireMap to keep ordering of inserts. According to the
specifications, "each handler must receive the events in the same order as
the events were posted" .. here the events are not posted in the same order
as they actually happened .. ?

Regards,




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix ResolveContext

2015-11-19 Thread Richard S. Hall



On 11/18/15 21:08 , David Leangen wrote:

Hi!

If I want to use the Felix Resolver, I need a ResolveContext. I noticed that 
Felix has one, but it is private.

How could I get an instance of the Felix ResolveContext so that I may use the 
Resolve service?


You don't. It is tied to the implementation details of the framework. 
You pretty much need to implement your own resolve context.


-> richard




Cheers,
=David



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Uninstalled API bundle, yet implementation still resolves and starts

2015-11-05 Thread Richard S. Hall


On 11/5/15 05:04 , Neil Bartlett wrote:

Hi Richard,

I agree with you, and I understand why the existing active bundles remain wired 
to the uninstalled bundle until refresh. However it sounded like the newly 
installed bundle was wiring to the uninstalled bundle. This doesn’t sound 
right… the framework shouldn’t create new wires into uninstalled bundles, 
should it?


It depends, but it is certainly not wrong to do so, since clearly the 
packages are still available to the system.


I have made an argument before that installing to stale packages is 
reasonable because it results in fewer class spaces if the framework is 
not refreshed. I still think this argument is valid, although I admit 
that you could differentiate between stale packages from an updated 
bundle versus stale packages from an uninstalled bundle. However, I'm 
not sure it is worthwhile to draw that distinction, since if you are 
uninstalling, you should do a refresh. Period.


Peter has argued before on this top that any update/uninstall should 
*always* be followed by a refresh, which I don't completely agree with 
but I do think that in general it is the right thing to do and only 
people who know what they are doing shouldn't refresh.


For example, if you have an bundle that exports some package and you 
make changes that only impact internal packages and you really don't 
want to bring down the entire system (potentially losing state, etc.), 
then it is possible to update that bundle and not refresh so the system 
can continue to use the stale packages.


Of course, this would only work if the bundle in question was importing 
what it exported. Assuming it was, then the resolver is free to wire it 
to its own stale packages.


As you can see, though, this is only for people who really know what 
they are doing, which is why 99% of the time I agree with Peter on this 
subject that you should refresh.


-> richard


This assumes I have correctly understood the scenario as described by Maurice.

Neil


On 4 Nov 2015, at 13:31, Richard S. Hall <he...@ungoverned.org> wrote:


On 11/4/15 06:52 , i...@cuhka.com <mailto:i...@cuhka.com> wrote:

I 'solved' it by restarting the device. I rather don't, as I like solution 
where I can upgrade functionality without shutting down.

You don't need to shut down, you just need to refresh the framework. If you update A and 
S, the old version of A is still hanging around because X1 is using it. So, you have your 
framework state in somewhat of an "in between" stage. Refreshing things gets 
everything back in shape. There are very few rare instances where you would not want to 
refresh after an update or an uninstall...99% of the time, you should refresh after 
either of those operations.

-> richard


Basically my structure is as follows:
Bundle A: API
Bundle S: Service (uses and provides some API implementation from A)
Bundle X1..N: Provide functionality for S using the extender pattern, use and 
provide some API implementation from A)
I updated A and S. For the X bundles the API change wasn't important, but for S 
it was. Somehow S still picked up old-A, while I had uninstalled old-A (and 
old-S). I have updated my tooling from 'THE OSGi plugin' from Gradle to use 
'the bnd OSGi plugin'. I noticed that the old plugin would automatically add 
A's package as Export-Bundle, while with bnd's plugin I had to do that myself. 
Maybe that caused the problem.

Maurice.

Citeren Neil Bartlett <njbartl...@gmail.com>:


On 4 Nov 2015, at 11:07, Robert Onslow <robert.ons...@gmail.com> wrote:

Delete the directory called felix-cache??

No, in his second email he says that other bundles are still running that use 
the old API. So we’re talking about a series of changes made in a running OSGi 
Framework, and it wouldn’t be a good idea to delete the storage directory 
underneath a running framework.

These changes *should* work. Best guess is that the implementation bundle ships 
its own copy of the API bundle.

As a general rule, you should do a refresh after a series of changes to bundle 
states (installs, uninstalls or updates). You can do this simply with the 
“refresh” command in the Gogo shell. In this scenario, a refresh would cause 
all the bundles that import from the API bundle to stop and revert to INSTALLED 
state.

Regards,
Neil



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
<mailto:users-unsubscr...@felix.apache.org>
For additional commands, e-mail: users-h...@felix.apache.org 
<mailto:users-h...@felix.apache.org>



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Uninstalled API bundle, yet implementation still resolves and starts

2015-11-05 Thread Richard S. Hall




On 11/5/15 12:26 , Neil Bartlett wrote:

Thanks Richard, that’s very clear.

It almost makes me think that, if we were designing the OSGi APIs all over 
again, management agents should be required to open a batch operation in order 
to do any install/update/uninstall. The operations in the batch would not take 
effect in the framework until it was committed, which would be equivalent to a 
refresh.


Yes, Tom Watson and I discussed this very thing some time ago...we both 
agreed that would make much more sense and would technically be nicer too.


-> richard

p.s. Sorry for the mistakes in my original response. For clarification, 
"installing to stale packages" should have been "wiring to stale 
packages" and "this top" should have been "this topic".




Neil




On 5 Nov 2015, at 14:31, Richard S. Hall <he...@ungoverned.org> wrote:

On 11/5/15 05:04 , Neil Bartlett wrote:

Hi Richard,

I agree with you, and I understand why the existing active bundles remain wired 
to the uninstalled bundle until refresh. However it sounded like the newly 
installed bundle was wiring to the uninstalled bundle. This doesn’t sound 
right… the framework shouldn’t create new wires into uninstalled bundles, 
should it?

It depends, but it is certainly not wrong to do so, since clearly the packages 
are still available to the system.

I have made an argument before that installing to stale packages is reasonable 
because it results in fewer class spaces if the framework is not refreshed. I 
still think this argument is valid, although I admit that you could 
differentiate between stale packages from an updated bundle versus stale 
packages from an uninstalled bundle. However, I'm not sure it is worthwhile to 
draw that distinction, since if you are uninstalling, you should do a refresh. 
Period.

Peter has argued before on this top that any update/uninstall should *always* 
be followed by a refresh, which I don't completely agree with but I do think 
that in general it is the right thing to do and only people who know what they 
are doing shouldn't refresh.

For example, if you have an bundle that exports some package and you make 
changes that only impact internal packages and you really don't want to bring 
down the entire system (potentially losing state, etc.), then it is possible to 
update that bundle and not refresh so the system can continue to use the stale 
packages.

Of course, this would only work if the bundle in question was importing what it 
exported. Assuming it was, then the resolver is free to wire it to its own 
stale packages.

As you can see, though, this is only for people who really know what they are 
doing, which is why 99% of the time I agree with Peter on this subject that you 
should refresh.

-> richard


This assumes I have correctly understood the scenario as described by Maurice.

Neil


On 4 Nov 2015, at 13:31, Richard S. Hall <he...@ungoverned.org 
<mailto:he...@ungoverned.org>> wrote:


On 11/4/15 06:52 , i...@cuhka.com <mailto:i...@cuhka.com> <mailto:i...@cuhka.com 
<mailto:i...@cuhka.com>> wrote:

I 'solved' it by restarting the device. I rather don't, as I like solution 
where I can upgrade functionality without shutting down.

You don't need to shut down, you just need to refresh the framework. If you update A and 
S, the old version of A is still hanging around because X1 is using it. So, you have your 
framework state in somewhat of an "in between" stage. Refreshing things gets 
everything back in shape. There are very few rare instances where you would not want to 
refresh after an update or an uninstall...99% of the time, you should refresh after 
either of those operations.

-> richard


Basically my structure is as follows:
Bundle A: API
Bundle S: Service (uses and provides some API implementation from A)
Bundle X1..N: Provide functionality for S using the extender pattern, use and 
provide some API implementation from A)
I updated A and S. For the X bundles the API change wasn't important, but for S 
it was. Somehow S still picked up old-A, while I had uninstalled old-A (and 
old-S). I have updated my tooling from 'THE OSGi plugin' from Gradle to use 
'the bnd OSGi plugin'. I noticed that the old plugin would automatically add 
A's package as Export-Bundle, while with bnd's plugin I had to do that myself. 
Maybe that caused the problem.

Maurice.

Citeren Neil Bartlett <njbartl...@gmail.com>:


On 4 Nov 2015, at 11:07, Robert Onslow <robert.ons...@gmail.com> wrote:

Delete the directory called felix-cache??

No, in his second email he says that other bundles are still running that use 
the old API. So we’re talking about a series of changes made in a running OSGi 
Framework, and it wouldn’t be a good idea to delete the storage directory 
underneath a running framework.

These changes *should* work. Best guess is that the implementation bundle ships 
its own copy of the AP

Re: Uninstalled API bundle, yet implementation still resolves and starts

2015-11-04 Thread Richard S. Hall



On 11/4/15 06:52 , i...@cuhka.com wrote:
I 'solved' it by restarting the device. I rather don't, as I like 
solution where I can upgrade functionality without shutting down.


You don't need to shut down, you just need to refresh the framework. If 
you update A and S, the old version of A is still hanging around because 
X1 is using it. So, you have your framework state in somewhat of an "in 
between" stage. Refreshing things gets everything back in shape. There 
are very few rare instances where you would not want to refresh after an 
update or an uninstall...99% of the time, you should refresh after 
either of those operations.


-> richard



Basically my structure is as follows:
Bundle A: API
Bundle S: Service (uses and provides some API implementation from A)
Bundle X1..N: Provide functionality for S using the extender pattern, 
use and provide some API implementation from A)
I updated A and S. For the X bundles the API change wasn't important, 
but for S it was. Somehow S still picked up old-A, while I had 
uninstalled old-A (and old-S). I have updated my tooling from 'THE 
OSGi plugin' from Gradle to use 'the bnd OSGi plugin'. I noticed that 
the old plugin would automatically add A's package as Export-Bundle, 
while with bnd's plugin I had to do that myself. Maybe that caused the 
problem.


Maurice.

Citeren Neil Bartlett :


On 4 Nov 2015, at 11:07, Robert Onslow  wrote:

Delete the directory called felix-cache??


No, in his second email he says that other bundles are still running 
that use the old API. So we’re talking about a series of changes made 
in a running OSGi Framework, and it wouldn’t be a good idea to delete 
the storage directory underneath a running framework.


These changes *should* work. Best guess is that the implementation 
bundle ships its own copy of the API bundle.


As a general rule, you should do a refresh after a series of changes 
to bundle states (installs, uninstalls or updates). You can do this 
simply with the “refresh” command in the Gogo shell. In this 
scenario, a refresh would cause all the bundles that import from the 
API bundle to stop and revert to INSTALLED state.


Regards,
Neil




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Bundle can't find its own classes: NoClassDefFoundError

2015-10-30 Thread Richard S. Hall


On 10/30/15 15:19 , i...@cuhka.com wrote:
Yes, indeed I'm using THE osgi plugin, and I didn't do any 
Bundle-Classpath editing, nor did bnd. Anyway, after 'ctrl-alt-del' of 
my Felix it all seems to be ok. While I still don't grasp while it 
occurs, what can make it hapen, I can continue.


If I had to guess then, I'd say you somehow updated your bundle and got 
it in a strange state and didn't do a refresh of the framework after 
updating.


-> richard



Maurice.
Citeren Paulo Renato de Athaydes :

You should not mess with the Bundle-Classpath unless you know exactly 
what you're doing.
Have a look at your bundle's Manifest, make sure the Bundle-ClassPath 
entry is not there, or if it is, it's just a dot.

Otherwise you will get the kind of problem you're having.
The osgi plugin (I assume you're using THE osgi plugin, I mean, the 
one called 'osgi') definitely won't magically add this to your Bundle.

Renato




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Bundle can't find its own classes: NoClassDefFoundError

2015-10-30 Thread Richard S. Hall


On 10/30/15 13:46 , i...@cuhka.com wrote:
After a flying start with OSGi'ing my application I'm running into 
some amazements, or frustrations as I seem to spend more time managing 
OSGi than actually creating stuff...


Anyway, my bundle resolves fine, but when it starts I get a 
NoClassDefFoundError on a class that is inside the bundle. I've opend 
the corresponding jar file, and sure, it is there.


What can possibly cause this?


Perhaps you didn't specify your Bundle-ClassPath correctly...

-> richard



Maurice.




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Bundle can't find its own classes: NoClassDefFoundError

2015-10-30 Thread Richard S. Hall


On 10/30/15 15:42 , Milen Dyankov wrote:

This seems to happen with felix (version 4.6 in my case) from time to time.
Basically I have some symlinks in `felix/bundle` folder pointing to the jar
files generated by my IDE/build tool. Someties (haven't tried to figure out
why) it will not notice the JAR has changed and the only way to force it is
to clean the `felix/felix-cache`. As I'm only using plain felix for demo
purposes it is not a big deal for me (I always clean the cache) but I can
imagine how frustrating it would be if I was to build something serious
this way.


I'm not exactly sure what you mean, the framework will never notice that 
the bundles have changed and do anything. It only does what it is told.


If you are saying that you are doing an explicit update on a bundle and 
the framework doesn't show the updated content of the bundle, even after 
a framework refresh, then this would be a significant bug. If that is 
the case, then it would be great to get more information. It would 
definitely be surprising, but certainly not out of the realm of possibility.


-> richard


Best,
Milen



On Fri, Oct 30, 2015 at 8:21 PM, Richard S. Hall <he...@ungoverned.org>
wrote:


On 10/30/15 15:19 , i...@cuhka.com wrote:


Yes, indeed I'm using THE osgi plugin, and I didn't do any
Bundle-Classpath editing, nor did bnd. Anyway, after 'ctrl-alt-del' of my
Felix it all seems to be ok. While I still don't grasp while it occurs,
what can make it hapen, I can continue.


If I had to guess then, I'd say you somehow updated your bundle and got it
in a strange state and didn't do a refresh of the framework after updating.

-> richard




Maurice.
Citeren Paulo Renato de Athaydes <renatoathay...@hotmail.com>:

You should not mess with the Bundle-Classpath unless you know exactly

what you're doing.
Have a look at your bundle's Manifest, make sure the Bundle-ClassPath
entry is not there, or if it is, it's just a dot.
Otherwise you will get the kind of problem you're having.
The osgi plugin (I assume you're using THE osgi plugin, I mean, the one
called 'osgi') definitely won't magically add this to your Bundle.
Renato




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

2015-10-27 Thread Richard S. Hall

On 10/27/15 13:27 , Balázs Zsoldos wrote:

Also, we used to package some framework services separately (e.g.,
PackageAdmin, etc.) and some framework still might, so this assumption also
is not correct.

I am wondering why PackageAdmin had to be re-implemented. If it was
possible to re-implement it based on other features of OSGi Core, does that
mean that OSGi Core contained something that it should not have? If some
services can be implemented based on others, they are more like libraries
than part of the core.

I didn't say it was re-implemented, I said it was packaged separately.
We still do, for example, package the permission-related services
separately. It did, however, use some special hooks to do what it needed
to do.

-> richard

E.g.: BundleTracker and ServiceTracker is part of a very helpful library.
It can be implemented based on OSGi Core. I am probably alone with the
opinion that is should not have been moved into OSGi Core. Also, it is
another discussion (I am sure this was discussed internally before
releasing OSGi Core 5).

On Tue, Oct 27, 2015 at 6:08 PM, Richard S. Hall <he...@ungoverned.org>
wrote:

On 10/27/15 11:27 , Balázs Zsoldos wrote:

@David:

I know about the *org.osgi.framework.system.**packages.extra* property,
but
that is about another use-case.

*org.osgi.framework.system.**packages.extra *can be used to extend the
list
of system packages.
*org.osgi.framework.system.**packages* can be used to reduce the list of
the system packages.

I want to reduce the list of system packages as some packages are coming
from bundles. More specifically, I want to list only those packages that I
actually need from the JDK. Reason: Many packages are incomplete or buggy
in the JDK: javax.transaction.*, javax.xml.*...

@Andy:

The text at

https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
says:* Framework launching property identifying packages which the
system
bundle must export.*

"Must" does not mean that only those packages should be exported by the
system bundle.

@Everyone:

Questions:

- What is the exact meaning of system packages from the perspective of
this setting? In my opinion, the list of packages that are coming
outside
the OSGi container. org.osgi.* packages do not come outside from the
OSGi
container.
- Could the org.osgi.* packages come from custom bundles? I think, no.
- Can you write an application that does not need any of the
org.osgi.*
package? I think you cannot. At least one bundle has to implement an
Activator to have any kind of functionality in the system. Otherwise
the
bundles will be resolved, but they will do nothing (not even a static
block
will be called).
- Can you imagine any use-case where exporting org.osgi.* packages by
the system bundle could cause any issue? I cannot.

Also, we used to package some framework services separately (e.g.,
PackageAdmin, etc.) and some framework still might, so this assumption also
is not correct.

- Is it an extra work that org.osgi.* packages have to be appended if

system.packages are overridden? Yes, always.

Sure, this is correct, but not really relevant to the meaning of system
packages.

-> richard

If we answer these questions, we will come to the conclusion (at least I
:)
) that org.osgi.* packages should always be exported by the system bundle.
They are not in the scope of the meaning of system.packages setting.

Kind regards,
*Balázs **Zsoldos*

On Tue, Oct 27, 2015 at 3:21 PM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

Yes, that's precisely what the

org.osgi.framework.system.packages.extra was designed for. That way
you don't need to remember what the framework puts on
org.osgi.framework.system.packages in order to augment it.

Best regards,

David

On 27 October 2015 at 14:18, Andy Lee <thelees.a...@gmail.com> wrote:

If you are trying to extend the set of packages exported by the system
bundle, you should use org.osgi.framework.system.packages.extra. By
specifying org.osgi.framework.system.packages you are overriding the
default value used by the framework, and hence must include the packaged
that are expected to be supplied by the framework.

See

https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES

--Andy

On Tue, Oct 27, 2015 at 10:00 AM, Balázs Zsoldos <

balazs.zsol...@everit.biz>

wrote:

Hi,

I asked this 1-2 years ago, but I think it is worthy to ask it again.

Are you sure that the set of system packages should include the OSGi

core
packages?

In my understanding:

- system packages are the ones coming from outside of the OSGi

container
- osgi core packages are offered by the framework bundle, but they
are
not system packages

In practice:

- If I specify org.osgi.system.packages property for equinox, I do

not
have to define the packages i

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

2015-10-27 Thread Richard S. Hall

On 10/27/15 13:14 , Balázs Zsoldos wrote:

That is not my interpretation. System packages are those packages provided
by the system bundle. From a wiring perspective, all of the JRE packages
look like they are coming from the system bundle just like the OSGi core
packages, so your distinction doesn't really make sense to me.

Seems that we are different :). I interpret rules based on use-cases. I
cannot find any use-case where I wanted to handle framework packages like
JDK packages. On the other hand, I see use-cases where I want to handle
them separately.

It is much more consistent to defines system.packages like,
"system.packages represents all packages that will be exported by the
system bundle", instead of something like "system.packages represents
all packages exported by the system bundle plus some additional packages
that will tacked on but may vary by framework implementation".

Wrong. The extender pattern is based almost wholly around such an approach.

How would you implement the extender pattern without the framework packages?

As an application developer, I don't need to implement the extender
pattern since framework developers have done that for me. It's all about
layers and perspective.

-> richard

On Tue, Oct 27, 2015 at 6:04 PM, Richard S. Hall <he...@ungoverned.org>
wrote:

On 10/27/15 11:27 , Balázs Zsoldos wrote:

@David:

I know about the *org.osgi.framework.system.**packages.extra* property,
but
that is about another use-case.

*org.osgi.framework.system.**packages.extra *can be used to extend the
list
of system packages.
*org.osgi.framework.system.**packages* can be used to reduce the list of
the system packages.

@Andy:

The text at

https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
says:* Framework launching property identifying packages which the
system
bundle must export.*

"Must" does not mean that only those packages should be exported by the
system bundle.

@Everyone:

Questions:

- What is the exact meaning of system packages from the perspective of
this setting? In my opinion, the list of packages that are coming
outside
the OSGi container.

org.osgi.* packages do not come outside from the OSGi

container.
- Could the org.osgi.* packages come from custom bundles? I think, no.
- Can you write an application that does not need any of the
org.osgi.*
package? I think you cannot.At least one bundle has to implement an
Activator to have any kind of functionality in the system. Otherwise
the
bundles will be resolved, but they will do nothing (not even a static
block
will be called).

Wrong. The extender pattern is based almost wholly around such an approach.

-> richard

- Can you imagine any use-case where exporting org.osgi.* packages by

the system bundle could cause any issue? I cannot.
- Is it an extra work that org.osgi.* packages have to be appended if
system.packages are overridden? Yes, always.

Kind regards,
*Balázs **Zsoldos*

On Tue, Oct 27, 2015 at 3:21 PM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

Yes, that's precisely what the

org.osgi.framework.system.packages.extra was designed for. That way
you don't need to remember what the framework puts on
org.osgi.framework.system.packages in order to augment it.

Best regards,

David

On 27 October 2015 at 14:18, Andy Lee <thelees.a...@gmail.com> wrote:

See

https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES

--Andy

On Tue, Oct 27, 2015 at 10:00 AM, Balázs Zsoldos <

balazs.zsol...@everit.biz>

wrote:

Hi,

I asked this 1-2 years ago, but I think it is worthy to ask it again.

Are you sure that the set of system packages should include the OSGi

core
packages?

In m

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

2015-10-27 Thread Richard S. Hall

On 10/27/15 13:33 , Balázs Zsoldos wrote:

As an application developer, I don't need to implement the extender
pattern since framework developers have done that for me. It's all about
layers and perspective.

As a technology developer, how would you implement an extender pattern
without the framework packages? You could not. If those packages are not
exported by the system bundle, you cannot implement the extender pattern.
As an application developer, you could not import a bundle that implements
the extender pattern, as the bundle would not resolve.

You mean that the Framework developers should implement technologies like
Declarative Services and include it into the Framework?

I was using the term "framework developers" in the general sense, not as
in OSGi framework. DS provides application developers a framework for
creating OSGi applications without dependencies on OSGi API. But really,
this is just an argument over semantics and is not germane to the real
issue.

From my perspective, you cannot define system.packages as a value that
depends on framework implementation details to know what the value is.

-> richard

On Tue, Oct 27, 2015 at 6:27 PM, Richard S. Hall <he...@ungoverned.org>
wrote:

On 10/27/15 13:14 , Balázs Zsoldos wrote:

That is not my interpretation. System packages are those packages provided

by the system bundle. From a wiring perspective, all of the JRE packages
look like they are coming from the system bundle just like the OSGi core
packages, so your distinction doesn't really make sense to me.

It is much more consistent to defines system.packages like,
"system.packages represents all packages that will be exported by the
system bundle", instead of something like "system.packages represents all
packages exported by the system bundle plus some additional packages that
will tacked on but may vary by framework implementation".

Wrong. The extender pattern is based almost wholly around such an
approach.

How would you implement the extender pattern without the framework
packages?

As an application developer, I don't need to implement the extender
pattern since framework developers have done that for me. It's all about
layers and perspective.

-> richard

On Tue, Oct 27, 2015 at 6:04 PM, Richard S. Hall <he...@ungoverned.org>
wrote:

On 10/27/15 11:27 , Balázs Zsoldos wrote:

@David:

I know about the *org.osgi.framework.system.**packages.extra* property,
but
that is about another use-case.

*org.osgi.framework.system.**packages.extra *can be used to extend the
list
of system packages.
*org.osgi.framework.system.**packages* can be used to reduce the list of
the system packages.

I want to reduce the list of system packages as some packages are coming
from bundles. More specifically, I want to list only those packages
that I
actually need from the JDK. Reason: Many packages are incomplete or
buggy
in the JDK: javax.transaction.*, javax.xml.*...

@Andy:

The text at

https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
says:* Framework launching property identifying packages which the
system
bundle must export.*

"Must" does not mean that only those packages should be exported by the
system bundle.

@Everyone:

Questions:

- What is the exact meaning of system packages from the
perspective of
this setting? In my opinion, the list of packages that are coming
outside
the OSGi container.

That is not my interpretation. System packages are those packages

provided
by the system bundle. From a wiring perspective, all of the JRE packages
look like they are coming from the system bundle just like the OSGi core
packages, so your distinction doesn't really make sense to me.

org.osgi.* packages do not come outside from the OSGi

container.
- Could the org.osgi.* packages come from custom bundles? I think,
no.
- Can you write an application that does not need any of the
org.osgi.*
package? I think you cannot.At least one bundle has to implement an
Activator to have any kind of functionality in the system.
Otherwise
the
bundles will be resolved, but they will do nothing (not even a
static
block
will be called).

Wrong. The extender pattern is based almost wholly around such an

approach.

-> richard

- Can you imagine any use-case where exporting org.osgi.* packages
by

the system bundle could cause any issue? I cannot.
- Is it an extra work that org.osgi.* packages have to be appended
if
system.packages are overridden? Yes, always.

If we answer these questions, we will come to the conclusion (at least I
:)
) that org.osgi.* packages should alway

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

2015-10-27 Thread Richard S. Hall

On 10/27/15 11:27 , Balázs Zsoldos wrote:

@David:

I know about the *org.osgi.framework.system.**packages.extra* property, but
that is about another use-case.

*org.osgi.framework.system.**packages.extra *can be used to extend the list
of system packages.
*org.osgi.framework.system.**packages* can be used to reduce the list of
the system packages.

@Andy:

The text at
https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
says:* Framework launching property identifying packages which the system
bundle must export.*

"Must" does not mean that only those packages should be exported by the
system bundle.

@Everyone:

Questions:

- What is the exact meaning of system packages from the perspective of
this setting? In my opinion, the list of packages that are coming outside
the OSGi container.

That is not my interpretation. System packages are those packages
provided by the system bundle. From a wiring perspective, all of the JRE
packages look like they are coming from the system bundle just like the
OSGi core packages, so your distinction doesn't really make sense to me.

org.osgi.* packages do not come outside from the OSGi
container.
- Could the org.osgi.* packages come from custom bundles? I think, no.
- Can you write an application that does not need any of the org.osgi.*
package? I think you cannot.At least one bundle has to implement an
Activator to have any kind of functionality in the system. Otherwise the
bundles will be resolved, but they will do nothing (not even a static block
will be called).

Wrong. The extender pattern is based almost wholly around such an approach.

-> richard

- Can you imagine any use-case where exporting org.osgi.* packages by
the system bundle could cause any issue? I cannot.
- Is it an extra work that org.osgi.* packages have to be appended if
system.packages are overridden? Yes, always.

If we answer these questions, we will come to the conclusion (at least I :)
) that org.osgi.* packages should always be exported by the system bundle.
They are not in the scope of the meaning of system.packages setting.

Kind regards,
*Balázs **Zsoldos*

On Tue, Oct 27, 2015 at 3:21 PM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

Yes, that's precisely what the
org.osgi.framework.system.packages.extra was designed for. That way
you don't need to remember what the framework puts on
org.osgi.framework.system.packages in order to augment it.

Best regards,

David

On 27 October 2015 at 14:18, Andy Lee wrote:

See

https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES

--Andy

On Tue, Oct 27, 2015 at 10:00 AM, Balázs Zsoldos <

balazs.zsol...@everit.biz>

wrote:

Hi,

I asked this 1-2 years ago, but I think it is worthy to ask it again.

Are you sure that the set of system packages should include the OSGi

core

packages?

In my understanding:

- system packages are the ones coming from outside of the OSGi

container

- osgi core packages are offered by the framework bundle, but they

are

not system packages

In practice:

- If I specify org.osgi.system.packages property for equinox, I do

not

have to define the packages implemented by the framework
- If I specify the same property for felix, I must copy-paste the
packages of osgi.core always

Do you think there is a use-case when osgi.core packages offered by the
framework should be excluded from the exported packages of the system
bundle? I think Equinox has the right behavior here.

Do you see any chance to change this behavior in the future?

Kind regards,
*Balázs **Zsoldos*

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

2015-10-27 Thread Richard S. Hall

On 10/27/15 11:27 , Balázs Zsoldos wrote:

@David:

I know about the *org.osgi.framework.system.**packages.extra* property, but
that is about another use-case.

*org.osgi.framework.system.**packages.extra *can be used to extend the list
of system packages.
*org.osgi.framework.system.**packages* can be used to reduce the list of
the system packages.

@Andy:

The text at
https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
says:* Framework launching property identifying packages which the system
bundle must export.*

"Must" does not mean that only those packages should be exported by the
system bundle.

@Everyone:

Questions:

- What is the exact meaning of system packages from the perspective of
this setting? In my opinion, the list of packages that are coming outside
the OSGi container. org.osgi.* packages do not come outside from the OSGi
container.
- Could the org.osgi.* packages come from custom bundles? I think, no.
- Can you write an application that does not need any of the org.osgi.*
package? I think you cannot. At least one bundle has to implement an
Activator to have any kind of functionality in the system. Otherwise the
bundles will be resolved, but they will do nothing (not even a static block
will be called).
- Can you imagine any use-case where exporting org.osgi.* packages by
the system bundle could cause any issue? I cannot.

Also, we used to package some framework services separately (e.g.,
PackageAdmin, etc.) and some framework still might, so this assumption
also is not correct.

- Is it an extra work that org.osgi.* packages have to be appended if
system.packages are overridden? Yes, always.

Sure, this is correct, but not really relevant to the meaning of system
packages.

-> richard

If we answer these questions, we will come to the conclusion (at least I :)
) that org.osgi.* packages should always be exported by the system bundle.
They are not in the scope of the meaning of system.packages setting.

Kind regards,
*Balázs **Zsoldos*

On Tue, Oct 27, 2015 at 3:21 PM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

Best regards,

David

On 27 October 2015 at 14:18, Andy Lee wrote:

See

https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES

--Andy

On Tue, Oct 27, 2015 at 10:00 AM, Balázs Zsoldos <

balazs.zsol...@everit.biz>

wrote:

Hi,

I asked this 1-2 years ago, but I think it is worthy to ask it again.

Are you sure that the set of system packages should include the OSGi

core

packages?

In my understanding:

- system packages are the ones coming from outside of the OSGi

container

- osgi core packages are offered by the framework bundle, but they

are

not system packages

In practice:

- If I specify org.osgi.system.packages property for equinox, I do

not

have to define the packages implemented by the framework
- If I specify the same property for felix, I must copy-paste the
packages of osgi.core always

Do you think there is a use-case when osgi.core packages offered by the
framework should be excluded from the exported packages of the system
bundle? I think Equinox has the right behavior here.

Do you see any chance to change this behavior in the future?

Kind regards,
*Balázs **Zsoldos*

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

2015-10-27 Thread Richard S. Hall

On 10/27/15 16:10 , Balázs Zsoldos wrote:

I guess your needs came from an environment I am not familiar with. I have
never had to use Permissions within OSGi, so I must discontinue the
argument here (until I get familiar once with OSGi security ;-) ).

Probably the different opinions come from the name "system.packages". If
there were "framework.packages" and "environment.packages" that would give
a better separation. The chance of having such discussion has gone long ago.

Considering that the system bundle is called a "system" bundle, then it
would seem that the relationship to "system" packages would be clear... :-)

Anyway, I would like to ask kindly you if it is possible to implement the
idea that you (Richard) proposed in one of your previous emails:

org.osgi.framework.system.packages= ${dollar}{framework-exports} \
${dollar}{jre-${dollar}{java.specification.version}}

That could save lots of work in the future for developers who want to
specify explicitly those JDK packages they need. I hope that in one day all
packages can come from bundles (all, even swing or other built-in
solutions), and we need to export only the framework packages.

You can certainly create an issue for this...

-> richard

On Tue, Oct 27, 2015 at 6:33 PM, Richard S. Hall <he...@ungoverned.org>
wrote:

On 10/27/15 13:27 , Balázs Zsoldos wrote:

Also, we used to package some framework services separately (e.g.,

PackageAdmin, etc.) and some framework still might, so this assumption
also
is not correct.

I am wondering why PackageAdmin had to be re-implemented. If it was
possible to re-implement it based on other features of OSGi Core, does
that
mean that OSGi Core contained something that it should not have? If some
services can be implemented based on others, they are more like libraries
than part of the core.

I didn't say it was re-implemented, I said it was packaged separately. We
still do, for example, package the permission-related services separately.
It did, however, use some special hooks to do what it needed to do.

-> richard

On Tue, Oct 27, 2015 at 6:08 PM, Richard S. Hall <he...@ungoverned.org>
wrote:

On 10/27/15 11:27 , Balázs Zsoldos wrote:

@David:

I know about the *org.osgi.framework.system.**packages.extra* property,
but
that is about another use-case.

*org.osgi.framework.system.**packages.extra *can be used to extend the
list
of system packages.
*org.osgi.framework.system.**packages* can be used to reduce the list of
the system packages.

I want to reduce the list of system packages as some packages are coming
from bundles. More specifically, I want to list only those packages
that I
actually need from the JDK. Reason: Many packages are incomplete or
buggy
in the JDK: javax.transaction.*, javax.xml.*...

@Andy:

The text at

https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES
says:* Framework launching property identifying packages which the
system
bundle must export.*

"Must" does not mean that only those packages should be exported by the
system bundle.

@Everyone:

Questions:

- What is the exact meaning of system packages from the
perspective of
this setting? In my opinion, the list of packages that are coming
outside
the OSGi container. org.osgi.* packages do not come outside from
the
OSGi
container.
- Could the org.osgi.* packages come from custom bundles? I think,
no.
- Can you write an application that does not need any of the
org.osgi.*
package? I think you cannot. At least one bundle has to implement
an
Activator to have any kind of functionality in the system.
Otherwise
the
bundles will be resolved, but they will do nothing (not even a
static
block
will be called).
- Can you imagine any use-case where exporting org.osgi.* packages
by
the system bundle could cause any issue? I cannot.

Also, we used to package some framework services separately (e.g.,

PackageAdmin, etc.) and some framework still might, so this assumption
also
is not correct.

- Is it an extra work that org.osgi.* packages have to be appended
if

system.packages are overridden? Yes, always.

Sure, this is correct, but not really relevant to the meaning of system

packages.

-> richard

If we answer these questions, we will come to the conclusion (at least I

:)
) that org.osgi.* packages should always be exported by the system
bundle.
They are not in the scope of the meaning of system.packages setting.

Kind regards,
*Balázs **Zsoldos*

On Tue, Oct 27, 2015 at 3:21 PM,

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

2015-10-27 Thread Richard S. Hall


On 10/27/15 16:22 , Christian Schneider wrote:

I can only speak for myself but it would help me a lot.
How can we determine if it is worthwhile?

If you would accept such a patch I can do the implementation of it.


Technically, you might be able to do this as just part of the launcher, 
but I don't have too much time to think about it.


Create an issue and potentially a patch and then start nagging people. :-)

-> richard



Christian

Am 27.10.2015 um 18:11 schrieb Richard S. Hall:

On 10/27/15 11:36 , Christian Schneider wrote:
A typical case I have is that I need to remove some packages from 
the system packages.


Would it be possible to have a property like:
org.osgi.framework.system.packages.ignore=javax.transaction

Or some other way to just specify what we do not want to export?


I think something like that was discussed in CPEG at one time, but 
not really acted upon because it was just an optimization. Certainly, 
we could have a Felix-specific property if people really thought it 
was worthwhile.


-> richard



Christian



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

2015-10-27 Thread Richard S. Hall


> On Oct 27, 2015, at 18:45, Balázs Zsoldos <balazs.zsol...@everit.biz> wrote:
> 
>> 
>> As an application developer, you don’t need to import anything from
>> extender bundles.
>> I would estimate that 90% of my bundles do not import anything from the
>> core OSGi framework, and I almost *never* write a BundleActivator.
> 
> 
> Probably "Import" was not the right word. As an application developer, you
> either have to implement BundleActivator, or use some technology that
> implements the extender pattern. That technology must either implement
> BundleActivator or use another technology that implements another extender
> pattern. And so on...
> 
> If org.osgi.framework is not part of the system packages, at least one of
> the bundles will not be able to resolve (the one that implements
> BundleActivator). As a result, no code will be executed in any of the
> bundles. (It can be executed if someone starts the framework
> programmatically than gets a class type from one of the bundles than
> instantiates it with reflection... I do not think anybody wants to do this).
> 
> In other words: The org.osgi.framework must ALWAYS export the
> org.osgi.framework package, otherwise no business logic will be executed.

This portion of the conversation has definitely gotten off track and I am to 
blame since I was splitting hairs that shouldn’t have been split…

Having said that, though, I did once create a custom launcher that simply 
probed installed JAR files for some metadata and kicked started the application 
from the outside (effectively, it was the extender pattern implemented directly 
in a framework launcher). This work really nicely, because it allowed the 
installed JAR files to benefit from module metadata, encapsulate, and 
dependency resolution, but there was no code in the application with any OSGi 
awareness. So, technically, in that case, the system bundle needn’t have 
exported any OSGi packages at all, since the launcher got access to them via 
the class path.

See what kind of fun stuff you can do? :-)

-> richard

> 
> 
> On Tue, Oct 27, 2015 at 11:18 PM, Neil Bartlett <njbartl...@gmail.com>
> wrote:
> 
>> 
>>> On 27 Oct 2015, at 17:33, Balázs Zsoldos <balazs.zsol...@everit.biz>
>> wrote:
>>> 
>>>> 
>>>> As an application developer, I don't need to implement the extender
>>>> pattern since framework developers have done that for me. It's all about
>>>> layers and perspective.
>>> 
>>> 
>>> As a technology developer, how would you implement an extender pattern
>>> without the framework packages? You could not. If those packages are not
>>> exported by the system bundle, you cannot implement the extender pattern.
>>> As an application developer, you could not import a bundle that
>> implements
>>> the extender pattern, as the bundle would not resolve.
>> 
>> 
>> As an application developer, you don’t need to import anything from
>> extender bundles.
>> 
>> I would estimate that 90% of my bundles do not import anything from the
>> core OSGi framework, and I almost *never* write a BundleActivator.
>> 
>> Regards,
>> Neil
>> 
>> 
>>> 
>>> You mean that the Framework developers should implement technologies like
>>> Declarative Services and include it into the Framework?
>>> 
>>> 
>>> On Tue, Oct 27, 2015 at 6:27 PM, Richard S. Hall <he...@ungoverned.org>
>>> wrote:
>>> 
>>>> On 10/27/15 13:14 , Balázs Zsoldos wrote:
>>>> 
>>>>> That is not my interpretation. System packages are those packages
>> provided
>>>>>> by the system bundle. From a wiring perspective, all of the JRE
>> packages
>>>>>> look like they are coming from the system bundle just like the OSGi
>> core
>>>>>> packages, so your distinction doesn't really make sense to me.
>>>>>> 
>>>>> 
>>>>> Seems that we are different :). I interpret rules based on use-cases. I
>>>>> cannot find any use-case where I wanted to handle framework packages
>> like
>>>>> JDK packages. On the other hand, I see use-cases where I want to handle
>>>>> them separately.
>>>>> 
>>>> 
>>>> It is much more consistent to defines system.packages like,
>>>> "system.packages represents all packages that will be exported by the
>>>> system bundle", instead of something like "system.packages represents
>> all
>>>> packages exported by the

Re: System packages should not contain osgi.core packages (packages that are exported by the framework)

2015-10-27 Thread Richard S. Hall

I think it is reasonable to allow someone to hide exports from the 
system bundle, but that doesn't mean that this process couldn't be 
improved. For example, we could introduce a new variable 
${framework-exports} as an alias to what the framework exports, so then 
in our default properties file the system.packages could be written 
something like this:


org.osgi.framework.system.packages= ${dollar}{framework-exports} \
 ${dollar}{jre-${dollar}{java.specification.version}}

Thus making it easier for people who want to override system.packages by 
using our alias.


Of course, though, if you just want to add stuff to system packages, 
then you should be using system.packages.extra like others have suggested.


-> richard

On 10/27/15 10:21 , David Bosschaert wrote:

Yes, that's precisely what the
org.osgi.framework.system.packages.extra was designed for. That way
you don't need to remember what the framework puts on
org.osgi.framework.system.packages in order to augment it.

Best regards,

David

On 27 October 2015 at 14:18, Andy Lee  wrote:

If you are trying to extend the set of packages exported by the system
bundle, you should use org.osgi.framework.system.packages.extra.  By
specifying org.osgi.framework.system.packages you are overriding the
default value used by the framework, and hence must include the packaged
that are expected to be supplied by the framework.

See
https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_SYSTEMPACKAGES


--Andy



On Tue, Oct 27, 2015 at 10:00 AM, Balázs Zsoldos 
wrote:


Hi,

I asked this 1-2 years ago, but I think it is worthy to  ask it again.

Are you sure that the set of system packages should include the OSGi core
packages?

In my understanding:

- system packages are the ones coming from outside of the OSGi container
- osgi core packages are offered by the framework bundle, but they are
not system packages

In practice:

- If I specify org.osgi.system.packages property for equinox, I do not
have to define the packages implemented by the framework
- If I specify the same property for felix, I must copy-paste the
packages of osgi.core always

Do you think there is a use-case when osgi.core packages offered by the
framework should be excluded from the exported packages of the system
bundle? I think Equinox has the right behavior here.

Do you see any chance to change this behavior in the future?

Kind regards,
*Balázs **Zsoldos*


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: When good version constraints go bad

2015-08-28 Thread Richard S. Hall


On 8/28/15 14:36 , Benson Margulies wrote:

Consider three bundles, A, B, and C. A has imports from B and C. All
three import Guava.

A and B import with a constraint of [18, 19), C takes [15, 16).

The container obediently wires A and B to one bundle, and C to the other.

Now, no Guava objects flow _directly_ from C to A. However, A calls C
with some Json, and asks C to turn it onto Java objects, and passes a
class (X) from B as the target of the conversion. X has a field of
type ImmutableList.

The code in C looked at that field, and does not recognize it, because
it has a ClassImmutableList for Guava 15, while the Class object
seen reflectively is for 18.


If I understand the scenario correctly: C gives an object to A that has 
an instance of something from Guava 15 inside of it somewhere.


It simply sounds like the export from C is missing a uses constraint 
on Guava. It doesn't matter how you expose classes, even if it deeply 
nested (i.e., not only directly), if the classes are visible to others 
(barring weird stuff like using reflection) then it has to be listed as 
a uses constraint on your export. In that were the case in your 
scenario, the bundles would not resolve.


There is no easy way to diagnose such issues. When bundles have faulty 
metadata, weird stuff can happen.


- richard



This raises two questions: is there some diagnostic technique I'm
missing here that would have made this more evident? And, is there any
legitimate way to tell the OSGi container I know that C works with 18
even if that fails the version constraint.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: When good version constraints go bad

2015-08-28 Thread Richard S. Hall


On 8/28/15 15:05 , Benson Margulies wrote:

On Fri, Aug 28, 2015 at 2:59 PM, Richard S. Hall he...@ungoverned.org wrote:

On 8/28/15 14:36 , Benson Margulies wrote:

Consider three bundles, A, B, and C. A has imports from B and C. All
three import Guava.

A and B import with a constraint of [18, 19), C takes [15, 16).

The container obediently wires A and B to one bundle, and C to the other.

Now, no Guava objects flow _directly_ from C to A. However, A calls C
with some Json, and asks C to turn it onto Java objects, and passes a
class (X) from B as the target of the conversion. X has a field of
type ImmutableList.

The code in C looked at that field, and does not recognize it, because
it has a ClassImmutableList for Guava 15, while the Class object
seen reflectively is for 18.


If I understand the scenario correctly: C gives an object to A that has an
instance of something from Guava 15 inside of it somewhere.

Never actually happens, but close enough.

A gives C a Class object for X. C doesn't recognize C as a class it
knows what to do with, so it throws.




It simply sounds like the export from C is missing a uses constraint on
Guava. It doesn't matter how you expose classes, even if it deeply nested
(i.e., not only directly), if the classes are visible to others (barring
weird stuff like using reflection) then it has to be listed as a uses
constraint on your export. In that were the case in your scenario, the
bundles would not resolve.

To be concrete: The package is 'com.google.collect', and I think that
bundle B is pretty much beside the point.

It may be significant that A is a pax-exam test probe. So,

A has no imports, just a Dynamic-Import of *.

B has an import of com.google.collect;version=[18.0,19)

C has an import of com.google.collect;version=[15.0,15.1)

Is the dynamic import the root of the evil?


Very well could be.

- richard





There is no easy way to diagnose such issues. When bundles have faulty
metadata, weird stuff can happen.

- richard


This raises two questions: is there some diagnostic technique I'm
missing here that would have made this more evident? And, is there any
legitimate way to tell the OSGi container I know that C works with 18
even if that fails the version constraint.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: cannot delete bundle jar from load directory (locked)

2015-08-21 Thread Richard S. Hall


On 8/21/15 14:24 , Hubert Felber wrote:

Windows

:-)

 1. stop the bundle before deleting its bundle

neither stop nor uninstall the bundle helps. It must have to do with
the native code running -- is still locked.


Did you refresh after uninstalling ?



2. stop using windows, by far the best choice IMHO :-)

well, since our customers insist of using windows 

regards
Hubert


Ferry Huberts maili...@hupie.com 21.08.2015 20:08 


On 21/08/15 20:05, Hubert Felber wrote:

Hi,

I cannot delete a certain bundle jar from load directory, while I

can

do this with others in the same load directory while they are

running.

It says that this is open by java --  I do not receive a stop event

in

the activator.

This specific bundle has embedded jniWrapper jar and lots of native
libraries (dlls).
The jniWrapper is active and the native libraries are loaded.

What could cause this lock?

Windows


Can I do anything to avoid this lock?

1. stop the bundle before deleting its bundle
2. stop using windows, by far the best choice IMHO :-)


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Core and Compendium APIS at runtime

2015-05-25 Thread Richard S. Hall

Overall, I agree...we should probably add some of this argumentation to 
our FAQ entry...


- richard

On 5/25/15 03:38 , Peter Kriens wrote:

This kind of reasoning is often caused by not seeing the extremely tight 
relation between the provider of an API and that API itself. There is virtually 
no backward compatibility for providers, if the API changes, you need a new 
provider. Separating the provider from its API therefore just creates a lot of 
work and potential error cases that provide no benefit whatsoever.

The best practice I learned over time is therefore is that a provider includes 
an exact copy of the API package that it is build against and both exports AND 
imports it. Since OSGi packages have a globally unique name + version this 
works, the framework will share one of the exported packages if possible. This 
model has a number of advantages:

1) The resolver can automatically drag in implementations based on the API
2) You have significantly fewer bundles to worry about
3) You always have the right version at hand
4) bnd supports this model very well with its package include from class path 
function and calculation of importing exports.

Every time I run into bundles that do not include their API I get this 
desperate sinking feeling :-(

The idea that it works better with multiple providers of the same API is 
nonsense since they both MUST use the identical versions of the overlapping 
packages. That is, there is no backward compatibility to speak of for 
providers. So substitutable imports work fine for this use case.

The only argument for separating API and implementation in two bundles is that 
you do not have to refresh the client if you update an implementation. True, 
but due to transitive dependencies it takes real hard work to actually achieve 
this unless you have a small trivial system. And an OSGi system that can handle 
the going down of any bundle is likely not very valuable since it will likely 
fail. So realistically, this argument sounds nice in theory but has very little 
value in practice.

Interestingly, this discussion was held early on and several times thereafter. 
Initially, I was not sure, the separate API bundle did not sound so bad. Now, 
15 years later I am quite convinced that the provider including the API is the 
best solution in most cases.

Kind regards,

Peter Kriens




On 20 mei 2015, at 17:37, Milen Dyankov milendyan...@gmail.com wrote:

Well I agree in general. My only point is that IMHO the one defining the
API should also be the one providing it at runtime. Since OSGi alliance is
defining a spec which describes a service API it should be the one
providing the API bundle. Vendors are still free to provide their own
implementations and extensions anyway they wish. But this way a random
consumer does not have to investigate if given vendor has included the API
in the implementation and if not then worry about which bundles need to be
installed at runtime to satisfy imports. I personally (as probably most
people on this list) can deal with it. And from that perspective it's easy
(and partly true) to say it's not rally a problem. However it doesn't look
nice and it does not help to fight the too complex and too messy
stereotypes.
Just my 2 cents!

Best,
Milen


On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall he...@ungoverned.org
wrote:


On 5/20/15 05:15 , Milen Dyankov wrote:


Thanks for your answer Richard!

I am aware if the FAQ however what it basically tells you is it depends
;)


Unfortunately, it does depend on your circumstances. There are very few
cases in software engineering where you can say, always do it like
this...that's the way the cookie crumbles.

Thus I was hoping for some more insides so I can better understand the

intentions and the situation with service APIs from OSGi specs as of
today.
So, if I understand your answer correctly the conclusions are:

- Never use compendium bundle at runtime because it is not a proper bundle
(whatever that means).


Bundles (i.e., modules) are supposed to be cohesive and loosely coupled.
The compendium is just a bunch of APIs thrown into a JAR file, so that
hardly is cohesive and certainly wouldn't lead to low coupling. Understand?

   I agree with you that this should be in FAQ at

least. It would be even better if there is some more official statement
(may be there is and I just couldn't find it) that also explains why!

- There are no proper/official separate API bundles for the service APIs
defined in the specs. Vendors are free to choose if they (1) package the
API in the implementation bundle, (2) provide the implementation only or
(3) provide separate bundles for API and implementation. Felix has chosen
the first approach to avoid maintaining too many bundles.


No choice has been made at Apache Felix, but generally people have
gravitated to that approach. Subprojects are free to do it any way they
want, because use cases vary.

   IMHO

and according to the FAQ it seems

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Richard S. Hall



On 5/20/15 05:15 , Milen Dyankov wrote:

Thanks for your answer Richard!

I am aware if the FAQ however what it basically tells you is it depends
;)


Unfortunately, it does depend on your circumstances. There are very few 
cases in software engineering where you can say, always do it like 
this...that's the way the cookie crumbles.



Thus I was hoping for some more insides so I can better understand the
intentions and the situation with service APIs from OSGi specs as of today.
So, if I understand your answer correctly the conclusions are:

- Never use compendium bundle at runtime because it is not a proper bundle
(whatever that means).


Bundles (i.e., modules) are supposed to be cohesive and loosely coupled. 
The compendium is just a bunch of APIs thrown into a JAR file, so that 
hardly is cohesive and certainly wouldn't lead to low coupling. Understand?



  I agree with you that this should be in FAQ at
least. It would be even better if there is some more official statement
(may be there is and I just couldn't find it) that also explains why!

- There are no proper/official separate API bundles for the service APIs
defined in the specs. Vendors are free to choose if they (1) package the
API in the implementation bundle, (2) provide the implementation only or
(3) provide separate bundles for API and implementation. Felix has chosen
the first approach to avoid maintaining too many bundles.


No choice has been made at Apache Felix, but generally people have 
gravitated to that approach. Subprojects are free to do it any way they 
want, because use cases vary.



  IMHO
and according to the FAQ it seems the third approach makes more sense: *This
situation would be different if the service API were package in a separate
bundle. In this situation, all consumer bundles would be wired to the API
bundle, not to the provider bundle. Thus, if the provider were updated or
uninstalled and then refreshed, the consumer bundles would only be
minimally impacted (i.e., they would either switch to the new version of
the provider or to a different provider).*  but I respect your decisions.


It does make a lot of sense in many cases. If you are unsure of your 
needs, I'd recommend this as the default approach.




- There is no issue with split packages
http://wiki.osgi.org/wiki/Split_Packages  because regardless of the
provider and the way APIs they are packaged/exported the API package(s)
*should* always be both complete and limited to what what OSGi alliance has
specified. IMHO this should be a bit more strict than just expecting
vendors to do it right. Then perhaps consumers can feel a bit more safe
from such issues when choosing an implementation (without the need to
examine it's internals). But I'm not going to argue about it.


There is not much that can be done about this. What do you want the OSGi 
Alliance to do? We could require that ever developer give a signed list 
of every class that should be in every package and store that in some 
central repository. Then any time a bundle says they export a particular 
class, the framework could go out to that authority get the list of 
classes for that package and scan the bundle to make sure it contains 
the proper classes. Of course, this wouldn't even guarantee anything, 
since the bundle could include bogus implementation classes. Nor could 
you make it better by including class signatures in this central 
repository, because that would eliminate substitutability of different 
provider implementations.


At some point, you just have to trust the bundle developers and if they 
end up lying, the you put that bundle developer on your blacklist and 
you exclude them in your future choices.


As with everything, you're not going to get something (worthwhile) for free.

- richard



Once again thanks for your answers. Please correct me if
I misunderstood something.

Regards,
Milen





On Sun, May 17, 2015 at 8:01 PM, Richard S. Hallhe...@ungoverned.org
wrote:


On 5/17/15 12:57 , Milen Dyankov wrote:


Hi,

I recently stumbled upon something that makes me wonder about OSGI specs
APIs. As Metatype was the one API that made me start thinking about the
issue, I'll use it as an example but the question is about APIs in
general.

So while attempting to replace Felix's Metatype with Equinox one,  I
realized Felix implementation jar provides also the API while Equinox does
not. So my first thought was that there should be another jar with the API
alone but I couldn't find one. Second thought was to install osgi.cmpn.jar
(it's  a bundle after all) but I was told I should never do that and that
those jars are provided to be only used as compile time dependencies.

So here comes the question - who should provide the APIs at runtime for a
OSGI specs?


See the FAQ:


http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages

  I would actually split

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Richard S. Hall


On 5/20/15 11:37 , Milen Dyankov wrote:

Well I agree in general. My only point is that IMHO the one defining the
API should also be the one providing it at runtime. Since OSGi alliance is
defining a spec which describes a service API it should be the one
providing the API bundle.


And apparently the OSGi Alliance will do so from now on; however, ...


Vendors are still free to provide their own
implementations and extensions anyway they wish. But this way a random
consumer does not have to investigate if given vendor has included the API
in the implementation and if not then worry about which bundles need to be
installed at runtime to satisfy imports.


You will still not be relieved of performing this task since bundles may 
or may not come packaged with the APIs, so you'll still likely need to 
understand this, because multiple providers can (and do) lead to 
unexpected wiring when you are assuming there is only one provider.


Now, if you are saying that the framework should somehow enforce that 
implementations never provide the service API and that only the 
official service API bundles can be used to provide those packages, 
then I'd say that this would go too far.



I personally (as probably most
people on this list) can deal with it. And from that perspective it's easy
(and partly true) to say it's not rally a problem. However it doesn't look
nice and it does not help to fight the too complex and too messy
stereotypes.
Just my 2 cents!


Understood, but clamping things downs just leads to other messiness (see 
.NET and its strong versions).


As I said before, there is no free lunch. Developing software is 
complicated and you have to work hard to keep it from getting messy.


- richard



Best,
Milen


On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall he...@ungoverned.org
wrote:


On 5/20/15 05:15 , Milen Dyankov wrote:


Thanks for your answer Richard!

I am aware if the FAQ however what it basically tells you is it depends
;)


Unfortunately, it does depend on your circumstances. There are very few
cases in software engineering where you can say, always do it like
this...that's the way the cookie crumbles.

  Thus I was hoping for some more insides so I can better understand the

intentions and the situation with service APIs from OSGi specs as of
today.
So, if I understand your answer correctly the conclusions are:

- Never use compendium bundle at runtime because it is not a proper bundle
(whatever that means).


Bundles (i.e., modules) are supposed to be cohesive and loosely coupled.
The compendium is just a bunch of APIs thrown into a JAR file, so that
hardly is cohesive and certainly wouldn't lead to low coupling. Understand?

I agree with you that this should be in FAQ at

least. It would be even better if there is some more official statement
(may be there is and I just couldn't find it) that also explains why!

- There are no proper/official separate API bundles for the service APIs
defined in the specs. Vendors are free to choose if they (1) package the
API in the implementation bundle, (2) provide the implementation only or
(3) provide separate bundles for API and implementation. Felix has chosen
the first approach to avoid maintaining too many bundles.


No choice has been made at Apache Felix, but generally people have
gravitated to that approach. Subprojects are free to do it any way they
want, because use cases vary.

IMHO

and according to the FAQ it seems the third approach makes more sense:
*This
situation would be different if the service API were package in a separate
bundle. In this situation, all consumer bundles would be wired to the API
bundle, not to the provider bundle. Thus, if the provider were updated or
uninstalled and then refreshed, the consumer bundles would only be
minimally impacted (i.e., they would either switch to the new version of
the provider or to a different provider).*  but I respect your decisions.


It does make a lot of sense in many cases. If you are unsure of your
needs, I'd recommend this as the default approach.



- There is no issue with split packages
http://wiki.osgi.org/wiki/Split_Packages  because regardless of the
provider and the way APIs they are packaged/exported the API package(s)
*should* always be both complete and limited to what what OSGi alliance
has
specified. IMHO this should be a bit more strict than just expecting
vendors to do it right. Then perhaps consumers can feel a bit more safe
from such issues when choosing an implementation (without the need to
examine it's internals). But I'm not going to argue about it.


There is not much that can be done about this. What do you want the OSGi
Alliance to do? We could require that ever developer give a signed list of
every class that should be in every package and store that in some central
repository. Then any time a bundle says they export a particular class, the
framework could go out to that authority get the list of classes for that
package and scan the bundle

Re: Core and Compendium APIS at runtime

2015-05-20 Thread Richard S. Hall



On 5/20/15 14:42 , Milen Dyankov wrote:

Now, if you are saying that the framework should somehow enforce that
implementations never provide the service API and that only the official
service API bundles can be used to provide those packages, then I'd say
that this would go too far.


No I didn't meant to say that. Rather that implementations would not
have/need to do it. At least I for one can not see a good reason why would
someone want to provide the same version of someone else's API if
it's already publicly available.


Well, that's the point, they make this decision based on their own 
requirements. Some people might want their bundle to be self-contained 
to make it easier to use or want to limit third-party dependencies, etc. 
It just depends. :-)


- richard






On Wed, May 20, 2015 at 5:47 PM, Richard S. Hall he...@ungoverned.org
wrote:


On 5/20/15 11:37 , Milen Dyankov wrote:


Well I agree in general. My only point is that IMHO the one defining the
API should also be the one providing it at runtime. Since OSGi alliance is
defining a spec which describes a service API it should be the one
providing the API bundle.


And apparently the OSGi Alliance will do so from now on; however, ...

  Vendors are still free to provide their own

implementations and extensions anyway they wish. But this way a random
consumer does not have to investigate if given vendor has included the API
in the implementation and if not then worry about which bundles need to be
installed at runtime to satisfy imports.


You will still not be relieved of performing this task since bundles may
or may not come packaged with the APIs, so you'll still likely need to
understand this, because multiple providers can (and do) lead to unexpected
wiring when you are assuming there is only one provider.

Now, if you are saying that the framework should somehow enforce that
implementations never provide the service API and that only the official
service API bundles can be used to provide those packages, then I'd say
that this would go too far.

  I personally (as probably most

people on this list) can deal with it. And from that perspective it's easy
(and partly true) to say it's not rally a problem. However it doesn't look
nice and it does not help to fight the too complex and too messy
stereotypes.
Just my 2 cents!


Understood, but clamping things downs just leads to other messiness (see
.NET and its strong versions).

As I said before, there is no free lunch. Developing software is
complicated and you have to work hard to keep it from getting messy.

- richard




Best,
Milen


On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall he...@ungoverned.org
wrote:

  On 5/20/15 05:15 , Milen Dyankov wrote:

  Thanks for your answer Richard!

I am aware if the FAQ however what it basically tells you is it
depends
;)

  Unfortunately, it does depend on your circumstances. There are very few

cases in software engineering where you can say, always do it like
this...that's the way the cookie crumbles.

   Thus I was hoping for some more insides so I can better understand the


intentions and the situation with service APIs from OSGi specs as of
today.
So, if I understand your answer correctly the conclusions are:

- Never use compendium bundle at runtime because it is not a proper
bundle
(whatever that means).

  Bundles (i.e., modules) are supposed to be cohesive and loosely

coupled.
The compendium is just a bunch of APIs thrown into a JAR file, so that
hardly is cohesive and certainly wouldn't lead to low coupling.
Understand?

 I agree with you that this should be in FAQ at


least. It would be even better if there is some more official statement
(may be there is and I just couldn't find it) that also explains why!

- There are no proper/official separate API bundles for the service APIs
defined in the specs. Vendors are free to choose if they (1) package the
API in the implementation bundle, (2) provide the implementation only or
(3) provide separate bundles for API and implementation. Felix has
chosen
the first approach to avoid maintaining too many bundles.

  No choice has been made at Apache Felix, but generally people have

gravitated to that approach. Subprojects are free to do it any way they
want, because use cases vary.

 IMHO


and according to the FAQ it seems the third approach makes more sense:
*This
situation would be different if the service API were package in a
separate
bundle. In this situation, all consumer bundles would be wired to the
API
bundle, not to the provider bundle. Thus, if the provider were updated
or
uninstalled and then refreshed, the consumer bundles would only be
minimally impacted (i.e., they would either switch to the new version of
the provider or to a different provider).*  but I respect your
decisions.

  It does make a lot of sense in many cases. If you are unsure of your

needs, I'd recommend this as the default approach.


  - There is no issue with split packages

http://wiki.osgi.org

Re: Core and Compendium APIS at runtime

2015-05-17 Thread Richard S. Hall

On 5/17/15 12:57 , Milen Dyankov wrote:

Hi,

I recently stumbled upon something that makes me wonder about OSGI specs
APIs. As Metatype was the one API that made me start thinking about the
issue, I'll use it as an example but the question is about APIs in general.

So while attempting to replace Felix's Metatype with Equinox one, I
realized Felix implementation jar provides also the API while Equinox does
not. So my first thought was that there should be another jar with the API
alone but I couldn't find one. Second thought was to install osgi.cmpn.jar
(it's a bundle after all) but I was told I should never do that and that
those jars are provided to be only used as compile time dependencies.

So here comes the question - who should provide the APIs at runtime for a
OSGI specs?

See the FAQ:

http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages

I would actually split the question into a few:
- is it really forbidden/nor recommended to use osgi.cmpn.jar at runtime?
If so can someone please elaborate?

This should probably be in the FAQ too. The compendium only happens to
be packaged as a bundle because that is how it is built, not because it
actually is a proper bundle. It is not cohesive, since it is just a
collection of API, and pulls in unnecessary dependencies. The OSGi
Alliance should probably quit publishing it as a bundle. Over the years,
we seen lots of users run into difficulties when using it as a bundle.

- shouldn't there be independent (perhaps released by OSGI alliance) API
bundles? If there should be but they are missing at the moment then why
Felix does not provide APIs in a separate bundles instead of packaging them
with the implementation?

It's not really the purpose of the OSGi Alliance, but I suppose they
could. At Apache Felix, we have enough bundles to maintain, without
creating more.

- finally if the expectation is that each implementation provides also the
API isn't this leading to split package condition? I'm aware for most specs
it probably makes no sense to have 2 different implementations at the same
time but still ...

No. How would they be split? Packages are self contained in OSGi bundles
unless you explicitly make them split. If done properly, there is little
harm in having multiple providers of a package. However, having a single
provider does provide some benefits too. As the FAQ says, it just
depends on your situation.

If you really are dealing with composing a system out of third-party
bundles, though, you cannot really always have it your way so you have
to deal with the realities on the ground.

- richard

I would appreciate if someone can throw more light on the subject.

Regards,
Milen

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix autostart Dependencies

2015-04-27 Thread Richard S. Hall


On 4/27/15 04:02 , Moss, Robin wrote:

Hello,

Sorry if this has been asked before but I've not had much lucking finding 
information about it.

I'm trying to configure felix to use auto deploy to install,start a set of 
plugins that are needed for auto.start bundles later on.

In my case I'm trying to get two specific features to work:
- Aries blueprints
- PAX Url wrap

I'm doing this by putting their dependencies along with some felix plugins into an 
auto deploy folder, I'm then using felix.auto.start.n to start all the other 
bundles I need for my application.

My Config:
   felix.auto.deploy.action=install,start
   felix.auto.deploy.dir=bin/felix
   felix.auto.start.3=. (will include some wrap:file:.. bundles)

When I start felix ` java 
-Dfelix.config.properties=file:config/felix.properties -jar 
bin/org.apache.felix.main-4.6.1.jar` its unable to use wrapped url's but if I 
then through gogo use felix:install it works fine.

Is the issue here that felix is installing all the auto start's and auto 
deploys before it starts any of them? If this is the case is there a way I can 
either get it to start the lower run levels before installing the higher level 
runlevels, or a way (i.e. a sub-project or other plugin I can use) I can write 
a script that after felix has started it can then install/start a list of 
bundles?


Yes, the launcher installs all bundles first, then starts them. It does 
this to ensure that all package dependencies can be resolved.


There is no way to get it to install and start lower start levels. I do 
believe the auto-deploy directory is processed before the auto 
properties, so you could use both mechanisms to achieve what you want, 
perhaps.


- richard



Thanks in advance,
Robin




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Missing Framework Event on Bundle start failure

2015-03-17 Thread Richard S. Hall


On 3/17/15 04:34 , Anders Engström wrote:

Hi!

I'm deploying bundles at runtime in a Felix container and was expecting
the container to generate a FrameworkEvent (of type ERROR) if a call to
`Bundle#start()` fails with an exception.

In my case the call to `start` triggers a `BundleException` because of
an unresolved dependency:

Caused by: org.apache.felix.log.LogException: 
org.osgi.framework.BundleException: Unresolved constraint in bundle 
se.hrmsoftware.bundles.modules.coins [43]: Unable to resolve 43.0: 
missing requirement [43.0] osgi.wiring.package; 
((osgi.wiring.package=org.apache.commons.codec.digest)(version=1.5.0)(!(version=2.0.0)))
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4097) ~[org.apache.felix.framework-4.6.1.jar:na] 

at 
org.apache.felix.framework.Felix.startBundle(Felix.java:2114) 
~[org.apache.felix.framework-4.6.1.jar:na]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977) 
~[org.apache.felix.framework-4.6.1.jar:na]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964) 
~[org.apache.felix.framework-4.6.1.jar:na]
at 
se.hrmsoftware.bundles.bootstrap.pack.internal.esa.BundlesUnit$1.apply(BundlesUnit.java:56) 
~[na:na]

... 12 common frames omitted

I notice that there are calls to `fireFrameworkEvent` in
`org.apache.felix.framework.Felix` that seems to be signaling unexpected
errors - but not when a Bundle fails to start.

Is this by design - or should a failure to start a bundle trigger a
FrameworkEvent.ERROR?


I don't believe the specification indicates that a framework event is 
fired in this case, does it?


- richard



Some context: I'm writing an integration test that verifies that a set
of bundles can be cleanly deployed into our container. My assumption was
that I could check if there are any failure by listening to Framework
events and fail the test if there are any ERRORS.

Best regards //Anders

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Same code in bundle and system bundle results in verify error

2015-01-12 Thread Richard S. Hall


On 1/12/15 11:42 , Benson Margulies wrote:

My idea that this has to do with system bundle versus not is wrong. I'm
still debugging.



Is it a single package you are talking about or is it a couple of 
packages with uses constraints among them?


- richard

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Framework#start versus FrameworkStartLevel#setStartLevel

2014-12-09 Thread Richard S. Hall


On 12/9/14 01:55 , Felix Meschberger wrote:

Hi


Am 09.12.2014 um 03:02 schrieb Richard Hall he...@ungoverned.org:

On 12/8/14 20:47 , Benson Margulies wrote:

On Mon, Dec 8, 2014 at 8:34 PM, Richard S. Hall he...@ungoverned.org wrote:

On 12/8/14 18:07 , Benson Margulies wrote:

FrameworkStartLevel#setStartLevel takes listeners, which looks really
useful. Can I call it instead of Framework#start?

They don't do the same thing, but certainly you can use either...

That's what I'm trying to sort out. To be perfectly clear about my
ignorance, I don't understand what the FrameworkStartLevel method is
for if it's not another way to express the Framework method.

Here's what I have working:

1. framework.init();
2. obtain default bundle start level from FrameworkStartLevel
3. installBundle all bundles
4. set start level for each bundle by adapting to a BundleStartLevel
5. start all bundles
6. framework.start

So, where would FrameworkStartLevel#setStartLevel fit into all this?
Is it only useful if I need to change the start level after
framework.start()?

Yeah, it is pretty much only useful after you activate the framework (i.e., 
call start()). Although, after a quick look, I'm not 100% certain what the 
Felix framework implementation will do if you call setStartLevel() before 
calling start()…

My interpretation is, that the init() method sets the StartLevel service up and 
then calling setStartLevel instead of Framework.start() would probably start 
the framework except: The framework STARTED event would not be sent !


Yes, that was sort of my interpretation of looking at the code too, but 
I'm not convinced that that is the correct behavior.


- richard



It would really stick to the original intent, as I read it: Use 
Framework.start() to start the framework and use 
FrameworkStartLevel.setStartLevel to change the current start level.

Regards
Felix


- richard







- richard



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Framework#start versus FrameworkStartLevel#setStartLevel

2014-12-09 Thread Richard S. Hall


On 12/8/14 21:24 , Richard Hall wrote:


I think that would work, although I think you can also configure the 
initial framework start level too.




Also, I'm not sure what synchronization you are trying to achieve, but 
calling Framework.start() is not asynchronous, so calling it waits until 
all start levels up to the initial start level have completed activating.


- richard

On Dec 8, 2014 9:10 PM, Benson Margulies ben...@basistech.com 
mailto:ben...@basistech.com wrote:


On Mon, Dec 8, 2014 at 9:02 PM, Richard S. Hall
he...@ungoverned.org mailto:he...@ungoverned.org wrote:
 On 12/8/14 20:47 , Benson Margulies wrote:

 On Mon, Dec 8, 2014 at 8:34 PM, Richard S. Hall
he...@ungoverned.org mailto:he...@ungoverned.org
 wrote:

 On 12/8/14 18:07 , Benson Margulies wrote:

 FrameworkStartLevel#setStartLevel takes listeners, which
looks really
 useful. Can I call it instead of Framework#start?


 They don't do the same thing, but certainly you can use either...


 That's what I'm trying to sort out. To be perfectly clear about my
 ignorance, I don't understand what the FrameworkStartLevel
method is
 for if it's not another way to express the Framework method.

 Here's what I have working:

 1. framework.init();
 2. obtain default bundle start level from FrameworkStartLevel
 3. installBundle all bundles
 4. set start level for each bundle by adapting to a
BundleStartLevel
 5. start all bundles
 6. framework.start

 So, where would FrameworkStartLevel#setStartLevel fit into all
this?
 Is it only useful if I need to change the start level after
 framework.start()?


 Yeah, it is pretty much only useful after you activate the
framework (i.e.,
 call start()). Although, after a quick look, I'm not 100%
certain what the
 Felix framework implementation will do if you call
setStartLevel() before
 calling start()...

So, if I set all the bundles to start at 2, and leave the beginning
level at 1, then start() won't start any bundles. Then I could call
setStartLevel(2, myFavoriteListener) and achieve synchronization?



 - richard








 - richard




-
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
mailto:users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org
mailto:users-h...@felix.apache.org


-
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
mailto:users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org
mailto:users-h...@felix.apache.org




-
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
mailto:users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org
mailto:users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
mailto:users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
mailto:users-h...@felix.apache.org

Re: Framework#start versus FrameworkStartLevel#setStartLevel

2014-12-09 Thread Richard S. Hall



On 12/9/14 08:16 , Richard S. Hall wrote:

On 12/9/14 01:55 , Felix Meschberger wrote:

Hi


Am 09.12.2014 um 03:02 schrieb Richard Hall he...@ungoverned.org:

On 12/8/14 20:47 , Benson Margulies wrote:
On Mon, Dec 8, 2014 at 8:34 PM, Richard S. Hall 
he...@ungoverned.org wrote:

On 12/8/14 18:07 , Benson Margulies wrote:
FrameworkStartLevel#setStartLevel takes listeners, which looks 
really

useful. Can I call it instead of Framework#start?

They don't do the same thing, but certainly you can use either...

That's what I'm trying to sort out. To be perfectly clear about my
ignorance, I don't understand what the FrameworkStartLevel method is
for if it's not another way to express the Framework method.

Here's what I have working:

1. framework.init();
2. obtain default bundle start level from FrameworkStartLevel
3. installBundle all bundles
4. set start level for each bundle by adapting to a BundleStartLevel
5. start all bundles
6. framework.start

So, where would FrameworkStartLevel#setStartLevel fit into all this?
Is it only useful if I need to change the start level after
framework.start()?
Yeah, it is pretty much only useful after you activate the framework 
(i.e., call start()). Although, after a quick look, I'm not 100% 
certain what the Felix framework implementation will do if you call 
setStartLevel() before calling start()…
My interpretation is, that the init() method sets the StartLevel 
service up and then calling setStartLevel instead of 
Framework.start() would probably start the framework except: The 
framework STARTED event would not be sent !


Yes, that was sort of my interpretation of looking at the code too, 
but I'm not convinced that that is the correct behavior.


I think we need to check for being in INIT state and throw an illegal 
state exception or something...


- richard



- richard



It would really stick to the original intent, as I read it: Use 
Framework.start() to start the framework and use 
FrameworkStartLevel.setStartLevel to change the current start level.


Regards
Felix


- richard







- richard



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Framework#start versus FrameworkStartLevel#setStartLevel

2014-12-08 Thread Richard S. Hall


On 12/8/14 18:07 , Benson Margulies wrote:

FrameworkStartLevel#setStartLevel takes listeners, which looks really
useful. Can I call it instead of Framework#start?


They don't do the same thing, but certainly you can use either...

- richard



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Framework#start versus FrameworkStartLevel#setStartLevel

2014-12-08 Thread Richard S. Hall


On 12/8/14 20:47 , Benson Margulies wrote:

On Mon, Dec 8, 2014 at 8:34 PM, Richard S. Hall he...@ungoverned.org wrote:

On 12/8/14 18:07 , Benson Margulies wrote:

FrameworkStartLevel#setStartLevel takes listeners, which looks really
useful. Can I call it instead of Framework#start?


They don't do the same thing, but certainly you can use either...


That's what I'm trying to sort out. To be perfectly clear about my
ignorance, I don't understand what the FrameworkStartLevel method is
for if it's not another way to express the Framework method.

Here's what I have working:

1. framework.init();
2. obtain default bundle start level from FrameworkStartLevel
3. installBundle all bundles
4. set start level for each bundle by adapting to a BundleStartLevel
5. start all bundles
6. framework.start

So, where would FrameworkStartLevel#setStartLevel fit into all this?
Is it only useful if I need to change the start level after
framework.start()?


Yeah, it is pretty much only useful after you activate the framework 
(i.e., call start()). Although, after a quick look, I'm not 100% certain 
what the Felix framework implementation will do if you call 
setStartLevel() before calling start()...


- richard









- richard



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: org.osgi.framework.system.packages.extra

2014-11-17 Thread Richard S. Hall

On 11/17/14 10:27 , Benson Margulies wrote:

In several places,

http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html

says:

This is achieved using the
org.osgi.framework.system.packages.extra configuration
property previously presented.

It does not seem to me to be previously presented. Is it on some other page?

Here:

http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.html

And in the OSGi specification.

I'm trying to work out in my head how to set up an embedded situation
that has the classpath issue discussed here. I have a family of
bundles that can be asked to do some work. I have to push work in and
get answers out from code outside. Now, I could throw my hands in the
air and, essentially, put a web service in there, having (e.g.) JSON
flow through. If I want actual Java objects to flow, I'm understanding
the situation to be that I need:

- a Non-bundle jar file that defines the interface and data that flow
in and out of the container
- to build the bundles to see themselves as importing this
- to make it available at real runtime as system packages
- to learn how to make the pax-exam unit tests for these bundles to
get this code as system package instead of as imported bundles.

Does this make sense?

Sounds like it.

- richard

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: OSGI Security in Felix

2014-10-06 Thread Richard S. Hall


On 10/6/14 06:13 , Andrew Scully wrote:

Hello,

I'm looking into domain security in OSGI. I've assembled a fairly complete
picture of what this would involve, but I have a question which I would
appreciate your thoughts on. It would also be useful to me to check that I
have correctly understood so far.

To reiterate what I think I know (please correct if wrong!):
-I understand that setting permissions for the OSGI framework is something
that must be done programatically using the ConditionalPermissionAdmin
service. This is installed into Felix by an extension bundle.
-A file format is specified for defining permissions declaratively, but no
facility exists to automatically read a file in this format and bootstrap
the policy into the framework during startup (as you can with standard Java
security policies using a -D argument).
-You can implement your own service for reading in such a file and passing
the instructions to the ConditionalPermissionAdmin. Example code for this is
given in the OSGI in Action book, which I have seen.

Now here's my question!

As noted in both in OSGI in Action and in this post --
http://apache-felix.18485.x6.nabble.com/Felix-security-td4837010.html -- the
first bundle to get the ConditionalPermissionAdmin service effectively
controls the security for the entire framework, as it can change the
permissions to prevent others from changing permissions.

Obviously this is undesirable. The developer trying to secure the runtime
environment will want to ensure that the correct policy is applied without
the possibility of interference.

Furthermore, timing seems important. Surely, if a developer is trying to
prevent certain bundles from being installed, it would be no good if Felix
had already installed those bundles before the security policy reader
service had completed?

Therefore my question is this: Is it possible for a developer to guarantee
that their security policy is applied and is being enforced before the
framework starts proper?

To put that another way: If I implemented a bundle that read in an OSGI
security policy file and applied these settings to the framework (and then
locked it down preventing any further changes), how would I make sure that
this bundle ran first? Ideally, initialization of the rest of the
framework would be postponed until after this bundle had finished its work.


Assuming you are in control of the framework configuration and it is not 
compromised, you just need to configure your framework to launch your 
security bundle in start level 1 and put all other bundles in start 
level 2 or above.


Another option is to not actually create a security bundle per se, but 
to simply do it in your launcher. When you create a framework, you get 
back the system bundle which you can then use its bundle context to get 
the conditional permission service while still in the init phase and 
then set up your permission policy before it even attempts to start any 
other bundles.


- richard


Any help hugely appreciated -- it feels like I'm just missing some small
step here!

Cheers, Andy.




--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/OSGI-Security-in-Felix-tp5010083.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Export packages of OSGi core by default

2014-09-01 Thread Richard S. Hall


On 9/1/14, 11:01 , Balázs Zsoldos wrote:

The system bundle exports in Felix are defined by the defaults.properties
file found inside the JAR, so it’s not necessary to use the Export-Package
header from the manifest.


I know. I saw it. The packages are also defined in the Export-Package
MANIFEST header. I do not understand why the packages that are listed in
the MANIFEST of a bundle have to even be specified in any configuration.
They are exported by a bundle directly, even if it is the system bundle.


The framework is not a bundle. The fact that it has an Export-Package 
manifest entry is purely because it is packaged by Maven Bundle Plugin. 
Those bundle-related entries should probably be removed to avoid 
confusion like yours.




Equinox uses profiles as well, but the packages that are exported directly
by equinox, do not have to be specified anywhere else.


I think the spec says something about using a reasonable default if 
nothing is specified...not sure if it defines what that default it, but 
I don't think so.




If I have to write a custom launcher that analyzes the MANIFEST of felix
JAR and add the exported packages to the system classpath programmatically,
it seems like a workaround of an unfixed bug to me.


I'm not sure there'd be much analyzing going on, just load the 
default.properties file and use the system.packages value minus the JRE 
variable as your system.packages value for your launcher.


However, I agree that it could be easier. What might possibly be better 
is just somehow allowing the ${jre-?} property to be overwritten in the 
config properties so you could set it to empty or whatever. Currently, 
it is not possible to override default configuration properties with 
system properties.





Logic game:

If I create a fragment of the system bundle that exports additional
packages, shall I list those packages in extra configuration as well? If
not, why not? The packages of the host bundle is exported only if I
configure it externally.


This has nothing to do with anything in this discussion. System bundle 
fragments are handled at run time are their handling is defined by the spec.


- richard



Regards,
Balazs



On Mon, Sep 1, 2014 at 4:44 PM, Neil Bartlett njbartl...@gmail.com wrote:


The system bundle exports in Felix are defined by the defaults.properties
file found inside the JAR, so it’s not necessary to use the Export-Package
header from the manifest. Actually Equinox works in almost exactly the same
way; it uses a bunch of J2SE-*.profile files.

You can always write your own launcher that overrides the default
behaviour. For example the bnd launcher does look for and use the
Export-Package headers from all JARs that are added to the system classpath
using -runpath.

Neil

On 1 September 2014 at 15:29:33, Balázs Zsoldos (balazs.zsol...@everit.biz)
wrote:

Hi,

this question might have been raised before. If you could drop a link to
the thread, that would be cool.

In case Equinox is started with an empty
*org.osgi.framework.system.packages* value, the packages of OSGi core are
available in the container. This is good in my opinion as the bundle of
Equinox exports these packages.

If I do the same with Felix, the packages that are specified in the
Export-Package MANIFEST header of felix JAR, are not available. Why is
that? These packages are exported by a bundle, the system bundle.

I normally override the system.packages to use only those packages from
the
JDK that are necessary. I use everything I can from bundles, even the JDBC
API. It is very annoying that I have to list all OSGi core packages in the
system.packages with versions. What if I upgrade felix? I have to check
the
package of every version again. I cannot make a felix version independent
configuration.

Thanks and regards,
*Balázs **Zsoldos*





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix and VLC

2014-06-12 Thread Richard S. Hall



On 6/12/14, 03:39 , Erik Jansman wrote:

Hello,

For a project I'm working on creating a VLC bundle in Felix. I'm
starting to wonder if trying to get VLC in a bundle is the right choice.

I'm running into what appears to be an import/export package problem.
VLC needs the uk.co.caprica.vlcj.binding package. So I have added it
both to the import and export-package in the MANIFEST.MF.


Does your bundle contain this package? If not, it should only import it, 
not export it.


- richard


When I try to
run a very small test, getting the version of VLC, I get a
/java.lang.NoClassDefFoundError: uk/co/caprica/vlcj/binding/LibVlc
error/ and according to Intellij this is Caused
by:/java.lang.ClassNotFoundException: *** Class
'uk.co.caprica.vlcj.binding.LibVlc' was not found because bundle
VideoActuator [7] does not import 'uk.co.caprica.vlcj.binding' /I find
this error strange since my manifest does import the package.

Just to try it I have added another uk.co.caprica.vlcj.binding to the
import field, this generates a duplicate import error, which does make
sense since it's already imported.

Am I overlooking something or should I proceed in a different way and
not use VLC in a bundle at all?

Below are the manifest and the source code of my test

Regards,

Erik Jansman

MANIFEST.MF:
Manifest-Version: 1.0
Bundle-Activator: VideoActuatorActivator
Bundle-ManifestVersion: 2
Bundle-Name: VideoActuator
Bundle-SymbolicName: VideoActuator
Bundle-Version: 1.0.0
Export-Package: uk.co.caprica.vlcj.binding
Import-Package: org.osgi.framework,uk.co.caprica.vlcj.binding

VideoActuatorActivator.java:
import com.sun.jna.Native;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import uk.co.caprica.vlcj.binding.LibVlc;
import uk.co.caprica.vlcj.version.LibVlcVersion;

/**
  * Created by ejansman on 12/05/14.
  */
public class VideoActuatorActivator implements BundleActivator {


 public void start(BundleContext Context){

 System.out.println( started VideoPlayerImplementation);
 loadVLClibs();

 }

 private void loadVLClibs() {
 Native.loadLibrary(libvlc, LibVlc.class);
 LibVlcVersion.getVersion();
 }

 public void stop (BundleContext Context){

 }

   
}









-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix 4.2.1 and 4.4.0 regression wrt native code (Win7)

2014-06-12 Thread Richard S. Hall



On 6/12/14, 05:01 , Benoît Thiébault wrote:

Hi again,

I checked what version of Felix did break it:

- Everything worked fine with Felix 4.0.3 that was released the 28th of 
December 2012
- Version 4.2.0, released on the 11th of February 2013, broke it

Isn’t this modification responsible for this?
http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/util/manifestparser/R4LibraryClause.java?r1=1355580r2=1441169

It also seems to be related to bug 
https://issues.apache.org/jira/browse/FELIX-3363


If I had to guess, I'd say that the OS name being reported by the JVM 
(i.e., System.getProperty(os.name);) is not what we are expecting.


I don't have Windows to test, but if I set a breakpoint in 
R4LibraryClause.normalizeOSName() and manually edit 'value' to be 
Windows 7, then it appears to resolve the bundle correctly on my Mac.


What value does your JVM report for os.name?

- richard



Thanks for your help,

Kind regards,

Ben

Le 11 juin 2014 à 21:50, Benoît Thiébault thieba...@artenum.com a écrit :


Hi everyone,

I have an OSGi bundle containing native code that worked great with Felix 4.0.2.

I have switched to newer versions (originally 4.2.1 but also I tried with 4.4.0) and the 
bundle does not load anymore on Windows 7 64-bits (I haven’t tried the 32-bits version): 
I have a No matching libraries found error message. Java version is 1.6.0_37.

I don’t have the problem with native bundles on other platforms (I tried Debian 
Squeeze 64-bits and Mac OS Mavericks).

Do you know were this could come from? Is there a workaround, or better, a fix? 
Or should I go back to Felix 4.0.2 (which has difficulties with Java 7…)?

I have uploaded files here to reproduce the bug:
http://dev.artenum.com/blog/ben/download/FelixComparison_zip?action=downloadnodecorator

It contains two versions of the Felix Framework (4.0.2 and 4.4.0), I just added 
the minimum required bundles in the bundle folder. Bundles in the bundle folder 
are identical. When you run the two Run.bat files, you obtain the attached 
screenshot. Bundle 4 loads in one case, not with Felix 4.4.0.

Below is also the Bundle-NativeCode definition in Maven Bundle plugin.

Thanks for you advice

Kind regards,

Ben


Error.png

plugin
 groupIdorg.apache.felix/groupId
 artifactIdmaven-bundle-plugin/artifactId
 configuration
 instructions
 
Bundle-SymbolicName${project.artifactId}/Bundle-SymbolicName
 
Export-Packagevtk;version=${vtk.version}/Export-Package
 
Embed-Dependency*;groupId=vtk;artifactId=vtk/Embed-Dependency
 Include-Resource
 
vtk=dependencies/thirdparty/vtk-${vtk.version}/windows-x86_64,
 {maven-resources}
 /Include-Resource
 Bundle-NativeCode
vtk/awt.dll;
vtk/jawt.dll;
vtk/msvcp100.dll;
vtk/msvcr100.dll;
vtk/Cosmo.dll;
vtk/MapReduceMPI.dll;
vtk/VPIC.dll;
vtk/mpistubs.dll;
vtk/vtkCharts.dll;
vtk/vtkChartsJava.dll;
vtk/vtkCommon.dll;
vtk/vtkCommonJava.dll;
vtk/vtkDICOMParser.dll;
vtk/vtkFiltering.dll;
vtk/vtkFilteringJava.dll;
vtk/vtkGenericFiltering.dll;
vtk/vtkGenericFilteringJava.dll;
vtk/vtkGeovis.dll;
vtk/vtkGeovisJava.dll;
vtk/vtkGraphics.dll;
vtk/vtkGraphicsJava.dll;
vtk/vtkHybrid.dll;
vtk/vtkHybridJava.dll;
vtk/vtkIO.dll;
vtk/vtkIOJava.dll;
vtk/vtkImaging.dll;
vtk/vtkImagingJava.dll;
vtk/vtkInfovis.dll;
vtk/vtkInfovisJava.dll;
vtk/vtkNetCDF.dll;
vtk/vtkNetCDF_cxx.dll;
vtk/vtkParallel.dll;
vtk/vtkParallelJava.dll;
vtk/vtkRendering.dll;
vtk/vtkRenderingJava.dll;
vtk/vtkViews.dll;
vtk/vtkViewsJava.dll;
vtk/vtkVolumeRendering.dll;
vtk/vtkVolumeRenderingJava.dll;
vtk/vtkWidgets.dll;
vtk/vtkWidgetsJava.dll;
vtk/vtkalglib.dll;
vtk/vtkexoIIc.dll;
vtk/vtkexpat.dll;
vtk/vtkfreetype.dll;
vtk/vtkftgl.dll;
vtk/vtkjpeg.dll;
vtk/vtklibxml2.dll;
vtk/vtkmetaio.dll;
vtk/vtkpng.dll;
vtk/vtkproj4.dll;
vtk/vtksys.dll;
vtk/vtktiff.dll;
vtk/vtkverdict.dll;
vtk/vtkzlib.dll;
osname=win7;
processor=x86_64
 /Bundle-NativeCode
 /instructions
 /configuration
 /plugin



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix 4.2.1 and 4.4.0 regression wrt native code (Win7)

2014-06-12 Thread Richard S. Hall

Perhaps you start the JVM up suspended with debug enabled and set a 
break point up at R4LibraryClause.match() and see precisely why it is 
failing?


The code in there is pretty self explanatory.

- richard

On 6/12/14, 14:13 , Benoît Thiébault wrote:

What is strange is that the OS, the JVM and the bundle are the same. Only Felix 
version changes.

We have tried to look at other classes that were modified in Felix since 4.0.3 
but could not find anything conclusive yet

Le 12 juin 2014 18:40, Richard S. Hall he...@ungoverned.org a écrit :


On 6/12/14, 05:01 , Benoît Thiébault wrote:

Hi again,

I checked what version of Felix did break it:

- Everything worked fine with Felix 4.0.3 that was released the 28th of 
December 2012
- Version 4.2.0, released on the 11th of February 2013, broke it

Isn’t this modification responsible for this?
http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/util/manifestparser/R4LibraryClause.java?r1=1355580r2=1441169

It also seems to be related to bug 
https://issues.apache.org/jira/browse/FELIX-3363

If I had to guess, I'd say that the OS name being reported by the JVM
(i.e., System.getProperty(os.name);) is not what we are expecting.

I don't have Windows to test, but if I set a breakpoint in
R4LibraryClause.normalizeOSName() and manually edit 'value' to be
Windows 7, then it appears to resolve the bundle correctly on my Mac.

What value does your JVM report for os.name?

- richard


Thanks for your help,

Kind regards,

Ben

Le 11 juin 2014 à 21:50, Benoît Thiébault thieba...@artenum.com a écrit :


Hi everyone,

I have an OSGi bundle containing native code that worked great with Felix 4.0.2.

I have switched to newer versions (originally 4.2.1 but also I tried with 4.4.0) and the 
bundle does not load anymore on Windows 7 64-bits (I haven’t tried the 32-bits version): 
I have a No matching libraries found error message. Java version is 1.6.0_37.

I don’t have the problem with native bundles on other platforms (I tried Debian 
Squeeze 64-bits and Mac OS Mavericks).

Do you know were this could come from? Is there a workaround, or better, a fix? 
Or should I go back to Felix 4.0.2 (which has difficulties with Java 7…)?

I have uploaded files here to reproduce the bug:
http://dev.artenum.com/blog/ben/download/FelixComparison_zip?action=downloadnodecorator

It contains two versions of the Felix Framework (4.0.2 and 4.4.0), I just added 
the minimum required bundles in the bundle folder. Bundles in the bundle folder 
are identical. When you run the two Run.bat files, you obtain the attached 
screenshot. Bundle 4 loads in one case, not with Felix 4.4.0.

Below is also the Bundle-NativeCode definition in Maven Bundle plugin.

Thanks for you advice

Kind regards,

Ben


Error.png

plugin
   groupIdorg.apache.felix/groupId
   artifactIdmaven-bundle-plugin/artifactId
   configuration
   instructions
   
Bundle-SymbolicName${project.artifactId}/Bundle-SymbolicName
   
Export-Packagevtk;version=${vtk.version}/Export-Package
   
Embed-Dependency*;groupId=vtk;artifactId=vtk/Embed-Dependency
   Include-Resource
   
vtk=dependencies/thirdparty/vtk-${vtk.version}/windows-x86_64,
   {maven-resources}
   /Include-Resource
   Bundle-NativeCode
vtk/awt.dll;
vtk/jawt.dll;
vtk/msvcp100.dll;
vtk/msvcr100.dll;
vtk/Cosmo.dll;
vtk/MapReduceMPI.dll;
vtk/VPIC.dll;
vtk/mpistubs.dll;
vtk/vtkCharts.dll;
vtk/vtkChartsJava.dll;
vtk/vtkCommon.dll;
vtk/vtkCommonJava.dll;
vtk/vtkDICOMParser.dll;
vtk/vtkFiltering.dll;
vtk/vtkFilteringJava.dll;
vtk/vtkGenericFiltering.dll;
vtk/vtkGenericFilteringJava.dll;
vtk/vtkGeovis.dll;
vtk/vtkGeovisJava.dll;
vtk/vtkGraphics.dll;
vtk/vtkGraphicsJava.dll;
vtk/vtkHybrid.dll;
vtk/vtkHybridJava.dll;
vtk/vtkIO.dll;
vtk/vtkIOJava.dll;
vtk/vtkImaging.dll;
vtk/vtkImagingJava.dll;
vtk/vtkInfovis.dll;
vtk/vtkInfovisJava.dll;
vtk/vtkNetCDF.dll;
vtk/vtkNetCDF_cxx.dll;
vtk/vtkParallel.dll;
vtk/vtkParallelJava.dll;
vtk/vtkRendering.dll;
vtk/vtkRenderingJava.dll;
vtk/vtkViews.dll;
vtk/vtkViewsJava.dll;
vtk/vtkVolumeRendering.dll;
vtk/vtkVolumeRenderingJava.dll;
vtk/vtkWidgets.dll;
vtk/vtkWidgetsJava.dll;
vtk/vtkalglib.dll;
vtk/vtkexoIIc.dll;
vtk/vtkexpat.dll;
vtk/vtkfreetype.dll;
vtk/vtkftgl.dll;
vtk/vtkjpeg.dll;
vtk/vtklibxml2.dll;
vtk/vtkmetaio.dll;
vtk/vtkpng.dll;
vtk/vtkproj4.dll;
vtk/vtksys.dll;
vtk/vtktiff.dll;
vtk/vtkverdict.dll;
vtk/vtkzlib.dll;
osname=win7;
processor=x86_64
   /Bundle-NativeCode
   /instructions
   /configuration
   /plugin


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail

Re: Felix 4.2.1 and 4.4.0 regression wrt native code (Win7)

2014-06-12 Thread Richard S. Hall



On 6/12/14, 16:33 , Benoît Thiébault wrote:

Hi Richard,

Here is what I did: I added a few System.out.println in the 
R4LibraryClause.match() and checkOSNames() methods and recompiled Felix 
Framework (4.5.0-SNAPSHOT thus)

The modified code:
public boolean match(final Map configMap) throws BundleException {
 System.out.println(os.name: + System.getProperty(os.name));
 System.out.println(os.arch: + System.getProperty(os.arch));
 final String normal_osname = normalizeOSName((String) 
configMap.get(Constants.FRAMEWORK_OS_NAME));
 System.out.println(normal_osname: + normal_osname + ;);
 final String normal_processor = normalizeProcessor((String) 
configMap.get(Constants.FRAMEWORK_PROCESSOR));
 System.out.println(normal_processor: + normal_processor + ;);
 final String normal_osversion = normalizeOSVersion((String) 
configMap.get(Constants.FRAMEWORK_OS_VERSION));
 System.out.println(normal_osversion: + normal_osversion + ;);
 final String normal_language = (String) 
configMap.get(Constants.FRAMEWORK_LANGUAGE);
 System.out.println(normal_language: + normal_language + ;);

 // Check library's osname.
 if (!checkOSNames(normal_osname, getOSNames())) {
 System.out.println(R4LibraryClause.match()-checkOSNames returned 
false);
 return false;
 }

 // Check library's processor.
 if (!checkProcessors(normal_processor, getProcessors())) {
 System.out.println(R4LibraryClause.match()-checkProcessors returned 
false);
 return false;
 }

 // Check library's osversion if specified.
 if ((getOSVersions() != null)  (getOSVersions().length  0)
  !checkOSVersions(normal_osversion, getOSVersions())) {
 System.out.println(R4LibraryClause.match()-checkOSVersion returned 
false);
 return false;
 }

 // Check library's language if specified.
 if ((getLanguages() != null)  (getLanguages().length  0)  
!checkLanguages(normal_language, getLanguages())) {
 System.out.println(R4LibraryClause.match()-checkLanguages returned 
false);
 return false;
 }

 // Check library's selection-filter if specified.
 if ((getSelectionFilter() != null)  (getSelectionFilter().length() 
= 0)
  !checkSelectionFilter(configMap, getSelectionFilter())) {
 System.out.println(R4LibraryClause.match()-checkSelectionFilter 
returned false);
 return false;
 }

 System.out.println(R4LibraryClause.match() - returned true);
 return true;
 }

private boolean checkOSNames(final String currentOSName, final String[] 
osnames) {
 final boolean win32 = currentOSName.startsWith(win)  
!currentOSName.equals(windowsce);
 System.out.println(currentOSName: + currentOSName);
 for (int i = 0; (osnames != null)  (i  osnames.length); i++) {
 System.out.println(osname[ + i + ]: + osnames[i]);
 if (osnames[i].equals(currentOSName) || (win32.equals(osnames[i]) 
 win32)) {
 return true;
 }
 }
 return false;
 }

The output when run on Windows:
os.name:Windows 7
os.arch:amd64
normal_osname:win;
normal_processor:x86-64;
normal_osversion:6.1.0;
normal_language:fr;
currentOSName:win
osname[0]:windows7
R4LibraryClause.match()-checkOSNames returned false

So the problem seems to be the normal_osname that is win and not windows7…

Do you confirm?


Looks like it, but that doesn't make much sense. You need to look into 
normalizeOSName() and see why it doesn't match windows7...when I 
edited my OS name to be Windows 7 it worked correctly, so the only 
thing that makes sense here is that the value being passed to 
normalizeOSName() is not Windows 7...


- richard



Kind regards,
Ben

Le 12 juin 2014 à 21:48, Richard S. Hall he...@ungoverned.org a écrit :


Perhaps you start the JVM up suspended with debug enabled and set a break point 
up at R4LibraryClause.match() and see precisely why it is failing?

The code in there is pretty self explanatory.

- richard





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Watching Felix bundle startup order

2014-04-25 Thread Richard S. Hall


I assume you have a framework.start() in there that you are not showing us?

- richard

On 4/25/14, 10:42 , Keith Hughes wrote:

Hi folks,

I have a strange bug and suspect it may be due to bundle startup order in
Felix.So I am trying to log bundle startup order. I tried adding a bundle
listener to the Framework object before starting it and see nothing being
logged at all.

My code looks like this:

 framework = getFrameworkFactory().newFramework(m);
 frameworkStartLevel = framework.adapt(FrameworkStartLevel.class);

 framework.init();
 rootBundleContext = framework.getBundleContext();
 rootBundleContext.addBundleListener(new BundleListener() {
   @Override
   public void bundleChanged(BundleEvent event) {
 try {
   System.out.println(event.getType());
   if (event.getType() == BundleEvent.STARTED) {
 Bundle bundle = event.getBundle();
 System.out.println(
 String.format(Bundle %s:%s started,
bundle.getSymbolicName(), bundle.getVersion()));
   }
 } catch (Exception e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
 }
   }
 });

I then later add bundles and start them and yet never see a peep.

Any ideas?

Thanks,
-Keith




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Watching Felix bundle startup order

2014-04-25 Thread Richard S. Hall


We're glad to have helped... ;-)

On 4/25/14, 11:41 , Keith Hughes wrote:

Found my problem. Very sorry.



On Fri, Apr 25, 2014 at 8:42 AM, Keith Hughes keith.mhug...@gmail.comwrote:


Hi folks,

I have a strange bug and suspect it may be due to bundle startup order in
Felix.So I am trying to log bundle startup order. I tried adding a bundle
listener to the Framework object before starting it and see nothing being
logged at all.

My code looks like this:

 framework = getFrameworkFactory().newFramework(m);
 frameworkStartLevel = framework.adapt(FrameworkStartLevel.class);

 framework.init();
 rootBundleContext = framework.getBundleContext();
 rootBundleContext.addBundleListener(new BundleListener() {
   @Override
   public void bundleChanged(BundleEvent event) {
 try {
   System.out.println(event.getType());
   if (event.getType() == BundleEvent.STARTED) {
 Bundle bundle = event.getBundle();
 System.out.println(
 String.format(Bundle %s:%s started,
bundle.getSymbolicName(), bundle.getVersion()));
   }
 } catch (Exception e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
 }
   }
 });

I then later add bundles and start them and yet never see a peep.

Any ideas?

Thanks,
-Keith





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: ipojo late injection

2014-03-26 Thread Richard S. Hall

I'm guessing you'd want to use iPOJO API, which allows you to describe a
component dynamically:

http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-api.html

- richard

On 3/26/14, 16:37 , alejandro.e...@miranda.com wrote:

Hello everyone,

I am just starting with iPOJO and I was wondering what is the
right/recommended way in iPOJO to select a service late at runtime.
Imagine a textbox in a GUI that asks for a version and only after the user
entered version=1.3.5 I can know that the service I want injected is
v1.3.5. In this case annotations or xml don't work since they are static

What I am currently doing is using an aggregate dependency and then I loop
myself over all the services (the version is a property of the service
BTW) and return the one that matches the request

I though of multiple ways of doing this but I don't know if they are
possible or make sense

1) doing some kind of service registry query where I can explicitly ask
for the service with the given properties and I will have it returned
right away
2) modifying the injection filter at runtime; however with this technique
I would have to wait for the framework to do the injection whenever it
wants instead of when I need it. i.e. it is asynchronous
3) using the iPOJO API to modify the dependency. Again this solution would
be async
4) The one I mentioned first. Keep a list of all the services via an
aggregate dependency and loop through them to find the one that matches
5) other?

Thank you in advance,

Alejandro Endo | Software Designer/Concepteur de logiciels

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: OpenJPA Support in Apache Felix

2014-03-24 Thread Richard S. Hall

This code looks to be based on a fairly old version of the framework...I 
would guess version 3.x, which is prior to OSGi R4.3. You need to do 
some updates to get this to work with the latest framework releases (now 
version 4.4). Further, I think that OSGi R4.3 introduced some changes 
that might make it possible to do this all outside the framework as a 
bundle now, such as getting access to bundle revisions (i.e., modules) 
and their class loaders.


In light of that, I'd say it would be better to consider donating this 
as a stand-alone bundle to Apache OpenJPA...


- richard

On 3/24/14, 06:28 , dirk.rudo...@t-systems.com wrote:


Hi all,

in our current project, we intensively use database access to store 
information and share it between different (not clustered) instances. 
As for the persistence layer, we use Apache OpenJPA in an Apache Felix 
container (CQ5.5) with Apache Aries bundles installed. The setting up 
faced out some problems related to the special ClassLoader scenario in 
the OSGI environment. For a detailed related previous discussion have 
a look at [1] and [2].


To sum up, the most frustrating problem was that the Classes loaded by 
a special ModuleClassLoader could not be collected by the GC. So, the 
static PCRegistry of OpenJPA referenced Classes, whose ClassLoader has 
been closed/invalidated by Felix before and on any further access on 
these Classes, caused NoClassDefFoundErrors.


To solve this issue we implemented a framework extension that 
registers a BundleListener, cleaning up the PCRegistry every time a 
Bundle is updated. This code we would like to contribute and any 
comments are appreciated.


[1] 
http://mail-archives.apache.org/mod_mbox/openjpa-dev/200707.mbox/%3cfbb27544-a571-4c30-af39-e0822f81d...@gmail.com%3E


[2] https://issues.apache.org/jira/browse/OPENJPA-285

Kind regards,

*Dirk Rudolph *


T-Systems Multimedia Solutions GmbH
Organisationseinheit CCS
Dirk Rudolph
Software-Entwicklung, OCJP

Hausanschrift: Riesaer Straße 5, 01129 Dresden
Postanschrift: Postfach 10 02 24, 01072 Dresden
+49 351 2820-5363   (Tel)
E-Mail:dirk.rudo...@t-systems.com mailto:mdirk.rudo...@t-systems-mms.com
Internet: http://www.t-systems-mms.com http://www.t-systems-mms.de/

T-Systems Multimedia Solutions GmbH

Aufsichtsrat: Thilo Kusch (Vorsitzender)
Geschäftsführung: Peter Klingenburg, Susanne Heger, Dr. Rolf Werner
Handelsregister: Amtsgericht Dresden HRB 11433
Sitz der Gesellschaft: Dresden
Ust-IdNr.: DE 811 807 949



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: AW: OpenJPA Support in Apache Felix

2014-03-24 Thread Richard S. Hall



On 3/24/14, 17:18 , dirk.rudo...@t-systems.com wrote:

Thanks for your advice Richard. How could this be solved with a more recent 
framework release in detail? Despite the fact that we are currently not able to 
update to a higher version of Felix, I'm interested to see how OpenJPA would 
fit into future product releases.


Well, I won't go into too much detail, since I only glanced at the 
patch, but it appears that it tries to access outstanding module 
revisions using internal Felix framework API, but now this is possible 
using Bundle.adapt(BundleRevisions.class) and from each BundleRevision 
you can now get a BundleWiring from which you can get the class loader 
associated with the bundle.


It looks like that's all your patch needed, but I could be missing 
something. If that's all, then this can be supplied in a bundle outside 
of the framework...


- richard



You are right. We use CQ 5.5 with Apache Felix 3.0.8.

Regards,
Dirk
-Ursprüngliche Nachricht-
Von: Richard S. Hall [mailto:he...@ungoverned.org]
Gesendet: Montag, 24. März 2014 19:01
An: users@felix.apache.org
Betreff: Re: OpenJPA Support in Apache Felix

This code looks to be based on a fairly old version of the framework...I would 
guess version 3.x, which is prior to OSGi R4.3. You need to do some updates to 
get this to work with the latest framework releases (now version 4.4). Further, 
I think that OSGi R4.3 introduced some changes that might make it possible to 
do this all outside the framework as a bundle now, such as getting access to 
bundle revisions (i.e., modules) and their class loaders.

In light of that, I'd say it would be better to consider donating this as a 
stand-alone bundle to Apache OpenJPA...

- richard

On 3/24/14, 06:28 , dirk.rudo...@t-systems.com wrote:

Hi all,

in our current project, we intensively use database access to store
information and share it between different (not clustered) instances.
As for the persistence layer, we use Apache OpenJPA in an Apache Felix
container (CQ5.5) with Apache Aries bundles installed. The setting up
faced out some problems related to the special ClassLoader scenario in
the OSGI environment. For a detailed related previous discussion have
a look at [1] and [2].

To sum up, the most frustrating problem was that the Classes loaded by
a special ModuleClassLoader could not be collected by the GC. So, the
static PCRegistry of OpenJPA referenced Classes, whose ClassLoader has
been closed/invalidated by Felix before and on any further access on
these Classes, caused NoClassDefFoundErrors.

To solve this issue we implemented a framework extension that
registers a BundleListener, cleaning up the PCRegistry every time a
Bundle is updated. This code we would like to contribute and any
comments are appreciated.

[1]
http://mail-archives.apache.org/mod_mbox/openjpa-dev/200707.mbox/%3CFB
b27544-a571-4c30-af39-e0822f81d...@gmail.com%3E

[2] https://issues.apache.org/jira/browse/OPENJPA-285

Kind regards,

*Dirk Rudolph *


T-Systems Multimedia Solutions GmbH
Organisationseinheit CCS
Dirk Rudolph
Software-Entwicklung, OCJP

Hausanschrift: Riesaer Straße 5, 01129 Dresden
Postanschrift: Postfach 10 02 24, 01072 Dresden
+49 351 2820-5363   (Tel)
E-Mail:dirk.rudo...@t-systems.com
mailto:mdirk.rudo...@t-systems-mms.com
Internet: http://www.t-systems-mms.com http://www.t-systems-mms.de/

T-Systems Multimedia Solutions GmbH

Aufsichtsrat: Thilo Kusch (Vorsitzender)
Geschäftsführung: Peter Klingenburg, Susanne Heger, Dr. Rolf Werner
Handelsregister: Amtsgericht Dresden HRB 11433 Sitz der Gesellschaft:
Dresden
Ust-IdNr.: DE 811 807 949



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: [java6][deadlock] with parallel classloading, and how to deal with it

2014-03-19 Thread Richard S. Hall


On 3/19/14, 10:47 , Stefan Egli wrote:

Hi,

I wrote a test which reproduces the deadlock on Java 6 (MacOS). It's
attached to FELIX-4462 ([0]). Unfortunately I only managed to get it fail
when running from Eclipse, not via 'mvn clean test'. I had to use byteman
to inject a delay in the BundleClassLoader.findClass - and if that inject
is not properly applied, the deadlock is not triggered. So there seems to
be a difference with byteman-injection under maven vs standalone.

Re a possible fix: I've also added a trivial patch suggesting to
synchronized findClass - but fear that this is too heavy, as it would
avoid parallel classloading for Java 7++. At least, when synchronizing
findClass, my test succeeds :)


Well, in my comments below, I suggest just changing the lock object from 
m_classList to this, which should be effectively equivalent to 
synchronizing on the findClass() method. So, if that solves your issue, 
then the proper patch is simply to detect if we are on Java 7 or above 
and then use m_classList as the lock object, otherwise use this as the 
lock object.


- richard



Cheers,
Stefan
--
[0] https://issues.apache.org/jira/browse/FELIX-4462

On 3/17/14 4:22 PM, Richard S. Hall he...@ungoverned.org wrote:


On 3/17/14, 09:07 , Stefan Egli wrote:

Hi Richard,

(see below)

On 3/17/14 1:34 PM, Richard S. Hall he...@ungoverned.org wrote:


On 3/14/14, 05:26 , Stefan Egli wrote:

Hi,

I just ran into the famous deadlock with Java 6 where the same class
is
being loaded from two different bundles (also see FELIX-3953). This
happened on a startup of a CQ instance.

I'll add more analysis details but my question is: what is the
suggested best practice to handle this issue?
* Use '-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass' as
suggested in [0] and [1]? But then again [1] says You must treat it
as
unstable, experimental, temporary, unsupported.

This is your only option if you are not able to use Java 7.


* Or would it be worth while to reconsider fixing FELIX-3953?

Unless we modify the JRE, there is no way to fix it. The Felix
framework
doesn't hold locks while class loading.

I obviously don't know the details of the BundleClassLoader, so I can
only
speculate. But it seems the problem is its 'class locking'
(m_classLocks).
The assumption there seems, that BundleClassLoader.findClass() is always
called unsynchronized. But this is clearly not the case in Java 6.

The underlying issue of eliminating class loader cycle deadlocks is not
possible.

The m_classLocks structure was put in place to support Java 7 parallel
class loaders. So, I guess the question is, does this approach make
deadlock more likely on older JVMs? I don't know the answer to that nor
do I have the time to look into it, but it would be worthwhile to
investigate/understand.


So maybe Java 6 would need a special class loader which is
synchronize-aware.. (in which case you could for example synchronize the
BundleClassLoaderJava6.findClass() - given that the synchronization
would
be done by the VM anyway).

Or introduce a 'proxy class loader' such that the VM would always only
(be
able to) synchronize the proxy.. (if that's feasible)

Again, the underlying issue is not resolvable. Before we did
m_classLocks, we were actually locking on this (i.e., the class
loader) before calling findLoadedClass() and that was the only time we
held a lock and we were still getting into deadlocks because of the
JVM-held locks.

As I state above, the only real issue in my mind is if we were to, for
example, effectively go back to locking on this for pre-Java7 JVMs,
would this solve the issue in your specific use case?

What we were trying to do was to keep a single approach for class
loading, but one that would automatically gain the parallel benefits on
Java 7. It could be possible that it interferes somehow.

If you want to do a test, modify the class loader code so lock on this
instead of m_classLocks when accessing the m_classLocks data structure,
I think that is all that would be necessary to simulate it. If it turns
out to help your situation, then it might be an easy patch. We just have
to modify the class loader to detect which lock it should use.

- richard


- richard


Cheers,
Stefan


- richard

Here's more details (see thread-dumps below):
* Thread 158 (on behalf on bundle X) wants to load class A which is
part of bundle Y - hence goes via getClassByDelegation - then does a
BundleWiringImpl$BundleClassLoader.findClass
* before Thread 158 continues VM threading decides to give Thread
156
some execution time:
* Thread 156 now wants to load same class A, but this time directly
on behalf of bundle Y.
* Due to [1] Thread 156 internally does a synchronized
loadClassInternal, thus holds the lock on 6f025d710 (the
BundleClassLoader of bundle Y) (I was able to verify this by hooking
the
deadlocked-VM to a debugger, which indicated exactly this)
* Thread 156 now continues into
BundleClassLoader.findClass

Re: [java6][deadlock] with parallel classloading, and how to deal with it

2014-03-19 Thread Richard S. Hall



On 3/19/14, 11:00 , Richard S. Hall wrote:

On 3/19/14, 10:47 , Stefan Egli wrote:

Hi,

I wrote a test which reproduces the deadlock on Java 6 (MacOS). It's
attached to FELIX-4462 ([0]). Unfortunately I only managed to get it 
fail
when running from Eclipse, not via 'mvn clean test'. I had to use 
byteman
to inject a delay in the BundleClassLoader.findClass - and if that 
inject
is not properly applied, the deadlock is not triggered. So there 
seems to

be a difference with byteman-injection under maven vs standalone.

Re a possible fix: I've also added a trivial patch suggesting to
synchronized findClass - but fear that this is too heavy, as it would
avoid parallel classloading for Java 7++. At least, when synchronizing
findClass, my test succeeds :)


Well, in my comments below, I suggest just changing the lock object 
from m_classList to this, which should be effectively equivalent to 
synchronizing on the findClass() method. So, if that solves your 
issue, then the proper patch is simply to detect if we are on Java 7 
or above and then use m_classList as the lock object, otherwise use 
this as the lock object.


Sorry, that should have been m_classLocks, not m_classList...



- richard



Cheers,
Stefan
--
[0] https://issues.apache.org/jira/browse/FELIX-4462

On 3/17/14 4:22 PM, Richard S. Hall he...@ungoverned.org wrote:


On 3/17/14, 09:07 , Stefan Egli wrote:

Hi Richard,

(see below)

On 3/17/14 1:34 PM, Richard S. Hall he...@ungoverned.org wrote:


On 3/14/14, 05:26 , Stefan Egli wrote:

Hi,

I just ran into the famous deadlock with Java 6 where the same class
is
being loaded from two different bundles (also see FELIX-3953). This
happened on a startup of a CQ instance.

I'll add more analysis details but my question is: what is the
suggested best practice to handle this issue?
* Use '-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass' as
suggested in [0] and [1]? But then again [1] says You must treat it
as
unstable, experimental, temporary, unsupported.

This is your only option if you are not able to use Java 7.


* Or would it be worth while to reconsider fixing FELIX-3953?

Unless we modify the JRE, there is no way to fix it. The Felix
framework
doesn't hold locks while class loading.

I obviously don't know the details of the BundleClassLoader, so I can
only
speculate. But it seems the problem is its 'class locking'
(m_classLocks).
The assumption there seems, that BundleClassLoader.findClass() is 
always

called unsynchronized. But this is clearly not the case in Java 6.

The underlying issue of eliminating class loader cycle deadlocks is not
possible.

The m_classLocks structure was put in place to support Java 7 parallel
class loaders. So, I guess the question is, does this approach make
deadlock more likely on older JVMs? I don't know the answer to that nor
do I have the time to look into it, but it would be worthwhile to
investigate/understand.


So maybe Java 6 would need a special class loader which is
synchronize-aware.. (in which case you could for example 
synchronize the

BundleClassLoaderJava6.findClass() - given that the synchronization
would
be done by the VM anyway).

Or introduce a 'proxy class loader' such that the VM would always only
(be
able to) synchronize the proxy.. (if that's feasible)

Again, the underlying issue is not resolvable. Before we did
m_classLocks, we were actually locking on this (i.e., the class
loader) before calling findLoadedClass() and that was the only time we
held a lock and we were still getting into deadlocks because of the
JVM-held locks.

As I state above, the only real issue in my mind is if we were to, for
example, effectively go back to locking on this for pre-Java7 JVMs,
would this solve the issue in your specific use case?

What we were trying to do was to keep a single approach for class
loading, but one that would automatically gain the parallel benefits on
Java 7. It could be possible that it interferes somehow.

If you want to do a test, modify the class loader code so lock on 
this

instead of m_classLocks when accessing the m_classLocks data structure,
I think that is all that would be necessary to simulate it. If it turns
out to help your situation, then it might be an easy patch. We just 
have

to modify the class loader to detect which lock it should use.

- richard


- richard


Cheers,
Stefan


- richard

Here's more details (see thread-dumps below):
* Thread 158 (on behalf on bundle X) wants to load class A 
which is

part of bundle Y - hence goes via getClassByDelegation - then does a
BundleWiringImpl$BundleClassLoader.findClass
* before Thread 158 continues VM threading decides to give 
Thread

156
some execution time:
* Thread 156 now wants to load same class A, but this time 
directly

on behalf of bundle Y.
* Due to [1] Thread 156 internally does a synchronized
loadClassInternal, thus holds the lock on 6f025d710 (the
BundleClassLoader of bundle Y) (I was able to verify this by hooking

Re: [java6][deadlock] with parallel classloading, and how to deal with it

2014-03-19 Thread Richard S. Hall

I just attached a patch to the issue...could you please try it and see 
if it solves your issue.


If so, report back on the issue. Thanks.

- richard

On 3/19/14, 10:47 , Stefan Egli wrote:

Hi,

I wrote a test which reproduces the deadlock on Java 6 (MacOS). It's
attached to FELIX-4462 ([0]). Unfortunately I only managed to get it fail
when running from Eclipse, not via 'mvn clean test'. I had to use byteman
to inject a delay in the BundleClassLoader.findClass - and if that inject
is not properly applied, the deadlock is not triggered. So there seems to
be a difference with byteman-injection under maven vs standalone.

Re a possible fix: I've also added a trivial patch suggesting to
synchronized findClass - but fear that this is too heavy, as it would
avoid parallel classloading for Java 7++. At least, when synchronizing
findClass, my test succeeds :)

Cheers,
Stefan
--
[0] https://issues.apache.org/jira/browse/FELIX-4462

On 3/17/14 4:22 PM, Richard S. Hall he...@ungoverned.org wrote:


On 3/17/14, 09:07 , Stefan Egli wrote:

Hi Richard,

(see below)

On 3/17/14 1:34 PM, Richard S. Hall he...@ungoverned.org wrote:


On 3/14/14, 05:26 , Stefan Egli wrote:

Hi,

I just ran into the famous deadlock with Java 6 where the same class
is
being loaded from two different bundles (also see FELIX-3953). This
happened on a startup of a CQ instance.

I'll add more analysis details but my question is: what is the
suggested best practice to handle this issue?
* Use '-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass' as
suggested in [0] and [1]? But then again [1] says You must treat it
as
unstable, experimental, temporary, unsupported.

This is your only option if you are not able to use Java 7.


* Or would it be worth while to reconsider fixing FELIX-3953?

Unless we modify the JRE, there is no way to fix it. The Felix
framework
doesn't hold locks while class loading.

I obviously don't know the details of the BundleClassLoader, so I can
only
speculate. But it seems the problem is its 'class locking'
(m_classLocks).
The assumption there seems, that BundleClassLoader.findClass() is always
called unsynchronized. But this is clearly not the case in Java 6.

The underlying issue of eliminating class loader cycle deadlocks is not
possible.

The m_classLocks structure was put in place to support Java 7 parallel
class loaders. So, I guess the question is, does this approach make
deadlock more likely on older JVMs? I don't know the answer to that nor
do I have the time to look into it, but it would be worthwhile to
investigate/understand.


So maybe Java 6 would need a special class loader which is
synchronize-aware.. (in which case you could for example synchronize the
BundleClassLoaderJava6.findClass() - given that the synchronization
would
be done by the VM anyway).

Or introduce a 'proxy class loader' such that the VM would always only
(be
able to) synchronize the proxy.. (if that's feasible)

Again, the underlying issue is not resolvable. Before we did
m_classLocks, we were actually locking on this (i.e., the class
loader) before calling findLoadedClass() and that was the only time we
held a lock and we were still getting into deadlocks because of the
JVM-held locks.

As I state above, the only real issue in my mind is if we were to, for
example, effectively go back to locking on this for pre-Java7 JVMs,
would this solve the issue in your specific use case?

What we were trying to do was to keep a single approach for class
loading, but one that would automatically gain the parallel benefits on
Java 7. It could be possible that it interferes somehow.

If you want to do a test, modify the class loader code so lock on this
instead of m_classLocks when accessing the m_classLocks data structure,
I think that is all that would be necessary to simulate it. If it turns
out to help your situation, then it might be an easy patch. We just have
to modify the class loader to detect which lock it should use.

- richard


- richard


Cheers,
Stefan


- richard

Here's more details (see thread-dumps below):
* Thread 158 (on behalf on bundle X) wants to load class A which is
part of bundle Y - hence goes via getClassByDelegation - then does a
BundleWiringImpl$BundleClassLoader.findClass
* before Thread 158 continues VM threading decides to give Thread
156
some execution time:
* Thread 156 now wants to load same class A, but this time directly
on behalf of bundle Y.
* Due to [1] Thread 156 internally does a synchronized
loadClassInternal, thus holds the lock on 6f025d710 (the
BundleClassLoader of bundle Y) (I was able to verify this by hooking
the
deadlocked-VM to a debugger, which indicated exactly this)
* Thread 156 now continues into
BundleClassLoader.findClass(BundleWiringImpl.java:2115) where it has
to
do a m_classLocks.wait() - since Thread 158 earlier marked the
BundleClassLoader 'in use/locked for class A'.
* Thread 158 on the other hand continues the findClass execution,
eventually walks

Re: [java6][deadlock] with parallel classloading, and how to deal with it

2014-03-17 Thread Richard S. Hall


On 3/14/14, 05:26 , Stefan Egli wrote:

Hi,

I just ran into the famous deadlock with Java 6 where the same class is being 
loaded from two different bundles (also see FELIX-3953). This happened on a 
startup of a CQ instance.

I'll add more analysis details but my question is: what is the suggested best 
practice to handle this issue?
  * Use '-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass' as suggested in [0] and 
[1]? But then again [1] says You must treat it as unstable, experimental, 
temporary, unsupported.


This is your only option if you are not able to use Java 7.


  * Or would it be worth while to reconsider fixing FELIX-3953?


Unless we modify the JRE, there is no way to fix it. The Felix framework 
doesn't hold locks while class loading.


- richard


Here's more details (see thread-dumps below):
  * Thread 158 (on behalf on bundle X) wants to load class A which is part of 
bundle Y - hence goes via getClassByDelegation - then does a 
BundleWiringImpl$BundleClassLoader.findClass
  * before Thread 158 continues VM threading decides to give Thread 156 some 
execution time:
  * Thread 156 now wants to load same class A, but this time directly on behalf 
of bundle Y.
  * Due to [1] Thread 156 internally does a synchronized loadClassInternal, 
thus holds the lock on 6f025d710 (the BundleClassLoader of bundle Y) (I was 
able to verify this by hooking the deadlocked-VM to a debugger, which indicated 
exactly this)
  * Thread 156 now continues into 
BundleClassLoader.findClass(BundleWiringImpl.java:2115) where it has to do a 
m_classLocks.wait() - since Thread 158 earlier marked the BundleClassLoader 'in 
use/locked for class A'.
  * Thread 158 on the other hand continues the findClass execution, eventually 
walks into checkCerts, which is synchronized(this), which Thread 156 holds
  * and we have the famous classloading deadlock.

Cheers,
Stefan
--
[0] https://issues.apache.org/jira/browse/FELIX-3953
[1] http://underlap.blogspot.de/2006/11/experimental-fix-for-sunbug-4670071.html

PS: Used org.apache.felix.framework 4.3.0.R1558704 - which is a 
snapshot-release as of SVN revision 1558704

Thread-158 daemon prio=5 tid=7f83a4cbd800 nid=0x25b73e000 waiting for monitor 
entry [25b73c000]
java.lang.Thread.State: BLOCKED (on object monitor)
 at java.lang.ClassLoader.checkCerts(ClassLoader.java:788)
 - waiting to lock 6f025d710 (a 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
 at java.lang.ClassLoader.preDefineClass(ClassLoader.java:493)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2297)
 at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1519)
 at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1973)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
 at 
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1392)
 at 
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1571)
 at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1502)
 at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1973)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
[class A being loaded from a class of bundle X]

Thread-156 daemon prio=5 tid=7f83a57ac800 nid=0x25b36b000 in Object.wait() 
[25b369000]
java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 at java.lang.Object.wait(Object.java:485)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2115)
 - locked 6f788bf40 (a java.util.HashMap)
 at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1519)
 at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1973)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
[class A being loaded from a class of bundle Y]





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: [java6][deadlock] with parallel classloading, and how to deal with it

2014-03-17 Thread Richard S. Hall


On 3/17/14, 09:07 , Stefan Egli wrote:

Hi Richard,

(see below)

On 3/17/14 1:34 PM, Richard S. Hall he...@ungoverned.org wrote:


On 3/14/14, 05:26 , Stefan Egli wrote:

Hi,

I just ran into the famous deadlock with Java 6 where the same class is
being loaded from two different bundles (also see FELIX-3953). This
happened on a startup of a CQ instance.

I'll add more analysis details but my question is: what is the
suggested best practice to handle this issue?
   * Use '-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass' as
suggested in [0] and [1]? But then again [1] says You must treat it as
unstable, experimental, temporary, unsupported.

This is your only option if you are not able to use Java 7.


   * Or would it be worth while to reconsider fixing FELIX-3953?

Unless we modify the JRE, there is no way to fix it. The Felix framework
doesn't hold locks while class loading.

I obviously don't know the details of the BundleClassLoader, so I can only
speculate. But it seems the problem is its 'class locking' (m_classLocks).
The assumption there seems, that BundleClassLoader.findClass() is always
called unsynchronized. But this is clearly not the case in Java 6.


The underlying issue of eliminating class loader cycle deadlocks is not 
possible.


The m_classLocks structure was put in place to support Java 7 parallel 
class loaders. So, I guess the question is, does this approach make 
deadlock more likely on older JVMs? I don't know the answer to that nor 
do I have the time to look into it, but it would be worthwhile to 
investigate/understand.




So maybe Java 6 would need a special class loader which is
synchronize-aware.. (in which case you could for example synchronize the
BundleClassLoaderJava6.findClass() - given that the synchronization would
be done by the VM anyway).

Or introduce a 'proxy class loader' such that the VM would always only (be
able to) synchronize the proxy.. (if that's feasible)


Again, the underlying issue is not resolvable. Before we did 
m_classLocks, we were actually locking on this (i.e., the class 
loader) before calling findLoadedClass() and that was the only time we 
held a lock and we were still getting into deadlocks because of the 
JVM-held locks.


As I state above, the only real issue in my mind is if we were to, for 
example, effectively go back to locking on this for pre-Java7 JVMs, 
would this solve the issue in your specific use case?


What we were trying to do was to keep a single approach for class 
loading, but one that would automatically gain the parallel benefits on 
Java 7. It could be possible that it interferes somehow.


If you want to do a test, modify the class loader code so lock on this 
instead of m_classLocks when accessing the m_classLocks data structure, 
I think that is all that would be necessary to simulate it. If it turns 
out to help your situation, then it might be an easy patch. We just have 
to modify the class loader to detect which lock it should use.


- richard


- richard



Cheers,
Stefan


- richard

Here's more details (see thread-dumps below):
   * Thread 158 (on behalf on bundle X) wants to load class A which is
part of bundle Y - hence goes via getClassByDelegation - then does a
BundleWiringImpl$BundleClassLoader.findClass
   * before Thread 158 continues VM threading decides to give Thread 156
some execution time:
   * Thread 156 now wants to load same class A, but this time directly
on behalf of bundle Y.
   * Due to [1] Thread 156 internally does a synchronized
loadClassInternal, thus holds the lock on 6f025d710 (the
BundleClassLoader of bundle Y) (I was able to verify this by hooking the
deadlocked-VM to a debugger, which indicated exactly this)
   * Thread 156 now continues into
BundleClassLoader.findClass(BundleWiringImpl.java:2115) where it has to
do a m_classLocks.wait() - since Thread 158 earlier marked the
BundleClassLoader 'in use/locked for class A'.
   * Thread 158 on the other hand continues the findClass execution,
eventually walks into checkCerts, which is synchronized(this), which
Thread 156 holds
   * and we have the famous classloading deadlock.

Cheers,
Stefan
--
[0] https://issues.apache.org/jira/browse/FELIX-3953
[1]
http://underlap.blogspot.de/2006/11/experimental-fix-for-sunbug-4670071.h
tml

PS: Used org.apache.felix.framework 4.3.0.R1558704 - which is a
snapshot-release as of SVN revision 1558704

Thread-158 daemon prio=5 tid=7f83a4cbd800 nid=0x25b73e000 waiting for
monitor entry [25b73c000]
 java.lang.Thread.State: BLOCKED (on object monitor)
  at java.lang.ClassLoader.checkCerts(ClassLoader.java:788)
  - waiting to lock 6f025d710 (a
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5)
  at java.lang.ClassLoader.preDefineClass(ClassLoader.java:493)
  at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
  at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
  at
org.apache.felix.framework.BundleWiringImpl

Re: Class loader related issue...

2014-03-12 Thread Richard S. Hall



On 3/12/14, 10:30 , Henry, Cedric wrote:

Hello,

I have a system using Felix and one of the bundles contains an SMTP client 
based on the JavaMail library.

That system is installed on different machines, and for some of them I have a 
situation as the one mentioned in 
http://www.oracle.com/technetwork/java/javamail/faq-135477.html#castmultipart.

In my opinion, there is an issue related to the class loader as it could be 
related to the fact the system package got updated on these machines.
I have been reading from 
https://felix.apache.org/site/apache-felix-framework-bundle-cache.html and 
http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.html.

I am currently wondering if there could be a solution for that matter through 
configuring framework properties, or others.
Nonetheless, I am not sure about if it is the case and which properties should 
be used.


I'm not sure to which properties you are referring, but just try 
different values and see what happens.


- richard



Best Regards,
Cedric HENRY
Technical Lead, Mobile Speech and V2T Engineering
Spinvox Limited, a Nuance group company
Wethered House
Pound Lane
Buckinghamshire, SL7 2AF
NUANCE.COMhttps://mail.nuance.com/owa/redir.aspx?C=967cf1f523c44197bb544a0ed5ef4801URL=http%3a%2f%2fwww.nuance.com%2f

The experience speaks for itself ™






-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Gogo Shell, leveraging existing Java capabilities

2014-03-05 Thread Richard S. Hall



On 3/5/14, 12:03 , Guillaume Nodet wrote:

Try the following:
   addcommand ($.context loadClass java.lang.System)


Or:

g! addcommand system ((bundle 0) loadClass java.lang.System)

You need to give it a class loader for doing the loadClass...

- richard




2014-03-05 17:42 GMT+01:00 Daniel McGreal dan...@redbite.com:


Hi Felix users,


https://felix.apache.org/documentation/subprojects/apache-felix-gogo/rfc-147-overview.html(which
 has quite some formatting issues, btw).

// add all public methods on java.lang.System as commands:

g! addcommand system (loadClass java.lang.System)
g! system:getproperties
sun.io.unicode.encodingUnicodeLittle
java.version1.5.0_19
java.class.path bin/felix.jar
java.awt.graphicsenvapple.awt.CGraphicsEnvironment
user.language   en
sun.os.patch.level  unknown
os.version  10.6.2
[snip]

g! addcommand (loadClass java.lang.System)
gogo: CommandNotFoundException: Command not found: loadClass

What am I doing wrong? I have the three org.apache.felix.gogo.* jars from
https://felix.apache.org/downloads.cgi

I actually want to try to call Runtime.getInstance().maxMemory(). Is this
possible?

Best, Dan.



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Problem with compiling Felix 3.1.1

2014-02-14 Thread Richard S. Hall

The framework isn't a bundle, so you could try just the normal mvn 
clean install...


On 2/14/14, 04:31 , Elros wrote:

Hi Felix users,

I need to compile the version of Apache Felix 3.1.1 on my Mac Air with JVM
1.7.0_51. When i try to do the command mvn -Dpackaging=bundle install the
process of building fail with this message: [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) on project org.apache.felix.framework: Compilation
failure: Compilation failure: (and other error messages).

Suggestions?

Best, Nino



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Problem-with-compiling-Felix-3-1-1-tp5007226.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Updating the System Bundle

2014-01-02 Thread Richard S. Hall


On 1/2/14, 10:07 , Daniel McGreal wrote:

Hi all,


Updating the system bundle has the effect of restarting the OSGi framework 
(requires support from the launcher).

- http://wiki.osgi.org/wiki/System_Bundle

Does the Felix launcher support updating itself? I notice there's no bundle.jar 
in bundle0 in the cache, are bundle updates reflected in felix.jar for 
subsequent boots?


It will shutdown and restart the framework on an update to the system 
bundle, but that's it. Updating the system bundle is not intended to 
update the framework, just restart it...if I recall correctly.


- richard



Many thanks, Dan.
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Withdraw GOGO-Shell

2013-12-28 Thread Richard S. Hall



On 12/27/13, 11:25 , Ulrich wrote:

Am trying to get familiar with OSGi. Therefore have right now installed Felix
to my Eclipse Kepler installation following the description as is published
in http://felix.apache.org/site/integrating-felix-with-eclipse.html.
But unfortunatly when starting Felix I see the GOGO-shell. This might be
an enhancement but while in my learning phase I would prefer to be able to
use the commonly know commands to control the bundles. For example I would
like to use ps instead of lb to list the installed bundles.
Is the a command to switch from gogo to whatever shell, which allows for
the OSGi-commands?

What might have gone wrong with my installation, that I ended up with this
shell? The installation description doesn't mention it.


I have to assume you are talking about the old Felix shell 
service...technically, you could probably install the last version of 
that, but it hasn't been shipped with the Felix framework for a very 
long time now. I agree with Neil, just spend a little time to learn the 
new commands, Gogo is much better than the old shell service.


- richard



Thanks,
Ulrich



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Withdraw-GOGO-Shell-tp5006613.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: [Discuss]About Unable to acquire global lock for resolve

2013-12-18 Thread Richard S. Hall

On 12/18/13, 09:06 , Daniel McGreal wrote:
Hi,
I wonder if this issue could be the cause, or related to problems when
running on JamVM (e.g. GNU Classpath) described here:
https://www.mail-archive.com/dev@felix.apache.org/msg31518.html
Best, Dan.

I don't think they are related. Your issue deals with class loader
locks, not the global lock (which is a Felix framework-specific thing).

- richard

On 18 Dec 2013, at 13:57, Felix Meschberger fmesc...@adobe.com wrote:

Am 17.12.2013 um 14:25 schrieb Richard S. Hall he...@ungoverned.org:

On 12/17/13, 04:36 , Tang Yong wrote:
Hi All,

I met an issue as the following,

...
Caused by: org.osgi.framework.BundleException: Unable to acquire global
lock for resolve.
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
...

Richard said the issue is not a bug[1] of felix, and I also agree with him.

However, I want to say once we truely met the issue and try to catch the
exception on upper layer, how can we do?

I think that best way should be: felix offered some api to let us
retrieve whether bundle lock has been released by other thread.

The second way can be: do a loop and wait for the changing of current
bundle state, and set a timeout to avoid infinite loop.

The third way should be: adjusting upper layer's bundles and decoupling
them to avoid the case…
I think there is a patch around somewhere in the issues where I proposed to
actually implement such a loop and timeout in the acquireGlobalLock method
itself. Yet, it does not solve the problem really so we never applied.

Want to listen your ideas.
The main way I'd like to address this issue is to simply avoid it by
eliminating the use of the global lock altogether. What I had thought
about long ago was to simply make resolving optimistic so that it would
work on a copy of the framework state and if the framework state changed
at the end of the resolve, it would try to resolve again until the
framework state didn't change (perhaps with a retry limit).
This sounds promising.

Unfortunately we hit this deadlock every now and then, even though we try
hard to setup our system to prevent (for example by carefully leveraging the
start level service on startup; nasty but pragmatic) them.

Regrds
Felix

The only other place that uses the global lock is for refreshing, but we
could probably eliminate it there in a somewhat similar fashion by
calculating all needed bundle locks in advance and locking all bundles
individually (you'd still need to double check the calculation to make
sure nothing changed and potentially release and try again).

- richard

[1]:http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3c4d498058.7080...@ungoverned.org%3E

Thanks
Tang

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: [Discuss]About Unable to acquire global lock for resolve

2013-12-17 Thread Richard S. Hall

On 12/17/13, 04:36 , Tang Yong wrote:
Hi All,

I met an issue as the following,

Richard said the issue is not a bug[1] of felix, and I also agree with him.

However, I want to say once we truely met the issue and try to catch the
exception on upper layer, how can we do?

I think that best way should be: felix offered some api to let us
retrieve whether bundle lock has been released by other thread.

The second way can be: do a loop and wait for the changing of current
bundle state, and set a timeout to avoid infinite loop.

The third way should be: adjusting upper layer's bundles and decoupling
them to avoid the case...

Want to listen your ideas.

The main way I'd like to address this issue is to simply avoid it by
eliminating the use of the global lock altogether. What I had thought
about long ago was to simply make resolving optimistic so that it would
work on a copy of the framework state and if the framework state changed
at the end of the resolve, it would try to resolve again until the
framework state didn't change (perhaps with a retry limit).

- richard

[1]:http://mail-archives.apache.org/mod_mbox/felix-users/201102.mbox/%3c4d498058.7080...@ungoverned.org%3E

Thanks
Tang

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Updating the implementation bundle

2013-12-09 Thread Richard S. Hall


On 12/9/13, 02:37 , Snorre Lothar von Gohren Edwin wrote:

Hi

I have split up my bundles with an API bundle, and an implementation bundle.
Right now im trying to update the implementation bundle to be able to to
other things.
But for some reason, even if the new version displays in the list of
installed bundles, it still calls towards the old implmentation bundle.
Everything is only connected throuhg services.

Except for the implementation and api bundle, they are connected simply
through imports.

What might be the reason for this issue?

Iv tried update and refresh on the bundle, but nothing works at runtime.


If you see that the existing bundle is getting updated (e.g., change the 
bundle version so you can see if you get the newer version after update) 
and you call refresh on it, but you still don't see the client calling 
the newer service, then the only thing I can think of is you are 
packaging your bundles incorrectly or perhaps configured the framework 
in a weird way (e.g., it also exports these packages). This should work.


- richard





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Stale BundleWiringImpl (ClassLoader) used for sun.reflect.ConstructorAccessorImpl

2013-11-26 Thread Richard S. Hall



On 11/25/13, 22:13 , Karl Rieb wrote:

Thanks for the quick response!  We have managed to come up with a work-around 
for our problem.  I will document it here in case someone else comes across the 
same issue we had, although I did have some questions (see last paragraph of 
e-mail).

I created a test environment to reproduce the bug that avoided spawning any 
threads; I made necessary calls within the Activator.  Using this test 
environment, I was able to narrow down the issue to an embedded dependency 
being used by our bundle.  Tracing through the code, I saw the embedded 
dependency dynamically adds a Java Security provider if one is not already 
present.  The code looks something like:

 if( Security.getProvider(BouncyCastleProvider.PROVIDER_NAME) == null ) {
 Security.addProvider(new BouncyCastleProvider());
 }

This happens upon loading one of the classes in the embedded dependency.  Now 
this is pure educated guessing on my part, but I think the problem arises 
because the BouncyCastleProvider class is being loaded by the current bundle's 
ClassLoader, but getting added statically to a class, java.security.Security, 
that is handled by one of the core/boot felix ClassLoaders (since it is a base 
JVM class).  So now this class, java.security.Security, that is accessible by 
all the bundles has a reference to a class, BouncyCastleProvider, that is tied 
to a specific bundle's bootloader.  When I do the uninstall and re-install of 
the bundle, the above code never adds a new provider because it can still see 
the old one it set previously (this is why I think the java.security.Security 
class is being loaded outside of the bundle's ClassLoader).

Now when the newly re-installed bundle makes some crypto calls that require the 
BouncyCastle provider, some classes get loaded 
(sun.reflect.ConstructorAccessorImpl, specifically) using the old bundle's 
ClassLoader.  This triggers the NullPointerException because the old 
ClassLoader is disposed.  Again, purely an educated guess.

WORKAROUND:  The workaround we set in place was to add the BouncyCastleProvider 
as a Java Security provider in our bootstrapping bundle that starts before all 
our other bundles.  This bundle removes any existing BouncyCastleProvider then 
adds one.  When the bootstrapping bundle is stopped, it removes the 
BouncyCastleProvider.  This ensures the BouncyCastle provider always has a 
valid ClassLoader since it is only ever available as long as our bootstrapping 
bundle is active and started.  Additionally, this lets us managed the version 
of BouncyCastleProvider we want to use.

Note: we had a strict requirement that prevented us from being able to restart 
our OSGi framework.  A simpler work-around was to configure the boot delegation 
property for Felix:

   -Dorg.osgi.framework.bootdelegation=sun.*

In either case, the issue no longer appears in our test environment using 
either fix mentioned above.  The boot delegation fix makes me a bit nervous 
since presumably you are still referencing an old ClassLoader.

Is there is a recommended practice for using the Java Crypto API in OSGi with 
custom providers?  Should providers be added statically outside of Felix?  
Should the Java Crypto APIs be avoided?  Or is boot delegation meant to be set 
when using these types of frameworks?


The tricky aspect here is that the embedded library automatically adds 
the provider when someone loads a class. It seems you'd have to modify 
the library to be aware that it has active/inactive states and it can 
only provide the crypto algorithm when it is active. There is no other 
way that I can think of because a non-activated bundle cannot get any 
events and it really isn't possible for the bundle to learn that it is 
being uninstalled (or refresh).


A slight different way to do it would be an extender pattern, where the 
provider bundles could offer their provider objects and the extender 
bundle could provide them when the bundle is resolved and remove them 
when the bundle is uninstalled/refreshed.


There is no real way around this issue, you cannot pass objects around 
from bundles and then not clean up after them after an uninstall/refresh.


- richard



-Karl



From: Richard S. Hall [he...@ungoverned.org]
Sent: Saturday, November 23, 2013 3:25 PM
To: users@felix.apache.org
Subject: Re: Stale BundleWiringImpl (ClassLoader) used for 
sun.reflect.ConstructorAccessorImpl

On 11/23/13, 13:29 , Karl Rieb wrote:

Hi,

We are using felix framwork 3.0.4 and are having problems when one of our 
bundle upgrades.  We noticed the same issue also occurs if we uninstall, then 
later re-install the bundle.

The bundle has an embedded dependency (e.g. a non-OSGi jar) that makes a call to 
MessageDigest.getInstance(MD4).  When the bundle is first installed, This 
internal call goes through without a problem.  But after upgrading the bundle or 
uninstalling and re-installing it, we start

Re: Getting Felix to support OSGi Core R5 (Was: Re: Running aries subsystem 1.0.0 on felix 4.2.1 failed)

2013-11-26 Thread Richard S. Hall


On 11/26/13, 11:01 , David Bosschaert wrote:

Thanks Richard.

I have now also provided patches for the following:
FELIX-4082
FELIX-4085
FELIX-4331

they also work towards Core R5 support.


Cool. Thanks. Still on my to do...will try to get to it this week.

- richard



Cheers,

David

On 20 November 2013 15:28, Richard S. Hall he...@ungoverned.org wrote:

On 11/20/13, 06:06 , David Bosschaert wrote:

It's been a while but I started implementing some of these. I added
patches to the following 3 bugs:
* FELIX-3868
* FELIX-4080
* FELIX-4083

Would be great if someone could review them and apply :)


Thanks! I'll try to look into them.

- richard


Cheers,

David

On 28 May 2013 15:00, David Bosschaert david.bosscha...@gmail.com wrote:

See below for the jiras:

On 28 May 2013 14:33, David Bosschaert david.bosscha...@gmail.com
wrote:



* New org.osgi.framework.UnfilteredServiceListener interface


Not implemented.


https://issues.apache.org/jira/browse/FELIX-4080


* New org.osgi.framework.VersionRange class


I would assume the class is there, since it is part of the API. Not
sure
if there was anything else necessary.


Ok, yeah, let's assume no work is needed ;)




* The Resource API and it's use in the Wiring API


I would guess most of that stuff would be in there since the framework
had to move to the new API.


Cool - didn't add any Jiras for this then...


* New osgi.identity namespace


Not implemented, should be easy to add.


https://issues.apache.org/jira/browse/FELIX-4081


* New value and new default for org.osgi.framework.bsnversion
framework
property


Not implemented.


https://issues.apache.org/jira/browse/FELIX-4082


* support for static valueOf methods in the Filter


Not implemented.


https://issues.apache.org/jira/browse/FELIX-4083


* Enhanced Bundle.adapt() to support AccessControlContext


I don't think this is implemented.


https://issues.apache.org/jira/browse/FELIX-4084


* Updates to the Bundle Hook Specification (Bundle Collision Hook)


Not implemented.


https://issues.apache.org/jira/browse/FELIX-4085

If I missed anything - let me know...

Cheers,

David


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Stale BundleWiringImpl (ClassLoader) used for sun.reflect.ConstructorAccessorImpl

2013-11-23 Thread Richard S. Hall


On 11/23/13, 13:29 , Karl Rieb wrote:

Hi,

We are using felix framwork 3.0.4 and are having problems when one of our 
bundle upgrades.  We noticed the same issue also occurs if we uninstall, then 
later re-install the bundle.

The bundle has an embedded dependency (e.g. a non-OSGi jar) that makes a call to 
MessageDigest.getInstance(MD4).  When the bundle is first installed, This 
internal call goes through without a problem.  But after upgrading the bundle or 
uninstalling and re-installing it, we start to get the following exceptions:

  Caused by: java.security.NoSuchAlgorithmException: Error constructing 
implementation (algorithm: MD4, provider: BC, class: 
org.bouncycastle.jce.provider.JDKMessageDigest$MD4)
 at java.security.Provider$Service.newInstance(Provider.java:1262)
 at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
 at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
 at java.security.Security.getImpl(Security.java:695)
 at java.security.MessageDigest.getInstance(MessageDigest.java:159)
 at rpc.security.ntlm.Responses.ntlmHash(Responses.java:186)
 at rpc.security.ntlm.Responses.ntlmv2Hash(Responses.java:203)
 at rpc.security.ntlm.Responses.getLMv2Response(Responses.java:102)
 at 
rpc.security.ntlm.NtlmAuthentication.createType3(NtlmAuthentication.java:270)
 ... 23 more
Caused by: java.lang.NullPointerException
 at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
 at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
 at java.security.Provider$Service.getImplClass(Provider.java:1279)
 at java.security.Provider$Service.newInstance(Provider.java:1237)

Using a debugger, we traced through this call and found that the 
NullPointerException gets triggered when trying to load the 
sun.reflect.ConstructorAccessorImpl class for creating a new instance of 
org.bouncycastle.jce.provider.JDKMessageDigest$MD4.  Note that the classloader 
has no problems finding org.bouncycastle.jce.provider.JDKMessageDigest$MD4, it 
only has an issue with sun.reflect.ConstructorAccessorImpl.

Stepping through the BundleWiringImpl calls, we noticed that the 
NullPointerException occurs because the BundleWiringImpl instance has been 
disposed (e.g. it is stale).  The revision of the BundleWiringImpl confirms 
this since it matches the revision of the original bundle install (when we 
first start up the felix container).  For example, the revision will be 
something like [25] when the currently running bundle revision is actually 
[25.2] or [27] (depending if we do upgrades or uninstall/re-install).

All the other non-sun classes required by the bundle go against the correct 
version of BundleWiringImpl except for sun.reflect.ConstructorAccessorImpl.  
Some how, no matter how many times we uninstall and re-install the bundle, the 
sun.reflect.ConstructorAccessorImpl class always gets loaded by the same stale 
instance of BundleWiringImpl (e.g. [25]).  I imagine there must be some sort of 
caching going on somewhere that is keeping a reference to this old classloader, 
but I don't understand where or how.


The framework isn't caching it, could be in some class loader somewhere. 
But still, this would indicate that when you uninstall and refresh, that 
you aren't really refreshing everything. In most cases, someone has left 
a thread running somewhere that continues to use the stale class loader.


Also, you could try on a new framework version, but if it is a runaway 
thread, it probably won't help.


- richard




Note that we are able to avoid this issue if we set:

   org.osgi.framework.bootdelegation=sun.*

Note that just setting 'sun.reflect.*' does not work.  We tried using dynamic 
imports for all sun packages, but this did not work:

   DynamicImport-Packagesun.*/DynamicImport-Package

Unfortunately we can not easily restart the Felix container to set the boot 
delegation property.  Is there a way to avoid this class loading issue without 
requiring a restart of Felix?

-Karl
This electronic message contains information which may be confidential or 
privileged. The information is intended for the use of the individual or entity 
named above. If you are not the intended recipient, be aware that any 
disclosure, copying, distribution or use of the contents of this information is 
prohibited. If you have received this electronic transmission in error, please 
notify us by e-mail at (postmas...@rapid7.com) immediately.


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Is the OBR documentation out of date?

2013-11-22 Thread Richard S. Hall

I think the API is largely the same...the main difference is the API was 
moved out of the org.osgi.service.obr package and into the 
org.apache.felix.bundlerepository package because OSGi wasn't/isn't 
releasing a spec around this, so we couldn't really continue to use 
their namespace.


- richard

On 11/22/13, 12:04 , Elliot Huntington wrote:

I assume that it is only the OBR Shell Command section that is no longer
valid. Are there any important changes to the other sections, specifically
to the overview, obr repository file, and obr service api sections that a
learner should be aware of?


On Thu, Nov 21, 2013 at 4:27 PM, Richard Hall he...@ungoverned.org wrote:


Yeah, apparently it is out of date. The obr command doesn't exist any more,
it is just a scope in Gogo. Type 'help' to get all commands and the
commands in the obr scope are the one you want.

- richard
On Nov 21, 2013 6:04 PM, Elliot Huntington elliot.hunting...@gmail.com
wrote:


Following the instructions at
http://felix.apache.org/site/apache-felix-osgi-bundle-repository.htmlI'm
doing the following:

g! obr help
gogo: CommandNotFoundException: Command not found: obr
g! obr:help
gogo: CommandNotFoundException: Command not found: obr:help
g! lb
START LEVEL 1
ID|State  |Level|Name
 0|Active |0|System Bundle (4.2.1)
 1|Active |1|com.typesafe.akka.osgi (2.2.1)
 2|Active |1|com.typesafe.config (1.0.2)
 3|Active |1|Apache Felix Bundle Repository (1.6.6)
 4|Active |1|Apache Felix Gogo Command (0.12.0)
 5|Active |1|Apache Felix Gogo Runtime (0.10.0)
 6|Active |1|Apache Felix Gogo Shell (0.10.0)
 7|Active |1|Scala Standard Library
(2.10.2.v20130530-074427-VFINAL-60d462ef6e)
 8|Installed  |1|Servlet 2.1 API (1.0.0)
g!

As you can see, the obr help command does not work. Neither does the

obr

list-url. This is my first time experimenting with the OBR. Am I missing
something?

If I just type help I do see an option: obr:list which does list

bundles

in the OBR, but that doesn't seem to match the documentation on the
referenced site.

Thanks,
Elliot




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Getting Felix to support OSGi Core R5 (Was: Re: Running aries subsystem 1.0.0 on felix 4.2.1 failed)

2013-11-20 Thread Richard S. Hall



On 11/20/13, 06:06 , David Bosschaert wrote:

It's been a while but I started implementing some of these. I added
patches to the following 3 bugs:
* FELIX-3868
* FELIX-4080
* FELIX-4083

Would be great if someone could review them and apply :)


Thanks! I'll try to look into them.

- richard



Cheers,

David

On 28 May 2013 15:00, David Bosschaert david.bosscha...@gmail.com wrote:

See below for the jiras:

On 28 May 2013 14:33, David Bosschaert david.bosscha...@gmail.com wrote:



* New org.osgi.framework.UnfilteredServiceListener interface


Not implemented.


https://issues.apache.org/jira/browse/FELIX-4080




* New org.osgi.framework.VersionRange class


I would assume the class is there, since it is part of the API. Not sure
if there was anything else necessary.


Ok, yeah, let's assume no work is needed ;)





* The Resource API and it's use in the Wiring API


I would guess most of that stuff would be in there since the framework
had to move to the new API.


Cool - didn't add any Jiras for this then...




* New osgi.identity namespace


Not implemented, should be easy to add.


https://issues.apache.org/jira/browse/FELIX-4081




* New value and new default for org.osgi.framework.bsnversion framework
property


Not implemented.


https://issues.apache.org/jira/browse/FELIX-4082




* support for static valueOf methods in the Filter


Not implemented.


https://issues.apache.org/jira/browse/FELIX-4083




* Enhanced Bundle.adapt() to support AccessControlContext


I don't think this is implemented.


https://issues.apache.org/jira/browse/FELIX-4084




* Updates to the Bundle Hook Specification (Bundle Collision Hook)


Not implemented.


https://issues.apache.org/jira/browse/FELIX-4085

If I missed anything - let me know...

Cheers,

David


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: obr:deploy and bundle versions

2013-11-14 Thread Richard S. Hall


On 11/14/13, 04:12 , Stijn de Witt wrote:

The industry as a whole doesn't treat qualifiers as being less that the version.

In my experience they usually do. E.G they will have -alpha, -beta, -rc1 etc 
until finally they drop the qualifier.
Unfortunately there is no consensus so there are also companies that do it 
differently...
But in my experience this is the approach that is used most often.
So mostly 1.0.0-alpha is treated as being a lower version than 1.0.0, which in 
OSGi is not the case.


It has been my experience that it is common for the qualifier to be used 
to indicate patch level or build number or something like that. There 
are some qualifiers that are used to be less than, like -SNAPSHOT and 
the ones you mention, but there are others like the ones I mention which 
are not. OSGi version numbering did not account for the less than 
variety, largely because it was coming from the specification version 
idea from Java.





For now I would advise people against using a qualifier at all.

So how do you version your snapshot builds if you don't use a qualifier at 
all? Do you bump the micro version on every change in a build?

We work in sprints. The version number stays the same during the sprint. Once 
the sprint is over we bump the micro version (or minor/major if we
had breaking changes) and publish to our internal repository. All our devs just 
get the updated sources and build from source themselves during the sprint.
So we treat code as in flux during the sprint and only publish stabilized 
versions. I can imagine this won't work well if you build and publish nightly.

Maybe I should add a nuance:
Either don't use qualifiers at all, or always use them, including for release 
versions (so no 'naked' versions).


Yes, or used an even/odd approach for numbering release/development 
versions.


- richard



-Stijn


-Original Message-
From: Daniel McGreal [mailto:dan...@redbite.com]
Sent: maandag 11 november 2013 16:17
To: users@felix.apache.org
Subject: Re: obr:deploy and bundle versions

Hi,
I'm not sure if this is pertinent. Having not the time to scrutinise the spec, 
I've been using the qualifier to indicate distribution/deployment specifics for 
my various targets. It's been useful in this regard, where qualifiers are 
treated equal in terms of revision amongst the same major.minor. etc

On 11 Nov 2013, at 15:12, Richard S. Hall wrote:


On 11/11/13, 07:46 , Stijn de Witt wrote:

for OSGi qualifiers are just sorted so a qualified version is greater

This is imho a big miss of the OSGi spec.
If you search for 'semantic versioning' you stumble on to this page:
http://semver.org/

Well, the OSGi version model was being defined back in 2004/early 2005...I'm 
pretty sure the semantic versioning page didn't exist then.


Tom Preston-Werner of Gravatar/GitHub tried to standardize semantic versioning 
across languages and it seems like a very nice attempt. The interesting thing 
is that it is virtually identical to the way OSGi defines semantic versioning, 
except for one crucial difference... They interpret the qualifier as lowering 
the major.minor.micro version, just like Maven does.
This makes a lot of sense. If you look at the way versioning is used throughout 
the industry, this most closely matches with the real-world use. The way OSGi 
does it is unintuitive and keeps surprising people...

It is not clear what you are saying. The industry as a whole doesn't treat qualifiers as 
being less that the version. This is a Maven-specific thing and it only relates to the 
qualifier -SNAPSHOT which is treated as less than the version. All other 
qualifiers are not less than the version.


But yeah, it is probably not something that can ever be changed anymore within 
OSGi so probably we are stuck with it...

Yeah, probably. We tried to look into specifying negative qualifiers, but it 
caused too much pain.


For now I would advise people against using a qualifier at all.

Eclipse seems to survive with qualifiers.

- richard


-Stijn


-Original Message-
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: woensdag 6 november 2013 18:38
To: users@felix.apache.org
Subject: Re: obr:deploy and bundle versions

This is a known issue between how Maven interprets the -SNAPSHOT
qualifier and how OSGi interprets version qualifiers. For Maven, the
-SNAPSHOT qualifier is less that the actual version specified, but
for OSGi qualifiers are just sorted so a qualified version is greater
(i.e.,
newer) than an unqualified version.

- richard

On 11/6/13, 11:48 , Benoît Thiébault wrote:

Hi,

I have been playing with OSGi bundle repositories lately and noticed the 
following behaviour.

In Felix (4.0.2), after adding my OBR URL, I type obr:deploy my-bundle.

On the OBR, I have 2 versions available of this bundle:
- 1.0.7
- 1.0.7-SNAPSHOT

By default, Felix deploys the SNAPSHOT version. Is this an expected behaviour?

I know I can force the use of a given version, but I

Re: Gogo and CommandProcessor, etc interfaces

2013-11-14 Thread Richard S. Hall

Yes, it was basically decided that there wasn't much reason to spec 
Gogo, since there wasn't any real prospect for getting multiple 
implementations. So, as of now, it won't be spec'ed and thus the 
implementation should not be using the spec package name space.


- richard

On 11/14/13 11:11 , Derek Baum wrote:

gogo is based on the OSGi Alliance RFC-147.

Initially gogo used the org.osgi.service.command package defined by RFC-147, 
but as RFC-147 had not transitioned to a specification, Felix decided it was 
better to use an internal package to avoid possible confusion with the 
yet-to-be-released specification.

Karaf did not follow Felix in this respect, so still uses a package in OSGi 
namespace, which is not supported by a specification.

I have just noticed that the OSGi Alliance have ceased work on RFC-147, so it 
will not become an OSGi specification.
http://wiki.osgi.org/wiki/RFC_147


In terms of how to support multiple gogo-like implementations, it depends what 
you want to do with them.

If you just want the ability to run gogo-like scripts, using 
CommandSession.execute(String command), you could create your own API with an 
execute(String command) method. Users of your API would not be exposed to the 
actual gogo implementation.


—
Derek


On 14 Nov 2013, at 15:28, Daniel McGreal dan...@redbite.com wrote:


Hi Felix users,

I notice that Felix's Gogo implementation uses org.apache.felix.service.command 
package, whereas there seems to be a standard (used by Knopflerfish, at least) 
which implements org.osgi.service.command
I have deployment environment constrains requiring both packages for different 
targets.

Is there any advice on how to cleanly support gogo and other implementations? I 
could write a wrapper for Gogo, but that seems a bit zealous.

Thanks, Dan.
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: obr:deploy and bundle versions

2013-11-11 Thread Richard S. Hall



On 11/11/13, 07:46 , Stijn de Witt wrote:

for OSGi qualifiers are just sorted so a qualified version is greater

This is imho a big miss of the OSGi spec.
If you search for 'semantic versioning' you stumble on to this page:
http://semver.org/


Well, the OSGi version model was being defined back in 2004/early 
2005...I'm pretty sure the semantic versioning page didn't exist then.




Tom Preston-Werner of Gravatar/GitHub tried to standardize semantic versioning 
across languages and it seems like a very nice attempt. The interesting thing 
is that it is virtually identical to the way OSGi defines semantic versioning, 
except for one crucial difference... They interpret the qualifier as lowering 
the major.minor.micro version, just like Maven does.
This makes a lot of sense. If you look at the way versioning is used throughout 
the industry, this most closely matches with the real-world use. The way OSGi 
does it is unintuitive and keeps surprising people...


It is not clear what you are saying. The industry as a whole doesn't 
treat qualifiers as being less that the version. This is a 
Maven-specific thing and it only relates to the qualifier -SNAPSHOT 
which is treated as less than the version. All other qualifiers are not 
less than the version.




But yeah, it is probably not something that can ever be changed anymore within 
OSGi so probably we are stuck with it...


Yeah, probably. We tried to look into specifying negative qualifiers, 
but it caused too much pain.




For now I would advise people against using a qualifier at all.


Eclipse seems to survive with qualifiers.

- richard



-Stijn


-Original Message-
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: woensdag 6 november 2013 18:38
To: users@felix.apache.org
Subject: Re: obr:deploy and bundle versions

This is a known issue between how Maven interprets the -SNAPSHOT qualifier and 
how OSGi interprets version qualifiers. For Maven, the -SNAPSHOT qualifier is 
less that the actual version specified, but for OSGi qualifiers are just sorted 
so a qualified version is greater (i.e.,
newer) than an unqualified version.

- richard

On 11/6/13, 11:48 , Benoît Thiébault wrote:

Hi,

I have been playing with OSGi bundle repositories lately and noticed the 
following behaviour.

In Felix (4.0.2), after adding my OBR URL, I type obr:deploy my-bundle.

On the OBR, I have 2 versions available of this bundle:
- 1.0.7
- 1.0.7-SNAPSHOT

By default, Felix deploys the SNAPSHOT version. Is this an expected behaviour?

I know I can force the use of a given version, but I was surprise by the 
default behaviour.

Moreover, if my-bundle depends on a my-bundle2 bundle, that itself is 
available in SNAPSHOT and final versions, the SNAPSHOT is chosen by default...

Thanks for your help,

Kind regards,

Ben
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: felix.bootdelegation.implicit

2013-11-05 Thread Richard S. Hall


On 11/5/13 11:45 , Elliot Huntington wrote:

The Felix documentation states:

felix.bootdelegation.implicit - Specifies whether the framework should try
to guess when to implicitly boot delegate to ease integration with external
code. The default value is true.

The documentation treats boot delegate as a verb in its definitive form.
What does it mean to boot delegate?


Delegate to the boot class loader. Normally, bundles do not have access 
to anything outside of the java.* packages and whatever they import or 
is accessible on their bundle class path.


Generally, you shouldn't have to worry about implicit boot class loader 
delegation, it is just something the framework tries to do to help out 
in certain situations.


- richard






-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Mangen

2013-11-01 Thread Richard S. Hall


On 10/31/13, 17:04 , Jason Tesser wrote:

I am looking for the download to
http://felix.apache.org/documentation/subprojects/apache-felix-manifest-generator-mangen.html

Where can I find it?


I don't believe there ever was an official release, so you'd have to 
build it yourself.


However, this is fairly old, now. I'd assume you'd be better off 
grabbing the latest bnd and using it to generate manifests...


- richard






-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Noob Help

2013-10-25 Thread Richard S. Hall

Try to exclude it in your Import-Package in your pom.xml (e.g., 
!oracle.xml.*).


- richard

On 10/25/13, 00:15 , Wade Girard wrote:

I have been experimenting with felix and learning OSGi for the last week. I 
really like what it has to offer and believe that I can use it for an upcoming 
project that I am working on.

I have been using maven to build bundles, and creating small test bundles, that has been 
going well. I have run into a snag though while trying to create a bundle from an 
existing jar file project. To figure out the dependencies that I need to include in the 
jar, by adding to the Private-Package in the pom.xml for the bundle plugin, I 
have been building-installing-starting, and then just adding each missing package as it's 
reported.

I am currently stuck on this one though

org.osgi.framework.BundleException: Unresolved constraint in bundle x.y.x [41]: 
Unable to resolve 41.0: missing requirement [41.0] osgi.wiring.package; 
(osgi.wiring.package=oracle.xml.parser)

That package is not being used in my project directly, I do use an xml reader 
to read rss feeds, that uses the com.sun.syndication.io.XmlReader class.

If I add oracle.xml.* to the list of packages, then the build gives the 
warning message
[WARNING] Warning building bundle x.y:z:bundle:2.0.0 : Instructions for 
Private-Package that are never used: oracle\.xml\..*|oracle\.xml
and when I install-start the bundle I get the same error message

Any help is appreciated

Thanks
Wade



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: adopt to OSGi

2013-10-17 Thread Richard S. Hall

On 10/17/13 00:31 , Peter Cheung wrote:
 Dear AllI have a app, which is a debugger, it works with qemu and bochs. 
 I am planning to support more VM, so I want to independent the middle part to 
 OSGi. I am not sure i am doing it correctly:
 1) I changed my app to start felix immediately after main(), in the 
 activator, i create a new object which is the original app. So my original 
 app is running inside OSGi container completely, this will let me avoid 
 class-casting error.
 2) I got two new projects : Interface project and Impl project. The interface 
 project doesn't have to be a bundle. Both host app and impl project just 
 include it in maven. Is it the best practice? or I have to make it as a 
 bundle? but i don't see advantage.

If the host app has to access it then it can *not* be in a bundle
(unless you plan to only access it via reflection or some other
proxy-like means in the host app).

What you will likely want to do is to include the interface in your host
app and then configure the framework to export the interface package via
the see bundle (see config property
org.osgi.framework.system.packages.extras). Then in your bundles you
import the interface package which will get it from the system bundle
(which will get it from the class loaded that loaded the framework and
is most likely the app class loader). Thus the host app and the bundles
inside the framework will all be using the same class definition.

Do *not* include multiple copies of the interface in the host and/or
bundles.

Keep in mind that as an OSGi newbie you are picking one of the more
complicated use cases as your starting point...

- richard

 Thanksfrom Peter


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Problem about upgrading of OSGi framework

2013-10-08 Thread Richard S. Hall

It looks like you deploying a system bundle extension. What is in its 
manifest?


- richard

On 10/8/13 02:26 , gavin.yao wrote:

Hi:
When upgrading to Felix Framework 4.2.1,  I run into BundleException,  however, 
old version: 3.2.2  has not this problem.

Here's the full stack trace:


Could not create framework: org.osgi.framework.BundleException: Could not 
create bundle object.
org.osgi.framework.BundleException: Could not create bundle object.
at org.apache.felix.framework.Felix.installBundle(Felix.java:2952)
at 
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165)
at 
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:138)
at 
com.duketechnology.platform.client.startup.Launcher.loadLibrary(Launcher.java:298)
at com.duketechnology.platform.client.startup.Launcher.load(Launcher.java:70)
at com.duketechnology.platform.client.startup.Main.main(Main.java:10)
Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.get(ArrayList.java:382)
at 
org.apache.felix.framework.ExtensionManager.addExtensionBundle(ExtensionManager.java:402)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2918)
... 5 more

The code looks like this:

try
 {
 m_felix = new Felix(null);
 // Now start Felix instance.
 m_felix.start();
 
 BundleContext m_context = m_felix.getBundleContext();
 
 registerAppSettings(m_context, args, getInstallLocation());


 loadLibrary(getLibraryLocaction(), m_context);


 }
 catch (Exception ex)
 {
 System.err.println(Could not create framework:  + ex);
 ex.printStackTrace();
 }
}



thanks!
gavin.yao



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Help with Unresolved constraint error

2013-10-03 Thread Richard S. Hall


On 10/3/13 10:24 , Rajan Parthasarathy wrote:

Hello,

I'm running into an Unresolved constraint in bundle error, and hoping to get 
some insight into it. I'm using Felix system bundle 4.0.3.

The application uses an OBR, with a thread that periodically checks for 
updates. Bundles are updated using Resolver. Here's the code which performs the 
updates (with null checks, etc. removed):

 repositoryAdmin.addRepository(new URL(repositoryUrl));
 Resolver resolver = repositoryAdmin.resolver();
 Resource resource = ... get the resource we want to update ...
 resolver.add(resource);
 if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
 resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES | 
Resolver.START);
 }

The application is running in Felix with the following bundles:
collector-api (0.2.2) - exports itself
collector-engine (0.2.10) - imports collector-api = 0.2.2
port-watcher (0.2.2) - imports collector-api = 0.2.0

I updated the OBR in the following manner:
- replaced collector-api 0.2.2 with collector-api 0.2.3
- replaced engine 0.2.10 with 0.2.11, which imports collector-api = 0.2.3

When I resolve and deploy engine 0.2.11 with the above code, it throws the 
following error:
ERROR 2013-10-02 16:52:58.235 (org.apache.felix.bundlerepository:?) - Resolver: 
Start error - com.rapid7.razor.collector.engine
org.osgi.framework.BundleException: Unresolved constraint in bundle 
com.rapid7.razor.collector.engine [8]: Unable to resolve 8.29: missing requirement [8.29] 
osgi.wiring.package; 
((osgi.wiring.package=com.rapid7.razor.collector.api)(version=0.2.3)(!(version=1.0.0)))

If I replicate the above scenario without the port-watcher bundle installed, 
then it works - the engine gets updated successfully. Any hints as to what is 
happening here?


Not sure. There is code in OBR that tries to update a bundle instead of 
deploying a second version. Perhaps it tries to update collector-api to 
0.2.3 but determines that it breaks the port-watcher dependency if it 
does that so it fails. If that is the case, then that would be a bug 
since it shouldn't fail, it should deploy a second version of collector-api.


When you run your example without port-watcher is the existing version 
of collector-api updated to 0.2.3 or are there two versions of the 
bundle deployed?


- richard



Thank you,
Raj
This electronic message contains information which may be confidential or 
privileged. The information is intended for the use of the individual or entity 
named above. If you are not the intended recipient, be aware that any 
disclosure, copying, distribution or use of the contents of this information is 
prohibited. If you have received this electronic transmission in error, please 
notify us by e-mail at (postmas...@rapid7.com) immediately.


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Help with Unresolved constraint error

2013-10-03 Thread Richard S. Hall


On 10/3/13 14:55 , Rajan Parthasarathy wrote:

In the tests I was running yesterday, the presence of the port-watcher 
dependency seemed to be making a difference. However, I just reproduced the 
issue without the port-watcher. Huh!

Here's the full stack trace:

ERROR 2013-10-03 14:44:35.979 (org.apache.felix.bundlerepository:?) - Resolver: 
Start error - com.rapid7.razor.collector.engine
org.osgi.framework.BundleException: Unresolved constraint in bundle 
com.rapid7.razor.collector.engine [8]: Unable to resolve 8.1: missing requirement [8.1] 
osgi.wiring.package; 
((osgi.wiring.package=com.rapid7.razor.collector.api)(version=0.2.3)(!(version=1.0.0)))
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at 
org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
at 
com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.deployEngine(BootstrapEngineManager.java:93)
at 
com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.access$200(BootstrapEngineManager.java:25)
at 
com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager$UpdateWorker.run(BootstrapEngineManager.java:215)
at java.lang.Thread.run(Thread.java:722)

In Gogo, I see this when I do an lb:

 8|Installed  |1|Razor Collector Engine (0.2.11)
 9|Active |1|Razor Collector API (0.2.3)

If I do this:
g! refresh 9
g! start 8
g! lb

then it seems to have started properly.

I'm confused because 0.2.3 is listed as active, yet the exception specifies 
it's not able to resolve the requirement for 0.2.3. Also, I do call 
Resolver.resolve() before calling Resolver.deploy(), and the first call 
returned true to indicate that resolution was successful.


If the bundle exports what it imports, then it won't actually start 
providing the new versions of the package until the refresh occurs. That 
might explain what you are seeing.


OBR doesn't handle refreshing very well. Generally, speaking you should 
always do a refreshing after updating one or more bundles...OBR doesn't 
do this.


- richard



Thank you for your help,
Raj

-Original Message-
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: Thursday, October 03, 2013 1:10 PM
To: users@felix.apache.org
Subject: Re: Help with Unresolved constraint error

On 10/3/13 10:24 , Rajan Parthasarathy wrote:

Hello,

I'm running into an Unresolved constraint in bundle error, and hoping to get 
some insight into it. I'm using Felix system bundle 4.0.3.

The application uses an OBR, with a thread that periodically checks for 
updates. Bundles are updated using Resolver. Here's the code which performs the 
updates (with null checks, etc. removed):

  repositoryAdmin.addRepository(new URL(repositoryUrl));
  Resolver resolver = repositoryAdmin.resolver();
  Resource resource = ... get the resource we want to update ...
  resolver.add(resource);
  if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
  resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES | 
Resolver.START);
  }

The application is running in Felix with the following bundles:
collector-api (0.2.2) - exports itself collector-engine (0.2.10) -
imports collector-api = 0.2.2 port-watcher (0.2.2) - imports
collector-api = 0.2.0

I updated the OBR in the following manner:
- replaced collector-api 0.2.2 with collector-api 0.2.3
- replaced engine 0.2.10 with 0.2.11, which imports collector-api =
0.2.3

When I resolve and deploy engine 0.2.11 with the above code, it throws the 
following error:
ERROR 2013-10-02 16:52:58.235 (org.apache.felix.bundlerepository:?) -
Resolver: Start error - com.rapid7.razor.collector.engine
org.osgi.framework.BundleException: Unresolved constraint in bundle
com.rapid7.razor.collector.engine [8]: Unable to resolve 8.29: missing
requirement [8.29] osgi.wiring.package;
((osgi.wiring.package=com.rapid7.razor.collector.api)(version=0.2.3)
(!(version=1.0.0)))

If I replicate the above scenario without the port-watcher bundle installed, 
then it works - the engine gets updated successfully. Any hints as to what is 
happening here?

Not sure. There is code in OBR that tries to update a bundle instead of 
deploying a second version. Perhaps it tries to update collector-api to
0.2.3 but determines that it breaks the port-watcher dependency if it does that 
so it fails. If that is the case, then that would be a bug since it shouldn't 
fail, it should deploy a second version of collector-api.

When you run your example without port-watcher is the existing version of 
collector-api updated to 0.2.3 or are there two versions of the bundle deployed?

- richard


Thank you,
Raj

Re: Help with Unresolved constraint error

2013-10-03 Thread Richard S. Hall



On 10/3/13 18:02 , Rajan Parthasarathy wrote:

So I rewrote the  code to not rely on Resolver.deploy to start the bundles. 
Instead, I'm refreshing the bundles prior to restarting them, and it seems to 
work.

The code looks like this:

   repositoryAdmin.addRepository(new URL(repositoryUrl));
   Resolver resolver = repositoryAdmin.resolver();
   Resource resource = ... get resource to update ...;
   resolver.add(resource);

   if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
 stopBundles(resolver); // stops bundles associated with added or required 
resources
 resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES); // do not automatically 
start bundles
 refreshBundles(resolver); // refreshes bundles associated with required 
resources
 startBundles(resolver); // starts bundles associated with added or 
required resources
   }

The stopBundles() call is needed because ResolverImpl.deploy will start any 
bundles that were in active state prior to being updated. In my scenario, it 
would do this:
- stop collector-api and collector-engine
- deploy collector-engine and collector-api
- refresh collector-api
- start collector-api and collector-engine

I need to run more tests (adding new bundles, etc.) but if you see anything 
wonky with this approach, please let me know.


Yes, I believe that is the correct approach.

- richard



Thanks again for all the help,
Raj


-Original Message-
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: Thursday, October 03, 2013 3:49 PM
To: users@felix.apache.org
Subject: Re: Help with Unresolved constraint error

On 10/3/13 14:55 , Rajan Parthasarathy wrote:

In the tests I was running yesterday, the presence of the port-watcher 
dependency seemed to be making a difference. However, I just reproduced the 
issue without the port-watcher. Huh!

Here's the full stack trace:

ERROR 2013-10-03 14:44:35.979 (org.apache.felix.bundlerepository:?) -
Resolver: Start error - com.rapid7.razor.collector.engine
org.osgi.framework.BundleException: Unresolved constraint in bundle 
com.rapid7.razor.collector.engine [8]: Unable to resolve 8.1: missing requirement [8.1] 
osgi.wiring.package; 
((osgi.wiring.package=com.rapid7.razor.collector.api)(version=0.2.3)(!(version=1.0.0)))
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at 
org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
at 
com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.deployEngine(BootstrapEngineManager.java:93)
at 
com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager.access$200(BootstrapEngineManager.java:25)
at 
com.rapid7.razor.collector.bootstrap.impl.BootstrapEngineManager$UpdateWorker.run(BootstrapEngineManager.java:215)
at java.lang.Thread.run(Thread.java:722)

In Gogo, I see this when I do an lb:

  8|Installed  |1|Razor Collector Engine (0.2.11)
  9|Active |1|Razor Collector API (0.2.3)

If I do this:
g! refresh 9
g! start 8
g! lb

then it seems to have started properly.

I'm confused because 0.2.3 is listed as active, yet the exception specifies 
it's not able to resolve the requirement for 0.2.3. Also, I do call 
Resolver.resolve() before calling Resolver.deploy(), and the first call 
returned true to indicate that resolution was successful.

If the bundle exports what it imports, then it won't actually start providing 
the new versions of the package until the refresh occurs. That might explain 
what you are seeing.

OBR doesn't handle refreshing very well. Generally, speaking you should always 
do a refreshing after updating one or more bundles...OBR doesn't do this.

- richard


Thank you for your help,
Raj

-Original Message-
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: Thursday, October 03, 2013 1:10 PM
To: users@felix.apache.org
Subject: Re: Help with Unresolved constraint error

On 10/3/13 10:24 , Rajan Parthasarathy wrote:

Hello,

I'm running into an Unresolved constraint in bundle error, and hoping to get 
some insight into it. I'm using Felix system bundle 4.0.3.

The application uses an OBR, with a thread that periodically checks for 
updates. Bundles are updated using Resolver. Here's the code which performs the 
updates (with null checks, etc. removed):

   repositoryAdmin.addRepository(new URL(repositoryUrl));
   Resolver resolver = repositoryAdmin.resolver();
   Resource resource = ... get the resource we want to update ...
   resolver.add(resource);
   if (resolver.resolve(Resolver.NO_OPTIONAL_RESOURCES)) {
   resolver.deploy(Resolver.NO_OPTIONAL_RESOURCES | 
Resolver.START

Re: iPOJO and dynamic requires

2013-10-02 Thread Richard S. Hall



On 10/2/13 08:42 , Bengt Rodehav wrote:

I'm creating a dynamic processing component using iPOJO and Camel. The idea
is to dynamically specify (via config admin) a number of processor id's. In
runtime I want to find the matching processors (the processors are Camel
processors published as OSGi services) with the correct id.

E g if I specify a list of services to {A,B} (FileInstall recognizes this
as a list). I want to require those services in order for my iPojo instance
to become valid. It was much harder than I thought.

I've tried something like:

   @Property(name = processors, mandatory = false, value = )
   public void setProcessors(String[] theProcessorIds) {
 mProcessorIds = theProcessorIds;
 updateProcessorFilter();
   }

   @Requires
   private Processor[] mProcessors;

The idea is that whenever the configuration property processors is
updated, I dynamically update the ldap filter on the dependency
mProcessors. I've used this approach before and it has worked when using a
single dependency (not an array).

The problem is that I want to specifically require each specified
processor. In the example above, I require one processor with id=A AND one
processor with id=B. It's not enough with anyone of them since I want to
invoke them one after another.

Can I use a filter for this? I've been thinking of something like this:

(|(processorId=A)(processorId=B))

This would match both my processors but if one of them were missing my
instance would still become valid which I don't want.


I don't think there is anyway to do what you want. This is essentially 
an N cardinality requirement, where you want to say that you require 
specifically N of something. Such requirements had been discussed over 
the years for Service Binder, Declarative Services, etc., but we could 
never agree on their usefulness or how to do them, so we just left it as 
it is now (i.e., optional, at least one...).


Other than adding some sort of threshold to service dependencies, I 
don't see this happening. You could potentially create an iPOJO 
lifecycle controller that would keep your component invalid until it 
matched the required number of services (if you can get this information 
in the handler)...or perhaps write/extend the service dependency handler.


- richard



/Bengt




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Which classloader load Fragment(Fragment-Host: system.bundle; extension:=framework), boot classloader?? or system classloader??

2013-09-25 Thread Richard S. Hall



On 9/25/13 05:25 , gavin.yao wrote:

Hi :
 Which classloader load Fragment(Fragment-Host: system.bundle; 
extension:=framework), boot classloader?? or system classloader??


I believe this would be the class loader that loaded the framework 
classes, which is typically the application class loader.


- richard


And how to trace loading class info?




gavin.yao



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: iPOJO service requirement via callbacks: specification discovery

2013-09-25 Thread Richard S. Hall



On 9/25/13 10:59 , Debeerst Benjamin wrote:

Hello all,

  


First of all I'd like to say how wonderful iPOJO works. Thanks for all
the hard work going into that project (and all the others at Apache
Felix). (Most of the time) there's good warnings or errors on why a
requirement could not be fulfilled, also the messages when
configurations don't work look nice (Altough one single error rather
than 3 is probably enough for non-applicable configurations.)

  


To the actual problem: Although the documentation on requiring services
[1] is pretty extensive and detailed, there is an important note
missing: namely when a service requirement is declared via callback
methods, how is the actual specification is determined? Which contraints
are exsiting for the method names?

  


I was wondering the whole time why no service was bound for an
implementation like this:

  


SetMyServiceInterface myServices;

@Bind(optional=true, aggregate=true)

addMyService(MyServiceInterface newService) {

   myServices.add(newService);

}

  


I thought the specification and binding would be clear through the @Bind
annotation and the method signature. However it turns out that the
method name has to start with 'bind' to get this to work:

  


SetMyServiceInterface myServices;

@Bind(optional=true, aggregate=true)

bindMyService(MyServiceInterface newService) {

   myServices.add(newService);

}

  


Maybe it would be good to mention this requirement in the documentation
[1], and document some details on the specification discovery.  I could
not find a note about that.


Yeah, there is some mention about it in the Mixing injections types 
section, but I agree it should be called out more explicitly in the 
Method invocation section.


- richard



  


I also post this to the list as others might run into the same issue.

  


Moreover I was wondering why the 'specification' argument of the @Bind
annotation is a String and not a Class object? It would be very helpful
to be able to write @Bind(specification=MyService.class). For the
@Provides class annotation this is possible.

(@Bind(specification=MyService.class.getName()) is not possible either,
because it is not regarded as a constant expression by the compiler)

  


Regards,

Benjamin

  


[1]
http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apa
che-felix-ipojo-userguide/describing-components/service-requirement-hand
ler.html

  







-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Weird cast problem when embedding the Jetty web service into Felix

2013-09-24 Thread Richard S. Hall



On 9/24/13 16:06 , Fulvio Risso wrote:
I'm currently embedding Jetty in the felix framework, using the 
examples provided on the felix website:


http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html 



  and

http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html 



Basically, I create my own application that embeds Felix (using the 
code provided by the first example), then I launch the Jetty bundle 
and I try to access to that web server (using the code provided by the 
second example).


The Jetty bundle starts correctly, then I get this very strange error 
at runtime (java.lang.ClassCastException: ...cannot be cast to) when I 
try to use the context to get the HttpService:


===
  BundleContext context= m_fwk.getBundleContext();

  ServiceReference sRef = context.getServiceReference(
HttpService.class.getName());

  if (sRef != null)
  {
  HttpService service = (HttpService) context.getService(sRef);
^

  HttpContext myHttpContext = new MyHttpContext());
  service.registerResources(/static, /etc/www, myHttpContext);
  }


When this line is executed, I get this exception:


java.lang.ClassCastException:
   org.apache.felix.http.base.internal.service.HttpServiceImpl
   cannot be cast to org.osgi.service.http.HttpService
at main.HostApplication.main(HostApplication.java:197)


What I am doing wrong?

fulvio


PS I use javac to compile, and java to execute (no Eclipse, no maven, 
etc).


Libraries (both to compile and to exec):
- org.apache.felix.main-4.2.1
- org.apache.felix.http.jetty-2.2.0

OSGI bundles:
- org.apache.felix.http.jetty-2.2.0
- org.apache.felix.gogo.shell-0.10.0
- org.apache.felix.gogo.runtime-0.10.0
- org.apache.felix.gogo.command-0.12.0


You cannot just put the http.jetty bundle on the outside and on the 
inside. The framework will get its copy of HttpService from the class 
path while the bundle will get it from itself.


You could possibly put the http service package on the outside and have 
the system bundle export it. If the http bundle also imports the http 
service package, then it will likely get it from the system bundle 
rather than itself, then all will be good.


This is described in the examples above, I'm pretty sure. Check out 
section Using Services Provided by Bundles...


- richard



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to improve the start time of Apache Felix

2013-09-23 Thread Richard S. Hall


On 9/23/13 03:19 , Roland wrote:

Roland wrote

[...]It would be nice if the wires also can be cached persistently in some
way.

I'm no Felix-expert and do not know the exact implementation, but I'm
assuming that Felix creats a hash table of wire-objects to resolve
dependencies at runtime. Generating wires takes a lot of time. On the way to
work I had the spontaneous idea that we can implement a lookup table based
on the principals of the memory management. As the base address we could use
the bundle ID and for the offset we could use for instance the ASCII code of
the package name + version or any sum of digits. The advantage would be that
this kind of table can be dumped very simple in the bundle cache. We do not
need to generate Wire-objects at startup, this can be done concurrently
after startup or at the time when they are explicitly requested. I'm just
thinking out loud.

How do you feel about that?


I'm confused as to whether you are talking about resolved wirings or the 
data structure in which capabilities are stored for resolving dependencies.


At one time during my GlassFish days I implemented a quick and dirty 
mechanism to persist wires and I didn't notice any huge performance 
advantage for a normal resolve. Granted, for a complex resolve it would 
make a difference, but in the class of GlassFish with  a couple hundred 
bundles and no inconsistencies, it made little difference.


- richard



Regards,
Roland




--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/How-to-improve-the-start-time-of-Apache-Felix-tp5004833p5005114.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to improve the start time of Apache Felix

2013-09-23 Thread Richard S. Hall


On 9/23/13 09:19 , Roland wrote:

Hello Richard,
I'm sorry that I did not clearly described it what I mean. Of course I meant
the latter. [...] the
data structure in which capabilities are stored for resolving dependencies.



For that case, the capabilities are effectively stored in hash maps, 
yes, but it is more complicated than that since the data structure is 
really part of filter evaluation. As filters are evaluated, some 
attributes (e.g., package name, bundle symbolic name) hit indexes to 
speed up evaluation, so of like normal query evaluation in a database 
(just much, much simpler).




Richard S. Hall wrote

[...], it made little difference. [...]

It's a pity because of the result. But good that you tried it once.


Well, it could be that my approach was too naive. Needless to say, I was 
surprised.


- richard





--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/How-to-improve-the-start-time-of-Apache-Felix-tp5004833p5005117.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Exported package names cannot be zero length. (?)

2013-09-19 Thread Richard S. Hall

Sounds like you need to see what the value of the ...system.packages 
(and ...system.packages.extras) property is when you start in your test 
container.


- richard

On 9/19/13 11:05 , Roland wrote:

Hello Felix experts...
Recently, I got the following error in my *test-container* (pax exam):

ERROR: Error parsing system bundle export statement: ... Exported package
names cannot be zero length.

But running my felix-launcher in the console everything works fine. The
manifest looks correct. So, I do not understand the error message.

Any suggestions?

Thanks in advance!
Roland



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Exported-package-names-cannot-be-zero-length-tp5005077.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Changing Felix log level at runtime

2013-09-16 Thread Richard S. Hall


On 9/16/13 12:50 , Christopher BROWN wrote:

Hi,

I provide my own implementation of the Felix logger (I'm not referring the
OSGi log service here, I'm aware of the difference).  I set it up using the
HashMap I provided to the Felix constructor (I'm using Felix in embedded
mode), using the two following properties:

FelixConstants.LOG_LEVEL_PROP
FelixConstants.LOG_LOGGER_PROP

It all works fine.  However, once constructed, I can't see anyway to change
the log level at runtime.  The use case involves starting in INFO or
WARNING level, and briefly setting it to DEBUG before returning to the
previous (less verbose) setting.

Is this possible?


I see a Logger.setLogLevel() method...

If you've created the logger, then you should have a reference to it.

- richard


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: New to Felix: How to resolve OSGI dependency for maven project

2013-09-14 Thread Richard S. Hall

Did you try installing all of your bundles into the framework and making 
sure they really do resolve? You might get a better error message, if 
there is an actual resolve error, if you try to resolve them in the 
framework.


- richard

On 9/12/13 17:45 , Jamescott wrote:

Hello,

I have a maven project which try to use Felix OSGI container to load OSGI
bundles at runtime. Since the bundles I am going to load depended on other
bundles. I am using local OSGI bundle repository to resolve dependency
issue.

First, in Eclipse, I run bundle:index maven goal to generate a
repository.xml file containing all dependencies by using
maven-bundle-plugin.

Second, my test code using Felix OSGI service API trys to resolve dependency
for one bundle based on repository.xml

FileUtils.deleteDirectory(new File(felix-cache));
FrameworkFactory frameworkFactory =
ServiceLoader.load(FrameworkFactory.class).iterator().next();

framework = frameworkFactory.newFramework(new 
HashMapString, String());
framework.start();

@SuppressWarnings(restriction)
RepositoryAdmin repoAdmin = new
RepositoryAdminImpl(framework.getBundleContext(), null);
URL url = new 
File(S:\\maven.repo\\repository.xml).toURI().toURL();

repoAdmin.addRepository(url);
Resolver resolver = repoAdmin.resolver();
Resource[] resource =
repoAdmin.discoverResources((symbolicname=com.ebay.bullseye.integ.BullseyeDAO));
resolver.add(resource[0]);
if (resolver.resolve())
{
resolver.deploy(16);
}
else
{
Reason[] reasons = 
resolver.getUnsatisfiedRequirements();
for (Reason reason : reasons)
{
System.out.println(Unable to resolve, requirement: 
 +
reason.getRequirement() +  resource:  + reason.getResource());
}
}


But resolver.resolve() return false, and unsatisfiedRequirments are printed
out as following

Unable to resolve, requirement:
package:((package=com.netflix.astyanax.retry)(version=1.1.0)(!(version=2.0.0)))
resource: com.ebay.bullseye.integ.BullseyeDAO/2.0.1.SNAPSHOT
Unable to resolve, requirement:
package:((package=org.cliffc.high_scale_lib)(version=0.3.0)(!(version=1.0.0)))
resource: com.ebay.astyanax.astyanax/1.1.2
Unable to resolve, requirement:
package:((package=org.apache.http.util)(version=4.1.2)) resource:
org.apache.httpcomponents.httpclient/4.1.2
Unable to resolve, requirement: package:((package=sun.tools.javac))
resource: org.apache.ant.ant-launcher/1.7.0
Unable to resolve, requirement: package:((package=javax.ws.rs.core))
resource: com.sun.jersey.jersey-core/1.8.0
Unable to resolve, requirement:
package:((package=com.netflix.astyanax.thrift)(version=1.1.0)(!(version=2.0.0)))
resource: com.ebay.bullseye.integ.BullseyeDAO/2.0.1.SNAPSHOT
Unable to resolve, requirement: package:((package=sun.rmi.rmic)) resource:
org.apache.ant.ant/1.7.0
Unable to resolve, requirement: package:((package=sun.tools.javac))
resource: org.apache.ant.ant/1.7.0
Unable to resolve, requirement:
package:((package=com.sun.jersey.core.util)) resource:
com.sun.jersey.jersey-client/1.8.0
Unable to resolve, requirement:
package:((package=com.netflix.astyanax.connectionpool)(version=1.1.0)(!(version=2.0.0)))
resource: com.ebay.bullseye.integ.BullseyeDAO/2.0.1.SNAPSHOT
Unable to resolve, requirement:
package:((package=com.netflix.astyanax.model)(version=1.1.0)(!(version=2.0.0)))
resource: com.ebay.bullseye.integ.BullseyeDAO/2.0.1.SNAPSHOT
Unable to resolve, requirement:
package:((package=org.apache.http.io)(version=4.1.2)) resource:
org.apache.httpcomponents.httpclient/4.1.2
Unable to resolve, requirement:
package:((package=com.google.common.cache)(version=11.0.0)(!(version=12.0.0)))
resource: com.ebay.astyanax.astyanax-dependencies/0.3.1
Unable to resolve, requirement:
package:((package=com.google.common.collect)(version=11.0.0)(!(version=12.0.0)))
resource: com.ebay.astyanax.astyanax/1.1.2
Unable to resolve, requirement:
package:((package=com.sun.jersey.spi.inject)) resource:
com.sun.jersey.jersey-client/1.8.0
Unable to resolve, requirement:
package:((package=com.sun.jersey.core.provider)) resource:
com.sun.jersey.jersey-client/1.8.0
Unable to resolve, requirement:
package:((package=com.google.common.primitives)(version=11.0.0)(!(version=12.0.0)))
resource: com.ebay.astyanax.astyanax-dependencies/0.3.1
Unable to resolve, requirement: package:((package=javax.ws.rs)) resource:
com.sun.jersey.jersey-core/1.8.0
Unable to resolve, requirement:
package:((package=com.sun.jersey.core.spi.component.ioc)) resource:

Re: After installing Java 8 developer preview, Felix 3.2.2 no longer exports javax.sql

2013-09-13 Thread Richard S. Hall


Sorry, I somehow didn't see your previous message.

Modifying default.properties is certainly okay from my perspective.

I didn't mean to imply that merge happened via conf/config.properties 
because it doesn't. However, you can override ...system.packages in 
there. The only way to merge is using ...system.packages.extras, but 
that is not what you want here since you want to supply the complete 
value since Java 8 doesn't exist.


Since you are not using the default Felix framework launcher, you can't 
use conf/config.properties any way, since it is the one that processes 
that, not the framework itself. However, all it does it put the 
properties into the config map passed into the framework, so you could 
have just done that yourself and not modified default.properties at all.


If the config map has a ...system.packages property, it overrides the 
default value.


- richard

On 9/12/13 17:50 , Christopher BROWN wrote:

I ended up patching the default.properties file in the JAR. Works fine.

Thanks to all!
  Le 12 sept. 2013 18:46, Christopher BROWN br...@reflexe.fr a écrit :


It looks like the list of packages is derived from
http://download.java.net/jdk8/docs/api/package-list so I'd need to have a
config.properties starting with:

jre-1.8=, \

..then each subsequent line starting with a space, package name,
semicolon, space, and a backslash, and terminating with the version line.
  With each subsequent line being derived from package-list, as above. Is
that correct?

As the application actually uses Felix in embedded mode, I don't have the
conf directory.  How should I then merge the default properties with the
Java 8 properties?  I'm guessing that I can't just
clobber Constants.FRAMEWORK_SYSTEMPACKAGES in the HashMap I pass to the
Felix constructor (because default.properties looks like it contains
multiple possible values from which a runtime-dependent property is
selected at some point I haven't yet found, and isn't used as-is for that
framework property).

I would like to avoid rolling my own build of Felix, and would prefer to
have some programmatic way where I can process package-list (and update
that file as JDK8 approaches its final release) -- I can deal with that
part -- and either add it to Felix's default.properties (when
initialising Felix) or just detect JDK8 myself and conditionally override
Felix's default behaviour.  I'm guessing that merging is possible, because
that's what's implied by your suggestion of using conf/config.properties
(which I'm assuming Felix merges with default.properties).  Can I do that
somehow, or can I define my own conf dir (and if I do, will Felix try to
read or write other files there)?

Alternatively, if I were to modify the default.properties file, I guess
I would need to copy the section starting jre-1.7=, \ up to
version=0.0.0.1_007_JavaSE (replacing the 7 with 8) and append it
after a blank line in the same file (or is there anything else to do... I
see that that file contains other non-jre sections).  Is that correct?

Thanks,
Christopher


On 12 September 2013 18:14, Richard S. Hall he...@ungoverned.org wrote:


On 9/12/13 11:56 , Christopher BROWN wrote:


Hello,

An application using Felix 3.2.2 on MacOS X has started failing with the
following exception:

org.osgi.framework.**BundleException: Unresolved constraint in bundle
system.sdk-project [5]: Unable to resolve 5.0: missing requirement [5.0]
package; (package=javax.sql)

The application is started from a shell script that includes the
following
(standard) MacOS X command:

/usr/libexec/java_home -d64 -v 1.6+

It's now locating:
/Library/Java/**JavaVirtualMachines/jdk1.8.0.**jdk/Contents/Home

Would I be correct in guessing that Felix 3.2.2 has no explicit support
for
JDK8 (would make sense), and that it has no fallback mechanism so that it
can at least export packages from prior Java releases?  As in, now that
there's Java 8, it's not exporting stuff it knew about in Java 6...

What can I do about that to fix it, apart from adding a hard-coded
dependency on Java 6 (which is EOL) or upgrading Felix?


The default.properties file inside the felix.jar contains the packages
that should be exported by the framework for a given Java platform. The
issue is that it doesn't have a property for Java 8 so the framework
doesn't export any JRE packages.

You can just copy the Java 7 property and use it for Java 8. You can copy
the value from default.properties, but specify it in conf/config.properties
so you don't need to edit the JAR file.

- richard



Thanks,
Christopher



--**--**-
To unsubscribe, e-mail: 
users-unsubscribe@felix.**apache.orgusers-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: About the status of Felix Repository Subproject

2013-09-12 Thread Richard S. Hall

On 9/12/13 03:09 , Tang Yong wrote:
 Hi Felix,

 Good Afternoon(My local time)!

 About the status of Felix Repository Subproject, I have two questions as
 following and looking forward to obtaining some answsers:

 1. Who are leading the subproject, Richard?

Not really, we don't really have subproject leaders per se, just anyone
who wants to work on it.


 2. The subproject has any plan/roadmap to evolve (eg. Implementing OSGi
 Compendium 5 Repository Service)?

People have expressed interesting in getting something going, but no one
has picked up the ball yet.

- richard


 Thanks
 Tang



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Filtering the default provided system packages

2013-09-12 Thread Richard S. Hall


On 9/12/13 10:59 , Christian Schneider wrote:
That would be really helpful. Using CXF also requires to not export 
some system packages.
Currently we have to completely redefine the system packages. So it 
would be nice to be able to just specify which packages to add 
(already works) and which to remove.


I don't think anyone opened an issue for this against the framework, 
would you do so? Thanks.




Of course it would be ideal to have a common solution with equinox for 
this.


I talked with Tom Watson, we might be able to coordinate such a feature.

- richard



Christian

On 11.09.2013 20:05, Per-Erik Svensson wrote:

Hi Felix,

Yes I understand that you don't have a set of packages defined for 
Java 8
yet. I was more wondering about the possibility of filtering the 
default

packages provides by saying something like

org.osgi.framework.system.packages=defaults, !javax.annotation

This would help me since I'm only stating what I don't want the 
framework

to export, so that my config-file can be used on a future felix/java
installation too. As it is now, I state what I want to include, meaning
that my config can't be used properly in a new felix install (say 
with OSGi

4.4 or Java 8) since.

I assume the answer is no, but asking doesn't hurt. :)

Regards,
Per-Erik Svensson


On Wed, Sep 11, 2013 at 7:57 PM, Felix Meschberger 
fmesc...@adobe.comwrote:



Hi

In Felix these packages are defined on a per-Java version basis in 
version

specific properties. This way we can semi-dynamically define the actual
packages depending on the actual Java version.

Currently we have versions upto and including Java 7 extracted from the
actual Java Platform. The Java 8 version is currently the same as 
for Java

7 to at least support running on Java 8 -- but as the Java 8 API is not
final yet, we cannot define these packages definitely yet.

Hope this helps.

Regards
Felix

Am 11.09.2013 um 19:53 schrieb Per-Erik Svensson:


Hi,

I'm trying to start a minimal set-up to run Jersey (JAX-RS) and 
Jetty in

Apache Felix. When doing this, I get a uses constraint violation on
javax.annotation.

None of this is of course Felix concern, but...

I was wondering if there is a quick way to specify the
org.osgi.framework.system.packages (or any other) property to
*exclude* certain
packages. What I did was that I ran inspect c osgi.wiring.package 
0 and
copy/pasted the result (with some find-replace to format it 
correctly and

removing javax.annotation) to the system.packages property. This works
fine. However, it isn't very future proof. If either felix or java8

comes

with a new set of default packages, I have to change this property.

So, is there any way to remove only some of the default exported

packages -

or is this an all-or-none affair?

Regards,
Per-Erik Svensson








-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: After installing Java 8 developer preview, Felix 3.2.2 no longer exports javax.sql

2013-09-12 Thread Richard S. Hall


On 9/12/13 11:56 , Christopher BROWN wrote:

Hello,

An application using Felix 3.2.2 on MacOS X has started failing with the
following exception:

org.osgi.framework.BundleException: Unresolved constraint in bundle
system.sdk-project [5]: Unable to resolve 5.0: missing requirement [5.0]
package; (package=javax.sql)

The application is started from a shell script that includes the following
(standard) MacOS X command:

/usr/libexec/java_home -d64 -v 1.6+

It's now locating:
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home

Would I be correct in guessing that Felix 3.2.2 has no explicit support for
JDK8 (would make sense), and that it has no fallback mechanism so that it
can at least export packages from prior Java releases?  As in, now that
there's Java 8, it's not exporting stuff it knew about in Java 6...

What can I do about that to fix it, apart from adding a hard-coded
dependency on Java 6 (which is EOL) or upgrading Felix?


The default.properties file inside the felix.jar contains the packages 
that should be exported by the framework for a given Java platform. The 
issue is that it doesn't have a property for Java 8 so the framework 
doesn't export any JRE packages.


You can just copy the Java 7 property and use it for Java 8. You can 
copy the value from default.properties, but specify it in 
conf/config.properties so you don't need to edit the JAR file.


- richard



Thanks,
Christopher




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: getBundle(1) throws NPE

2013-09-10 Thread Richard S. Hall


I guess I don't recall, is this a framework issue or an OBR issue?

If it is a bug in the framework, did you open an issue for it?

- richard

On 9/10/13 11:08 , Roland wrote:

same issue as
http://apache-felix.18485.x6.nabble.com/bundlecontext-getBundles-returns-Array-with-a-null-Object-td5003850.html



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/getBundle-1-throws-NPE-tp5004910p5004911.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: START_TRANSIENT_ERROR is 10 but BundleException typ is set to 0

2013-09-06 Thread Richard S. Hall


On 9/6/13 04:45 , Roland wrote:

Hello Felix-experts,

I got a BundleException Cannot start bundle xyz because its start level is
3, which is greater than the framework's start level of 1. After the
exception was thrown I checked the Exception-type and I got 0 but I expected
START_TRANSIENT_ERROR (10). Am I wrong?


Yes, it should probably be set. This was added to the spec later and 
never updated in the framework. Please open an issue for it. Thanks.


- richard



Thanks  Regards
Roland



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/START-TRANSIENT-ERROR-is-10-but-BundleException-typ-is-set-to-0-tp5004856.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to improve the start time of Apache Felix

2013-09-06 Thread Richard S. Hall


On 9/6/13 05:27 , Roland wrote:

Is it possible to start the framework and the cached bundles concurrently?


I'm not optimistic:

https://issues.apache.org/jira/browse/FELIX-3034

- richard





--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/How-to-improve-the-start-time-of-Apache-Felix-tp5004833p5004859.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to set default logger

2013-09-06 Thread Richard S. Hall


On 9/6/13 08:42 , Roland wrote:

Hello Felix-experts!
The org.apache.felix.utils.log.Logger can only be instanciated without using
the fallbacklogger (stdout,stderr) if a bundle exports the LogService
interface, isn't it? How can I set felix.log.logger at runtime after calling
the felix-constructor?

http://felix.apache.org/site/apache-felix-framework-configuration-properties.html
felix.log.logger - An instance of Logger that the framework uses as its
default logger. (This property cannot be set in the configuration file since
it requires an instance; it can only be passed into Felix' constructor
directly.)


The Felix logger is not intended to come from bundle. We originally 
allowed this and it caused all sorts of concurrency issues since logging 
happens during critical operations.


- richard


Thanks and Regards
Roland



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/How-to-set-default-logger-tp5004867.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to set default logger

2013-09-06 Thread Richard S. Hall


On 9/6/13 08:59 , Roland wrote:

Does it mean that I should export the LogService-interface with
FRAMEWORK_SYSTEMPACKAGES_EXTRA? Otherwise it makes no sense to me.


Not sure what you mean, the framework doesn't use a logging service, it 
uses an instance of org.apache.felix.framework.Logger.


- richard



Thanks!!



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/How-to-set-default-logger-tp5004867p5004873.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1532 matches

Mail list logo