Bugzilla – Full Text Bug Listing
| Summary: | Bundles are generated with 'singleton:=true' automatically | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Alex Blewitt <alex.blewitt> |
| Component: | Core | Assignee: | Ed Merks <Ed.Merks> |
| Status: | VERIFIED WORKSFORME | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | herrmama, mikael.barbero, stepper |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Alex Blewitt
The bundles register their EPackage via their plugin.xml. A given EPackage only has a single namespace (eNsURI) so multiple versions of the package are going to collide in the registry. I think they must be singletons therefore, right? So I think the current behavior is correct. It seems an unnecessary restriction in general, but if EMF works in this way then as you say, this is probably an invalid or worksforme request. As Ed mentioned, the default mechansim for contribution of EPackages to the global package registry is based on the Equinox extension registry. And that requires bundles to declare singleton:=true. That said, this can quickly become a severe issue when it comes to model evolution. If an EPackage contains custom EDataTypes with handwritten serialization logic it seems inevitable to have the old and the new code of this model deployed at the same time. Not easily possible with bundles that are marked singleton. I wonder if it would be a good idea to come up with an alternative mechanism for the contribution that does not suffer from this limitation... It's not just contribution that's an issue, it comes down to each instance having to have a different namespace URI in order to coexist in the package registry, i.e., the same issue that CDO handles by arguing that a package can never change, you can only introduce new ones with different namespace. An issue that comes up with non-singletons, which I've actually encounter when DOM wasn't part of the basic JDK, is that downstream clients depending on different bundles that end up pulling in different versions of the same bundle end up with two java.lang.Class instances of some non-singelton class and instances of those aren't compatible. You get a message like a.b.C is not compatible with a.b.C, which makes no sense until you realize there are multiple versions of class C. There is no magic wand that makes all problems like this just go away. Making things non-singletons, just makes a different set of problems crop up. (In reply to comment #5) > It's not just contribution that's an issue, it comes down to each instance > having to have a different namespace URI in order to coexist in the package > registry, i.e., the same issue that CDO handles by arguing that a package can > never change, you can only introduce new ones with different namespace. Absolutely. I didn't mean to contribute two versions of an EPackage to the registry with the same nsURI. Increasing for example a version identifer in the nsURI is definitely required. But with the singleton attribute being in the manifest it's just impossible to deploy the two EPackages at the same time, even though they have different nsURIs. The only way would be to change the bundle's symbolic name for each version. > An issue that comes up with non-singletons, which I've actually encounter when > DOM wasn't part of the basic JDK, is that downstream clients depending on > different bundles that end up pulling in different versions of the same bundle > end up with two java.lang.Class instances of some non-singelton class and > instances of those aren't compatible. You get a message like a.b.C is not > compatible with a.b.C, which makes no sense until you realize there are > multiple versions of class C. The only "client" I see using both EPackage versions at the same time is the actual instance migrator. > There is no magic wand that makes all problems like this just go away. Making > things non-singletons, just makes a different set of problems crop up. I don't have a problem with removing the singleton attribute manually, together with the whole plugin.xml (well, actually I think our users can afford that). It's more that we should provide an alternative mechanism to contribute the Epackage versions to the global EMF registry. That doesn't have to have an impact on the existing contribution mechansim. Clearly a new genmodel switch to choose between the different contribution mechanisms would be appreciated by those users that plan to profit from model evolution support. Suppose you have two instances of model A, A' and A''. Suppose both B and C rely on A. Which version do they end up with? It doesn't matter you say. It must matter somehow, or you'd not want there to be both coexisting. Now suppose you have D that relies on B and C. If B and C didn't pull in the same A, it's just not going to work. If you want them to coexist, you'll have to change the package namespace and the bundle namespace. Then clients can choose which to use, though of course you still have a problem with D. I'm not sure in what way this whole modular versioning story for models should differ from the same situation with OSGi bundles. Bundles have an ID and a version. EPackages have an nsURI that consists of (should consist of) an ID part and a version part. Bundles express their *versioned* dependencies in their manifest.mf and models should also express their dependencies via nsURIs, which are versioned. Did I miss something? I suppose the real problem here is it's all very hypothetical. You're suggesting we invent a replacement mechanism for extension points which obviates the need for singletons. You have to ask why the platform hasn't done that. But this is a special case you'll say. The discussion will then continue... One thing that seems clear is that if one changes the nsURI of a package, downstream clients will find that they have trouble reading older instances once the older nsURI's package can't be located. They're in fact going to require both versions to exists in order to handle serializations that have encoded those nsURIs. That hardly sounds like a bundle that satisfies the same things that are expected of it. Of course that's more hypothetical discussion that will have hypothetical responses. In any case, I don't intend to spend time solving this problem because I'm convinced we'd be trading off one set of problems for a new improved set of problems. So the onus will be on others to come up with a complete design that doesn't have obvious problems. (In reply to comment #9) > I suppose the real problem here is it's all very hypothetical. No, it's real. Or are you suggesting that EMF users do not implement their own custom EDatatType serialization formats? > You're > suggesting we invent a replacement mechanism for extension points which > obviates the need for singletons. No, I'm suggesting that we integrate with existing mechanism in the platform that are way more suitable, e.g. the OSGi service registry, which can perfectly cope with "contributions" from multiple versions of a bundle. IMHO the extension registry has been invented for UI contributions where you certainly don't want multiple versions of, e.g. "Open File" to appear in a menu. Since the its inntroduction the extension registry has been misused in many places. > You have to ask why the platform hasn't done > that. But this is a special case you'll say. The discussion will then > continue... See above. > One thing that seems clear is that if one changes the nsURI of a package, > downstream clients will find that they have trouble reading older instances > once the older nsURI's package can't be located. The EPackages belong to the application (code) and they evolve at the same pace. The problem is just that users do have old data persisted that conforms to old versions of the packages (and the application code). This application code is not expected to deal with the old data. But a migrator has to be run once to transform the old data to make it conform to the new packages. Only this migrator utility (use once for your old data, then throw it away) needs to have access to the old packages *and* the new ones. > They're in fact going to > require both versions to exists in order to handle serializations that have > encoded those nsURIs. That hardly sounds like a bundle that satisfies the same > things that are expected of it. Of course that's more hypothetical discussion > that will have hypothetical responses. not sure I get this. > In any case, I don't intend to spend time solving this problem because I'm > convinced we'd be trading off one set of problems for a new improved set of > problems. So the onus will be on others to come up with a complete design that > doesn't have obvious problems. You might think this all is hypothetical because tools like COPE do already solve all of this. But I talked to Markus to hear how he solved it. He wasn't even aware of the challenge to deserialize data of old custom EDataTypes. Sure, we can wait until he realizes that it's basically not possible without the possibility to deploy both, the old and the new version of the model code. I can assure you that several of my past customers had to apply very annoying processes and techniques to tackle this real problem. I'll be happy to review a complete and concrete solution. My intuition tells me it will have new improved problems different from the old exiting problems, but I'd be happy to be proven wrong. So best others focus on designing a solution, rather than discussing the current problems and suggesting they can be solved, somehow. |