Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322639

Summary:	'An object may not circularly contain itself' validation problem
Product:	[Modeling] TMF	Reporter:	Ed Willink <ed>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3	CC:	romain.raugi, sebastian.zarnekow, sven.efftinge
Version:	1.0.0	Flags:	sven.efftinge: indigo+
Target Milestone:	M7
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description Ed Willink

2010-08-13 07:09:01 EDT

EObjectValidator.validate_NoCircularContainment sets the ROOT_OBJECT context element on first root encounter allowing the 'An object may not circularly contain itself' message to be generated on a re-encounter.

The default Xtext validation can lead to at least two invocations of EObjectValidator, one imposed by Xtext and one from the user. The second invocation reports circular containment because the first has already set the ROOT_OBJECT context entry.

The user can fix this by:

- arranging for CompositeEValidator.USE_EOBJECT_VALIDATOR to be false by injection; the help contents doesn't indicate how this might be achieved.

- providing a derived CompositeEValidator whose constructor setUseEObjectValidator(false)

Xtext could fix this by:

- resetting ROOT_OBJECT around the Xtext imposed EObjectValidator

- not imposing an EObjectValidator if there is a user EObjectValidator derived class

- providing a useEObjectValidator validator fragment control

- issuing an MWE-time warning if there are two EObjectValidators

Comment 1 Sebastian Zarnekow

2010-08-25 13:21:19 EDT

I prefer both approaches for indigo:

- not imposing an EObjectValidator if there is a user EObjectValidator derived
class

- providing a useEObjectValidator validator fragment control

Comment 2 Ed Willink

2011-01-21 02:56:58 EST

(In reply to comment #0)
> - providing a derived CompositeEValidator whose constructor
> setUseEObjectValidator(false)

In Xtext 2.0M4.5 it is now necessary to do this in extended-editors as well as the extending-editor since the default list of packages for which registration occurs is no longer empty. Both extended and extending editors fight to establish the AbstractInjectableValidator registration for common packages.

AbstractInjectableValidator.registerPackages now prohibits the re-instatement of the old policy since an empty getEPackages return now generates an ISE. This seems unduly nannyish given that the default default is an UOE inviting an 'overwrite' (rather than an 'override') and the generated default is no longer empty. It would be useful to allow an empty list rather than requiring register to be overridden which might acquire other functionality.

Comment 3 Sebastian Zarnekow

2011-04-11 11:35:28 EDT

Since we found a way to register a validator for a concrete syntax rather than an EPackage, I'm inclined to close this as works for me since there is a way to register / unregister additional concrete syntax aware validators for those who already defined EPackage specific validation rules.

If you don't want to use the validator stub that we provide, I'd recommend to remove the respective fragment from the workflow that generates the language infrastructure rather than overwriting register() or getEPackages().

Comment 4 Karsten Thoms

2017-09-19 16:56:47 EDT

Closing all bugs that were set to RESOLVED before Neon.0

Comment 5 Karsten Thoms

2017-09-19 17:08:00 EDT

Closing all bugs that were set to RESOLVED before Neon.0