[jira] [Created] (FELIX-3359) Turn around to avoid to use the split verifier on Java 7
Turn around to avoid to use the split verifier on Java 7 Key: FELIX-3359 URL: https://issues.apache.org/jira/browse/FELIX-3359 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-manipulator-1.8.2 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-manipulator-1.8.4 -- 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-3358) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations
Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations Key: FELIX-3358 URL: https://issues.apache.org/jira/browse/FELIX-3358 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Environment: Eclipse Indigo or newer Reporter: Robert Munteanu With the recent changes brought to the Maven Eclipse integration, any unknown [0] plugins are flagged as problematic and an error is reported in the pom.xml . Typically this is solved by writing a thin integration layer between the Eclipse integration and the Maven plugin [1] or by instructing Eclipse to ignore some plugin executions. The new 1.1 version of the m2eclipse plugin will allow a Maven plugin ( with no links to Eclipse plugin development ) to use an enhanced API to become compatible out of the box with the Eclipse integration [2] . The maven-scr-plugin should take advantage of these new APIs to allow seamless integration with Eclipse. [0]: http://wiki.eclipse.org/M2E_plugin_execution_not_covered [1]: http://wiki.eclipse.org/M2E/Extension_Development [2]: http://wiki.eclipse.org/M2E_compatible_maven_plugins -- 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-3329) Allow the autoconf resource processor to defer the setting of the configuration until ConfigurationAdmin is available
[ https://issues.apache.org/jira/browse/FELIX-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211892#comment-13211892 ] Marcel Offermans commented on FELIX-3329: - 1) I totally agree this can and should be improved and created a separate issue for it: FELIX-3357 2) The patch looks good. I'll further review and apply it. 3) Let me start by stating that the primary goal of this project (autoconf) is to implement the Auto Configuration Specification (115) in the compendium. In Amdatu there is a plugin for File Install that tries to emulate a deployment session so it can re-use this bundle to install configurations, but as discussed in http://jira.amdatu.org/jira/browse/AMDATU-558 there are mismatches between what File Install does and what Deployment Admin does. I don't think it's fair though to state that via a File Install extension, this has now also become a use case of this project when the goal of that extension was to emulate a deployment session. > The fundamental issue with discarding updates at the end of a > deployment session if rather arbitrary. It covers the use case in the > description of this issue where DeploymentAdmin stops the > ConfigurationAdmin bundle during deployment, then starts it again AND > it synchronously registers its service during start. If for whatever > reason the ConfigurationAdmin is deferred asynchronously this > mechanism will fail in a non deterministic way. It couples bundles > and service lifecycle and places requirements on the implementation > of the ConfigurationAdmin bundle. To set the record straight, the use case in the description of this issue is all about the problem of the initial deployment, where you start out with an empty system and have a deployment package that contains an implementation of Configuration Admin, this resource processor and some configuration resources. That is a use case that is simply not covered by the spec, as discussed previously here: http://www.mail-archive.com/osgi-dev@mail.osgi.org/msg01934.html > Previously the AutoConfResourceProcessor would simply throw a > ResourceProcessorException when no ConfigurationAdmin was available > which, as explained in this issue, has severe limitations. If Configuration Admin already was available because it was somehow already deployed outside of the deployment package, there is no problem. Same goes for a scenario where it was already installed via an earlier deployment package (depending on the setting of the optional flag to not stop all bundles in a deployment package while doing the update). So this is really about the initial deployment. The question remains, how long should we defer configuration? > Thus deferring IMHO is a good option changing the > AutoConfResourceProcessor contract from "yes, the configuration is > valid and I have delivered the it" to "yes, the configuration is > valid and I will deliver it when the (appropriate) ConfigurationAdmin > shows up". To be honest I am not sure this is within the intent of > the specification which specifies the processor must create/delete > configurations in the commit(), but as we have use cases for this > behavior I am inclined to support defer when needed. Deferring the delivery is clearly beyond the spec. However, we only defer if there is no Configuration Admin available. If there is, the delivery will happing synchronously in the commit. > Thus, my concern is about the "before the end of the deployment > session" part. Effectively the contract is now "yes, the > configuration is valid and I will deliver the configuration when the > (appropriate) ConfigurationAdmin shows up before the end of the > deployment session OR ELSE I WILL SILENTLY DROP THEM". The spec dictates we cannot deliver the configurations before the commit. The spec also dictates that commit cannot fail, so in case Configuration Admin is not around at commit time, there is no other option but to silently fail. 114.8 step 14 even states (about exceptions during commit) that "Any exceptions should be logged as warnings, but must be ignored.". > Why and why > not defer indefinitely? It is true that deferring longer does not > guarantee delivery, but as long as AutoConfResourceProcessor honors > its contract maintaining configuration update order I think it's much > more robust. You can hardly blame AutoConfResourceProcessor for a > ConfigurationAdmin not showing up. > Concluding, IMHO defer is a good option but it should not be limited > to deployment session lifetime because that is not very robust and > does not cover use cases that exceed the deployment session. > Obviously, to support that AutoConfResourceProcessor would also have > to persist its state to survive restarts itself. Deferring updates indefinitely does not work in for example the following scenario: We start from scratch and install "dp-1" (depoyment package versio
[jira] [Created] (FELIX-3357) Improve
Improve Key: FELIX-3357 URL: https://issues.apache.org/jira/browse/FELIX-3357 Project: Felix Issue Type: Improvement Components: Deployment Admin Affects Versions: autoconf-rp-0.1.0 Reporter: Marcel Offermans The ambiguous use of "resource" throughout the code is rather confusing. First there is the "deployment resources" which are effectively representations of metadata files. Second there are the "autoconf resources" which are effectively representations of designates. So, for example the DropResource and DeleteResource tasks are entirely different beasts. I think some renaming could help future adventurers. -- 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-3355) Autoconf can't find Metatype service
[
https://issues.apache.org/jira/browse/FELIX-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211824#comment-13211824
]
Marcel Offermans commented on FELIX-3355:
-
I agree that we should fix the import, preferably whilst still keeping the
bundle self-contained. So that API package should be substitutable.
I do not agree it is reasonable to require MetaTypeService as that would
contradict the spec (115.3.4): "If the reference cannot be found in this file,
it must consult the Meta Type service (if present) for the bundle that is
associated with the PID that is configured.". To me the "if present" clearly
states that we must not require it.
> Autoconf can't find Metatype service
>
>
> Key: FELIX-3355
> URL: https://issues.apache.org/jira/browse/FELIX-3355
> Project: Felix
> Issue Type: Bug
> Components: Deployment Admin
>Affects Versions: autoconf-rp-0.1.0
>Reporter: Bram de Kruijff
>
> Although Autoconf appears to consult MetaTypeService to resolve OCDs in code
> it never will. This is caused by the fact that the bundle does not import
> org.osgi.service.metatype, but embeds it. Any actual MetaTypeService will not
> be assignable.
> The reason it doesn't fail is that the dependencymanager dependency is
> optional. As a result the AutoconfResourceProcessor operates against an
> injected NullObject. You never get any warning, but it simply never resolves
> OCDs.
> Besides fixing the import IMHO it would not be unreasnable to require
> MetaTypeService
> {code}
> Index: autoconf/pom.xml
> ===
> --- autoconf/pom.xml(revision 1245822)
> +++ autoconf/pom.xml(working copy)
> @@ -86,7 +86,7 @@
> Apache Felix AutoConf Resource
> Processor
> A customizer bundle that
> publishes a Resource Processor service that processes configuration resources
> shipped in a
> Deployment Package.
> Apache Software
> Foundation
> -
> org.apache.felix.deployment.rp.autoconf,
> org.apache.felix.metatype, org.apache.felix.metatype.internal.l10n, org.apach
> e.felix.metatype.internal, org.kxml2.io;-split-package:=merge-first,
> org.xmlpull.v1;-split-package:=merge-first,
> org.osgi.service.metatype;-split-package:=merge
> -first
> +
> org.apache.felix.deployment.rp.autoconf,
> org.apache.felix.metatype, org.apache.felix.metatype.internal.l10n, org.apach
> e.felix.metatype.internal, org.kxml2.io;-split-package:=merge-first,
> org.xmlpull.v1;-split-package:=merge-first
>
> org.osgi.service.deploymentadmin.spi;version="1.0"
>
> true
>
> org.osgi.deployment.rp.autoconf
> {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] [Commented] (FELIX-3356) Objectweb ASM Clashes with IPojo
[ https://issues.apache.org/jira/browse/FELIX-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211718#comment-13211718 ] Bob Ziuchkovski commented on FELIX-3356: Hmm...it looks like bnd is getting the manifest correct, in that it only shows org.apache.felix.ipojo.handlers.dependency as using org.objectweb.asm. However, it lists org.apache.felix.ipojo.architecture as using org.apache.felix.ipojo, which in turn is marked as using org.apache.felix.ipojo.handlers.dependency, which uses org.objectweb.asm. I think the ipojo->ipojo.handlers.dependency use clause is probably coming from PrimitiveInstanceDescription.java. At a glance I don't see anything else that would cause ipojo.architecture to pull in wiring for org.objectweb.asm, but I am not 100% certain. > Objectweb ASM Clashes with IPojo > > > Key: FELIX-3356 > URL: https://issues.apache.org/jira/browse/FELIX-3356 > Project: Felix > Issue Type: Bug > Components: iPOJO >Reporter: Bob Ziuchkovski >Priority: Minor > > Ipojo automatically imports org.apache.felix.ipojo.architecture for bundles > that it manages, and org.apache.felix.ipojo.architecture is marked as using > org.objectweb.asm. This creates conflicts for any ipojo-managed bundle that > wishes to import and use a different objectweb asm version (i.e. 4.0) for > non-ipojo purposes. See the below output for an example: > Error executing command: Error starting bundles: > Unable to start bundle 107: Uses constraint violation. Unable to > resolve bundle revision test.service [107.0] because it is exposed to package > 'org.objectweb.asm' from bundle revisions org.objectweb.asm.all [98.0] and > org.apache.felix.ipojo [99.0] via two dependency chains. > Chain 1: > test.service [107.0] > import: > (&(osgi.wiring.package=org.objectweb.asm)(version>=4.0.0)(!(version>=5.0.0))) > | > export: osgi.wiring.package=org.objectweb.asm > org.objectweb.asm.all [98.0] > Chain 2: > test.service [107.0] > import: > (&(osgi.wiring.package=org.apache.felix.ipojo.architecture)(version>=1.8.0)) > | > export: osgi.wiring.package=org.apache.felix.ipojo.architecture; > uses:=org.objectweb.asm > export: osgi.wiring.package=org.objectweb.asm > org.apache.felix.ipojo [99.0] -- 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
