RE: Enhanced Apache Felix / JRebel integration
> -Original Message- > From: Marcel Offermans [mailto:marcel.offerm...@luminis.nl] > Sent: Thursday, April 19, 2012 4:51 PM > To: dev@felix.apache.org > Subject: Re: Enhanced Apache Felix / JRebel integration > > Hello Robert, > Hi Marcel, (snip) > > Did you ever look at BndTools? It is a lot quicker in this respect: as > soon as you save a source file, directly after Eclipse compiled it, a > bundle is generated and if you had a framework already running inside > Eclipse, it is directly updated. No manual steps whatsoever, and > usually done within a second or two. > > You cannot make it much faster unless you take shortcuts that at some > point will break (ie. not deploying things "a bundle at a time"). > > Greetings, Marcel BndTools has an interesting approach, I'll take a look. Thanks. Robert
Re: Enhanced Apache Felix / JRebel integration
Hello Robert, On Apr 19, 2012, at 14:34 , Robert Munteanu wrote: >> -Original Message- >> From: Felix Meschberger [mailto:fmesc...@adobe.com] >> Bundle deployment is generally really fast -- unless your bundle is >> large and has a complex import/export list, which would make that >> bundle a bad bundle by definition ;-) > > Agreed, bundle deployment is usually fast. However, the whole deployment > process is not instant for me. My use case is based on Sling, not Felix > standalone. > > I typically have to switch to the console and run something like 'mvn package > sling:install' or hunt for the Maven build command in my IDE and click it. > And all in all the process can take 10-20 seconds. All of that contrasted > with saving a class and then refreshing a web page seems a lot. Did you ever look at BndTools? It is a lot quicker in this respect: as soon as you save a source file, directly after Eclipse compiled it, a bundle is generated and if you had a framework already running inside Eclipse, it is directly updated. No manual steps whatsoever, and usually done within a second or two. You cannot make it much faster unless you take shortcuts that at some point will break (ie. not deploying things "a bundle at a time"). Greetings, Marcel
RE: Enhanced Apache Felix / JRebel integration
> -Original Message- > From: Felix Meschberger [mailto:fmesc...@adobe.com] > Sent: Tuesday, April 17, 2012 12:49 PM > To: dev@felix.apache.org > Subject: Re: Enhanced Apache Felix / JRebel integration > > > Perhaps I can explain better with an example rather than in abstract > terms, so here's what I want to achieve in terms of development > experience: > > > > 1. Start Apache Felix with SCR capabilities and with the JRebel agent > > 2. Deploy a bundle with a JRebel configuration attached > > 3. Start listening for changes to the declared SCR descriptors of the > bundle > > That's part of JRebel support ? Yes, and already available without any changes. > > > 4. When the SCR descriptors change on disk, call > PackageAdmin.refreshPackages() > > This is probably not adequate (or even required): What you would have > to do is just stop and start the bundles. refreshPackages would only be > required if you want the wires of the bundle refresh. Right, thanks. > > > > > I can safely do (4) the packages since JRebel already ensures that I > will get the most current version of the class without needing to > redeploy the bundle. I purposefully ignore how the changes will be made > for (3) since that's a different implementation topic. > > > > I am aware that this process does not make sense unless JRebel is > used, so that's why I'm trying to find out the best way of hooking into > the framework without the need to make invasive changes. > > The longer I think of it, the longer I think such a thing is really > futile ... > > Bundle deployment is generally really fast -- unless your bundle is > large and has a complex import/export list, which would make that > bundle a bad bundle by definition ;-) Agreed, bundle deployment is usually fast. However, the whole deployment process is not instant for me. My use case is based on Sling, not Felix standalone. I typically have to switch to the console and run something like 'mvn package sling:install' or hunt for the Maven build command in my IDE and click it. And all in all the process can take 10-20 seconds. All of that contrasted with saving a class and then refreshing a web page seems a lot. > I honestly fail to see the point of JRebel in an OSGi framework ... To rephrase what I've said above - it's not that fast, incremental developement is not supported by OSGi frameworks, it's that it's not fast enough for my goals. My tooling should be smart enough to 'refresh on save', without the need to ask it nicely to repackage and redeploy my bundle. There's also a blog post from one of the JRebel devs regarding how JRebel and OSGi fit together [1]. However, I can see why you're skeptical and when I'll have a proof-of-concept I hope to have some hard numbers to support to difference in speed. Robert [1] http://zeroturnaround.com/blog/jrebel-vs-osgi-use-the-right-tool-for-the-right-job/ > > Regards > Felix > > > > > Robert > > > >> > >> -> 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/ > >>>>>
Re: Enhanced Apache Felix / JRebel integration
Hi, Am 13.04.2012 um 17:03 schrieb Robert Munteanu: 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. > > One of my (self-imposed) constraints is that this process should be > IDE-driven rather than build tool-driven. The main reason is performance - I > prefer not to repackage bundles on each change since that will take some > time. > > Instead, I prefer to react to filesystem changes myself and nicely ask the > Felix container to refresh a bundle if needed. As as far as I can see > fileinstall handles only configuration and jar files, not SCR descriptors and > I think that this is not something which belongs in the core fileinstall > bundle. > > Perhaps I can explain better with an example rather than in abstract terms, > so here's what I want to achieve in terms of development experience: > > 1. Start Apache Felix with SCR capabilities and with the JRebel agent > 2. Deploy a bundle with a JRebel configuration attached > 3. Start listening for changes to the declared SCR descriptors of the bundle That's part of JRebel support ? > 4. When the SCR descriptors change on disk, call > PackageAdmin.refreshPackages() This is probably not adequate (or even required): What you would have to do is just stop and start the bundles. refreshPackages would only be required if you want the wires of the bundle refresh. > > I can safely do (4) the packages since JRebel already ensures that I will get > the most current version of the class without needing to redeploy the bundle. > I purposefully ignore how the changes will be made for (3) since that's a > different implementation topic. > > I am aware that this process does not make sense unless JRebel is used, so > that's why I'm trying to find out the best way of hooking into the framework > without the need to make invasive changes. The longer I think of it, the longer I think such a thing is really futile ... Bundle deployment is generally really fast -- unless your bundle is large and has a complex import/export list, which would make that bundle a bad bundle by definition ;-) I honestly fail to see the point of JRebel in an OSGi framework ... Regards Felix > > Robert > >> >> -> 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/ >
RE: Enhanced Apache Felix / JRebel integration
> >> 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. One of my (self-imposed) constraints is that this process should be IDE-driven rather than build tool-driven. The main reason is performance - I prefer not to repackage bundles on each change since that will take some time. Instead, I prefer to react to filesystem changes myself and nicely ask the Felix container to refresh a bundle if needed. As as far as I can see fileinstall handles only configuration and jar files, not SCR descriptors and I think that this is not something which belongs in the core fileinstall bundle. Perhaps I can explain better with an example rather than in abstract terms, so here's what I want to achieve in terms of development experience: 1. Start Apache Felix with SCR capabilities and with the JRebel agent 2. Deploy a bundle with a JRebel configuration attached 3. Start listening for changes to the declared SCR descriptors of the bundle 4. When the SCR descriptors change on disk, call PackageAdmin.refreshPackages() I can safely do (4) the packages since JRebel already ensures that I will get the most current version of the class without needing to redeploy the bundle. I purposefully ignore how the changes will be made for (3) since that's a different implementation topic. I am aware that this process does not make sense unless JRebel is used, so that's why I'm trying to find out the best way of hooking into the framework without the need to make invasive changes. Robert > > -> 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/ > >>>
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/
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: 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. 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? 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. -> 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/
Enhanced Apache Felix / JRebel integration
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 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/
