felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Munteanu <rmunt...@adobe.com>
Subject RE: Enhanced Apache Felix / JRebel integration
Date Fri, 30 Mar 2012 13:14:07 GMT

> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@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. 



> -> 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/
> >
View raw message