You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Zhemzhitsky Sergey <Se...@troika.ru> on 2011/11/10 09:31:24 UTC
Felix EventAdmin configuration in Karaf
Hi there,
I'd like to use felix EventAdmin as centralized event handler/dispatcher in my application in Karaf.
I know that EventAdmin can blacklist slow event handlers. However I would not like event handlers to be blacklisted at all.
So could you please answer to the following questions:
1. How to configure Felix EventAdmin in Karaf by means of cfg files in Karaf? Is availability of org.apache.felix.eventadmin.impl.EventAdmin.cfg enough in the $KARAF_HOME/etc directory?
2. How to set org.apache.felix.eventadmin.IgnoreTimeout property of event admin properly?
Is the following configuration right: org.apache.felix.eventadmin.IgnoreTimeout= org.osgi.framework., org.foo.*, org.bar.Clazz?
Does the configuration above mean that all the event handlers will not have timeout for the events in the org.osgi.framework package such as org/osgi/framework/BundleEvent/INSTALLED, org/osgi/framework/BundleEvent/STARTED, etc., as well as for all the events in the org.foo package like org/foo/Event, org/foo/bar/Event, as well as for all the events like org/bar/Clazz/Event?
Best Regards,
Sergey
_______________________________________________________
The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp
AW: AW: Pax Web and Felix 4.0.1
Posted by Markus Dippold <Ma...@infoteam.de>.
Hi Achim,
thank you.
Best regards,
Markus
-----Ursprüngliche Nachricht-----
Von: Achim Nierbeck [mailto:bcanhome@googlemail.com]
Gesendet: Mittwoch, 16. November 2011 10:58
An: users@felix.apache.org
Betreff: Re: AW: Pax Web and Felix 4.0.1
Hi
I just fixed a bug at Pax Web last night, that might have caused
this behavior.
See http://team.ops4j.org/browse/PAXWEB-321
right now it's only fixed in the 2.0.0-SNAPSHOT line but I'll merge this
into the
1.1.2-SNAPSHOT line asap.
Regards, Achim
2011/11/12 Richard S. Hall <he...@ungoverned.org>
> On 11/11/11 4:48, Markus Dippold wrote:
>
>> Hi Richard,
>>
>> it says it is stopped. If we stop the bundle 19 with more logging
>> enabled, we get this output:
>>
>
> The important point is, is the exception thrown after bundle 19 is stopped
> (meaning that it has threads running after its bundle activator was
> stopped) or is the exception thrown while bundle 19 is stopping (meaning it
> should not get an exception).
>
> There were changes here because the older framework let somethings happen
> that it shouldn't. So it could be impacting you here, but it also could be
> a bug.
>
> -> richard
>
>
>
>> ...
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**service.internal.Activator]
>> : Pax Web stopped
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceProxy] : Unregistering
>> [/system/console/res]
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceProxy] : Unregistering [/system/console]
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceFactoryImpl] : Unbinding bundle:
>> [org.apache.felix.webconsole [15]]
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceProxy] : Stopping http service:
>> [org.ops4j.pax.web.service.**internal.HttpServiceProxy@**13b9a2fd]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceStopped] : Changing HttpService state
>> to org.ops4j.pax.web.service.**internal.HttpServiceStopped@**8059dbd
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceFactoryImpl] : Unbinding bundle:
>> [de.infoteam.infoteamservlet [6]]
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceProxy] : Stopping http service:
>> [org.ops4j.pax.web.service.**internal.HttpServiceProxy@**5f47ff11]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceStopped] : Changing HttpService state
>> to org.ops4j.pax.web.service.**internal.HttpServiceStopped@**6fbae5f5
>> ERROR: Bundle org.ops4j.pax.web.pax-web-**jetty-bundle [19]
>> EventDispatcher: Error during dispatch. (java.lang.**IllegalStateException:
>> Invalid BundleContext.)
>> ...
>> g!
>>
>> If we stop the bundle in felix 3.2.2, we get the same output, but without
>> exception:
>> ...
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**Activator] : Pax Web stopped
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceProxy] : Unregistering
>> [/system/console/res]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceProxy] : Unregistering
>> [/system/console]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceFactoryImpl] : Unbinding bundle:
>> [org.apache.felix.webconsole [15]]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceProxy] : Stopping http service:
>> [org.ops4j.pax.web.service.**internal.HttpServiceProxy@**2d61100c]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceStopped] : Changing HttpService state
>> to org.ops4j.pax.web.service.**internal.HttpServiceStopped@**23f95cce
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceFactoryImpl] : Unbinding bundle:
>> [de.infoteam.infoteamservlet [6]]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceProxy] : Stopping http service:
>> [org.ops4j.pax.web.service.**internal.HttpServiceProxy@**1646fef3]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceStopped] : Changing HttpService state
>> to org.ops4j.pax.web.service.**internal.HttpServiceStopped@**f0c0ef2
>> g!
>>
>>
>> In both felix version, the bundle state is "Resolved", after stopping the
>> bundle.
>>
>> Best regards,
>> Markus
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Gesendet: Freitag, 11. November 2011 10:20
>> An: users@felix.apache.org
>> Betreff: Re: Pax Web and Felix 4.0.1
>>
>> The first question I have is, is bundle 19 actually stopped when this
>> exception occurs? That would only happen if it wasn't cleaning up after
>> itself when its activator was stopped, which would then be a bug in it
>> that should be fixed.
>>
>> On the other hand, if it hasn't been stopped yet, then something else
>> must be going on.
>>
>> -> richard
>>
>> On 11/11/11 3:07, Markus Dippold wrote:
>>
>>> Hi,
>>>
>>> we tried to upgrade Felix from 3.2.2 to 4.0.1 and we are using Pax Web
>>> 1.0.7.
>>> It works as expected, but every time we shut down the framework, Pax Web
>>> throws an exception:
>>>
>>> 2011-11-11 08:41:00.839:INFO::stopped
>>> HttpServiceContext{**httpContext=org.apache.felix.**
>>> webconsole.internal.serv
>>> let.OsgiManagerHttpContext@**2242f64e}
>>> java.lang.**IllegalStateException: Invalid BundleContext.
>>> ERROR: Bundle org.ops4j.pax.web.pax-web-**jetty-bundle [19]
>>> EventDispatcher: Error during dispatch.
>>> (java.lang.**IllegalStateException: Invalid BundleContext.)
>>> at
>>> org.apache.felix.framework.**BundleContextImpl.**
>>> checkValidity(BundleContext
>>> Impl.java:514)
>>> at
>>> org.apache.felix.framework.**BundleContextImpl.**
>>> ungetService(BundleContextI
>>> mpl.java:473)
>>> at
>>> org.ops4j.pax.web.service.**internal.Activator$**
>>> DynamicsServiceTrackerCusto
>>> mizer.removedService(**Activator.java:364)
>>> at
>>> org.osgi.util.tracker.**ServiceTracker$Tracked.**
>>> customizerRemoved(ServiceTr
>>> acker.java:1006)
>>> at
>>> org.osgi.util.tracker.**ServiceTracker$Tracked.**
>>> customizerRemoved(ServiceTr
>>> acker.java:906)
>>> at
>>> org.osgi.util.tracker.**AbstractTracked.untrack(**
>>> AbstractTracked.java:352)
>>> at
>>> org.osgi.util.tracker.**ServiceTracker$Tracked.**
>>> serviceChanged(ServiceTrack
>>> er.java:949)
>>> at
>>> org.apache.felix.framework.**util.EventDispatcher.**
>>> invokeServiceListenerCal
>>> lback(EventDispatcher.java:**932)
>>> at
>>> org.apache.felix.framework.**util.EventDispatcher.**
>>> fireEventImmediately(Eve
>>> ntDispatcher.java:793)
>>> at
>>> org.apache.felix.framework.**util.EventDispatcher.**
>>> fireServiceEvent(EventDi
>>> spatcher.java:543)
>>> at
>>> org.apache.felix.framework.**Felix.fireServiceEvent(Felix.**java:4252)
>>> at org.apache.felix.framework.**Felix.access$000(Felix.java:**74)
>>> at org.apache.felix.framework.**Felix$1.serviceChanged(Felix.**
>>> java:390)
>>> at
>>> org.apache.felix.framework.**ServiceRegistry.**
>>> unregisterService(ServiceRegi
>>> stry.java:148)
>>> at
>>> org.apache.felix.framework.**ServiceRegistrationImpl.**
>>> unregister(ServiceReg
>>> istrationImpl.java:127)
>>> at
>>> org.apache.felix.framework.**ServiceRegistry.**
>>> unregisterServices(ServiceReg
>>> istry.java:191)
>>> at org.apache.felix.framework.**Felix.stopBundle(Felix.java:**2386)
>>> at
>>> org.apache.felix.framework.**Felix.setActiveStartLevel(**
>>> Felix.java:1214)
>>> at
>>> org.apache.felix.framework.**FrameworkStartLevelImpl.run(**
>>> FrameworkStartLev
>>> elImpl.java:295)
>>> at java.lang.Thread.run(Unknown Source)
>>>
>>> The exception has no negative effects, but it just does not look good.
>>>
>>> Can anybody help us to avoid this exception?
>>>
>>> Best regards,
>>> Markus
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AW: Pax Web and Felix 4.0.1
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi
I just fixed a bug at Pax Web last night, that might have caused
this behavior.
See http://team.ops4j.org/browse/PAXWEB-321
right now it's only fixed in the 2.0.0-SNAPSHOT line but I'll merge this
into the
1.1.2-SNAPSHOT line asap.
Regards, Achim
2011/11/12 Richard S. Hall <he...@ungoverned.org>
> On 11/11/11 4:48, Markus Dippold wrote:
>
>> Hi Richard,
>>
>> it says it is stopped. If we stop the bundle 19 with more logging
>> enabled, we get this output:
>>
>
> The important point is, is the exception thrown after bundle 19 is stopped
> (meaning that it has threads running after its bundle activator was
> stopped) or is the exception thrown while bundle 19 is stopping (meaning it
> should not get an exception).
>
> There were changes here because the older framework let somethings happen
> that it shouldn't. So it could be impacting you here, but it also could be
> a bug.
>
> -> richard
>
>
>
>> ...
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**service.internal.Activator]
>> : Pax Web stopped
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceProxy] : Unregistering
>> [/system/console/res]
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceProxy] : Unregistering [/system/console]
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceFactoryImpl] : Unbinding bundle:
>> [org.apache.felix.webconsole [15]]
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceProxy] : Stopping http service:
>> [org.ops4j.pax.web.service.**internal.HttpServiceProxy@**13b9a2fd]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceStopped] : Changing HttpService state
>> to org.ops4j.pax.web.service.**internal.HttpServiceStopped@**8059dbd
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceFactoryImpl] : Unbinding bundle:
>> [de.infoteam.infoteamservlet [6]]
>> org.ops4j.pax.logging.pax-**logging-api[org.ops4j.pax.web.**
>> service.internal.**HttpServiceProxy] : Stopping http service:
>> [org.ops4j.pax.web.service.**internal.HttpServiceProxy@**5f47ff11]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceStopped] : Changing HttpService state
>> to org.ops4j.pax.web.service.**internal.HttpServiceStopped@**6fbae5f5
>> ERROR: Bundle org.ops4j.pax.web.pax-web-**jetty-bundle [19]
>> EventDispatcher: Error during dispatch. (java.lang.**IllegalStateException:
>> Invalid BundleContext.)
>> ...
>> g!
>>
>> If we stop the bundle in felix 3.2.2, we get the same output, but without
>> exception:
>> ...
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**Activator] : Pax Web stopped
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceProxy] : Unregistering
>> [/system/console/res]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceProxy] : Unregistering
>> [/system/console]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceFactoryImpl] : Unbinding bundle:
>> [org.apache.felix.webconsole [15]]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceProxy] : Stopping http service:
>> [org.ops4j.pax.web.service.**internal.HttpServiceProxy@**2d61100c]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceStopped] : Changing HttpService state
>> to org.ops4j.pax.web.service.**internal.HttpServiceStopped@**23f95cce
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceFactoryImpl] : Unbinding bundle:
>> [de.infoteam.infoteamservlet [6]]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceProxy] : Stopping http service:
>> [org.ops4j.pax.web.service.**internal.HttpServiceProxy@**1646fef3]
>> org.ops4j.pax.web.pax-web-**jetty-bundle[org.ops4j.pax.**
>> web.service.internal.**HttpServiceStopped] : Changing HttpService state
>> to org.ops4j.pax.web.service.**internal.HttpServiceStopped@**f0c0ef2
>> g!
>>
>>
>> In both felix version, the bundle state is "Resolved", after stopping the
>> bundle.
>>
>> Best regards,
>> Markus
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Gesendet: Freitag, 11. November 2011 10:20
>> An: users@felix.apache.org
>> Betreff: Re: Pax Web and Felix 4.0.1
>>
>> The first question I have is, is bundle 19 actually stopped when this
>> exception occurs? That would only happen if it wasn't cleaning up after
>> itself when its activator was stopped, which would then be a bug in it
>> that should be fixed.
>>
>> On the other hand, if it hasn't been stopped yet, then something else
>> must be going on.
>>
>> -> richard
>>
>> On 11/11/11 3:07, Markus Dippold wrote:
>>
>>> Hi,
>>>
>>> we tried to upgrade Felix from 3.2.2 to 4.0.1 and we are using Pax Web
>>> 1.0.7.
>>> It works as expected, but every time we shut down the framework, Pax Web
>>> throws an exception:
>>>
>>> 2011-11-11 08:41:00.839:INFO::stopped
>>> HttpServiceContext{**httpContext=org.apache.felix.**
>>> webconsole.internal.serv
>>> let.OsgiManagerHttpContext@**2242f64e}
>>> java.lang.**IllegalStateException: Invalid BundleContext.
>>> ERROR: Bundle org.ops4j.pax.web.pax-web-**jetty-bundle [19]
>>> EventDispatcher: Error during dispatch.
>>> (java.lang.**IllegalStateException: Invalid BundleContext.)
>>> at
>>> org.apache.felix.framework.**BundleContextImpl.**
>>> checkValidity(BundleContext
>>> Impl.java:514)
>>> at
>>> org.apache.felix.framework.**BundleContextImpl.**
>>> ungetService(BundleContextI
>>> mpl.java:473)
>>> at
>>> org.ops4j.pax.web.service.**internal.Activator$**
>>> DynamicsServiceTrackerCusto
>>> mizer.removedService(**Activator.java:364)
>>> at
>>> org.osgi.util.tracker.**ServiceTracker$Tracked.**
>>> customizerRemoved(ServiceTr
>>> acker.java:1006)
>>> at
>>> org.osgi.util.tracker.**ServiceTracker$Tracked.**
>>> customizerRemoved(ServiceTr
>>> acker.java:906)
>>> at
>>> org.osgi.util.tracker.**AbstractTracked.untrack(**
>>> AbstractTracked.java:352)
>>> at
>>> org.osgi.util.tracker.**ServiceTracker$Tracked.**
>>> serviceChanged(ServiceTrack
>>> er.java:949)
>>> at
>>> org.apache.felix.framework.**util.EventDispatcher.**
>>> invokeServiceListenerCal
>>> lback(EventDispatcher.java:**932)
>>> at
>>> org.apache.felix.framework.**util.EventDispatcher.**
>>> fireEventImmediately(Eve
>>> ntDispatcher.java:793)
>>> at
>>> org.apache.felix.framework.**util.EventDispatcher.**
>>> fireServiceEvent(EventDi
>>> spatcher.java:543)
>>> at
>>> org.apache.felix.framework.**Felix.fireServiceEvent(Felix.**java:4252)
>>> at org.apache.felix.framework.**Felix.access$000(Felix.java:**74)
>>> at org.apache.felix.framework.**Felix$1.serviceChanged(Felix.**
>>> java:390)
>>> at
>>> org.apache.felix.framework.**ServiceRegistry.**
>>> unregisterService(ServiceRegi
>>> stry.java:148)
>>> at
>>> org.apache.felix.framework.**ServiceRegistrationImpl.**
>>> unregister(ServiceReg
>>> istrationImpl.java:127)
>>> at
>>> org.apache.felix.framework.**ServiceRegistry.**
>>> unregisterServices(ServiceReg
>>> istry.java:191)
>>> at org.apache.felix.framework.**Felix.stopBundle(Felix.java:**2386)
>>> at
>>> org.apache.felix.framework.**Felix.setActiveStartLevel(**
>>> Felix.java:1214)
>>> at
>>> org.apache.felix.framework.**FrameworkStartLevelImpl.run(**
>>> FrameworkStartLev
>>> elImpl.java:295)
>>> at java.lang.Thread.run(Unknown Source)
>>>
>>> The exception has no negative effects, but it just does not look good.
>>>
>>> Can anybody help us to avoid this exception?
>>>
>>> Best regards,
>>> Markus
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
*Achim Nierbeck*
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Re: AW: Pax Web and Felix 4.0.1
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 11/11/11 4:48, Markus Dippold wrote:
> Hi Richard,
>
> it says it is stopped. If we stop the bundle 19 with more logging enabled, we get this output:
The important point is, is the exception thrown after bundle 19 is
stopped (meaning that it has threads running after its bundle activator
was stopped) or is the exception thrown while bundle 19 is stopping
(meaning it should not get an exception).
There were changes here because the older framework let somethings
happen that it shouldn't. So it could be impacting you here, but it also
could be a bug.
-> richard
>
> ...
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.Activator] : Pax Web stopped
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Unregistering [/system/console/res]
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Unregistering [/system/console]
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceFactoryImpl] : Unbinding bundle: [org.apache.felix.webconsole [15]]
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Stopping http service: [org.ops4j.pax.web.service.internal.HttpServiceProxy@13b9a2fd]
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceStopped] : Changing HttpService state to org.ops4j.pax.web.service.internal.HttpServiceStopped@8059dbd
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceFactoryImpl] : Unbinding bundle: [de.infoteam.infoteamservlet [6]]
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Stopping http service: [org.ops4j.pax.web.service.internal.HttpServiceProxy@5f47ff11]
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceStopped] : Changing HttpService state to org.ops4j.pax.web.service.internal.HttpServiceStopped@6fbae5f5
> ERROR: Bundle org.ops4j.pax.web.pax-web-jetty-bundle [19] EventDispatcher: Error during dispatch. (java.lang.IllegalStateException: Invalid BundleContext.)
> ...
> g!
>
> If we stop the bundle in felix 3.2.2, we get the same output, but without exception:
> ...
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.Activator] : Pax Web stopped
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Unregistering [/system/console/res]
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Unregistering [/system/console]
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceFactoryImpl] : Unbinding bundle: [org.apache.felix.webconsole [15]]
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Stopping http service: [org.ops4j.pax.web.service.internal.HttpServiceProxy@2d61100c]
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceStopped] : Changing HttpService state to org.ops4j.pax.web.service.internal.HttpServiceStopped@23f95cce
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceFactoryImpl] : Unbinding bundle: [de.infoteam.infoteamservlet [6]]
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Stopping http service: [org.ops4j.pax.web.service.internal.HttpServiceProxy@1646fef3]
> org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceStopped] : Changing HttpService state to org.ops4j.pax.web.service.internal.HttpServiceStopped@f0c0ef2
> g!
>
>
> In both felix version, the bundle state is "Resolved", after stopping the bundle.
>
> Best regards,
> Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Richard S. Hall [mailto:heavy@ungoverned.org]
> Gesendet: Freitag, 11. November 2011 10:20
> An: users@felix.apache.org
> Betreff: Re: Pax Web and Felix 4.0.1
>
> The first question I have is, is bundle 19 actually stopped when this
> exception occurs? That would only happen if it wasn't cleaning up after
> itself when its activator was stopped, which would then be a bug in it
> that should be fixed.
>
> On the other hand, if it hasn't been stopped yet, then something else
> must be going on.
>
> -> richard
>
> On 11/11/11 3:07, Markus Dippold wrote:
>> Hi,
>>
>> we tried to upgrade Felix from 3.2.2 to 4.0.1 and we are using Pax Web
>> 1.0.7.
>> It works as expected, but every time we shut down the framework, Pax Web
>> throws an exception:
>>
>> 2011-11-11 08:41:00.839:INFO::stopped
>> HttpServiceContext{httpContext=org.apache.felix.webconsole.internal.serv
>> let.OsgiManagerHttpContext@2242f64e}
>> java.lang.IllegalStateException: Invalid BundleContext.
>> ERROR: Bundle org.ops4j.pax.web.pax-web-jetty-bundle [19]
>> EventDispatcher: Error during dispatch.
>> (java.lang.IllegalStateException: Invalid BundleContext.)
>> at
>> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContext
>> Impl.java:514)
>> at
>> org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextI
>> mpl.java:473)
>> at
>> org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCusto
>> mizer.removedService(Activator.java:364)
>> at
>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTr
>> acker.java:1006)
>> at
>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTr
>> acker.java:906)
>> at
>> org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
>> at
>> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTrack
>> er.java:949)
>> at
>> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCal
>> lback(EventDispatcher.java:932)
>> at
>> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Eve
>> ntDispatcher.java:793)
>> at
>> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDi
>> spatcher.java:543)
>> at
>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4252)
>> at org.apache.felix.framework.Felix.access$000(Felix.java:74)
>> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
>> at
>> org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegi
>> stry.java:148)
>> at
>> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceReg
>> istrationImpl.java:127)
>> at
>> org.apache.felix.framework.ServiceRegistry.unregisterServices(ServiceReg
>> istry.java:191)
>> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2386)
>> at
>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1214)
>> at
>> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLev
>> elImpl.java:295)
>> at java.lang.Thread.run(Unknown Source)
>>
>> The exception has no negative effects, but it just does not look good.
>>
>> Can anybody help us to avoid this exception?
>>
>> Best regards,
>> Markus
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
AW: Pax Web and Felix 4.0.1
Posted by Markus Dippold <Ma...@infoteam.de>.
Hi Richard,
it says it is stopped. If we stop the bundle 19 with more logging enabled, we get this output:
...
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.Activator] : Pax Web stopped
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Unregistering [/system/console/res]
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Unregistering [/system/console]
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceFactoryImpl] : Unbinding bundle: [org.apache.felix.webconsole [15]]
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Stopping http service: [org.ops4j.pax.web.service.internal.HttpServiceProxy@13b9a2fd]
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceStopped] : Changing HttpService state to org.ops4j.pax.web.service.internal.HttpServiceStopped@8059dbd
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceFactoryImpl] : Unbinding bundle: [de.infoteam.infoteamservlet [6]]
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Stopping http service: [org.ops4j.pax.web.service.internal.HttpServiceProxy@5f47ff11]
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceStopped] : Changing HttpService state to org.ops4j.pax.web.service.internal.HttpServiceStopped@6fbae5f5
ERROR: Bundle org.ops4j.pax.web.pax-web-jetty-bundle [19] EventDispatcher: Error during dispatch. (java.lang.IllegalStateException: Invalid BundleContext.)
...
g!
If we stop the bundle in felix 3.2.2, we get the same output, but without exception:
...
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.Activator] : Pax Web stopped
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Unregistering [/system/console/res]
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Unregistering [/system/console]
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceFactoryImpl] : Unbinding bundle: [org.apache.felix.webconsole [15]]
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Stopping http service: [org.ops4j.pax.web.service.internal.HttpServiceProxy@2d61100c]
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceStopped] : Changing HttpService state to org.ops4j.pax.web.service.internal.HttpServiceStopped@23f95cce
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceFactoryImpl] : Unbinding bundle: [de.infoteam.infoteamservlet [6]]
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceProxy] : Stopping http service: [org.ops4j.pax.web.service.internal.HttpServiceProxy@1646fef3]
org.ops4j.pax.web.pax-web-jetty-bundle[org.ops4j.pax.web.service.internal.HttpServiceStopped] : Changing HttpService state to org.ops4j.pax.web.service.internal.HttpServiceStopped@f0c0ef2
g!
In both felix version, the bundle state is "Resolved", after stopping the bundle.
Best regards,
Markus
-----Ursprüngliche Nachricht-----
Von: Richard S. Hall [mailto:heavy@ungoverned.org]
Gesendet: Freitag, 11. November 2011 10:20
An: users@felix.apache.org
Betreff: Re: Pax Web and Felix 4.0.1
The first question I have is, is bundle 19 actually stopped when this
exception occurs? That would only happen if it wasn't cleaning up after
itself when its activator was stopped, which would then be a bug in it
that should be fixed.
On the other hand, if it hasn't been stopped yet, then something else
must be going on.
-> richard
On 11/11/11 3:07, Markus Dippold wrote:
> Hi,
>
> we tried to upgrade Felix from 3.2.2 to 4.0.1 and we are using Pax Web
> 1.0.7.
> It works as expected, but every time we shut down the framework, Pax Web
> throws an exception:
>
> 2011-11-11 08:41:00.839:INFO::stopped
> HttpServiceContext{httpContext=org.apache.felix.webconsole.internal.serv
> let.OsgiManagerHttpContext@2242f64e}
> java.lang.IllegalStateException: Invalid BundleContext.
> ERROR: Bundle org.ops4j.pax.web.pax-web-jetty-bundle [19]
> EventDispatcher: Error during dispatch.
> (java.lang.IllegalStateException: Invalid BundleContext.)
> at
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContext
> Impl.java:514)
> at
> org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextI
> mpl.java:473)
> at
> org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCusto
> mizer.removedService(Activator.java:364)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTr
> acker.java:1006)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTr
> acker.java:906)
> at
> org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTrack
> er.java:949)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCal
> lback(EventDispatcher.java:932)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Eve
> ntDispatcher.java:793)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDi
> spatcher.java:543)
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4252)
> at org.apache.felix.framework.Felix.access$000(Felix.java:74)
> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
> at
> org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegi
> stry.java:148)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceReg
> istrationImpl.java:127)
> at
> org.apache.felix.framework.ServiceRegistry.unregisterServices(ServiceReg
> istry.java:191)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2386)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1214)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLev
> elImpl.java:295)
> at java.lang.Thread.run(Unknown Source)
>
> The exception has no negative effects, but it just does not look good.
>
> Can anybody help us to avoid this exception?
>
> Best regards,
> Markus
>
> ---------------------------------------------------------------------
> 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: Pax Web and Felix 4.0.1
Posted by "Richard S. Hall" <he...@ungoverned.org>.
The first question I have is, is bundle 19 actually stopped when this
exception occurs? That would only happen if it wasn't cleaning up after
itself when its activator was stopped, which would then be a bug in it
that should be fixed.
On the other hand, if it hasn't been stopped yet, then something else
must be going on.
-> richard
On 11/11/11 3:07, Markus Dippold wrote:
> Hi,
>
> we tried to upgrade Felix from 3.2.2 to 4.0.1 and we are using Pax Web
> 1.0.7.
> It works as expected, but every time we shut down the framework, Pax Web
> throws an exception:
>
> 2011-11-11 08:41:00.839:INFO::stopped
> HttpServiceContext{httpContext=org.apache.felix.webconsole.internal.serv
> let.OsgiManagerHttpContext@2242f64e}
> java.lang.IllegalStateException: Invalid BundleContext.
> ERROR: Bundle org.ops4j.pax.web.pax-web-jetty-bundle [19]
> EventDispatcher: Error during dispatch.
> (java.lang.IllegalStateException: Invalid BundleContext.)
> at
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContext
> Impl.java:514)
> at
> org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextI
> mpl.java:473)
> at
> org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCusto
> mizer.removedService(Activator.java:364)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTr
> acker.java:1006)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTr
> acker.java:906)
> at
> org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTrack
> er.java:949)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCal
> lback(EventDispatcher.java:932)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Eve
> ntDispatcher.java:793)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDi
> spatcher.java:543)
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4252)
> at org.apache.felix.framework.Felix.access$000(Felix.java:74)
> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
> at
> org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegi
> stry.java:148)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceReg
> istrationImpl.java:127)
> at
> org.apache.felix.framework.ServiceRegistry.unregisterServices(ServiceReg
> istry.java:191)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2386)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1214)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLev
> elImpl.java:295)
> at java.lang.Thread.run(Unknown Source)
>
> The exception has no negative effects, but it just does not look good.
>
> Can anybody help us to avoid this exception?
>
> Best regards,
> Markus
>
> ---------------------------------------------------------------------
> 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
Pax Web and Felix 4.0.1
Posted by Markus Dippold <Ma...@infoteam.de>.
Hi,
we tried to upgrade Felix from 3.2.2 to 4.0.1 and we are using Pax Web
1.0.7.
It works as expected, but every time we shut down the framework, Pax Web
throws an exception:
2011-11-11 08:41:00.839:INFO::stopped
HttpServiceContext{httpContext=org.apache.felix.webconsole.internal.serv
let.OsgiManagerHttpContext@2242f64e}
java.lang.IllegalStateException: Invalid BundleContext.
ERROR: Bundle org.ops4j.pax.web.pax-web-jetty-bundle [19]
EventDispatcher: Error during dispatch.
(java.lang.IllegalStateException: Invalid BundleContext.)
at
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContext
Impl.java:514)
at
org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextI
mpl.java:473)
at
org.ops4j.pax.web.service.internal.Activator$DynamicsServiceTrackerCusto
mizer.removedService(Activator.java:364)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTr
acker.java:1006)
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTr
acker.java:906)
at
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
at
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTrack
er.java:949)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCal
lback(EventDispatcher.java:932)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Eve
ntDispatcher.java:793)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDi
spatcher.java:543)
at
org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4252)
at org.apache.felix.framework.Felix.access$000(Felix.java:74)
at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
at
org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegi
stry.java:148)
at
org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceReg
istrationImpl.java:127)
at
org.apache.felix.framework.ServiceRegistry.unregisterServices(ServiceReg
istry.java:191)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2386)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1214)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLev
elImpl.java:295)
at java.lang.Thread.run(Unknown Source)
The exception has no negative effects, but it just does not look good.
Can anybody help us to avoid this exception?
Best regards,
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Felix EventAdmin configuration in Karaf
Posted by Zhemzhitsky Sergey <Se...@troika.ru>.
Achim, Carsten,
Thanks a lot for clarification.
Regards,
Sergey
-----Original Message-----
From: Achim Nierbeck [mailto:bcanhome@googlemail.com]
Sent: Friday, November 11, 2011 1:08 AM
To: users@felix.apache.org
Subject: Re: Felix EventAdmin configuration in Karaf
Well I might jump in on the karaf part :) you need a cfg file which reflects the pid of the EventAdmin Service.
org.apache.felix.eventadmin.impl.EventAdmin.cfg (taking a look at the ServicePID this seems to be it :) ) and yes the etc folder is the right place it'll be picked up by the fileinstaller
regards, Achim
Am 10.11.2011 18:37, schrieb Carsten Ziegeler:
> I don't know how to do things in Karaf, but for your second question:
>
>> 2. How to set org.apache.felix.eventadmin.IgnoreTimeout property of event admin properly?
>>
>> Is the following configuration right: org.apache.felix.eventadmin.IgnoreTimeout= org.osgi.framework., org.foo.*, org.bar.Clazz?
>>
>> Does the configuration above mean that all the event handlers will not have timeout for the events in the org.osgi.framework package such as org/osgi/framework/BundleEvent/INSTALLED, org/osgi/framework/BundleEvent/STARTED, etc., as well as for all the events in the org.foo package like org/foo/Event, org/foo/bar/Event, as well as for all the events like org/bar/Clazz/Event?
>
> See the docs at
> https://issues.apache.org/jira/browse/FELIX/fixforversion/12317147 -
> the configuration of IgnoreTimeout is for the implementation class of
> the event handler! It's not the topic. So if you configure "org.foo."
> this means all implementations in this package are ignored for timeout
> handling, with "org.foo*" all implementations in this package or sub
> package are ignored and everything not ending in dot or start is
> considered to be a complete class name like
> "org.foo.impl.MyEventHandler"
> But there is no way to define to ignore the timeout for all handlers
> except listing all packages
>
> Carsten
>
>
>>
>> Best Regards,
>> Sergey
>>
>> _______________________________________________________
>>
>> The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
>> If you need assistance please contact our Contact Center (+7495) 258
>> 0500 or go to www.troika.ru/eng/Contacts/system.wbp
>>
>>
>
>
--
-----
Apache Karaf<http://karaf.apache.org/> Committer& PMC
OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer& Project Lead
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
_______________________________________________________
The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix EventAdmin configuration in Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
Well I might jump in on the karaf part :)
you need a cfg file which reflects the pid of the EventAdmin Service.
org.apache.felix.eventadmin.impl.EventAdmin.cfg (taking a look at the
ServicePID this seems to be it :) )
and yes the etc folder is the right place it'll be picked up by the
fileinstaller
regards, Achim
Am 10.11.2011 18:37, schrieb Carsten Ziegeler:
> I don't know how to do things in Karaf, but for your second question:
>
>> 2. How to set org.apache.felix.eventadmin.IgnoreTimeout property of event admin properly?
>>
>> Is the following configuration right: org.apache.felix.eventadmin.IgnoreTimeout= org.osgi.framework., org.foo.*, org.bar.Clazz?
>>
>> Does the configuration above mean that all the event handlers will not have timeout for the events in the org.osgi.framework package such as org/osgi/framework/BundleEvent/INSTALLED, org/osgi/framework/BundleEvent/STARTED, etc., as well as for all the events in the org.foo package like org/foo/Event, org/foo/bar/Event, as well as for all the events like org/bar/Clazz/Event?
>
> See the docs at
> https://issues.apache.org/jira/browse/FELIX/fixforversion/12317147 -
> the configuration of IgnoreTimeout is for the implementation class of
> the event handler! It's not the topic. So if you configure "org.foo."
> this means all implementations in this package are ignored for timeout
> handling, with "org.foo*" all implementations in this package or sub
> package are ignored and everything not ending in dot or start is
> considered to be a complete class name like
> "org.foo.impl.MyEventHandler"
> But there is no way to define to ignore the timeout for all handlers
> except listing all packages
>
> Carsten
>
>
>>
>> Best Regards,
>> Sergey
>>
>> _______________________________________________________
>>
>> The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
>> If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp
>>
>>
>
>
--
-----
Apache Karaf<http://karaf.apache.org/> Committer& PMC
OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer& Project Lead
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Felix EventAdmin configuration in Karaf
Posted by Carsten Ziegeler <cz...@apache.org>.
I don't know how to do things in Karaf, but for your second question:
> 2. How to set org.apache.felix.eventadmin.IgnoreTimeout property of event admin properly?
>
> Is the following configuration right: org.apache.felix.eventadmin.IgnoreTimeout= org.osgi.framework., org.foo.*, org.bar.Clazz?
>
> Does the configuration above mean that all the event handlers will not have timeout for the events in the org.osgi.framework package such as org/osgi/framework/BundleEvent/INSTALLED, org/osgi/framework/BundleEvent/STARTED, etc., as well as for all the events in the org.foo package like org/foo/Event, org/foo/bar/Event, as well as for all the events like org/bar/Clazz/Event?
See the docs at
https://issues.apache.org/jira/browse/FELIX/fixforversion/12317147 -
the configuration of IgnoreTimeout is for the implementation class of
the event handler! It's not the topic. So if you configure "org.foo."
this means all implementations in this package are ignored for timeout
handling, with "org.foo*" all implementations in this package or sub
package are ignored and everything not ending in dot or start is
considered to be a complete class name like
"org.foo.impl.MyEventHandler"
But there is no way to define to ignore the timeout for all handlers
except listing all packages
Carsten
>
>
> Best Regards,
> Sergey
>
> _______________________________________________________
>
> The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
> If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp
>
>
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org