Community
Participate
Working Groups
Created attachment 106594 [details] Screenshot of error pop-up Harald, I think there is a problem with the BAE Grid Project that you created in CVS at the Reading meeting. Otherwise, it has got mixed up somehow after checkout into my workspace? See exception below and screenshot. I'm not exactly sure yet the sequence of events which resulted in this, but probably this is not quite appropriate to be in CVS? Regards, Ken. java.lang.RuntimeException: Object already exists, but with a different type! Wanted 'uk.ac.soton.ecs.iam.grid.comms.client.DataConversation' but got 'uk.ac.soton.ecs.iam.grid.comms.client.RemoteDataService' for EPR Address: https://grid1.baegrid.co.uk:443/gria-basic-app-services-5-2/services/Dat aService/.cvsignore Metadata [0]: <ns1:type xmlns:ns1="http://it-innovation.soton.ac.uk/2005/grid">uk.ac.soton.ecs.i am.grid.comms.client.DataConversation</ns1:type> Metadata [1]: <ns1:parent xmlns:ns1="http://it-innovation.soton.ac.uk/2005/grid">https://grid1.bae grid.co.uk:443/gria-basic-app-services-5-2/services/DataService/.cvsigno re</ns1:parent> at uk.ac.soton.ecs.iam.grid.client.staterepos.AbstractStateRepository.getOr CreateObject(AbstractStateRepository.java:244) at eu.geclipse.efs.gria.GriaStore.openInputStream(GriaStore.java:441) at eu.geclipse.core.filesystem.internal.filesystem.GEclipseFileStore.openIn putStream(GEclipseFileStore.java:408) at org.eclipse.team.internal.ccvs.core.util.SyncFileWriter.getInputStream(S yncFileWriter.java:508) at org.eclipse.team.internal.ccvs.core.util.SyncFileWriter.readLines(SyncFi leWriter.java:526) at org.eclipse.team.internal.ccvs.core.util.SyncFileWriter.readCVSIgnoreEnt ries(SyncFileWriter.java:272) at org.eclipse.team.internal.ccvs.core.resources.SessionPropertySyncInfoCac he.getFolderIgnores(SessionPropertySyncInfoCache.java:72) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.cacheF olderIgnores(EclipseSynchronizer.java:1128) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.isIgno red(EclipseSynchronizer.java:384) at org.eclipse.team.internal.ccvs.core.resources.EclipseResource.isIgnored( EclipseResource.java:120) at org.eclipse.team.internal.ccvs.core.CVSSyncTreeSubscriber.isSupervised(C VSSyncTreeSubscriber.java:95) at org.eclipse.team.internal.ccvs.ui.CVSLightweightDecorator.isSupervised(C VSLightweightDecorator.java:255) at org.eclipse.team.internal.ccvs.ui.CVSLightweightDecorator.decorate(CVSLi ghtweightDecorator.java:213) at org.eclipse.team.internal.ccvs.ui.CVSLightweightDecorator.decorate(CVSLi ghtweightDecorator.java:165) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decora te(LightweightDecoratorDefinition.java:253) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$Lightweig htRunnable.run(LightweightDecoratorManager.java:71) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:857) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate( LightweightDecoratorManager.java:336) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecora tions(LightweightDecoratorManager.java:322) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCac hed(DecorationScheduler.java:369) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationS cheduler.java:329) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Looking at part of stack trace: >> java.lang.RuntimeException: Object already exists, but with a different >> type! Wanted 'uk.ac.soton.ecs.iam.grid.comms.client.DataConversation' >> but got 'uk.ac.soton.ecs.iam.grid.comms.client.RemoteDataService' for >> EPR Address: >> https://grid1.baegrid.co.uk:443/gria-basic-app-services-5-2/services/Dat >> aService/.cvsignore I see that stager ID is wrong. It looks that during check-in to CVS, additional file (.cvsignore) was created in Gria connection directory. And then for that file we are trying to find related data stager, which of course doesn't exist! Summarizing: - my last fixes don't fix this problem - described problem is related to bigger problem "cooperation with CVS/SVN", which should be solved/checked generally for whole g-Eclipse
I agree with Mariusz that we must have more testing and detailed analysis of the interworking between g-Eclipse projects and CVS/SVN.
(In reply to comment #2) > I agree with Mariusz that we must have more testing and detailed analysis of > the interworking between g-Eclipse projects and CVS/SVN. > Yepp, I think we all agree on that. Nevertheless please do not put all such bugs on my shoulders, we have a lot of other developers in the team :-P
Thomas, would you take care of looking at this strange interaction between gEclipse and CVS(.cvsignore) problem? Thanks!
I think the problem is that the EFS implementation for the GRIA data stagers does not handle requests on files that do not exist correctly. The CVS plugins checks for the existence of a ".cvsignore" file in every single directory of a project shared by CVS, if this file exists (or the EFS implementation in case of a mounted file system returns that it exists) the CVS plugin tries to open the file which then of course fails if it is not really existing. We had similar problems with every other EFS implementation till now (bug #234652 for SRM, bug #192138 for GridFTP) and for sftp correct handling of this case is also not yet implemented. If the FileInfo object is filled with correct values (i.e. it has to be flaged that the file is not existing, so it is not allowed to assume that every URI that is passed to EFS really exists) this should be working. I guess this could be a bit more difficult to implement for GRIA data stagers since they are not really a filesystem, but this is something where the person who did the GRIA EFS implementation (Mariusz?) should have a look at (or maybe its even easier because there is only one allowed URI per datastager, if I understood that right). I think this is something that should not be done at one place for all EFS plugins in g-Eclipse. The check for existence of files using the FileInfo object is something that is specified in EFS and if it is implemented in a way that real values are assigned the CVS plugin does not complain either. If we one day can get rid of the gecl filesystem and do not have a central place were all our EFS plugins are accessed through we need valid values from the EFS filesystems anyway.
