| <html><head> | |
| <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | |
| <title>Chapter 1. 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 1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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> </td><td width="20%" align="center"><a accesskey="h" href="faq.html">Home</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">Eclipse Gemini Blueprint </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"> </td></tr></table></div></body></html> |