Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » E4 Tools Internationalization - Use case on OSGi Level
E4 Tools Internationalization - Use case on OSGi Level [message #1067764] Wed, 10 July 2013 13:37 Go to next message
Christoph Keimel is currently offline Christoph Keimel
Messages: 371
Registered: December 2010
Location: Germany
Senior Member
Hi Dirk! Hi Tom!

I am currently testing your new internationalization mechanism from e4 tools by migration a small e4 application. In this project all the messages are externalized like discribed in your blog: All the messages were externalized into one large Messages class, that is used by all other classes of the application.

I changed the Messages class as described and started to refactor all the accesssing classes. This is where I am running into a problem: Some of the classes are OSGi service implementations, so they actually aren't hooked into E4 DI.

Is the Translation available as an OSGi service, which I could use as a dependency in DS?
Is there a way for an OSGi service implementation to know, when the translation service is available in the context?

Greetings
Christoph

Re: E4 Tools Internationalization - Use case on OSGi Level [message #1067775 is a reply to message #1067764] Wed, 10 July 2013 14:21 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
The service createing the instance of the Message-Class is available in
OSGi as org.eclipse.e4.tools.services.IMessageFactoryService. The
DI-Supplier (TranslationObjectSupplier) delegates to this service.

Tom

On 10.07.13 15:37, Christoph Keimel wrote:
> Hi Dirk! Hi Tom!
>
> I am currently testing your new internationalization mechanism from e4
> tools by migration a small e4 application. In this project all the
> messages are externalized like
> http://blog.vogella.com/2013/06/25/eclipse-internationalization-part-34-migration-by-dirk-fauth/:
> All the messages were externalized into one large Messages class, that
> is used by all other classes of the application.
>
> I changed the Messages class as described and started to refactor all
> the accesssing classes. This is where I am running into a problem: Some
> of the classes are OSGi service implementations, so they actually aren't
> hooked into E4 DI.
>
> Is the Translation available as an OSGi service, which I could use as a
> dependency in DS?
> Is there a way for an OSGi service implementation to know, when the
> translation service is available in the context?
>
> Greetings
> Christoph
>
>
Re: E4 Tools Internationalization - Use case on OSGi Level [message #1070130 is a reply to message #1067775] Wed, 17 July 2013 09:38 Go to previous messageGo to next message
Christoph Keimel is currently offline Christoph Keimel
Messages: 371
Registered: December 2010
Location: Germany
Senior Member
Hi Tom,

thanks for the feedback. I did a small test with a TestService that is injected into the LifeCycleHandler of an E4AP application. That works nicely Smile. The IMessageFactoryService gets bound to the TestService by DS and I can retrieve my Messages instance from it.

When I try to use this in the context of our "real" application I run into a strange NPE.
java.lang.NullPointerException
	at org.eclipse.e4.tools.services.impl.TranslationObjectSupplier.getMessageInstance(TranslationObjectSupplier.java:125)
	at org.eclipse.e4.tools.services.impl.TranslationObjectSupplier.get(TranslationObjectSupplier.java:77)
	at org.eclipse.e4.core.internal.di.InjectorImpl.resolveArgs(InjectorImpl.java:455)
	at org.eclipse.e4.core.internal.di.InjectorImpl.resolveRequestorArgs(InjectorImpl.java:393)
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:108)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:333)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:254)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:102)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:71)
	at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:53)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:230)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.start(E4Application.java:144)
	at de.emsw.gosa.e4.application.AbstractE4Application.startE4Application(AbstractE4Application.java:226)
	at de.emsw.gosa.e4.application.AbstractE4Application.start(AbstractE4Application.java:171)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1426)


Debugging into this I noticed that the problem is that InjectorImpl.setDefaultSupplier has not been set, probably because of a race condition. This seems fairly easy to handle in InjectorImpl, so I opened a Bug for this:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=413149

Or am I looking into the wrong direction?

