[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 > ). 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-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-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-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-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
[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
