[jira] [Resolved] (FELIX-3400) Nullpointer in autoconfprocessor for invalid metatype files
[ https://issues.apache.org/jira/browse/FELIX-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3400. - Resolution: Fixed Applied the patch. Nullpointer in autoconfprocessor for invalid metatype files --- Key: FELIX-3400 URL: https://issues.apache.org/jira/browse/FELIX-3400 Project: Felix Issue Type: Bug Components: Deployment Admin Affects Versions: autoconf-rp-0.1.0 Reporter: Bram de Kruijff Assignee: Marcel Offermans Priority: Minor Attachments: FELIX-3400-validate.patch Ran into trouble when I was feeding autoconf some, according to spec, invalid metatype files. MetadataReader does not catch them and AutoconfProcessor subsequently runs into nullpointers. Patch with basic additional validation checks attached for reference. -- 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-3338) Add support for optional attributes in the MetaDataReader as defined in the XML schema for metatype
[ https://issues.apache.org/jira/browse/FELIX-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3338. - Resolution: Fixed Fix Version/s: metatype-1.0.6 Implemented support in the relevant objects. You can now get a list of optional attributes for such objects. Add support for optional attributes in the MetaDataReader as defined in the XML schema for metatype --- Key: FELIX-3338 URL: https://issues.apache.org/jira/browse/FELIX-3338 Project: Felix Issue Type: Improvement Components: Metatype Service Affects Versions: metatype-1.0.4 Reporter: Marcel Offermans Assignee: Marcel Offermans Fix For: metatype-1.0.6 If you look at the metatype spec, 105.8 shows the XML schema for metatype. We have a parser for it called MetaDataReader, and it basically converts the XML file into a tree of Java objects (MetaData and related). The schema, in several locations, allows you to use optional attributes (scan the schema for anyAttribute /). Our parser currently does not have a way to read such attributes though, but it should! :) -- 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-3243) Autoconf does not recognize non-local non-factory OCDs
[
https://issues.apache.org/jira/browse/FELIX-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Offermans resolved FELIX-3243.
-
Resolution: Fixed
Patch applied, thanks Bram.
Autoconf does not recognize non-local non-factory OCDs
--
Key: FELIX-3243
URL: https://issues.apache.org/jira/browse/FELIX-3243
Project: Felix
Issue Type: Bug
Components: Deployment Admin
Affects Versions: autoconf-rp-0.1.0
Reporter: Bram de Kruijff
Assignee: Marcel Offermans
Attachments: autoconf_isFactoryConfig.patch
Small bug means this this never worked:
{code}
private boolean isFactoryConfig(Designate designate) {
String factoryPid = designate.getFactoryPid();
return (factoryPid != null || !.equals(factoryPid));
}
{code}
--
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-3272) Add property to allow foreign resource processors
[ https://issues.apache.org/jira/browse/FELIX-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3272. - Resolution: Fixed Makes sense to provide this as an option. Thanks for the patch, I just applied it. Add property to allow foreign resource processors - Key: FELIX-3272 URL: https://issues.apache.org/jira/browse/FELIX-3272 Project: Felix Issue Type: Improvement Components: Deployment Admin Affects Versions: deploymentadmin-0.9.0 Reporter: Angelo van der Sijpt Assignee: Marcel Offermans Attachments: FELIX-3272.patch DeploymentAdmin is built in such a way, that a deployment package is self-contained. However, in my case, I want to use a ResourceProcessor that is already on the system to process a configuration resource; if I do this, this will give me a DeploymentException.CODE_FOREIGN_CUSTOMIZER. Just like system property org.apache.felix.deploymentadmin.stopunaffectedbundle can customize the behavior of deployment admin, I propose a new property: org.apache.felix.deploymentadmin.allowforeigncustomizers , which allows ResourceProcessors that are already on the system to process resources in a deployment package. This should not be default behavior, so a system property should be in order. I will attach a patch for this shortly. -- 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-3292) Allow passing of resource properties to a resource handler for use with resource adapters.
[ https://issues.apache.org/jira/browse/FELIX-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3292. - Resolution: Fixed Resolving the issue after committing the patch. Xander, please review if you agree with the small changes I made while applying the patch. Allow passing of resource properties to a resource handler for use with resource adapters. -- Key: FELIX-3292 URL: https://issues.apache.org/jira/browse/FELIX-3292 Project: Felix Issue Type: Improvement Components: Dependency Manager Reporter: Xander Uiterlinden Assignee: Marcel Offermans Labels: patch Attachments: resourceadapterpatch2.patch, resourcepatch.patch Currently we're using the dependency manager in our project. A feature we extensively use is the resource adapter. The resource adapter service gets access to a resource through the abstraction of a URL. This is a nice abstraction but raises challenges whenever an implementation requires more properties of the resource, e.g. the last modification date or the encoding. At the moment we're working our way around it by creating implementing a custom URLHandler. It would be nicer if the resource adapter could be provided with a set of optional properties. My suggestion would be to extend the added(URL resource) method of the ResourceHandler with an additional argument holding a untyped set of properties. When provided these will be injected into the resource adapter implementation. I'll attach a patch to this issue with the implementation of this feature. -- 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-3186) Adapter services do not get their adapted services transparently replaced when an aspect is added to them.
[ https://issues.apache.org/jira/browse/FELIX-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3186. - Resolution: Fixed Thanks for this extensive patch, Xander. As you can see from the commit log, I applied the patches with some changes, so it probably makes sense that you review my changes. Adapter services do not get their adapted services transparently replaced when an aspect is added to them. -- Key: FELIX-3186 URL: https://issues.apache.org/jira/browse/FELIX-3186 Project: Felix Issue Type: Bug Components: Dependency Manager Affects Versions: dependencymanager-3.0.0 Environment: mac-osx Reporter: Xander Uiterlinden Assignee: Marcel Offermans Labels: bug Fix For: dependencymanager-3.0.0 Attachments: AspectAdapterTest.java, adapteronsomethingwithaspectpatch.patch, adapteronsomethingwithaspecttestpatch.patch A service consumer consumes an adapter service. The adapter service adapts a service provider. An aspect is added to the service provider. This should not impact the service consumer. Expected behavior is transparent replacement of the service the adapter adapts with the aspect service. -- 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-3245) Autoconf handles metatype 1.1 cardinalty wrong
[ https://issues.apache.org/jira/browse/FELIX-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3245. - Resolution: Fixed Patch applied. Autoconf handles metatype 1.1 cardinalty wrong -- Key: FELIX-3245 URL: https://issues.apache.org/jira/browse/FELIX-3245 Project: Felix Issue Type: Bug Components: Deployment Admin Affects Versions: autoconf-rp-0.1.0 Reporter: Bram de Kruijff Assignee: Marcel Offermans Attachments: autoconf_Cardinality.patch According to 105.13.2.12 in the R42 compendium spec cardinality is interpreted as: x = Integer.MIN_VALUE no limit, but use Vector x 0 -x = max occurrences, store in Vector x 0 x = max occurrences, store in array [] x = Integer.MAX_VALUE no limit, but use array [] x = 0 1 occurrence required This is not what happens in autoconf 0.1. I'll attach a small patch that should be self-expl. -- 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-3270) Deployment admin incorrectly takes snapshots of bundle data areas
[ https://issues.apache.org/jira/browse/FELIX-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3270. - Resolution: Fixed Fixed. Deployment admin incorrectly takes snapshots of bundle data areas - Key: FELIX-3270 URL: https://issues.apache.org/jira/browse/FELIX-3270 Project: Felix Issue Type: Bug Components: Deployment Admin Affects Versions: deploymentadmin-0.9.0 Reporter: Marcel Offermans Assignee: Marcel Offermans The deployment admin implementation relies on a SnapshotCommand to make snapshots of bundle data areas. However, dus to a mistake in the store() method, these snapshots don't work. The method incorrectly invokes storeRecursive(). We actually ran into this issue because we saw an update deployment fail (hanging in this method because it managed to create an infinity copy). storeRecursive(target, ... - storeRecursive(source, ... -- 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-3264) Dependency manager shell should not print the state of optional dependencies when not all required ones are available
[ https://issues.apache.org/jira/browse/FELIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3264. - Resolution: Fixed Committed a fix for this. Dependency manager shell should not print the state of optional dependencies when not all required ones are available - Key: FELIX-3264 URL: https://issues.apache.org/jira/browse/FELIX-3264 Project: Felix Issue Type: Improvement Components: Dependency Manager Affects Versions: dependencymanager-3.0.0 Reporter: Marcel Offermans Assignee: Marcel Offermans Internally, the dependency manager only starts listening to optional dependencies once all required ones are available. That means that optional dependencies will always be listed as unavailable in that scenario. That looks somewhat funny though: a required dependency to A that is available might also be shown as an optional one to A in a different component, and it might seem unavailable there. The fix is to not print the state of (optional) dependencies if they have not been started yet. -- 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-3218) ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services.
[ https://issues.apache.org/jira/browse/FELIX-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3218. - Resolution: Fixed Patch applied. ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services. - Key: FELIX-3218 URL: https://issues.apache.org/jira/browse/FELIX-3218 Project: Felix Issue Type: Improvement Components: Dependency Manager Environment: MacOS Snow Leopard. Reporter: Xander Uiterlinden Assignee: Marcel Offermans Attachments: ServiceTracker.patch ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services. The ServiceTracker.setInitial() implementation has a nested loop causing performance issues, e.g. quatratic lookup of service properties. -- 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-3042) [PATCH] Add a convenience clear() method on DependencyManager
[ https://issues.apache.org/jira/browse/FELIX-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3042. - Resolution: Fixed I agree that this patch is an improvement. Moving the method makes a lot of sense and improves the use case of directly working with a DependencyManager. [PATCH] Add a convenience clear() method on DependencyManager - Key: FELIX-3042 URL: https://issues.apache.org/jira/browse/FELIX-3042 Project: Felix Issue Type: Improvement Components: Dependency Manager Reporter: Jeremias Maerki Assignee: Marcel Offermans Priority: Minor Labels: patch Attachments: dependencymanager-clear-patch.diff I recently stumbled over DependencyManager and immediately found it very nice to work with. I have some cases where I instantiate my own DependencyManagers (ex. one per monitored bundle in a SynchronousBundleListener). Now that I found myself copy/pasting a method that removes all components from a DependencyManager, I modified DM to add a clear() method on DependencyManager. Basically I moved the code from DependencyActivatorBase. I hope you find this patch useful. -- 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-3201) Offer more functional callback methods for services that have aspects on them.
[ https://issues.apache.org/jira/browse/FELIX-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3201. - Resolution: Fixed Reviewed and committed both patches. Offer more functional callback methods for services that have aspects on them. -- Key: FELIX-3201 URL: https://issues.apache.org/jira/browse/FELIX-3201 Project: Felix Issue Type: Improvement Components: Dependency Manager Environment: n/a Reporter: Xander Uiterlinden Assignee: Marcel Offermans Labels: features Attachments: dm-core-patch.txt, dm-test-patch.txt When programmatically adding service dependencies using the Apache felix dependency manager there are two ways to have the component brought its dependencies when they come available. These are the following: - have the service injected in the component; this is usually sufficient for cases where there's only one service expected to satisfy the dependency (1-to-1) . - explicitly specify callback methods; callbacks can be used when there might be more than one service satisfying the dependency (1-to-n). When a dependency is marked optional, the callback method also helps to determine when the dependency actually became satisfied. When using callback methods with the dependency manager you can specify the following callbacks: - added; gets called when the service required has become available. - changed; gets called when the service properties of a added required service have changed. - removed; gets called when the service required has become unavailable. At first these callbacks seem pretty simple. Just add the service to the component's internal administration on the added callback and remove it from the administration whenever the removed callback is called. But, the dependency manager also supports the concept of aspect services which make using the callback method in a correct way a bit more difficult. Aspect services are services that are put on top of another service while still implementing the original service's interface. They allow you to implement cross-cutting functional requirements. In the OSGi service registry aspect services are individual services just like 'regular' singleton services. When using callback methods for dependencies a component is informed of the add/remove of an aspect service, just like it is when a 'regular' service is added/removed. When using injection for dependencies the aspect is transparently injected. The callbacks also handling aspect services the same way as 'regular' services makes it difficult for a component developer to correctly implement these callbacks. For example take the following scenario: Component A expresses a service dependency to Service B. Without any aspects in the container the following callbacks would be added on Component A. added(Service B) But whenever there's an aspect running on top of Service B, the order of callbacks would be as follows: added(Service B) added(Service B aspect) removed(Service B) When backed by a typical HashMap administration this would result in: put(B.id, B) put(B.id, B) remove(B.id) This sequence would result in an empty Map, which is not a desirable situation. In order to ease the dependency handling an additional callback method is needed which hides the complexity as described above and translates the callbacks to the following more functional callbacks: added; called when the service required has become available. swapped; called when the service required needs to be replaced due to add or removal of an aspect. This to be sure the component uses the aspect that's on top of the aspect chain for the required service. changed; called when the service properties of an added required service have changed. removed; called when the service required has become unavailable. With these callbacks a developer does not have to worry about the possible sequences in which added/removed can occur. -- 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-1828) Mistake in code of the class UpdateCommand
[ https://issues.apache.org/jira/browse/FELIX-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-1828. - Resolution: Fixed Mistake in code of the class UpdateCommand -- Key: FELIX-1828 URL: https://issues.apache.org/jira/browse/FELIX-1828 Project: Felix Issue Type: Bug Components: Deployment Admin Reporter: Pavel Kodl Assignee: Marcel Offermans Priority: Critical On row 70 should be : Bundle bundle = targetPackage.getBundle(bundleInfo.getSymbolicName()); instead of: Bundle bundle = source.getBundle(bundleInfo.getSymbolicName()); -- 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-3072) Bad manifest content on Import-package part
[ https://issues.apache.org/jira/browse/FELIX-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3072. - Resolution: Not A Problem See comment. Bad manifest content on Import-package part --- Key: FELIX-3072 URL: https://issues.apache.org/jira/browse/FELIX-3072 Project: Felix Issue Type: Bug Components: Deployment Admin Affects Versions: deploymentadmin-0.9.0 Environment: linux (archlinux Reporter: Thierry D. Priority: Minor Labels: build The Import-Package parameter of the bundle's manifest file should not contain org.osgi.service.deploymentadmin packages classes because it embeds these classes. this bug generates ClassNotFound exception when you use the webconsole bundle felix plugin. original parameter value : Import-Package: org.apache.felix.dm;version=[3.0,4),org.osgi.framework;version=[1.5,2),org.osgi.service.deploymentadmin;version=1.1,2),org.osgi.service.deploymentadmin.spi;version=[1.0,2),org.osgi.service.event;version=[1.2,2),org.osgi.service.log;version=1.3,2),org.osgi.service.packageadmin;version=[1.2,2) suggested parameter value (fix ?): Import-Package: org.apache.felix.dm;version=[3.0,4),org.osgi.framework;version=[1.5,2),org.osgi.service.event;version=[1.2,2), org.osgi.service.log;version=[1.3,2),org.osgi.service.packageadmin;version=[1.2,2) unfortunatelly I am not able to provide a fix because I dont know how the osgi bunble maven plugin work exactly. I hope this will help you regards -- 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
