Re: framework snapshot
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] [Updated] (FELIX-3356) Objectweb ASM Clashes with IPojo
[ https://issues.apache.org/jira/browse/FELIX-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3356: - Fix Version/s: (was: ipojo-manipulator-1.8.4) (was: ipojo-core-1.8.2) (was: ipojo-composite-1.8.2) ipojo-manipulator-1.8.6 Affects Version/s: (was: ipojo-manipulator-1.8.2) (was: iPOJO-1.8.0) ipojo-manipulator-1.8.4 Objectweb ASM Clashes with IPojo Key: FELIX-3356 URL: https://issues.apache.org/jira/browse/FELIX-3356 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-manipulator-1.8.4 Reporter: Bob Ziuchkovski Assignee: Clement Escoffier Priority: Minor Fix For: ipojo-manipulator-1.8.6 Ipojo automatically imports org.apache.felix.ipojo.architecture for bundles that it manages, and org.apache.felix.ipojo.architecture is marked as using org.objectweb.asm. This creates conflicts for any ipojo-managed bundle that wishes to import and use a different objectweb asm version (i.e. 4.0) for non-ipojo purposes. See the below output for an example: Error executing command: Error starting bundles: Unable to start bundle 107: Uses constraint violation. Unable to resolve bundle revision test.service [107.0] because it is exposed to package 'org.objectweb.asm' from bundle revisions org.objectweb.asm.all [98.0] and org.apache.felix.ipojo [99.0] via two dependency chains. Chain 1: test.service [107.0] import: ((osgi.wiring.package=org.objectweb.asm)(version=4.0.0)(!(version=5.0.0))) | export: osgi.wiring.package=org.objectweb.asm org.objectweb.asm.all [98.0] Chain 2: test.service [107.0] import: ((osgi.wiring.package=org.apache.felix.ipojo.architecture)(version=1.8.0)) | export: osgi.wiring.package=org.apache.felix.ipojo.architecture; uses:=org.objectweb.asm export: osgi.wiring.package=org.objectweb.asm org.apache.felix.ipojo [99.0] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3286) Update POM to use the new parent
[ https://issues.apache.org/jira/browse/FELIX-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-3286: - Fix Version/s: (was: ipojo-manipulator-1.8.4) (was: ipojo-core-1.8.2) (was: ipojo-composite-1.8.2) ipojo-manipulator-1.8.6 Affects Version/s: ipojo-manipulator-1.8.4 Update POM to use the new parent Key: FELIX-3286 URL: https://issues.apache.org/jira/browse/FELIX-3286 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: ipojo-manipulator-1.8.4 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-manipulator-1.8.6 -- 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
[VOTE] Release of the iPOJO Manipulator 1.8.4
Hi, It's time to cut a release of the iPOJO Manipulator project (1.8.4). This releases contains: * org.apache.felix.ipojo.manipulator 1.8.4 * maven-ipojo-plugin 1.8.4 * ipojo-ant-task 1.8.4 * bnd-ipojo-plugin 1.8.4 * manipulator-project 1.8.4 (the changelog is included below) Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-129/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 129 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours (at least). Regards, Clement Changelog: ** Bug * [FELIX-3297] - iPOJO Manipulator throws ClassNotFoundException * [FELIX-3359] - Turn around to avoid to use the split verifier on Java 7 * [FELIX-3389] - Bnd iPOJO Plugin ignores annotated components * [FELIX-3391] - Unexpected warning when using bnd-ipojo-plugin ** Improvement * [FELIX-3384] - Ensure maven-ipojo-plugin is thread-safe for parallel maven builds
[jira] [Commented] (FELIX-3152) JMX as web console feature
[ https://issues.apache.org/jira/browse/FELIX-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242182#comment-13242182 ] Valentin Valchev commented on FELIX-3152: - Hmm, I don't see that plugin imported in the source tree? Are there any licensing issues that prevented us from doing that? JMX as web console feature -- Key: FELIX-3152 URL: https://issues.apache.org/jira/browse/FELIX-3152 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Christanto Labels: jmx, webconsole Attachments: org.apache.felix.webconsole.plugins.jmx.zip The attached file is a source code that implement JMX client as felix web console. -- 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-2896) Add support for bundle info providers
[ https://issues.apache.org/jira/browse/FELIX-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242184#comment-13242184 ] Valentin Valchev commented on FELIX-2896: - Another related issue that could be implemented as BundleInfoProvider : https://issues.apache.org/jira/browse/FELIX-3140 Add support for bundle info providers - Key: FELIX-2896 URL: https://issues.apache.org/jira/browse/FELIX-2896 Project: Felix Issue Type: New Feature Components: Web Console Affects Versions: webconsole-3.1.8 Reporter: Carsten Ziegeler Currently all information displayed about a bundle is coded into the bundle list plugin. We could improve this by defining a BundleInfoProvider interface which might return a map for a bundle. The bundle list plugin will query all providers and display all key/value pairs as additional information about the bundle. Open questions: - how to we handle localization? - how can a bundle provide this service without having a dependency to the web console api? -- 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-3402) DependencyManager stop can trigger IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/FELIX-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bram de Kruijff updated FELIX-3402:
---
Component/s: Dependency Manager
DependencyManager stop can trigger IndexOutOfBoundsException
Key: FELIX-3402
URL: https://issues.apache.org/jira/browse/FELIX-3402
Project: Felix
Issue Type: Bug
Components: Dependency Manager
Affects Versions: dependencymanager-3.0.0
Reporter: Bram de Kruijff
Assignee: Marcel Offermans
Attachments: FELIX-3402-sync.patch
DependencyManager.clear(), pre FELIX-3042 known as
DependencyActivatorBase.cleanup(), iterates over unprotected list determining
size only at the start.
{code}
build 22-Mar-2012 10:03:08java.lang.IndexOutOfBoundsException: Index: 66,
Size: 66
build 22-Mar-2012 10:03:08at
java.util.ArrayList.RangeCheck(ArrayList.java:547)
build 22-Mar-2012 10:03:08at
java.util.ArrayList.get(ArrayList.java:322)
build 22-Mar-2012 10:03:08at
java.util.Collections$SynchronizedList.get(Collections.java:1816)
build 22-Mar-2012 10:03:08at
java.util.Collections$UnmodifiableList.get(Collections.java:1154)
build 22-Mar-2012 10:03:08at
org.apache.felix.dm.DependencyActivatorBase.cleanup(DependencyActivatorBase.java:301)
build 22-Mar-2012 10:03:08at
org.apache.felix.dm.DependencyActivatorBase.stop(DependencyActivatorBase.java:90)
build 22-Mar-2012 10:03:08at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:663)
build 22-Mar-2012 10:03:08at
org.apache.felix.framework.Felix.stopBundle(Felix.java:2361)
build 22-Mar-2012 10:03:08at
org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:980)
build 22-Mar-2012 10:03:08at
org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:967)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3409) with permissions enabled, AbstractComponentManager.verifyDependencyManagers is wrong.
[ https://issues.apache.org/jira/browse/FELIX-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-3409. -- Resolution: Fixed Fix Version/s: scr-1.6.2 Assignee: Felix Meschberger Oh my ... Thanks for providing the patch. I have applied in Rev. 1307344. with permissions enabled, AbstractComponentManager.verifyDependencyManagers is wrong. - Key: FELIX-3409 URL: https://issues.apache.org/jira/browse/FELIX-3409 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.2 Reporter: David Jencks Assignee: Felix Meschberger Fix For: scr-1.6.2 Attachments: FELIX-3409.diff If running with permissions and the bundle doesn't have permissions to look up services, then AbstractComponentManager.verifyDependencyManagers returns whether the _last_ DependencyManager is optional, not whether _all_ the DependencyManagers are optional. -- 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-3410) ImmediateComponentManager should use any non-ignored configuration to try to activate a component.
[ https://issues.apache.org/jira/browse/FELIX-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242215#comment-13242215 ] Felix Meschberger commented on FELIX-3410: -- Oh, quite right. I missed that detail. Thanks for providing the patch. ImmediateComponentManager should use any non-ignored configuration to try to activate a component. -- Key: FELIX-3410 URL: https://issues.apache.org/jira/browse/FELIX-3410 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.2 Reporter: David Jencks Attachments: FELIX-3410.diff ImmediateComponentManager.reconfigure only tries to activate an unsatisfied component if the configuration is require. However, if configuration is optional (i.e. not ignored) it could still change target properties and make the component satisfied so it can be activated. -- 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-3415) Disable update button if bundle location URL is invalid
Disable update button if bundle location URL is invalid
---
Key: FELIX-3415
URL: https://issues.apache.org/jira/browse/FELIX-3415
Project: Felix
Issue Type: Improvement
Components: Web Console
Affects Versions: webconsole-3.1.8
Reporter: Felix Meschberger
When clicking the update button on any bundle, the bundle location (or the
bundle's update location header) is taken as an URL to retrieve a bundle
update. If the bundle's update location header is not set and the bundle
location is not a valid URL, this of course fails.
We should probably disable the update button if the bundle location URL fails
to be created:
try {
new URL(bundleLocation);
updatePossible = true;
} catch (MalformedURLException mue) {
updatePossible = false;
}
--
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: [VOTE] Release of the iPOJO Manipulator 1.8.4
[X] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Non binding --G 2012/3/30 Clement Escoffier clement.escoff...@gmail.com: Hi, It's time to cut a release of the iPOJO Manipulator project (1.8.4). This releases contains: * org.apache.felix.ipojo.manipulator 1.8.4 * maven-ipojo-plugin 1.8.4 * ipojo-ant-task 1.8.4 * bnd-ipojo-plugin 1.8.4 * manipulator-project 1.8.4 (the changelog is included below) Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-129/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 129 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours (at least). Regards, Clement Changelog: ** Bug * [FELIX-3297] - iPOJO Manipulator throws ClassNotFoundException * [FELIX-3359] - Turn around to avoid to use the split verifier on Java 7 * [FELIX-3389] - Bnd iPOJO Plugin ignores annotated components * [FELIX-3391] - Unexpected warning when using bnd-ipojo-plugin ** Improvement * [FELIX-3384] - Ensure maven-ipojo-plugin is thread-safe for parallel maven builds
RE: Enhanced Apache Felix / JRebel integration
-Original Message- From: Richard S. Hall [mailto:he...@ungoverned.org] Sent: Thursday, March 29, 2012 6:53 PM To: dev@felix.apache.org Subject: Re: Enhanced Apache Felix / JRebel integration On 3/29/12 6:45, Robert Munteanu wrote: Hi, I am looking into enhancing the integration between Apache Felix and the JRebel [1] JVM agent. If you're not familiar with JRebel, it's a java agent which allows classes loaded into the JVM to be redefined as soon as they are recompiled e.g. in an IDE. For more information about its features, see [2]. JRebel already has basic support for Apache Felix by allowing classes for a deployed bundle to be reloaded without requiring a bundle repackage and reinstall. What I want to contribute is support for components managed using declarative services. The basic principle is that given a bundle which contains service components descriptors, watch for changes to those component descriptors and refresh the components when the respective descriptors have changed. I have taken a quick look at both JRebel and Felix to see how an implementation should look like. JRebel offers support for detecting class changes, but not generic filesystem changes. Therefore I'd have to rely on Felix code ( in org.apache.felix.scr ? ) to detect - when a bundle with component descriptors is deployed and start watching for changes to the descriptors - when changes to the mentioned descriptors are detected refresh the components Is there some reason you need to refresh at the class level as opposed to the bundle level? If the bundle level was sufficient then it seems like this scenario becomes much simpler. My intention is to first refresh the whole bundle when a component descriptor is changed. If needed I will look into fine-grained refreshes but that's not on my immediate plan. Also, what do you mean by refresh the components above? Do you specifically mean re-load the class bytes? If so, how do you know that changes to the descriptor require re-loading the class bytes or are you just assuming it does? By refresh I mean a deactivate/activate operation taking into account whether a component is marked as immediate or not. Fortunately refreshing the actual class bytes is handled by the 'core' JRebel functionality when the class file changes. Additionally, it seems you might be confused about the responsibility of some tasks. For example, SCR doesn't look for changes in component descriptors at all, it simply listens for bundles to be activated. Listening to changes in the component descriptor would have to hook into the build process somehow. By and large, none of the Felix subprojects are involved in the build process other than the Maven Bundle plugin. I have considered hooking into the maven-bundle-plugin as well, but I have no idea on how to notify Felix that a bundle needs to be refreshed or even send a custom event which I can handle myself. Thanks, Robert - richard I would like to validate that this is at all possible within Apache Felix and to ask which are the best places to start looking for adding the JRebel functionality. Any thoughts/pointers on how to best start developing this would be greatly appreciated. If this is feasible, I intend to develop this as a separate JRebel plugin and contribute it to the Apache Felix project. Thanks, Robert [1]: http://zeroturnaround.com/jrebel/ [2]: http://zeroturnaround.com/jrebel/features/
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 on
Re: Enhanced Apache Felix / JRebel integration
On 3/30/12 9:14, Robert Munteanu wrote: -Original Message- From: Richard S. Hall [mailto:he...@ungoverned.org] Sent: Thursday, March 29, 2012 6:53 PM To: dev@felix.apache.org Subject: Re: Enhanced Apache Felix / JRebel integration On 3/29/12 6:45, Robert Munteanu wrote: Hi, I am looking into enhancing the integration between Apache Felix and the JRebel [1] JVM agent. If you're not familiar with JRebel, it's a java agent which allows classes loaded into the JVM to be redefined as soon as they are recompiled e.g. in an IDE. For more information about its features, see [2]. JRebel already has basic support for Apache Felix by allowing classes for a deployed bundle to be reloaded without requiring a bundle repackage and reinstall. What I want to contribute is support for components managed using declarative services. The basic principle is that given a bundle which contains service components descriptors, watch for changes to those component descriptors and refresh the components when the respective descriptors have changed. I have taken a quick look at both JRebel and Felix to see how an implementation should look like. JRebel offers support for detecting class changes, but not generic filesystem changes. Therefore I'd have to rely on Felix code ( in org.apache.felix.scr ? ) to detect - when a bundle with component descriptors is deployed and start watching for changes to the descriptors - when changes to the mentioned descriptors are detected refresh the components Is there some reason you need to refresh at the class level as opposed to the bundle level? If the bundle level was sufficient then it seems like this scenario becomes much simpler. My intention is to first refresh the whole bundle when a component descriptor is changed. If needed I will look into fine-grained refreshes but that's not on my immediate plan. Refreshing the bundle would definitely be easier. Also, what do you mean by refresh the components above? Do you specifically mean re-load the class bytes? If so, how do you know that changes to the descriptor require re-loading the class bytes or are you just assuming it does? By refresh I mean a deactivate/activate operation taking into account whether a component is marked as immediate or not. Fortunately refreshing the actual class bytes is handled by the 'core' JRebel functionality when the class file changes. Additionally, it seems you might be confused about the responsibility of some tasks. For example, SCR doesn't look for changes in component descriptors at all, it simply listens for bundles to be activated. Listening to changes in the component descriptor would have to hook into the build process somehow. By and large, none of the Felix subprojects are involved in the build process other than the Maven Bundle plugin. I have considered hooking into the maven-bundle-plugin as well, but I have no idea on how to notify Felix that a bundle needs to be refreshed or even send a custom event which I can handle myself. If you use something like File Install and generate bundle's into a directory managed by File Install, it will automatically update and refresh the bundle when its JAR file changes, which would cause SCR to stop, then restart managing it. It's a little more coarse grained that what you want, but it should work out of the box with a lot less effort. - richard Thanks, Robert - richard I would like to validate that this is at all possible within Apache Felix and to ask which are the best places to start looking for adding the JRebel functionality. Any thoughts/pointers on how to best start developing this would be greatly appreciated. If this is feasible, I intend to develop this as a separate JRebel plugin and contribute it to the Apache Felix project. Thanks, Robert [1]: http://zeroturnaround.com/jrebel/ [2]: http://zeroturnaround.com/jrebel/features/
