Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType
[CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431731] Thu, 23 July 2009 12:08 Go to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
As I mentioned in my previous message I switched from CDO 2.0 to the current CVS Head as target for
my RCP app.
When starting my app I get the below exception.
So it seems the mapping doen't like some type in my EMF model (it worked perfectly with 2.0).
But the error message is so unhandy that no one could tell what exactly the cause is. At least the
feature structure should be also named.
Also I am not sure why the EMF type "CUSTOM" is used. I am not using any special in my EMF models.

Regards,
Kai
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431732 is a reply to message #431731] Thu, 23 July 2009 12:09 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
Forgot the trace:

Rollback in DBStore: java.lang.IllegalArgumentException: No suitable mapping found from EMF type
CUSTOM to DB type DBType
at
org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
at
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
at
org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
at org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
at
org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
at
org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

at org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
at org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
at org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
at org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)


Kai Schlamp wrote:
> As I mentioned in my previous message I switched from CDO 2.0 to the
> current CVS Head as target for my RCP app.
> When starting my app I get the below exception.
> So it seems the mapping doen't like some type in my EMF model (it worked
> perfectly with 2.0).
> But the error message is so unhandy that no one could tell what exactly
> the cause is. At least the feature structure should be also named.
> Also I am not sure why the EMF type "CUSTOM" is used. I am not using any
> special in my EMF models.
>
> Regards,
> Kai
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431734 is a reply to message #431732] Thu, 23 July 2009 12:30 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
Ok, here lies the problem.
My model has indeed a custom field (EJavaObject), but I never commit any of those objects with this
feature structure into the database.
CDO 2.0 could live with that and was never interested in that never persisted object. In contrast
CDO CVS Head now is interested in those objects when setting up the database and throws the below
exception.
In my opinion we should make CDO Head behave as CDO 2.0. Only do mappings when needed.

Regards,
Kai


Kai Schlamp wrote:
> Forgot the trace:
>
> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
> mapping found from EMF type CUSTOM to DB type DBType
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>
> at
> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>
> at
> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>
> at
> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>
> at
> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>
> at java.lang.Thread.run(Thread.java:619)
>
> at
> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>
> at
> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>
> at
> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>
> at
> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>
>
>
> Kai Schlamp wrote:
>> As I mentioned in my previous message I switched from CDO 2.0 to the
>> current CVS Head as target for my RCP app.
>> When starting my app I get the below exception.
>> So it seems the mapping doen't like some type in my EMF model (it
>> worked perfectly with 2.0).
>> But the error message is so unhandy that no one could tell what
>> exactly the cause is. At least the feature structure should be also
>> named.
>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>> any special in my EMF models.
>>
>> Regards,
>> Kai
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431735 is a reply to message #431734] Thu, 23 July 2009 12:35 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6512
Registered: July 2009
Senior Member
Shouldn't the field be transient?

Tom

Kai Schlamp schrieb:
> Ok, here lies the problem.
> My model has indeed a custom field (EJavaObject), but I never commit any
> of those objects with this feature structure into the database.
> CDO 2.0 could live with that and was never interested in that never
> persisted object. In contrast CDO CVS Head now is interested in those
> objects when setting up the database and throws the below exception.
> In my opinion we should make CDO Head behave as CDO 2.0. Only do
> mappings when needed.
>
> Regards,
> Kai
>
>
> Kai Schlamp wrote:
>> Forgot the trace:
>>
>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>> mapping found from EMF type CUSTOM to DB type DBType
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>
>> at
>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>
>> at
>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>
>> at
>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>
>> at
>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>
>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>
>> at java.lang.Thread.run(Thread.java:619)
>>
>> at
>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>
>> at
>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>
>> at
>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>
>> at
>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>
>>
>>
>> Kai Schlamp wrote:
>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>> current CVS Head as target for my RCP app.
>>> When starting my app I get the below exception.
>>> So it seems the mapping doen't like some type in my EMF model (it
>>> worked perfectly with 2.0).
>>> But the error message is so unhandy that no one could tell what
>>> exactly the cause is. At least the feature structure should be also
>>> named.
>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>> any special in my EMF models.
>>>
>>> Regards,
>>> Kai
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431736 is a reply to message #431731] Thu, 23 July 2009 12:36 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
> But the error message is so unhandy that no one could tell what exactly
> the cause is. At least the feature structure should be also named.

Here is a little patch for a more detailed error message. Please don't ask me to add a bugzilla for
that little line ;-)

