I also recommend "EventAdminService" and just loose couple the "thing"
________________________________ From: [email protected] on behalf of Richard S. Hall Sent: Sat 8/29/2009 1:15 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] Circular Dependency You can break the common bundle down into more bundles to lessen the impact. If you can separate the interfaces to put them into the implementation bundles, then you should be able to separate them into different "common" bundles. Then only the bundles dependent upon a particular interface will be refreshed if that interfaces is updated. -> richard On 8/29/09 12:17, cato kato wrote: > I am asking these questions because I am trying to solve a little big > problem. > I have an application that contains 30 bundles. Each bundle has some > specific services that can be used by other bundles. So this produces > circular dependencies in the system. In order to prevent this > situation I put all interfaces in a common bundle. So there is no > circular dependency in the system. > > But when an update occurs in common bundle as you said all bundles > that uses common bundle must be refreshed. Because system refresh > takes long time (1-2 minute) in my system, I will lose many requests > in the system. I try to avoid this. One thing is I will allow circular > dependencies in the system. But I am not sure this will cause some > other mistakes because circular dependencies are not good. I also want > to learn is there a better solution that can solve this situation. > > Here is an example of my system > > A (this bundle counts events in the system, nearly all bundles uses this > bundle) > B (this bundle is a db pool mechanism, nearly all bundles uses this bundle) > C (this bundle logs system events to file and db, nearly all bundles > uses this bundle) > > C uses both A and B > A uses B and C > B uses A and C > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
<<winmail.dat>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
