<html><head>
      <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
   <title>Chapter&nbsp;1.&nbsp;Frequently Asked Questions</title><link rel="stylesheet" href="css/html.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.72.0"><link rel="start" href="faq.html" title="Eclipse Gemini Blueprint"><link rel="up" href="faq.html" title="Eclipse Gemini Blueprint"><link rel="prev" href="faq.html" title="Eclipse Gemini Blueprint"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="spring-osgi-faq"></a>Chapter&nbsp;1.&nbsp;Frequently Asked Questions</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="eclipse-springdm"></a>1.1.&nbsp;What's the relationship between Spring Dynamic Modules and Gemini Blueprint?</h2></div></div></div><p>Eclipse Gemini Blueprint is based on Spring Dynamic Modules 2.0 which has been migrated
        to the Eclipse Foundation. While the name and the packages have changed the internals are still the same; one
        will find both names are used interchangeably (especially by those that have used Spring DM for a while).
        Further more, all Spring DM applications are supported by Gemini Blueprint (do pay attention to the migration guide available
        <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.eclipse.org/gemini/blueprint/documentation/migration/" target="_top">here</a>).</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="name-change"></a>1.2.&nbsp;What happened to "Spring OSGi" project name?</h2></div></div></div><p>The OSGi term is a trademark belonging to <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.osgi.org/" target="_top">The OSGi Alliance</a>. In order to
        comply with their guidelines, it was decided that the project name 
        be changed to "Spring Dynamic Modules for OSGi Service Platforms" 
        (aka Spring DM). The new name is still pending final approval 
        by the OSGi Alliance. 
        The name change was the result of an amicable discussion between 
        the OSGi Alliance and Interface21. Interface21 is a member of the 
        OSGi Alliance, and the OSGi	Alliance remain very supportive of 
        the project.
        Note that Spring Dynamic Modules has moved to Eclipse Foundation to form Gemini Blueprint project (see above)</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="internal-package"></a>1.3.&nbsp;Why aren't there any javadocs on <code class="literal">*.internal.*</code>?</h2></div></div></div><p><code class="literal">org.eclipse.gemini.blueprint.*.internal</code> packages are
        meant (as the name implies) to be private and non-public package. Thus,
        there is no documentation, support or compatibility guarantee for
        them. In fact, the Gemini Blueprint bundle does not even export
        them to prevent accidental usage.</p><p>If you find classes under this package, which you really, really
        depend on, then consider raising an issue on <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://opensource.atlassian.com/projects/spring/browse/OSGI" target="_top">JIRA</a>
        to have access opened up.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="requirements"></a>1.4.&nbsp;What are Gemini Blueprint requirements?</h2></div></div></div><p>
	    Gemini Blueprint requires at least Java 1.7, OSGi 4.1+ and Spring 4.2
	    It might be possible to use Gemini Blueprint on a lower <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://wiki.eclipse.org/index.php/Execution_Environments" target="_top">execution environment</a>
	    (such <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://java.sun.com/products/cdc/" target="_top">CDC</a>) but 
	    it is not guaranteed to work.
	    Both Spring and Gemini Blueprint rely on <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://java.sun.com/products/javabeans/" target="_top">
	    JavaBeans</a> (java.beans package) which, unfortunately, is missing in most 
	    restricted environments. See this <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://java.sun.com/products/cdc/reference/cdc_packages.pdf" target="_top">PDF</a> for information on CDC profiles.
	    Note that, Spring 4.2 also requires Java 1.7.
	  </p><p>
	    Nevertheless, experiences and feedback on running Gemini Blueprint in restricted environments 
	    is welcomed - please use our mailing list.
	  </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="other-module-frameworks"></a>1.5.&nbsp;Are there plans to support other dynamic module frameworks (such as the JSR 277 extensions in Java 7)?</h2></div></div></div><p>There are no current plans to support other dynamic module frameworks.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="restricted-environments"></a>1.6.&nbsp;Will Gemini Blueprint work in restricted environments (such as small/mobile devices)?</h2></div></div></div><p>See the <a href="spring-osgi-faq.html#requirements" title="1.4.&nbsp;What are Gemini Blueprint requirements?">requirements</a> entry. The OSGi Service Platform is designed to run in 
	  very constrained environments however, Gemini Blueprint depends on the Spring Framework v4.2.x which in turn depends on
	  JDK 1.7. Thus Gemini Blueprint cannot run on more constrained environments (such as the OSGi Minimum Execution Environment)
	  unless Spring itself also runs in those environments. There are no current plans to make such a version of Spring. 
	  However as existing OSGi developers adopt Gemini Blueprint to simplify creation of OSGi applications and the user
	  base expands, the target audience can cover domains much broader than <span class="emphasis"><em>enterprise Java applications</em></span>. 
	  In time this could create a large enough demand to justify the investment needed to allow Spring and Gemini Blueprint to run in
	  restricted environments.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="supported-osgi-platforms"></a>1.7.&nbsp;What OSGi platforms are supported?</h2></div></div></div><p>
	  Gemini Blueprint requires an OSGi 4.2 (though it might work on OSGi 4.0 and 4.1) platform. The framework has been tested
	  on <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.eclipse.org/equinox/" target="_top">Equinox</a>, <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://felix.apache.org" target="_top">Felix</a> 
	  and <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.knopflerfish.org/" target="_top">Knopflerfish</a> 
	  - in fact, the test suite is <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://build.springframework.org:8085/bamboo/browse/OSGI" target="_top">ran</a> 
	  against all of them as part of our continuous integration process.
	  </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="osgi-intro"></a>1.8.&nbsp;Where can I learn about OSGi?</h2></div></div></div><p>
	   The best place to start is The Osgi Alliance <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.osgi.org/" target="_top">home</a> and 
	   <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www2.osgi.org/Main/HomePage" target="_top">developer</a> pages which
	   provide the OSGi specifications, introductions and many links and blogs on the topic.
	   Please see the reference documentation appendix for more information.
 	  </p><p>
	   In addition, all OSGi implementation websites host detailed, step-by-step tutorials and introduction.
	  </p><p>   
	   If you discover any additional materials useful for OSGi newbies, please let us know to update the list.
	   Thank you.
	  </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="building-the-sources"></a>1.9.&nbsp;I have problems building the sources. What can I do?</h2></div></div></div><p>Please see the file called <code class="literal">readme-building.txt</code> found in the source tree.
      </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="logging"></a>1.10.&nbsp;How can I use logging in OSGi?</h2></div></div></div><p>OSGi platforms do not change the way libraries work, it just
        enforces tighter classloading. Thus, you can, in most of the cases,
        use the same logging strategy used in non-OSGi environments.</p><p>Spring (and Gemini Blueprint) use internally the <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://commons.apache.org/logging/" target="_top">commons-logging API</a>
        which acts as an "ultra-thin bridge between different logging
        implementations". In OSGi, just like in a non-OSGi environment, Spring
        and Gemini Blueprint delegate all logging (including initialisation) to the
        actual commons-logging API implementation.</p><p>Out of the box, <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.slf4j.org/" target="_top">SLF4J</a> library is provided, which
        shares the same purpose as commons-logging but without the
        class loading discovery mechanism (that causes loading issues), using
        static wiring (see the SLF4J site for more info). To use slf4j, make sure
        you use: <code class="literal">slf4j-api-XXX.jar</code>, <code class="literal">jcl104-overslf4j-XXX.jar</code>
        and <code class="literal">slf4j-log4j-XXX.jar</code> (where XXX stands for the slf4j version).
        The last jar provides the static wiring between slf4j and log4j - if another implementation
        is desired (such as jdk14), then a different jar is required (for the jdk14 that would be
        slf4j-jdk14-XXX.jar) - see the official SLF4J site for more information.
        Please see <a href="spring-osgi-faq.html#commons-logging" title="1.11.&nbsp;If you use the commons-logging API, why rely on SLF4J and not the commons-logging jar?">this
        question</a> for more details on why commons-logging jar is not
        used.</p><p>Gemini Blueprint uses SLF4J on top of <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://logging.apache.org/log4j/" target="_top">Log4J</a> but this can be
        easily changed. As part of log4j initialisation, a
        <code class="literal">log4j.properties</code> or <code class="literal">log4j.xml</code>
        configuration fille needs to be present in the bundle classpath. This
        means that the configuration file has to be part of your bundle or one
        of its attached fragments. Besides SLF4J, for another OSGi-aware
        solution, one can try <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://wiki.ops4j.org/dokuwiki/doku.php?id=pax:logging" target="_top">Pax
        Logging</a>.</p><p>To learn more about log4j setup process, follow this <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://logging.apache.org/log4j/1.2/manual.html" target="_top">link</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="commons-logging"></a>1.11.&nbsp;If you use the commons-logging API, why rely on SLF4J and
        not the commons-logging jar?</h2></div></div></div><p>The commons-logging project provides the commons-logging API
        (<code class="literal">commons-logging-api-nn.jar</code>) along with an
        implementation (<code class="literal">commons-logging-adapters-nn.jar</code>)
        that provides a wrapper between the API and the actual logging libraries
        used underneath (such as log4j, java.util.logging, etc). However, in
        order to determine what implementation should be used, commons-logging
        library tries to do some classloading-based discovery that is fragile
        and can fail unexpectedly. In an strict classloading environment such
        as OSGi, this mechanism adds unnecessary complexity - that's why we
        decided to use SFL4J which is not just simpler and actively maintained
        but is also OSGi-friendly out of the box.</p><p>For more information about commons-logging classloading
        problems, see these links: <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://radio.weblogs.com/0122027/2003/08/15.html" target="_top">#1</a>
        <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.qos.ch/logging/thinkAgain.jsp" target="_top">#2</a></p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="getting-commons-logging-to-work"></a>1.12.&nbsp;I have to use commons-logging, what can I do?</h2></div></div></div><p>If you have to use commons-logging (for example the jar is required by certain bundles)
        then try using the most recent version commons-logging version (1.1+) as it provides more options
        on the discovery process. Below are some settings that can be used to make commons-logging work
        inside an OSGi environment:</p><div class="itemizedlist"><ul type="disc"><li><p>1.0.x</p><p>
          	Unfortunately, commons-logging 1.0.x uses the thread context class loader (TCCL) always for <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://commons.apache.org/logging/commons-logging-1.1/tech.html#A_Short_Theory_Guide_To_JCL" target="_top">loading
          	loggers</a> implementations. Inside an OSGi environment, the TCCL is undefined and cannot be relied upon.
          	Since managing the TCCL is almost impossible as most loggers are defined as static fields that need to
          	resolved on class loading, using a different <code class="classname">LogFactory</code> is advised. One can use
          	the <span class="emphasis"><em>org.apache.commons.logging.LogFactory</em></span> system property to specify a different
          	log factory however, the commons-logging bundle should be able to load this class.</p></li><li><p>1.1.x</p><p>If using commons logging 1.1.x, one can turn off the tccl usage through <span class="emphasis"><em>use_tccl</em></span>
          	property, part of the <span class="emphasis"><em>commons-logging.properties</em></span> file.
          	<a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://commons.apache.org/logging/commons-logging-1.1/troubleshooting.html" target="_top">http://commons.apache.org/logging/commons-logging-1.1/troubleshooting.html</a>. Additionally,
          	1.1.x provides several system properties (such as <span class="emphasis"><em>org.apache.commons.logging.Log.allowFlawedContext</em></span>,
          	<span class="emphasis"><em>org.apache.commons.logging.Log.allowFlawedDiscovery</em></span> and 
          	<span class="emphasis"><em>org.apache.commons.logging.Log.allowFlawedHierarchy</em></span>) that can change the behavious of the discovery process.
          	See the <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://commons.apache.org/logging/apidocs/org/apache/commons/logging/impl/LogFactoryImpl.html" target="_top">LogFactoryImpl</a>
          	javadoc for more details.</p></li></ul></div><p>In our tests, commons logging 1.1.x can be used with reasonable success inside OSGi. We haven't been able to find a generic
        configuration for commons logging 1.0.x that works and that does not rely on fragile hacks dependent on the running environment.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="logging-impl-choice"></a>1.13.&nbsp;Why don't you use the OSGi logging service/[insert your favourite
        logging library in here]?</h2></div></div></div><p>It is completely up to you what logging implementation you want
        Gemini Blueprint to use. To route log messages to the OSGi logging service, 
        just use a commons-logging API implementation that delegates to the 
        OSGi logging service, such as Pax Logging.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="osgi-wrapping"></a>1.14.&nbsp;I have to use [insert name] library/framework inside. What can I do?</h2></div></div></div><p>
          OSGi requires JARs to contain certain <code class="literal">MANIFEST.MF</code> entries which indicate what classes are 
          required and shared by each archive. This means that <span class="emphasis"><em>tradition</em></span> jars cannot be used inside an OSGi environment. 
          To solve the problem one can:
          </p><div class="itemizedlist"><ul type="disc"><li><p>Use a repository of pre-wrapped libraries such as <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.eclipse.org/orbit/" target="_top">Orbit</a>,
          	  <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://felix.apache.org/site/apache-felix-commons.html" target="_top">Felix Commons</a> or Knopflerfish <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.knopflerfish.org/repo/index.html" target="_top">repository</a>.
          	  Gemini Blueprint uses the SpringSource Enterprise <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.springsource.com/repository/app/" target="_top">Bundle Repository</a> 
          	  for its dependencies, which you might find useful. Additionally, for artifacts that have not yet made it into SpringSource Repository,
          	  Gemini Blueprint provides a small, temporary (Amazon S3) 
          	  Maven repository (<a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://s3.amazonaws.com/maven.springframework.org/osgi" target="_top">link</a> | 
          	  <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://s3browse.com/explore/maven.springframework.org/osgi/" target="_top">browser-friendly link</a>) for its internal usage.</p></li><li><p>Wrap the necessary jars with proper OSGi manifest. While this can be done by hand, we strongly recommend Peter Kriens
          	  excellent <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.aqute.biz/Code/Bnd" target="_top">bnd</a> tool which can do this for you automatically.
          	  For Maven, see Felix <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://felix.apache.org/site/maven-bundle-plugin-bnd.html" target="_top">
          	  maven-bundle-plugin</a>.
          	  </p></li><li><p>Include the jar inside your OSGi bundle and include it in the bundle classpath through <span class="emphasis"><em>Bundle-ClassPath</em></span>
          	  directive. See the OSGi specification for more information.</p></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="jdk-crippled-jta-api"></a>1.15.&nbsp;I keep getting <span class="emphasis"><em>java.lang.NoClassDefFoundError: javax/transaction/...</em></span> when trying to do data access..</h2></div></div></div><p>
          This problem is likely to be caused by bad class wiring. All 1.3+ JDKs include incomplete <span class="emphasis"><em>javax.transaction</em></span> 
          and <span class="emphasis"><em>javax.transaction.xa</em></span> packages for usage inside ORB environments. To address the problem, use a proper
          JTA library which contains all the classes from the forementioned packages and exports them with a specific version to prevent
          confusion.
          </p><p>
          Gemini Blueprint wraps JTA 1.1 library for OSGI environments which can be found at Spring snapshot repository. One can deploy this library
          and specify version 1.1 for <span class="emphasis"><em>javax.transaction*</em></span> packages inside <span class="emphasis"><em>Import-Package</em></span> header.
          By specifying the version, one can be sure that the proper package is used.
          </p><p>
          Note that JTA 1.1 is compatible with version 1.0.1.
          </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="incomplete-osgi-jar"></a>1.16.&nbsp;When doing integration testing I receive <span class="emphasis"><em>java.lang.NoClassDefFoundError: org.osgi.vendor.framework property not set</em></span>... </h2></div></div></div><p>Remove the official OSGi jars (osgi.jar or osgi-r4-core.jar) from the classpath and use only the actual OSGi platform (Equinox/Knopflerfish/Felix) 
	  	 jars. The former provides only the public classes without an actual implementation and thus cannot be used during runtime, only during the compilation stage.
	  	 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="auto-export-visibility"></a>1.17.&nbsp;The autoExport option doesn't work properly!</h2></div></div></div><p>autoExport flag, part of the service exporter, will discover and
        include for exporting only the <span class="emphasis"><em>visible</em></span> interfaces/classes implemented
        by the service object. Consider class
        <code class="literal">GenericApplicationContext</code> which implements among
        others, interfaces <code class="literal">BeanFactory</code> (from
        <code class="literal">org.springframework.beans.factory</code> package) and
        <code class="literal">ResourceLoader</code>
        (<code class="literal">org.springframework.core.io</code>).</p><p>
          </p><div class="mediaobject" align="center"><img src="images/visibility.png" align="middle"><div class="caption"><p>Class Hierarchy</p></div></div><p>
        </p><p>Depending on your OSGi imports, the exporting bundle can see
        only one of the packages, none or both. Based on these visibility
        settings, the exporter will only export the classes that are 'known'
        to the exporting bundle. For example, if the exporting bundle sees
        <code class="literal">org.springframework.core.io</code> but not
        <code class="literal">org.springframework.beans.factory</code>, the service will
        be exported as a <code class="literal">ResourceLoader</code> but not as a
        <code class="literal">BeanFactory</code>. In fact, exporting the object as a
        <code class="literal">BeanFactory</code> will fail since the bundle doesn't see
        this interface and thus doesn't know how to handle its contract.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="junit382-serialization"></a>1.18.&nbsp;When using Gemini Blueprint integration testing I get an exception about serialVersionUID. What is the problem?</h2></div></div></div><p>
      	This problem occurs on Spring DM versions up to 1.0 - consider upgrading to 1.0.1 or better. If you are stuck with 1.0 see below.
      	When running an integration test, Gemini Blueprint will duplicate the test instance and execute it inside OSGi. To avoid problems
      	like this one, make sure you are using the same libraries (with the same version) as Spring DM when running your test. This
      	particular problem for example is caused by a JUnit 3.8.2 vs 3.8.x serialization compatibility. Make sure that you are using
      	at least JUnit 3.8.2 for the execution of your tests. 
      	</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="pde-errors"></a>1.19.&nbsp;I'm using Eclipse PDE and I started getting some weird exceptions/behaviour. What's the matter?</h2></div></div></div><p>
      	Eclipse PDE uses Equinox OSGi platform underneath which (like other OSGi platforms) caches the bundles between re-runs. When
      	the cache is not properly updated, one can encounter strange behaviour (such as the new services/code being picked up)
      	or errors ranging from class versioning to linkage. Consider doing a complete clean build or, in case of Eclipse, 
      	creating a new workspace or deleting the bundle folder (depends on each project settings but most users should find it at:
      	<code class="code">[workspace_dir]\.metadata\.plugins\org.eclipse.pde.core\OSGi\org.eclipse.osgi\bundles</code>).
      	</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="upgrade-to-1.1"></a>1.20.&nbsp;I'm upgrading to Spring DM 1.1 but now I get some ClassNotFoundExceptions. What has changed?</h2></div></div></div><p>
      	In Spring DM 1.1 M2, the proxy infrastructure has been refined to avoid <span class="emphasis"><em>type leaks</em></span>, the usage of dynamic imports
      	or exposure of class loader chain delegation. If you encounter class visibility problems during the upgrade then it's likely you have
      	missing imports which were previously resolved as a side effect of Spring DM proxy weaving process. 
      	</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="proxy-equality"></a>1.21.&nbsp;I've noticed that objects imported by Gemini Blueprint are not always equal to the raw target service. Why is that?</h2></div></div></div><p>
     	To deal with dynamics, Gemini Blueprint creates proxies around the imported services. The proxies are classes (generated at runtime), different
     	from the target but able to intercept the calls made to it. Since a proxy is different then its target, comparing objects against it can 
     	yield different results then when the comparison is done against the target. In most scenarios this is not a problem but there might be 
     	corner cases where this contract matters. Since 1.1, Gemini Blueprint importer proxies implement <code class="interfacename">InfrastructureProxy</code> 
     	interface (from Spring framework) which allow access to the raw target.
     	</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="static-collections"></a>1.22.&nbsp;My Gemini Blueprint collection doesn't change even though the number of OSGi service changes. What's wrong?</h2></div></div></div><p>
     	Make sure the Gemini Blueprint collections are injected into object of compatible types (for example <code class="literal">list</code> into 
     	<code class="interfacename">java.util.List</code> or <code class="interfacename">java.util.Collection</code>). If the types are not compatible,
     	the container will have to perform 
     	<a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://static.springframework.org/spring/docs/2.5.x/reference/validation.html#beans-beans-conversion" target="_top">type conversion</a>,
     	transforming the Gemini Blueprint managed collection into a 'normal' one, unaware of the OSGi dynamics.
     	</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="update-to-1.2"></a>1.23.&nbsp;I have upgraded to Gemini Blueprint but my custom extender/web extender configuration doesn't work anymore. What has changed?</h2></div></div></div><p>Since Spring 2.5.6, the symbolic names of the artifacts have changed slightly. Spring DM/Gemini Blueprint aligned its symbolic names as well with the 
     	new patter since Spring DM 1.2.0 M2. Thus the prefix <code class="literal">org.springframework.bundle.osgi</code> has been changed to 
     	<code class="literal">org.eclipse.gemini.blueprint</code>; for example Gemini BLueprint extender symbolic name was changed from 
     	<code class="literal">org.springframework.bundle.osgi.extender</code> to <code class="literal">org.eclipse.gemini.blueprint.extender</code> 
		(notice the missing <code class="literal">bundle</code> word).
		To fix this problem, change the reference to the old symbolic name (usually inside the fragments manifests or LDAP filters) to the new one.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="linkage-error"></a>1.24.&nbsp;I get a <code class="literal">java.lang.LinkageError: loader constraint violation</code> if I use Gemini Blueprint. Things work fine with vanilla OSGi. 
     	What's wrong?</h2></div></div></div><p>Most likely the bundle imports do not identify all the transitive packages dependencies (through the <span class="emphasis"><em>uses</em></span> directive). Packages
     	imported from a bundle, can in turn, depend on other packages from other bundles - these are sometime called transitive or indirect dependencies. If
     	these are not properly identified, the OSGi platform cannot validate the wiring and allows multiple versions of the same class to be available inside the
     	same class space. This problem appears whether Gemini Blueprint is used or not. However, due to the usage of proxies inside Gemini Blueprint (which forces eager class loading
     	for the classes proxies), the class graph is evaluated at runtime causing the problem to occur early. With vanilla OSGi, the loading occurs lazy which means
     	the problem is going to occur at runtime rather then at startup.
     	To fix the problem, add the relevant transitive packages to the list of exported packages, either manually or automatically through tools such as  
     	<a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.springsource.org/bundlor" target="_top">Bundlor</a> or <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.aqute.biz/Code/Bnd" target="_top">Bnd</a>.
     	For more information on the <code class="literal">uses</code> directive please see the OSGi spec, 
     	section	3.6.4 or <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://blog.springsource.com/2008/10/20/understanding-the-osgi-uses-directive/" target="_top">this</a> SpringSource blog entry.
     	</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="blueprint"></a>1.25.&nbsp;What can I use Gemini Blueprint with the Blueprint Container spec? What's the relationship between the two? Are the they compatible?
     	Are there any differences?</h2></div></div></div><p>Gemini Blueprint (Spring DM 2.0) is the Reference Implementation for OSGi 4.2 Blueprint Container specification. Simply deploy your Blueprint bundles in a platform
     	where Gemini Blueprint is already activated and you should be done. For more information about Blueprint and Gemini Blueprint, please see the 
     	<span class="emphasis"><em>Blueprint Container</em></span> chapter in the reference documentation.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="kf-2.3-boot-delegation"></a>1.26.&nbsp;I'm using Knopflerfish 2.3.x and I have a lot of visibility exception. How can I fix this?</h2></div></div></div><p>Since 2.3.0, Knopflerfish changed the way it does bootpath delegation which causes classes to be loaded from inside and outside OSGi. Set
     	the system property <code class="literal">org.knopflerfish.framework.strictbootclassloading</code> to <code class="literal">true</code> before starting up the Knopflerfish
     	platform to prevent this from happening. See Knopflerfish 2.3.x release <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.knopflerfish.org/release_notes_2.3.html" target="_top">notes</a> for more
     	information.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="pde-cycles"></a>1.27.&nbsp;I'm using Gemini Blueprint and Spring jars inside Eclipse PDE but I get an error about cycle dependency errors. What's wrong?</h2></div></div></div><p>Some of the Spring jars (optionally) import each other packages for bootstrapping reasons. While cycles between jars are allowed and
     	supported by the OSGi platform, by default, Eclipse PDE complains about them. Since Eclipse Galileo, it is possible to enable binary cycles
     	in a target platform. allowing the build to compile. For more information, see 
     	<a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tools/export_wizards/export_plugins.htm" target="_top">this</a> 
     	entry from the Eclipse Reference Guide.</p></div></div><div xmlns:fo="http://www.w3.org/1999/XSL/Format" class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="faq.html">Prev</a>&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="faq.html">Home</a></td><td width="40%" align="right">&nbsp;</td></tr><tr><td width="40%" align="left" valign="top">Eclipse Gemini Blueprint&nbsp;</td><td width="20%" align="center"><span style="color:white;font-size:90%;"><a href="http://www.SpringSource.com/" title="SpringSource - Spring from the Source">Sponsored by SpringSource
                                        </a></span></td><td width="40%" align="right" valign="top">&nbsp;</td></tr></table></div></body></html>