### Eclipse Workspace Patch 1.0
#P org.eclipse.emf.cdo.server.db
Index: src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
============================================================ =======
RCS file:
/cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo/plugin s/org.eclipse.emf.cdo.server.db/src/org/eclipse/emf/cdo/serv er/internal/db/mapping/TypeMappingFactory.java,v
retrieving revision 1.2
diff -u -r1.2 TypeMappingFactory.java
--- src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java 17 Jul 2009
09:05:02 -0000 1.2
+++ src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java 23 Jul 2009 12:32:50
-0000
@@ -253,7 +253,8 @@
if (concreteFactory == null)
{
throw new IllegalArgumentException("No suitable mapping found from EMF type " +
cdoType.getName()
- + " to DB type " + dbType.getClass().getSimpleName());
+ + " to DB type " + dbType.getClass().getSimpleName() + " for feature " +
feature.getName() + " of "
+ + feature.getEContainingClass().getName());
}

return concreteFactory.doCreateTypeMapping(mappingStrategy, feature, dbType);
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431737 is a reply to message #431735] Thu, 23 July 2009 12:43 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
Tom, you are correct. Transient indeed works (I already solved it that way). But in my opinion it's
more a conceptual question of how CDO works. Why does CDO bother with type mappings when nothing is
intended to be committed. But I am still not sure for myself ... is it intended or even a feature?!
As I said, it behave differently when using CDO 2.0 that's why it attracted my attention.

Regards,
Kai

Tom Schindl wrote:
> Shouldn't the field be transient?
>
> Tom
>
> Kai Schlamp schrieb:
>> Ok, here lies the problem.
>> My model has indeed a custom field (EJavaObject), but I never commit any
>> of those objects with this feature structure into the database.
>> CDO 2.0 could live with that and was never interested in that never
>> persisted object. In contrast CDO CVS Head now is interested in those
>> objects when setting up the database and throws the below exception.
>> In my opinion we should make CDO Head behave as CDO 2.0. Only do
>> mappings when needed.
>>
>> Regards,
>> Kai
>>
>>
>> Kai Schlamp wrote:
>>> Forgot the trace:
>>>
>>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>>> mapping found from EMF type CUSTOM to DB type DBType
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>
>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>>
>>> at
>>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>>
>>> at
>>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>>
>>>
>>>
>>> Kai Schlamp wrote:
>>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>>> current CVS Head as target for my RCP app.
>>>> When starting my app I get the below exception.
>>>> So it seems the mapping doen't like some type in my EMF model (it
>>>> worked perfectly with 2.0).
>>>> But the error message is so unhandy that no one could tell what
>>>> exactly the cause is. At least the feature structure should be also
>>>> named.
>>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>>> any special in my EMF models.
>>>>
>>>> Regards,
>>>> Kai
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431738 is a reply to message #431736] Thu, 23 July 2009 12:49 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6512
Registered: July 2009
Senior Member
There's no other possibility to bring in code into the Eclipse Repo
because all projects need to maintain an IP-Log.

Tom

Kai Schlamp schrieb:
>> But the error message is so unhandy that no one could tell what
>> exactly the cause is. At least the feature structure should be also
>> named.
>
> Here is a little patch for a more detailed error message. Please don't
> ask me to add a bugzilla for that little line ;-)
>
> ### Eclipse Workspace Patch 1.0
> #P org.eclipse.emf.cdo.server.db
> Index:
> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
> ============================================================ =======
> RCS file:
> /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo/plugin s/org.eclipse.emf.cdo.server.db/src/org/eclipse/emf/cdo/serv er/internal/db/mapping/TypeMappingFactory.java,v
>
> retrieving revision 1.2
> diff -u -r1.2 TypeMappingFactory.java
> ---
> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
> 17 Jul 2009 09:05:02 -0000 1.2
> +++
> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
> 23 Jul 2009 12:32:50 -0000
> @@ -253,7 +253,8 @@
> if (concreteFactory == null)
> {
> throw new IllegalArgumentException("No suitable mapping found
> from EMF type " + cdoType.getName()
> - + " to DB type " + dbType.getClass().getSimpleName());
> + + " to DB type " + dbType.getClass().getSimpleName() + " for
> feature " + feature.getName() + " of "
> + + feature.getEContainingClass().getName());
> }
>
> return concreteFactory.doCreateTypeMapping(mappingStrategy,
> feature, dbType);
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431739 is a reply to message #431738] Thu, 23 July 2009 13:07 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
Ah, yes ... the IP thing ;-)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=284412

