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 <[email protected]> wrote:
> On Thu, Aug 11, 2016 at 5:07 PM, David Jencks
> <[email protected]> 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 <[email protected]> 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: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to