You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Chris Custine <cc...@apache.org> on 2009/10/09 00:36:00 UTC
[DISCUSS] Bundle refresh, optional imports, etc
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
Re: [DISCUSS] Bundle refresh, optional imports, etc
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, I don't have much problems to reverse the option semantic.
On Tue, Oct 13, 2009 at 11:49, Chris Custine <ch...@gmail.com> wrote:
> 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 <gn...@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 <cc...@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
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Bundle refresh, optional imports, etc
Posted by Chris Custine <ch...@gmail.com>.
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 <gn...@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 <cc...@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
>
Re: [DISCUSS] Bundle refresh, optional imports, etc
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Guillaume,
thanks for the update. I will make some tries tomorrow and keep you posted.
Regards
JB
Guillaume Nodet 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 <cc...@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
>>
>
>
>
Re: [DISCUSS] Bundle refresh, optional imports, etc
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <cc...@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
Re: [DISCUSS] Bundle refresh, optional imports, etc
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Oct 9, 2009 at 06:46, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi,
>
> Maybe we can add a kind of scanner feature registering the bundles
> containing optional import.
> The scanner stores a map<Bundle, OptionalImport> and when at least one of
> the optional import change, the scanner fires a bundle redeployment.
> It can be an extension of the karaf deployer.
Not sure, this would not work with bundles that have not been deployed
through features.
I'd rather do that when a feature is installed and see if there are
any unsolved optional imports at that time in the system.
> @Guillaume, I have looking into the Blueprint specification but I can't see
> anything around "dynamic" optional import management. I guess that it's core
> deployment related (not really dynamic module), correct ?
Imports and dynamic imports are specified in the OSGi Core 4.x spec.
> Anyway, I'm agree with Chris, we need to find a way at least to inform the
> users of an optional import has changed and that he has to redeploy the
> bundles that use it.
>
> Regards
> JB
>
> Chris Custine 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
Re: [DISCUSS] Bundle refresh, optional imports, etc
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
Maybe we can add a kind of scanner feature registering the bundles
containing optional import.
The scanner stores a map<Bundle, OptionalImport> and when at least one
of the optional import change, the scanner fires a bundle redeployment.
It can be an extension of the karaf deployer.
@Guillaume, I have looking into the Blueprint specification but I can't
see anything around "dynamic" optional import management. I guess that
it's core deployment related (not really dynamic module), correct ?
Anyway, I'm agree with Chris, we need to find a way at least to inform
the users of an optional import has changed and that he has to redeploy
the bundles that use it.
Regards
JB
Chris Custine 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
>
Re: [DISCUSS] Bundle refresh, optional imports, etc
Posted by Charles Moulliard <cm...@gmail.com>.
Very interesting post and discussion.
>From a user point of view, the existing situation is really paint
full. As mentioned, we don't know exactly which bundle has to
refreshed after an update (and certainly for bundles which are
spring/spring-DM aware). So, you spend your time to look in the cache
folder to check those for which refresh must be executed. So, warning
option is not a must.
Another point that I think interesting to mention is to have the
possibility to update a feature and refresh it. For a project, you
will most probably design infrastructure bundles that you will package
in features and separately, you will prepare one or several features
for your project. When you would like to update "globally" your
project, you must now update (and sometimes refresh) each bundle
individually. This is time consuming and error prone.
When Apache Felix Karaf will move from the sphere of the development
team to infrastructure team, you cannot imagine that they will spend
their time to check wich bundle must be updated/refreshed. They need a
function/command who will allow us (like for WAR/EAR update in j2EE
server) to update a project globally even if sometimes we will ask us
to update bundle individually.
Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard
On Fri, Oct 9, 2009 at 8:53 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> I like the idea to at least warn the user. Maybe this could be a flag
> on the command, i.e. auto-refresh the needed bundles. If this flag
> is not set up, we would print a warning in the console instead.
>
> Another thing I was thinking about and started to implement at some
> point, is to have a batched feature installation, which would solve
> part of the problem, at least for initial provisioning. The idea
> would be to defer the start of the bundles at the end, i.e. when all
> bundles have been installed. This would allow wiring all optional
> imports in a set of features. This could also be done when installing
> a feature that has dependency on other features. This would thus
> reduce the number of refresh that need to be done afterwards, and I
> think this solution can be done in addition to the above.
>
> For our bundles, another way for optional imports is to back them with
> dynamic imports, so that the wiring is done early if possible and
> lately if not. I haven't actually tried that, but had a chat with
> Richard Hall that this should not really be a problem. The only
> downside is that it takes a bit more time before throwing a
> ClassNotFoundException when loading a class from an unsolved optional
> import package. But that would only work for servicemix bundles.
>
> On Fri, Oct 9, 2009 at 00:36, Chris Custine <cc...@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
>
Re: [DISCUSS] Bundle refresh, optional imports, etc
Posted by Guillaume Nodet <gn...@gmail.com>.
I like the idea to at least warn the user. Maybe this could be a flag
on the command, i.e. auto-refresh the needed bundles. If this flag
is not set up, we would print a warning in the console instead.
Another thing I was thinking about and started to implement at some
point, is to have a batched feature installation, which would solve
part of the problem, at least for initial provisioning. The idea
would be to defer the start of the bundles at the end, i.e. when all
bundles have been installed. This would allow wiring all optional
imports in a set of features. This could also be done when installing
a feature that has dependency on other features. This would thus
reduce the number of refresh that need to be done afterwards, and I
think this solution can be done in addition to the above.
For our bundles, another way for optional imports is to back them with
dynamic imports, so that the wiring is done early if possible and
lately if not. I haven't actually tried that, but had a chat with
Richard Hall that this should not really be a problem. The only
downside is that it takes a bit more time before throwing a
ClassNotFoundException when loading a class from an unsolved optional
import package. But that would only work for servicemix bundles.
On Fri, Oct 9, 2009 at 00:36, Chris Custine <cc...@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