[
https://issues.apache.org/jira/browse/SMX4-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davy Toch updated SMX4-1386:
----------------------------
Attachment: be.steria.esbpoc.personservice.1-1.0-SNAPSHOT-features.xml
be.steria.esbpoc.personservice.1-1.0-SNAPSHOT.jar
be.steria.esbpoc.personservice.0-1.0-SNAPSHOT-features.xml
be.steria.esbpoc.personservice.0-1.0-SNAPSHOT.jar
servicemix.log
> 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
