Community
Participate
Working Groups
Hi, I think it should be very cool if CLR Class from XWT file (x:Class) could be declared with Spring files with bean. If CLR Class is managed with Spring, we could use the Spring power like DI for instance get an OSGI services with Spring DM. Instead of setting the class into the XWT file we could set an id bean from Spring file. On other words, instead writing that : ---------------------- <Composite xmlns="http://www.eclipse.org/xwt/presentation" xmlns:x="http://www.eclipse.org/xwt" x:Class="org.eclipse.e4.xwt.tests.xaml.Name"> ---------------------- We could write that : ---------------------- <Composite xmlns="http://www.eclipse.org/xwt/presentation" xmlns:spring="http://www.eclipse.org/xwt/spring" spring:bean="NameID"> ---------------------- and declare into Spring file the bean CLR Class : ---------------------- <bean id="NameID" class="org.eclipse.e4.xwt.tests.xaml.Name"> </bean> ---------------------- With this feature we could use Spring DI with or without OSGi. For instance the classe Name could use an OSGi service : ---------------------- public class Name { private INameService nameService; public void setNameService(INameService nameService) { this.nameService = nameService; } public void selectedButton() { // Use the service getted from DI Spring nameService.getName(); } } ---------------------- and the Spring XML file looks like this : ---------------------- <bean id="nameService" class"org.eclipse.e4.service.NameService" > </bean> <bean id="NameID" class="org.eclipse.e4.xwt.tests.xaml.Name"> <property name="nameService" ref="nameService" /> </bean> ---------------------- It was an example without OSGI, whith OSGi (by using Spring DM), we could write: ---------------------- <osgi:reference id="nameService" interface"org.eclipse.e4.service.INameService" /> <bean id="NameID" class="org.eclipse.e4.xwt.tests.xaml.Name"> <property name="nameService" ref="nameService" /> </bean> ---------------------- To do that XWT should provide a CLRFactory that we can implement as we wish (in this case with Spring ApplicationContext). If you like this idea, I could help you to implement that. Regards Angelo
I think there is a common requirement with the comment @2 of bug 2667722, about the customization of event handler
(In reply to comment #0) > ... > To do that XWT should provide a CLRFactory that we can implement as we wish (in > this case with Spring ApplicationContext). If you like this idea, I could help > you to implement that. Yes, please start it. I'll assist you if you need any help. And I'll focus on a generic CLR customizable solution.
(In reply to comment #2) > (In reply to comment #0) > > ... > > To do that XWT should provide a CLRFactory that we can implement as we wish (in > > this case with Spring ApplicationContext). If you like this idea, I could help > > you to implement that. > Yes, please start it. I'll assist you if you need any help. And I'll focus on a > generic CLR customizable solution. Yves, is it possible that you develop the concept of ICLRFactory interface into XWT (and implement this factory with CLRClassFactory wich use x:Class) or give me some help (which class must I change?) because I don't know the XWT code. Thanks. Angelo
(In reply to comment #3) > Yves, is it possible that you develop the concept of ICLRFactory interface into > XWT (and implement this factory with CLRClassFactory wich use x:Class) or give > me some help (which class must I change?) because I don't know the XWT code. > We need to understand first the requirement. At current stage, XWT use the x:Class to find the Java Class and create an instance (if it is not the host widget) to handle the events. And then we use the Java reflection to find the event handler. Probably, we can define a generic solution to enable the customization. The solution could be an extension of the current solution by adding the property initialization: x:Class="<classname> propertyName=propertyValue" where classname could a normal class or a type of ICLRFactory. The ICLRFactory definition should be: interface ICLRFactory { Object createCR(); Method findEventHandle(String handleName); } Do you think it meets the requirement with Spring?
> We need to understand first the requirement. At current stage, XWT use the > x:Class to find the Java Class and create an instance (if it is not the host > widget) to handle the events. And then we use the Java reflection to find the > event handler. > > Probably, we can define a generic solution to enable the customization. The > solution could be an extension of the current solution by adding the property > initialization: > > x:Class="<classname> propertyName=propertyValue" > > where classname could a normal class or a type of ICLRFactory. The ICLRFactory > definition should be: > > interface ICLRFactory { > Object createCR(); > Method findEventHandle(String handleName); > } > > Do you think it meets the requirement with Spring? Yves I'm creating a very basic Eclipse Projectwith ICLRFactory with Spring and Class implementation. I think it should be easier for us to discuss about this feature and for me I could validate if Spring implementation will able to works. For the moment I have this interface : -------------- public interface ICLRFactory { Object createCLR(String xClass); } -------------- As you can see there is xClass parameter which is the content of x:class attribute. So my idea is to write with class : x:Class="org.eclipse.e4.xwt.tests.xaml.Name" and this call ClassCLRFactory instance which is a singleton. With Spring we could write : x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory:myBeanId" MySpringCLRFactory is the Spring CLR Factory implementation which use a SPring XML. myBeanId is the id of teh Spring bean. MySpringCLRFactory can be too a singleton. With the xClass parameter, each ICLRFactory can be a singleton that it can be cached by XWT. What do you think about this idea? I will send to this bug the Eclipse Project (soon finished), but I don't understand the method ? -------------- Method findEventHandle(String handleName); -------------- I don't retrieve 2667722 bug? Could you put the link to this bug please? I suppose this method retrieve the method to call for an event. Today thoses handler methods are stored into CLR class. Is that it? If it's so, why delegate this method for an another Class? I'm waiting for your answer and after I will send the Eclipse project.
(In reply to comment #5) > With Spring we could write : > > x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory:myBeanId" > Sorry, you cannot use this syntax. The separator ":" has another mean. The prefix before ":" is considered as the prefix of namespace. This is why I proposed: x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory bean=myBeanId" > MySpringCLRFactory is the Spring CLR Factory implementation which use a SPring > XML. myBeanId is the id of teh Spring bean. MySpringCLRFactory can be too a > singleton. for each x:Class specification, we should create an instance., which can be a factory or CLR instance. If it is a factory, it is its responsibility to create an instacneof of CLR or share the same using the solo instance. > > With the xClass parameter, each ICLRFactory can be a singleton that it can be > cached by XWT. What do you think about this idea? > > I will send to this bug the Eclipse Project (soon finished), but I don't > understand the method ? > > -------------- > Method findEventHandle(String handleName); > -------------- This method is used to find the event handling method. Without this method, we need to use reflection. I'm not sure it is a good solution. Maybe we need to introduce a new type interface EventHanlder { void invoke(Object sender, Event event); } > > I don't retrieve 2667722 bug? Could you put the link to this bug please? It is in fact the Bug 266772 https://bugs.eclipse.org/bugs/show_bug.cgi?id=266772
(In reply to comment #6) > (In reply to comment #5) > This method is used to find the event handling method. Without this method, we > need to use reflection. I'm not sure it is a good solution. Maybe we need to > introduce a new type > interface EventHanlder { > void invoke(Object sender, Event event); > } > The ICLRFactory should be: interface ICLRFactory { Object createCR(); EventHanlder findEventHandle(Object clr, String handleName); }
(In reply to comment #6) > (In reply to comment #5) > > With Spring we could write : > > > > x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory:myBeanId" > > > Sorry, you cannot use this syntax. The separator ":" has another mean. The > prefix before ":" is considered as the prefix of namespace. This is why I > proposed: > > x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory bean=myBeanId" Ok I understand the problem. What do you think to use ';' character instead of ' '. It looks like OSGI MANIFEST.MF syntax.Ex : Require-Bundle: org.eclipse.e4.xwt;bundle-version="0.9.1" So we could write : x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory;bean=myBeanId" If we need another parameters we coudl write : x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory;bean=myBeanId;anotherparam=value" > for each x:Class specification, we should create an instance., which can be a > factory or CLR instance. > If it is a factory, it is its responsibility to create an instacneof of CLR or > share the same using the solo instance. IHMO I think it should better that factory is singleton. I understand that CLR instance must be an instance and not a singleton. I will send you soon my work. The idea is that I have CLRFactoryManager which create CLR instance ONLY with ICLRFactory. If I have xClass without parameters (ex : x:Class="org.eclipse.e4.xwt.tests.xaml.Name"), I'm using ClassCLRFactory singleton. After I call ClassCLRFactory#createCLR("org.eclipse.e4.xwt.tests.xaml.Name"). If I have parameters (ex : x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory;bean=myBeanId") I get org.eclipse.e4.xwt.test.clr.MySpringCLRFactory and I search if this factory is not cached, if its not cached I instantiate it and cache it. After I call MySpringCLRFactory#createCLR("myBeanId") which it use Spring XML file. MySpringCLRFactory is a singleton and create several instance of CLR by using Spring XML file. So the MySpringCLRFactory must load ONCE time the Spring XML file and not each time that a CLR class must be created. Do you understand why I need to have a singlton for ICLRFactory? > > > > > With the xClass parameter, each ICLRFactory can be a singleton that it can be > > cached by XWT. What do you think about this idea? > > > > I will send to this bug the Eclipse Project (soon finished), but I don't > > understand the method ? > > > > -------------- > > Method findEventHandle(String handleName); > > -------------- > > This method is used to find the event handling method. Without this method, we > need to use reflection. I'm not sure it is a good solution. Maybe we need to > introduce a new type > interface EventHanlder { > void invoke(Object sender, Event event); > } > > > > > > I don't retrieve 2667722 bug? Could you put the link to this bug please? > It is in fact the Bug 266772 > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=266772 Ok Thanks, I will see it.
Created attachment 174862 [details] ICLRFactory Eclipse Project api+sample with Spring and Class#formName ICLRFactory Eclipse Project api+sample with Spring and Class#formName
(In reply to comment #8) > (In reply to comment #6) > > Ok I understand the problem. What do you think to use ';' character instead of > ' '. It looks like OSGI MANIFEST.MF syntax.Ex : > > Require-Bundle: org.eclipse.e4.xwt;bundle-version="0.9.1" So we could write : > > x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory;bean=myBeanId" I think we should keep consistence with others like binding. x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory bean=myBeanId,anotherparam=value" > > > > for each x:Class specification, we should create an instance., which can be a > > factory or CLR instance. > > If it is a factory, it is its responsibility to create an instacneof of CLR or > > share the same using the solo instance. > > IHMO I think it should better that factory is singleton. I understand that CLR > instance must be an instance and not a singleton. I will send you soon my work. > The idea is that I have CLRFactoryManager which create CLR instance ONLY with > ICLRFactory. If I have xClass without parameters (ex : > x:Class="org.eclipse.e4.xwt.tests.xaml.Name"), I'm using ClassCLRFactory > singleton. After I call > ClassCLRFactory#createCLR("org.eclipse.e4.xwt.tests.xaml.Name"). > > If I have parameters (ex : > x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory;bean=myBeanId") I get > org.eclipse.e4.xwt.test.clr.MySpringCLRFactory and I search if this factory is > not cached, if its not cached I instantiate it and cache it. > > After I call MySpringCLRFactory#createCLR("myBeanId") which it use Spring XML > file. > > MySpringCLRFactory is a singleton and create several instance of CLR by using > Spring XML file. So the MySpringCLRFactory must load ONCE time the Spring XML > file and not each time that a CLR class must be created. > > Do you understand why I need to have a singlton for ICLRFactory? I understood. But I don't like to change the semantic of x:Class. I think you can load ONCE Spring XML and share them for all instances of MySpringCLRFactory.
(In reply to comment #10) > (In reply to comment #8) > > (In reply to comment #6) > > > > Ok I understand the problem. What do you think to use ';' character instead of > > ' '. It looks like OSGI MANIFEST.MF syntax.Ex : > > > > Require-Bundle: org.eclipse.e4.xwt;bundle-version="0.9.1" So we could write : > > > > x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory;bean=myBeanId" > > I think we should keep consistence with others like binding. > x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory > bean=myBeanId,anotherparam=value" > > > > > > > > for each x:Class specification, we should create an instance., which can be a > > > factory or CLR instance. > > > If it is a factory, it is its responsibility to create an instacneof of CLR or > > > share the same using the solo instance. > > > > IHMO I think it should better that factory is singleton. I understand that CLR > > instance must be an instance and not a singleton. I will send you soon my work. > > The idea is that I have CLRFactoryManager which create CLR instance ONLY with > > ICLRFactory. If I have xClass without parameters (ex : > > x:Class="org.eclipse.e4.xwt.tests.xaml.Name"), I'm using ClassCLRFactory > > singleton. After I call > > ClassCLRFactory#createCLR("org.eclipse.e4.xwt.tests.xaml.Name"). > > > > If I have parameters (ex : > > x:Class="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory;bean=myBeanId") I get > > org.eclipse.e4.xwt.test.clr.MySpringCLRFactory and I search if this factory is > > not cached, if its not cached I instantiate it and cache it. > > > > After I call MySpringCLRFactory#createCLR("myBeanId") which it use Spring XML > > file. > > > > MySpringCLRFactory is a singleton and create several instance of CLR by using > > Spring XML file. So the MySpringCLRFactory must load ONCE time the Spring XML > > file and not each time that a CLR class must be created. > > > > Do you understand why I need to have a singlton for ICLRFactory? > > I understood. But I don't like to change the semantic of x:Class. I think you > can load ONCE Spring XML and share them for all instances of > MySpringCLRFactory. Ok, please see my work. I find it's very shame to instanciate an CLR Factory and the CLR Class each time although CLR Factory coule be singleton but I understand your opinion.
Hi Yves, I have continued to develop the CLR concept with Spring DM (OSGi context) and I need : * the bean ID of an Spring XML file (like Spring without OSGi). * bundle name (symbolicName) which contains XML Spring file. I need only the bundle symbolicName and Spring DM is enable to retrieve the bean. So today the only solution I have founded is to write : ---------------- x:Class="org.eclipse.e4.xwt.spring.SpringCLRFactory bean=MyCLR, bundle=org.eclipse.e4.xwt.spring.test.osgi" ---------------- So bundle parameter is used to fill the bundle symbolicName. It works but I found it's not very elegant : 1. symbolicName refactoring will cause problem with CLR bundle declaration. 2. Set the bundle parameter for each XWT is very awfull. To resolve that, I think it should be cool if XWT could add automaticly the bundle parameter where *.xwt file belong to. Do you think it's possible to do that? Angelo
Yves, I have an another idea. I think its should be cool if we could write x:Class with ONLY Spring bean id, like this : ------------- x:Class="MyBeanId" ------------- where MyBeanId is Spring bean id to avoid writing this : ------------- x:Class="org.eclipse.e4.xwt.spring.SpringCLRFactory bean=MyBeanId" ------------- The idea is to configure XWT which works ICLRFactory. By default ICLRFactory ClassCLRFactory singleton which instantiate the x:Class. But we could set the SpringCLRFactory to XWT global configuration with this new method : ------------- XWT#setCLRFactory(ICLRFactory factory) ------------- like this : ------------- XWT.setCLRFactory(SpringCLRFactory.INSTANCE); ------------- I think this idea could simplify really the x:Class content and avoid problem when SpringCLRFactory is refactored with new name. But to do that ICLRFactory must be a singleton. What do you think about this idea?
(In reply to comment #13) > I have an another idea. I think its should be cool if we could write x:Class > with ONLY Spring bean id, like this : > > ------------- > x:Class="MyBeanId" > ------------- > > where MyBeanId is Spring bean id to avoid writing this : > > ------------- > x:Class="org.eclipse.e4.xwt.spring.SpringCLRFactory > bean=MyBeanId" > ------------- I'm sorry. I think this changes also the semantic of x:Class. The most important of XML in XWT is to keep all syntax consistent and model based. The simple code is in second. And I'd like to have a generic solution.
(In reply to comment #14) > (In reply to comment #13) > > I have an another idea. I think its should be cool if we could write x:Class > > with ONLY Spring bean id, like this : > > > > ------------- > > x:Class="MyBeanId" > > ------------- > > > > where MyBeanId is Spring bean id to avoid writing this : > > > > ------------- > > x:Class="org.eclipse.e4.xwt.spring.SpringCLRFactory > > bean=MyBeanId" > > ------------- > > I'm sorry. I think this changes also the semantic of x:Class. The most > important of XML in XWT is to keep all syntax consistent and model based. The > simple code is in second. And I'd like to have a generic solution. I find it's very shame that XAML doesn't specify ICLRFactory concept -(. x:Class is the CLR class linked to the xwt file. It can be created with Class#forName, Spring container... it's our ICLRFactory concept. Into XAML it's possible to link some information (assembly, crl-namespace...) with the x:Class by using xmlns:custom. I have seen that at http://msdn.microsoft.com/en-us/library/ms747086.aspx#Mapping_To_Custom_Classes_and_Assemblies So you can write : -------------- x:Class="WPFApplication1.MainPage" xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary" -------------- I tell me, that we could do the same thing and use xmlns:custom attribute to specify our ICLRFactory like this : -------------- x:Class="myBeanId" xmlns:custom="clr-factory:org.eclipse.e4.xwt.spring.SpringCLRFactory" -------------- clr-factory give the information of the ICLRFactory to use to interpret the x:Class content. It's an information linked to x:Class like an assembly information. I find xmlns:custom is more clean than x:Class because with this solution x:Class follow XAML specification (it contains only one information). Into OSGi context we must add bundle symbolicName (as I have explained you), so we could write : -------------- x:Class="myBeanId" xmlns:custom="clr-factory:org.eclipse.e4.xwt.spring.SpringCLRFactory;bundle=org.eclipse.e4.xwt.spring.test.osgi" -------------- What do you think about this idea?
(In reply to comment #15) > (In reply to comment #14) > > I find it's very shame that XAML doesn't specify ICLRFactory concept -(. > > x:Class is the CLR class linked to the xwt file. It can be created with > Class#forName, Spring container... it's our ICLRFactory concept. > > Into XAML it's possible to link some information (assembly, crl-namespace...) > with the x:Class by using xmlns:custom. I have seen that at > http://msdn.microsoft.com/en-us/library/ms747086.aspx#Mapping_To_Custom_Classes_and_Assemblies > > So you can write : > > -------------- > x:Class="WPFApplication1.MainPage" > xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary" > -------------- > > I tell me, that we could do the same thing and use xmlns:custom attribute to > specify our ICLRFactory like this : > > -------------- > x:Class="myBeanId" > xmlns:custom="clr-factory:org.eclipse.e4.xwt.spring.SpringCLRFactory" > -------------- > > clr-factory give the information of the ICLRFactory to use to interpret the > x:Class content. It's an information linked to x:Class like an assembly > information. > > I find xmlns:custom is more clean than x:Class because with this solution > x:Class follow XAML specification (it contains only one information). > > Into OSGi context we must add bundle symbolicName (as I have explained you), so > we could write : > > -------------- > x:Class="myBeanId" > xmlns:custom="clr-factory:org.eclipse.e4.xwt.spring.SpringCLRFactory;bundle=org.eclipse.e4.xwt.spring.test.osgi" > -------------- > > What do you think about this idea? There are two points bother me: 1. There is no relation between x:Class and xmlns:custom. 2. You map a Class to a prefix of namespace. They are not corresponding. I prefer extending directly x:Class.
> > What do you think about this idea? > There are two points bother me: > 1. There is no relation between x:Class and xmlns:custom. > 2. You map a Class to a prefix of namespace. They are not corresponding. > > I prefer extending directly x:Class. Ok Yves, it was just an idea to try to find a solution to manage ICLRFactory singleton. I'm sorry to insist with ICLRFactory singleton, but if you 'extend' the x:Class to manage parameters (bean=...), why not extending that to manage ICLRFactory singleton? There is no sense that ICLRFactory is an instance. If we have no singleton, your idea is to have this method : -------------------- Object createCLR(); -------------------- But how can I get bean parameters from the x:Class content? In my case I have : -------------------- Object createCLR(String xClass); -------------------- And I can get the parameters (and manage singleton). Implement ICLRFactory as you wish, tell me, and I will adapt my work with yours.
Angelo, please give me some time. I'll study all aspects including the JS support. And then we can make a good decision.
(In reply to comment #18) > Angelo, please give me some time. I'll study all aspects including the JS > support. And then we can make a good decision. No problem Yves! Tell me as soon as you will have time to manage this feature and I will help you to implement ICLRFactory with Spring and Spring DM.
Created attachment 175175 [details] patch for the openness event handling
I have investigated this issue and developed an openness solution (see the attached patch) to handle all kinds of events. I'm aware it doesn't meet your requirement directly. Particuliarly, you cannot use the Factory singleton directly. But I think it is possible to implement a solution. In this patch, I have added two interfaces: interface IEventInvoker { void invoke(Object sender, Event event); } public interface IEventHandler { IEventInvoker getEventInvoker(Object sender, Class<?> elementType, Class<?> eventType); } The interface IEventHandler can be used for each class which intents to manage the event handling. If a CLR implements IEventHandler, it is responsible to handle all events via an instance of IEventInvoker. The later should handle the event by implementing the method invoke(Object sender, Event event). Next step, we need to investigate the integration with Spring over this solution. By now, I don't recommand to change the concept and syntax of x:Class. The code is already very complicate.
(In reply to comment #21) > I have investigated this issue and developed an openness solution (see the > attached patch) to handle all kinds of events. I'm aware it doesn't meet your > requirement directly. Particuliarly, you cannot use the Factory singleton > directly. But I think it is possible to implement a solution. > > In this patch, I have added two interfaces: > > interface IEventInvoker { > void invoke(Object sender, Event event); > } > > public interface IEventHandler { > IEventInvoker getEventInvoker(Object sender, Class<?> elementType, > Class<?> eventType); > } > > The interface IEventHandler can be used for each class which intents to manage > the event handling. If a CLR implements IEventHandler, it is responsible to > handle all events via an instance of IEventInvoker. The later should handle the > event by implementing the method invoke(Object sender, Event event). > > Next step, we need to investigate the integration with Spring over this > solution. By now, I don't recommand to change the concept and syntax of > x:Class. The code is already very complicate. Ok Yves, I'm waiting that you introduce ICLRFactory to help you for XWT-Spring support. Angelo
Finally, I think we can provide a new extension of XML markup, like x:ClassFactory. The XML specification could be: x:ClassFactory="<Factory calss name> <property1>=<value1>, <property2>=<value2>, ..." In case of Spring integration, it should be: <Composite xmlns="http://www.eclipse.org/xwt/presentation" xmlns:x="http://www.eclipse.org/xwt" x:ClassFactory="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory bean=NameID"> The x:Class has precedant than x:ClassFactory. What do you think?
(In reply to comment #23) > Finally, I think we can provide a new extension of XML markup, like > x:ClassFactory. The XML specification could be: > > x:ClassFactory="<Factory calss name> <property1>=<value1>, > <property2>=<value2>, ..." > > In case of Spring integration, it should be: > <Composite xmlns="http://www.eclipse.org/xwt/presentation" > xmlns:x="http://www.eclipse.org/xwt" > x:ClassFactory="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory > bean=NameID"> > > The x:Class has precedant than x:ClassFactory. > > What do you think? I think it should be very fantastic! ClassFactory can be a singleton? Do you think it's possible to have XWT#setClassFactory(IClassFactory factory) to avoid setting the factory into each XWT file (global configuration)?
(In reply to comment #24) > (In reply to comment #23) > > Finally, I think we can provide a new extension of XML markup, like > > x:ClassFactory. The XML specification could be: > > > > x:ClassFactory="<Factory calss name> <property1>=<value1>, > > <property2>=<value2>, ..." > > > > In case of Spring integration, it should be: > > <Composite xmlns="http://www.eclipse.org/xwt/presentation" > > xmlns:x="http://www.eclipse.org/xwt" > > x:ClassFactory="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory > > bean=NameID"> > > > > The x:Class has precedant than x:ClassFactory. > > > > What do you think? > I think it should be very fantastic! ClassFactory can be a singleton? If it is a singleton, we need to extend the syntax to specify an instance of ICLRFactory such as: x:ClassFactory="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory.INSTANCE NameID"> We can support both. > Do you think it's possible to have XWT#setClassFactory(IClassFactory factory) to avoid > setting the factory into each XWT file (global configuration)? yes. In fact, I have a small modification. It could be better to have one single value: x:ClassFactory="<Factory calss name> <value>" It is the ICLRFactory's responsability to parse the value.
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #23) > > > Finally, I think we can provide a new extension of XML markup, like > > > x:ClassFactory. The XML specification could be: > > > > > > x:ClassFactory="<Factory calss name> <property1>=<value1>, > > > <property2>=<value2>, ..." > > > > > > In case of Spring integration, it should be: > > > <Composite xmlns="http://www.eclipse.org/xwt/presentation" > > > xmlns:x="http://www.eclipse.org/xwt" > > > x:ClassFactory="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory > > > bean=NameID"> > > > > > > The x:Class has precedant than x:ClassFactory. > > > > > > What do you think? > > I think it should be very fantastic! ClassFactory can be a singleton? > > If it is a singleton, we need to extend the syntax to specify an instance of > ICLRFactory such as: > > x:ClassFactory="org.eclipse.e4.xwt.test.clr.MySpringCLRFactory.INSTANCE > NameID"> > > We can support both. > > > Do you think it's possible to have XWT#setClassFactory(IClassFactory factory) to avoid > > setting the factory into each XWT file (global configuration)? > > yes. > > In fact, I have a small modification. It could be better to have one single > value: > x:ClassFactory="<Factory calss name> <value>" > > It is the ICLRFactory's responsability to parse the value. Great! I think XWT should provide AbstractCLRFactory to parse the x:ClassFactory. I had done that into my patch. Ok I'm waiting your patch and I will update my work to adapt it with your work.
(In reply to comment #26) > Great! I think XWT should provide AbstractCLRFactory to parse the > x:ClassFactory. I had done that into my patch. I know. But I don't think it is necessary since it doesn't provide any useful service.
There is an imcompatibility between ICLRFactory and XWT#setClassFactory(IClassFactory factory). The method createCLR(String) requires a String value. XWTLoader doesn't know it. So I think we can use the option CLASS_PROPERTY to call XWT.load()/open instead.
(In reply to comment #28) > There is an imcompatibility between ICLRFactory and > XWT#setClassFactory(IClassFactory factory). The method createCLR(String) > requires a String value. XWTLoader doesn't know it. So I think we can use the > option CLASS_PROPERTY to call XWT.load()/open instead. To keep the consistance with the method getCLR(), the new methods are setCLRFactory() and getCLRFactory() instead of setClassFactory(ICLRFactory factory) and getClassFactory() When the Factory is provided by the global environment or loading option, XWTLoader call createCLR() with value null.
I have committed the implementation. There are some testcases, which may be useful for you. Please check it.
(In reply to comment #30) > I have committed the implementation. There are some testcases, which may be > useful for you. > > Please check it. Hi Yves, Thanks for your commit. I'm working on this XWT Spring support. I have started to create new bundle org.eclipse.e4.xwt.spring which provides support for Spring. Is it OK with this bundle name? This bundle provides : 1. AbstractSpringCLRFactory wich use Spring container ApplicationContext. It has the abstract method : ApplicationContext getApplicationContext(String properties, Map<String, String> propertiesMap); Where properties is the arg value of createCLR and propertiesMap the map tokenized. When you wish use XWT without OSGi you must implements this classe to return the Spring ApplicationContext. Here a sample of XWT with Spring (without OSGi) : <Composite xmlns="http://www.eclipse.org/xwt/presentation" xmlns:x="http://www.eclipse.org/xwt" x:ClassFactory="org.eclipse.e4.xwt.spring.SpringCLRFactory bean=myCLR"> As you can see there is bean=myCLR. You suggested me to have only "myCLR" (without bean name), but into OSGi context I need bundle parameter (please see next section) 2. SpringCLRFactory extends AbstractSpringCLRFactory and works with OSGi context. It use an OSGi ServiceTracker to retrieve ApplicationContext into an OSGi Bundle. So you must fill the bundle into XWT file : <Composite xmlns="http://www.eclipse.org/xwt/presentation" xmlns:x="http://www.eclipse.org/xwt" x:ClassFactory="org.eclipse.e4.xwt.spring.SpringCLRFactory bean=myCLR,bundle=org.eclipse.e4.xwt.spring.tests.osgi"> It start to works BUT I had to modify XWT bundle org.eclipse.e4.xwt : 1. Comment line 378 of the ResourceLoader.java : if (!options.containsKey(IXWTLoader.CLASS_FACTORY_PROPERTY)) { //options.put(IXWTLoader.CLASS_FACTORY_PROPERTY, loader.getCLRFactory()); } Otherwise I have the following error : ------------- java.lang.UnsupportedOperationException at java.util.AbstractMap.put(Unknown Source) at org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:378) ---- loader.getCLRFactory() return null, I don't know why? With your sampel I have the same problem. I had to comments this line to launch your sample. 2. Modify MANIFEST.MF by adding DynamicImport-Package: * It's the solution I have founded to load org.eclipse.e4.xwt.spring.SpringCLRFactory class into OSGi context. I don"t know how I could resolve the ClassLoader of my SpringCLRFactory. The SpringCLRFactory belong to the bundle org.eclipse.e4.xwt.spring and my XWT is loaded into another bundle. I had founded this discussion http://webcache.googleusercontent.com/search?q=cache:3C4KHp5QS40J:www.eclipse.org/forums/index.php%3Ft%3Dmsg%26%26th%3D168642%26goto%3D535820+XWT+OSgi&cd=11&hl=fr&ct=clnk&gl=fr&client=firefox-a but I don't know how I can extends DefaultLoadingContext . I think DynamicImport-Package: * could resolve a lot of ClassLoader problems but I don"t know if you find it's a clean solution.
(In reply to comment #31) > > Thanks for your commit. I'm working on this XWT Spring support. I have started > to create new bundle org.eclipse.e4.xwt.spring which provides support for > Spring. Is it OK with this bundle name? Yes, it was what I thought. > > This bundle provides : > > 1. AbstractSpringCLRFactory wich use Spring container ApplicationContext. It > has the abstract method : > > ApplicationContext getApplicationContext(String properties, Map<String, > String> propertiesMap); > > Where properties is the arg value of createCLR and propertiesMap the map > tokenized. When you wish use XWT without OSGi you must implements this classe > to return the Spring ApplicationContext. > > Here a sample of XWT with Spring (without OSGi) : > > <Composite xmlns="http://www.eclipse.org/xwt/presentation" > xmlns:x="http://www.eclipse.org/xwt" > x:ClassFactory="org.eclipse.e4.xwt.spring.SpringCLRFactory bean=myCLR"> > > As you can see there is bean=myCLR. You suggested me to have only "myCLR" > (without bean name), but into OSGi context I need bundle parameter (please see > next section) OK, it should work. It is the responsibility of SpringCLRFactory to part the arguments: bean=myCLR. > > 2. SpringCLRFactory extends AbstractSpringCLRFactory and works with OSGi > context. It use an OSGi ServiceTracker to retrieve ApplicationContext into an > OSGi Bundle. So you must fill the bundle into XWT file : > > <Composite xmlns="http://www.eclipse.org/xwt/presentation" > xmlns:x="http://www.eclipse.org/xwt" > x:ClassFactory="org.eclipse.e4.xwt.spring.SpringCLRFactory > bean=myCLR,bundle=org.eclipse.e4.xwt.spring.tests.osgi"> > > It start to works BUT I had to modify XWT bundle org.eclipse.e4.xwt : > > 1. Comment line 378 of the ResourceLoader.java : > > if (!options.containsKey(IXWTLoader.CLASS_FACTORY_PROPERTY)) { > //options.put(IXWTLoader.CLASS_FACTORY_PROPERTY, loader.getCLRFactory()); > } We cannot remove it. I know the reason. I'll fix it. > > Otherwise I have the following error : > > ------------- > java.lang.UnsupportedOperationException > at java.util.AbstractMap.put(Unknown Source) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:378) > ---- > loader.getCLRFactory() return null, I don't know why? With your sampel I have > the same problem. I had to comments this line to launch your sample. > > 2. Modify MANIFEST.MF by adding > DynamicImport-Package: * > > It's the solution I have founded to load > org.eclipse.e4.xwt.spring.SpringCLRFactory class into OSGi context. I don"t > know how I could resolve the ClassLoader of my SpringCLRFactory. The > SpringCLRFactory belong to the bundle org.eclipse.e4.xwt.spring and my XWT is > loaded into another bundle. You should setup the XWT.setLoaderContext(); > > I had founded this discussion > http://webcache.googleusercontent.com/search?q=cache:3C4KHp5QS40J:www.eclipse.org/forums/index.php%3Ft%3Dmsg%26%26th%3D168642%26goto%3D535820+XWT+OSgi&cd=11&hl=fr&ct=clnk&gl=fr&client=firefox-a > but I don't know how I can extends DefaultLoadingContext . You can load at the root Part class in org.eclipse.e4.xwt.workbench. > > I think DynamicImport-Package: * could resolve a lot of ClassLoader problems > but I don"t know if you find it's a clean solution. org.eclipse.e4.xwt is generic component, which should work in OSGi and non-OSGi. So I think it doesn't help.
(In reply to comment #32) > You can load at the root Part class in org.eclipse.e4.xwt.workbench. Sorry, I mean "look" instead of "load".
(In reply to comment #32) > (In reply to comment #31) > > > > Thanks for your commit. I'm working on this XWT Spring support. I have started > > to create new bundle org.eclipse.e4.xwt.spring which provides support for > > Spring. Is it OK with this bundle name? > > Yes, it was what I thought. Cool. > > > > > This bundle provides : > > > > 1. AbstractSpringCLRFactory wich use Spring container ApplicationContext. It > > has the abstract method : > > > > ApplicationContext getApplicationContext(String properties, Map<String, > > String> propertiesMap); > > > > Where properties is the arg value of createCLR and propertiesMap the map > > tokenized. When you wish use XWT without OSGi you must implements this classe > > to return the Spring ApplicationContext. > > > > Here a sample of XWT with Spring (without OSGi) : > > > > <Composite xmlns="http://www.eclipse.org/xwt/presentation" > > xmlns:x="http://www.eclipse.org/xwt" > > x:ClassFactory="org.eclipse.e4.xwt.spring.SpringCLRFactory bean=myCLR"> > > > > As you can see there is bean=myCLR. You suggested me to have only "myCLR" > > (without bean name), but into OSGi context I need bundle parameter (please see > > next section) > > OK, it should work. It is the responsibility of SpringCLRFactory to part the > arguments: bean=myCLR. Cool. > > > > > 2. SpringCLRFactory extends AbstractSpringCLRFactory and works with OSGi > > context. It use an OSGi ServiceTracker to retrieve ApplicationContext into an > > OSGi Bundle. So you must fill the bundle into XWT file : > > > > <Composite xmlns="http://www.eclipse.org/xwt/presentation" > > xmlns:x="http://www.eclipse.org/xwt" > > x:ClassFactory="org.eclipse.e4.xwt.spring.SpringCLRFactory > > bean=myCLR,bundle=org.eclipse.e4.xwt.spring.tests.osgi"> > > > > It start to works BUT I had to modify XWT bundle org.eclipse.e4.xwt : > > > > 1. Comment line 378 of the ResourceLoader.java : > > > > if (!options.containsKey(IXWTLoader.CLASS_FACTORY_PROPERTY)) { > > //options.put(IXWTLoader.CLASS_FACTORY_PROPERTY, loader.getCLRFactory()); > > } > > We cannot remove it. I know the reason. I'll fix it. Ok I can continue my work if you will fix this problem. > > > > > Otherwise I have the following error : > > > > ------------- > > java.lang.UnsupportedOperationException > > at java.util.AbstractMap.put(Unknown Source) > > at > > org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:378) > > ---- > > loader.getCLRFactory() return null, I don't know why? With your sampel I have > > the same problem. I had to comments this line to launch your sample. > > > > 2. Modify MANIFEST.MF by adding > > DynamicImport-Package: * > > > > It's the solution I have founded to load > > org.eclipse.e4.xwt.spring.SpringCLRFactory class into OSGi context. I don"t > > know how I could resolve the ClassLoader of my SpringCLRFactory. The > > SpringCLRFactory belong to the bundle org.eclipse.e4.xwt.spring and my XWT is > > loaded into another bundle. > > You should setup the XWT.setLoaderContext(); > > > > > I had founded this discussion > > http://webcache.googleusercontent.com/search?q=cache:3C4KHp5QS40J:www.eclipse.org/forums/index.php%3Ft%3Dmsg%26%26th%3D168642%26goto%3D535820+XWT+OSgi&cd=11&hl=fr&ct=clnk&gl=fr&client=firefox-a > > but I don't know how I can extends DefaultLoadingContext . > > You can load at the root Part class in org.eclipse.e4.xwt.workbench. > > > > > I think DynamicImport-Package: * could resolve a lot of ClassLoader problems > > but I don"t know if you find it's a clean solution. > > org.eclipse.e4.xwt is generic component, which should work in OSGi and > non-OSGi. So I think it doesn't help. Problem come from ONLY with OSGi context. I think DynamicImport-Package: * could resolve a lot of problems. But I don't know if it's a clean solution?
(In reply to comment #34) > > > > org.eclipse.e4.xwt is generic component, which should work in OSGi and > > non-OSGi. So I think it doesn't help. > Problem come from ONLY with OSGi context. I think DynamicImport-Package: * > could resolve a lot of problems. But I don't know if it's a clean solution? You can attach your codes here or commit in e4 under XWT/bundles. I can look at it.
(In reply to comment #35) > (In reply to comment #34) > > > > > > org.eclipse.e4.xwt is generic component, which should work in OSGi and > > > non-OSGi. So I think it doesn't help. > > Problem come from ONLY with OSGi context. I think DynamicImport-Package: * > > could resolve a lot of problems. But I don't know if it's a clean solution? > > You can attach your codes here or commit in e4 under XWT/bundles. I can look at > it. I have not finished my work. But for DynamicImport-Package: * I have just added line : ------------------------------ DynamicImport-Package: * ------------------------------ Into the MANIFEST.MF of the org.eclipse.e4.xwt bundle.
(In reply to comment #36) > (In reply to comment #35) > > (In reply to comment #34) > > > > > > > > org.eclipse.e4.xwt is generic component, which should work in OSGi and > > > > non-OSGi. So I think it doesn't help. > > > Problem come from ONLY with OSGi context. I think DynamicImport-Package: * > > > could resolve a lot of problems. But I don't know if it's a clean solution? > > > > You can attach your codes here or commit in e4 under XWT/bundles. I can look at > > it. > > I have not finished my work. But for DynamicImport-Package: * I have just added > line : > > ------------------------------ > DynamicImport-Package: * > ------------------------------ > > Into the MANIFEST.MF of the org.eclipse.e4.xwt bundle. Yves I have seen XWTAbstractPart class from org.eclipse.e4.xwt.ui.workbench bundle wich configure XWT : ------------------------------ XWT.setLoadingContext(new DefaultLoadingContext(loader)); ------------------------------ But I cannot use that because I have noticed that XWT.set* must be called into the same Thread than SWT Display otherwise I have : ------------------------------ org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.SWT.error(SWT.java:3969) at org.eclipse.swt.widgets.Widget.error(Widget.java:468) at org.eclipse.swt.widgets.Shell.<init>(Shell.java:282) at org.eclipse.swt.widgets.Shell.<init>(Shell.java:273) at org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:472) ------------------------------ For the workbench it works well because the XWT.setLoadingContext is called into the same Thread than SWT Display. In my case I have 1. a bundle wich provides SpringCLRFactory. I tried to call ------------------------------ XWT.setLoadingContext(new DefaultLoadingContext(loader)); ------------------------------ into the Activator of the bundle of SpringCLRFactory 2. Call XWT.load into a bundle which load teh xwt file and I have org.eclipse.swt.SWTException: Invalid thread access. DynamicImport-Package: * resolve the ClassLoader problem.
(In reply to comment #37) > Yves I have seen XWTAbstractPart class from org.eclipse.e4.xwt.ui.workbench > bundle wich configure XWT : > ------------------------------ > XWT.setLoadingContext(new DefaultLoadingContext(loader)); > ------------------------------ > But I cannot use that because I have noticed that XWT.set* must be called into > the same Thread than SWT Display otherwise I have : > ------------------------------ > org.eclipse.swt.SWTException: Invalid thread access > at org.eclipse.swt.SWT.error(SWT.java:4083) > at org.eclipse.swt.SWT.error(SWT.java:3998) > at org.eclipse.swt.SWT.error(SWT.java:3969) > at org.eclipse.swt.widgets.Widget.error(Widget.java:468) > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:282) > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:273) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:472) > ------------------------------ > For the workbench it works well because the XWT.setLoadingContext is called > into the same Thread than SWT Display. In my case I have > 1. a bundle wich provides SpringCLRFactory. I tried to call > ------------------------------ > XWT.setLoadingContext(new DefaultLoadingContext(loader)); > ------------------------------ > into the Activator of the bundle of SpringCLRFactory > 2. Call XWT.load into a bundle which load teh xwt file and I have > org.eclipse.swt.SWTException: Invalid thread access. > DynamicImport-Package: * resolve the ClassLoader problem. I think it is not a problem of XWT.setLoadingContext(). The problem is the XWT.load() or XWT.open(), which need the Display thread to create SWT Widgets.
(In reply to comment #38) > (In reply to comment #37) > > Yves I have seen XWTAbstractPart class from org.eclipse.e4.xwt.ui.workbench > > bundle wich configure XWT : > > ------------------------------ > > XWT.setLoadingContext(new DefaultLoadingContext(loader)); > > ------------------------------ > > But I cannot use that because I have noticed that XWT.set* must be called into > > the same Thread than SWT Display otherwise I have : > > ------------------------------ > > org.eclipse.swt.SWTException: Invalid thread access > > at org.eclipse.swt.SWT.error(SWT.java:4083) > > at org.eclipse.swt.SWT.error(SWT.java:3998) > > at org.eclipse.swt.SWT.error(SWT.java:3969) > > at org.eclipse.swt.widgets.Widget.error(Widget.java:468) > > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:282) > > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:273) > > at > > org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:472) > > ------------------------------ > > For the workbench it works well because the XWT.setLoadingContext is called > > into the same Thread than SWT Display. In my case I have > > 1. a bundle wich provides SpringCLRFactory. I tried to call > > ------------------------------ > > XWT.setLoadingContext(new DefaultLoadingContext(loader)); > > ------------------------------ > > into the Activator of the bundle of SpringCLRFactory > > 2. Call XWT.load into a bundle which load teh xwt file and I have > > org.eclipse.swt.SWTException: Invalid thread access. > > DynamicImport-Package: * resolve the ClassLoader problem. > > I think it is not a problem of XWT.setLoadingContext(). The problem is the > XWT.load() or XWT.open(), which need the Display thread to create SWT Widgets. Yes it's the problem. When I call XWT.setLoadingContext() tehre is no problem, it's XWT.open() which throw the error. Do you think it's possible to add DynamicImport-Package: *?
(In reply to comment #39) > > I think it is not a problem of XWT.setLoadingContext(). The problem is the > > XWT.load() or XWT.open(), which need the Display thread to create SWT Widgets. > Yes it's the problem. When I call XWT.setLoadingContext() tehre is no problem, > it's XWT.open() which throw the error. > Do you think it's possible to add DynamicImport-Package: *? Yes, I think so. I didn't see any negative effects.
(In reply to comment #40) > (In reply to comment #39) > > > I think it is not a problem of XWT.setLoadingContext(). The problem is the > > > XWT.load() or XWT.open(), which need the Display thread to create SWT Widgets. > > Yes it's the problem. When I call XWT.setLoadingContext() tehre is no problem, > > it's XWT.open() which throw the error. > > Do you think it's possible to add DynamicImport-Package: *? > Yes, I think so. I didn't see any negative effects. Great! I think I can do something with DynamicImport-Package: *. I would like just know if teh call of XWT.set* (setLoadingContext, stCLRFactory...) must be called into teh same Thread than SWT Display? I would like provides several examples and I would like too write something into E4 Wiki about XWT Spring Support (could you give me a Wiki URL where I could write something, thank's).
(In reply to comment #41) > (In reply to comment #40) > > (In reply to comment #39) > > > > I think it is not a problem of XWT.setLoadingContext(). The problem is the > > > > XWT.load() or XWT.open(), which need the Display thread to create SWT Widgets. > > > Yes it's the problem. When I call XWT.setLoadingContext() tehre is no problem, > > > it's XWT.open() which throw the error. > > > Do you think it's possible to add DynamicImport-Package: *? > > Yes, I think so. I didn't see any negative effects. > Great! I think I can do something with DynamicImport-Package: *. > I would like just know if teh call of XWT.set* (setLoadingContext, > stCLRFactory...) must be called into teh same Thread than SWT Display? I would > like provides several examples and I would like too write something into E4 > Wiki about XWT Spring Support (could you give me a Wiki URL where I could write > something, thank's). I have created a link in http://wiki.eclipse.org/E4/XWT#Spring_Integration to: http://wiki.eclipse.org/index.php?title=E4/XWT/Spring&action=edit
(In reply to comment #31) > java.lang.UnsupportedOperationException > at java.util.AbstractMap.put(Unknown Source) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:378) This bug is fixed and committed in CVS. Please check it.
(In reply to comment #43) > (In reply to comment #31) > > java.lang.UnsupportedOperationException > > at java.util.AbstractMap.put(Unknown Source) > > at > > org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:378) > This bug is fixed and committed in CVS. Please check it. Thank a lot Yves, it works very well. Please let me time to finish and clean my work and I will send you a patch. I have tried to use XWT.setCLRFactory (into my same thread than SWT) and my factory is never used? It seems that ResourceLoader#loadFactoryCLR doesn't check if XWT.getCLRFactory is not null? I have not found sample with XWT.setCLRFactory. My last question is XWT.set* must be called into the same Thread that SWT Display. Is it a normal?
(In reply to comment #44) > Thank a lot Yves, it works very well. Please let me time to finish and clean my > work and I will send you a patch. Sure. > I have tried to use XWT.setCLRFactory (into my same thread than SWT) and my > factory is never used? It seems that ResourceLoader#loadFactoryCLR doesn't > check if XWT.getCLRFactory is not null? I have not found sample with > XWT.setCLRFactory. It is in the JUnit testcase testCLRFactoryPrecedentGlobal() of the class CLRFactoryTests: > My last question is XWT.set* must be called into the same Thread that SWT > Display. Is it a normal? No, it can be called in any thread.
(In reply to comment #45) > (In reply to comment #44) > > Thank a lot Yves, it works very well. Please let me time to finish and clean my > > work and I will send you a patch. > > Sure. > > > I have tried to use XWT.setCLRFactory (into my same thread than SWT) and my > > factory is never used? It seems that ResourceLoader#loadFactoryCLR doesn't > > check if XWT.getCLRFactory is not null? I have not found sample with > > XWT.setCLRFactory. > > It is in the JUnit testcase testCLRFactoryPrecedentGlobal() of the class > CLRFactoryTests: Thank's Yves. I have created the same JUnit Test like you, it works very well except testCLRFactoryOption and testCLRFactoryGlobalOption. To manage CLRFactoryOption.xwt I must write : -------------------------------------------------------- <Composite xmlns="http://www.eclipse.org/xwt/presentation" xmlns:x="http://www.eclipse.org/xwt" x:ClassFactory="bean=myCLR"> .... -------------------------------------------------------- As you can see x:ClassFactory="bean=myCLR"contains not the CLR factory class (just th eargs). So I have the error : -------------------------------------------------------- org.eclipse.e4.xwt.XWTException: bean=myCLR ClassFactory not found. at org.eclipse.e4.xwt.javabean.ResourceLoader.loadFactoryCLR(ResourceLoader.java:1458) at org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:602) at org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:490) at org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:392) at org.eclipse.e4.xwt.internal.core.Core.createCLRElement(Core.java:617) at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:674) at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:644) at org.eclipse.e4.xwt.XWTLoader.loadWithOptions(XWTLoader.java:857) at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:790) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:784) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:736) at org.eclipse.e4.xwt.XWT.open(XWT.java:416) at -------------------------------------------------------- > > > My last question is XWT.set* must be called into the same Thread that SWT > > Display. Is it a normal? > > No, it can be called in any thread. In my case it doesn't works. The test is simple : -------------------------------------------------------- public static void main(String[] args) { XWT.setCLRFactory(CLRFactory.INSTANCE); new Thread() { public void run() { URL url = CLRFactoryDefault.class.getResource(CLRFactoryDefault.class.getSimpleName() + IConstants.XWT_EXTENSION_SUFFIX); try { XWT.open(url); } catch (Exception e) { e.printStackTrace(); } }; }.start(); } -------------------------------------------------------- When I run this case, I have the error : -------------------------------------------------------- org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.SWT.error(SWT.java:3969) at org.eclipse.swt.widgets.Widget.error(Widget.java:468) at org.eclipse.swt.widgets.Shell.<init>(Shell.java:282) at org.eclipse.swt.widgets.Shell.<init>(Shell.java:273) at org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:483) at org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:392) at org.eclipse.e4.xwt.internal.core.Core.createCLRElement(Core.java:617) at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:674) at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:644) at org.eclipse.e4.xwt.XWTLoader.loadWithOptions(XWTLoader.java:857) at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:790) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:784) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:736) at org.eclipse.e4.xwt.XWT.open(XWT.java:416) at --------------------------------------------------------
(In reply to comment #46) > > Thank's Yves. I have created the same JUnit Test like you, it works very well > except testCLRFactoryOption and testCLRFactoryGlobalOption. To manage > CLRFactoryOption.xwt I must write : > > -------------------------------------------------------- > <Composite xmlns="http://www.eclipse.org/xwt/presentation" > xmlns:x="http://www.eclipse.org/xwt" > x:ClassFactory="bean=myCLR"> > .... > -------------------------------------------------------- > > As you can see x:ClassFactory="bean=myCLR"contains not the CLR factory class > (just the args). So I have the error : > > -------------------------------------------------------- > org.eclipse.e4.xwt.XWTException: bean=myCLR ClassFactory not found. > at > org.eclipse.e4.xwt.javabean.ResourceLoader.loadFactoryCLR(ResourceLoader.java:1458) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:602) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:490) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:392) > at org.eclipse.e4.xwt.internal.core.Core.createCLRElement(Core.java:617) > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:674) > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:644) > at org.eclipse.e4.xwt.XWTLoader.loadWithOptions(XWTLoader.java:857) > at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:790) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:784) > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:736) > at org.eclipse.e4.xwt.XWT.open(XWT.java:416) > at > -------------------------------------------------------- It is an expected behavior. The first token of x:ClassFactory must be a class name. > > > > > > My last question is XWT.set* must be called into the same Thread that SWT > > > Display. Is it a normal? > > > > No, it can be called in any thread. > > In my case it doesn't works. The test is simple : > -------------------------------------------------------- > public static void main(String[] args) { > > XWT.setCLRFactory(CLRFactory.INSTANCE); > > new Thread() { > public void run() { > URL url = > CLRFactoryDefault.class.getResource(CLRFactoryDefault.class.getSimpleName() > + IConstants.XWT_EXTENSION_SUFFIX); > try { > XWT.open(url); > } catch (Exception e) { > e.printStackTrace(); > } > }; > }.start(); > > } > -------------------------------------------------------- > > When I run this case, I have the error : > > -------------------------------------------------------- > org.eclipse.swt.SWTException: Invalid thread access > at org.eclipse.swt.SWT.error(SWT.java:4083) > at org.eclipse.swt.SWT.error(SWT.java:3998) > at org.eclipse.swt.SWT.error(SWT.java:3969) > at org.eclipse.swt.widgets.Widget.error(Widget.java:468) > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:282) > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:273) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:483) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:392) > at org.eclipse.e4.xwt.internal.core.Core.createCLRElement(Core.java:617) > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:674) > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:644) > at org.eclipse.e4.xwt.XWTLoader.loadWithOptions(XWTLoader.java:857) > at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:790) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:784) > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:736) > at org.eclipse.e4.xwt.XWT.open(XWT.java:416) > at > -------------------------------------------------------- XWT.load()/XWT.open() must be called in Display thread.
(In reply to comment #47) > (In reply to comment #46) > > > > Thank's Yves. I have created the same JUnit Test like you, it works very well > > except testCLRFactoryOption and testCLRFactoryGlobalOption. To manage > > CLRFactoryOption.xwt I must write : > > > > -------------------------------------------------------- > > <Composite xmlns="http://www.eclipse.org/xwt/presentation" > > xmlns:x="http://www.eclipse.org/xwt" > > x:ClassFactory="bean=myCLR"> > > .... > > -------------------------------------------------------- > > > > As you can see x:ClassFactory="bean=myCLR"contains not the CLR factory class > > (just the args). So I have the error : > > > > -------------------------------------------------------- > > org.eclipse.e4.xwt.XWTException: bean=myCLR ClassFactory not found. > > at > > org.eclipse.e4.xwt.javabean.ResourceLoader.loadFactoryCLR(ResourceLoader.java:1458) > > at > > org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:602) > > at > > org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:490) > > at > > org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:392) > > at org.eclipse.e4.xwt.internal.core.Core.createCLRElement(Core.java:617) > > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:674) > > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:644) > > at org.eclipse.e4.xwt.XWTLoader.loadWithOptions(XWTLoader.java:857) > > at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:790) > > at > > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:784) > > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:736) > > at org.eclipse.e4.xwt.XWT.open(XWT.java:416) > > at > > -------------------------------------------------------- > > It is an expected behavior. The first token of x:ClassFactory must be a class > name. I know that but I think it's shame that I cannot use XWT.setCLRFactory for Spring support. I think it should be cool if we can set only args (into my case bean) into x:ClassFactory ONLY if XWT.setCLRFactory is filled. What do you think about that? > > > > > > > > > > My last question is XWT.set* must be called into the same Thread that SWT > > > > Display. Is it a normal? > > > > > > No, it can be called in any thread. > > > > In my case it doesn't works. The test is simple : > > -------------------------------------------------------- > > public static void main(String[] args) { > > > > XWT.setCLRFactory(CLRFactory.INSTANCE); > > > > new Thread() { > > public void run() { > > URL url = > > CLRFactoryDefault.class.getResource(CLRFactoryDefault.class.getSimpleName() > > + IConstants.XWT_EXTENSION_SUFFIX); > > try { > > XWT.open(url); > > } catch (Exception e) { > > e.printStackTrace(); > > } > > }; > > }.start(); > > > > } > > -------------------------------------------------------- > > > > When I run this case, I have the error : > > > > -------------------------------------------------------- > > org.eclipse.swt.SWTException: Invalid thread access > > at org.eclipse.swt.SWT.error(SWT.java:4083) > > at org.eclipse.swt.SWT.error(SWT.java:3998) > > at org.eclipse.swt.SWT.error(SWT.java:3969) > > at org.eclipse.swt.widgets.Widget.error(Widget.java:468) > > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:282) > > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:273) > > at > > org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:483) > > at > > org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:392) > > at org.eclipse.e4.xwt.internal.core.Core.createCLRElement(Core.java:617) > > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:674) > > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:644) > > at org.eclipse.e4.xwt.XWTLoader.loadWithOptions(XWTLoader.java:857) > > at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:790) > > at > > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:784) > > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:736) > > at org.eclipse.e4.xwt.XWT.open(XWT.java:416) > > at > > -------------------------------------------------------- > > XWT.load()/XWT.open() must be called in Display thread. So must call XWT.setCLRFactory into teh same thread than XWT.open. Is that? I think it's shame because I would like call XWT.setCLRFactory(SpringCLRFactory.INSTANCE) (if we can write x:CmlasFactory="bean=myBean" ) into the Activator of teh Spring support. So user could juste write x:CmlasFactory="bean=myBean" without filled the Spring CLR factory.
(In reply to comment #48) > (In reply to comment #47) > > > > It is an expected behavior. The first token of x:ClassFactory must be a class > > name. > > I know that but I think it's shame that I cannot use XWT.setCLRFactory for > Spring support. I think it should be cool if we can set only args (into my case > bean) into x:ClassFactory ONLY if XWT.setCLRFactory is filled. What do you > think about that? This introduces a conflict with the override mechanism, i.e, The setting in file overrides the option and global setting. We may introduce a keyword or operator such as +. x:ClassFactory="+ bean=myCLR" > > > > > XWT.load()/XWT.open() must be called in Display thread. > > So must call XWT.setCLRFactory into teh same thread than XWT.open. Is that? No, we don't care the thread to call XWT.setCLRFactory(). Only the Display thread can call XWT.load()/XWT.open().
(In reply to comment #49) > (In reply to comment #48) > > (In reply to comment #47) > > > > > > It is an expected behavior. The first token of x:ClassFactory must be a class > > > name. > > > > I know that but I think it's shame that I cannot use XWT.setCLRFactory for > > Spring support. I think it should be cool if we can set only args (into my case > > bean) into x:ClassFactory ONLY if XWT.setCLRFactory is filled. What do you > > think about that? > > This introduces a conflict with the override mechanism, i.e, The setting in > file overrides the option and global setting. > > We may introduce a keyword or operator such as +. > x:ClassFactory="+ bean=myCLR" > Good idea. Why not use '*' character : x:ClassFactory="* bean=myCLR" If you implements that (with '+' or '*' character), the args of teh createCLR should be "bean=myCLR" and not "* bean=myCLR". Is that OK? > > > > > > > > XWT.load()/XWT.open() must be called in Display thread. > > > > So must call XWT.setCLRFactory into teh same thread than XWT.open. Is that? > No, we don't care the thread to call XWT.setCLRFactory(). Only the Display > thread can call XWT.load()/XWT.open(). Ok I cannot set SpringCLRFactory.INSTANCE with XWT.setCLRFactory(SpringCLRFactory.INSTANCE) into the Activator of the XWT Spring support.
(In reply to comment #50) > > Good idea. Why not use '*' character : > > x:ClassFactory="* bean=myCLR" I prefer "+" that means "append". > > If you implements that (with '+' or '*' character), the args of teh createCLR > should be "bean=myCLR" and not "* bean=myCLR". Is that OK? Yes. I did the modification and committed in CVS. You can find a testcase CLRFactoryOptionArgs > > > > > > > > > > > > XWT.load()/XWT.open() must be called in Display thread. > > > > > > So must call XWT.setCLRFactory into teh same thread than XWT.open. Is that? > > No, we don't care the thread to call XWT.setCLRFactory(). Only the Display > > thread can call XWT.load()/XWT.open(). > > Ok I cannot set SpringCLRFactory.INSTANCE with > XWT.setCLRFactory(SpringCLRFactory.INSTANCE) into the Activator of the XWT > Spring support. Please give me more detail information.
(In reply to comment #51) > (In reply to comment #50) > > > > Good idea. Why not use '*' character : > > > > x:ClassFactory="* bean=myCLR" > > I prefer "+" that means "append". > > > > > If you implements that (with '+' or '*' character), the args of teh createCLR > > should be "bean=myCLR" and not "* bean=myCLR". Is that OK? > Yes. I did the modification and committed in CVS. You can find a testcase > CLRFactoryOptionArgs Thank a lot Yves. My JUnit (which are teh same than you) works well!!! (with the '+' character but not with '*' character). > > > > > > > > > > > > > > > > > XWT.load()/XWT.open() must be called in Display thread. > > > > > > > > So must call XWT.setCLRFactory into teh same thread than XWT.open. Is that? > > > No, we don't care the thread to call XWT.setCLRFactory(). Only the Display > > > thread can call XWT.load()/XWT.open(). > > > > Ok I cannot set SpringCLRFactory.INSTANCE with > > XWT.setCLRFactory(SpringCLRFactory.INSTANCE) into the Activator of the XWT > > Spring support. > > Please give me more detail information. Ok. my Spring support for XWT is managed with the bundle org.eclipse.e4.xwt.springframework. It can manage CLR bean declaration with Spring into NO OSGi context and with OSGi context (Spring DM is used for that). Into OSGi context you must write for instance : ---------------------- <Shell xmlns="http://www.eclipse.org/xwt/presentation" xmlns:x="http://www.eclipse.org/xwt" x:ClassFactory="org.eclipse.e4.xwt.springframework.SpringCLRFactory.INSTANCE bean=myUI bundle=org.eclipse.e4.xwt.springframework.osgi.sample1"> ---------------------- I think it should be very cool if we could write without declaring the SpringCLRFactory like this : ---------------------- <Shell xmlns="http://www.eclipse.org/xwt/presentation" xmlns:x="http://www.eclipse.org/xwt" x:ClassFactory="+ bean=myUI bundle=org.eclipse.e4.xwt.springframework.osgi.sample1"> ---------------------- To do that I thought to set the default SpringCLRfactory into the Bundle Activator of the bundle org.eclipse.e4.xwt.springframework : ---------------------- public void start(BundleContext bundleContext) throws Exception { XWT.setCLRFactory(SpringCLRFactory.INSTANCE); } ---------------------- If I create OSGi config launch (without setting the start level of any bundles) it works great. BUT if I set a start level for the bundle which open teh XWT file I have the error : ---------------------- org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.SWT.error(SWT.java:3969) at org.eclipse.swt.widgets.Widget.error(Widget.java:468) at org.eclipse.swt.widgets.Shell.<init>(Shell.java:282) at org.eclipse.swt.widgets.Shell.<init>(Shell.java:273) at org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:483) at org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:392) at org.eclipse.e4.xwt.internal.core.Core.createCLRElement(Core.java:617) at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:674) at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:644) at org.eclipse.e4.xwt.XWTLoader.loadWithOptions(XWTLoader.java:859) at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:792) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:786) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:738) at org.eclipse.e4.xwt.XWT.open(XWT.java:416) at org.eclipse.e4.xwt.springframework.osgi.sample1.Activator$1.run(Activator.java:52) ---------------------- I think it's impossible for you to discover the problem with my explanation. I will create a launch with problem into my patch (coming soon) and it will be more easy for you, I think.
(In reply to comment #52) > > ---------------------- > public void start(BundleContext bundleContext) throws Exception { > XWT.setCLRFactory(SpringCLRFactory.INSTANCE); > } > ---------------------- > > If I create OSGi config launch (without setting the start level of any bundles) > it works great. BUT if I set a start level for the bundle which open teh XWT > file I have the error : > > ---------------------- > org.eclipse.swt.SWTException: Invalid thread access > at org.eclipse.swt.SWT.error(SWT.java:4083) > at org.eclipse.swt.SWT.error(SWT.java:3998) > at org.eclipse.swt.SWT.error(SWT.java:3969) > at org.eclipse.swt.widgets.Widget.error(Widget.java:468) > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:282) > at org.eclipse.swt.widgets.Shell.<init>(Shell.java:273) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.doCreate(ResourceLoader.java:483) > at > org.eclipse.e4.xwt.javabean.ResourceLoader.createUIElement(ResourceLoader.java:392) > at org.eclipse.e4.xwt.internal.core.Core.createCLRElement(Core.java:617) > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:674) > at org.eclipse.e4.xwt.internal.core.Core.load(Core.java:644) > at org.eclipse.e4.xwt.XWTLoader.loadWithOptions(XWTLoader.java:859) > at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:792) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:786) > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:738) > at org.eclipse.e4.xwt.XWT.open(XWT.java:416) > at > org.eclipse.e4.xwt.springframework.osgi.sample1.Activator$1.run(Activator.java:52) > ---------------------- > > I think it's impossible for you to discover the problem with my explanation. I > will create a launch with problem into my patch (coming soon) and it will be > more easy for you, I think. I cannot understand why you need to open a XWT file in start(). If you really need it, you can do the following: public void start(BundleContext bundleContext) throws Exception { XWT.setCLRFactory(SpringCLRFactory.INSTANCE); Display.getDefault().asyncexec(new Runnable() { public void run() { XWT.open()... ) ) }
(In reply to comment #53) > (In reply to comment #52) > I cannot understand why you need to open a XWT file in start(). If you really > need it, you can do the following: > > public void start(BundleContext bundleContext) throws Exception { > XWT.setCLRFactory(SpringCLRFactory.INSTANCE); > Display.getDefault().asyncexec(new Runnable() { > public void run() { > XWT.open()... > ) > ) > } No sorry it doesn't works (even if I don't change the start level as I have explained below). My case is : 1. I have a bundle org.eclipse.e4.xwt.springframework where I wish call into the Activator#start : ----------------------- XWT.setCLRFactory(SpringCLRFactory.INSTANCE); ----------------------- 2. I have an another bundle org.eclipse.e4.xwt.springframework.osgi.sample4 which open an XWT file into the Activator#start : ----------------------- public void start(BundleContext bundleContext) throws Exception { new Thread() { public void run() { URL url = EventHandler.class.getResource("ui" + IConstants.XWT_EXTENSION_SUFFIX); try { XWT.open(url); } catch (Exception e) { e.printStackTrace(); } }; }.start(); ----------------------- So the Thread which open the XWT file is different from the Thread which configure XWT.setCLRFactory.
(In reply to comment #54) > 2. I have an another bundle org.eclipse.e4.xwt.springframework.osgi.sample4 > which open an XWT file into the Activator#start : > > ----------------------- > public void start(BundleContext bundleContext) throws Exception { > > new Thread() { > public void run() { > > URL url = EventHandler.class.getResource("ui" > + IConstants.XWT_EXTENSION_SUFFIX); > try { > XWT.open(url); > } catch (Exception e) { > e.printStackTrace(); > } > }; > }.start(); > ----------------------- > > So the Thread which open the XWT file is different from the Thread which > configure XWT.setCLRFactory. You can call only open/load in the Display thread.
(In reply to comment #55) > (In reply to comment #54) > > 2. I have an another bundle org.eclipse.e4.xwt.springframework.osgi.sample4 > > which open an XWT file into the Activator#start : > > > > ----------------------- > > public void start(BundleContext bundleContext) throws Exception { > > > > new Thread() { > > public void run() { > > > > URL url = EventHandler.class.getResource("ui" > > + IConstants.XWT_EXTENSION_SUFFIX); > > try { > > XWT.open(url); > > } catch (Exception e) { > > e.printStackTrace(); > > } > > }; > > }.start(); > > ----------------------- > > > > So the Thread which open the XWT file is different from the Thread which > > configure XWT.setCLRFactory. > > You can call only open/load in the Display thread. Ok. I don't understand very good why there is this restriction. Perhaps you wish having configuration linked to the Display Thread? If it's that is it possible to have a global configuration like this : ------------------------------------------------------ XWT.setGlobalCLRFactory(ICLRFactory factory) ------------------------------------------------------ You could use static fields to store this factory : ------------------------------------------------------ public class XWT { private static ICLRFactory globalCLRFactory; static public void setCLRFactory(ICLRFactory factory) { XWT.globalCLRFactory = factory; } static public void setCLRFactory(ICLRFactory factory) { XWTLoaderManager.getActive().setCLRFactory(factory); } } ------------------------------------------------------ What do you think? If we have this features, we could omit to declare the SpringCLRFactory.INSTANCE for each xwt file into OSGi context (teh Activator#start of SpringCLRFactory bundle will set the factory).
(In reply to comment #56) > (In reply to comment #55) > > You can call only open/load in the Display thread. > > Ok. I don't understand very good why there is this restriction. Perhaps you > wish having configuration linked to the Display Thread? If it's that is it > possible to have a global configuration like this : > It is not XWT, it is the feature of SWT. You cannot access or create SWT widgets in other thread than Display thread.
(In reply to comment #57) > (In reply to comment #56) > > (In reply to comment #55) > > > You can call only open/load in the Display thread. > > > > Ok. I don't understand very good why there is this restriction. Perhaps you > > wish having configuration linked to the Display Thread? If it's that is it > > possible to have a global configuration like this : > > > > It is not XWT, it is the feature of SWT. You cannot access or create SWT > widgets in other thread than Display thread. Yes I know that, but ICLRFactory doesn't create SWT widgets? If we have global ICLRFactory it can works no?
(In reply to comment #58) > (In reply to comment #57) > > It is not XWT, it is the feature of SWT. You cannot access or create SWT > > widgets in other thread than Display thread. > > Yes I know that, but ICLRFactory doesn't create SWT widgets? ICLRFactory will be called only by XWT.load/open(), not at XWT.setCLRfactory(). > If we have global ICLRFactory it can works no? No.
(In reply to comment #59) > (In reply to comment #58) > > (In reply to comment #57) > > > It is not XWT, it is the feature of SWT. You cannot access or create SWT > > > widgets in other thread than Display thread. > > > > Yes I know that, but ICLRFactory doesn't create SWT widgets? > > ICLRFactory will be called only by XWT.load/open(), not at XWT.setCLRfactory(). > > > If we have global ICLRFactory it can works no? > No. In my case ICLRFactory is singleton which can be shared between the whole XWT files. XWT.load/open() use the same instance of ICLRFactory. I think it should be cool if we have this features. Set ICLRFactory as global singleton instance.
(In reply to comment #60) > In my case ICLRFactory is singleton which can be shared between the whole XWT > files. XWT.load/open() use the same instance of ICLRFactory. I think it should > be cool if we have this features. Set ICLRFactory as global singleton instance. It is already supported. You need just to call XWT.setCLRFactory(StringCLRFactory.INSTANCE) once before load()/open().
Angelo, I think we are wasting time. Could you prepare a sample project I can look at it in detail ?
(In reply to comment #62) > Angelo, I think we are wasting time. Could you prepare a sample project I can > look at it in detail ? Yes Yves you are right. I attach a patch with my projects in few minutes. I will explain you the problems.
Created attachment 176215 [details] Spring support for XWT Contains Spring support for XWT + samples + Spring Target Platform (without Spring lib).
Created attachment 176216 [details] Spring JAR (1) to copy to spring-target-platform project Unzip this zip and copy/pase Spring JAR into spring-target-platform project.
Created attachment 176217 [details] Spring JAR (2) to copy to spring-target-platform project Unzip this zip and copy/pase Spring JAR into spring-target-platform project.
(In reply to comment #66) > Created an attachment (id=176217) [details] > Spring JAR (2) to copy to spring-target-platform project > > Unzip this zip and copy/pase Spring JAR into spring-target-platform project. Ok Yves I have attached my work. Please read http://wiki.eclipse.org/Using_Spring_with_XWT I have explained how use and test Spring support for XWT. I have finished to explain Spring support into Java "Application" context but not finished for Spring DM. To test Spring support for XWT into OSGi context, you have several launch (sample1, samples2...) into spring-target-platform. To test the case which doesn't works : * modify org.eclipse.e4.xwt.springframework.osgi.sample4.config.springclrfactory/src/springclrfactory.properties uncomment the line : ----------------------------------------------- org.eclipse.e4.xwt.springclrfactory.lazy = true ----------------------------------------------- and launch the sample4 or sample4_debug (you will see some debug information about SpringCLRFactory). org.eclipse.e4.xwt.springframework.osgi.sample4.config.springclrfactory is an OSGi fragment which is linked to org.eclipse.e4.xwt.springframework.osgi bundle to configure it. When you set the property : ----------------------------------------------- org.eclipse.e4.xwt.springclrfactory.lazy = true ----------------------------------------------- It is used into org.eclipse.e4.xwt.springframework\src\org\eclipse\e4\xwt\springframework\internal\Activator.java (line 105) : ----------------------------------------------- if (lazy) { // Set default XWT ICLRFactory XWT.setCLRFactory(SpringCLRFactory.INSTANCE); ... ----------------------------------------------- So when I'm here I'm not into the Thread Display. The bundle org.eclipse.e4.xwt.springframework.osgi.sample4 has an Activaor which open a XWT file. Hope you understand my explanation and my requirement.
Created attachment 176250 [details] ODT with schema about Spring support for XWT ODT with schema about Spring support for XWT
(In reply to comment #68) > Created an attachment (id=176250) [details] > ODT with schema about Spring support for XWT > > ODT with schema about Spring support for XWT Ok Yves I have finished the wiki documentation. Tell me if you like "Support Spring for XWT" (Java code, class names, comments....), if you can launch the samples and if wiki please you (my english is so bad, if you have time to fix some sentences it should be cool). Any suggestions are welcome. Thank's!
(In reply to comment #69) > (In reply to comment #68) > > Created an attachment (id=176250) [details] [details] > > ODT with schema about Spring support for XWT > > > > ODT with schema about Spring support for XWT > > Ok Yves I have finished the wiki documentation. Tell me if you like "Support > Spring for XWT" (Java code, class names, comments....), if you can launch the > samples and if wiki I'm on it. It is very impressive. I'll contribute it when it is possible.
I got an exception when I start sample1. The reason is the activator of bundle org.eclipse.e4.xwt.springframework, is not started. After turning on Bundle-ActivationPolicy: lazy, it works fine. And the sample4 works fine as well with the option org.eclipse.e4.xwt.springclrfactory.lazy = true Please check it.
(In reply to comment #71) > I got an exception when I start sample1. The reason is the activator of bundle > org.eclipse.e4.xwt.springframework, is not started. After turning on > Bundle-ActivationPolicy: lazy, it works fine. I agree with you this option must be checked. I will do a new patch for that (and for using org.eclipse.e4.xwt.springclrfactory.lazy = true). But before I would like clarify some problems. "I got an exception when I start sample1". Which exception? Is this exception? : ----------------------------------------------------- org.eclipse.e4.xwt.XWTException: Bunde <org.eclipse.e4.xwt.springframework> must be started before using SpringCLRFactory. ----------------------------------------------------- In my case I don't have errors? > > And the sample4 works fine as well with the option > org.eclipse.e4.xwt.springclrfactory.lazy = true I have investigated a lot of time with this problem and it doesn't work. Try to launch several times the sample4 and sometimes you will see ----------------------------------------------------- org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4083) ----------------------------------------------------- I believe I can explain the errors. As you said me, XWT.setCLRFactory must be called into the same Thread than the SWT Display. It's more complicated than this. I notice that XWT.setCLRFactory can be called into a Thread which is different from the Display Thread, ONLY if XWTLoaderManager.getActive() was called before into the SWT Display Thread. XWT.open and XWT.setCLRFactory call XWTLoaderManager.getActive() which create private static IXWTLoader defaultXWTLoader = new XWTLoader(); where XWTLoader use Display.getCurrent(). So in my case, I have * Thread1 => Activator from org.eclipse.e4.xwt.springframework which call XWT.setCLRFactory(SpringCLRFactory.INSTANCE); * Thread2 => Activator from org.eclipse.e4.xwt.springframework.osgi.sample4 which call XWT.open(url); If Thread1 is executed before Thread2, XWT.setCLRFactory call XWTLoaderManager.getActive() the first and Display.getCurrent() is linked to the Thread1. When Thread2 call XWT.open(url); there is the error : ----------------------------------------------------- org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4083) ---------------------------------------------------- To simulate this behaviour, set start level to 3 for the bundle org.eclipse.e4.xwt.springframework. If it doesn't works, try to call XWT.setCLRFactory(SpringCLRFactory.INSTANCE); on first time into your start method of the Activator. If Thread2 is executed before Thread1, it works well. I think you have luck and you have this case. We have 2 choices to fix this problem : * resolve problems with Thread. It means that XWT doesn't support multi threading? I have tried this basic sample, which open 2 xwt file into 2 Threads : ---------------------------------------------------- public static void main(String[] args) { new Thread() { @Override public void run() { URL url = CLRFactoryNamespace.class .getResource(CLRFactoryNamespace.class.getSimpleName() + IConstants.XWT_EXTENSION_SUFFIX); try { XWT.open(url); } catch (Exception e) { e.printStackTrace(); } } }.start(); new Thread() { @Override public void run() { URL url = CLRFactoryNamespace.class .getResource(CLRFactoryNamespace.class.getSimpleName() + IConstants.XWT_EXTENSION_SUFFIX); try { XWT.open(url); } catch (Exception e) { e.printStackTrace(); } } }.start(); } ---------------------------------------------------- The first window is opened, when I close it, I'm waiting to show the next window, but I have org.eclipse.swt.SWTException: Invalid thread access * disable the lazy mode for SpringCLRFactory, but I find it's very shame, because I think it's more elegant to write this : ------------------------------------------ x:ClassFactory="+ bean=myUI" ------------------------------------------ than write this : ------------------------------------------ x:ClassFactory="ui.MySpringCLRFactory.INSTANCE bean=myUI" ------------------------------------------ > > Please check it.
There is a problem with multiple threading. I have fixed in the Bug 322495 - Support of multiple threading. Now it should work.
(In reply to comment #73) > There is a problem with multiple threading. I have fixed in the Bug 322495 - > Support of multiple threading. Now it should work. Yves It's works great!!! Ok now we can use x:ClassFactory="+ bean=myUI" declaration into OSGi context if lazy mode is activated (not the default behaviour,is it OK with that?). I think it's very cool. I will send a new patch (soon) with this cool feature and fix the problem with Bundle-ActivationPolicy: lazy
(In reply to comment #74) > (In reply to comment #73) > > There is a problem with multiple threading. I have fixed in the Bug 322495 - > > Support of multiple threading. Now it should work. > > Yves It's works great!!! Ok now we can use x:ClassFactory="+ bean=myUI" > declaration into OSGi context if lazy mode is activated (not the default > behaviour,is it OK with that?). I think it's very cool. > > I will send a new patch (soon) with this cool feature and fix the problem with > Bundle-ActivationPolicy: lazy Yves for your information, the code : --------------------------------------------------------------- public static void main(String[] args) { XWT.setCLRFactory(CLRFactory.INSTANCE); new Thread() { @Override public void run() { URL url = CLRFactoryOption.class.getResource(CLRFactoryOption.class.getSimpleName() + IConstants.XWT_EXTENSION_SUFFIX); try { XWT.open(url); } catch (Exception e) { e.printStackTrace(); } } }.start(); } --------------------------------------------------------------- works very well since you have fixed problem with multi threading.
Created attachment 176464 [details] Spring support for XWT - Sample with lazy mode + Bundle-ActivationPolicy: lazy This patch improve Spring support for XWT : * Use Bundle-ActivationPolicy: lazy intio the org.eclipse.e4.xwt.springframework bundle. * Configure SpringCLRFactory with lazy mode to write XWT file with x:ClassFactory="+ bean=myUI" (see sample4). * some trace/debug log added.
(In reply to comment #76) > Created an attachment (id=176464) [details] > Spring support for XWT - Sample with lazy mode + Bundle-ActivationPolicy: lazy > > This patch improve Spring support for XWT : > > * Use Bundle-ActivationPolicy: lazy intio the > org.eclipse.e4.xwt.springframework bundle. > * Configure SpringCLRFactory with lazy mode to write XWT file with > x:ClassFactory="+ bean=myUI" (see sample4). > * some trace/debug log added. Yves I have attached a new patch. Could you retest please. I have updated my doc to explain how use lazy model with SPringCLRFactory and explain how use "Validate Bundles", "Add Required Bundles" for the launch. I'm waiting for your tests/suggestions (documentations is enough?), but I think Spring support for XWT start to be stable.
(In reply to comment #77) > > Yves I have attached a new patch. Could you retest please. I have updated my > doc to explain how use lazy model with SPringCLRFactory and explain how use > "Validate Bundles", "Add Required Bundles" for the launch. > > I'm waiting for your tests/suggestions (documentations is enough?), but I think > Spring support for XWT start to be stable. It is works fine for me. I think we can start to integrate in CVS. As for the documentations, I think we need to list the purpose of this integration by iterating all benefices.
(In reply to comment #78) > (In reply to comment #77) > > > > Yves I have attached a new patch. Could you retest please. I have updated my > > doc to explain how use lazy model with SPringCLRFactory and explain how use > > "Validate Bundles", "Add Required Bundles" for the launch. > > > > I'm waiting for your tests/suggestions (documentations is enough?), but I think > > Spring support for XWT start to be stable. > > It is works fine for me. I think we can start to integrate in CVS. > > As for the documentations, I think we need to list the purpose of this > integration by iterating all benefices. OK Hi Yves, I would like improve SpringCLRFactory for the bean declaration in the x:ClassFactory. On other words I would like give the capability to set the bean parameter as optionnal to write this : x:ClassFactory="org.eclipse.e4.xwt.springframework.SpringCLRFactory.INSTANCE" and not write this : x:ClassFactory="org.eclipse.e4.xwt.springframework.SpringCLRFactory.INSTANCE bean=Hello" My idea is used the file name Hello.xwt to retrieve the bean name Hello. I have studied how do that and it works in my workspace. I had to change org.eclipse.e4.xwt bundle to manage this case. So now I have this signature : ------------------------------------------------------------ public interface ICLRFactory { Object createCLR(String args, Map<String, Object> options); } ------------------------------------------------------------ The options comes from XWT. After I had a new property in IXWTLoader : ------------------------------------------------------------ public interface IXWTLoader { // Properties /** * The URL which open XWT file * */ String URL_PROPERTY = "XWT.URL"; String[] ALL_PROPERTIES = { URL_PROPERTY, CONTAINER_PROPERTY, INIT_STYLE_PROPERTY, DATACONTEXT_PROPERTY, BINDING_CONTEXT_PROPERTY, RESOURCE_DICTIONARY_PROPERTY, CLASS_PROPERTY, CLASS_FACTORY_PROPERTY, LOADED_CALLBACK, CREATED_CALLBACK, BEFORE_PARSING_CALLBACK, DESIGN_MODE_PROPERTY}; ------------------------------------------------------------ I have modified XWTLoader#prepareOptions(Map<String, Object> options) to set the URL as parameter and it to the options : ------------------------------------------------------------ protected Map<String, Object> prepareOptions(Map<String, Object> options, URL url) { .... // Register URL property if (options == Collections.EMPTY_MAP) { options = new HashMap<String, Object>(); } options.put(URL_PROPERTY, url); } ------------------------------------------------------------ So after in my SpringCLRFactory, I can use options to get the URL and compute (if bean parameter is not filled) the bean name (ex : URl=C:/Hello.xwt, my bean value is Hello). I think it can be a cool feature : * bean name follow the same name than XWT file. * les declaration to do. I'm sorry I can not do today a patch with my work (I cannot connect to CVS today), but tell me if you like this idea and I will send you a patch (or if you like it, you can do it). At end I think it should be cool if we can have package name to the options to use the same logic than Spring and define a ClassCLRFactory wich use teh XWT file name + package name.
(In reply to comment #72) > ---------------------------------------------------- > public static void main(String[] args) { > > new Thread() { > @Override > public void run() { > > URL url = CLRFactoryNamespace.class > .getResource(CLRFactoryNamespace.class.getSimpleName() > + IConstants.XWT_EXTENSION_SUFFIX); > try { > XWT.open(url); > } catch (Exception e) { > e.printStackTrace(); > } > } > }.start(); > > new Thread() { > @Override > public void run() { > > URL url = CLRFactoryNamespace.class > .getResource(CLRFactoryNamespace.class.getSimpleName() > + IConstants.XWT_EXTENSION_SUFFIX); > try { > XWT.open(url); > } catch (Exception e) { > e.printStackTrace(); > } > } > }.start(); > } > > ---------------------------------------------------- The multiple displays are not supported on Mac OS and Linux. There is a problem on those platforms
(In reply to comment #80) > The multiple displays are not supported on Mac OS and Linux. There is a problem > on those platforms I have implemented the mono display for multi threading. It works well on Linux. But SWT on MacOS has another specificity: The SWT thread must be the Main thread. This makes an addtion work on the Spring Integration. We need to initialize XWT in the main thread. Please check out the testcase.
(In reply to comment #79) > Hi Yves, > > I would like improve SpringCLRFactory for the bean declaration in the > x:ClassFactory. On other words I would like give the capability to set the bean > parameter as optionnal to write this : > > x:ClassFactory="org.eclipse.e4.xwt.springframework.SpringCLRFactory.INSTANCE" > > and not write this : > > x:ClassFactory="org.eclipse.e4.xwt.springframework.SpringCLRFactory.INSTANCE > bean=Hello" > > My idea is used the file name Hello.xwt to retrieve the bean name Hello. > > I have studied how do that and it works in my workspace. I had to change > org.eclipse.e4.xwt bundle to manage this case. So now I have this signature : > > ------------------------------------------------------------ > public interface ICLRFactory { > Object createCLR(String args, Map<String, Object> options); > } > ------------------------------------------------------------ > > The options comes from XWT. > > After I had a new property in IXWTLoader : > > > ------------------------------------------------------------ > public interface IXWTLoader { > // Properties > > /** > * The URL which open XWT file > * > */ > String URL_PROPERTY = "XWT.URL"; > > String[] ALL_PROPERTIES = { URL_PROPERTY, > CONTAINER_PROPERTY, > INIT_STYLE_PROPERTY, > DATACONTEXT_PROPERTY, > BINDING_CONTEXT_PROPERTY, > RESOURCE_DICTIONARY_PROPERTY, > CLASS_PROPERTY, > CLASS_FACTORY_PROPERTY, > LOADED_CALLBACK, > CREATED_CALLBACK, > BEFORE_PARSING_CALLBACK, > DESIGN_MODE_PROPERTY}; > > > ------------------------------------------------------------ > > I have modified XWTLoader#prepareOptions(Map<String, Object> options) to set > the URL as parameter and it to the options : > > ------------------------------------------------------------ > > protected Map<String, Object> prepareOptions(Map<String, Object> options, URL > url) { > .... > // Register URL property > if (options == Collections.EMPTY_MAP) { > options = new HashMap<String, Object>(); > } > options.put(URL_PROPERTY, url); > } > ------------------------------------------------------------ > > So after in my SpringCLRFactory, I can use options to get the URL and compute > (if bean parameter is not filled) the bean name (ex : URl=C:/Hello.xwt, my bean > value is Hello). > > I think it can be a cool feature : > > * bean name follow the same name than XWT file. > * les declaration to do. > > I'm sorry I can not do today a patch with my work (I cannot connect to CVS > today), but tell me if you like this idea and I will send you a patch (or if > you like it, you can do it). Please make a patch, I'll look at it. > > At end I think it should be cool if we can have package name to the options to > use the same logic than Spring and define a ClassCLRFactory wich use teh XWT > file name + package name. Sorry, I didn't get your point.
Created attachment 176969 [details] Samples + ICLRFactory Patched to get Map options in the ICLRFactory#createCLR Yves, You will find in this zip 2 patches : * org.eclipse.e4.xwt.patch which : ** set the Map options in the ICLRFactory#createCLR(String arg, Map<String, Object> options) ** register the URL in the options as XWT.URL key. * org.eclipse.e4.xwt.tests.patch to compile. I have added a new interface IBeanNameProvider : -------------------------------------------------- public interface IBeanNameProvider { /** * Returns the Spring bean name from the XWT file {@link URL}. * * @param url * XWT file {@link URL}. * @return Spring bean name. */ String getBeanName(URL url); } -------------------------------------------------- SpringCLRFactory use this feature and I can use (if IBeanNameProvider is filled) the XWT file name for the bean name : * please see org.eclipse.e4.xwt.springframework.sample5 in NO OSGi context. You have : protected MySpringCLRFactory() { super.setBeanNameProvider(DefaultBeanNameProvider.INSTANCE); } * please see org.eclipse.e4.xwt.springframework.osgi.sample5 in OSGi context, you have a fragment org.eclipse.e4.xwt.springframework.osgi.sample5.config.springclrfactory which set the IBeanNameProvider to the SpringCLRFactory. I think IBeanNameProvider could be moved to the XWT Core (name should be just changed). We could provide a CLRClassFactory which use I???NameProvider to retrieve the className from the XWT file name. So we could write just : <Shell xmlns="http://www.eclipse.org/xwt/presentation" xmlns:x="http://www.eclipse.org/xwt" x:ClassFactory="org.eclipse.e4.xwt.CLRClassFactory.INSTANCE"> And this factory retrieve the class name by using the XWT file name. There are just package name problem, I don't know how we could retrieve it.
(In reply to comment #81) > (In reply to comment #80) > > The multiple displays are not supported on Mac OS and Linux. There is a problem > > on those platforms > I have implemented the mono display for multi threading. It works well on > Linux. But SWT on MacOS has another specificity: The SWT thread must be the > Main thread. This makes an addtion work on the Spring Integration. We need to > initialize XWT in the main thread. Please check out the testcase. Yves, could you explain me more please. What I must to do? I have noticed that I have a problem when I close XWT window in OSGi context (when XWT.setCLRFactory is called in the Activator). For instance launch sample4. XWT is opened. Close it and you will have : ----------------------------------------------------------------------- org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.SWT.error(SWT.java:3969) at org.eclipse.swt.widgets.Display.error(Display.java:1249) at org.eclipse.swt.widgets.Display.checkDevice(Display.java:755) at org.eclipse.swt.widgets.Display.getShells(Display.java:2171) at org.eclipse.e4.xwt.XWTLoader$1$1.widgetDisposed(XWTLoader.java:804) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:123) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1058) at org.eclipse.swt.widgets.Widget.release(Widget.java:808) at org.eclipse.swt.widgets.Widget.dispose(Widget.java:446) at org.eclipse.swt.widgets.Decorations.dispose(Decorations.java:447) at org.eclipse.swt.widgets.Shell.dispose(Shell.java:714) at org.eclipse.swt.widgets.Decorations.closeWidget(Decorations.java:309) at org.eclipse.swt.widgets.Decorations.WM_CLOSE(Decorations.java:1665) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4162) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1598) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2038) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2454) at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:497) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4251) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1598) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2038) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2454) at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:497) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4251) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1598) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2038) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2459) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3655) at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:812) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:793) at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:742) at org.eclipse.e4.xwt.XWT.open(XWT.java:416) at org.eclipse.e4.xwt.springframework.osgi.sample4.Activator$1.run(Activator.java:50) -----------------------------------------------------------------------
(In reply to comment #84) > Yves, could you explain me more please. What I must to do? I have noticed that > I have a problem when I close XWT window in OSGi context (when > XWT.setCLRFactory is called in the Activator). For instance launch sample4. XWT > is opened. Close it and you will have : We need to test our integration on Linux and Mac OS since they don't multi displays: one thread to one Display. And furthermore, on Mac OS (cocoa) the Display thread must be the main thread. > > ----------------------------------------------------------------------- > org.eclipse.swt.SWTException: Invalid thread access > at org.eclipse.swt.SWT.error(SWT.java:4083) > at org.eclipse.swt.SWT.error(SWT.java:3998) > at org.eclipse.swt.SWT.error(SWT.java:3969) > at org.eclipse.swt.widgets.Display.error(Display.java:1249) > at org.eclipse.swt.widgets.Display.checkDevice(Display.java:755) > at org.eclipse.swt.widgets.Display.getShells(Display.java:2171) > at org.eclipse.e4.xwt.XWTLoader$1$1.widgetDisposed(XWTLoader.java:804) > at > org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:123) > at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1058) > at org.eclipse.swt.widgets.Widget.release(Widget.java:808) > at org.eclipse.swt.widgets.Widget.dispose(Widget.java:446) > at org.eclipse.swt.widgets.Decorations.dispose(Decorations.java:447) > at org.eclipse.swt.widgets.Shell.dispose(Shell.java:714) > at org.eclipse.swt.widgets.Decorations.closeWidget(Decorations.java:309) > at org.eclipse.swt.widgets.Decorations.WM_CLOSE(Decorations.java:1665) > at org.eclipse.swt.widgets.Control.windowProc(Control.java:4162) > at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) > at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1598) > at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2038) > at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873) > at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) > at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2454) > at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:497) > at org.eclipse.swt.widgets.Control.windowProc(Control.java:4251) > at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) > at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1598) > at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2038) > at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873) > at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) > at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2454) > at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:497) > at org.eclipse.swt.widgets.Control.windowProc(Control.java:4251) > at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) > at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1598) > at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2038) > at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873) > at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) > at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2459) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3655) > at org.eclipse.e4.xwt.XWTLoader$1.run(XWTLoader.java:812) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:793) > at org.eclipse.e4.xwt.XWTLoader.open(XWTLoader.java:742) > at org.eclipse.e4.xwt.XWT.open(XWT.java:416) > at > org.eclipse.e4.xwt.springframework.osgi.sample4.Activator$1.run(Activator.java:50) It is fixed and committed.
Could you commit the bundles in e4/XWT since you are the e4 commiter? I suppose if I don't it, all patches must be passed thru IP. Please put org.eclipse.e4.xwt.springframework in e4/org.eclipse.e4.xwt/bundles/ a,d all others samples in e4/org.eclipse.e4.xwt/examples/ It will be helpful to work together.
You need to rename ui.xwt to UI.xwt since on other platforms, file name is case sensitive.
Created attachment 176985 [details] Spring support for XWT - Sample with lazy mode: Porting on linux I have tested on Linux. There are several modification: 1. Rename all XWT files from ui.xwt to UI.xwt 2. Add a display thread for linux in Activator of org.eclipse.e4.xwt.springframework 3. Add a method XWT.waitForStarted() to make sure the XWT gets started by the Display thread 4. Add the call XWT.waitForStarted() on each application bundles
(In reply to comment #88) > Created an attachment (id=176985) [details] > Spring support for XWT - Sample with lazy mode: Porting on linux > > I have tested on Linux. There are several modification: > 1. Rename all XWT files from ui.xwt to UI.xwt > 2. Add a display thread for linux in Activator of > org.eclipse.e4.xwt.springframework > 3. Add a method XWT.waitForStarted() to make sure the XWT gets started by > the Display thread > 4. Add the call XWT.waitForStarted() on each application bundles But there a problem with Mac OS. The Main thread must be the Display thread. We need to start XWT in Main Thread. Could you indicate how to do it with Spring?
(In reply to comment #88) > Created an attachment (id=176985) [details] > Spring support for XWT - Sample with lazy mode: Porting on linux > Yves I have everything commited in CVS. I have Rename all XWT files from ui.xwt to UI.xwt. I'm modifying Wiki to explain how get projects from CVS + explain teh new feature with lazy bean declaration. I think it should be more easy for us to modify the Spring support for XWT. > I have tested on Linux. There are several modification: > 1. Rename all XWT files from ui.xwt to UI.xwt Done. > 2. Add a display thread for linux in Activator of > org.eclipse.e4.xwt.springframework > 3. Add a method XWT.waitForStarted() to make sure the XWT gets started by > the Display thread > 4. Add the call XWT.waitForStarted() on each application bundles Could you do the changes? Tell me if you need help.
(In reply to comment #90) > (In reply to comment #88) > > Created an attachment (id=176985) [details] [details] > > Spring support for XWT - Sample with lazy mode: Porting on linux > > > > Yves I have everything commited in CVS. I have Rename all XWT files from ui.xwt > to UI.xwt. I'm modifying Wiki to explain how get projects from CVS + explain > teh new feature with lazy bean declaration. > > I think it should be more easy for us to modify the Spring support for XWT. > > > > I have tested on Linux. There are several modification: > > 1. Rename all XWT files from ui.xwt to UI.xwt > Done. > > 2. Add a display thread for linux in Activator of > > org.eclipse.e4.xwt.springframework > > 3. Add a method XWT.waitForStarted() to make sure the XWT gets started by > > the Display thread > > 4. Add the call XWT.waitForStarted() on each application bundles > > Could you do the changes? Tell me if you need help. I think it's not linked to Spring. It's the Activator of the bundle org.eclipse.e4.xwt.springframework which call XWT.setCLRFactory. See line 125 of the class org.eclipse.e4.xwt.springframework.internal.Activator
(In reply to comment #90) > > Could you do the changes? Tell me if you need help. It is committed.
(In reply to comment #92) > (In reply to comment #90) > > > > Could you do the changes? Tell me if you need help. > It is committed. Thank a lot! I have modified a little your code about the Activator (please synchronise you). I have finished the nwiki and explain how get bunldes+samples from CVS + explain how use XWT file name as a bean name.
(In reply to comment #91) > > I think it's not linked to Spring. It's the Activator of the bundle > org.eclipse.e4.xwt.springframework which call XWT.setCLRFactory. See line 125 > of the class org.eclipse.e4.xwt.springframework.internal.Activator Yes, but it is linked to the execution context of Spring. I have modified it for Linux porting. For Mac OS, all stuffs about XWT invoked in org.eclipse.e4.xwt.springframework.internal.Activator must be done in Main Thread.
(In reply to comment #94) > (In reply to comment #91) > > > > I think it's not linked to Spring. It's the Activator of the bundle > > org.eclipse.e4.xwt.springframework which call XWT.setCLRFactory. See line 125 > > of the class org.eclipse.e4.xwt.springframework.internal.Activator > > Yes, but it is linked to the execution context of Spring. I have modified it > for > Linux porting. For Mac OS, all stuffs about XWT invoked in > org.eclipse.e4.xwt.springframework.internal.Activator must be done in Main > Thread. Yves it's very difficult for me to help you with Thread problem (I'm not very good in this domain). I know that Spring DM use extender pattern to load XML Spring file (there is a bundle which observe each start/end of bundles and check if there are META-INF/.spring folder to load XML Spring file). I don't know if it will help you? I have noticed that you call -------------------------------- XWT.waitForStarted(); -------------------------------- I have started to call with that at http://wiki.eclipse.org/Using_Spring_with_XWT#Activator.23start You will se a comment "TODO : yves could you explain that???? " Could you modify the wiki to explain it. Thanks
(In reply to comment #95) > (In reply to comment #94) > > (In reply to comment #91) > > > > > > I think it's not linked to Spring. It's the Activator of the bundle > > > org.eclipse.e4.xwt.springframework which call XWT.setCLRFactory. See line 125 > > > of the class org.eclipse.e4.xwt.springframework.internal.Activator > > > > Yes, but it is linked to the execution context of Spring. I have modified it > > for > > Linux porting. For Mac OS, all stuffs about XWT invoked in > > org.eclipse.e4.xwt.springframework.internal.Activator must be done in Main > > Thread. > > Yves it's very difficult for me to help you with Thread problem (I'm not very > good in this domain). I know that Spring DM use extender pattern to load XML > Spring file (there is a bundle which observe each start/end of bundles and > check if there are META-INF/.spring folder to load XML Spring file). I don't > know if it will help you? > > I have noticed that you call > > -------------------------------- > XWT.waitForStarted(); > -------------------------------- > > I have started to call with that at > > http://wiki.eclipse.org/Using_Spring_with_XWT#Activator.23start > > You will se a comment "TODO : yves could you explain that???? " Could you > modify the wiki to explain it. Thanks Yves there are a problem with XWT.waitForStarted(); with sample1* to sample3* : XWT file is never opened because defaultXWTLoader is already null because in this case XWT.setCLRFactory is never called. So XWT.waitForStarted(); must be called only for sample4 and sample5 (which use default SpringCLRFactory). Are you OK with that?
(In reply to comment #96) > (In reply to comment #95) > > (In reply to comment #94) > > > (In reply to comment #91) > > > > > > > > I think it's not linked to Spring. It's the Activator of the bundle > > > > org.eclipse.e4.xwt.springframework which call XWT.setCLRFactory. See line 125 > > > > of the class org.eclipse.e4.xwt.springframework.internal.Activator > > > > > > Yes, but it is linked to the execution context of Spring. I have modified it > > > for > > > Linux porting. For Mac OS, all stuffs about XWT invoked in > > > org.eclipse.e4.xwt.springframework.internal.Activator must be done in Main > > > Thread. > > > > Yves it's very difficult for me to help you with Thread problem (I'm not very > > good in this domain). I know that Spring DM use extender pattern to load XML > > Spring file (there is a bundle which observe each start/end of bundles and > > check if there are META-INF/.spring folder to load XML Spring file). I don't > > know if it will help you? > > > > I have noticed that you call > > > > -------------------------------- > > XWT.waitForStarted(); > > -------------------------------- > > > > I have started to call with that at > > > > http://wiki.eclipse.org/Using_Spring_with_XWT#Activator.23start > > > > You will se a comment "TODO : yves could you explain that???? " Could you > > modify the wiki to explain it. Thanks > > Yves there are a problem with > > XWT.waitForStarted(); with sample1* to sample3* : XWT file is never opened > because defaultXWTLoader is already null because in this case XWT.setCLRFactory > is never called. > > So XWT.waitForStarted(); must be called only for sample4 and sample5 (which use > default SpringCLRFactory). Are you OK with that? You are using XWT.waitForStarted(); in order the Activator org.eclipse.e4.xwt.springframework intialize the first the XWTLoader. I think it can be awfull to set this code in your whole project. Why don't specify in the wiki to start the bundel org.eclipse.e4.xwt.springframework BEFORE the other bundles wich use XWT file?
(In reply to comment #97) > > So XWT.waitForStarted(); must be called only for sample4 and sample5 (which use > > default SpringCLRFactory). Are you OK with that? > I'm fine with it. > You are using XWT.waitForStarted(); in order the Activator > org.eclipse.e4.xwt.springframework intialize the first the XWTLoader. I think > it can be awfull to set this code in your whole project. > We cannot. since we don't know who is the display thread. > Why don't specify in the wiki to start the bundel > org.eclipse.e4.xwt.springframework BEFORE the other bundles wich use XWT file? It is not enough because org.eclipse.e4.xwt.springframework start a new thread to initialize XWTLoader. Even the Bundle thread is over, we are not sure XWTLoader gets initialized.
(In reply to comment #98) > (In reply to comment #97) > > > So XWT.waitForStarted(); must be called only for sample4 and sample5 (which use > > > default SpringCLRFactory). Are you OK with that? > > > > I'm fine with it. > But I prefer to call XWT.waitForStarted() as a convention.
(In reply to comment #96) > > Yves there are a problem with > > XWT.waitForStarted(); with sample1* to sample3* : XWT file is never opened > because defaultXWTLoader is already null because in this case XWT.setCLRFactory > is never called. Please sync with the last modifications in XWT. It works fine in my env. > > So XWT.waitForStarted(); must be called only for sample4 and sample5 (which use > default SpringCLRFactory). Are you OK with that?
(In reply to comment #100) > (In reply to comment #96) > > > > Yves there are a problem with > > > > XWT.waitForStarted(); with sample1* to sample3* : XWT file is never opened > > because defaultXWTLoader is already null because in this case XWT.setCLRFactory > > is never called. > > Please sync with the last modifications in XWT. It works fine in my env. Yes I have synchronized. For the sampel4 it works well but not with sample1. Have tried to launch the sample1? This launch call NEVER XWT.setCLRFactory(SpringCLRFactory.INSTANCE), so XWT.waitForStarted() loop for every time. > > > > > So XWT.waitForStarted(); must be called only for sample4 and sample5 (which use > > default SpringCLRFactory). Are you OK with that?
(In reply to comment #101) > > Yes I have synchronized. > For the sampel4 it works well but not with sample1. > > Have tried to launch the sample1? This launch call NEVER > XWT.setCLRFactory(SpringCLRFactory.INSTANCE), so XWT.waitForStarted() loop for > every time. > OK, I debug it. In my env, the lazy is true for sample1. It seems we have to add one condition line before calling XWT.waitForStarted(): if (lazy) { XWT.waitForStarted(); }
(In reply to comment #102) > OK, I debug it. In my env, the lazy is true for sample1. > > It seems we have to add one condition line before calling > XWT.waitForStarted(): > > if (lazy) { > XWT.waitForStarted(); > } I have added a class XWTSpring for this purpose. From the application bundle, we can call XWTSpring.waitForStarted(); Please check it.
Created attachment 177058 [details] Patch for using only XWT#waitForStarted() Yves, I find it's shame to have XWTSpring.waitForStarted() using. I have thought how we could use only XWT.waitForStarted(). I send you a patch to explain more my idea. In this 2 patches you will find 3 features : 1. XWT#runWithSWTDisplay(Runnable runnable) : I have moved your code with SWT Platform -------------------- String platform = SWT.getPlatform(); if (platform.startsWith("win")) { ... -------------------- from the SpringCLRFactory Activator to the XWT class. I find code is more clean and this method could be used into another case. So the code of the Activator is : -------------------- if (lazy) { XWT.runWithSWTDisplay(new Runnable() { public void run() { // Set default XWT ICLRFactory setDefaultCLRFactory(); } }); } -------------------- 2. IXWTIntializer To use only XWT.waitForStarted(), I have introduced IXWTInitializer interface : -------------------- package org.eclipse.e4.xwt; public interface IXWTInitializer { boolean isInitialized(); } -------------------- The SpringCLRFactory Activator implement this class and manage an internal intitialized flag in the start method. The initialized flag is set to true * when start method is finished (only if !lazy) * after when XWT.setCLRFactory(SpringCLRFactory.INSTANCE); is called. You can add IXWTInitializer instance with XWT#ddXWTInitializer(IXWTInitializer initializer) : ---------------------------------- public static void addXWTInitializer(IXWTInitializer initializer) { if (initializers == null) { initializers = new ListenerList(); } initializers.add(initializer); } ---------------------------------- The SpringCLRFactory Activator use this method to add the Activator as IXWTInitializer. XWT#waitForStarted don't use XWTLoaderManager#isStarted() but loop for each IXWTInitializer to know if intializer is finished or not. It manage too the case of the Thread for gtk. 3.XWT Core Activator Problem that we have comes from with the call of XWTLoaderManager#getDefault() (is the SpringCLRFactory which call the first time or another sample bundle?). I tell me why don't create an Activator on org.eclipse.e4.xwt bundle and on start it call XWTLoaderManager.getDefault();. I have do that on the Activator of the XWT Core : ---------------------------------- public void start(BundleContext context) throws Exception { initialized = false; XWT.addXWTInitializer(this); XWT.runWithSWTDisplay(new Runnable() { public void run() { try { XWTLoaderManager.getDefault(); } finally { initialized = true; } } }); } ---------------------------------- If we can do that, the code of the SPringCLKRFactory Activator can be changed (it doesn't manage IXWTInitializer). More we could have just a static variable for the initializer, because it"s just the XWT COre wich initialize XWTLoaderManager.getDefault(); At end I tell me, if XWT#waitForStarted should be called internally in the XWT#open. No? Hope you will like this idea. I don't have comments my code, but if you wish apply some piece of code of the patch, I will (or you?) add comments.
(In reply to comment #104) > Created an attachment (id=177058) [details] > Patch for using only XWT#waitForStarted() > > Yves, > > I find it's shame to have XWTSpring.waitForStarted() using. I have thought how > we could use only XWT.waitForStarted(). I send you a patch to explain more my > idea. > > In this 2 patches you will find 3 features : > > 1. XWT#runWithSWTDisplay(Runnable runnable) : > I have moved your code with SWT Platform > > -------------------- > String platform = SWT.getPlatform(); > if (platform.startsWith("win")) { > ... > -------------------- > > from the SpringCLRFactory Activator to the XWT class. I find code is more clean > and this method could be used into another case. So the code of the Activator > is : > > -------------------- > if (lazy) { > XWT.runWithSWTDisplay(new Runnable() { > public void run() { > // Set default XWT ICLRFactory > setDefaultCLRFactory(); > } > }); > } > -------------------- > > 2. IXWTIntializer > > To use only XWT.waitForStarted(), I have introduced IXWTInitializer interface : > > -------------------- > > package org.eclipse.e4.xwt; > > public interface IXWTInitializer { > > boolean isInitialized(); > } > -------------------- > > > The SpringCLRFactory Activator implement this class and manage an internal > intitialized flag in the start method. The initialized flag is set to true > * when start method is finished (only if !lazy) > * after when XWT.setCLRFactory(SpringCLRFactory.INSTANCE); is called. > > You can add IXWTInitializer instance with XWT#ddXWTInitializer(IXWTInitializer > initializer) : > > ---------------------------------- > public static void addXWTInitializer(IXWTInitializer initializer) { > if (initializers == null) { > initializers = new ListenerList(); > } > initializers.add(initializer); > } > > ---------------------------------- > > The SpringCLRFactory Activator use this method to add the Activator as > IXWTInitializer. > > XWT#waitForStarted don't use XWTLoaderManager#isStarted() but loop for each > IXWTInitializer to know if intializer is finished or not. It manage too the > case of the Thread for gtk. > > 3.XWT Core Activator > > Problem that we have comes from with the call of XWTLoaderManager#getDefault() > (is the SpringCLRFactory which call the first time or another sample bundle?). > I tell me why don't create an Activator on org.eclipse.e4.xwt bundle > and on start it call XWTLoaderManager.getDefault();. I have do that on the > Activator of the XWT Core : > > ---------------------------------- > > public void start(BundleContext context) throws Exception { > initialized = false; > XWT.addXWTInitializer(this); > XWT.runWithSWTDisplay(new Runnable() { > > public void run() { > try { > XWTLoaderManager.getDefault(); > } finally { > initialized = true; > } > } > }); > > } > ---------------------------------- > > If we can do that, the code of the SPringCLKRFactory Activator can be changed > (it doesn't manage IXWTInitializer). More we could have just a static variable > for the initializer, because it"s just the XWT COre wich initialize > XWTLoaderManager.getDefault(); > > At end I tell me, if XWT#waitForStarted should be called internally in the > XWT#open. No? > > Hope you will like this idea. I don't have comments my code, but if you wish > apply some piece of code of the patch, I will (or you?) add comments. By now, we have introduced too much stuffs. We should keep the API simple. I think I'll take some time to analyze all impacts.
(In reply to comment #105) > (In reply to comment #104) > > > > Hope you will like this idea. I don't have comments my code, but if you wish > > apply some piece of code of the patch, I will (or you?) add comments. > > By now, we have introduced too much stuffs. We should keep the API simple. I > think I'll take some time to analyze all impacts. I have committed the codes with some minor modifications.
(In reply to comment #106) > (In reply to comment #105) > > (In reply to comment #104) > > > > > > Hope you will like this idea. I don't have comments my code, but if you wish > > > apply some piece of code of the patch, I will (or you?) add comments. > > > > By now, we have introduced too much stuffs. We should keep the API simple. I > > think I'll take some time to analyze all impacts. > > I have committed the codes with some minor modifications. Thank a lot Yves! I have clean SpringCLRFactory to : 1. remove XWTSpring from org.eclipse.e4.xwt.springframework 2. remove the SWT dependency from org.eclipse.e4.xwt.springframework 3. use XWT.waitForInitialization(); in the OSGi samples instead of using SWTSpring. 4.Remove org.eclipse.e4.xwt.springframework dependency from the org.eclipse.e4.xwt.springframework* OSGi samples. Please synchronize to the whole org.eclipse.e4.xwt.springframework.* projects Now I think it should be better to call XWT.waitForInitialization(); into the XWT.open() in order to avoid calling this method in the Activator. I have tried that in OSGi + NO OSGi env and it works well in Windows OS. What do you think?
(In reply to comment #107) > Thank a lot Yves! > I have clean SpringCLRFactory to : > 1. remove XWTSpring from org.eclipse.e4.xwt.springframework > 2. remove the SWT dependency from org.eclipse.e4.xwt.springframework > 3. use XWT.waitForInitialization(); in the OSGi samples instead of using > SWTSpring. > 4.Remove org.eclipse.e4.xwt.springframework dependency from the > org.eclipse.e4.xwt.springframework* OSGi samples. > Please synchronize to the whole org.eclipse.e4.xwt.springframework.* projects > Now I think it should be better to call XWT.waitForInitialization(); into the > XWT.open() in order to avoid calling this method in the Activator. I have tried > that in OSGi + NO OSGi env and it works well in Windows OS. > What do you think? Here is my modifications: 1. rename waitForInitialization to checkInitialization() 2. add the call on all XWT.open(). But keep in mind, this method must be called on first before other methods of XWT. Please update all org.eclipse.e4.xwt.springframework.* projects.
(In reply to comment #108) > (In reply to comment #107) > > Thank a lot Yves! > > I have clean SpringCLRFactory to : > > 1. remove XWTSpring from org.eclipse.e4.xwt.springframework > > 2. remove the SWT dependency from org.eclipse.e4.xwt.springframework > > 3. use XWT.waitForInitialization(); in the OSGi samples instead of using > > SWTSpring. > > 4.Remove org.eclipse.e4.xwt.springframework dependency from the > > org.eclipse.e4.xwt.springframework* OSGi samples. > > Please synchronize to the whole org.eclipse.e4.xwt.springframework.* projects > > Now I think it should be better to call XWT.waitForInitialization(); into the > > XWT.open() in order to avoid calling this method in the Activator. I have tried > > that in OSGi + NO OSGi env and it works well in Windows OS. > > What do you think? > > Here is my modifications: > 1. rename waitForInitialization to checkInitialization() > 2. add the call on all XWT.open(). > But keep in mind, this method must be called on first before other methods > of XWT. > Please update all org.eclipse.e4.xwt.springframework.* projects. Thank's Yves, I have commited all org.eclipse.e4.xwt.springframework.* projects and it works well.
It is committed by Angelo ZERR. I have checked.
