You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Benson Margulies <be...@basistech.com> on 2016/08/11 20:36:13 UTC
Solved felix SCR Logging, but replaced that with a problem with
optional dependency resolution in the framework
Quite some time ago, we had a requirement to have read-only
provisioned OSGi caches. So I had set up our standard configuration to
use Equinox rather than Felix.
Equinox sets up a LogService of its own, which in turn requires a
'LogReader' to get the log messages to show up anywhere. Adding
another LogService doesn't work. I have yet to figure out how to
politely instruct Equinox to stay out of the way in this respect.
As it turns out, the read-only requirement is gone. So I decided that
since I am in the occasional habit of asking for help on the Felix
list, it would be good if I was, well, using more of Felix.
So I switched to the Felix framework (5.4.0). Sure enough, there are
my log messages.
But some optional packages are now a problem that worked fine in Equinox.
I suspect that this will be impossible for anyone to comment on unless
I can build a minimized test case.
I get a class not found for a class in a package that I have
intentionally left out of this deployment. Leaving it out is
facilitated by the use of resolution:=optional. In Equinox, this works
fine. In Felix, somehow, something decides that it needs to wire up
this and fails.
If by some really unlikely accident this has the earmarks of a
well-known phenomenon, I'm sure someone will let me know. Otherwise,
I'll either bail back to Equinox or do the more complex refactoring
that I'm deferring and be able to remove the optional resolution.
Caused by: java.lang.ClassNotFoundException:
org.apache.cxf.common.i18n.Exception not found by
com.basistech.ws.rosapi-common [21]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Solved felix SCR Logging, but replaced that with a problem with
optional dependency resolution in the framework
Posted by Benson Margulies <be...@basistech.com>.
I have now explained it. The exception is noisy and harmless. In
Equinox, it's logged to the Equinox log service, which was, until
moments ago, invisible to me.
However, it's still true that my test fails in Felix. I am not going
to bother this list or myself with that phenomenon until I have some
other things, including that exception, sorted.
On Thu, Aug 11, 2016 at 6:31 PM, Benson Margulies <be...@basistech.com> wrote:
> On Thu, Aug 11, 2016 at 5:07 PM, David Jencks
> <da...@yahoo.com.invalid> wrote:
>> I don’t understand your explanation. What is causing the class load? So far it looks like resolution:=optional worked fine, but your code doesn’t implement what it needs to make it actually optional. Maybe the details you left out explain better :-)
>
> The 'details I left out' are much too voluminous until and unless I
> boil this down to a test case. In brief, I agree, it makes no sense. I
> run the program in equinox, it works. I run it in felix, it fails.
> Maybe my code is wrong and equinox excuses it for some reason. Maybe
> something else. I apologize for using bandwidth on such a muddle.
>
>
>>
>> If you go back to equinox, you might try registering your log service with service ranking > 0; that might make it preferred vs the built in equinox one.
>
> Unfortunately, I'd have to fork:
>
> https://github.com/qos-ch/slf4j/blob/master/osgi-over-slf4j/src/main/java/org/slf4j/osgi/logservice/impl/Activator.java
>
> But I just figured out how to get the equinox log where I can see it, maybe.
>
>>
>> david jencks
>>
>>> On Aug 11, 2016, at 1:36 PM, Benson Margulies <be...@basistech.com> wrote:
>>>
>>> Quite some time ago, we had a requirement to have read-only
>>> provisioned OSGi caches. So I had set up our standard configuration to
>>> use Equinox rather than Felix.
>>>
>>> Equinox sets up a LogService of its own, which in turn requires a
>>> 'LogReader' to get the log messages to show up anywhere. Adding
>>> another LogService doesn't work. I have yet to figure out how to
>>> politely instruct Equinox to stay out of the way in this respect.
>>>
>>> As it turns out, the read-only requirement is gone. So I decided that
>>> since I am in the occasional habit of asking for help on the Felix
>>> list, it would be good if I was, well, using more of Felix.
>>>
>>> So I switched to the Felix framework (5.4.0). Sure enough, there are
>>> my log messages.
>>>
>>> But some optional packages are now a problem that worked fine in Equinox.
>>>
>>> I suspect that this will be impossible for anyone to comment on unless
>>> I can build a minimized test case.
>>>
>>> I get a class not found for a class in a package that I have
>>> intentionally left out of this deployment. Leaving it out is
>>> facilitated by the use of resolution:=optional. In Equinox, this works
>>> fine. In Felix, somehow, something decides that it needs to wire up
>>> this and fails.
>>>
>>> If by some really unlikely accident this has the earmarks of a
>>> well-known phenomenon, I'm sure someone will let me know. Otherwise,
>>> I'll either bail back to Equinox or do the more complex refactoring
>>> that I'm deferring and be able to remove the optional resolution.
>>>
>>>
>>>
>>> Caused by: java.lang.ClassNotFoundException:
>>> org.apache.cxf.common.i18n.Exception not found by
>>> com.basistech.ws.rosapi-common [21]
>>> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
>>> at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>>> at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Solved felix SCR Logging,
but replaced that with a problem with optional dependency resolution in the
framework
Posted by Erwin Hogeweg <er...@me.com>.
Benson,
>
> But I just figured out how to get the equinox log where I can see it, maybe.
Talk to us ;-). I have been following this thread with great interest because I have the exact same problem. A bunch of services bind to the Equinox log service but the output is nowhere to be found.
Would you mind sharing what you found and make this a better place? ;-)
Cheers,
Erwin.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Solved felix SCR Logging, but replaced that with a problem with
optional dependency resolution in the framework
Posted by Benson Margulies <be...@basistech.com>.
On Thu, Aug 11, 2016 at 5:07 PM, David Jencks
<da...@yahoo.com.invalid> wrote:
> I don’t understand your explanation. What is causing the class load? So far it looks like resolution:=optional worked fine, but your code doesn’t implement what it needs to make it actually optional. Maybe the details you left out explain better :-)
The 'details I left out' are much too voluminous until and unless I
boil this down to a test case. In brief, I agree, it makes no sense. I
run the program in equinox, it works. I run it in felix, it fails.
Maybe my code is wrong and equinox excuses it for some reason. Maybe
something else. I apologize for using bandwidth on such a muddle.
>
> If you go back to equinox, you might try registering your log service with service ranking > 0; that might make it preferred vs the built in equinox one.
Unfortunately, I'd have to fork:
https://github.com/qos-ch/slf4j/blob/master/osgi-over-slf4j/src/main/java/org/slf4j/osgi/logservice/impl/Activator.java
But I just figured out how to get the equinox log where I can see it, maybe.
>
> david jencks
>
>> On Aug 11, 2016, at 1:36 PM, Benson Margulies <be...@basistech.com> wrote:
>>
>> Quite some time ago, we had a requirement to have read-only
>> provisioned OSGi caches. So I had set up our standard configuration to
>> use Equinox rather than Felix.
>>
>> Equinox sets up a LogService of its own, which in turn requires a
>> 'LogReader' to get the log messages to show up anywhere. Adding
>> another LogService doesn't work. I have yet to figure out how to
>> politely instruct Equinox to stay out of the way in this respect.
>>
>> As it turns out, the read-only requirement is gone. So I decided that
>> since I am in the occasional habit of asking for help on the Felix
>> list, it would be good if I was, well, using more of Felix.
>>
>> So I switched to the Felix framework (5.4.0). Sure enough, there are
>> my log messages.
>>
>> But some optional packages are now a problem that worked fine in Equinox.
>>
>> I suspect that this will be impossible for anyone to comment on unless
>> I can build a minimized test case.
>>
>> I get a class not found for a class in a package that I have
>> intentionally left out of this deployment. Leaving it out is
>> facilitated by the use of resolution:=optional. In Equinox, this works
>> fine. In Felix, somehow, something decides that it needs to wire up
>> this and fails.
>>
>> If by some really unlikely accident this has the earmarks of a
>> well-known phenomenon, I'm sure someone will let me know. Otherwise,
>> I'll either bail back to Equinox or do the more complex refactoring
>> that I'm deferring and be able to remove the optional resolution.
>>
>>
>>
>> Caused by: java.lang.ClassNotFoundException:
>> org.apache.cxf.common.i18n.Exception not found by
>> com.basistech.ws.rosapi-common [21]
>> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
>> at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>> at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Solved felix SCR Logging, but replaced that with a problem with optional dependency resolution in the framework
Posted by David Jencks <da...@yahoo.com.INVALID>.
I don’t understand your explanation. What is causing the class load? So far it looks like resolution:=optional worked fine, but your code doesn’t implement what it needs to make it actually optional. Maybe the details you left out explain better :-)
If you go back to equinox, you might try registering your log service with service ranking > 0; that might make it preferred vs the built in equinox one.
david jencks
> On Aug 11, 2016, at 1:36 PM, Benson Margulies <be...@basistech.com> wrote:
>
> Quite some time ago, we had a requirement to have read-only
> provisioned OSGi caches. So I had set up our standard configuration to
> use Equinox rather than Felix.
>
> Equinox sets up a LogService of its own, which in turn requires a
> 'LogReader' to get the log messages to show up anywhere. Adding
> another LogService doesn't work. I have yet to figure out how to
> politely instruct Equinox to stay out of the way in this respect.
>
> As it turns out, the read-only requirement is gone. So I decided that
> since I am in the occasional habit of asking for help on the Felix
> list, it would be good if I was, well, using more of Felix.
>
> So I switched to the Felix framework (5.4.0). Sure enough, there are
> my log messages.
>
> But some optional packages are now a problem that worked fine in Equinox.
>
> I suspect that this will be impossible for anyone to comment on unless
> I can build a minimized test case.
>
> I get a class not found for a class in a package that I have
> intentionally left out of this deployment. Leaving it out is
> facilitated by the use of resolution:=optional. In Equinox, this works
> fine. In Felix, somehow, something decides that it needs to wire up
> this and fails.
>
> If by some really unlikely accident this has the earmarks of a
> well-known phenomenon, I'm sure someone will let me know. Otherwise,
> I'll either bail back to Equinox or do the more complex refactoring
> that I'm deferring and be able to remove the optional resolution.
>
>
>
> Caused by: java.lang.ClassNotFoundException:
> org.apache.cxf.common.i18n.Exception not found by
> com.basistech.ws.rosapi-common [21]
> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
> at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org