activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <chir...@gmail.com>
Subject Re: OSGi plugin discovery (was Re: svn commit: r816444 - in /activemq/trunk: ./ activemq-core/ activemq-core/src/main/java/org/apache/activemq/util/ activemq-core/src/main/java/org/apache/activemq/util/osgi/)
Date Fri, 18 Sep 2009 13:06:34 GMT
Yeah.  I guess we need to setup a couple of use cases / usage scenarios in
an integration test env.  Would love it if someone more familiar /w OSGi
could setup a module like that.
hint. hint. ;-)


On Fri, Sep 18, 2009 at 2:36 AM, Guillaume Nodet <gnodet@gmail.com> wrote:

> On Fri, Sep 18, 2009 at 04:49,  <chirino@apache.org> 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
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://fusesource.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message