Over the past couple of days I started thinking that by default we should just log something informative (if running as server) or display some feedback to the user if they are using the console. I worry that the danger of automatically refreshing blueprint or spring and causing all contexts to reload makes it kind of intrusive. I was thinking that the auto refresh option could be a command option when installing bundles or features from the command line, or a global option in a config file with the default being normal behavior.
I'll test out your new code with some of the scenarios I ran across last week and follow up. Thanks, Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Tue, Oct 13, 2009 at 12:28 AM, Guillaume Nodet <gno...@gmail.com> wrote: > FWIW, I've started working on that yesterday and committed some > enhacnements. > The strategy is the following: when installing a feature, grab a list > of all installed bundles and all bundles part of the feature (i.e. > bundles that were already installed before). When all bundles (and > bundles from features dependencies) have been installed, analyze the > old bundles to see if there is any matching requirements that could be > solved by newly installed bundles. If so, refresh those bundles. The > auto-refresh can be turned off using an option on the command. > > It seems to work quite well, but there is one potential problem: the > blueprint implementation has an optional dependency on cglib which is > not satisfied at start time. So that you can end up refreshing the > blueprint bundle and cause the whole (nearly) karaf to restart ... So > we might want to provision cglib initially to make sure this does not > happen. > > Anyway, feel free to give it a try and provide feedback. > > > On Fri, Oct 9, 2009 at 00:36, Chris Custine <ccust...@apache.org> wrote: > > Hi All, > > I have been looking at several issues this week that all relate to the > > problem of refreshing bundles with optional imports. Guillaume has a > couple > > of issues opened related to this in Karaf: > > https://issues.apache.org/jira/browse/FELIX-1074 > > https://issues.apache.org/jira/browse/FELIX-1689 > > > > The real problem seems to be that users expect to be able to install and > > start bundles without much manual intervention. But with the optional > > imports case, there has to be a refresh on the bundle to pick up the > newly > > installed package. So generally speaking, these issues are being > reported > > as bugs when they are actually normal behavior. > > > > So the question is, how do we solve this in a nice user friendly way? > Right > > now, I am leaning toward Guillaume's suggestion to look through bundles > with > > optional imports on newly installed packages and refresh them very > > selectively. However, I can imagine that some people would not like this > to > > be a default behavior and want more control over their deployments. It > also > > seems like refreshing things like Spring AOP can cause a lot of thrashing > as > > there are a lot of downstream bundles that will also refresh > > (Spring-DM->Spring-Core->JBI components). > > > > So I think we need to determine what approach to take and document it so > > that we are prepared when people run into these issues. Seems like our > > options are to report more detailed logs or display a warning on the > console > > for the admin to manually refresh, or we try to do it in an automated > > fashion when features/bundles are installed. > > > > BTW, I know this is a Karaf issue now, but it seems to happen to us a lot > in > > SMX so I wanted to start a discussion here for anyone not following Karaf > > mailing list. > > > > WDYT? > > > > Chris > > -- > > Chris Custine > > FUSESource :: http://fusesource.com > > My Blog :: http://blog.organicelement.com > > Apache ServiceMix :: http://servicemix.apache.org > > Apache Directory Server :: http://directory.apache.org > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
