[jira] [Commented] (FELIX-3624) Performance tuning solution for BundleRepository/ResolverImpl
[
https://issues.apache.org/jira/browse/FELIX-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13491834#comment-13491834
]
Jarek Gawor commented on FELIX-3624:
I think there might be a potential problem with the patch with the
searchResources(Requirement, Set) function. The function is supposed to search
for matching resources within a specified set of resources. With caching
enabled that means the m_capabilitiesCache will be checked first - a cache of
local and remote resources only. Once a matching resource is found in the cache
it will be checked against the specified set. That's good but there is at least
one case where the cache might not contain a resource in the specified set. For
example, the m_addedSet - which user can add resources to before resolve() is
called. So in this case, with caching, searchResources() would return null
instead of a matching resource from the m_addedSet.
Performance tuning solution for BundleRepository/ResolverImpl
-
Key: FELIX-3624
URL: https://issues.apache.org/jira/browse/FELIX-3624
Project: Felix
Issue Type: Improvement
Components: Bundle Repository (OBR)
Environment: Geronimo3 + BundleRepository 1.6.6
Reporter: SheldonShao
Priority: Critical
Attachments: Felix_ResolverImpl_AfterTuning.png,
Felix_ResolverImpl.png, repo_for_resolver_perf.xml, ResolverImpl.diff,
ResolverImpl.java, ResolverImplTest.diff
There are too many numebers of method calling about checking whether
capabities are matched with requiment in ResolverImpl.searchResources.
This is a performance issue of ResolverImpl.resolve.
If it creates a capabity to resource+capabity mapping first. Then leverage
this cache to do requirment matching. It will get better performance.
Here is part of code. More details please check attachments.
private final Map m_capabilitiesCache = new HashMap(8192);
private String getKey(String filter, String prefix) {
if (filter != null) {
int index = filter.indexOf(prefix);
if (index 0) {
int end = filter.indexOf(SUFFIX, index +
prefix.length());
if (end index) {
return filter.substring(index, end);
}
}
}
return null;
}
private String getKey(Requirement requirement) {
String key = null;
String name = requirement.getName();
String filter = requirement.getFilter();
if (Capability.BUNDLE.equals(name)) {
key = getKey(filter, PREFIX_SYMBOLICNAME);
} else if (Capability.PACKAGE.equals(name)) {
key = getKey(filter, PREFIX_PACKAGE);
} else if (Capability.SERVICE.equals(name)) {
key = getKey(filter, PREFIX_SERVICE);
} else if (Capability.FRAGMENT.equals(name)) {
key = getKey(filter, PREFIX_HOST);
} else {
key = PREFIX_CAPABILITY + name;
}
return key;
}
private static final String PREFIX_SYMBOLICNAME = symbolicname=;
private static final String PREFIX_PACKAGE = package=;
private static final String PREFIX_SERVICE = service=;
private static final String PREFIX_HOST = host=;
private static final String PREFIX_CAPABILITY = capability=;
private static final char SUFFIX = ')';
private void initCache(Capability[] capabilities, Resource resource) {
Capability cap;
Map properties;
String name;
for (int j = 0; j capabilities.length; j++) {
cap = capabilities[j];
String key = null;
properties = cap.getPropertiesAsMap();
name = cap.getName();
if (Capability.BUNDLE.equals(name)) {
key = PREFIX_SYMBOLICNAME +
properties.get(symbolicname);
} else if (Capability.PACKAGE.equals(name)) {
key = PREFIX_PACKAGE +
properties.get(package);
} else if (Capability.SERVICE.equals(name)) {
key = PREFIX_SERVICE +
properties.get(service);
} else if (Capability.FRAGMENT.equals(name)) {
key = PREFIX_HOST + properties.get(host);
} else {
key = PREFIX_CAPABILITY + name
[jira] [Created] (FELIX-3635) Unnecessary processing in DirectoryWatcher
Jarek Gawor created FELIX-3635: -- Summary: Unnecessary processing in DirectoryWatcher Key: FELIX-3635 URL: https://issues.apache.org/jira/browse/FELIX-3635 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.2.4 Reporter: Jarek Gawor When a DirectoryWatcher is setup to only watch configuration files (e.g. *.cfg), on each scan findBundlesWithOptionalPackagesToRefresh() is called. Since only configuration can change - no bundles, there is no need to call findBundlesWithOptionalPackagesToRefresh(). And the findBundlesWithOptionalPackagesToRefresh() can be expensive since it goes through all bundles in the framework looking for optional imports that can be now satisfied. -- 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] [Updated] (FELIX-3635) Unnecessary processing in DirectoryWatcher
[ https://issues.apache.org/jira/browse/FELIX-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-3635: --- Attachment: FELIX-3635.patch Patch for this issue that only calls findBundlesWithOptionalPackagesToRefresh() if there were any actual bundles installed, modified, or updated. Unnecessary processing in DirectoryWatcher -- Key: FELIX-3635 URL: https://issues.apache.org/jira/browse/FELIX-3635 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.2.4 Reporter: Jarek Gawor Attachments: FELIX-3635.patch When a DirectoryWatcher is setup to only watch configuration files (e.g. *.cfg), on each scan findBundlesWithOptionalPackagesToRefresh() is called. Since only configuration can change - no bundles, there is no need to call findBundlesWithOptionalPackagesToRefresh(). And the findBundlesWithOptionalPackagesToRefresh() can be expensive since it goes through all bundles in the framework looking for optional imports that can be now satisfied. -- 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
Re: framework snapshot
Thank you! Jarek On Fri, Mar 30, 2012 at 3:01 AM, Guillaume Nodet gno...@gmail.com wrote: Done On Fri, Mar 30, 2012 at 05:23, Jarek Gawor jga...@gmail.com wrote: Hi, Can someone please publish a snapshot of the latest framework code? Thanks, Jarek -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
[jira] [Reopened] (FELIX-3393) Possible deadlock with reentrant calls
[
https://issues.apache.org/jira/browse/FELIX-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor reopened FELIX-3393:
Possible deadlock with reentrant calls
--
Key: FELIX-3393
URL: https://issues.apache.org/jira/browse/FELIX-3393
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.0.2
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
Fix For: framework-4.2.0
This happen when a thread which has a bundle lock has some reentrant call
while the global lock is held by another thread (see stack trace below)
In the code Felix#acquireBundleLock, the comment on the loop says Wait if
the desired bundle is already locked by someone else or if any thread has the
global lock, unless the current thread holds the global lock or the bundle
lock already. which makes total sense, but I don't think the code handle the
case where the lock is already held by the current thread *and* the global
lock is held by a different thread.
Possible patch below.
{code}
diff --git a/framework/src/main/java/org/apache/felix/framework/Felix.java
b/framework/src/main/java/org/apache/felix/framework/Felix.java
index 6504f13..0965d8b 100644
--- a/framework/src/main/java/org/apache/felix/framework/Felix.java
+++ b/framework/src/main/java/org/apache/felix/framework/Felix.java
@@ -5002,7 +5002,8 @@ public class Felix extends BundleImpl implements
Framework
// holds the global lock or the bundle lock already.
while (!bundle.isLockable() ||
((m_globalLockThread != null)
- (m_globalLockThread != Thread.currentThread(
+ (m_globalLockThread != Thread.currentThread())
+ (bundle.getLockingThread() !=
Thread.currentThread(
{
// Check to make sure the bundle is in a desired state.
// If so, keep waiting. If not, throw an exception.
{code}
{code}
FelixStartLevel daemon prio=5 tid=7fb1b2ac7800 nid=0x44000 in
Object.wait() [42000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 7e039bc90 (a [Ljava.lang.Object;)
at java.lang.Object.wait(Object.java:485)
at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:5025)
- locked 7e039bc90 (a [Ljava.lang.Object;)
at org.apache.felix.framework.Felix.registerService(Felix.java:3282)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:408)
at
org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:184)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:666)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:334)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:230)
- locked 7f5898750 (a java.util.concurrent.atomic.AtomicBoolean)
- locked 7f5898740 (a java.util.concurrent.atomic.AtomicBoolean)
at
org.apache.aries.blueprint.container.BlueprintExtender.checkBundle(BlueprintExtender.java:325)
at
org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:244)
at
org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:471)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:495)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:1)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:238)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:457)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:870)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:791)
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:515)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4321)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1945)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1213)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:680)
{code}
--
This message is automatically generated by JIRA.
If you think
[jira] [Commented] (FELIX-3393) Possible deadlock with reentrant calls
[ https://issues.apache.org/jira/browse/FELIX-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242534#comment-13242534 ] Jarek Gawor commented on FELIX-3393: I was hoping that this fix also addresses the problem we were seeing in Geronimo (which looks very similar to the original stack trace) but we are still seeing the problem. Here are the relevant stack traces: FelixShutdown prio=10 tid=0x08157c00 nid=0x5a0c in Object.wait() [0x30ffe000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xa33ded98 (a java.lang.Integer) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.FrameworkStartLevelImpl.setStartLevelAndWait(FrameworkStartLevelImpl.java:153) - locked 0xa33ded98 (a java.lang.Integer) at org.apache.felix.framework.Felix$SystemBundleActivator.stop(Felix.java:4492) at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:663) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2361) at org.apache.felix.framework.Felix$2.run(Felix.java:882) at java.lang.Thread.run(Thread.java:662) Blueprint Extender: 1 daemon prio=10 tid=0x086fa400 nid=0x5a09 in Object.wait() [0x312fb000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x9f6a28f0 (a [Ljava.lang.Object;) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4871) - locked 0x9f6a28f0 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.registerService(Felix.java:3205) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:388) at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:324) at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:213) - locked 0xa26ec7f0 (a java.util.concurrent.atomic.AtomicBoolean) - locked 0xa26ec7e0 (a java.util.concurrent.atomic.AtomicBoolean) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) FelixStartLevel daemon prio=10 tid=0x082dcc00 nid=0x5a07 waiting for monitor entry [0x326c8000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:810) - waiting to lock 0xa26ec7f0 (a java.util.concurrent.atomic.AtomicBoolean) at org.apache.aries.blueprint.container.BlueprintExtender.destroyContext(BlueprintExtender.java:204) at org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:196) at org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:385) at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:453) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:237) at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:413) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2351) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1214) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:298) at java.lang.Thread.run(Thread.java:662) main prio=10 tid=0x08058c00 nid=0x470e in Object.wait() [0xb741] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting
framework snapshot
Hi, Can someone please publish a snapshot of the latest framework code? Thanks, Jarek
[jira] [Commented] (FELIX-3288) NPE when component exposed as a service with servicefactory = true
[ https://issues.apache.org/jira/browse/FELIX-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195920#comment-13195920 ] Jarek Gawor commented on FELIX-3288: Can someone please take a look at this? We are hitting this problem quite frequently. NPE when component exposed as a service with servicefactory = true -- Key: FELIX-3288 URL: https://issues.apache.org/jira/browse/FELIX-3288 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Jarek Gawor Attachments: FELIX-3288.patch I have a component that is exposed as a service and is also configured with servicefactory = true. I see the following NPE when shutting the framework: java.lang.NullPointerException at org.apache.felix.scr.impl.manager.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:252) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:135) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1075) at org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:357) at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:196) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.disposeComponents(ConfiguredComponentHolder.java:299) at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:319) at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:340) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:207) Since the component is configured with servicefactory = true, ServiceFactoryComponentManager is used to manage the object. ServiceFactoryComponentManager overrides the createComponent() method from ImmediateComponentManager. ServiceFactoryComponentManager also intended (I think) to override the corresponding deleteComponent() method from ImmediateComponentManager. However, the signature of the deleteComponent() in ImmediateComponentManager has changed a bit so the override doesn't work anymore. So that's what I think is causing the problem in this case. -- 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] [Updated] (FELIX-3288) NPE when component exposed as a service with servicefactory = true
[ https://issues.apache.org/jira/browse/FELIX-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-3288: --- Attachment: FELIX-3288.patch Small patch for this issue. NPE when component exposed as a service with servicefactory = true -- Key: FELIX-3288 URL: https://issues.apache.org/jira/browse/FELIX-3288 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Jarek Gawor Attachments: FELIX-3288.patch I have a component that is exposed as a service and is also configured with servicefactory = true. I see the following NPE when shutting the framework: java.lang.NullPointerException at org.apache.felix.scr.impl.manager.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:252) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:135) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1075) at org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:357) at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:196) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.disposeComponents(ConfiguredComponentHolder.java:299) at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:319) at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:340) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:207) Since the component is configured with servicefactory = true, ServiceFactoryComponentManager is used to manage the object. ServiceFactoryComponentManager overrides the createComponent() method from ImmediateComponentManager. ServiceFactoryComponentManager also intended (I think) to override the corresponding deleteComponent() method from ImmediateComponentManager. However, the signature of the deleteComponent() in ImmediateComponentManager has changed a bit so the override doesn't work anymore. So that's what I think is causing the problem in this case. -- 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-3288) NPE when component exposed as a service with servicefactory = true
NPE when component exposed as a service with servicefactory = true -- Key: FELIX-3288 URL: https://issues.apache.org/jira/browse/FELIX-3288 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.0.2 Reporter: Jarek Gawor I have a component that is exposed as a service and is also configured with servicefactory = true. I see the following NPE when shutting the framework: java.lang.NullPointerException at org.apache.felix.scr.impl.manager.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:252) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:135) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1075) at org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:357) at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:196) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.disposeComponents(ConfiguredComponentHolder.java:299) at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:319) at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:340) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:207) Since the component is configured with servicefactory = true, ServiceFactoryComponentManager is used to manage the object. ServiceFactoryComponentManager overrides the createComponent() method from ImmediateComponentManager. ServiceFactoryComponentManager also intended (I think) to override the corresponding deleteComponent() method from ImmediateComponentManager. However, the signature of the deleteComponent() in ImmediateComponentManager has changed a bit so the override doesn't work anymore. So that's what I think is causing the problem in this case. -- 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] [Updated] (FELIX-3288) NPE when component exposed as a service with servicefactory = true
[ https://issues.apache.org/jira/browse/FELIX-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-3288: --- Affects Version/s: (was: scr-1.0.2) scr-1.6.0 NPE when component exposed as a service with servicefactory = true -- Key: FELIX-3288 URL: https://issues.apache.org/jira/browse/FELIX-3288 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Jarek Gawor I have a component that is exposed as a service and is also configured with servicefactory = true. I see the following NPE when shutting the framework: java.lang.NullPointerException at org.apache.felix.scr.impl.manager.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:252) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:135) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1075) at org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:357) at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:196) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.disposeComponents(ConfiguredComponentHolder.java:299) at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:319) at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:340) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:207) Since the component is configured with servicefactory = true, ServiceFactoryComponentManager is used to manage the object. ServiceFactoryComponentManager overrides the createComponent() method from ImmediateComponentManager. ServiceFactoryComponentManager also intended (I think) to override the corresponding deleteComponent() method from ImmediateComponentManager. However, the signature of the deleteComponent() in ImmediateComponentManager has changed a bit so the override doesn't work anymore. So that's what I think is causing the problem in this case. -- 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-3288) NPE when component exposed as a service with servicefactory = true
[ https://issues.apache.org/jira/browse/FELIX-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173758#comment-13173758 ] Jarek Gawor commented on FELIX-3288: I just selected a wrong version my mistake. NPE when component exposed as a service with servicefactory = true -- Key: FELIX-3288 URL: https://issues.apache.org/jira/browse/FELIX-3288 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Jarek Gawor I have a component that is exposed as a service and is also configured with servicefactory = true. I see the following NPE when shutting the framework: java.lang.NullPointerException at org.apache.felix.scr.impl.manager.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:252) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:135) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1075) at org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:357) at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:196) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.disposeComponents(ConfiguredComponentHolder.java:299) at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:319) at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:340) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:207) Since the component is configured with servicefactory = true, ServiceFactoryComponentManager is used to manage the object. ServiceFactoryComponentManager overrides the createComponent() method from ImmediateComponentManager. ServiceFactoryComponentManager also intended (I think) to override the corresponding deleteComponent() method from ImmediateComponentManager. However, the signature of the deleteComponent() in ImmediateComponentManager has changed a bit so the override doesn't work anymore. So that's what I think is causing the problem in this case. -- 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] [Issue Comment Edited] (FELIX-3288) NPE when component exposed as a service with servicefactory = true
[ https://issues.apache.org/jira/browse/FELIX-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173758#comment-13173758 ] Jarek Gawor edited comment on FELIX-3288 at 12/21/11 1:38 AM: -- I just selected a wrong version by mistake. was (Author: ga...@mcs.anl.gov): I just selected a wrong version my mistake. NPE when component exposed as a service with servicefactory = true -- Key: FELIX-3288 URL: https://issues.apache.org/jira/browse/FELIX-3288 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Jarek Gawor I have a component that is exposed as a service and is also configured with servicefactory = true. I see the following NPE when shutting the framework: java.lang.NullPointerException at org.apache.felix.scr.impl.manager.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:252) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:135) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1075) at org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:357) at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:196) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.disposeComponents(ConfiguredComponentHolder.java:299) at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:319) at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:340) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:207) Since the component is configured with servicefactory = true, ServiceFactoryComponentManager is used to manage the object. ServiceFactoryComponentManager overrides the createComponent() method from ImmediateComponentManager. ServiceFactoryComponentManager also intended (I think) to override the corresponding deleteComponent() method from ImmediateComponentManager. However, the signature of the deleteComponent() in ImmediateComponentManager has changed a bit so the override doesn't work anymore. So that's what I think is causing the problem in this case. -- 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-3047) Infinite loop in File Install if java.io.tmpdir is non-writable
Infinite loop in File Install if java.io.tmpdir is non-writable --- Key: FELIX-3047 URL: https://issues.apache.org/jira/browse/FELIX-3047 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.1.10 Reporter: Jarek Gawor File Install (in prepareTempDir()) goes into an infinite loop if the java.io.tmpdir specifies a directory that is non-writable (e.g. somebody set java.io.tmpdir to a wrong directory by mistake). Since prepareTempDir() can be called on the same thread as the bundle activation this can prevent other bundles in the framework from starting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
snapshot of bundlerepository
Hi, Can someone please publish latest snapshot of the bundlerepository module? The one currently published is pretty old. Thanks, Jarek
[jira] [Created] (FELIX-2958) Unable to remove previously added repository from OBR
Unable to remove previously added repository from OBR - Key: FELIX-2958 URL: https://issues.apache.org/jira/browse/FELIX-2958 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor When adding a new repository to OBR, the passed url is converted into an actual URL object and the repository is stored in a map under url.toExternalForm() key. However, when removing a repository, the raw url string is used remove the repository from the map. Because of the uri conversion to URL object in addRepository(), the passed in string and the string produced by URL.toExternalForm() might be slightly different. That can make removeRepository() not work right (the repository won't be removed). For example, URL.toExternalForm() on file:///media/d/m2/repository.xml returns file:/media/d/m2/repository.xml. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2958) Unable to remove previously added repository from OBR
[ https://issues.apache.org/jira/browse/FELIX-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2958: --- Attachment: FELIX-2958.patch Attached patch for this issue. Unable to remove previously added repository from OBR - Key: FELIX-2958 URL: https://issues.apache.org/jira/browse/FELIX-2958 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor Attachments: FELIX-2958.patch When adding a new repository to OBR, the passed url is converted into an actual URL object and the repository is stored in a map under url.toExternalForm() key. However, when removing a repository, the raw url string is used remove the repository from the map. Because of the uri conversion to URL object in addRepository(), the passed in string and the string produced by URL.toExternalForm() might be slightly different. That can make removeRepository() not work right (the repository won't be removed). For example, URL.toExternalForm() on file:///media/d/m2/repository.xml returns file:/media/d/m2/repository.xml. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-2958) Unable to remove previously added repository from OBR
[ https://issues.apache.org/jira/browse/FELIX-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor closed FELIX-2958. -- Thank you! Unable to remove previously added repository from OBR - Key: FELIX-2958 URL: https://issues.apache.org/jira/browse/FELIX-2958 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor Assignee: Richard S. Hall Fix For: bundlerepository-1.6.6 Attachments: FELIX-2958.patch When adding a new repository to OBR, the passed url is converted into an actual URL object and the repository is stored in a map under url.toExternalForm() key. However, when removing a repository, the raw url string is used remove the repository from the map. Because of the uri conversion to URL object in addRepository(), the passed in string and the string produced by URL.toExternalForm() might be slightly different. That can make removeRepository() not work right (the repository won't be removed). For example, URL.toExternalForm() on file:///media/d/m2/repository.xml returns file:/media/d/m2/repository.xml. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2912) Host name is lost in exceptions when dealing with Windows shared drives
[ https://issues.apache.org/jira/browse/FELIX-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2912: --- Attachment: FELIX-2912.2.patch Attached another version of the patch that is more generic. Host name is lost in exceptions when dealing with Windows shared drives --- Key: FELIX-2912 URL: https://issues.apache.org/jira/browse/FELIX-2912 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor Attachments: FELIX-2912.2.patch, FELIX-2912.patch When OBR repository URL specifies a Windows shared drive for example: file://myhost/mydir/myrepo.xml and the myrepo.xml specifies a relative uri to a mybundle.jar that does not exist in that location, OBR will throw the following exception (during Resolver.deploy()): java.io.FileNotFoundException: mydir/mybundle.jar at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:441) at org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:203) at org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:196) at org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:598) The hostname part of the repository url is lost in the exception. The root cause of this is probably somewhere in the JDK but OBR could handle this case a bit better. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: OBR - FELIX-2912
On Wed, May 4, 2011 at 4:02 PM, Richard S. Hall he...@ungoverned.org wrote: On 5/4/11 15:39, Jarek Gawor wrote: I was wondering if somebody could review possibly commit the patch attached to FELIX-2912 for the bundlerepository module. The patch in and of itself seems ok, but generally speaking it seems like a specific special case for a situation that could have lots of similar special cases. What if there are other types of exceptions that get thrown and similarly provide inadequate reporting. Will we need a bunch of different catch clauses converting them into something more meaningful? Is there a more general approach to solve this issue? What always catching any IOException and rethrowing another IOException that includes the full URL of what we were trying to open in its message along with the exception that caused this in the first place? Would that give you enough of the information you want in this case? Just wondering... Sure. I just attached another patch for FELIX-2912 that follows your suggestion to catch any IOException. Let me know if that works for you. Thanks, Jarek
[jira] [Closed] (FELIX-2912) Host name is lost in exceptions when dealing with Windows shared drives
[ https://issues.apache.org/jira/browse/FELIX-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor closed FELIX-2912. -- Looks good. Thank you! Host name is lost in exceptions when dealing with Windows shared drives --- Key: FELIX-2912 URL: https://issues.apache.org/jira/browse/FELIX-2912 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor Assignee: Richard S. Hall Fix For: bundlerepository-1.6.6 Attachments: FELIX-2912.2.patch, FELIX-2912.patch When OBR repository URL specifies a Windows shared drive for example: file://myhost/mydir/myrepo.xml and the myrepo.xml specifies a relative uri to a mybundle.jar that does not exist in that location, OBR will throw the following exception (during Resolver.deploy()): java.io.FileNotFoundException: mydir/mybundle.jar at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:441) at org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:203) at org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:196) at org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:598) The hostname part of the repository url is lost in the exception. The root cause of this is probably somewhere in the JDK but OBR could handle this case a bit better. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
OBR - FELIX-2912
Hi, I was wondering if somebody could review possibly commit the patch attached to FELIX-2912 for the bundlerepository module. Thanks, Jarek
[jira] [Created] (FELIX-2912) Host name is lost in exceptions when dealing with Windows shared drives
Host name is lost in exceptions when dealing with Windows shared drives --- Key: FELIX-2912 URL: https://issues.apache.org/jira/browse/FELIX-2912 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor When OBR repository URL specifies a Windows shared drive for example: file://myhost/mydir/myrepo.xml and the myrepo.xml specifies a relative uri to a mybundle.jar that does not exist in that location, OBR will throw the following exception (during Resolver.deploy()): java.io.FileNotFoundException: mydir/mybundle.jar at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:441) at org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:203) at org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:196) at org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:598) The hostname part of the repository url is lost in the exception. The root cause of this is probably somewhere in the JDK but OBR could handle this case a bit better. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2912) Host name is lost in exceptions when dealing with Windows shared drives
[ https://issues.apache.org/jira/browse/FELIX-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2912: --- Attachment: FELIX-2912.patch Proposed patch for this issue. The code catches the FileNotFoundException and throws a new FileNotFoundException with full URL if the URL specified a hostname. Host name is lost in exceptions when dealing with Windows shared drives --- Key: FELIX-2912 URL: https://issues.apache.org/jira/browse/FELIX-2912 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor Attachments: FELIX-2912.patch When OBR repository URL specifies a Windows shared drive for example: file://myhost/mydir/myrepo.xml and the myrepo.xml specifies a relative uri to a mybundle.jar that does not exist in that location, OBR will throw the following exception (during Resolver.deploy()): java.io.FileNotFoundException: mydir/mybundle.jar at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:441) at org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:203) at org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:196) at org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:598) The hostname part of the repository url is lost in the exception. The root cause of this is probably somewhere in the JDK but OBR could handle this case a bit better. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
framework snapshot
Hi, Can someone please publish latest snapshot of the framework module? Thanks, Jarek
[jira] Updated: (FELIX-2457) Bundle repository does not respect NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags
[ https://issues.apache.org/jira/browse/FELIX-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2457: --- Attachment: FELIX-2457.patch Patch for this problem. The problem is that the getResources() call to obtain a list of local resources is made before the m_resolutionFlags variable is set to the specified flags. Bundle repository does not respect NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags --- Key: FELIX-2457 URL: https://issues.apache.org/jira/browse/FELIX-2457 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor Attachments: FELIX-2457.patch When passing a Resolver.NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags to resolver, the system bundle or local resources are still considered during resolution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2457) Bundle repository does not respect NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags
Bundle repository does not respect NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags --- Key: FELIX-2457 URL: https://issues.apache.org/jira/browse/FELIX-2457 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor When passing a Resolver.NO_SYSTEM_BUNDLE or NO_LOCAL_RESOURCES flags to resolver, the system bundle or local resources are still considered during resolution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2306) ClassCastException in Wrapper.unwrap() when calling Resolver.add(x implements Resource)
[
https://issues.apache.org/jira/browse/FELIX-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor updated FELIX-2306:
---
Attachment: FELIX-2306.patch
Proposed patch for this issue. The patch code will attempt to covert osgi
Resource to felix Resource by copying the data. This might not work in all
cases but should in most.
ClassCastException in Wrapper.unwrap() when calling Resolver.add(x implements
Resource)
---
Key: FELIX-2306
URL: https://issues.apache.org/jira/browse/FELIX-2306
Project: Felix
Issue Type: Bug
Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.0
Environment: Windows 7, Java 6
Reporter: Mark Nuttall
Attachments: FELIX-2306.patch
This looks like a regression from OBR 1.4.1 to 1.6. I have a resource class
that implements org.osgi.service.obr.Resource. When I call
Resolver.add(myResource) I
get a ClassCastException:
Caused by: java.lang.ClassCastException:my.resources.MyResource
incompatible with
org.apache.felix.bundlerepository.impl.wrapper.ResourceWrapper
at
org.apache.felix.bundlerepository.impl.wrapper.Wrapper.unwrap(Wrapper.java:59)
at
org.apache.felix.bundlerepository.impl.wrapper.ResolverWrapper.add(ResolverWrapper.java:40)
at my.provisioning.impl.OBRProvisioner.resolve(OBRProvisioner.java:496)
Looking at Wrapper.java:
public static Resource unwrap(org.osgi.service.obr.Resource resource) {
return ((ResourceWrapper) resource).resource;
}
I've passed in a class that implemented obr.Resource which this code is
attempting to cast to ResourceWrapper: this fails. We got there via,
// ResolverWrapper.java
public void add(org.osgi.service.obr.Resource resource) {
resolver.add(Wrapper.unwrap(resource));
}
At no time was my Resource wrapped before it was unwrapped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
bundlerepository snapshot
Hi, Can someone please publish latest snapshot of the bundlerepository module? Thanks, Jarek
Re: bundlerepository snapshot
Thank you! On Tue, Jun 8, 2010 at 5:13 PM, Richard S. Hall he...@ungoverned.org wrote: Done. - richard On 6/8/10 17:10, Jarek Gawor wrote: Hi, Can someone please publish latest snapshot of the bundlerepository module? Thanks, Jarek
[jira] Created: (FELIX-2385) Execution environment property is not correctly exposed
Execution environment property is not correctly exposed --- Key: FELIX-2385 URL: https://issues.apache.org/jira/browse/FELIX-2385 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.2 Reporter: Jarek Gawor The org.osgi.framework.executionenvironment property can be a list of comma separated of supported execution environments. Currently, the OBR assumes it contains a single value and publishes it as a single capability. If the value of this property is a list, the OBR resolution will pretty much fail since the filter generated based on the Bundle-RequiredExecutionEnvironment header will not match the single capability. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2385) Execution environment property is not correctly exposed
[ https://issues.apache.org/jira/browse/FELIX-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2385: --- Attachment: FELIX-2385.patch A patch for this issue. The patch publishes each value in the org.osgi.framework.executionenvironment property as a separate capability. Execution environment property is not correctly exposed --- Key: FELIX-2385 URL: https://issues.apache.org/jira/browse/FELIX-2385 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.2 Reporter: Jarek Gawor Attachments: FELIX-2385.patch The org.osgi.framework.executionenvironment property can be a list of comma separated of supported execution environments. Currently, the OBR assumes it contains a single value and publishes it as a single capability. If the value of this property is a list, the OBR resolution will pretty much fail since the filter generated based on the Bundle-RequiredExecutionEnvironment header will not match the single capability. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FELIX-2310) Karaf framework environment is not set correctly
[ https://issues.apache.org/jira/browse/FELIX-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reopened FELIX-2310: The org.osgi.framework.executionenvironment property needs to list all supported execution environments. Otherwise, bundles with for example Bundle-RequireExecutionEnvironment: J2SE-3.0 will fail to resolve on Karaf. Try for example to install and start http://repo2.maven.org/maven2/asm/asm-all/3.2/asm-all-3.2.jar. The bundle will fail to start with: Unresolved constraint in bundle org.objectweb.asm.all [35]: Execution environment not supported: J2SE-1.3. This problem also affects OBR-based resolution - but OBR also has another problem that's related to execution environments (see FELIX-2385). Karaf framework environment is not set correctly Key: FELIX-2310 URL: https://issues.apache.org/jira/browse/FELIX-2310 Project: Felix Issue Type: Bug Components: Karaf Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: karaf 1.6.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Move Karaf as a TLP
I would like to be involved with this TLP as well. Thanks, Jarek On Friday, May 28, 2010, Guillaume Nodet gno...@gmail.com wrote: It seems there is a consensus to move Karaf as a TLP, at least amongst people involved in Karaf (the other felix committers haven't really expressed any opinion). I think the next steps would be to draft a proposed resolution to the board, which would include: * the project goal * the project PMC (including the chair) In order to create an open community from the start, I'd like to invite anyone with an Apache account willing to contribute to Karaf to raise hands so that we can build this list. I don't think opening it wider for now would be wise, but I do thing we should have a very low entry bar for committership (but that can be discussed later). I'll try to come up with a proposal for Karaf's project goal asap, but anyone is welcome to give it a try and propose some wording. FWIW, it would like the following, we just need to fill the : WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a machine learning platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Karaf Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creation and maintenance of software related to XXX; and be it further RESOLVED, that the office of Vice President, Apache Karaf be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Karaf Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Karaf Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Karaf Project: * xxx x...@apache.org * ... NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Apache Karaf, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Karaf PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Mahout Project; and be it further RESOLVED, that the Apache Karaf Project be and hereby is tasked with the migration and rationalization of the Apache Felix Karaf sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Felix Karaf sub-project encumbered upon the Apache Felix Project are hereafter discharged. On Fri, May 14, 2010 at 12:20, Guillaume Nodet gno...@gmail.com wrote: Karaf has been brought into the Felix TLP nearly one year ago. Things have not been too bad, but I still see the karaf community as being very disjoint from the other felix community, as it looks that none of the existing felix committers did really get involved in Karaf. I really don't blame anyone, i think it's just that the interest are not the same (not sure where they actually diverge though). I don't really see what benefit Karaf would have in continuing being part of Felix, so I'd like to open the discussion about moving it to a TLP. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Preparation of Karaf release
Guillaume, I have to outstanding patches: FELIX-2327 FELIX-2330. Thanks, Jarek On Fri, May 14, 2010 at 10:13 AM, Guillaume Nodet gno...@gmail.com wrote: All the snapshots dependencies have been released. I'll try to do the release next week (but i'm travelling), but feel free to ping if there is any outstanding patch to apply. On Thu, Apr 29, 2010 at 20:50, Guillaume Nodet gno...@gmail.com wrote: I've been staging a bunch of releases in preparation of the karaf release. If there are any karaf pending issues that should be applied before the release, let me know to make sure they are included. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (FELIX-2330) Uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids
Uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids -- Key: FELIX-2330 URL: https://issues.apache.org/jira/browse/FELIX-2330 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Jarek Gawor Fix For: karaf 1.6.0 The uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2330) Uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids
[ https://issues.apache.org/jira/browse/FELIX-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2330: --- Attachment: FELIX-2330.patch Updates to uninstall, refresh, and resolve osgi shell commands to work with multiple bundles. Uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids -- Key: FELIX-2330 URL: https://issues.apache.org/jira/browse/FELIX-2330 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Jarek Gawor Fix For: karaf 1.6.0 Attachments: FELIX-2330.patch The uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2327) Disable and delay Jline terminal initialization
Disable and delay Jline terminal initialization --- Key: FELIX-2327 URL: https://issues.apache.org/jira/browse/FELIX-2327 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Jarek Gawor Fix For: karaf 1.6.0 Sometimes on different OSes and terminals, the initialization of Jline terminal can cause all kinds of weird side effects on the actual terminal. Therefore, there should be a way disable Jline terminal initialization and just use the standard Java terminal (i.e. use jline.UnsupportedTerminal). Also, right now, even though the karaf.startLocalConsole = false, the Jline terminal will be initialized. The Jline terminal should only be initialized when needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2327) Disable and delay Jline terminal initialization
[ https://issues.apache.org/jira/browse/FELIX-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2327: --- Attachment: FELIX-2327.patch Patch that allows to 1) disable the Jline terminal initialization (via passing Djline.terminal=jline.UnsupportedTerminal system property) and 2) delay the Jline terminal initialization. Disable and delay Jline terminal initialization --- Key: FELIX-2327 URL: https://issues.apache.org/jira/browse/FELIX-2327 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Jarek Gawor Fix For: karaf 1.6.0 Attachments: FELIX-2327.patch Sometimes on different OSes and terminals, the initialization of Jline terminal can cause all kinds of weird side effects on the actual terminal. Therefore, there should be a way disable Jline terminal initialization and just use the standard Java terminal (i.e. use jline.UnsupportedTerminal). Also, right now, even though the karaf.startLocalConsole = false, the Jline terminal will be initialized. The Jline terminal should only be initialized when needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2320) Override default Karaf shell prompt
Override default Karaf shell prompt --- Key: FELIX-2320 URL: https://issues.apache.org/jira/browse/FELIX-2320 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Jarek Gawor As part of branding/customization it would be nice to override the prompt of the Karaf shell. Right now there is no way to override it when Karaf starts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Karaf snapshots
Hi, Does anyone know what's going on with Karaf snapshots? It looks like the jar, pom files are not getting updated since March 17th. For example, take a look at https://repository.apache.org/snapshots/org/apache/felix/karaf/jaas/org.apache.felix.karaf.jaas.boot/1.5.0-SNAPSHOT/. Thanks, Jarek
Re: Framework trunk
On Sun, Mar 21, 2010 at 4:30 AM, Richard S. Hall he...@ungoverned.org wrote: On 3/9/10 10:26, Richard S. Hall wrote: Just a follow up...I think I see what is going wrong here...not exactly sure how I will fix it yet, but I see the issue at any rate. In short, the new resolver thinks there is a conflict because the two exports are different capabilities, but since they come from the same bundle this isn't really a conflict. So, I will need to put some sort of check in there to special case this situation I think. Hopefully, I will have a fix tomorrow. Sorry that this took me a little longer than I anticipated, but I just committed what I believe is a fix for this issue. The example bundles now resolve for me. I have deployed new snapshots for framework and main that include this fix and fixes for a few other issues. Let me know if you still have issues. Great! I tested a few things in Geronimo with latest framework and things do appear to be working much better now. Thanks a lot, Jarek
[jira] Created: (FELIX-2196) Karaf uses old version of Aries artifacts
Karaf uses old version of Aries artifacts - Key: FELIX-2196 URL: https://issues.apache.org/jira/browse/FELIX-2196 Project: Felix Issue Type: Bug Components: Karaf Reporter: Jarek Gawor In trunk, Karaf uses 1.0.0-SNAPSHOT version for Aries artifacts but the latest version is 0.1-SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2196) Karaf uses old version of Aries artifacts
[ https://issues.apache.org/jira/browse/FELIX-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2196: --- Attachment: FELIX-2196.patch Karaf uses old version of Aries artifacts - Key: FELIX-2196 URL: https://issues.apache.org/jira/browse/FELIX-2196 Project: Felix Issue Type: Bug Components: Karaf Reporter: Jarek Gawor Attachments: FELIX-2196.patch In trunk, Karaf uses 1.0.0-SNAPSHOT version for Aries artifacts but the latest version is 0.1-SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Framework trunk
Hi, In Geronimo we also running into some problems with the latest framework/resolver. Specifically, a bundle that exports the same package with different versions seems to be causing problems. You can reproduce the problem we are seeing by installing the following bundles: http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.configadmin/1.2.4/org.apache.felix.configadmin-1.2.4.jar http://repo2.maven.org/maven2/org/apache/felix/org.apache.felix.eventadmin/1.2.2/org.apache.felix.eventadmin-1.2.2.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-api/1.4.1-SNAPSHOT/pax-logging-api-1.4.1-20100213.165007-16.jar http://repository.ops4j.org/mvn-snapshots/org/ops4j/pax/logging/pax-logging-service/1.4.1-SNAPSHOT/pax-logging-service-1.4.1-20100213.165007-16.jar http://repo2.maven.org/maven2/org/apache/mina/mina-core/2.0.0-RC1/mina-core-2.0.0-RC1.jar When starting the mina-core package you'll see ResolveException: Constraint violation for package 'org.slf4j.helpers' Same set of bundles resolve/start fine on Felix 2.0.4 or Equinox. Jarek On Fri, Mar 5, 2010 at 7:33 AM, David Bosschaert david.bosscha...@gmail.com wrote: Yes, it's quite simple to reproduce. 1. Check out CXF-DOSGi from http://svn.apache.org/repos/asf/cxf/dosgi/trunk 2. First simply do a build with 'mvn install' from the root to get everything ready (you may have to set MAVEN_OPTS=-Xmx512m) 3. cd into systests2/multi-bundle 4. Then run: 'mvn install -Dtest=TestDiscoveryRountrip' from there. You will see that it runs some test (which uses a fairly large number of bundles). It's currently configured to use Equinox via Pax Exam. 5. Applying the attached patch will change it to use Felix. 6. Run: 'mvn install -Dtest=TestDiscoveryRountrip' again, and you'll see that just after 'Welcome to Felix' it hangs. Cheers, David On 3 March 2010 17:30, Richard S. Hall he...@ungoverned.org wrote: On 3/3/10 12:13 PM, David Bosschaert wrote: Nice :) I've had lots of hangs (or extremely long resolves) in the CXF-DOSGi system tests, which run using Pax Exam. Does anyone know how to get Pax Exam to use this latest build? Currently I'm using: CoreOptions.frameworks(CoreOptions.felix()) to simply select felix... If you can find a simple way to reproduce any long resolves, let me know since I'd like to play with them... - richard Thanks, David On 3 March 2010 16:55, Richard S. Hallhe...@ungoverned.org wrote: For those using framework from trunk, I've merged work from my sandbox into the trunk...the changes are fairly substantial. The changes are not complete and the API will likely be in flux for a while, but the framework should be reasonably stable (i.e., still passing the CT). The big change for now is the introduction of a new resolver implementation. If you are someone experiencing hangs from long resolver cycles, feel free to try the snapshot and see if it makes a difference for you. In fact, any usage and reporting of issues would be helpful. Thanks. - richard p.s. Currently, I am unable to publish a snapshot, but I will try to do that later (for the time being you can build from trunk).
[jira] Updated: (FELIX-1951) The SchemaObr.xsd in bundleplugin is incomplete
[ https://issues.apache.org/jira/browse/FELIX-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-1951: --- Attachment: FELIX-1951.patch The attached patch includes some updates to SchemaObr.xsd that allows the generated repository.xml to be validated against the schema. For example: $ xmllint --noout --schema bundleplugin/src/main/resources/SchemaObr.xsd ~/.m2/repository/repository.xml /home/gawor/.m2/repository/repository.xml validates The SchemaObr.xsd in bundleplugin is incomplete --- Key: FELIX-1951 URL: https://issues.apache.org/jira/browse/FELIX-1951 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR), Maven Bundle Plugin Reporter: Jarek Gawor Attachments: FELIX-1951.patch The SchemaObr.xsd in bundleplugin is incomplete. It's missing a few elements and attributes and the repository.xml generated by maven-bundle-plugin does not validate against it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1810) Improvements to Main startup class
[ https://issues.apache.org/jira/browse/FELIX-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-1810: --- Attachment: (was: FELIX-1810.patch) Improvements to Main startup class -- Key: FELIX-1810 URL: https://issues.apache.org/jira/browse/FELIX-1810 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Jarek Gawor Assignee: Guillaume Nodet Attachments: FELIX-1810.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1810) Improvements to Main startup class
[ https://issues.apache.org/jira/browse/FELIX-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-1810: --- Attachment: FELIX-1810.patch Slightly updated patch. It contains additional improvement to copySystemProperties() function to copy all system properties that start with org.osgi.framework. name to config properties. Improvements to Main startup class -- Key: FELIX-1810 URL: https://issues.apache.org/jira/browse/FELIX-1810 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Jarek Gawor Assignee: Guillaume Nodet Attachments: FELIX-1810.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1810) Improvements to Main startup class
Improvements to Main startup class -- Key: FELIX-1810 URL: https://issues.apache.org/jira/browse/FELIX-1810 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Jarek Gawor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1810) Improvements to Main startup class
[ https://issues.apache.org/jira/browse/FELIX-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-1810: --- Attachment: FELIX-1810.patch The attached patch has the following improvements: 1) Adds getFramework() method to return the created framework instance. This will be useful for subclasses on the Main class. 2) Minor exception handling improvements. For example, ensures the right error message is displayed when the framework fails to start up or stop, and avoids NPE when the framework fails to start up. Improvements to Main startup class -- Key: FELIX-1810 URL: https://issues.apache.org/jira/browse/FELIX-1810 Project: Felix Issue Type: Improvement Components: Karaf Reporter: Jarek Gawor Attachments: FELIX-1810.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
