On Fri, Sep 18, 2009 at 04:49, <[email protected]> wrote: > Author: chirino > Date: Fri Sep 18 02:49:21 2009 > New Revision: 816444 > > URL: http://svn.apache.org/viewvc?rev=816444&view=rev > Log: > - refactored FactoryFinder so that it Implementation is pluggable. > - made an OSGi friendly strategy for it using a BundleActivator (needs > testing) > > > Added: > activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/osgi/ > - copied from r816369, > servicemix/smx4/specs/trunk/locator/src/main/java/org/apache/servicemix/specs/locator/ > Removed: > > activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/osgi/OsgiLocator.java > Modified: > activemq/trunk/activemq-core/pom.xml > > activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/FactoryFinder.java > > activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/osgi/Activator.java > activemq/trunk/pom.xml >
<snipped> > > Modified: > activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/osgi/Activator.java > URL: > http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/osgi/Activator.java?rev=816444&r1=816369&r2=816444&view=diff > ============================================================================== > --- > activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/osgi/Activator.java > (original) > +++ > activemq/trunk/activemq-core/src/main/java/org/apache/activemq/util/osgi/Activator.java > Fri Sep 18 02:49:21 2009 > @@ -14,17 +14,22 @@ > * See the License for the specific language governing permissions and > * limitations under the License. > */ <snipped> > + private boolean isImportingUs(Bundle bundle) { > + try { > + // If that bundle can load our classes.. then it must be > importing us. > + return > bundle.loadClass(Activator.class.getName())==Activator.class; > + } catch (ClassNotFoundException e) { > + return false; > + } > + } This won't work in OSGi for several reasons. In OSGi, class visibility is controlled per package, not per bundle. So for a bundle to see the Activator class, it would have to explicitely import the org.apache.activemq.util.osgi package, else a ClassNotFoundException would be thrown. This looks like an unnecessary constraint to put on the bundles. As I said in the other thread, I think we should defer that for 5.4 and discuss that a bit more. For plugins, I think the best way would be to use the OSGi service registry for importing such plugins. i.e. a plugin would be registered in the OSGi registry with the interface it is supposed to implement (for example org.apache.activemq.transport.TransportFactory and with a property associated to the service which represents the name of the tramsport. This would then allow the FactoryFinder to find the transport in the OSGi registry. Also, using OSGi services would ensure class compatibility (i.e. if the plugin uses a different activemq version, activemq-core would not use it). We then have two problems to solve. The first one is to allow plugins to not have to deal too much with OSGi, and also not impose any constraints on people that write plugins that are not OSGi aware. So the registration of plugins can be done by a different bundle: this bundle would listen for newly started or stopped bundles and would register / unregister the plugin service accordingly. Last, we need to think about how we want to handle OSGi dynamics. The OSGi environment is really dynamic and bundles can come and go at any time. Thus we need to be prepared for: * starting a broker if some transports / discovery plugins are not available yet * react on the fact that a used plugin has just been stopped / uninstall One possible solution would be to use the same solution has done in blueprint / spring-dm. i.e. for a mandatory dependency, we first wait until the dependency is satisfied. One it is, we create a proxy for the OSGi service. If the OSGi service is unregistered and the proxy need to satisfy an invocation, we wait until a new service is available. Wait has a configurable timeout. This allow updating one transport for example without shutting down the whole broker. I don't have enough knowledge of activemq's internal, so maybe using proxies does not make sense at all (because all the plugins maintain a state that would be lost and cause data corruption or such things). So maybe this is not the solution, but we need to be prepared for such things, hence a solution must be discussed and found. > + > + private static class BundleWrapper { > + private final Bundle bundle; > + private final ArrayList<String> cachedServices = new > ArrayList<String>(); > + > + public BundleWrapper(Bundle bundle) { > + this.bundle = bundle; > } > } > } > > Modified: activemq/trunk/pom.xml > URL: > http://svn.apache.org/viewvc/activemq/trunk/pom.xml?rev=816444&r1=816443&r2=816444&view=diff > ============================================================================== > --- activemq/trunk/pom.xml (original) > +++ activemq/trunk/pom.xml Fri Sep 18 02:49:21 2009 > @@ -401,6 +401,13 @@ > </dependency> > > <dependency> > + <groupId>org.osgi</groupId> > + <artifactId>org.osgi.core</artifactId> > + <version>4.1.0</version> > + <scope>provided</scope> > + </dependency> > + > + <dependency> > <groupId>org.apache.hadoop.zookeeper</groupId> > <artifactId>zookeeper</artifactId> > <version>3.0.0</version> > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
