Skip to main content



      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 09:37 Go to next message
Eclipse UserFriend
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 10:21 Go to previous messageGo to next message
Eclipse UserFriend
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 05:38 Go to previous messageGo to next message
Eclipse UserFriend
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 06:05 Go to previous messageGo to next message
Eclipse UserFriend
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 08:05 Go to previous messageGo to next message
Eclipse UserFriend
[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 10:10 Go to previous messageGo to next message
Eclipse UserFriend
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 04:11 Go to previous message
Eclipse UserFriend
[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 Jul 12 21:46:08 EDT 2025

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

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

Back to the top