Regards
Christoph
Re: E4 Tools Internationalization - Use case on OSGi Level [message #1070143 is a reply to message #1070130] Wed, 17 July 2013 10:05 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
Hm,

I've never see this problem. In which class do you expect the Message
instance to be injected? I don't really understand how the
primarySupplier can be NULL.

Tom

On 17.07.13 11:38, Christoph Keimel wrote:
> Hi Tom,
>
> thanks for the feedback. I did a small test with a TestService that is
> injected into the LifeCycleHandler of an E4AP application. That works
> nicely :). The IMessageFactoryService gets bound to the TestService by
> DS and I can retrieve my Messages instance from it.
>
> When I try to use this in the context of our "real" application I run
> into a strange NPE.
> java.lang.NullPointerException
> at
> org.eclipse.e4.tools.services.impl.TranslationObjectSupplier.getMessageInstance(TranslationObjectSupplier.java:125)
>
> at
> org.eclipse.e4.tools.services.impl.TranslationObjectSupplier.get(TranslationObjectSupplier.java:77)
>
> at
> org.eclipse.e4.core.internal.di.InjectorImpl.resolveArgs(InjectorImpl.java:455)
>
> at
> org.eclipse.e4.core.internal.di.InjectorImpl.resolveRequestorArgs(InjectorImpl.java:393)
>
> at
> org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:108)
> at
> org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:333)
>
> at
> org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:254)
> at
> org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
>
> at
> org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:102)
>
> at
> org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:71)
>
> at
> org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:53)
>
> at
> org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:230)
>
> at
> org.eclipse.e4.ui.internal.workbench.swt.E4Application.start(E4Application.java:144)
>
> at
> de.emsw.gosa.e4.application.AbstractE4Application.startE4Application(AbstractE4Application.java:226)
>
> at
> de.emsw.gosa.e4.application.AbstractE4Application.start(AbstractE4Application.java:171)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
>
> Debugging into this I noticed that the problem is that
> InjectorImpl.setDefaultSupplier has not been set, probably because of a
> race condition. This seems fairly easy to handle in InjectorImpl, so I
> opened a Bug for this:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=413149
>
> Or am I looking into the wrong direction?
>
> Regards
> Christoph
Re: E4 Tools Internationalization - Use case on OSGi Level [message #1070179 is a reply to message #1070143] Wed, 17 July 2013 12:05 Go to previous messageGo to next message
Christoph Keimel is currently offline Christoph Keimel
Messages: 371
Registered: December 2010
Location: Germany
Senior Member
[quote title=Thomas Schindl wrote on Wed, 17 July 2013 12:05]Hm,

> I've never see this problem. In which class do you expect the Message
> instance to be injected? I don't really understand how the
> primarySupplier can be NULL.

I've been doing some more research: The Message instance is to be injected into the LifeCycleManager. The reason why InjectorImpl.defaultSupplier is still NULL is because the defaultSupplier is set to be the application context after it is created. When the LifeCycleManger is created this is still NULL.

This is easy to fix though, because InjectorImpl.findExtendedSupplier gets another PrimaryObjectSupplier passed as a parameter objectSupplier. This is not NULL, so a possible solution is to use this instead of the defaultSupplier.

Please have a look a my patch with Bug 413149.

One could ask why the parameter objectSupplier is currently not used at all ...
Re: E4 Tools Internationalization - Use case on OSGi Level [message #1070233 is a reply to message #1070179] Wed, 17 July 2013 14:10 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
Would it be better to reorder the calls so that the defaultSupplier is
set a the very beginning of the bootstrapping?

Tom

On 17.07.13 14:05, Christoph Keimel wrote:
> [quote title=Thomas Schindl wrote on Wed, 17 July 2013 12:05]Hm,
>
>> I've never see this problem. In which class do you expect the Message
>> instance to be injected? I don't really understand how the
>> primarySupplier can be NULL.
>
> I've been doing some more research: The Message instance is to be
> injected into the LifeCycleManager. The reason why
> InjectorImpl.defaultSupplier is still NULL is because the
> defaultSupplier is set to be the application context after it is
> created. When the LifeCycleManger is created this is still NULL.
>
> This is easy to fix though, because InjectorImpl.findExtendedSupplier
> gets another PrimaryObjectSupplier passed as a parameter objectSupplier.
> This is not NULL, so a possible solution is to use this instead of the
> defaultSupplier.
>
> Please have a look a my patch with
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=413149.
>
> One could ask why the parameter objectSupplier is currently not used at
> all ...
Re: E4 Tools Internationalization - Use case on OSGi Level [message #1070563 is a reply to message #1070233] Thu, 18 July 2013 08:11 Go to previous message
Christoph Keimel is currently offline Christoph Keimel
Messages: 371
Registered: December 2010
Location: Germany
Senior Member
[quote title=Thomas Schindl wrote on Wed, 17 July 2013 16:10]
> Would it be better to reorder the calls so that the defaultSupplier is
> set a the very beginning of the bootstrapping?

That works as well. I don't know what is better. Maybe even both patches are worth applying ...

I added a second patch to Bug 413149.

Previous Topic:Add Composite On Coolbar
Next Topic:MultiPageEditorPart on Eclipse 4
Goto Forum:
  


Current Time: Sat Oct 25 18:59:03 GMT 2014

Powered by FUDForum. Page generated in 0.03296 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software