Tom Schindl wrote:
> There's no other possibility to bring in code into the Eclipse Repo
> because all projects need to maintain an IP-Log.
>
> Tom
>
> Kai Schlamp schrieb:
>>> But the error message is so unhandy that no one could tell what
>>> exactly the cause is. At least the feature structure should be also
>>> named.
>> Here is a little patch for a more detailed error message. Please don't
>> ask me to add a bugzilla for that little line ;-)
>>
>> ### Eclipse Workspace Patch 1.0
>> #P org.eclipse.emf.cdo.server.db
>> Index:
>> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
>> ============================================================ =======
>> RCS file:
>> /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo/plugin s/org.eclipse.emf.cdo.server.db/src/org/eclipse/emf/cdo/serv er/internal/db/mapping/TypeMappingFactory.java,v
>>
>> retrieving revision 1.2
>> diff -u -r1.2 TypeMappingFactory.java
>> ---
>> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
>> 17 Jul 2009 09:05:02 -0000 1.2
>> +++
>> src/org/eclipse/emf/cdo/server/internal/db/mapping/TypeMappi ngFactory.java
>> 23 Jul 2009 12:32:50 -0000
>> @@ -253,7 +253,8 @@
>> if (concreteFactory == null)
>> {
>> throw new IllegalArgumentException("No suitable mapping found
>> from EMF type " + cdoType.getName()
>> - + " to DB type " + dbType.getClass().getSimpleName());
>> + + " to DB type " + dbType.getClass().getSimpleName() + " for
>> feature " + feature.getName() + " of "
>> + + feature.getEContainingClass().getName());
>> }
>>
>> return concreteFactory.doCreateTypeMapping(mappingStrategy,
>> feature, dbType);
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431754 is a reply to message #431732] Thu, 23 July 2009 17:11 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Kai,

The exception message looks odd. Please file a bugzilla and prefix the
summary with "[DB] ...".

It should be: "No suitable mapping found from CDOType CUSTOM to
DBType.BLABLA" or just "No suitable mapping found from CDOType CUSTOM"...

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Kai Schlamp schrieb:
> Forgot the trace:
>
> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
> mapping found from EMF type CUSTOM to DB type DBType
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>
> at
> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>
> at
> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>
> at
> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>
> at
> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>
> at java.lang.Thread.run(Thread.java:619)
>
> at
> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>
> at
> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>
> at
> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>
> at
> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>
>
>
> Kai Schlamp wrote:
>> As I mentioned in my previous message I switched from CDO 2.0 to the
>> current CVS Head as target for my RCP app.
>> When starting my app I get the below exception.
>> So it seems the mapping doen't like some type in my EMF model (it
>> worked perfectly with 2.0).
>> But the error message is so unhandy that no one could tell what
>> exactly the cause is. At least the feature structure should be also
>> named.
>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>> any special in my EMF models.
>>
>> Regards,
>> Kai


Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431755 is a reply to message #431734] Thu, 23 July 2009 17:11 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Kai Schlamp schrieb:
> Ok, here lies the problem.
> My model has indeed a custom field (EJavaObject), but I never commit
> any of those objects with this feature structure into the database.
> CDO 2.0 could live with that and was never interested in that never
> persisted object. In contrast CDO CVS Head now is interested in those
> objects when setting up the database and throws the below exception.
> In my opinion we should make CDO Head behave as CDO 2.0. Only do
> mappings when needed.
Can you file a bugzilla so that we can discuss that with Stefan?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> Regards,
> Kai
>
>
> Kai Schlamp wrote:
>> Forgot the trace:
>>
>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>> mapping found from EMF type CUSTOM to DB type DBType
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>
>> at
>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>
>> at
>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>
>> at
>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>
>> at
>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>
>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>> at
>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>
>> at
>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>
>> at java.lang.Thread.run(Thread.java:619)
>>
>> at
>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>
>> at
>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>
>> at
>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>
>> at
>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>
>>
>>
>> Kai Schlamp wrote:
>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>> current CVS Head as target for my RCP app.
>>> When starting my app I get the below exception.
>>> So it seems the mapping doen't like some type in my EMF model (it
>>> worked perfectly with 2.0).
>>> But the error message is so unhandy that no one could tell what
>>> exactly the cause is. At least the feature structure should be also
>>> named.
>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>> any special in my EMF models.
>>>
>>> Regards,
>>> Kai


Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431756 is a reply to message #431735] Thu, 23 July 2009 17:12 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Tom Schindl schrieb:
> Shouldn't the field be transient?
>
Indeed, that's what I think, too.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


> Tom
>
> Kai Schlamp schrieb:
>
>> Ok, here lies the problem.
>> My model has indeed a custom field (EJavaObject), but I never commit any
>> of those objects with this feature structure into the database.
>> CDO 2.0 could live with that and was never interested in that never
>> persisted object. In contrast CDO CVS Head now is interested in those
>> objects when setting up the database and throws the below exception.
>> In my opinion we should make CDO Head behave as CDO 2.0. Only do
>> mappings when needed.
>>
>> Regards,
>> Kai
>>
>>
>> Kai Schlamp wrote:
>>
>>> Forgot the trace:
>>>
>>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>>> mapping found from EMF type CUSTOM to DB type DBType
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>
>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>>
>>> at
>>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>>
>>> at
>>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>>
>>>
>>>
>>> Kai Schlamp wrote:
>>>
>>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>>> current CVS Head as target for my RCP app.
>>>> When starting my app I get the below exception.
>>>> So it seems the mapping doen't like some type in my EMF model (it
>>>> worked perfectly with 2.0).
>>>> But the error message is so unhandy that no one could tell what
>>>> exactly the cause is. At least the feature structure should be also
>>>> named.
>>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>>> any special in my EMF models.
>>>>
>>>> Regards,
>>>> Kai
>>>>


Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431757 is a reply to message #431737] Thu, 23 July 2009 17:17 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Kai Schlamp schrieb:
> Tom, you are correct. Transient indeed works (I already solved it that
> way). But in my opinion it's more a conceptual question of how CDO
> works. Why does CDO bother with type mappings when nothing is intended
> to be committed. But I am still not sure for myself ... is it intended
> or even a feature?!
I'd say it's intended. From a conceptual point of view it sounds odd to
allow things that are known to violate assumptions and hope that it will
not occur. Technically it's next to impossible to lazily create missing
mappings. SQL does not seem to define a standard way how to execute DDL.
Some vendors do it in the normal transaction, some do it outside, others
implicitely commit the ongoing transaction before and after DDL.

