[jira] [Commented] (FELIX-3148) ipojo - auto handlers - issue in plugging the auto-handler to a particular component ( without making any changes in POJO component)
[ https://issues.apache.org/jira/browse/FELIX-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123665#comment-13123665 ] sadishkumar commented on FELIX-3148: Hi, Yes, the handler knows to which component's instances it will be plugged. ipojo - auto handlers - issue in plugging the auto-handler to a particular component ( without making any changes in POJO component) Key: FELIX-3148 URL: https://issues.apache.org/jira/browse/FELIX-3148 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: iPOJO-1.8.0 Reporter: sadishkumar Labels: features To avoid the problem of attaching the Auto-handlers (which are listed in the system property) to all the component's instances unnecessarily. To make it more specific dynamic to particular components, The auto-handlers can have annotations like this @handle (component-1, component-2,...). This ipojo annotations can be used by handlers to be automatically plugged into instances of the specific list of components given as parameter in the bracket (here for example: component-1, component-2..;etc. are component names). -- 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-3087) Given invalid value, but the property isn't invalid.
[ https://issues.apache.org/jira/browse/FELIX-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123689#comment-13123689 ] Felix Meschberger commented on FELIX-3087: -- In Rev. 1180605: * Fix wrong Character/Char type conversion * add unit tests * refactor value conversion to do it during validation, which allows to fail value conversion on a component-level instead of a descriptor file level Given invalid value, but the property isn't invalid. Key: FELIX-3087 URL: https://issues.apache.org/jira/browse/FELIX-3087 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Yasuhiro Kawame Assignee: Felix Meschberger Given the following XML, the value of the property will be invalid. But this property is a valid property, with a value of char 'a'. ?xml version=1.0 encoding=UTF-8? scr:component xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0; implementation class=DummyClass / property name=test.property.Character type=Character value=ab / /scr:component -- 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] [Resolved] (FELIX-3087) Given invalid value, but the property isn't invalid.
[ https://issues.apache.org/jira/browse/FELIX-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-3087. -- Resolution: Fixed Fix Version/s: scr-1.6.2 This works and the issue can be resolved. Given invalid value, but the property isn't invalid. Key: FELIX-3087 URL: https://issues.apache.org/jira/browse/FELIX-3087 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Yasuhiro Kawame Assignee: Felix Meschberger Fix For: scr-1.6.2 Given the following XML, the value of the property will be invalid. But this property is a valid property, with a value of char 'a'. ?xml version=1.0 encoding=UTF-8? scr:component xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0; implementation class=DummyClass / property name=test.property.Character type=Character value=ab / /scr:component -- 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-3039) SCR cleans up delayed service components too aggressively
[ https://issues.apache.org/jira/browse/FELIX-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123732#comment-13123732 ] Felix Meschberger commented on FELIX-3039: -- Actually the specification states that delayed components have to be deactivated and destroyed if not used any longer: If the service registered by a component configuration becomes unused because there are no more bundles using it, then SCR should deactivate that component configuration. This allows SCR implementations to eagerly reclaim activated component configurations. (112.5.4, Delayed Components) While should of course is not a requirement, I understand it as a strong recommendation. On the other hand, since this still allows the implementation to keep the components alive, it might make sense to keep them alive. Will consider an option ds.dontDisposeInstances as follows: * default: false -- to implement the spec recommendation * base (static) configuration by framework property (BundleContext.getProperty) * dynamic configuration through Configuration Admin (if available) SCR cleans up delayed service components too aggressively - Key: FELIX-3039 URL: https://issues.apache.org/jira/browse/FELIX-3039 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Reporter: Neil Bartlett Priority: Minor In the case of an ordinary delayed service component, SCR immediately deactivates and destroys the component when its service is released by the consumer. In cases where a consumer occasionally binds and invokes the service (e.g. EventAdmin) this can cause the component to be continuously destroyed and recreated. Note that Equinox's DS offers a little more control, we can choose either to immediately clean up or never clean up (and the default is never). This is still not very satisfactory though. I think ideally there should be a configurable timeout, so that a component will be cleaned up only if it is not used for some time. I also think the default should be quite long, e.g. many minutes. -- 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-2895) Allow the use of a property to tell SCR to always discover Service Component files even if there's no wildcard in the name
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123740#comment-13123740 ] Felix Meschberger commented on FELIX-2895: -- Thinking about it I come to the conclusion, that using getResource is really wrong. So I think we should go the full length and completely remove the use of getResource Allow the use of a property to tell SCR to always discover Service Component files even if there's no wildcard in the name -- Key: FELIX-2895 URL: https://issues.apache.org/jira/browse/FELIX-2895 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Reporter: Justin Edelson Attachments: FELIX-2895-fmeschbe.patch, FELIX-2895.patch, FELIX-2895_take2.patch The current version of SCR will use the API method getResource() to get the service component descriptor if the Service-Component header does not contain a wildcard. This precludes the discovery of DS components in attached fragment bundles. From the DS spec: Section 112.4: Component descriptions are defined in XML documents contained in a bundle and any attached fragments. Section 112.4.1: The last component of each path in the Service-Component header may use wildcards so that Bundle.findEntries can be used to locate the XML document within the bundle and its fragments A Service-Component manifest header specified in a fragment is ignored by SCR. However, XML documents referenced by a bundle's Service-Component Note the use of the word may in the first sentence. It does not say that findEntries() should/must *only* be used if there's a wildcard. As such, I believe this is within the spec, albeit not backwards compatible which is why I'm proposing to use a framework property. -- 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] [Resolved] (FELIX-2895) Allow the use of a property to tell SCR to always discover Service Component files even if there's no wildcard in the name
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2895. -- Resolution: Fixed Fix Version/s: scr-1.6.2 Assignee: Felix Meschberger Removed the use of getResource to find the descriptor altogether thus also not implementing the new configuration property. Done in Rev. 1180676. Allow the use of a property to tell SCR to always discover Service Component files even if there's no wildcard in the name -- Key: FELIX-2895 URL: https://issues.apache.org/jira/browse/FELIX-2895 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Reporter: Justin Edelson Assignee: Felix Meschberger Fix For: scr-1.6.2 Attachments: FELIX-2895-fmeschbe.patch, FELIX-2895.patch, FELIX-2895_take2.patch The current version of SCR will use the API method getResource() to get the service component descriptor if the Service-Component header does not contain a wildcard. This precludes the discovery of DS components in attached fragment bundles. From the DS spec: Section 112.4: Component descriptions are defined in XML documents contained in a bundle and any attached fragments. Section 112.4.1: The last component of each path in the Service-Component header may use wildcards so that Bundle.findEntries can be used to locate the XML document within the bundle and its fragments A Service-Component manifest header specified in a fragment is ignored by SCR. However, XML documents referenced by a bundle's Service-Component Note the use of the word may in the first sentence. It does not say that findEntries() should/must *only* be used if there's a wildcard. As such, I believe this is within the spec, albeit not backwards compatible which is why I'm proposing to use a framework property. -- 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-3151) Activating bundles in seperate thread
Activating bundles in seperate thread - Key: FELIX-3151 URL: https://issues.apache.org/jira/browse/FELIX-3151 Project: Felix Issue Type: Improvement Components: Framework Reporter: Andie Similon Priority: Minor I was wondering about the following thing and I'd like one of the developers opinion about it. Is there a reason why bundles are not started in a seperate thread. I was wondering this because if a bundle developer creates a bundle that ends up in an infinite loop or something in the bundle start method, it will block the entire system. Is there a reason why the bundles aren't started in a seperate thread? -- 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-3084) Submission of source code for review of software grant for lightweight HTTP service implementation.
[ https://issues.apache.org/jira/browse/FELIX-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123814#comment-13123814 ] Ken Gilmer commented on FELIX-3084: --- Just checking, anything I need to do for this? It's not clear to me from the review page what the current status is... Submission of source code for review of software grant for lightweight HTTP service implementation. --- Key: FELIX-3084 URL: https://issues.apache.org/jira/browse/FELIX-3084 Project: Felix Issue Type: Task Components: HTTP Service Reporter: Ken Gilmer Labels: software Attachments: GRANT.pdf, org.apache.felix.http.lightweight-src.tar.gz This issue is created as part of the process outlined in the Contributing Source Code Felix page as suggested by Richard Hall in issue FELIX-538[1]. The source code attached[6] to this issue is an implementation of the OSGi HTTP Service specification version 1.2. The code is based on Richard's original server which is also referenced in FELIX-538, and the remaining code was developed by me, with the exception of a few classes which were adapted from existing Felix sources[2]. Design constraints for this project were backwards compatibility, simplicity, and size. The code base consists of 23 Java files in 3 packages. The source is divided into osgi, server, and servlet packages according to the primary purpose of the class, and interfaces are utilized to keep the three domains fairly isolated[3]. The minimal compiled jar which does not include the servlet API or OSGi API currently is 41Kb, and the dependency-free jar with all necessary APIs is 125Kb. An Ant script is provided that will build the jars and a CI server is also available for binary builds[4] and javadocs[5]. In terms of features the server doesn't offer: -HTTPS -Authentication -Cookie support -Session support In addition several aspects of the Servlet implementation have not been tested including: -Multipart POST -DELETE -PUT -Non-default character encodings And as of the submission several Servlet API methods are unimplemented in (all unimplemented methods throw org.apache.felix.http.lightweight.servlet.UnimplementedAPIException): -HttpServletRequest(Impl) -HttpServletResponse(Impl) However the core functionality has been implemented and tested and the Felix Web Admin application can be hosted with this HTTP Service implementation. I plan in continuing to use the service in personal and professional projects and would be happy to continue to add unimplemented features and maintain the code base as a Felix committer. Thanks! Ken Gilmer 1: https://issues.apache.org/jira/browse/FELIX-538 2: /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/DefaultContextImpl.java, /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/Logger.java 3: /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationHandler.java, /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationResolver.java 4: https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/ 5: https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/javadoc/ 6: MD5SUM 47580996a8c364890518222494d4d26b org.apache.felix.http.lightweight-src.tar.gz -- 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-3084) Submission of source code for review of software grant for lightweight HTTP service implementation.
[ https://issues.apache.org/jira/browse/FELIX-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123815#comment-13123815 ] Richard S. Hall commented on FELIX-3084: No, nothing to do. It is done and I'll wrap it up this coming week. I was at JavaOne last week, so I didn't really have much time to do other things. Submission of source code for review of software grant for lightweight HTTP service implementation. --- Key: FELIX-3084 URL: https://issues.apache.org/jira/browse/FELIX-3084 Project: Felix Issue Type: Task Components: HTTP Service Reporter: Ken Gilmer Labels: software Attachments: GRANT.pdf, org.apache.felix.http.lightweight-src.tar.gz This issue is created as part of the process outlined in the Contributing Source Code Felix page as suggested by Richard Hall in issue FELIX-538[1]. The source code attached[6] to this issue is an implementation of the OSGi HTTP Service specification version 1.2. The code is based on Richard's original server which is also referenced in FELIX-538, and the remaining code was developed by me, with the exception of a few classes which were adapted from existing Felix sources[2]. Design constraints for this project were backwards compatibility, simplicity, and size. The code base consists of 23 Java files in 3 packages. The source is divided into osgi, server, and servlet packages according to the primary purpose of the class, and interfaces are utilized to keep the three domains fairly isolated[3]. The minimal compiled jar which does not include the servlet API or OSGi API currently is 41Kb, and the dependency-free jar with all necessary APIs is 125Kb. An Ant script is provided that will build the jars and a CI server is also available for binary builds[4] and javadocs[5]. In terms of features the server doesn't offer: -HTTPS -Authentication -Cookie support -Session support In addition several aspects of the Servlet implementation have not been tested including: -Multipart POST -DELETE -PUT -Non-default character encodings And as of the submission several Servlet API methods are unimplemented in (all unimplemented methods throw org.apache.felix.http.lightweight.servlet.UnimplementedAPIException): -HttpServletRequest(Impl) -HttpServletResponse(Impl) However the core functionality has been implemented and tested and the Felix Web Admin application can be hosted with this HTTP Service implementation. I plan in continuing to use the service in personal and professional projects and would be happy to continue to add unimplemented features and maintain the code base as a Felix committer. Thanks! Ken Gilmer 1: https://issues.apache.org/jira/browse/FELIX-538 2: /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/DefaultContextImpl.java, /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/Logger.java 3: /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationHandler.java, /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationResolver.java 4: https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/ 5: https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/javadoc/ 6: MD5SUM 47580996a8c364890518222494d4d26b org.apache.felix.http.lightweight-src.tar.gz -- 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
