Re: IPOJO initialization + refresh deadlock
On Thu, Jan 3, 2013 at 12:55 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Tue, Jan 1, 2013 at 12:09 PM, Jad Naous j...@nerati.com wrote: ...I'm running into another deadlock now. It seems like there needs to be a more rigorous study of how locking is used in the framework. In particular, it seems like the framework should not be invoking any listeners within the same thread that's executing the stopping/starting/refreshing of bundles... I haven't studied your case in detail but you might want to compare with FELIX-3067 - it would be interesting to see if that's related to what you see. Seems related. I'm guessing you are running into the deadlock because the classloader tries to acquire the global lock while holding some application lock? I'm not familiar with the Sling Launchpad. Is this a maven repo somewhere where I can get your patches? Thanks, Jad.
[jira] [Commented] (FELIX-3835) Cannot get from PojoMetadata, MethodMetadata object of an inherited method of an iPOJO instance.
[ https://issues.apache.org/jira/browse/FELIX-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542822#comment-13542822 ] Guillaume Sauthier commented on FELIX-3835: --- Inheritance is not supported in the manipulator. Cannot get from PojoMetadata, MethodMetadata object of an inherited method of an iPOJO instance. Key: FELIX-3835 URL: https://issues.apache.org/jira/browse/FELIX-3835 Project: Felix Issue Type: Bug Components: iPOJO Reporter: Jérémy Cazaux Cannot get from org.apache.felix.ipojo.parser.PojoMetadata, MethodMetadata object of an inherited method of an iPOJO instance (it looks like that inherited methods are not store in the « manipulation » element of the MANIFEST). MethodMetadata method = getPojoMetadata().getMethod(name); Here method is null. As a result on my own iPOJO handler, I cannot register an interceptor on inherited methods. After that, I also got an NPE when I called the register method of the InstanceManager. java.lang.NullPointerException at org.apache.felix.ipojo.InstanceManager.register(InstanceManager.java:987) -- 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-3837) PojoizationPlugin should be more extensible
[ https://issues.apache.org/jira/browse/FELIX-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542841#comment-13542841 ] Guillaume Sauthier commented on FELIX-3837: --- I had something similar in mind, but at runtime. Something that looks like the auto-handlers behavior, but based on service. You could modify the component definition before a Factory is created from it. Could that feature be useful for you ? PojoizationPlugin should be more extensible --- Key: FELIX-3837 URL: https://issues.apache.org/jira/browse/FELIX-3837 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Jérémy Cazaux Attachments: 0001-PojoizationPlugin-should-be-more-extensible.patch I would like to extend Pojoization plugin without duplication of code in order to manipulate metadata elements from the CacheableMetadataProvider object just before the pojoization operation (for example to automate the definition of my own handlers in the manifest). So all fields and methods should be protected instead of private and a new mechanism should be add in order to allow to manipulate cacheable metadata easily. I have attached a patch to fix this issue if the extensibility of the plugin is acceptable. -- 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: IPOJO initialization + refresh deadlock
On Thu, Jan 3, 2013 at 10:19 AM, Jad Naous j...@nerati.com wrote: On Thu, Jan 3, 2013 at 12:55 AM, Bertrand Delacretaz bdelacre...@apache.org ... I haven't studied your case in detail but you might want to compare with FELIX-3067... Seems related. I'm guessing you are running into the deadlock because the classloader tries to acquire the global lock while holding some application lock? I cannot say for sure, haven't looked at that issue in a while. The SCR subsystem might have its own locks that contribute to exposing the deadlocks. I'm not familiar with the Sling Launchpad. Is this a maven repo somewhere where I can get your patches?... You can build Sling and use its launchpad as described in FELIX-3067 if you want, but the key part in reproducing the deadlocks is the stress tests [1] - I used Sling only as a provider of several bundles which use SCR services, as that helps expose the problem. -Bertrand [1] https://github.com/bdelacretaz/osgi-stresser
[jira] [Commented] (FELIX-3837) PojoizationPlugin should be more extensible
[ https://issues.apache.org/jira/browse/FELIX-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542853#comment-13542853 ] Guillaume Sauthier commented on FELIX-3837: --- See here for an implementation proposal: https://github.com/sauthieg/felix/commit/33070082a209da9b3baa9b5cd1f2cc3aec8288a8 PojoizationPlugin should be more extensible --- Key: FELIX-3837 URL: https://issues.apache.org/jira/browse/FELIX-3837 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Jérémy Cazaux Attachments: 0001-PojoizationPlugin-should-be-more-extensible.patch I would like to extend Pojoization plugin without duplication of code in order to manipulate metadata elements from the CacheableMetadataProvider object just before the pojoization operation (for example to automate the definition of my own handlers in the manifest). So all fields and methods should be protected instead of private and a new mechanism should be add in order to allow to manipulate cacheable metadata easily. I have attached a patch to fix this issue if the extensibility of the plugin is acceptable. -- 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-3837) PojoizationPlugin should be more extensible
[ https://issues.apache.org/jira/browse/FELIX-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542903#comment-13542903 ] Jérémy Cazaux commented on FELIX-3837: -- Yes, as you have added the possibility to modify the component definition before the component(=factory) creation at runtime, this feature is great and will be really useful for a lots of peoples. However, just from my personal point of view, I always prefer to make a feature at compile time rather than at runtime (it's always cheaper) if the feature is really similar (like this one). I think it could be a good thing to add the possibility to modify elments metadata either at compile time or at runtime. After what, it'll be to the user to determine if he prefers to modify elements metadata at compile time or at runtime. PojoizationPlugin should be more extensible --- Key: FELIX-3837 URL: https://issues.apache.org/jira/browse/FELIX-3837 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Jérémy Cazaux Attachments: 0001-PojoizationPlugin-should-be-more-extensible.patch I would like to extend Pojoization plugin without duplication of code in order to manipulate metadata elements from the CacheableMetadataProvider object just before the pojoization operation (for example to automate the definition of my own handlers in the manifest). So all fields and methods should be protected instead of private and a new mechanism should be add in order to allow to manipulate cacheable metadata easily. I have attached a patch to fix this issue if the extensibility of the plugin is acceptable. -- 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-3835) Cannot get from PojoMetadata, MethodMetadata object of an inherited method of an iPOJO instance.
[ https://issues.apache.org/jira/browse/FELIX-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542906#comment-13542906 ] Jérémy Cazaux commented on FELIX-3835: -- Yes but maybe inheritance could be support in the manipulator. From a user point of view, it's wierd that we could add callback to inherit methods but we can't introspect them with the iPOJO api. Maybe this could be a new feature ? (I personally think that all methods should be added except methods of the super java class). Cannot get from PojoMetadata, MethodMetadata object of an inherited method of an iPOJO instance. Key: FELIX-3835 URL: https://issues.apache.org/jira/browse/FELIX-3835 Project: Felix Issue Type: Bug Components: iPOJO Reporter: Jérémy Cazaux Cannot get from org.apache.felix.ipojo.parser.PojoMetadata, MethodMetadata object of an inherited method of an iPOJO instance (it looks like that inherited methods are not store in the « manipulation » element of the MANIFEST). MethodMetadata method = getPojoMetadata().getMethod(name); Here method is null. As a result on my own iPOJO handler, I cannot register an interceptor on inherited methods. After that, I also got an NPE when I called the register method of the InstanceManager. java.lang.NullPointerException at org.apache.felix.ipojo.InstanceManager.register(InstanceManager.java:987) -- 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-3837) PojoizationPlugin should be more extensible
[ https://issues.apache.org/jira/browse/FELIX-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542931#comment-13542931 ] Guillaume Sauthier commented on FELIX-3837: --- I understand your POV, I was just wondering how much we want to have 2 ways to do the same thing ? BTW, the compile time way is still harder to use (you'll have to both extends the PojoizationPlugin and write your MetadataManipulator). I'm not sure how we could do something easier for the user. For the runtime way, you just have to write a transformer (equivalent to your MetadataManipulator). PojoizationPlugin should be more extensible --- Key: FELIX-3837 URL: https://issues.apache.org/jira/browse/FELIX-3837 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Jérémy Cazaux Attachments: 0001-PojoizationPlugin-should-be-more-extensible.patch I would like to extend Pojoization plugin without duplication of code in order to manipulate metadata elements from the CacheableMetadataProvider object just before the pojoization operation (for example to automate the definition of my own handlers in the manifest). So all fields and methods should be protected instead of private and a new mechanism should be add in order to allow to manipulate cacheable metadata easily. I have attached a patch to fix this issue if the extensibility of the plugin is acceptable. -- 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-3837) PojoizationPlugin should be more extensible
[ https://issues.apache.org/jira/browse/FELIX-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13543103#comment-13543103 ] Jérémy Cazaux commented on FELIX-3837: -- 2 ways to do globally the same thing in two different phases (compile runtime). With the runtime way, a new service will be registered in the OSGi registry just to manipulate metadata before factories creation (more expensive at runtime). The main advantage of the runtime way is that if our own iPOJO handler and a transformer which automate definition of this handler are not included in a profil of an OSGi server then all others factories can still be valid and can instantiate new instances easily (the handler will not be added in the component definition). However the runtime way imply that metadata modifications will be applied to all factories (and not just a group of factories). So that remains to be seen if we want two ways to manipulate metadata elements. PojoizationPlugin should be more extensible --- Key: FELIX-3837 URL: https://issues.apache.org/jira/browse/FELIX-3837 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Jérémy Cazaux Attachments: 0001-PojoizationPlugin-should-be-more-extensible.patch I would like to extend Pojoization plugin without duplication of code in order to manipulate metadata elements from the CacheableMetadataProvider object just before the pojoization operation (for example to automate the definition of my own handlers in the manifest). So all fields and methods should be protected instead of private and a new mechanism should be add in order to allow to manipulate cacheable metadata easily. I have attached a patch to fix this issue if the extensibility of the plugin is acceptable. -- 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-3838) [DS] Race condition in ImmediateComponentHolder
[
https://issues.apache.org/jira/browse/FELIX-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Glenn Marcy updated FELIX-3838:
---
Attachment: felix-scr.89998-patch.txt
Attached is a patch with changes for two files:
1) BundleComponentActivator
The changes here are only to add LOG_DEBUG messages which were used to help
understand what was happening in the thread which would call enableComponents.
These were a help in tracking down the bug so wanted to make them available in
case they were helpful to others.
2) ImmediateComponentHolder
These changes contain a fix for the defect. The basic issue was that while
there were synchronized ( m_components ) blocks within the code, they were only
protecting access to that field at a very fine grained level. The changes
expand the scope of such blocks to account for the fact that changes to that
map also need to be consistent with changes to the m_enabled and
m_singleComponent fields as well.
[DS] Race condition in ImmediateComponentHolder
---
Key: FELIX-3838
URL: https://issues.apache.org/jira/browse/FELIX-3838
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Affects Versions: scr-1.6.2
Reporter: Glenn Marcy
Attachments: felix-scr.89998-patch.txt
There is a race condition where one thread is running the
BundleComponentActivator
and calling enableComponents on the ImmediateComponentHolder when another
thread
is running that has called configurationUpdated. The first thread is
executing
this:
m_enabled = true;
final ImmediateComponentManager[] cms = getComponentManagers( false );
...
for ( ImmediateComponentManager cm : cms )
{
cm.enable( async );
}
The second thread is executing this:
// enable the component if it is initially enabled
if ( m_enabled getComponentMetadata().isEnabled() )
{
newIcm.enable( false );
...
}
// store the component in the map
putComponentManager( pid, newIcm );
The failing sequence is this:
The second thread executes the test of m_enabled and it is false, so it will
not
enable the component manager expecting that it will be enabled by
enableComponents
later when it is called. The first thread then sets m_enabled to true and
gets a
copy of the entries in the map of component managers in order to enable them.
The
second thread puts the component manager into that map, but after the first
thread
has already made a copy of the managers in that map, so the component manager
the
second thread created will not be enabled at all.
--
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
Metatype Service - OptionalAttributes - extra XML attributes with namespace support
Hi I intend to use extra (optional) XML attributes with the Metatype Service. For this purpose I examined the Felix metatype service implementation and found the class org.apache.felix.metatype.OptionalAttributes, which is extended by AD, OCD, ... . But unluckily this class is neither inherited by LocalizedObjectClassDefinition nor by LocalizedAttributeDefinition, which makes it quite useless for the moment. Another Problem is that OptionalAttributes does not support XML namespaces for the attribute names. The underlying Map should use something like javax.xml.namespace.QName as key and not just the name of the attribute (String). Note, XML namespace support is crucial as extra XML attribute have to be in a different (##other) namespace (see Metatype Service Specifiaction (Version 1.2), section 105.9 XML Schema). The above observations lead me to the following question: 1. Is it still a requirement for Felix subprojects to avoid dependencies on packages like java.xml.** and rely on kxml2 instead? a. If so, then I could try create a patch for metatype service which will add support for extra XML attributes (including XML namespace support but not using javax.xml.namespace.QName), so that extra XML attributes could be retrieved from AD, OCD, ..., LocalizedObjectClassDefinition and LocalizedAttributeDefinition instances. b. If not, then I could try to create a similar patch as described above (a) but using javax.xml.namespace.QName instead. Note, the class javax.xml.namespace.QName is part of JavaSE since version 1.5 older versions as well as JavaME do not contain that class. Alex