> As I said, it behave differently when using CDO 2.0 that's why it
> attracted my attention.
Maybe it's related with different handling of the mapping inside the
DBStore. Stefan, is there something that pops into your mind?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> Regards,
> Kai
>
> Tom Schindl wrote:
>> Shouldn't the field be transient?
>>
>> Tom
>>
>> Kai Schlamp schrieb:
>>> Ok, here lies the problem.
>>> My model has indeed a custom field (EJavaObject), but I never commit
>>> any
>>> of those objects with this feature structure into the database.
>>> CDO 2.0 could live with that and was never interested in that never
>>> persisted object. In contrast CDO CVS Head now is interested in those
>>> objects when setting up the database and throws the below exception.
>>> In my opinion we should make CDO Head behave as CDO 2.0. Only do
>>> mappings when needed.
>>>
>>> Regards,
>>> Kai
>>>
>>>
>>> Kai Schlamp wrote:
>>>> Forgot the trace:
>>>>
>>>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>>>> mapping found from EMF type CUSTOM to DB type DBType
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>>>
>>>>
>>>> at
>>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>>
>>>>
>>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>>
>>>>
>>>> at
>>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>>
>>>>
>>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>>>
>>>>
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>>>
>>>>
>>>> at java.lang.Thread.run(Thread.java:619)
>>>>
>>>> at
>>>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>>>
>>>>
>>>> at
>>>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>>>
>>>>
>>>> at
>>>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>>>
>>>>
>>>> at
>>>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>>>
>>>>
>>>>
>>>>
>>>> Kai Schlamp wrote:
>>>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>>>> current CVS Head as target for my RCP app.
>>>>> When starting my app I get the below exception.
>>>>> So it seems the mapping doen't like some type in my EMF model (it
>>>>> worked perfectly with 2.0).
>>>>> But the error message is so unhandy that no one could tell what
>>>>> exactly the cause is. At least the feature structure should be also
>>>>> named.
>>>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>>>> any special in my EMF models.
>>>>>
>>>>> Regards,
>>>>> Kai


Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #431781 is a reply to message #431755] Sun, 26 July 2009 17:30 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
Eike Stepper wrote:
> Kai Schlamp schrieb:
>> Ok, here lies the problem.
>> My model has indeed a custom field (EJavaObject), but I never commit
>> any of those objects with this feature structure into the database.
>> CDO 2.0 could live with that and was never interested in that never
>> persisted object. In contrast CDO CVS Head now is interested in those
>> objects when setting up the database and throws the below exception.
>> In my opinion we should make CDO Head behave as CDO 2.0. Only do
>> mappings when needed.
> Can you file a bugzilla so that we can discuss that with Stefan?

But it's not only the type mapping, it's also the way the complete database is created by the DB
store. In CDO 2.0 a database table was created on demand (if something was commited). With CDO Head
all database tables are created the first time the database is accessed.
The problem is that I mostly mix my models with classes that should be persisted to database and
classes that are not intendet for persistence. Now with CDO Head many tables are created that are
never used.
May we should add an annotation option to suppress a table creation for a specific class.
What do you think?
Discussion here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=284680





