|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: [Announce] EMF CDO 2.0.0M4 is available [message #426304 is a reply to message #426246] |
Mon, 22 December 2008 21:02   |
 Anders Forsell
Messages: 127
Registered: July 2009 |
Senior Member |
|
|
Eike,
Once I got the correct versions, the setup was very easy.
Very clever way of using Ant!
---
Anders
"Eike Stepper" <stepper@esc-net.de> skrev i meddelandet
news:gink9q$r13$2@build.eclipse.org...
> Anders, André,
>
> Since our automated build does not yet use these setup-workspace
> properties/scripts they get out of sync just too easily.
> And even if we maintain them properly the caching of the huge files
> sometimes blurs the view on removed dependencies.
>
> The general rule is: For a HEAD-based workspace use the latest versions of
> the dependencies.
> André, the versions you discovered seem to be good. I updated the
> properties file accordingly:
>
> # Eclipse SDK
> target.eclipse.folder = S-3.5M4-200812111908
> target.eclipse.prefix = eclipse-SDK-3.5M4
>
> # EMF SDK
> target.emf.version = 2.5.0
> target.emf.build = S200812151800
> target.emf.file = emf-xsd-SDK-2.5.0M4.zip
>
> # Teneo SDK
> target.teneo.version = 1.0.2
> target.teneo.build = M200812170122
> target.teneo.file = emf-teneo-SDK-M200812170122.zip
>
> # Orbit Bundles
> orbit.release = S20081025033911
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> André Dietisheim schrieb:
>> Hi Anders
>>
>> just tested and found a bug. Here's what works for me:
>>
>> # Eclipse SDK
>> target.eclipse.folder = S-3.5M4-200812111908
>> target.eclipse.prefix = eclipse-SDK-3.5M4
>>
>> # EMF SDK
>> target.emf.version = 2.5.0
>> target.emf.build = S200812151800
>> target.emf.file = emf-xsd-SDK-2.5.0M4.zip
>>
>> # Teneo SDK
>> target.teneo.version = 1.0.2
>> target.teneo.build = M200812170122
>> target.teneo.file = emf-teneo-SDK-M200812170122.zip
>>
>> Cheers
>> André
>>
>> Anders Forsell wrote:
>>> I am trying to set up sources from HEAD but I got a bunch of errors
>>> during the ANT script, for example:
>>>
>>> [get] To: C:\develop\downloads\emf-sdo-xsd-SDK-2.5.0M2.zip
>>> [get] Error opening connection java.io.FileNotFoundException:
>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>> [get] Error opening connection java.io.FileNotFoundException:
>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>> [get] Error opening connection java.io.FileNotFoundException:
>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>> [get] Can't get
>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>> to C:\develop\downloads\emf-sdo-xsd-SDK-2.5.0M2.zip
>>> [get] Getting:
>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>>> [get] To: C:\develop\downloads\emf-teneo-SDK-M200809211527.zip
>>> [get] Error opening connection java.io.FileNotFoundException:
>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>>> [get] Error opening connection java.io.FileNotFoundException:
>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>>> [get] Error opening connection java.io.FileNotFoundException:
>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>>> [get] Can't get
>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>
>>> to C:\develop\downloads\emf-teneo-SDK-M200809211527.zip
>>>
>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>>
>>> It seems the "setup-workspace.properties" is out-of-date with respect to
>>> the version numbers of the EMF SDK being targeted?
>>>
>>> Which versions should I use?
>>>
>>> ---
>>> Anders
>>>
>>> "Eike Stepper" <stepper@esc-net.de> skrev i meddelandet
>>> news:gijbvh$4ol$1@build.eclipse.org...
>>>> Anders,
>>>>
>>>> If you install the ZIP downloads of Net4j and CDO into dropins you
>>>> shouldn't have problems.
>>>> We are planning to remove all plugins with 3rdparty dependencies from
>>>> the SDK to solve the p2 problem.
>>>>
>>>> And if you want to use the sources from HEAD please follow
>>>> http://wiki.eclipse.org/CDO_Source_Installation .
>>>> This should automatically populate the target platform as appropriate.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>>
>>>>
>>>>
>>>> Anders Forsell schrieb:
>>>>> I saw the P2 dependency problems described on the CDO wiki.
>>>>> I am not planning to use Hibernate or its dependencies from
>>>>> SpringSource.
>>>>> Can I use the dropins folder and remove some of the CDO plug-ins to
>>>>> get everything working (Derby with default DBStore)?
>>>>>
>>>>> Alternatively, is it better to checkout the CVS latest (HEAD) against
>>>>> Eclipse 3.5M4 (with EMF M4)?
>>>>>
>>>>> ---
>>>>> Anders
>>>>>
>>>>> "Anders Forsell" <aforsell1971@gmail.com> skrev i meddelandet
>>>>> news:gii3n4$4dg$1@build.eclipse.org...
>>>>>> I have Eclipse SDK 3.5M4 with EMF SDK 2.5.0M4 installed separately
>>>>>> from EMF update site, but when trying to intall Net4j and CDO M4 from
>>>>>> the CDO update site I get the following error:
>>>>>>
>>>>>> "Cannot find a solution satisfying the following requirements
>>>>>> org.eclipse.ltk.core.refactoring [3.5.0.v20081209-0100]."
>>>>>>
>>>>>> What is the recommended way to get the CDO/Net4j M4 packages to
>>>>>> install correctly?
>>>>>>
>>>>>> ---
>>>>>> Anders
>>>>>>
>>>>>> "Eike Stepper" <stepper@esc-net.de> skrev i meddelandet
>>>>>> news:gigknv$kii$1@build.eclipse.org...
>>>>>>> The following build [1] will be available at eclipse.org in the next
>>>>>>> 30-60 mins.
>>>>>>> [1]
>>>>>>> http://www.eclipse.org/modeling/emf/downloads/?project=cdo&a mp;showAll=1&hlbuild=S200812191119#S200812191119
>>>>>>>
>>>>>>> Updated release notes [2] will be available within to 24hrs.
>>>>>>> [2]
>>>>>>> http://www.eclipse.org/modeling/emf/news/relnotes.php?projec t=cdo&version=2.0.0M4
>>>>>>>
>>>>>>>
|
|
|
| Re: [Announce] EMF CDO 2.0.0M4 is available [message #426309 is a reply to message #426304] |
Tue, 23 December 2008 08:55 |
|
Anders Forsell schrieb:
> Eike,
>
> Once I got the correct versions, the setup was very easy.
> Very clever way of using Ant!
Thank you ;-)
I hope that we're soon be able to re-use at least the version properties
in the unattended build.
That would reduce the likelyhood of outdated values a lot...
Cheers
/Eike
----
http://thegordian.blogspot.com
>
> ---
> Anders
>
> "Eike Stepper" <stepper@esc-net.de> skrev i meddelandet
> news:gink9q$r13$2@build.eclipse.org...
>> Anders, André,
>>
>> Since our automated build does not yet use these setup-workspace
>> properties/scripts they get out of sync just too easily.
>> And even if we maintain them properly the caching of the huge files
>> sometimes blurs the view on removed dependencies.
>>
>> The general rule is: For a HEAD-based workspace use the latest
>> versions of the dependencies.
>> André, the versions you discovered seem to be good. I updated the
>> properties file accordingly:
>>
>> # Eclipse SDK
>> target.eclipse.folder = S-3.5M4-200812111908
>> target.eclipse.prefix = eclipse-SDK-3.5M4
>>
>> # EMF SDK
>> target.emf.version = 2.5.0
>> target.emf.build = S200812151800
>> target.emf.file = emf-xsd-SDK-2.5.0M4.zip
>>
>> # Teneo SDK
>> target.teneo.version = 1.0.2
>> target.teneo.build = M200812170122
>> target.teneo.file = emf-teneo-SDK-M200812170122.zip
>>
>> # Orbit Bundles
>> orbit.release = S20081025033911
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>> André Dietisheim schrieb:
>>> Hi Anders
>>>
>>> just tested and found a bug. Here's what works for me:
>>>
>>> # Eclipse SDK
>>> target.eclipse.folder = S-3.5M4-200812111908
>>> target.eclipse.prefix = eclipse-SDK-3.5M4
>>>
>>> # EMF SDK
>>> target.emf.version = 2.5.0
>>> target.emf.build = S200812151800
>>> target.emf.file = emf-xsd-SDK-2.5.0M4.zip
>>>
>>> # Teneo SDK
>>> target.teneo.version = 1.0.2
>>> target.teneo.build = M200812170122
>>> target.teneo.file = emf-teneo-SDK-M200812170122.zip
>>>
>>> Cheers
>>> André
>>>
>>> Anders Forsell wrote:
>>>> I am trying to set up sources from HEAD but I got a bunch of errors
>>>> during the ANT script, for example:
>>>>
>>>> [get] To: C:\develop\downloads\emf-sdo-xsd-SDK-2.5.0M2.zip
>>>> [get] Error opening connection
>>>> java.io.FileNotFoundException:
>>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>>>
>>>> [get] Error opening connection
>>>> java.io.FileNotFoundException:
>>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>>>
>>>> [get] Error opening connection
>>>> java.io.FileNotFoundException:
>>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>>>
>>>> [get] Can't get
>>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>>> to C:\develop\downloads\emf-sdo-xsd-SDK-2.5.0M2.zip
>>>> [get] Getting:
>>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>>>>
>>>> [get] To: C:\develop\downloads\emf-teneo-SDK-M200809211527.zip
>>>> [get] Error opening connection
>>>> java.io.FileNotFoundException:
>>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>>>>
>>>> [get] Error opening connection
>>>> java.io.FileNotFoundException:
>>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>>>>
>>>> [get] Error opening connection
>>>> java.io.FileNotFoundException:
>>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>>>>
>>>> [get] Can't get
>>>> http://download.eclipse.org/modeling/emf/teneo/downloads/dro ps/1.0.1/M200809211527/emf-teneo-SDK-M200809211527.zip
>>>>
>>
>>>> to C:\develop\downloads\emf-teneo-SDK-M200809211527.zip
>>>>
>>>> http://download.eclipse.org/modeling/emf/emf/downloads/drops /2.5.0/S200809231800/emf-sdo-xsd-SDK-2.5.0M2.zip
>>>>
>>>>
>>>> It seems the "setup-workspace.properties" is out-of-date with
>>>> respect to the version numbers of the EMF SDK being targeted?
>>>>
>>>> Which versions should I use?
>>>>
>>>> ---
>>>> Anders
>>>>
>>>> "Eike Stepper" <stepper@esc-net.de> skrev i meddelandet
>>>> news:gijbvh$4ol$1@build.eclipse.org...
>>>>> Anders,
>>>>>
>>>>> If you install the ZIP downloads of Net4j and CDO into dropins you
>>>>> shouldn't have problems.
>>>>> We are planning to remove all plugins with 3rdparty dependencies
>>>>> from the SDK to solve the p2 problem.
>>>>>
>>>>> And if you want to use the sources from HEAD please follow
>>>>> http://wiki.eclipse.org/CDO_Source_Installation .
>>>>> This should automatically populate the target platform as
>>>>> appropriate.
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://thegordian.blogspot.com
>>>>>
>>>>>
>>>>>
>>>>> Anders Forsell schrieb:
>>>>>> I saw the P2 dependency problems described on the CDO wiki.
>>>>>> I am not planning to use Hibernate or its dependencies from
>>>>>> SpringSource.
>>>>>> Can I use the dropins folder and remove some of the CDO plug-ins
>>>>>> to get everything working (Derby with default DBStore)?
>>>>>>
>>>>>> Alternatively, is it better to checkout the CVS latest (HEAD)
>>>>>> against Eclipse 3.5M4 (with EMF M4)?
>>>>>>
>>>>>> ---
>>>>>> Anders
>>>>>>
>>>>>> "Anders Forsell" <aforsell1971@gmail.com> skrev i meddelandet
>>>>>> news:gii3n4$4dg$1@build.eclipse.org...
>>>>>>> I have Eclipse SDK 3.5M4 with EMF SDK 2.5.0M4 installed
>>>>>>> separately from EMF update site, but when trying to intall Net4j
>>>>>>> and CDO M4 from the CDO update site I get the following error:
>>>>>>>
>>>>>>> "Cannot find a solution satisfying the following requirements
>>>>>>> org.eclipse.ltk.core.refactoring [3.5.0.v20081209-0100]."
>>>>>>>
>>>>>>> What is the recommended way to get the CDO/Net4j M4 packages to
>>>>>>> install correctly?
>>>>>>>
>>>>>>> ---
>>>>>>> Anders
>>>>>>>
>>>>>>> "Eike Stepper" <stepper@esc-net.de> skrev i meddelandet
>>>>>>> news:gigknv$kii$1@build.eclipse.org...
>>>>>>>> The following build [1] will be available at eclipse.org in the
>>>>>>>> next 30-60 mins.
>>>>>>>> [1]
>>>>>>>> http://www.eclipse.org/modeling/emf/downloads/?project=cdo&a mp;showAll=1&hlbuild=S200812191119#S200812191119
>>>>>>>>
>>>>>>>>
>>>>>>>> Updated release notes [2] will be available within to 24hrs.
>>>>>>>> [2]
>>>>>>>> http://www.eclipse.org/modeling/emf/news/relnotes.php?projec t=cdo&version=2.0.0M4
>>>>>>>>
>>>>>>>>
>>>>>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: [Announce] EMF CDO 2.0.0M6 is available [message #428475 is a reply to message #428405] |
Mon, 23 March 2009 15:28 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Hi,
It took me one day to move to this new CDO M6 :(
Here are some issues I've faced.
1) First issue :
As Kai mentioned it, in his post
( http://www.eclipse.org/newsportal/article.php?id=40267&g roup=eclipse.tools.emf#40267),
CDOSessionConfiguration.setLazyPackageRegistry() is not anymore present in
the API.
As ViK suggested, I replace this call by
CDOPackageRegistryPopulator.populate(session.getPackageRegis try());
Nevertheless, it does not make the job !
I got exceptions, it seems my packages are not registered...
Here is the code I'm using to connect :
// Create TCP connector through wiring container
IConnector connector = (IConnector)
IPluginContainer.INSTANCE.getElement("org.eclipse.net4j.connectors ",
"tcp", "localhost:2036"); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
// Create CDO session configuration
CDOSessionConfiguration config = CDONet4jUtil.createSessionConfiguration();
config.setConnector(connector);
config.setRepositoryName("repo1"); //$NON-NLS-1$
// Open the session.
CDOSession session = config.openSession();
// Set Lazy Package Registry.
CDOPackageRegistryPopulator.populate(session.getPackageRegis try());
Thus, I had a look at CDOPackageRegistryPopulator implementation.
CDOPackageRegistryPopulator.populate(EPackage.Registry source,
CDOPackageRegistry target) and
CDOPackageRegistryPopulator.populateFirstMatch(..) methods are really
weird.
Why don't use a single loop to register all packages as descriptors ?
populateFirstMatch(..) method is only called in populate(EPackage.Registry
source, CDOPackageRegistry target)method.
From my point of view, it's better (in terms of performance) to loop over
the EMF package registry once.
Hence, the CDOPackageRegistryPopulator.populate(EPackage.Registry source,
CDOPackageRegistry target) code can be replaced with something like that :
Registry source = EPackage.Registry.INSTANCE;
Iterator<Entry<String, Object>> iterator = source.entrySet().iterator();
while (iterator.hasNext()) {
Entry<String, Object> entry = iterator.next();
String nsURI = entry.getKey();
if (!target.containsKey(nsURI)) {
target.put(nsURI, new Descriptor(source, nsURI));
}
}
That's great to register these packages lazily with
CDOPackageRegistryPopulator.Descriptor but we should handle them as
descriptor when needed.
In CDOPackageResgistryImpl.getPackageInfo(EPackage ePackage) before the
"return null;" statement, I had that code :
if (object instanceof Descriptor) {
initPackageUnit(ePackage);
return getPackageInfo(ePackage);
}
Because this method only expects InternalCDOPackageInfo object as value
from a nsURI :
// Looks in the registry
Object object = get(ePackage.getNsURI());
but with lazy registration (CDOPackageRegistryPopulator.populate(..)), we
have CDOPackageRegistryPopulator.Descriptor instead of.
Now, it runs smoothly for that point :)
2) Second issue :
EMF BigInteger and BigDecimal data types are not handled. I got exceptions.
Indeed, CDOModelUtil registers null for both data types.
Instead of null, I put CDOType.CUSTOM in the static initialization bloc
for both data types (in 2.0.0 M5, it was the case).
registerCoreType(types, EcorePackage.eINSTANCE.getEBigDecimal(),
CDOType.CUSTOM);
registerCoreType(types, EcorePackage.eINSTANCE.getEBigInteger(),
CDOType.CUSTOM);
3) Third issue :
scenario :
A) I start an empty HSQLDB data base
B) I start my CDO Server connected to this HSQLDB db.
C) I populate data in the CDO Server x times in the same resource named
melody(arbitrary name).
That runs well.
D) I stop my CDO Server from the OSGi console, with close command.
E) I start my CDO Server again.
F) I populate data in the CDO Server, I got the following exceptions :
java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EEnumLiteralImpl
at
org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$21.doW riteValue(CDOTypeImpl.java:303)
at
org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$Object Type.writeValue(CDOTypeImpl.java:432)
at
org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDOFeatureValue(CDODataOutputImpl.java:251)
at
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. writeValues(AbstractCDORevision.java:643)
at
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. write(AbstractCDORevision.java:162)
at
org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDORevision(CDODataOutputImpl.java:154)
at
org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.responding(LoadRevisionIndication.java:158)
at
org.eclipse.emf.cdo.internal.server.protocol.CDOServerIndica tion.responding(CDOServerIndication.java:119)
at
org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:285)
at
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
at
org.eclipse.emf.cdo.internal.server.protocol.CDOReadIndicati on.execute(CDOReadIndication.java:36)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
!ENTRY org.eclipse.net4j 4 0 2009-03-23 16:05:08.602
!MESSAGE org.eclipse.emf.ecore.impl.EEnumLiteralImpl
!STACK 0
java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EEnumLiteralImpl
at
org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$21.doW riteValue(CDOTypeImpl.java:303)
at
org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$Object Type.writeValue(CDOTypeImpl.java:432)
at
org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDOFeatureValue(CDODataOutputImpl.java:251)
at
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. writeValues(AbstractCDORevision.java:643)
at
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. write(AbstractCDORevision.java:162)
at
org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDORevision(CDODataOutputImpl.java:154)
at
org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.responding(LoadRevisionIndication.java:158)
at
org.eclipse.emf.cdo.internal.server.protocol.CDOServerIndica tion.responding(CDOServerIndication.java:119)
at
org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:285)
at
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
at
org.eclipse.emf.cdo.internal.server.protocol.CDOReadIndicati on.execute(CDOReadIndication.java:36)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
!ENTRY org.eclipse.emf.cdo.server 4 0 2009-03-23 16:05:12.728
!MESSAGE Duplicate resource or folder: melody in folder NULL
!STACK 0
java.lang.IllegalStateException: Duplicate resource or folder: melody in
folder NULL
at
org.eclipse.emf.cdo.server.internal.db.mapping.HorizontalCla ssMapping.checkDuplicateResources(HorizontalClassMapping.jav a:76)
at
org.eclipse.emf.cdo.server.internal.db.mapping.ClassMapping. writeRevision(ClassMapping.java:372)
at
org.eclipse.emf.cdo.server.internal.db.mapping.HorizontalCla ssMapping.writeRevision(HorizontalClassMapping.java:50)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write Revision(DBStoreAccessor.java:560)
at
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write Revisions(DBStoreAccessor.java:542)
at
org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:137)
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:87)
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:337)
at
org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:266)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication$1.runLoop(CommitTransactionIndication.java:73)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication$1.runLoop(CommitTransactionIndication.java:1)
at
org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:324)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:197 )
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java: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:317)
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:237)
at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
I get this problem only if start a CDO Server with existing data.
Does anyone have an idea ?
A part from that 3 issues, I filed a bug sometime ago regarding the
CDOResourceImpl (https://bugs.eclipse.org/bugs/show_bug.cgi?id=265136)
Would it be possible to have a fix with the suggestions I made in the bug
comments ?
Stephane.
Eike Stepper wrote:
> CDO Users,
> Please don't forget to re-create your database after istalling this M6
> version of CDO!
> I hope to see many of you at the EclipseCon ;-)
> Cheers
> /Eike
> ----
> http://thegordian.blogspot.com
> Eike Stepper schrieb:
>> The following build [1] will be available at eclipse.org in the next 30-60
mins.
>> [1]
http://www.eclipse.org/modeling/emf/downloads/?project=cdo&a mp;showAll=1&hlbuild=S200903191750#S200903191750
>>
>> Updated release notes [2] should be updated within 24hrs.
>> [2]
http://www.eclipse.org/modeling/emf/news/relnotes.php?projec t=cdo&version=2.0.0M6
>>
>>
>>
|
|
|
| Re: [Announce] EMF CDO 2.0.0M6 is available [message #428482 is a reply to message #428475] |
Mon, 23 March 2009 17:39 |
|
Stéphane,
Apologies for these inconveniences. The emf-on-server branch locked HEAD
for longer than expected so we are a bit behind with bug fixing.
Unfortunately I could also not influence the deadline of M6 which is
dictated by the Galileo release train and then the EclipseCon got in the
way. Some more comments below...
Stéphane Fournier schrieb:
> Hi,
>
> It took me one day to move to this new CDO M6 :(
>
> Here are some issues I've faced.
>
> 1) First issue :
>
> As Kai mentioned it, in his post
> ( http://www.eclipse.org/newsportal/article.php?id=40267&g roup=eclipse.tools.emf#40267),
> CDOSessionConfiguration.setLazyPackageRegistry() is not anymore
> present in the API.
> As ViK suggested, I replace this call by
> CDOPackageRegistryPopulator.populate(session.getPackageRegis try());
Basically the CDOPackageRegistryPopulator is not a replacement for the
former *lazy* registry but rather for the former *eager* registry.
Please not also, that you there are two modes available: Calling the
static populate() method directly is a one-loop-only procedure. But you
can also instantiate the class and have the two registries synced in
periodic intervals.
The new CDOPackageRegistry *always* behaves like the former lazy
registry! You don't need to do anything particular for this mode. Should
I explain the differences between the old lazy and eager concepts in
more detail?
>
> Nevertheless, it does not make the job !
> I got exceptions, it seems my packages are not registered...
Can you wrap all this info into a bugzilla and also attach the actual
stack trace?
In case that none of the other team members jumps in immediately Simon
or I will address this issue after the EclipseCon...
> Here is the code I'm using to connect :
> // Create TCP connector through wiring container
> IConnector connector = (IConnector)
> IPluginContainer.INSTANCE.getElement("org.eclipse.net4j.connectors ",
> "tcp", "localhost:2036"); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
> // Create CDO session configuration
> CDOSessionConfiguration config =
> CDONet4jUtil.createSessionConfiguration();
> config.setConnector(connector);
> config.setRepositoryName("repo1"); //$NON-NLS-1$
> // Open the session.
> CDOSession session = config.openSession();
> // Set Lazy Package Registry.
> CDOPackageRegistryPopulator.populate(session.getPackageRegis try());
>
> Thus, I had a look at CDOPackageRegistryPopulator implementation.
> CDOPackageRegistryPopulator.populate(EPackage.Registry source,
> CDOPackageRegistry target) and
> CDOPackageRegistryPopulator.populateFirstMatch(..) methods are really
> weird.
I wouldn't say "weird". They're either wrong or you just don't
understand the rationale :P
>
> Why don't use a single loop to register all packages as descriptors ?
The reason is that the registration of one package can trigger the
registration of other packages in the same tree hierarchy of packages.
The contents of the package registry is in some way a flattened list of
packages that are otherwise organized in a hierarchical structure.
That's the whole point about the new concept of the CDOPackageUnits.
>
> populateFirstMatch(..) method is only called in
> populate(EPackage.Registry source, CDOPackageRegistry target)method.
> From my point of view, it's better (in terms of performance) to loop
> over the EMF package registry once.
> Hence, the CDOPackageRegistryPopulator.populate(EPackage.Registry
> source, CDOPackageRegistry target) code can be replaced with something
> like that :
>
> Registry source = EPackage.Registry.INSTANCE;
> Iterator<Entry<String, Object>> iterator = source.entrySet().iterator();
> while (iterator.hasNext()) {
> Entry<String, Object> entry = iterator.next();
> String nsURI = entry.getKey();
> if (!target.containsKey(nsURI)) {
> target.put(nsURI, new Descriptor(source, nsURI));
> }
> }
>
> That's great to register these packages lazily with
> CDOPackageRegistryPopulator.Descriptor but we should handle them as
> descriptor when needed.
> In CDOPackageResgistryImpl.getPackageInfo(EPackage ePackage) before
> the "return null;" statement, I had that code :
> if (object instanceof Descriptor) {
> initPackageUnit(ePackage);
> return getPackageInfo(ePackage);
> }
> Because this method only expects InternalCDOPackageInfo object as
> value from a nsURI :
> // Looks in the registry
> Object object = get(ePackage.getNsURI());
> but with lazy registration (CDOPackageRegistryPopulator.populate(..)),
> we have CDOPackageRegistryPopulator.Descriptor instead of.
>
> Now, it runs smoothly for that point :)
>
> 2) Second issue :
> EMF BigInteger and BigDecimal data types are not handled. I got
> exceptions.
> Indeed, CDOModelUtil registers null for both data types.
> Instead of null, I put CDOType.CUSTOM in the static initialization
> bloc for both data types (in 2.0.0 M5, it was the case).
> registerCoreType(types, EcorePackage.eINSTANCE.getEBigDecimal(),
> CDOType.CUSTOM);
> registerCoreType(types, EcorePackage.eINSTANCE.getEBigInteger(),
> CDOType.CUSTOM);
Please file a bugzilla so that we can introduce dedicated CDOTypes for
BigInteger and BigDecimal.
BTW. we plan to rework the internal type system such that you'll be able
to register your own custom value handlers directly after the Con...
>
> 3) Third issue :
> scenario : A) I start an empty HSQLDB data base
> B) I start my CDO Server connected to this HSQLDB db.
> C) I populate data in the CDO Server x times in the same resource
> named melody(arbitrary name).
>
> That runs well.
>
> D) I stop my CDO Server from the OSGi console, with close command.
> E) I start my CDO Server again.
> F) I populate data in the CDO Server, I got the following exceptions :
>
> java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EEnumLiteralImpl
> at
> org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$21.doW riteValue(CDOTypeImpl.java:303)
>
> at
> org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$Object Type.writeValue(CDOTypeImpl.java:432)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDOFeatureValue(CDODataOutputImpl.java:251)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. writeValues(AbstractCDORevision.java:643)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. write(AbstractCDORevision.java:162)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDORevision(CDODataOutputImpl.java:154)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.responding(LoadRevisionIndication.java:158)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CDOServerIndica tion.responding(CDOServerIndication.java:119)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
>
> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:285)
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CDOReadIndicati on.execute(CDOReadIndication.java:36)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>
> at java.lang.Thread.run(Thread.java:595)
>
> !ENTRY org.eclipse.net4j 4 0 2009-03-23 16:05:08.602
> !MESSAGE org.eclipse.emf.ecore.impl.EEnumLiteralImpl
> !STACK 0
> java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EEnumLiteralImpl
> at
> org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$21.doW riteValue(CDOTypeImpl.java:303)
>
> at
> org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$Object Type.writeValue(CDOTypeImpl.java:432)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDOFeatureValue(CDODataOutputImpl.java:251)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. writeValues(AbstractCDORevision.java:643)
>
> at
> org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. write(AbstractCDORevision.java:162)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDORevision(CDODataOutputImpl.java:154)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.responding(LoadRevisionIndication.java:158)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CDOServerIndica tion.responding(CDOServerIndication.java:119)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
>
> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:285)
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CDOReadIndicati on.execute(CDOReadIndication.java:36)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>
> at java.lang.Thread.run(Thread.java:595)
>
> !ENTRY org.eclipse.emf.cdo.server 4 0 2009-03-23 16:05:12.728
> !MESSAGE Duplicate resource or folder: melody in folder NULL
> !STACK 0
> java.lang.IllegalStateException: Duplicate resource or folder: melody
> in folder NULL
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.HorizontalCla ssMapping.checkDuplicateResources(HorizontalClassMapping.jav a:76)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.ClassMapping. writeRevision(ClassMapping.java:372)
>
> at
> org.eclipse.emf.cdo.server.internal.db.mapping.HorizontalCla ssMapping.writeRevision(HorizontalClassMapping.java:50)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write Revision(DBStoreAccessor.java:560)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write Revisions(DBStoreAccessor.java:542)
>
> at
> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:137)
>
> 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:87)
>
> 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:337)
>
> at
> org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:266)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication$1.runLoop(CommitTransactionIndication.java:73)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication$1.runLoop(CommitTransactionIndication.java:1)
>
> at
> org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:324)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:197 )
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java: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:317)
> 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:237)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>
> at java.lang.Thread.run(Thread.java:595)
>
>
> I get this problem only if start a CDO Server with existing data.
> Does anyone have an idea ?
Not concretely but I had the feeling that enum handling might not be
100% correct. Apologies for that again!
I'm currently not sure if we already have a bugzilla for that. Please
feel free to file one.
>
> A part from that 3 issues, I filed a bug sometime ago regarding the
> CDOResourceImpl (https://bugs.eclipse.org/bugs/show_bug.cgi?id=265136)
> Would it be possible to have a fix with the suggestions I made in the
> bug comments ?
Sure! As I said, we were pressed in several ways and I hope that after
the Con everything comes back to normal operation ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
>
> Stephane.
>
>
>
>
>
>
>
> Eike Stepper wrote:
>
>> CDO Users,
>
>> Please don't forget to re-create your database after istalling this
>> M6 version of CDO!
>> I hope to see many of you at the EclipseCon ;-)
>
>> Cheers
>> /Eike
>
>> ----
>> http://thegordian.blogspot.com
>
>
>
>> Eike Stepper schrieb:
>>> The following build [1] will be available at eclipse.org in the next
>>> 30-60
> mins.
>>> [1]
> http://www.eclipse.org/modeling/emf/downloads/?project=cdo&a mp;showAll=1&hlbuild=S200903191750#S200903191750
>
>>>
>>> Updated release notes [2] should be updated within 24hrs.
>>> [2]
> http://www.eclipse.org/modeling/emf/news/relnotes.php?projec t=cdo&version=2.0.0M6
>
>>>
>>>
>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Announce] EMF CDO 2.0.0M6 is available [message #428500 is a reply to message #428482] |
Tue, 24 March 2009 09:12 |
Stephane fournier
Messages: 340
Registered: July 2009 |
Senior Member |
|
|
Eike Stepper wrote:
> Stéphane,
> Apologies for these inconveniences. The emf-on-server branch locked HEAD
> for longer than expected so we are a bit behind with bug fixing.
> Unfortunately I could also not influence the deadline of M6 which is
> dictated by the Galileo release train and then the EclipseCon got in the
> way. Some more comments below...
I already faced this kind of situation ;)
Answers below..
Enjoyed EclipseCon, lucky you !
Stephane.
> Stéphane Fournier schrieb:
>> Hi,
>>
>> It took me one day to move to this new CDO M6 :(
>>
>> Here are some issues I've faced.
>>
>> 1) First issue :
>>
>> As Kai mentioned it, in his post
>>
( http://www.eclipse.org/newsportal/article.php?id=40267&g roup=eclipse.tools.emf#40267),
>> CDOSessionConfiguration.setLazyPackageRegistry() is not anymore
>> present in the API.
>> As ViK suggested, I replace this call by
>> CDOPackageRegistryPopulator.populate(session.getPackageRegis try());
> Basically the CDOPackageRegistryPopulator is not a replacement for the
> former *lazy* registry but rather for the former *eager* registry.
> Please not also, that you there are two modes available: Calling the
> static populate() method directly is a one-loop-only procedure. But you
> can also instantiate the class and have the two registries synced in
> periodic intervals.
> The new CDOPackageRegistry *always* behaves like the former lazy
> registry! You don't need to do anything particular for this mode. Should
> I explain the differences between the old lazy and eager concepts in
> more detail?
Not necessary.
>>
>> Nevertheless, it does not make the job !
>> I got exceptions, it seems my packages are not registered...
> Can you wrap all this info into a bugzilla and also attach the actual
> stack trace?
I've filed a bugzilla :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=269787
I checked that again this morning, without
CDOPackageRegistryPopulator.populate() call, it does not work.
> In case that none of the other team members jumps in immediately Simon
> or I will address this issue after the EclipseCon...
>> Here is the code I'm using to connect :
>> // Create TCP connector through wiring container
>> IConnector connector = (IConnector)
>> IPluginContainer.INSTANCE.getElement("org.eclipse.net4j.connectors ",
>> "tcp", "localhost:2036"); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
>> // Create CDO session configuration
>> CDOSessionConfiguration config =
>> CDONet4jUtil.createSessionConfiguration();
>> config.setConnector(connector);
>> config.setRepositoryName("repo1"); //$NON-NLS-1$
>> // Open the session.
>> CDOSession session = config.openSession();
>> // Set Lazy Package Registry.
>> CDOPackageRegistryPopulator.populate(session.getPackageRegis try());
>>
>> Thus, I had a look at CDOPackageRegistryPopulator implementation.
>> CDOPackageRegistryPopulator.populate(EPackage.Registry source,
>> CDOPackageRegistry target) and
>> CDOPackageRegistryPopulator.populateFirstMatch(..) methods are really
>> weird.
> I wouldn't say "weird". They're either wrong or you just don't
> understand the rationale :P
>>
>> Why don't use a single loop to register all packages as descriptors ?
> The reason is that the registration of one package can trigger the
> registration of other packages in the same tree hierarchy of packages.
> The contents of the package registry is in some way a flattened list of
> packages that are otherwise organized in a hierarchical structure.
> That's the whole point about the new concept of the CDOPackageUnits.
>>
I was thinking EMF generates 'generated_package' extensions for all
packages (sub packages included) contained in an Ecore model. Hence, the
EMF package registry would be only populated by collecting these
extensions with all packages and sub-packages....
>> populateFirstMatch(..) method is only called in
>> populate(EPackage.Registry source, CDOPackageRegistry target)method.
>> From my point of view, it's better (in terms of performance) to loop
>> over the EMF package registry once.
>> Hence, the CDOPackageRegistryPopulator.populate(EPackage.Registry
>> source, CDOPackageRegistry target) code can be replaced with something
>> like that :
>>
>> Registry source = EPackage.Registry.INSTANCE;
>> Iterator<Entry<String, Object>> iterator = source.entrySet().iterator();
>> while (iterator.hasNext()) {
>> Entry<String, Object> entry = iterator.next();
>> String nsURI = entry.getKey();
>> if (!target.containsKey(nsURI)) {
>> target.put(nsURI, new Descriptor(source, nsURI));
>> }
>> }
>>
>> That's great to register these packages lazily with
>> CDOPackageRegistryPopulator.Descriptor but we should handle them as
>> descriptor when needed.
>> In CDOPackageResgistryImpl.getPackageInfo(EPackage ePackage) before
>> the "return null;" statement, I had that code :
>> if (object instanceof Descriptor) {
>> initPackageUnit(ePackage);
>> return getPackageInfo(ePackage);
>> }
>> Because this method only expects InternalCDOPackageInfo object as
>> value from a nsURI :
>> // Looks in the registry
>> Object object = get(ePackage.getNsURI());
>> but with lazy registration (CDOPackageRegistryPopulator.populate(..)),
>> we have CDOPackageRegistryPopulator.Descriptor instead of.
>>
>> Now, it runs smoothly for that point :)
>>
>> 2) Second issue :
>> EMF BigInteger and BigDecimal data types are not handled. I got
>> exceptions.
>> Indeed, CDOModelUtil registers null for both data types.
>> Instead of null, I put CDOType.CUSTOM in the static initialization
>> bloc for both data types (in 2.0.0 M5, it was the case).
>> registerCoreType(types, EcorePackage.eINSTANCE.getEBigDecimal(),
>> CDOType.CUSTOM);
>> registerCoreType(types, EcorePackage.eINSTANCE.getEBigInteger(),
>> CDOType.CUSTOM);
> Please file a bugzilla so that we can introduce dedicated CDOTypes for
> BigInteger and BigDecimal.
> BTW. we plan to rework the internal type system such that you'll be able
> to register your own custom value handlers directly after the Con...
Done : https://bugs.eclipse.org/bugs/show_bug.cgi?id=269789
>>
>> 3) Third issue :
>> scenario : A) I start an empty HSQLDB data base
>> B) I start my CDO Server connected to this HSQLDB db.
>> C) I populate data in the CDO Server x times in the same resource
>> named melody(arbitrary name).
>>
>> That runs well.
>>
>> D) I stop my CDO Server from the OSGi console, with close command.
>> E) I start my CDO Server again.
>> F) I populate data in the CDO Server, I got the following exceptions :
>>
>> java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EEnumLiteralImpl
>> at
>>
org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$21.doW riteValue(CDOTypeImpl.java:303)
>>
>> at
>>
org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$Object Type.writeValue(CDOTypeImpl.java:432)
>>
>> at
>>
org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDOFeatureValue(CDODataOutputImpl.java:251)
>>
>> at
>>
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. writeValues(AbstractCDORevision.java:643)
>>
>> at
>>
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. write(AbstractCDORevision.java:162)
>>
>> at
>>
org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDORevision(CDODataOutputImpl.java:154)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.responding(LoadRevisionIndication.java:158)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CDOServerIndica tion.responding(CDOServerIndication.java:119)
>>
>> at
>>
org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
>>
>> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:285)
>> at
>>
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CDOReadIndicati on.execute(CDOReadIndication.java:36)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>>
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>>
>> at java.lang.Thread.run(Thread.java:595)
>>
>> !ENTRY org.eclipse.net4j 4 0 2009-03-23 16:05:08.602
>> !MESSAGE org.eclipse.emf.ecore.impl.EEnumLiteralImpl
>> !STACK 0
>> java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EEnumLiteralImpl
>> at
>>
org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$21.doW riteValue(CDOTypeImpl.java:303)
>>
>> at
>>
org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$Object Type.writeValue(CDOTypeImpl.java:432)
>>
>> at
>>
org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDOFeatureValue(CDODataOutputImpl.java:251)
>>
>> at
>>
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. writeValues(AbstractCDORevision.java:643)
>>
>> at
>>
org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision. write(AbstractCDORevision.java:162)
>>
>> at
>>
org.eclipse.emf.cdo.internal.common.io.CDODataOutputImpl.wri teCDORevision(CDODataOutputImpl.java:154)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.responding(LoadRevisionIndication.java:158)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CDOServerIndica tion.responding(CDOServerIndication.java:119)
>>
>> at
>>
org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOu tput(IndicationWithResponse.java:96)
>>
>> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:285)
>> at
>>
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:65)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CDOReadIndicati on.execute(CDOReadIndication.java:36)
>>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:237)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>>
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>>
>> at java.lang.Thread.run(Thread.java:595)
>>
>> !ENTRY org.eclipse.emf.cdo.server 4 0 2009-03-23 16:05:12.728
>> !MESSAGE Duplicate resource or folder: melody in folder NULL
>> !STACK 0
>> java.lang.IllegalStateException: Duplicate resource or folder: melody
>> in folder NULL
>> at
>>
org.eclipse.emf.cdo.server.internal.db.mapping.HorizontalCla ssMapping.checkDuplicateResources(HorizontalClassMapping.jav a:76)
>>
>> at
>>
org.eclipse.emf.cdo.server.internal.db.mapping.ClassMapping. writeRevision(ClassMapping.java:372)
>>
>> at
>>
org.eclipse.emf.cdo.server.internal.db.mapping.HorizontalCla ssMapping.writeRevision(HorizontalClassMapping.java:50)
>>
>> at
>>
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write Revision(DBStoreAccessor.java:560)
>>
>> at
>>
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.write Revisions(DBStoreAccessor.java:542)
>>
>> at
>> org.eclipse.emf.cdo.spi.server.StoreAccessor.write(StoreAcce ssor.java:137)
>>
>> 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:87)
>>
>> 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:337)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.TransactionCommitContext Impl.write(TransactionCommitContextImpl.java:266)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication$1.runLoop(CommitTransactionIndication.java:73)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication$1.runLoop(CommitTransactionIndication.java:1)
>>
>> at
>>
org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(Pr ogressDistributor.java:96)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicatingCommit(CommitTransactionIndication.ja va:324)
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:197 )
>>
>> at
>>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java: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:317)
>> 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:237)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:145)
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:650)
>>
>> at
>>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:675)
>>
>> at java.lang.Thread.run(Thread.java:595)
>>
>>
>> I get this problem only if start a CDO Server with existing data.
>> Does anyone have an idea ?
> Not concretely but I had the feeling that enum handling might not be
> 100% correct. Apologies for that again!
> I'm currently not sure if we already have a bugzilla for that. Please
> feel free to file one.
>>
Done : https://bugs.eclipse.org/bugs/show_bug.cgi?id=269793
>> A part from that 3 issues, I filed a bug sometime ago regarding the
>> CDOResourceImpl (https://bugs.eclipse.org/bugs/show_bug.cgi?id=265136)
>> Would it be possible to have a fix with the suggestions I made in the
>> bug comments ?
> Sure! As I said, we were pressed in several ways and I hope that after
> the Con everything comes back to normal operation ;-)
> Cheers
> /Eike
> ----
> http://thegordian.blogspot.com
>>
>> Stephane.
>>
>>
>>
>>
>>
>>
>>
>> Eike Stepper wrote:
>>
>>> CDO Users,
>>
>>> Please don't forget to re-create your database after istalling this
>>> M6 version of CDO!
>>> I hope to see many of you at the EclipseCon ;-)
>>
>>> Cheers
>>> /Eike
>>
>>> ----
>>> http://thegordian.blogspot.com
>>
>>
>>
>>> Eike Stepper schrieb:
>>>> The following build [1] will be available at eclipse.org in the next
>>>> 30-60
>> mins.
>>>> [1]
>>
http://www.eclipse.org/modeling/emf/downloads/?project=cdo&a mp;showAll=1&hlbuild=S200903191750#S200903191750
>>
>>>>
>>>> Updated release notes [2] should be updated within 24hrs.
>>>> [2]
>>
http://www.eclipse.org/modeling/emf/news/relnotes.php?projec t=cdo&version=2.0.0M6
>>
>>>>
>>>>
>>>>
>>
>>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
] 
Search
Help
Register
Login
Home
