Re: [WebConsole] [Question - feature request] optionnal dependency on httpService
Hi Am 14.04.2012 um 01:27 schrieb Frederic Esnault: > Thanks for the answer Felix, Welcome. Regards Felix > > Actually i think you're right, i forgot about the http bridge. And it seems > it's quite what i was asking for. > I was more thinking about something like discovery of the http service > published by the aplication through the system bundle, but i was missing > one point : how the request is supposed to be routed to the webConsole. > I'll have a look at this. > > Thanks again ! > > Frederic > > On Fri, Apr 13, 2012 at 7:39 PM, Felix Meschberger wrote: > >> Hi, >> >> Am 13.04.2012 um 14:39 schrieb Frederic Esnault: >> >>> Hi all, >>> I'm wondering if it would be possible to use the webconsole without the >>> dependency on the httpService. >>> For example, in a webapplication embedding an OSGi framework, we could >> make >>> the packages and services available to the web console bundle through the >>> EXTRA_PACKAGE export of the framework, and publish the service in the >>> webapp, through the system bundle. >>> >>> Could it be a possibility? >> >> This would be a major refactoring because the Web Console uses the Http >> Service to register the console servlet and it uses the HttpContext to >> implement the authentication. >> >> But if you have an OSGi Framework in your web application, why not using >> the Http Service bridge ? This requires a bridge servlet in your web >> application and the Http Service bridge bundle in the framework. >> >> Regards >> Felix
[jira] [Commented] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253938#comment-13253938 ] David Jencks commented on FELIX-3456: - Just in case anyone was wondering, as I was, I checked the spec and (4.3 section 5.3) all service events must be delivered synchronously. Thus there is definitely a possibility of deadlocks if we're not careful (more careful than my patch). A colleague tried a completely asynchronous model for service events in scr and although start seemed to work, stopping resulted in a lot of work on stopped bundles and component objects. I think if we can convince ourselves that it conforms to the spec this is a viable approach but it will take quite a bit of work to identify all the cases where we're working with closed stuff. I wonder to what extent we can remove the deadlock scenarios by (a) avoiding the synchronized block entirely when possible. For instance the first place we found this, DependencyManager.serviceAdded, I think we can skip the block I synchronized if the dependency is not mandatory, because if its not mandatory it showing up can't result in service activation. (b) avoiding calling out, such as the bind and unbind methods, from a synchronized block. This might be a wacky and non-plausible idea We might have an internal and external state. for instance: thread 1 supplies service A thread 1 gets the lock and updates internal and external state to "activating" thread 2 supplies service B and can't get the lock thread 1 does the calculations in Unsatisfied.activate up to the point where it calls out to the bind methods, and then updates the internal state to "active" and releases the lock thread 2 gets the lock and sees the internal state is "active" so it doesn't do much except release the lock thread 1 finishes calling the bind methods and updates the external state to "active". > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Priority: Critical > Attachments: FELIX-3456-1.diff > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentMana
Re: [WebConsole] [Question - feature request] optionnal dependency on httpService
Thanks for the answer Felix, Actually i think you're right, i forgot about the http bridge. And it seems it's quite what i was asking for. I was more thinking about something like discovery of the http service published by the aplication through the system bundle, but i was missing one point : how the request is supposed to be routed to the webConsole. I'll have a look at this. Thanks again ! Frederic On Fri, Apr 13, 2012 at 7:39 PM, Felix Meschberger wrote: > Hi, > > Am 13.04.2012 um 14:39 schrieb Frederic Esnault: > > > Hi all, > > I'm wondering if it would be possible to use the webconsole without the > > dependency on the httpService. > > For example, in a webapplication embedding an OSGi framework, we could > make > > the packages and services available to the web console bundle through the > > EXTRA_PACKAGE export of the framework, and publish the service in the > > webapp, through the system bundle. > > > > Could it be a possibility? > > This would be a major refactoring because the Web Console uses the Http > Service to register the console servlet and it uses the HttpContext to > implement the authentication. > > But if you have an OSGi Framework in your web application, why not using > the Http Service bridge ? This requires a bridge servlet in your web > application and the Http Service bridge bundle in the framework. > > Regards > Felix
[jira] [Created] (FELIX-3458) Resolver should populate results with wires to self
Resolver should populate results with wires to self --- Key: FELIX-3458 URL: https://issues.apache.org/jira/browse/FELIX-3458 Project: Felix Issue Type: Bug Components: Resolver Environment: All Reporter: Thomas Watson Priority: Minor Except for the osgi.wiring.* namespaces, I think all other namespaces should include results where the Wire has the same provider and requirer. Currently org.apache.felix.resolver.ResolverImpl.populateWireMap() has a check omits the wire from the result if a resource requriement gets wired to its own capability. This has to be done for osgi.wiring.package namespace because that is a case where the import got dropped in favor of the export. But for other namespaces I am not sure that is a valid assumption. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253605#comment-13253605 ] Felix Meschberger commented on FELIX-3456: -- Thanks for reporting. This is in fact an issue. I am not against replacing the size int by an AtomicInteger; in the interest of concurrency stability this might make sense. (though this might prevent SCR from being used in pre-Java 5 setups; we still consider this requirement valid for SCR) But I am not convinced with the state lock. This going to be dangerous for deadlocks because during activate and deactive services may be registered or unregistered, which may cause deadlocks: We currently have one single situation where we synchronize (creation of delayed component service instances) and we realize occasional deadlocks. Thinking the other way around: We have some transient states during which events may happen which may get lost. One such transient state is the activating state. And this is such an event which may get lost. Another event may be a configuration update. I have been contemplating some kind of event queuing and some way of processing such a queue when leaving the transient state. In the concrete example: T1 registers Service A, causes component into the ACTIVATING state T2 registers Service B, enqueues event since component is ACTIVATING T1 terminates ACTIVATING, checks queue and handles event. The queue could be as simple as a list of Runnable on each component manager. > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Priority: Critical > Attachments: FELIX-3456-1.diff > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentManager.STATE_ACTIVE ) > This is an easy fix, but I guess may leave a small window where a static > reference could get replaced while a component was still activating if > another instance of the same service was registered on a different thread. > There are other fixes that could be done by synchronizing more around service > additions. > Is anyone willing to make this fix or does anyone have any thoug
Re: [WebConsole] [Question - feature request] optionnal dependency on httpService
Hi, Am 13.04.2012 um 14:39 schrieb Frederic Esnault: > Hi all, > I'm wondering if it would be possible to use the webconsole without the > dependency on the httpService. > For example, in a webapplication embedding an OSGi framework, we could make > the packages and services available to the web console bundle through the > EXTRA_PACKAGE export of the framework, and publish the service in the > webapp, through the system bundle. > > Could it be a possibility? This would be a major refactoring because the Web Console uses the Http Service to register the console servlet and it uses the HttpContext to implement the authentication. But if you have an OSGi Framework in your web application, why not using the Http Service bridge ? This requires a bridge servlet in your web application and the Http Service bridge bundle in the framework. Regards Felix
RE: Enhanced Apache Felix / JRebel integration
> >> Additionally, it seems you might be confused about the > responsibility > >> of > >> some tasks. For example, SCR doesn't look for changes in component > >> descriptors at all, it simply listens for bundles to be activated. > >> Listening to changes in the component descriptor would have to hook > >> into > >> the build process somehow. By and large, none of the Felix > subprojects > >> are involved in the build process other than the Maven Bundle > plugin. > > I have considered hooking into the maven-bundle-plugin as well, but I > have no idea on how to notify Felix that a bundle needs to be refreshed > or even send a custom event which I can handle myself. > > If you use something like File Install and generate bundle's into a > directory managed by File Install, it will automatically update and > refresh the bundle when its JAR file changes, which would cause SCR to > stop, then restart managing it. It's a little more coarse grained that > what you want, but it should work out of the box with a lot less > effort. One of my (self-imposed) constraints is that this process should be IDE-driven rather than build tool-driven. The main reason is performance - I prefer not to repackage bundles on each change since that will take some time. Instead, I prefer to react to filesystem changes myself and nicely ask the Felix container to refresh a bundle if needed. As as far as I can see fileinstall handles only configuration and jar files, not SCR descriptors and I think that this is not something which belongs in the core fileinstall bundle. Perhaps I can explain better with an example rather than in abstract terms, so here's what I want to achieve in terms of development experience: 1. Start Apache Felix with SCR capabilities and with the JRebel agent 2. Deploy a bundle with a JRebel configuration attached 3. Start listening for changes to the declared SCR descriptors of the bundle 4. When the SCR descriptors change on disk, call PackageAdmin.refreshPackages() I can safely do (4) the packages since JRebel already ensures that I will get the most current version of the class without needing to redeploy the bundle. I purposefully ignore how the changes will be made for (3) since that's a different implementation topic. I am aware that this process does not make sense unless JRebel is used, so that's why I'm trying to find out the best way of hooking into the framework without the need to make invasive changes. Robert > > -> richard > > > > > Thanks, > > > > Robert > > > >> -> richard > >> > >>> I would like to validate that this is at all possible within Apache > >> Felix and to ask which are the best places to start looking for > adding > >> the JRebel functionality. Any thoughts/pointers on how to best start > >> developing this would be greatly appreciated. > >> > >>> If this is feasible, I intend to develop this as a separate JRebel > >> plugin and contribute it to the Apache Felix project. > >>> Thanks, > >>> > >>> Robert > >>> > >>> [1]: http://zeroturnaround.com/jrebel/ > >>> [2]: http://zeroturnaround.com/jrebel/features/ > >>>
[jira] [Resolved] (FELIX-3457) Component annotation does not detect abstract class
[ https://issues.apache.org/jira/browse/FELIX-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-3457. - Resolution: Duplicate Duplicate of FELIX-3077 > Component annotation does not detect abstract class > --- > > Key: FELIX-3457 > URL: https://issues.apache.org/jira/browse/FELIX-3457 > Project: Felix > Issue Type: Bug > Components: SCR Annotations >Affects Versions: scr annotations 1.6.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: scr annotations 1.6.2 > > > The component annotation either returns the provided value for > componentAbstract() or the default value, it does never check the class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3457) Component annotation does not detect abstract class
Component annotation does not detect abstract class --- Key: FELIX-3457 URL: https://issues.apache.org/jira/browse/FELIX-3457 Project: Felix Issue Type: Bug Components: SCR Annotations Affects Versions: scr annotations 1.6.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: scr annotations 1.6.2 The component annotation either returns the provided value for componentAbstract() or the default value, it does never check the class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3411) The implementation of org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the spec
[
https://issues.apache.org/jira/browse/FELIX-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall updated FELIX-3411:
---
Fix Version/s: framework-4.2.0
> The implementation of
> org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the
> spec
>
>
> Key: FELIX-3411
> URL: https://issues.apache.org/jira/browse/FELIX-3411
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Yasuhiro Kawame
> Fix For: framework-4.2.0
>
>
> I think that the implementation of Changing the Active Start Level is
> different from Spec.
> see:
> OSGi Service Platform Core Specification Release 4, Version 4.3, Figure 8.2
> page154
> Move to requested start level R, active level is A, B is a bundle's start
> level
> Spec:
> if (A < R)
> while (A < R) {
> A = A + 1
> Start All bundles where B = A
> }
> Implementation:
> if (A < R)
> Start All bundles where B <= R
> A = R
> Similarly, if A > R.
> Javadoc:
> http://www.osgi.org/javadoc/r4v43/org/osgi/service/startlevel/StartLevel.html#setStartLevel%28int%29
> http://www.osgi.org/javadoc/r4v43/org/osgi/framework/startlevel/FrameworkStartLevel.html#setStartLevel(int,
> org.osgi.framework.FrameworkListener...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3411) The implementation of org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the spec
[
https://issues.apache.org/jira/browse/FELIX-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253359#comment-13253359
]
Richard S. Hall commented on FELIX-3411:
Ok, I think I understand your point now, you think it should attempt to restart
bundles that are below the current active start level (effectively blacklisting
them). I'm not sure this is what the spec means. I'll investigate.
> The implementation of
> org.osgi.service.startlevel.StartLevel#setStartLevel(int) does not follow the
> spec
>
>
> Key: FELIX-3411
> URL: https://issues.apache.org/jira/browse/FELIX-3411
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Yasuhiro Kawame
>
> I think that the implementation of Changing the Active Start Level is
> different from Spec.
> see:
> OSGi Service Platform Core Specification Release 4, Version 4.3, Figure 8.2
> page154
> Move to requested start level R, active level is A, B is a bundle's start
> level
> Spec:
> if (A < R)
> while (A < R) {
> A = A + 1
> Start All bundles where B = A
> }
> Implementation:
> if (A < R)
> Start All bundles where B <= R
> A = R
> Similarly, if A > R.
> Javadoc:
> http://www.osgi.org/javadoc/r4v43/org/osgi/service/startlevel/StartLevel.html#setStartLevel%28int%29
> http://www.osgi.org/javadoc/r4v43/org/osgi/framework/startlevel/FrameworkStartLevel.html#setStartLevel(int,
> org.osgi.framework.FrameworkListener...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[WebConsole] [Question - feature request] optionnal dependency on httpService
Hi all, I'm wondering if it would be possible to use the webconsole without the dependency on the httpService. For example, in a webapplication embedding an OSGi framework, we could make the packages and services available to the web console bundle through the EXTRA_PACKAGE export of the framework, and publish the service in the webapp, through the system bundle. Could it be a possibility? Frederic Esnault
[jira] [Updated] (FELIX-3152) JMX as web console feature
[ https://issues.apache.org/jira/browse/FELIX-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christanto updated FELIX-3152: -- Attachment: org.apache.felix.webconsole.plugins.jmx.zip Updated codes > JMX as web console feature > -- > > Key: FELIX-3152 > URL: https://issues.apache.org/jira/browse/FELIX-3152 > Project: Felix > Issue Type: New Feature > Components: Web Console >Reporter: Christanto > Labels: jmx, webconsole > Attachments: org.apache.felix.webconsole.plugins.jmx.zip, > org.apache.felix.webconsole.plugins.jmx.zip > > > The attached file is a source code that implement JMX client as felix web > console. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated FELIX-3456: Attachment: FELIX-3456-1.diff This synchronized some state changes in Componentmanager and uses an AtomicInteger for DependencyManager.size. I realize that using modern concurrency techniques is going to require some debate :-) but I'm putting this out for review and testing. > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Priority: Critical > Attachments: FELIX-3456-1.diff > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentManager.STATE_ACTIVE ) > This is an easy fix, but I guess may leave a small window where a static > reference could get replaced while a component was still activating if > another instance of the same service was registered on a different thread. > There are other fixes that could be done by synchronizing more around service > additions. > Is anyone willing to make this fix or does anyone have any thoughts about > this issue? > Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
