[
https://issues.apache.org/jira/browse/SMX4-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588217#comment-13588217
]
Gert Vanthienen commented on SMX4-1386:
---------------------------------------
The import is in the OSGi Import-Package header of your bundle. The features
definition only list bundles to be installed, but it's the OSGi metadata inside
the bundles that determines how things get wired and which packages are visible
to which bundle.
> OSGI component isolation problem resulting in "Cannot convert value of type"
> in JPA persistence layer
> -----------------------------------------------------------------------------------------------------
>
> Key: SMX4-1386
> URL: https://issues.apache.org/jira/browse/SMX4-1386
> Project: ServiceMix 4
> Issue Type: Bug
> Affects Versions: 4.4.2, 4.5.0
> Environment: Windows Vista 64 bit
> JDK 1.6.0_25
> Reporter: Davy Toch
> Attachments:
> be.steria.esbpoc.personservice.0-1.0-SNAPSHOT-features.xml,
> be.steria.esbpoc.personservice.0-1.0-SNAPSHOT.jar,
> be.steria.esbpoc.personservice.1-1.0-SNAPSHOT-features.xml,
> be.steria.esbpoc.personservice.1-1.0-SNAPSHOT.jar, servicemix.log
>
>
> We're trying to make a proof of concept with a webservice 'personservice'
> that has CUD operations to manipulate person data that are persisted in a
> database using OpenJPA. The purpose of the POC is actually to simulate
> different nodes of 'personservice' each having their own database and to test
> data replication between these different nodes with regards to performance,
> stability. In order to simulate multiple nodes of this service, we
> implemented it as an OSGI component deployable in servicemix, but with each
> deployable component having in its configuration a distinct context root,
> schema URL, ... . We wanted it this way in order to be able to deploy these
> instances in the same servicemix JVM which facilitates configuration for the
> POC (a more realistic situation is to have multiple JVMs but for the moment
> we don't want to do that because then it's a hassle trying to get the ports
> configurated without conflicts, like http port, ActiveMQ broker port, ...).
> Now our problem : deployment of the first node '0' of the service works, but
> when trying to deploy the second node '1', we get a class conflict on the DAO
> persistence layer that I didn't expect since OSGI deployments are supposed to
> be completely isolated from each other:
> Caused by: org.springframework.beans.ConversionNotSupportedException:
> Failed to convert property value of type
> 'be.steria.esbpoc.personservice.dao.PersonDaoImpl'
> to required type 'be.steria.esbpoc.personservice.dao.PersonDao' for
> property 'personDao';
> nested exception is java.lang.IllegalStateException: Cannot
> convert value of type [be.steria.esbpoc.personservice.dao.PersonDaoImpl]
> to required type [be.steria.esbpoc.personservice.dao.PersonDao]
> for property 'personDao': no matching editors or conversion strategy found
> ...
> Caused by: java.lang.IllegalStateException: Cannot convert value of
> type [be.steria.esbpoc.personservice.dao.PersonDaoImpl]
> to required type [be.steria.esbpoc.personservice.dao.PersonDao] for
> property 'personDao': no matching editors or conversion strategy found
> ...
> The deployment was done in the servicemix console using the following
> commands:
> features:addUrl
> mvn:be.steria.esbpoc/be.steria.esbpoc.personservice.0/1.0-SNAPSHOT/xml/features
> features:install be.steria.esbpoc.personservice.0
> features:addUrl
> mvn:be.steria.esbpoc/be.steria.esbpoc.personservice.1/1.0-SNAPSHOT/xml/features
> features:install be.steria.esbpoc.personservice.1
> Included the log file (servicemix.log), the 2 jars of the personservice nodes
> '0' and '1' and the related features configurations for these 2 deployments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
