Bugzilla – Full Text Bug Listing
| Summary: | [Dawn] GMF extension throws CoreException | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Martin Fluegge <martin.fluegge> | ||||||
| Component: | cdo.dawn | Assignee: | Martin Fluegge <martin.fluegge> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Eike Stepper <stepper> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | Flags: | stepper:
review-
|
||||||
| Version: | 4.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Martin Fluegge
Created attachment 185846 [details]
Patch v1
Shame on me. It turned out, that the exception was there all the time. But it is only visible when "-consoleLog" is activated. It also seems that it does not have a major influence when "-consoleLog" is not set (seems to be just a print out, but I did not find where it is printed), but if it is activated it simply floods the lock and slows the application. Since the root of the problem (calling the file system) is heavily used by GMF I do not think that find can get a clean solution in a short time.
That's why I attach the patch which is merly some sort of a hack. But it seems to work to solve our problem.
Eike, I would like to discuss this solution with you. Especially the influcence on our CDO FS. Please ping me if you find some time.
(In reply to comment #1) > Created an attachment (id=185846) > Patch v1 > > Shame on me. It turned out, that the exception was there all the time. But it is > only visible when "-consoleLog" is activated. It also seems that it does not > have a major influence when "-consoleLog" is not set What would you expect? > (seems to be just a print > out, but I did not find where it is printed), but if it is activated it simply > floods the lock What lock? > and slows the application. Since the root of the problem > (calling the file system) is heavily used by GMF I do not think that find can > get a clean solution in a short time. Can't the WorkspaceSynchronizer be deactivated or replaced with a stub? > That's why I attach the patch which is merly some sort of a hack. But it seems > to work to solve our problem. I don't like it ;-( > Eike, I would like to discuss this solution with you. Especially the influcence > on our CDO FS. There's no current influence but it will prevent us from using the cdo: protocol at the EFS layer in the future. Worse: It's visible outside of CDO and that's a no go for an internal hack. > Please ping me if you find some time. Will do. I've no clue why API Tools complain about "DawnGMFFileStore illegally implements IFileInfo". By looking at your patch I noticed that you already have an internal package for the OM class. That package is not marked internal! Created attachment 185849 [details]
Patch v2 - do not commit
See commetn #2
> > > > Shame on me. It turned out, that the exception was there all the time. But it is > > only visible when "-consoleLog" is activated. It also seems that it does not > > have a major influence when "-consoleLog" is not set > > What would you expect? > Exactly what I described. I simply forgot to turn it on. That's why I said 'shame on me' ;) > > (seems to be just a print > > out, but I did not find where it is printed), but if it is activated it simply > > floods the lock > > What lock? > Darn. One of my common typos. I meant 'log'. So what I meant was that the log file and/or the console are full of unnecessary stack traces. > > and slows the application. Since the root of the problem > > (calling the file system) is heavily used by GMF I do not think that find can > > get a clean solution in a short time. > > Can't the WorkspaceSynchronizer be deactivated or replaced with a stub? > Don't know. But I do not think so because the getFile() call is used in a static way. The only to fix this out of our scope is that GMF encapsulates all static calls in a way that we can influence the calling, e.g. be something we can change. Or the implementation of getFile() could be changed from outside. Actually the last thing was what I tried be providing a dummy FS. > > That's why I attach the patch which is merly some sort of a hack. But it seems > > to work to solve our problem. > > I don't like it ;-( Me neither. But I think the alternative is worse. > > > Eike, I would like to discuss this solution with you. Especially the influcence > > on our CDO FS. > > There's no current influence but it will prevent us from using the cdo: > protocol at the EFS layer in the future. If we decide later that we want to use "cdo" as filesystem, we could just do it and remove this solution. In this context it is only important that we have a FS registered with the prefix 'cdo'. As far as I could see it the content is irrelevant. >Worse: It's visible outside of CDO and > that's a no go for an internal hack. > Agreed. I would be happier if we'd find a better solution > > Please ping me if you find some time. > > Will do. O.k. I'll wait for you :P This is an issue in EMF Transactions and should be addressed there. |