>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>> Regards,
>> Kai
>>
>>
>> Kai Schlamp wrote:
>>> Forgot the trace:
>>>
>>> Rollback in DBStore: java.lang.IllegalArgumentException: No suitable
>>> mapping found from EMF type CUSTOM to DB type DBType
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.TypeMappingFa ctory.createTypeMapping(TypeMappingFactory.java:255)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createValueMapping(AbstractMappingStrategy.java:3 88)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.createValueMappings(AbstractHor izontalClassMapping.java:119)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping.initFeatures(AbstractHorizontal ClassMapping.java:107)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ab stractHorizontalClassMapping. <init>(AbstractHorizontalClassMapping.java:76)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditClassMapping. <init>(HorizontalNonAuditClassMapping.java:90)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.Ho rizontalNonAuditMappingStrategy.doCreateClassMapping(Horizon talNonAuditMappingStrategy.java:29)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createClassMapping(AbstractMappingStrategy.java:3 55)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapClasses(AbstractMappingStrategy.java:325)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageInfos(AbstractMappingStrategy.java:314)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.mapPackageUnits(AbstractMappingStrategy.java:336)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappi ngStrategy.createMapping(AbstractMappingStrategy.java:297)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write PackageUnits(DBStoreAccessor.java:501)
>>>
>>> at
>>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:132)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.acces s$4(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:80)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor$1.run Loop(DBStoreAccessor.java:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write (DBStoreAccessor.java:299)
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:273)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:72)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication$1.runLoop(CommitTransactionIndication.jav a:1)
>>>
>>> at
>>> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicatingCommit(CommitTransactionIndicat ion.java:280)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:173)
>>>
>>> at
>>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTra nsactionIndication.indicating(CommitTransactionIndication.ja va:139)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating (IndicationWithMonitoring.java:84)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedIn put(IndicationWithResponse.java:90)
>>>
>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>>> at
>>> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:63)
>>>
>>> at
>>> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(In dicationWithMonitoring.java:63)
>>>
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:886)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:908)
>>>
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToServer(S erverManager.java:228)
>>>
>>> at
>>> org.pubcurator.core.managers.ServerManager.connectToLocalSer ver(ServerManager.java:186)
>>>
>>> at
>>> org.pubcurator.core.ApplicationWorkbenchAdvisor$1$1.run(Appl icationWorkbenchAdvisor.java:87)
>>>
>>> at
>>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:121)
>>>
>>>
>>>
>>> Kai Schlamp wrote:
>>>> As I mentioned in my previous message I switched from CDO 2.0 to the
>>>> current CVS Head as target for my RCP app.
>>>> When starting my app I get the below exception.
>>>> So it seems the mapping doen't like some type in my EMF model (it
>>>> worked perfectly with 2.0).
>>>> But the error message is so unhandy that no one could tell what
>>>> exactly the cause is. At least the feature structure should be also
>>>> named.
>>>> Also I am not sure why the EMF type "CUSTOM" is used. I am not using
>>>> any special in my EMF models.
>>>>
>>>> Regards,
>>>> Kai
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #435435 is a reply to message #431731] Thu, 30 July 2009 21:00 Go to previous messageGo to next message
Christopher Albert is currently offline Christopher AlbertFriend
Messages: 5
Registered: July 2009
Junior Member
I got the same error today and could track it down with your little patch
(I don't know if you're getting it for the same reason, but maybe it will
help):

I am using an xsd based model and the error occurs on the first String
typed feature in a class. The problem that occurs is the following:

CDOModelUtil.getType(EClassifier classifier) is used to determin the type
which looks like that:

public static CDOType getType(EClassifier classifier)
{
if (classifier instanceof EClass)
{
return CDOType.OBJECT;
}

if (classifier instanceof EEnum)
{
return CDOType.ENUM_ORDINAL;
}

if (isCorePackage(classifier.getEPackage()))
{
EDataType eDataType = (EDataType)classifier;
CDOType type = getCoreType(eDataType);
if (type != null)
{
return type;
}
}

return CDOType.CUSTOM;
}

The problem is that neither of the three condition is fulfilled because
String is a base type and no EClass BUT in the package
http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns only true
if it's http://www.eclipse.org/emf/2002/Ecore (and mappings are only
defined for those types).

Possible solution: Add type mappings for XMLType types

I'm not really sure, if I have interpreted that correctly, so I haven't
yet created a bugzilla entry. Please let me know what you think about it.

regards,
Chris
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #435643 is a reply to message #435435] Thu, 30 July 2009 21:22 Go to previous messageGo to next message
Christopher Albert is currently offline Christopher AlbertFriend
Messages: 5
Registered: July 2009
Junior Member
Christopher Albert wrote:

> ...
> The problem is that neither of the three condition is fulfilled because
> String is a base type and no EClass BUT in the package
> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns only true
> if it's http://www.eclipse.org/emf/2002/Ecore (and mappings are only
> defined for those types).

> Possible solution: Add type mappings for XMLType types

> I'm not really sure, if I have interpreted that correctly, so I haven't
> yet created a bugzilla entry. Please let me know what you think about it.

Update: I forgot to generate an xsd-ecore mapping file, when I did that,
the problem disappeared as the types are now mapped to core types.
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #436717 is a reply to message #435643] Fri, 31 July 2009 00:10 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
Hi Christopher.

Good that you found your problem. I only run into that problem when using non EMF data types. Those
must be set to transient as CDO can't know how to store them.

Regards,
Kai

