[jira] [Updated] (FELIX-3789) Deadlock due to synchronization on INSTANCE_NAME
[ https://issues.apache.org/jira/browse/FELIX-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3789: - Fix Version/s: ipojo-runtime-1.8.6 Assignee: Clement Escoffier > Deadlock due to synchronization on INSTANCE_NAME > > > Key: FELIX-3789 > URL: https://issues.apache.org/jira/browse/FELIX-3789 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-core-1.8.4 >Reporter: Sebastien GRIMARD >Assignee: Clement Escoffier > Fix For: ipojo-runtime-1.8.6 > > > iPojo sometimes locks up during component instanciation in our application. > After analysis, the lockup occurs since the fix in FELIX-3548 was applied. > The problem is that createComponentInstance in the class IPojoFactory is > pseudo-recursive (through a call to getHandler), that is it can call > recursively itself on a different factory instance. > Since createComponentInstance synchronizes itself on the factory first (local > lock) and on INSTANCE_NAME second (global lock), sometimes it will try to > call createComponentInstance on a different factory while holding the global > lock and while another threads holds that factory's local lock and is trying > to acquire the global lock (I hope what I wrote makes sense). > Stack trace of the problem : > Daemon Thread [Thread-1] (Suspended) > owns: ComponentFactory (id=5717) > owns: ArrayList (id=5708) <== > owns: HandlerManagerFactory (id=5718) > waiting for: HandlerManagerFactory (id=5709) <== > HandlerManagerFactory(IPojoFactory).createComponentInstance(Dictionary, > ServiceContext) line: 258 > ComponentFactory(IPojoFactory).getHandler(IPojoFactory$RequiredHandler, > ServiceContext) line: 830 > ComponentFactory(IPojoFactory).createComponentInstance(Dictionary, > ServiceContext) line: 306 > ComponentFactory(IPojoFactory).createComponentInstance(Dictionary) > line: 239 > InstanceCreator$ManagedInstance.create(IPojoFactory) line: 343 > InstanceCreator.onValidation(IPojoFactory) line: 202 > InstanceCreator.stateChanged(Factory, int) line: 243 > ComponentFactory(IPojoFactory).computeFactoryState() line: 766 > ComponentFactory.addedService(ServiceReference) line: 414 > Tracker$Tracked.trackAdding(ServiceReference) line: 725 > Tracker$Tracked.track(ServiceReference) line: 686 > Tracker$Tracked.serviceChanged(ServiceEvent) line: 642 > FilteredServiceListener.serviceChanged(ServiceEvent) line: 107 > BundleContextImpl.dispatchEvent(Object, Object, int, Object) line: 861 > EventManager.dispatchEvent(Set, EventDispatcher, int, Object) line: > 230 > ListenerQueue.dispatchEventSynchronous(int, Object) line: 148 > ServiceRegistry.publishServiceEventPrivileged(ServiceEvent) line: 819 > ServiceRegistry.publishServiceEvent(ServiceEvent) line: 771 > ServiceRegistrationImpl.register(Dictionary) line: 130 > ServiceRegistry.registerService(BundleContextImpl, String[], Object, > Dictionary) line: 214 > BundleContextImpl.registerService(String[], Object, Dictionary) line: > 433 > HandlerManagerFactory(IPojoFactory).start() line: 613 > Extender.createAbstractFactory(Bundle, Element) line: 520 > Extender.parse(Bundle, String) line: 301 > Extender.startManagementFor(Bundle) line: 237 > Extender.access$600(Extender, Bundle) line: 52 > Extender$CreatorThread.run() line: 769 > Thread.run() line: 662 > Daemon Thread [Thread-7] (Suspended) > owns: HandlerManagerFactory (id=5709) <== > owns: ComponentFactory (id=5710) > owns: Tracker (id=5711) > owns: Dependency[] (id=5712) > waiting for: ArrayList (id=5708)<== > HandlerManagerFactory(IPojoFactory).createComponentInstance(Dictionary, > ServiceContext) line: 283 > ComponentFactory(IPojoFactory).getHandler(IPojoFactory$RequiredHandler, > ServiceContext) line: 830 > ComponentFactory(IPojoFactory).computeDescription() line: 721 > ComponentFactory(IPojoFactory).computeFactoryState() line: 757 > ComponentFactory.addedService(ServiceReference) line: 414 > Tracker$Tracked.trackAdding(ServiceReference) line: 725 > Tracker$Tracked.trackInitialServices() line: 610 > Tracker.open() line: 210 > ComponentFactory.starting() line: 262 > ComponentFactory(IPojoFactory).start() line: 605 > PrimitiveComponentType.createFactory() line: 441 > PrimitiveComponentType.initializeFactory() line: 198 > PrimitiveComponentType.getFactory() line: 171 > PrimitiveComponentType(ComponentType).ensureFactory() line: 185 > Primitiv
[jira] [Commented] (FELIX-3742) Implementing class fails to load unless super interface's (interface extended by implemented interface) package is imported.
[ https://issues.apache.org/jira/browse/FELIX-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534042#comment-13534042 ] Ricardo Torres commented on FELIX-3742: --- No, it looks like you're right. My old issue must have been unrelated. Please feel free to close this issue. Thanks. > Implementing class fails to load unless super interface's (interface extended > by implemented interface) package is imported. > > > Key: FELIX-3742 > URL: https://issues.apache.org/jira/browse/FELIX-3742 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-core-1.8.2 >Reporter: Ricardo Torres >Assignee: Clement Escoffier > Attachments: impl.jar, parent.jar, service.jar > > > I attempted to file FELIX-3741, but the issue appears to stem from iPOJO. > Specifically > org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler > generates the following error: > [Thread-1] ERROR com.sample.bundle - [ERROR] com.sample.SampleServiceImpl : > Service Providing: The service specification com.sample.ICoreService cannot > be load > This happens if SampleServiceImpl is in com.sample.bundle. This bundle > imports the package of the interface SampleServiceImpl implements, but does > not directly import the interface this interface extends. > Beyond the above referenced issue, I also hashed this out on the mailing > list: > https://mail-archives.apache.org/mod_mbox/felix-users/201210.mbox/%3CCAAkggDoMXvJ995o3=4_gnlwaq9gmyjmjyzgtdjhateg7pxe...@mail.gmail.com%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3742) Implementing class fails to load unless super interface's (interface extended by implemented interface) package is imported.
[ https://issues.apache.org/jira/browse/FELIX-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534042#comment-13534042 ] Ricardo Torres commented on FELIX-3742: --- No, it looks like you're right. My old issue must have been unrelated. Please feel free to close this issue. Thanks. > Implementing class fails to load unless super interface's (interface extended > by implemented interface) package is imported. > > > Key: FELIX-3742 > URL: https://issues.apache.org/jira/browse/FELIX-3742 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-core-1.8.2 >Reporter: Ricardo Torres >Assignee: Clement Escoffier > Attachments: impl.jar, parent.jar, service.jar > > > I attempted to file FELIX-3741, but the issue appears to stem from iPOJO. > Specifically > org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler > generates the following error: > [Thread-1] ERROR com.sample.bundle - [ERROR] com.sample.SampleServiceImpl : > Service Providing: The service specification com.sample.ICoreService cannot > be load > This happens if SampleServiceImpl is in com.sample.bundle. This bundle > imports the package of the interface SampleServiceImpl implements, but does > not directly import the interface this interface extends. > Beyond the above referenced issue, I also hashed this out on the mailing > list: > https://mail-archives.apache.org/mod_mbox/felix-users/201210.mbox/%3CCAAkggDoMXvJ995o3=4_gnlwaq9gmyjmjyzgtdjhateg7pxe...@mail.gmail.com%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3742) Implementing class fails to load unless super interface's (interface extended by implemented interface) package is imported.
[ https://issues.apache.org/jira/browse/FELIX-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534042#comment-13534042 ] Ricardo Torres commented on FELIX-3742: --- No, it looks like you're right. My old issue must have been unrelated. Please feel free to close this issue. Thanks. > Implementing class fails to load unless super interface's (interface extended > by implemented interface) package is imported. > > > Key: FELIX-3742 > URL: https://issues.apache.org/jira/browse/FELIX-3742 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-core-1.8.2 >Reporter: Ricardo Torres >Assignee: Clement Escoffier > Attachments: impl.jar, parent.jar, service.jar > > > I attempted to file FELIX-3741, but the issue appears to stem from iPOJO. > Specifically > org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler > generates the following error: > [Thread-1] ERROR com.sample.bundle - [ERROR] com.sample.SampleServiceImpl : > Service Providing: The service specification com.sample.ICoreService cannot > be load > This happens if SampleServiceImpl is in com.sample.bundle. This bundle > imports the package of the interface SampleServiceImpl implements, but does > not directly import the interface this interface extends. > Beyond the above referenced issue, I also hashed this out on the mailing > list: > https://mail-archives.apache.org/mod_mbox/felix-users/201210.mbox/%3CCAAkggDoMXvJ995o3=4_gnlwaq9gmyjmjyzgtdjhateg7pxe...@mail.gmail.com%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3742) Implementing class fails to load unless super interface's (interface extended by implemented interface) package is imported.
[ https://issues.apache.org/jira/browse/FELIX-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534042#comment-13534042 ] Ricardo Torres commented on FELIX-3742: --- No, it looks like you're right. My old issue must have been unrelated. Please feel free to close this issue. Thanks. > Implementing class fails to load unless super interface's (interface extended > by implemented interface) package is imported. > > > Key: FELIX-3742 > URL: https://issues.apache.org/jira/browse/FELIX-3742 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-core-1.8.2 >Reporter: Ricardo Torres >Assignee: Clement Escoffier > Attachments: impl.jar, parent.jar, service.jar > > > I attempted to file FELIX-3741, but the issue appears to stem from iPOJO. > Specifically > org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler > generates the following error: > [Thread-1] ERROR com.sample.bundle - [ERROR] com.sample.SampleServiceImpl : > Service Providing: The service specification com.sample.ICoreService cannot > be load > This happens if SampleServiceImpl is in com.sample.bundle. This bundle > imports the package of the interface SampleServiceImpl implements, but does > not directly import the interface this interface extends. > Beyond the above referenced issue, I also hashed this out on the mailing > list: > https://mail-archives.apache.org/mod_mbox/felix-users/201210.mbox/%3CCAAkggDoMXvJ995o3=4_gnlwaq9gmyjmjyzgtdjhateg7pxe...@mail.gmail.com%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3810) @org.osgi.service.component.annotations.Component configurationPolicy attribute not processed correctly by DSAnnotationProcessor
[ https://issues.apache.org/jira/browse/FELIX-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Flynn updated FELIX-3810: - Fix Version/s: scr ds annotations 1.2.2 > @org.osgi.service.component.annotations.Component configurationPolicy > attribute not processed correctly by DSAnnotationProcessor > > > Key: FELIX-3810 > URL: https://issues.apache.org/jira/browse/FELIX-3810 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: scr ds annotations 1.2.0 >Reporter: Stephen Flynn > Fix For: scr ds annotations 1.2.2 > > Attachments: DSAnnotationProcessor.java.patch > > > Non default (OPTIONAL) values of the configurationPolicy attribute are > ignored by DSAnnotationProcessor. I think this is a trivial fix - patch > attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DS} major refactoring of dependency management
Hi David, great ! I'll try to do some tests this week. regards /Pierre On Sun, Dec 16, 2012 at 6:03 AM, David Jencks wrote: > I've been working on fixing the numerous timing holes in ds dependency > tracking and I think I'm getting close to being willing to commit the > results. > > I've put what I have now up at github at > https://github.com/djencks/felix.git in the service-tracker-3 branch. If > anyone is interested in taking a look that would be great. > > There are two main parts to my refactoring: > > 1. use a copy of ServiceTracker modified for the requirements of DS. > Service tracker actually tracks services properly and doesn't emit > duplicate events, miss events, etc etc. I don't think its possible to > track services properly in any simpler way. Modifications are primarily: > -a- we need a new Added event after the service is put in the tracking map > since we may want to use the event as a trigger to try to activate the > component, querying the service tracker for matching services. So the > service better be in the map :-) > -b- Closing needs to happen in 2 steps in order to deal with filter > changes. The initial close step needs to unregister the service listener > and return the current state of the map. The second close step can clear > the map. > -c- We need to expose the internal tracker for some locking. > -d- expose the tracking count. This already was in the base tracker code > but not used in ServiceTracker. we need it. This is an event counter, not > the number of tracked services. > > 2. For each component instance, keep track of the initial tracking count > when we query for existing services and the final tracking count when we > unbind services. Then we can ignore, for a given instance, events that are > "before" (have a lower tracking count than) the open and "after" (have a > higher tracking count than) the close thus avoiding duplicate and missing > bind and unbinds. > > I also put the different multiplicity/dynamic styles of reference in > separate customizer classes which I think simplifies the logic. > > There are a few other bug fixes in there too: > > FELIX-3729 > [DS] Track dependencies by imitating ServiceTracker and keeping a list of > actual service references all the time (this is most of the work) > > FELIX-3738 > [DS] ComponentInstance.getServices(String refName) is implemented wrong > for 0..1 and 1..1 refs > > FELIX-3825 > [DS] make logging more useful by including component ID when known > > > > As a side effect, a lot more of the circular reference situations are > getting resolved. I'm not entirely sure why, but I'm not objecting. > > > There are a lot (?) of unused parts of service tracker. So far I've made > minimal modifications to the copied osgi code in the interests of > maintainability in case the osgi code changes, but I could easily be talked > into removing the stuff we don't use. > > > thanks > david jencks > > > >
[jira] [Work started] (FELIX-3811) http service should allow the interfaces bound to be configured
[ https://issues.apache.org/jira/browse/FELIX-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3811 started by Ken Gilmer. > http service should allow the interfaces bound to be configured > --- > > Key: FELIX-3811 > URL: https://issues.apache.org/jira/browse/FELIX-3811 > Project: Felix > Issue Type: Wish > Components: Lightweight HTTP Service >Reporter: Ed Schaller >Assignee: Ken Gilmer >Priority: Minor > Labels: patch > Attachments: httplite.bind.patch > > > As I primarily use the lightweight http service to debug using the webconsole > it would be nice to only bind it to the local interface to limit access to > the webconsole. This could be done by providing a configuration paramater to > specify the host address to bind to and could also be useful for those > running lightweight http on multihomed hosts. > I have created a patch against 0.1.5-SNAPSHOT that includes such > functionality. It uses org.apache.felix.http.host as the configuration key > but this could be changed. The semantics of what should be done when the host > specified cannot be resolved (eg: InetAddress.getByName() fails) may also be > worth changing. Presently it just binds to all interfaces if it is unable to > resolve/parse the address. Failing closed would be better in my opinion but > might not be the most intuitive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3811) http service should allow the interfaces bound to be configured
[ https://issues.apache.org/jira/browse/FELIX-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Gilmer resolved FELIX-3811. --- Resolution: Fixed Applied Ed's patch and a minor update for consistent code style. All tests pass. > http service should allow the interfaces bound to be configured > --- > > Key: FELIX-3811 > URL: https://issues.apache.org/jira/browse/FELIX-3811 > Project: Felix > Issue Type: Wish > Components: Lightweight HTTP Service >Reporter: Ed Schaller >Assignee: Ken Gilmer >Priority: Minor > Labels: patch > Attachments: httplite.bind.patch > > > As I primarily use the lightweight http service to debug using the webconsole > it would be nice to only bind it to the local interface to limit access to > the webconsole. This could be done by providing a configuration paramater to > specify the host address to bind to and could also be useful for those > running lightweight http on multihomed hosts. > I have created a patch against 0.1.5-SNAPSHOT that includes such > functionality. It uses org.apache.felix.http.host as the configuration key > but this could be changed. The semantics of what should be done when the host > specified cannot be resolved (eg: InetAddress.getByName() fails) may also be > worth changing. Presently it just binds to all interfaces if it is unable to > resolve/parse the address. Failing closed would be better in my opinion but > might not be the most intuitive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Apache Felix Web Console 4.0.0 and plugins
FYI the httplite bug should be fixed as of rev 1423137. thx, ken On Mon, Jun 4, 2012 at 8:39 AM, Pierre De Rop wrote: > Mon, 04 Jun > 2012 12:27:48 GMT >
[jira] [Created] (FELIX-3826) [DS] race in enabling components with factory pid
David Jencks created FELIX-3826: --- Summary: [DS] race in enabling components with factory pid Key: FELIX-3826 URL: https://issues.apache.org/jira/browse/FELIX-3826 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.2 Reporter: David Jencks Assignee: David Jencks Fix For: scr-1.6.4 ImmediateComponentHolder.enableComponents has a race condition. It sets the holder's m_enabled state last after enabling all the components it finds when it starts. However other threads from config admin could be adding components during this time, and they will never get enabled. Calling enable on a component twice shouldn't cause a problem, so moving setting m_enabled to the start of enableComponents should fix this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SCR compilation problem in the trunk ?
It's a mistake. It's long gone in my github branch. I blame autocompletion :-). I'd prefer to just let my branch fix it when I commit, but if you want to fix it now I don't think it would cause any serious merge problems. thanks david jencks On Dec 17, 2012, at 9:19 AM, Pierre De Rop wrote: > Hi, > > The scr seems to not compile in the trunk: > > [ERROR] > /home/nxuser/work/osgi/felix-trunk/scr/src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java:[38,40] > package com.sun.xml.internal.rngom.binary does not exist > > > maybe the com.sun.xml.internal.rngom.binary.DataExceptPattern import has > been included by mistake ? or is it intentional ? > > Thanks > /Pierre
