[jira] Updated: (FELIX-1660) karaf should not hardcode the "system" location of its maven-like repository
[ https://issues.apache.org/jira/browse/FELIX-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated FELIX-1660: Attachment: FELIX-1660.diff simple patch that enables configuring the default internal repo location from "system" > karaf should not hardcode the "system" location of its maven-like repository > > > Key: FELIX-1660 > URL: https://issues.apache.org/jira/browse/FELIX-1660 > Project: Felix > Issue Type: Bug > Components: Karaf >Affects Versions: karaf-1.0.2 >Reporter: David Jencks > Attachments: FELIX-1660.diff > > > A lot of stuff in the karaf setup is configurable, but the directory in which > the maven-like bundle repo is located is not. For geronimo integration we'd > like to not surprise our users and use "repository" instead of "system". > I'm attaching a minimal patch to enable configuring this, I'll refine it if > the idea meets with approval. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1660) karaf should not hardcode the "system" location of its maven-like repository
karaf should not hardcode the "system" location of its maven-like repository Key: FELIX-1660 URL: https://issues.apache.org/jira/browse/FELIX-1660 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.2 Reporter: David Jencks A lot of stuff in the karaf setup is configurable, but the directory in which the maven-like bundle repo is located is not. For geronimo integration we'd like to not surprise our users and use "repository" instead of "system". I'm attaching a minimal patch to enable configuring this, I'll refine it if the idea meets with approval. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1659) Sigil build fails due to api incompatibility in ivy 2.0.0.beta2 which has been published into spring repo?
[ https://issues.apache.org/jira/browse/FELIX-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Savage closed FELIX-1659. --- Resolution: Fixed Fix Version/s: sigil-1.0.0 Assignee: David Savage locked down version for time being to 2.0.0 > Sigil build fails due to api incompatibility in ivy 2.0.0.beta2 which has > been published into spring repo? > -- > > Key: FELIX-1659 > URL: https://issues.apache.org/jira/browse/FELIX-1659 > Project: Felix > Issue Type: Bug > Components: Sigil >Reporter: David Savage >Assignee: David Savage > Fix For: sigil-1.0.0 > > > resolve: > [mkdir] Created dir: > /Users/dave/development/felix-trunk/sigil/ivy/resolver/build/deps > [ivy:resolve] [20090929204655] > org.apache#felix.sigil.common.obr;latest.integration > [ivy:resolve] [20090929204649] > org.apache#felix.sigil.common.osgi;latest.integration > [ivy:resolve] [20090929204651] > org.apache#felix.sigil.common.core;latest.integration > [ivy:resolve] downloading > http://repository.springsource.com/ivy/bundles/external/org.apache.ant/com.springsource.org.apache.ivy/2.0.0.beta2/com.springsource.org.apache.ivy-2.0.0.beta2.jar > ... > [ivy:resolve] [SUCCESSFUL ] > sigil#com.springsource.org.apache.ivy;2.0.0.beta2!com.springsource.org.apache.ivy.jar > (6934ms) > [ivy:retrieve] :: retrieving :: org.apache#felix.sigil.ivy.resolver [sync] > [ivy:retrieve] confs: [default] > [ivy:retrieve] 8 artifacts copied, 0 already retrieved (2623kB/279ms) > compile: > [mkdir] Created dir: > /Users/dave/development/felix-trunk/sigil/ivy/resolver/build/main-classes > [javac] Compiling 11 source files to > /Users/dave/development/felix-trunk/sigil/ivy/resolver/build/main-classes > [javac] > /Users/dave/development/felix-trunk/sigil/ivy/resolver/src/org/apache/felix/sigil/ivy/SigilParser.java:235: > cannot inherit from final > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser > [javac] static class DelegateParser extends XmlModuleDescriptorParser > [javac] ^ > [javac] > /Users/dave/development/felix-trunk/sigil/ivy/resolver/src/org/apache/felix/sigil/ivy/SigilParser.java:235: > XmlModuleDescriptorParser() has private access in > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser > [javac] static class DelegateParser extends XmlModuleDescriptorParser > [javac]^ > [javac] > /Users/dave/development/felix-trunk/sigil/ivy/resolver/src/org/apache/felix/sigil/ivy/SigilParser.java:555: > cannot find symbol > [javac] symbol : constructor > DefaultDependencyArtifactDescriptor(org.apache.ivy.core.module.descriptor.DefaultDependencyDescriptor,java.lang.String,java.lang.String,java.lang.String,,) > [javac] location: class > org.apache.ivy.core.module.descriptor.DefaultDependencyArtifactDescriptor > [javac] dd.addDependencyArtifact( module, new > DefaultDependencyArtifactDescriptor( dd, id, "jar", > [javac] ^ > [javac] > /Users/dave/development/felix-trunk/sigil/ivy/resolver/src/org/apache/felix/sigil/ivy/SigilResolver.java:288: > method does not override a method from its superclass > [javac] @Override > [javac] ^ > [javac] 4 errors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1659) Sigil build fails due to api incompatibility in ivy 2.0.0.beta2 which has been published into spring repo?
Sigil build fails due to api incompatibility in ivy 2.0.0.beta2 which has been published into spring repo? -- Key: FELIX-1659 URL: https://issues.apache.org/jira/browse/FELIX-1659 Project: Felix Issue Type: Bug Components: Sigil Reporter: David Savage resolve: [mkdir] Created dir: /Users/dave/development/felix-trunk/sigil/ivy/resolver/build/deps [ivy:resolve] [20090929204655] org.apache#felix.sigil.common.obr;latest.integration [ivy:resolve] [20090929204649] org.apache#felix.sigil.common.osgi;latest.integration [ivy:resolve] [20090929204651] org.apache#felix.sigil.common.core;latest.integration [ivy:resolve] downloading http://repository.springsource.com/ivy/bundles/external/org.apache.ant/com.springsource.org.apache.ivy/2.0.0.beta2/com.springsource.org.apache.ivy-2.0.0.beta2.jar ... [ivy:resolve] [SUCCESSFUL ] sigil#com.springsource.org.apache.ivy;2.0.0.beta2!com.springsource.org.apache.ivy.jar (6934ms) [ivy:retrieve] :: retrieving :: org.apache#felix.sigil.ivy.resolver [sync] [ivy:retrieve] confs: [default] [ivy:retrieve] 8 artifacts copied, 0 already retrieved (2623kB/279ms) compile: [mkdir] Created dir: /Users/dave/development/felix-trunk/sigil/ivy/resolver/build/main-classes [javac] Compiling 11 source files to /Users/dave/development/felix-trunk/sigil/ivy/resolver/build/main-classes [javac] /Users/dave/development/felix-trunk/sigil/ivy/resolver/src/org/apache/felix/sigil/ivy/SigilParser.java:235: cannot inherit from final org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser [javac] static class DelegateParser extends XmlModuleDescriptorParser [javac] ^ [javac] /Users/dave/development/felix-trunk/sigil/ivy/resolver/src/org/apache/felix/sigil/ivy/SigilParser.java:235: XmlModuleDescriptorParser() has private access in org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser [javac] static class DelegateParser extends XmlModuleDescriptorParser [javac]^ [javac] /Users/dave/development/felix-trunk/sigil/ivy/resolver/src/org/apache/felix/sigil/ivy/SigilParser.java:555: cannot find symbol [javac] symbol : constructor DefaultDependencyArtifactDescriptor(org.apache.ivy.core.module.descriptor.DefaultDependencyDescriptor,java.lang.String,java.lang.String,java.lang.String,,) [javac] location: class org.apache.ivy.core.module.descriptor.DefaultDependencyArtifactDescriptor [javac] dd.addDependencyArtifact( module, new DefaultDependencyArtifactDescriptor( dd, id, "jar", [javac] ^ [javac] /Users/dave/development/felix-trunk/sigil/ivy/resolver/src/org/apache/felix/sigil/ivy/SigilResolver.java:288: method does not override a method from its superclass [javac] @Override [javac] ^ [javac] 4 errors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1658) Deadlocks caused by component activation and deactivation
Deadlocks caused by component activation and deactivation - Key: FELIX-1658 URL: https://issues.apache.org/jira/browse/FELIX-1658 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.2.0 Reporter: Felix Meschberger Fix For: scr-1.2.0 Deadlock issues with SCR: Component operations are synchronized and may run while the bundle lock is held. This may cause deadlocks with the framework (mostly between the PackageAdmin thread and the SCR Component Actor thread). The problem is that many operations of SCR are called in a bundle listener and cause further operations (while holding Java locks (synchronized)) inside the framework. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1657) Add option in fileinstall to start bundles transiently (START_TRANSIENT)
Add option in fileinstall to start bundles transiently (START_TRANSIENT) Key: FELIX-1657 URL: https://issues.apache.org/jira/browse/FELIX-1657 Project: Felix Issue Type: Improvement Components: File Install Reporter: Sahoo Currently fileinstall starts bundle persistently. Does it make sense to have the option of starting bundles transiently? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1656) new Shell command: shell:clear
[ https://issues.apache.org/jira/browse/FELIX-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Heinemann updated FELIX-1656: -- Attachment: org.apache.felix.karaf.shell.commands.patch added patch > new Shell command: shell:clear > -- > > Key: FELIX-1656 > URL: https://issues.apache.org/jira/browse/FELIX-1656 > Project: Felix > Issue Type: New Feature > Components: Karaf >Affects Versions: karaf-1.0.0 >Reporter: Lars Heinemann > Attachments: org.apache.felix.karaf.shell.commands.patch > > > I 've prepared a clear command for karaf shell to clear the screen. Please > review and apply. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1656) new Shell command: shell:clear
new Shell command: shell:clear -- Key: FELIX-1656 URL: https://issues.apache.org/jira/browse/FELIX-1656 Project: Felix Issue Type: New Feature Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Lars Heinemann I 've prepared a clear command for karaf shell to clear the screen. Please review and apply. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Felix Web Console Event Plugin 0.9.0
+1 Approve the release Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Felix 2.0.0 download link broken
Yeah, I noticed that too. It seems the download cgi is failing for some reason. Has anyone any idea how this is set up ? On Tue, Sep 29, 2009 at 15:09, Sahoo wrote: > http://cwiki.apache.org/confluence/display/FELIX/%5Bpreferred%5D/felix/felix-framework-2.0.0.zip > is broken. > > Sahoo > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Commented: (FELIX-1627) Add support for variable expansion in sigil.property values
[
https://issues.apache.org/jira/browse/FELIX-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760596#action_12760596
]
Derek Baum commented on FELIX-1627:
---
This fix has now been enhanced to use Ant properties in the substitution of
variables when running in Ant.
> Add support for variable expansion in sigil.property values
> ---
>
> Key: FELIX-1627
> URL: https://issues.apache.org/jira/browse/FELIX-1627
> Project: Felix
> Issue Type: Improvement
> Components: Sigil
>Reporter: David Savage
>Assignee: Derek Baum
>
> Currently sigil.properties supports expansion of ${key} values in a number of
> key places such as -defaults location and translation of ${.} and ${..} to
> paths relative to the sigil.properties file.
> Proposal to make this behaviour universal for all values.
> As part of this fix we should also address consistency issues with path
> locations wrt ${.} and ${..}
> In most places:
> key: path/to/resource
> is considered a path relative to the jvm process that executes where as
> key: ${.}/path/to/resource
> is considered a path relative to the sigil.properties file
> However this is not true for the -sourcedirs attribute which has explicit
> parsing to make
> -sourcedirs: src
> imply the source dir relative to the sigil.properties file.
> Suggestion to make source dirs behaviour default and use ${.} syntax only for
> jvm process paths.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-1600) ServiceReference.isAssignableTo() always returns true if requesting bundle has no wire
[ https://issues.apache.org/jira/browse/FELIX-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1600. -- Resolution: Fixed Great, thanks Henning. I will close this issue again. > ServiceReference.isAssignableTo() always returns true if requesting bundle > has no wire > -- > > Key: FELIX-1600 > URL: https://issues.apache.org/jira/browse/FELIX-1600 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-2.0.0 >Reporter: Stuart McCulloch >Assignee: Richard S. Hall > Fix For: felix-2.2.0 > > > [ from http://markmail.org/message/pu5usr5s7vsweyv3 ] > I think there's a bug in our ServiceReference.isAssignableTo implementation... > the javadoc for this method states: > "This method performs the following checks: >1. Get the package name from the specified class name. >2. For the bundle that registered the service referenced by this > ServiceReference (registrant bundle); >find the source for the package. If no source is found then return > true if the registrant bundle is >equal to the specified bundle; otherwise return false. >3. If the package source of the registrant bundle is equal to the package > source of the specified > bundle then return true; otherwise return false." > whereas our implementation does: > // There are three situations that may occur here: > // 1. The requester does not have a wire for the package. > // 2. The provider does not have a wire for the package. > // 3. Both have a wire for the package. > // For case 1, we do not filter the service reference since we > // assume that the bundle is using reflection or that it won't > // use that class at all since it does not import it. For > // case 2, we have to try to load the class from the class > // loader of the service object and then compare the class > // loaders to determine if we should filter the service > // refernce. In case 3, we simply compare the exporting > // modules from the package wiring to determine if we need > // to filter the service reference. > assume both the provider and requester have no wire for the package > (as happens when a bundle uses it's own export, as in this situation) > the javadoc says isAssignableTo should return false, because the > provider has no wire and the provider != requester - but we'll return > true because the requester has no wire and we do that check first -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1600) ServiceReference.isAssignableTo() always returns true if requesting bundle has no wire
[ https://issues.apache.org/jira/browse/FELIX-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760559#action_12760559 ] Henning Andersen commented on FELIX-1600: - The new version also works - I tested the latest snapshot: org.apache.felix.framework-2.1.0-20090928.211315-3.jar. Thanks, Henning > ServiceReference.isAssignableTo() always returns true if requesting bundle > has no wire > -- > > Key: FELIX-1600 > URL: https://issues.apache.org/jira/browse/FELIX-1600 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-2.0.0 >Reporter: Stuart McCulloch >Assignee: Richard S. Hall > Fix For: felix-2.2.0 > > > [ from http://markmail.org/message/pu5usr5s7vsweyv3 ] > I think there's a bug in our ServiceReference.isAssignableTo implementation... > the javadoc for this method states: > "This method performs the following checks: >1. Get the package name from the specified class name. >2. For the bundle that registered the service referenced by this > ServiceReference (registrant bundle); >find the source for the package. If no source is found then return > true if the registrant bundle is >equal to the specified bundle; otherwise return false. >3. If the package source of the registrant bundle is equal to the package > source of the specified > bundle then return true; otherwise return false." > whereas our implementation does: > // There are three situations that may occur here: > // 1. The requester does not have a wire for the package. > // 2. The provider does not have a wire for the package. > // 3. Both have a wire for the package. > // For case 1, we do not filter the service reference since we > // assume that the bundle is using reflection or that it won't > // use that class at all since it does not import it. For > // case 2, we have to try to load the class from the class > // loader of the service object and then compare the class > // loaders to determine if we should filter the service > // refernce. In case 3, we simply compare the exporting > // modules from the package wiring to determine if we need > // to filter the service reference. > assume both the provider and requester have no wire for the package > (as happens when a bundle uses it's own export, as in this situation) > the javadoc says isAssignableTo should return false, because the > provider has no wire and the provider != requester - but we'll return > true because the requester has no wire and we do that check first -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1655) Provide an additional argument to the Karaf admin:create command that specifies the featuresBoot
Provide an additional argument to the Karaf admin:create command that specifies the featuresBoot Key: FELIX-1655 URL: https://issues.apache.org/jira/browse/FELIX-1655 Project: Felix Issue Type: Improvement Components: Karaf Reporter: David Bosschaert Currently when you do admin:create from the Karaf shell, it creates a minimal Karaf runtime. This is nice, but it would be even better if you could specify some additional intial features with the create command. Something like: admin:creat -f web+jbi This would add web and jbi to the minimum set of features (which is ssh and management I think). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1655) Provide an additional argument to the Karaf admin:create command that specifies the featuresBoot
[ https://issues.apache.org/jira/browse/FELIX-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-1655: Description: Currently when you do admin:create from the Karaf shell, it creates a minimal Karaf runtime. This is nice, but it would be even better if you could specify some additional intial features with the create command. Something like: admin:create -f web+jbi This would add web and jbi to the minimum set of features (which is ssh and management I think). was: Currently when you do admin:create from the Karaf shell, it creates a minimal Karaf runtime. This is nice, but it would be even better if you could specify some additional intial features with the create command. Something like: admin:creat -f web+jbi This would add web and jbi to the minimum set of features (which is ssh and management I think). > Provide an additional argument to the Karaf admin:create command that > specifies the featuresBoot > > > Key: FELIX-1655 > URL: https://issues.apache.org/jira/browse/FELIX-1655 > Project: Felix > Issue Type: Improvement > Components: Karaf >Reporter: David Bosschaert > > Currently when you do admin:create from the Karaf shell, it creates a minimal > Karaf runtime. This is nice, but it would be even better if you could specify > some additional intial features with the create command. > Something like: > admin:create -f web+jbi > This would add web and jbi to the minimum set of features (which is ssh and > management I think). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Web site syncing problem
Guillaume Nodet wrote: > Carsten, it seems some of the files permissions in > /www/felix.apache.org/site are wrong. > Could you please run: >cd /www/felix.apache.org/site >chmod -R g+w * >chown -R :felix * > Done > Also is there a cron job to rsync the content or does this have to be > done manually ? > Yes, there is a cron job running in my user account, but I have the feeling that it is not running anymore - although crontab still choose the entry. Carsten -- Carsten Ziegeler cziege...@apache.org
Web site syncing problem
Carsten, it seems some of the files permissions in /www/felix.apache.org/site are wrong. Could you please run: cd /www/felix.apache.org/site chmod -R g+w * chown -R :felix * Also is there a cron job to rsync the content or does this have to be done manually ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Updated: (FELIX-1303) add an osgi/imports and osgi/exports to show a pretty-printed output of the imports/exports packages for a bundle
[
https://issues.apache.org/jira/browse/FELIX-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-1303:
---
Fix Version/s: (was: karaf-1.0.0)
karaf-1.2.0
> add an osgi/imports and osgi/exports to show a pretty-printed output of the
> imports/exports packages for a bundle
> -
>
> Key: FELIX-1303
> URL: https://issues.apache.org/jira/browse/FELIX-1303
> Project: Felix
> Issue Type: Improvement
> Components: Karaf
>Reporter: james strachan
> Fix For: karaf-1.2.0
>
>
> e.g.
> {code}
> > osgi/imports 22
> com.acme.bar=
> com.acme.bar.something =...
> com.acme.foo =...
> {code}
> So its really easy to see the scope of import/exports in a nice sorted display
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Felix Http Service version 2.0.0
Our release process has been delayed, so haven't had a chance to try the new Http in our environment. Happy to add my +1 though if others have and it's working well for them - R
Re: Deadlock in Felix 1.8.1 with Spring-DM
On Tue, Sep 29, 2009 at 7:17 AM, Don Brown wrote: > Any way to easily fix it on 1.8.1? I can't move to 2.0 easily, but > this issue is quite worrying. Maybe. In general, I don't think it is an easy one to hit for you as the issue at hand is the following. Something at the outside is calling into java.* classes which lock the appclassloader and then create a url which goes via the urlhandlers which turn around and try to lock the serviceregistry (this part has changed in 2.0). At the same time something on the outside is calling into the framework, trying to get a service, which locks the serviceregistry and is then triggering a classload for the appclassloader -> deadlock. This is a pretty special combination and due to the fact that certain paths inside the java.* and javax.* packages result in different orders of lock taking. I can try to look into creating a patch for you as the urlhandlers are somewhat independent so it might be possible to create an easy backport but it sure would be nicer if we could get you on the current trunk. I plan to cut a 2.0.1 release real soon now... regards, Karl > Don > > On Tue, Sep 29, 2009 at 11:16 AM, Gerry Woods wrote: >> Thanks for your response Karl. We examined the 2.0 source today and arrived >> at the same conclusion. We're testing with it now. >> >> On Mon, Sep 28, 2009 at 2:23 PM, Karl Pauls wrote: >> >>> This looks like something which should not be happening with felix >>> 2.0.0 anymore. Can you reproduce the issue and if so, can you retry >>> with felix 2.0? >>> >>> regards, >>> >>> Karl >>> >>> On Sat, Sep 26, 2009 at 1:24 AM, Gerry Woods wrote: >>> > Hi, >>> > First let me say a word of thanks for the fantastic work you guys have >>> been >>> > doing. We have encountered a deadlock with Felix (1.8.1) and Spring-DM >>> > (1.2.0) and I wanted to run it by you guys to see if this is a known >>> issue, >>> > or if you have any opinions on the problem. I had a look through Jira >>> for >>> > any deadlock-related issues and didn't see anything that looked quite >>> like >>> > this. >>> > Thanks for any help or feedback, >>> > Gerry >>> > >>> > >>> > Found one Java-level deadlock: >>> > = >>> > "SpringOsgiExtenderThread-17": >>> > waiting to lock monitor 0x0033d8ec (object 0x07f41dc0, a >>> > org.apache.felix.framework.ServiceRegistry), >>> > which is held by "SpringOsgiExtenderThread-3" >>> > "SpringOsgiExtenderThread-3": >>> > waiting to lock monitor 0x0033d7ac (object 0x078c9058, a >>> > sun.misc.Launcher$AppClassLoader), >>> > which is held by "SpringOsgiExtenderThread-17" >>> > >>> > Java stack information for the threads listed above: >>> > === >>> > "SpringOsgiExtenderThread-17": >>> > at >>> > >>> org.apache.felix.framework.ServiceRegistry.getServiceReferences(ServiceRegistry.java:165) >>> > - waiting to lock <0x07f41dc0> (a >>> > org.apache.felix.framework.ServiceRegistry) >>> > at >>> > org.apache.felix.framework.Felix.getServiceReferences(Felix.java:2617) >>> > at >>> > >>> org.apache.felix.framework.Felix.getAllowedServiceReferences(Felix.java:2672) >>> > at >>> > >>> org.apache.felix.framework.BundleContextImpl.getServiceReferences(BundleContextImpl.java:310) >>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >>> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>> > at java.lang.reflect.Method.invoke(Unknown Source) >>> > at >>> > >>> org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:763) >>> > at >>> > >>> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:476) >>> > at >>> > >>> org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:352) >>> > at java.net.URL.(Unknown Source) >>> > at java.net.URL.(Unknown Source) >>> > at java.net.URL.(Unknown Source) >>> > at java.net.JarURLConnection.parseSpecs(Unknown Source) >>> > at java.net.JarURLConnection.(Unknown Source) >>> > at sun.net.www.protocol.jar.JarURLConnection.(Unknown >>> Source) >>> > at sun.net.www.protocol.jar.Handler.openConnection(Unknown Source) >>> > at java.net.URL.openConnection(Unknown Source) >>> > at java.net.URL.openStream(Unknown Source) >>> > at java.lang.ClassLoader.getSystemResourceAsStream(Unknown Source) >>> > at java.lang.Class.getResourceAsStream(Unknown Source) >>> > at sun.text.NormalizerImpl$1.run(Unknown Source) >>> > at java.security.AccessController.doPrivileged(Native Method) >>> > at sun.text.NormalizerImpl.(Unknown Source) >>> > at sun.text.NormalizerImpl.(Unknown Source) >>> > at sun.text.Normalizer.decompose(Unknown Source) >>> > at sun
[jira] Created: (FELIX-1654) BND should WARN when the Bundle-Activator is not present in the current bundle
BND should WARN when the Bundle-Activator is not present in the current bundle -- Key: FELIX-1654 URL: https://issues.apache.org/jira/browse/FELIX-1654 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Reporter: Niclas Hedhman Currently, if a declared Bundle-Activator is not present, BND will add an Import-Package statement for such activator. I think it would be better that it at least create a warning that the activator doesn't exist in the current bundle, or even generate an error so that the developer is forced to include the package import explicitly (but I understand that this might be too strong for people's taste.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