Christopher Albert wrote:
> Christopher Albert wrote:
>
>> ...
>> The problem is that neither of the three condition is fulfilled
>> because String is a base type and no EClass BUT in the package
>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns only
>> true if it's http://www.eclipse.org/emf/2002/Ecore (and mappings are
>> only defined for those types).
>
>> Possible solution: Add type mappings for XMLType types
>
>> I'm not really sure, if I have interpreted that correctly, so I
>> haven't yet created a bugzilla entry. Please let me know what you
>> think about it.
>
> Update: I forgot to generate an xsd-ecore mapping file, when I did that,
> the problem disappeared as the types are now mapped to core types.
>
>
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #439224 is a reply to message #436717] Fri, 31 July 2009 05:48 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Christopher, Kai,

That sounds like a regression in CDO. Unknown EDataTypes should be
represented by CDOType.CUSTOM. Can you file a bugzilla?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Kai Schlamp schrieb:
> Hi Christopher.
>
> Good that you found your problem. I only run into that problem when
> using non EMF data types. Those must be set to transient as CDO can't
> know how to store them.
>
> Regards,
> Kai
>
> Christopher Albert wrote:
>> Christopher Albert wrote:
>>
>>> ...
>>> The problem is that neither of the three condition is fulfilled
>>> because String is a base type and no EClass BUT in the package
>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>> mappings are only defined for those types).
>>
>>> Possible solution: Add type mappings for XMLType types
>>
>>> I'm not really sure, if I have interpreted that correctly, so I
>>> haven't yet created a bugzilla entry. Please let me know what you
>>> think about it.
>>
>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>> that, the problem disappeared as the types are now mapped to core types.
>>
>>


Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441010 is a reply to message #439224] Fri, 31 July 2009 09:22 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
Eike Stepper wrote:
> Christopher, Kai,
>
> That sounds like a regression in CDO. Unknown EDataTypes should be
> represented by CDOType.CUSTOM. Can you file a bugzilla?

I think that those are represented by CDOType.CUSTOM, but the DB Store simply doesn't know what to
do with that type (and throws an exception). Or do you mean something other?

>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Kai Schlamp schrieb:
>> Hi Christopher.
>>
>> Good that you found your problem. I only run into that problem when
>> using non EMF data types. Those must be set to transient as CDO can't
>> know how to store them.
>>
>> Regards,
>> Kai
>>
>> Christopher Albert wrote:
>>> Christopher Albert wrote:
>>>
>>>> ...
>>>> The problem is that neither of the three condition is fulfilled
>>>> because String is a base type and no EClass BUT in the package
>>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>>> mappings are only defined for those types).
>>>> Possible solution: Add type mappings for XMLType types
>>>> I'm not really sure, if I have interpreted that correctly, so I
>>>> haven't yet created a bugzilla entry. Please let me know what you
>>>> think about it.
>>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>>> that, the problem disappeared as the types are now mapped to core types.
>>>
>>>
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441011 is a reply to message #441010] Fri, 31 July 2009 09:34 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Kai Schlamp schrieb:
> Eike Stepper wrote:
>> Christopher, Kai,
>>
>> That sounds like a regression in CDO. Unknown EDataTypes should be
>> represented by CDOType.CUSTOM. Can you file a bugzilla?
>
> I think that those are represented by CDOType.CUSTOM, but the DB Store
> simply doesn't know what to do with that type (and throws an
> exception). Or do you mean something other?
Probably I just lost track in this long thread. If there is a problem
anywhere please file a bugzilla with a stack trace ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Kai Schlamp schrieb:
>>> Hi Christopher.
>>>
>>> Good that you found your problem. I only run into that problem when
>>> using non EMF data types. Those must be set to transient as CDO can't
>>> know how to store them.
>>>
>>> Regards,
>>> Kai
>>>
>>> Christopher Albert wrote:
>>>> Christopher Albert wrote:
>>>>
>>>>> ...
>>>>> The problem is that neither of the three condition is fulfilled
>>>>> because String is a base type and no EClass BUT in the package
>>>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>>>> mappings are only defined for those types).
>>>>> Possible solution: Add type mappings for XMLType types
>>>>> I'm not really sure, if I have interpreted that correctly, so I
>>>>> haven't yet created a bugzilla entry. Please let me know what you
>>>>> think about it.
>>>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>>>> that, the problem disappeared as the types are now mapped to core
>>>> types.
>>>>
>>>>


Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441057 is a reply to message #441011] Fri, 31 July 2009 09:39 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6512
Registered: July 2009
Senior Member
Hi Eike,

I don't think there's a problem because one simply can't persist an
arbitrary JavaObject whether it is CDO, Teneo or the "simple" XMI
persistance.

IMHO CDO is completely right in throwing an Exception if someone to has
a none transient arbitrary JavaObject in his/her model.

Tom

