Re: [riena-dev] still problems to use 1.2 (M1 or HEAD) REASON FOUND :-)

[Elias Volanakis <elias@xxxxxxxxxxxxxxxxx>]

Hi Christian,

I agree that doing this as late as possible is good.

However this line will cause an exception:

ColorLnfResource:
   return new Color(null, rgb);
                           ^^^^
Color.java:
  public Color (Device device, RGB rgb) {
	super(device);
	if (rgb == null) SWT.error(SWT.ERROR_NULL_ARGUMENT);
[...]

Kind regards,
Elias.

On Tue, Sep 22, 2009 at 3:23 AM, Christian Campo
<christian.campo@xxxxxxxxxxxx> wrote:
> after some further testing and investigation I changed the two renderers in
> question EmbeddedTitlebarRenderer and SubApplicationTabRenderer so that they
> access the ColorRessource only once they need it. Further RienaLnF was
> changed to create "black" and "white" only pretty late (not in init, but in
> the first access to getColor).
> So i think the lesson learned is that we should access Ressource that
> require Display like Color only as late as possible to give the workbench a
> chance to exist.
> I also replaced the ColorLnfResource code to supply a null Display to the
> Color constructor.
> public Resource createResource() {
> if (rgb == null) {
> return null;
> }
> return new Color(null, rgb);
>         }
> So Color can figure out the Display.
> Ekke's code is running, the SWT Example Client of Riena is running and the
> two testcases mentioned by Steffen are running.....
> christian
> Am 22.09.2009 um 09:13 schrieb ekke:
>
> Christian Campo schrieb:
>
> Ekke,
> I am not sure why the current solution to check whether the Workbench is
> running and then decide does not please everyone......
> if (PlatformUI.isWorkbenchRunning()) {
> return new Color(PlatformUI.getWorkbench().getDisplay(), rgb);
> } else {
> return new Color(Display.getCurrent(), rgb);
> }
> That code should work for testcases and for the Ekke and certainly for the
> SWT Example Application......
>
> I also think that this code should work in all cases, but I'm not the SWT
> expert to know what's recommended
>
> ...but this change only avoids some errors -  not the problem that creating
> Color resources
> in 1.2 still creates the Display too early in DS ResolveComponents Thread
> perhaps I can use Elias idea to dispose this Display I don't want
> ...but at first I'm interested to hear if these changes in 1.2 are really
> needed by Riena
>
> ekke
>
> Of the two testcases pointed out by Steffen, ChoiceCompositeTest runs with
> this current code and ComboRidgetTest has two failures which are unrelated
> to this change (they also happen with the old version).
> +1 for keeping the code as it is now....
>
> christian
> Am 22.09.2009 um 08:03 schrieb ekke:
>
> Hi Elias,
>
> Elias Volanakis schrieb:
>
> Hi ekke,
>
> I agree with Steffen - i.e. it would be best to revert the change.
>
>
> ...one shouldn't change things on a sonday ... tired after hours of
> debugging ;-)
>
> Actually, I think Display.getCurrent() is not problematic -- this will
> return null when called from a non-UI thread and fail -- which is
> acceptable from my POV. I.e. if one is trying to create UI things,
> such as Colors from a non-ui thread, it means trouble in any case.
>
> What I pointed out as a bad practice in my original mail was
> Display.getDefault() -- because this will create the one-and-only
> Display if called from a non-ui thread, instead of returning null.
> This typically makes the code work in that thread, but creates
> problems later.
>
>
> thanks again for making things clear
>
> @ekke: I think the key for fixing this is to find out where/how
> Displays are created. Could attach stack traces for each display
> creation to the bug? Setting a breakpoint in Display should help
> pinpoint this.
>
>
> I have done this - and so found out that from DS Thread UI Access was needed
> from ColorLnfResource while creating a resource
>
> Some random thoughts: (a) if you need a display before the Application
> launches you might be able to create one and the dispose it (for the
> login). However, I'm not sure how this will work with potentially
> cached resources (i.e. LnF colors, etc). (b) If you need UI access
> from declarative services, how to you obtain the display?
>
>
> I don't need UI Access from DS - and using Riena 1.1 it works well -
> using 1.2 Riena needs UI Access while resolving my DS
> (where I instantiate some LnF classes extending RienaDefaultLnf,
> but where I don't need resources)
>
> ...exactly the same code is used from my site, at the time the first Display
> is created,
> excactly the same bundles from Riena with the same state are running.
>
> to avoid problems from LoginView I started the app without LoginView - same
> happens
>
> Analyzing the stack where the 1st Display was created, finally I found the
> reason !
>
> RienaDefaultLnf.getTheme() in 1.1 needs no access to UI Thread
> but in 1.2 there's a difference:
>
> while initialize()
> initWidgetRendererDefaults() was called
>
> then SubApplicationTabRenderer was initialized
> and there in 1.2 was new:
> DEFAULT_COLOR = LnfManager.getLnf().getColor("black");
> this results in.... ColorLnfResource.createResource
>
> same happens in EmbeddedTitlebarRenderer
>
> also the next method from initializing: initColorDefaults()
> ... in 1.2 there are new lines added:
>
> getResourceTable().put("black", new ColorLnfResource(0, 0, 0));
> //$NON-NLS-1$
> getResourceTable().put("white", new ColorLnfResource(255, 255, 255));
> //$NON-NLS-1$
>
> and these calls are the reason !
> so it wasn't the Display.getCurrent() - the reason is the creation of
> ColorLnfResources
> while initializing
>
> in 1.1 Resources are created later
>
> I did a test and commented out the creation of ColorLnfResources in:
>
> SubApplicationTabRenderer
> EmbeddedTitlebarRenderer
> RienaDefaultLnf#initColorDefaults()
>
> now my appliction runs under 1.2 same as under 1.1
> but I dont know why this was added and if there's a way to avoid creation of
> resources so early
>
> also tried with LoginView - the View comes up (with some problems - but this
> is work for flo,
> to finish changes to use new DialogView)
>
> so my question: is there a way to avoid creation of Color Resources while
> initializing ?
> if not, I have to rethink my LnF implementation, but this will take time -
> so perhaps I have
> to stay with 1.1 for next 2 months
>
> ekke
>
> Kind regards,
> Elias.
>
>
>
> On Mon, Sep 21, 2009 at 2:42 AM, ekke <ekke@xxxxxxxxxxxxxxxx> wrote:
>
>
> Steffen Kriese schrieb:
>
> ekke schrieb:
>
> see bugzilla 287617
> using Platform.getWorkbench().getDisplay() starts my riena rcp app without
> SWT.error,
> but using a LoginView or setting the LnF from DS now there's a problem,
> because at some early points the workbench isn't started yet
>
> ...did some more tests and compared behaviour between 1.1 and 1.2:
> same bundles are runnin from riena with same state
> but in 1.1 Thread-0 from my RCPApplication (extending SWTApplication)
> creates first Display
> and in 1.2 the ComponentResolveThread from ColorLnFResource creates first
> Display
>
> so something must be different between 1.1 and 1.2 while activating the
> running bundles
>
> ekke
> btw: so my first commit was only half-way-to-success :-(
>
> Your commit had another side effect: Some of our UI-Tests don't work
> anymore, because they are trying to create a Color-Ressource before the
> workbench is started. Take a look at ChoiceCompositeTest or ComboRidgetTest.
>
> so I think its best I revert the change and hopefully someone has an idea
> why in 1.2 there's a different behaviour,
> when the ColorLnFResource creates the Resource
>
> ekke
>
> Best regards,
> Steffen Kriese
>
>
> ekke schrieb:
>
> after some more debugging and discussions with christian campo,
> the reason was found:
>
> I had to replace
> Display.getDefault() with Platform.getWorkbench().getDisplay()
> in ColorLnfRessource to correct the threading problems
>
> btw: this was my first own Commit to eclipse cvs to fix a bug :-)
>
> ekke
>
> --
>
> ekke (ekkehard gentz)
> independent software-architect
> senior erp-consultant
> eclipse | osgi | equinox | mdsd | oaw | emf | uml
> max-josefs-platz 30, D-83022 rosenheim, germany
> mailto:ekke@xxxxxxxxxxxxxxxx
> homepage (de): http://gentz-software.de
> blog (en): http://ekkes-corner.org
> twitter: @ekkescorner
> skype: ekkes-corner
> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
>
> ________________________________
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
>
>
> --
>
> ekke (ekkehard gentz)
> independent software-architect
> senior erp-consultant
> eclipse | osgi | equinox | mdsd | oaw | emf | uml
> max-josefs-platz 30, D-83022 rosenheim, germany
> mailto:ekke@xxxxxxxxxxxxxxxx
> homepage (de): http://gentz-software.de
> blog (en): http://ekkes-corner.org
> twitter: @ekkescorner
> skype: ekkes-corner
> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
>
> ________________________________
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
>
>
> --
>
> ekke (ekkehard gentz)
> independent software-architect
> senior erp-consultant
> eclipse | osgi | equinox | mdsd | oaw | emf | uml
> max-josefs-platz 30, D-83022 rosenheim, germany
> mailto:ekke@xxxxxxxxxxxxxxxx
> homepage (de): http://gentz-software.de
> blog (en): http://ekkes-corner.org
> twitter: @ekkescorner
> skype: ekkes-corner
> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
>
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
>
>
>
>
>
>
> --
>
> ekke (ekkehard gentz)
> independent software-architect
> senior erp-consultant
> eclipse | osgi | equinox | mdsd | oaw | emf | uml
> max-josefs-platz 30, D-83022 rosenheim, germany
> mailto:ekke@xxxxxxxxxxxxxxxx
> homepage (de): http://gentz-software.de
> blog (en): http://ekkes-corner.org
> twitter: @ekkescorner
> skype: ekkes-corner
> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
>
> <ATT00001.c>
>
> ________________________________
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
>
>
> --
>
> ekke (ekkehard gentz)
> independent software-architect
> senior erp-consultant
> eclipse | osgi | equinox | mdsd | oaw | emf | uml
> max-josefs-platz 30, D-83022 rosenheim, germany
> mailto:ekke@xxxxxxxxxxxxxxxx
> homepage (de): http://gentz-software.de
> blog (en): http://ekkes-corner.org
> twitter: @ekkescorner
> skype: ekkes-corner
> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
>
> <ATT00001.c>
>
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
>
>



-- 
Elias Volanakis | Technical Lead | EclipseSource Portland
elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | http://eclipsesource.com