Community
Participate
Working Groups
If I get Part1 injected in Part2 I receive the incorrect Composite: Example: package com.example.e4.rcp.todo.parts; import javax.annotation.PostConstruct; import javax.inject.Inject; import org.eclipse.swt.SWT; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Label; public class TestPart2 { @Inject TodoDeletionPart part; @PostConstruct public void post(Composite parent) { new Label(parent, SWT.NONE).setText("Funny"); new Label(parent, SWT.NONE).setText("Funny"); new Label(parent, SWT.NONE).setText("Funny"); new Label(parent, SWT.NONE).setText("Funny"); new Label(parent, SWT.NONE).setText("Funny"); } } package com.example.e4.rcp.todo.parts; import javax.annotation.PostConstruct; import javax.inject.Inject; import org.eclipse.swt.SWT; import org.eclipse.swt.widgets.Button; import org.eclipse.swt.widgets.Composite; public class TestPart1 { @Inject TestPart2 part; @PostConstruct public void post(Composite parent) { System.out.println("Also got funny stuff"); Button button = new Button(parent, SWT.PUSH); button.setText("hello"); } } As a result the Labels of TestPart2 are also included into TestPart1. I don't think that should happen.
This behaviour is occurring because the TodoDeletionPart has an implicit 0-argument constructor and so the injector is auto-generating an instance as per bug 302533.
But why has it the UI components of the other part on it?
(In reply to comment #2) > But why has it the UI components of the other part on it? Because that's the composite that was available from the context of the TestPart2. The TodoDeletionPart was created and injected with TestPart2's context. Although the intent may seem clear in your code, it would never actually work. The first problem is the injection can't actually be satisfied: context lookups go up in the hierarchy, and parts are always at the leaves (at least, with the current model). Unless, of course, you explicitly placed the object into the context. And even if the context lookup did span the tree of contexts, it's not clear what should happen if there were several instances of the object to choose from. The second problem is that that the TodoDeletionPart is actually the part's contribution object, and not the part. So you wouldn't inject this object anyways. This particular situation might be fixed by Tom's suggestion of a @ElementId: public class TestPart2 { @ElementId("xpath/expression") MPart part; ... public void xxxxxx() { TodoDeletionPart impl = (TodoDeletionPart)part.getObject(); impl.blah(); } } Or you could (should) use the EModelService. I'm marking this as INVALID as the result is a feature, and leave the discussion about the autogen feature to bug 371115.
I agree that this should not work. It was an error done by one of my participants in the training. Currently the DI container does seem to get confused by this @Inject and I think this should be preferened, e.g. by throwing an exception.
Closing again, as the current behavior is correct unless be behavior described in Bug 371115 is changed. This behavior should get documented as its not the expected behavior IMHO by most people. Even if 371115 make it an opt-in, documentation might in all cases be useful for this.