Eike Stepper schrieb:
> Kai Schlamp schrieb:
>> Eike Stepper wrote:
>>> Christopher, Kai,
>>>
>>> That sounds like a regression in CDO. Unknown EDataTypes should be
>>> represented by CDOType.CUSTOM. Can you file a bugzilla?
>> I think that those are represented by CDOType.CUSTOM, but the DB Store
>> simply doesn't know what to do with that type (and throws an
>> exception). Or do you mean something other?
> Probably I just lost track in this long thread. If there is a problem
> anywhere please file a bugzilla with a stack trace ;-)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>> Kai Schlamp schrieb:
>>>> Hi Christopher.
>>>>
>>>> Good that you found your problem. I only run into that problem when
>>>> using non EMF data types. Those must be set to transient as CDO can't
>>>> know how to store them.
>>>>
>>>> Regards,
>>>> Kai
>>>>
>>>> Christopher Albert wrote:
>>>>> Christopher Albert wrote:
>>>>>
>>>>>> ...
>>>>>> The problem is that neither of the three condition is fulfilled
>>>>>> because String is a base type and no EClass BUT in the package
>>>>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>>>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>>>>> mappings are only defined for those types).
>>>>>> Possible solution: Add type mappings for XMLType types
>>>>>> I'm not really sure, if I have interpreted that correctly, so I
>>>>>> haven't yet created a bugzilla entry. Please let me know what you
>>>>>> think about it.
>>>>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>>>>> that, the problem disappeared as the types are now mapped to core
>>>>> types.
>>>>>
>>>>>
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441195 is a reply to message #441057] Fri, 31 July 2009 09:50 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Tom Schindl schrieb:
> Hi Eike,
>
> I don't think there's a problem because one simply can't persist an
> arbitrary JavaObject whether it is CDO, Teneo or the "simple" XMI
> persistance.
>
> IMHO CDO is completely right in throwing an Exception if someone to has
> a none transient arbitrary JavaObject in his/her model.
>
I'm not sure, though. This changed since we have the EPackage available
on the server. Now we have the EDataType on both client and server side
and we should use its String conversion methods. I know that the
CDOProtocol does that already via CDOType.CUSTOM. Maybe the DBStore did
not catch up with this change but continues to expect a String in the
CDORevision / delta. It that case we'd just need an additional
TypeMapping for CDOType.CUSTOM / String. Stefan?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


> Tom
>
> Eike Stepper schrieb:
>
>> Kai Schlamp schrieb:
>>
>>> Eike Stepper wrote:
>>>
>>>> Christopher, Kai,
>>>>
>>>> That sounds like a regression in CDO. Unknown EDataTypes should be
>>>> represented by CDOType.CUSTOM. Can you file a bugzilla?
>>>>
>>> I think that those are represented by CDOType.CUSTOM, but the DB Store
>>> simply doesn't know what to do with that type (and throws an
>>> exception). Or do you mean something other?
>>>
>> Probably I just lost track in this long thread. If there is a problem
>> anywhere please file a bugzilla with a stack trace ;-)
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>>> Kai Schlamp schrieb:
>>>>
>>>>> Hi Christopher.
>>>>>
>>>>> Good that you found your problem. I only run into that problem when
>>>>> using non EMF data types. Those must be set to transient as CDO can't
>>>>> know how to store them.
>>>>>
>>>>> Regards,
>>>>> Kai
>>>>>
>>>>> Christopher Albert wrote:
>>>>>
>>>>>> Christopher Albert wrote:
>>>>>>
>>>>>>
>>>>>>> ...
>>>>>>> The problem is that neither of the three condition is fulfilled
>>>>>>> because String is a base type and no EClass BUT in the package
>>>>>>> http://www.eclipse.org/emf/2003/XMLType. isCorePackage() returns
>>>>>>> only true if it's http://www.eclipse.org/emf/2002/Ecore (and
>>>>>>> mappings are only defined for those types).
>>>>>>> Possible solution: Add type mappings for XMLType types
>>>>>>> I'm not really sure, if I have interpreted that correctly, so I
>>>>>>> haven't yet created a bugzilla entry. Please let me know what you
>>>>>>> think about it.
>>>>>>>
>>>>>> Update: I forgot to generate an xsd-ecore mapping file, when I did
>>>>>> that, the problem disappeared as the types are now mapped to core
>>>>>> types.
>>>>>>
>>>>>>
>>>>>>


Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441216 is a reply to message #441195] Fri, 31 July 2009 10:05 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 301
Registered: July 2009
Location: Germany
Senior Member
Hi,

Comments below...

