[jira] [Commented] (SMX4-1386) OSGI component isolation problem resulting in "Cannot convert value of type" in JPA persistence layer

["Gert Vanthienen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SMX4-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585932#comment-13585932 ] 

Gert Vanthienen commented on SMX4-1386:
---------------------------------------

Could you run a packages:import on both bundles?  You might have Import-Package and Export-Package headers that are causing classes from one bundle to be visible by the next one inadvertently.  Only exporting the shared (API-like) bits from a bundle and hiding the internal implementation packages should help prevent this.
                
> 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