Re: Enhanced Apache Felix / JRebel integration

[Richard S. Hall]

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/