Eike Stepper schrieb:
> Tom Schindl schrieb:
>
>> Hi Eike,
>>
>> I don't think there's a problem because one simply can't persist an
>> arbitrary JavaObject whether it is CDO, Teneo or the "simple" XMI
>> persistance.
>>
>> IMHO CDO is completely right in throwing an Exception if someone to has
>> a none transient arbitrary JavaObject in his/her model.
>>
>>
> I'm not sure, though. This changed since we have the EPackage available
> on the server. Now we have the EDataType on both client and server side
> and we should use its String conversion methods.
> I know that the
> CDOProtocol does that already via CDOType.CUSTOM. Maybe the DBStore did
> not catch up with this change but continues to expect a String in the
> CDORevision / delta. It that case we'd just need an additional
> TypeMapping for CDOType.CUSTOM / String. Stefan?
>
Yes and no. It is true that we have EDataType on the Server and it would
be no problem to create a TypeMapping which maps CUSTOM to String
calling the String conversion methods.

However, we don't have the *generated* or *user-defined* packages on the
server - we use reflective models there.
So, if a user creates a custom data type together with
createXYfromString)= and convertXYtoString() implementation, we still
don't have those on the server.

Even if the custom object would implement Serializable we still would
not be able to handle it on the server, because the custom class might
not be known on the server and, thus, can't be deserialized there.

So, if I have

public class Duck implements Serializable {
String name;
int gender;
}

and have a corresponding EDataType with instance class name = Duck, we
can't deserialize Duck on the server unless we put Duck into the server
class path.

I think, if we want to support CUSTOM-To-String mappings we need to do
the conversion where it can be done: on the client.

However, this might also be problematic, if different clients have
different mapping methods (e.g. due to versioning conflicts ...).


Cheers,
Stefan
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #441244 is a reply to message #441216] Fri, 31 July 2009 10:08 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Stefan Winkler schrieb:
>> I'm not sure, though. This changed since we have the EPackage available
>> on the server. Now we have the EDataType on both client and server side
>> and we should use its String conversion methods.
>> I know that the
>> CDOProtocol does that already via CDOType.CUSTOM. Maybe the DBStore did
>> not catch up with this change but continues to expect a String in the
>> CDORevision / delta. It that case we'd just need an additional
>> TypeMapping for CDOType.CUSTOM / String. Stefan?
>>
>>
> Yes and no. It is true that we have EDataType on the Server and it would
> be no problem to create a TypeMapping which maps CUSTOM to String
> calling the String conversion methods.
>
> However, we don't have the *generated* or *user-defined* packages on the
> server - we use reflective models there.
>
If they are deployed on the server they're now available. The new
CDOPackageRegistry is smart enough to handle this ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #442268 is a reply to message #441244] Fri, 31 July 2009 12:41 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 301
Registered: July 2009
Location: Germany
Senior Member
CB (*C*omments *B*elow -- we should make this abbreviation
newsgroup-standard ;-))

Eike Stepper schrieb:
> Stefan Winkler schrieb:
>
>>> I'm not sure, though. This changed since we have the EPackage available
>>> on the server. Now we have the EDataType on both client and server side
>>> and we should use its String conversion methods.
>>> I know that the
>>> CDOProtocol does that already via CDOType.CUSTOM. Maybe the DBStore did
>>> not catch up with this change but continues to expect a String in the
>>> CDORevision / delta. It that case we'd just need an additional
>>> TypeMapping for CDOType.CUSTOM / String. Stefan?
>>>
>>>
>>>
>> Yes and no. It is true that we have EDataType on the Server and it would
>> be no problem to create a TypeMapping which maps CUSTOM to String
>> calling the String conversion methods.
>>
>> However, we don't have the *generated* or *user-defined* packages on the
>> server - we use reflective models there.
>>
>>
> If they are deployed on the server they're now available. The new
> CDOPackageRegistry is smart enough to handle this ;-)
>
Hmm... ok in the one case the server has to be start-time configured and
in the other case it can run out of the box and custom types are
converted on the client.
I think both scenarios have their rationale.

E.g., in a bigger setting, where the server is shared among different
applications, the latter case would be more operations-friendly...

Cheers,
Stefan
Re: [CDO] No suitable mapping found from EMF type CUSTOM to DB type DBType [message #451768 is a reply to message #442268] Sat, 01 August 2009 11:32 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
>> If they are deployed on the server they're now available. The new
>> CDOPackageRegistry is smart enough to handle this ;-)
>>
>>
> Hmm... ok in the one case the server has to be start-time configured and
> in the other case it can run out of the box and custom types are
> converted on the client.
> I think both scenarios have their rationale.
>
> E.g., in a bigger setting, where the server is shared among different
> applications, the latter case would be more operations-friendly...
Maybe we can do both:

if (packageUnit.getType == NATIVE)
revision.setValue(EDataType.createFromString(value));
else
revision.setValue(value);

The DBStore would have to do the opposite:

if (packageUnit.getType == NATIVE)
writeAttribute(EDataType.convertToString(revision.getValue() ));
else
writeAttribute(revision.getValue());


Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Previous Topic:custom drawn property sheet cells
Next Topic:Re: Duplicate case error in generated model
Goto Forum:
  


Current Time: Mon Dec 09 21:18:12 GMT 2019

Powered by FUDForum. Page generated in 0.03583 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top