Tuesday, June 30, 2020

Re: GWT SingleUploader gets stuck

Thanks very much.

I was using it because it allows me to modify the uploaded file name from the client's side. Is it possible to do that using FileUpload?


On Tuesday, June 30, 2020 at 5:27:47 PM UTC+3, Colin Alworth wrote:
It looks like this isn't part of GWT itself, but an external library. Here's a stackoverflow post i found from a few years ago that seems to address your issue: https://stackoverflow.com/questions/31424639/gwt-error-when-uploading-file-with-singleuploader

It looks like the project might live on in github, but there has been minimal activity there: https://github.com/manolo/gwtupload/. Check the network of forks for more updated versions to see if one of them might be the "new home" for this project? https://github.com/manolo/gwtupload/network

On Tuesday, June 30, 2020 at 8:52:36 AM UTC-5, ahmdt wrote:
When I upload a file using SingleUploader or MultiUploader, the file gets uploaded but the uploader's progress bar gets stuck at 0% for a very, very long time.

When I try to upload a second file in the same session, I get this message:
 
There is already an active upload, try later. 


This is my code:

final SingleUploader uploader = new SingleUploader();
uploader.setAutoSubmit(false);
uploader.setMultipleSelection(false);
uploader.setValidExtensions(".log");
uploader.setServletPath("/reprocess/"+userTestXml);
uploader.avoidRepeatFiles(false);


 Any advice here?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/9f57d3b6-956b-40de-9823-452a187094efo%40googlegroups.com.

Re: GWT SingleUploader gets stuck

It looks like this isn't part of GWT itself, but an external library. Here's a stackoverflow post i found from a few years ago that seems to address your issue: https://stackoverflow.com/questions/31424639/gwt-error-when-uploading-file-with-singleuploader

It looks like the project might live on in github, but there has been minimal activity there: https://github.com/manolo/gwtupload/. Check the network of forks for more updated versions to see if one of them might be the "new home" for this project? https://github.com/manolo/gwtupload/network

On Tuesday, June 30, 2020 at 8:52:36 AM UTC-5, ahmdt wrote:
When I upload a file using SingleUploader or MultiUploader, the file gets uploaded but the uploader's progress bar gets stuck at 0% for a very, very long time.

When I try to upload a second file in the same session, I get this message:
 
There is already an active upload, try later. 


This is my code:

final SingleUploader uploader = new SingleUploader();
uploader.setAutoSubmit(false);
uploader.setMultipleSelection(false);
uploader.setValidExtensions(".log");
uploader.setServletPath("/reprocess/"+userTestXml);
uploader.avoidRepeatFiles(false);


 Any advice here?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/f942772a-5013-4910-9b5d-6ea0c10eeadao%40googlegroups.com.

GWT SingleUploader gets stuck

When I upload a file using SingleUploader or MultiUploader, the file gets uploaded but the uploader's progress bar gets stuck at 0% for a very, very long time.

When I try to upload a second file in the same session, I get this message:
 
There is already an active upload, try later. 


This is my code:

final SingleUploader uploader = new SingleUploader();
uploader.setAutoSubmit(false);
uploader.setMultipleSelection(false);
uploader.setValidExtensions(".log");
uploader.setServletPath("/reprocess/"+userTestXml);
uploader.avoidRepeatFiles(false);


 Any advice here?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/946acfd8-47d6-4a37-a5ce-8d632818e7e7o%40googlegroups.com.

Re: Security Vulnerabilities with GWT

Thank you very much for quick responses.
Here are Vulnerabilities listed -


Gwt-dev.jar -
1.1 Vulnerable version of jetty library(current version-- 9.2.14, available version -9.2.27+ ) 
[Associated CVEs -  CVE-2017-7656,CVE-2017-7657,CVE-2017-7658,CVE-2017-9735,CVE-2018-12536]
1.2 Vulnerable version of commons-collections(current version - 3.2.1)  [ CVE-2015-6420,CVE-2017-15708,CVE-2014-3577]
1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current version - 4.3.1)  [ CVE-2015-6420,CVE-2017-15708,CVE-2014-3577]
1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0) [CVE-2015-5237]
1.5  Vulnerable version of htmlunit ( current version - 2.19 , available version- 2.37) [CVE-2020-5529]

Gwt-servlet.jar -
        1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0) [CVE-2015-5237]


On Monday, 29 June 2020 16:27:41 UTC+5:30, Priya Kolekar wrote:

Hi All,

Security Vulnerability have been detected in gwt-dev.jar & gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker tool.

Below are the details -

Gwt-dev.jar -
1.1 Vulnerable version of jetty library(current version-- 9.2.14, available version -9.2.27+ )
1.2 Vulnerable version of commons-collections(current version - 3.2.1)
1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current version - 4.3.1)
1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)
1.5  Vulnerable version of htmlunit ( current version - 2.19 , available version- 2.37)

Gwt-servlet.jar -
        1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)

Given above vulnerabilities -
1. Are those security issues addressed in latest 2.9.0 release?
2. If no, is there a plan to include them in any future release say 3.x?
3. As we know that gwt-dev.jar is used for development purpose & can be flagged as false positive, still are there any attack surfaces exists?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/53fc57d4-6d37-44b5-b267-044aa30e878co%40googlegroups.com.

Monday, June 29, 2020

Re: Security Vulnerabilities with GWT

The gwt-servlet issue is only on c++ versions of protobuf, so we believe there is no exploit here at all.

The other issues are all specific to gwt-dev, and neither gwt-dev.jar nor gwt-user.jar should ever be deployed as part of a running server application, so none of those should be exploitable either.


On Mon, Jun 29, 2020, at 10:38 AM, Velusamy Velu wrote:
Is there a documented or demonstrated case of break-in using any of the vulnerabilities listed in your post, in an application developed with GWT framework? Do these vulnerabilities matter if a GWT application doesn't use GWT's RPC?

On Monday, June 29, 2020 at 6:57:41 AM UTC-4, Priya Kolekar wrote:

Hi All,

Security Vulnerability have been detected in gwt-dev.jar & gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker tool.

Below are the details -

Gwt-dev.jar -
1.1 Vulnerable version of jetty library(current version-- 9.2.14, available version -9.2.27+ )
1.2 Vulnerable version of commons-collections(current version - 3.2.1)
1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current version - 4.3.1)
1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)
1.5  Vulnerable version of htmlunit ( current version - 2.19 , available version- 2.37)

Gwt-servlet.jar -
        1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)

Given above vulnerabilities -
1. Are those security issues addressed in latest 2.9.0 release?
2. If no, is there a plan to include them in any future release say 3.x?
3. As we know that gwt-dev.jar is used for development purpose & can be flagged as false positive, still are there any attack surfaces exists?

Re: Security Vulnerabilities with GWT

Is there a documented or demonstrated case of break-in using any of the vulnerabilities listed in your post, in an application developed with GWT framework? Do these vulnerabilities matter if a GWT application doesn't use GWT's RPC?

On Monday, June 29, 2020 at 6:57:41 AM UTC-4, Priya Kolekar wrote:

Hi All,

Security Vulnerability have been detected in gwt-dev.jar & gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker tool.

Below are the details -

Gwt-dev.jar -
1.1 Vulnerable version of jetty library(current version-- 9.2.14, available version -9.2.27+ )
1.2 Vulnerable version of commons-collections(current version - 3.2.1)
1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current version - 4.3.1)
1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)
1.5  Vulnerable version of htmlunit ( current version - 2.19 , available version- 2.37)

Gwt-servlet.jar -
        1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)

Given above vulnerabilities -
1. Are those security issues addressed in latest 2.9.0 release?
2. If no, is there a plan to include them in any future release say 3.x?
3. As we know that gwt-dev.jar is used for development purpose & can be flagged as false positive, still are there any attack surfaces exists?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/ffaffa6f-6753-4546-ba7b-db2cb85e9a6eo%40googlegroups.com.

Re: Security Vulnerabilities with GWT



On Monday, June 29, 2020 at 12:57:41 PM UTC+2, Priya Kolekar wrote:

Hi All,

Security Vulnerability have been detected in gwt-dev.jar & gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker tool.

Below are the details -

Gwt-dev.jar -
1.1 Vulnerable version of jetty library(current version-- 9.2.14, available version -9.2.27+ )

Dev servers only listen on 127.0.0.1 by default, which already limits the attack surface a lot.
I don't know the details of the vulnerabilities, but I suspect many would be hard to exploit in a dev environment, even if you opened your dev servers to other machines on your network.
 
1.2 Vulnerable version of commons-collections(current version - 3.2.1)

This is all related to Java Object Serialization. GWT does not use serialization across the network AFAICT (some objects are serialized to disk as a persistent cache, but then they're not vulnerable)
 
1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current version - 4.3.1)

HttpClient is a dependency of HtmlUnit, it'll only be used during your GWTTestCase tests (if you run them with HtmlUnit)
 
1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)

This (https://snyk.io/vuln/maven:com.google.protobuf%3Aprotobuf-java) is a false positive: it's actually in the C++ version.

1.5  Vulnerable version of htmlunit ( current version - 2.19 , available version- 2.37)

You're only vulnerable if you load untrusted third-party scripts within your GWTTestCase tests (and you use HtmlUnit to run them)


Gwt-servlet.jar -
        1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)

As said in my other message, this is an "internal" dependency (and probably never used for serialization/deserialization of protobuf objects), and as seen above, the vulnerability actually is in Protobuf C++, not Protobuf Java.

Given above vulnerabilities -
1. Are those security issues addressed in latest 2.9.0 release?
2. If no, is there a plan to include them in any future release say 3.x?
3. As we know that gwt-dev.jar is used for development purpose & can be flagged as false positive, still are there any attack surfaces exists?

Given the above, I'd say no.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/8dd17a2b-d9e8-411f-ac35-426dbfec5b6fo%40googlegroups.com.

Re: Security Vulnerabilities with GWT



On Monday, June 29, 2020 at 3:36:11 PM UTC+2, Colin Alworth wrote:
1. No, these dependencies were not updated as part of the 2.9.0 release 
2. An update would come either in a 2.9.x bugfix release, or in 2.10 - the 3.x release is going to be structured in a different enough of a way that none of these will be present.
3. At a quick glance, it appears to be an oversight that protobuf is included in gwt-servlet and can be entirely removed. I believe this is likely a false positive if it is not used, since it gets a custom package, so will not interfere with other protobuf dependencies.

From a quick search in gwtproject/tools, protobuf is a transitive dependency of jscomp-sourcemaps, and it *is* indeed the rebased/repackaged version.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/674eca0f-36d2-48fa-88f1-2a5ccdb2c494o%40googlegroups.com.

Re: Security Vulnerabilities with GWT

1. No, these dependencies were not updated as part of the 2.9.0 release
2. An update would come either in a 2.9.x bugfix release, or in 2.10 - the 3.x release is going to be structured in a different enough of a way that none of these will be present.
3. At a quick glance, it appears to be an oversight that protobuf is included in gwt-servlet and can be entirely removed. I believe this is likely a false positive if it is not used, since it gets a custom package, so will not interfere with other protobuf dependencies.

Can you share the full report you obtained so we can confirm that #3 is true, and file an issue with all the details? I'll start work on confirming we can remove it from gwt-servlet, and after we are certain about these issues we look into making a release.
On Monday, June 29, 2020 at 5:57:41 AM UTC-5 priyako...@gmail.com wrote:

Hi All,

Security Vulnerability have been detected in gwt-dev.jar & gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker tool.

Below are the details -

Gwt-dev.jar -
1.1 Vulnerable version of jetty library(current version-- 9.2.14, available version -9.2.27+ )
1.2 Vulnerable version of commons-collections(current version - 3.2.1)
1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current version - 4.3.1)
1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)
1.5  Vulnerable version of htmlunit ( current version - 2.19 , available version- 2.37)

Gwt-servlet.jar -
        1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)

Given above vulnerabilities -
1. Are those security issues addressed in latest 2.9.0 release?
2. If no, is there a plan to include them in any future release say 3.x?
3. As we know that gwt-dev.jar is used for development purpose & can be flagged as false positive, still are there any attack surfaces exists?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/3c7a79d4-7ce4-4000-bb50-e040f2110bden%40googlegroups.com.

Security Vulnerabilities with GWT


Hi All,

Security Vulnerability have been detected in gwt-dev.jar & gwt-servlet.jar(in release 2.8.2) & are reported by Dependency checker tool.

Below are the details -

Gwt-dev.jar -
1.1 Vulnerable version of jetty library(current version-- 9.2.14, available version -9.2.27+ )
1.2 Vulnerable version of commons-collections(current version - 3.2.1)
1.3 Vulnerable version of org.apache.httpcomponents:httpclient(current version - 4.3.1)
1.4 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)
1.5  Vulnerable version of htmlunit ( current version - 2.19 , available version- 2.37)

Gwt-servlet.jar -
        1.1 Vulnerable version of Google Protobuf(current version - 2.5.0, available version - 3.4.0)

Given above vulnerabilities -
1. Are those security issues addressed in latest 2.9.0 release?
2. If no, is there a plan to include them in any future release say 3.x?
3. As we know that gwt-dev.jar is used for development purpose & can be flagged as false positive, still are there any attack surfaces exists?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/64c4c6b7-e73d-455a-87bc-ad838861a843o%40googlegroups.com.

Friday, June 26, 2020

Re: Elemental2 and widgets

in most of the simple cases where you just wrap an element inside a widget like that, then you keep using the element as element not as a widget, things should work, but if you at some point needs a widget like interaction between wrapped widgets where the widget will expect a correct wiring of parent widget and a proper events sink you will face problems.

as for domino-ui, i would say you can just wrap as widgets only to append those domino-ui as elements, which means you will only treat them as widgets when you are appending them. other than that the gradual migration depends on how you would map your widgets to the domino-ui components, and how you split your views, and what mvp you use for example.

On Sunday, June 21, 2020 at 2:02:09 PM UTC+3, Gordan Krešić wrote:
On 21. 06. 2020. 08:55, Vegegoku wrote:
> sorry, i meant to say : That will *NOT* do the required wiring
>
> On Saturday, June 20, 2020 at 1:55:20 PM UTC+3, Vegegoku wrote:
>
>     That will do the required wiring to make elements behave like widgets,
>     it will not wire events correctly nor it will wire the attach/detach,
>     you can do it but it is not a simple task, thats why elemento moved the
>     issue the lib user instead of solving it in the lib itself.

Could you be a bit more specific?

So far, I've tested with only a very simple hierarchy:

        RootPanel -> SimpleLayoutPanel -> [widget/Domino border] -> GridLayout ->
other Domino elements

and I didn't see any problems, neither with event handling (click listeners
on GridLayout children) nor with GridLayout.onDetached (didn't test onAttached).

So, where I can expect problems to start manifesting?

Also, back to my initial question: ss there any "best practice" for
graduately migrating widget-based app to DominoUI?

        -gkresic.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7042edb1-0c52-41a9-b367-7c50d4857575o%40googlegroups.com.

Re: runAsync + permutations

I'm not sure I've seen this done before, but in theory what you are attempting should be supported? The CodeSplitter runs on each individual permutation, taking both java/js programs as input, and appears to have checks to confirm that only reachable code for that permutation ends up in the split points. This is well after the optimization loop too, so the each java program should have dead code removed from it after constants (like system.getProperty("foo").equals("bar")) have been handled (getProperty("foo") replaced with a JPermutationDependentValue early in the build, then in the specific permutation the real value is swapped in by ResolvePermutationDependentValues, then DeadCodeElimination first rewrites the "literal".equals("literal") to true or false and the entire if statement gets replaced with an empty statement by Simplifier, also in DeadCodeElimination).

Can you confirm how you are checking this? You said "the code splits are generated all the same" - does that mean that the same number of split points exist and have should-be-pruned code in them, or that they exist but are actually empty (or mostly empty, minimum size is a under 1kb iirc)? Also, is there any chance that you've told the compiler to not heavily optimize? This is a long shot since even one pass through the optimization loop should make these changes, but is my next best guess just from reading the code briefly.

It does appear that the "count how many split points exist at all" (aka ReplaceRunAsyncs) happens before permutations are considered, so my hunch would be that those garbage split points are actually small or empty, and that avoiding generating them at all would probably be more trouble than it is worth, but I'm not certain about this.

On Friday, June 26, 2020 at 7:31:12 AM UTC-5 Alexander Bertram wrote:
Hi there,

I've have defined a second set of permutations for our app based on screen size. When screen size dips below 768, the property "form.factor" is set to "mini", and we bind the entry point to a different implementation.

<replace-with class="com.acme.ui.client.MiniEntryPoint">
<when-type-is class="com.acme.ui.client.LargeEntryPoint" />
<when-property-is name="form.factor" value="mini"/>
</replace-with>

The LargeEntryPoint contains many more features, and uses GWT.runAsync() to split some of the larger ones from the initial download.

The mini permutations correctly only include the features included from MiniEntryPoint. BUT they also include identical splits for each of the GWT.runAsync() calls, even though the GWT.runAsync() calls are not reachable from MiniEntryPoint.

I've even tried wrapping the calls to GWT.runAsync() in:

if(System.getProperty("form.factor").equals("full")) {
   GWT.runAsync(new RunAsyncCallback() {
      // ...
   });
}

but it has no impact - the code splits are generated all the same.

This isn't a show stopper as these split points are ever loaded from the mini app, but it would be nice to reduce the extra compile and deploy time involved in these large split points.

Is it possible that the code splitting runs before dead code elimination in each permutation? Any workarounds?

Thanks,
Alex



--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/acb5f188-6555-4831-b3e5-00257adeaa27n%40googlegroups.com.

Wednesday, June 24, 2020

Re: StyleInjector chokes on startup

Sorry, I phrased that poorly.

Old scheduler with "old events" (i.e. from JSNI that correctly uses $entry, buggy JSNI forgetting $entry doesnt count) will work properly, and old/new events with new scheduler will work too. The problem is in old scheduler with "new" events - anything using plain jsinterop and avoiding $entry on its way into JS from Java. There is no fix we can do in GWT for it, old Scheduler assumes always that Entry owns all chances for JS to call Java, and so correctly wires up GWT's side of the event loop as well as uncaught exception handling.

Another option than triggering a fixed delay is to decide when the finally should be invoked, and call SchedulerImpl.INSTANCE.flushFinallyCommands(), that will trigger them all to take place right away. This is what $entry does, after your event is entirely handled in Java.

As a workaround, it may be possible to extend com.google.gwt.core.client.SchedulerImpl and splice in the Promise wiring found in gwt-core. Three bad effects off the top of my head:
* scheduleEntry won't work (deprecated in gwt-core, there is no way to do this without requiring $entry or the like)
* legacy dev mode won't work (it _might_ be possible to work around this, but for this last issue...)
* any browser without Promise support won't work, or will have a still-wrong hack in it (without promises, you need another microtask implementation, and of the browsers that don't have Promise, most don't have MutationObserver either which is the go-to hack I've found. Are there other hacks?) - you may end up with the "finally" happening after the next event or after some other timer instead of before it.

Filing it sounds good - we can offer the tradeoffs, and if someone has the need and the bandwidth to resolve this problem fully, we probably can get most of the way there, provided they can accept the caveats and test heavily.

--
Colin Alworth
colin@colinalworth.com

On Wed, Jun 24, 2020, at 5:09 PM, Gordan Krešić wrote:
> I'm willing to provide more info, but TBH I'm not sure what are you asking.
>
> You can see below code example that shows the problem. One "solution" that
> triggers scheduleFinally to run is to invoke another scheduleFixedDelay -
> that event is for sure not related to widgets, but I'm not sure if it is
> related to JsInterop.
>
> OTOH, I can confirm that handling mouse click on button widget DO triggers
> scheduleFinally, too.
>
> Like I've said, I've noticed new Sheduler (gwt-core) and all the differences
> that it brings when compared to "old" Scheduler (gwt-client), but I didn't
> test this new Scheduler.
>
> So, "old" Scheduler obviously has a bug or at least very unexpected
> behaviour. I agree that fixing this is not worth an effort if it's not a
> very simple fix (which I assume it isn't), but I offered to document this
> misbehaviour in form of bug report so that anyone else can at least find
> this workaround if needed (I didn't found any reference to it so far).
>
>
> On 24. 06. 2020. 19:16, Colin Alworth wrote:
> > Can you clarify the browser event that you are working with? If it is
> > something through JsInterop, then this is expected, since JSNI style calls
> > into Java from JS require $entry, but jsinterop provides no such mechanism.
> > If it is an event from a GWT Widget, then that would go through JSNI, and
> > this should not happen.
> >
> > As such, https://github.com/gwtproject/gwt-core has an updated Scheduler
> > which is compatible with JsInterop calls - scheduleFinally is now
> > implemented as a microtask, so that it will always precede any subsequent
> > event, no matter how the event originates. The gwt-core project also
> > contains an updated StyleInjector, and a corresponding gwt-resources module
> > (not yet moved to github.com/gwtproject) will provide an updated
> > ClientBundle implementation.
> >
> > Note that as we're committed to maintaining legacy dev mode in the GWT 2.x
> > branch, we cannot replace the com.google.gwt.core.client.Scheduler wiring
> > with jsinterop.
> >
> > On Sunday, June 21, 2020 at 6:13:54 AM UTC-5, Gordan Krešić wrote:
> >
> > I'll take the blame for code design, no questions about that :)
> >
> > Do you think it's worth filing a bug report or this is too much of an edge
> > case in a code that is going away soon anyway? Note that I didn't test
> > against org.gwtproject.core.client.Scheduler only
> > com.google.gwt.core.client.Scheduler (and they do differ, at least
> > regarding
> > scheduleFinally).
> >
> >
> > On 19. 06. 2020. 09:42, Thomas Broyer wrote:
> > > Yes, we can probably consider that a bug in GWT.
> > > I'd also call this pattern of doing real work in a static initializer
> > a code
> > > smell:
> > >
> > http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/
> > <http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/>
> >
> > > While still a flaw considering the above link, it's however a common
> > > practice to call `ensureInjected()` from the class constructor (ideally,
> > > you'd rather call it in a lifecycle method, such as Activity#start, or
> > > Widget#onAttach); and that would likely fix your issue here.
> > >
> > > On Thursday, June 18, 2020 at 8:33:06 PM UTC+2, Gordan Krešić wrote:
> > >
> > >     On 18. 06. 2020. 20:25, Gordan Krešić wrote:
> > >      > Probably unrelated with StyleInjector but with
> > Scheduler.scheduleFinally
> > >
> > >     Ok, I've put a most basic repro case to prove that this is a
> > Scheduler
> > >     issue:
> > >
> > >     public class Foo {
> > >
> > >              static {
> > >                      Scheduler.get().scheduleFinally(() ->
> > >     GWT.log("Finally!"));
> > >              }
> > >
> > >     }
> > >
> > >     Now initialite Foo on startup (in EntryPoint.onModuleLoad() for
> > example),
> > >     but "Finally!" will be printed only *after* first event loop, like
> > >     described:
> > >
> > >     Scheduler.get().scheduleFixedDelay(() -> {
> > >              return false;
> > >     }, 0);
> > >
> > >              -gkresic.
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > Groups
> > > "GWT Users" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send an
> > > email to google-web-toolkit+unsubscribe@googlegroups.com
> > <mailto:google-web-toolkit%2Bunsubscribe@googlegroups.com>
> > > <mailto:google-web-toolkit+unsubscribe@googlegroups.com
> > <mailto:google-web-toolkit%2Bunsubscribe@googlegroups.com>>.
> > > To view this discussion on the web visit
> > >
> > https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com
> > <https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com>
> >
> > >
> > <https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com?utm_medium=email&utm_source=footer
> > <https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "GWT Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to google-web-toolkit+unsubscribe@googlegroups.com
> > <mailto:google-web-toolkit+unsubscribe@googlegroups.com>.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/google-web-toolkit/0d761c71-bb99-44b2-9581-9aee45cff40bo%40googlegroups.com
> > <https://groups.google.com/d/msgid/google-web-toolkit/0d761c71-bb99-44b2-9581-9aee45cff40bo%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GWT Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/TyJAVyCkir4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit/060994ea-9eef-9ecb-fa96-a54cceeac3d1%40steatoda.com.
>

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/872580b3-db73-44f2-91d7-110a7e389d4a%40www.fastmail.com.

Re: StyleInjector chokes on startup

I'm willing to provide more info, but TBH I'm not sure what are you asking.

You can see below code example that shows the problem. One "solution" that
triggers scheduleFinally to run is to invoke another scheduleFixedDelay -
that event is for sure not related to widgets, but I'm not sure if it is
related to JsInterop.

OTOH, I can confirm that handling mouse click on button widget DO triggers
scheduleFinally, too.

Like I've said, I've noticed new Sheduler (gwt-core) and all the differences
that it brings when compared to "old" Scheduler (gwt-client), but I didn't
test this new Scheduler.

So, "old" Scheduler obviously has a bug or at least very unexpected
behaviour. I agree that fixing this is not worth an effort if it's not a
very simple fix (which I assume it isn't), but I offered to document this
misbehaviour in form of bug report so that anyone else can at least find
this workaround if needed (I didn't found any reference to it so far).


On 24. 06. 2020. 19:16, Colin Alworth wrote:
> Can you clarify the browser event that you are working with? If it is
> something through JsInterop, then this is expected, since JSNI style calls
> into Java from JS require $entry, but jsinterop provides no such mechanism.
> If it is an event from a GWT Widget, then that would go through JSNI, and
> this should not happen.
>
> As such, https://github.com/gwtproject/gwt-core has an updated Scheduler
> which is compatible with JsInterop calls - scheduleFinally is now
> implemented as a microtask, so that it will always precede any subsequent
> event, no matter how the event originates. The gwt-core project also
> contains an updated StyleInjector, and a corresponding gwt-resources module
> (not yet moved to github.com/gwtproject) will provide an updated
> ClientBundle implementation.
>
> Note that as we're committed to maintaining legacy dev mode in the GWT 2.x
> branch, we cannot replace the com.google.gwt.core.client.Scheduler wiring
> with jsinterop.
>
> On Sunday, June 21, 2020 at 6:13:54 AM UTC-5, Gordan Krešić wrote:
>
> I'll take the blame for code design, no questions about that :)
>
> Do you think it's worth filing a bug report or this is too much of an edge
> case in a code that is going away soon anyway? Note that I didn't test
> against org.gwtproject.core.client.Scheduler only
> com.google.gwt.core.client.Scheduler (and they do differ, at least
> regarding
> scheduleFinally).
>
>
> On 19. 06. 2020. 09:42, Thomas Broyer wrote:
> > Yes, we can probably consider that a bug in GWT.
> > I'd also call this pattern of doing real work in a static initializer
> a code
> > smell:
> >
> http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/
> <http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/>
>
> > While still a flaw considering the above link, it's however a common
> > practice to call `ensureInjected()` from the class constructor (ideally,
> > you'd rather call it in a lifecycle method, such as Activity#start, or
> > Widget#onAttach); and that would likely fix your issue here.
> >
> > On Thursday, June 18, 2020 at 8:33:06 PM UTC+2, Gordan Krešić wrote:
> >
> >     On 18. 06. 2020. 20:25, Gordan Krešić wrote:
> >      > Probably unrelated with StyleInjector but with
> Scheduler.scheduleFinally
> >
> >     Ok, I've put a most basic repro case to prove that this is a
> Scheduler
> >     issue:
> >
> >     public class Foo {
> >
> >              static {
> >                      Scheduler.get().scheduleFinally(() ->
> >     GWT.log("Finally!"));
> >              }
> >
> >     }
> >
> >     Now initialite Foo on startup (in EntryPoint.onModuleLoad() for
> example),
> >     but "Finally!" will be printed only *after* first event loop, like
> >     described:
> >
> >     Scheduler.get().scheduleFixedDelay(() -> {
> >              return false;
> >     }, 0);
> >
> >              -gkresic.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "GWT Users" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an
> > email to google-web-toolkit+unsubscribe@googlegroups.com
> <mailto:google-web-toolkit%2Bunsubscribe@googlegroups.com>
> > <mailto:google-web-toolkit+unsubscribe@googlegroups.com
> <mailto:google-web-toolkit%2Bunsubscribe@googlegroups.com>>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com
> <https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com>
>
> >
> <https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscribe@googlegroups.com
> <mailto:google-web-toolkit+unsubscribe@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit/0d761c71-bb99-44b2-9581-9aee45cff40bo%40googlegroups.com
> <https://groups.google.com/d/msgid/google-web-toolkit/0d761c71-bb99-44b2-9581-9aee45cff40bo%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/060994ea-9eef-9ecb-fa96-a54cceeac3d1%40steatoda.com.

Re: StyleInjector chokes on startup

Can you clarify the browser event that you are working with? If it is something through JsInterop, then this is expected, since JSNI style calls into Java from JS require $entry, but jsinterop provides no such mechanism. If it is an event from a GWT Widget, then that would go through JSNI, and this should not happen.

As such, https://github.com/gwtproject/gwt-core has an updated Scheduler which is compatible with JsInterop calls - scheduleFinally is now implemented as a microtask, so that it will always precede any subsequent event, no matter how the event originates. The gwt-core project also contains an updated StyleInjector, and a corresponding gwt-resources module (not yet moved to github.com/gwtproject) will provide an updated ClientBundle implementation.

Note that as we're committed to maintaining legacy dev mode in the GWT 2.x branch, we cannot replace the com.google.gwt.core.client.Scheduler wiring with jsinterop.

On Sunday, June 21, 2020 at 6:13:54 AM UTC-5, Gordan Krešić wrote:
I'll take the blame for code design, no questions about that :)

Do you think it's worth filing a bug report or this is too much of an edge
case in a code that is going away soon anyway? Note that I didn't test
against org.gwtproject.core.client.Scheduler only
com.google.gwt.core.client.Scheduler (and they do differ, at least regarding
scheduleFinally).


On 19. 06. 2020. 09:42, Thomas Broyer wrote:
> Yes, we can probably consider that a bug in GWT.
> I'd also call this pattern of doing real work in a static initializer a code
> smell:
> http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/
> While still a flaw considering the above link, it's however a common
> practice to call `ensureInjected()` from the class constructor (ideally,
> you'd rather call it in a lifecycle method, such as Activity#start, or
> Widget#onAttach); and that would likely fix your issue here.
>
> On Thursday, June 18, 2020 at 8:33:06 PM UTC+2, Gordan Krešić wrote:
>
>     On 18. 06. 2020. 20:25, Gordan Krešić wrote:
>      > Probably unrelated with StyleInjector but with Scheduler.scheduleFinally
>
>     Ok, I've put a most basic repro case to prove that this is a Scheduler
>     issue:
>
>     public class Foo {
>
>              static {
>                      Scheduler.get().scheduleFinally(() ->
>     GWT.log("Finally!"));
>              }
>
>     }
>
>     Now initialite Foo on startup (in EntryPoint.onModuleLoad() for example),
>     but "Finally!" will be printed only *after* first event loop, like
>     described:
>
>     Scheduler.get().scheduleFixedDelay(() -> {
>              return false;
>     }, 0);
>
>              -gkresic.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscribe@googlegroups.com
> <mailto:google-web-toolkit+unsubscribe@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com
> <https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/0d761c71-bb99-44b2-9581-9aee45cff40bo%40googlegroups.com.

Monday, June 22, 2020

Re: Elemental2 and widgets



So, where I can expect problems to start manifesting?

I think if you can make sure that you only put elemental2 based components into GWT widgets, then it should work without major issues. But if you have to add a GWT widget into an elemental2 based component, then you have the problem of handling the widget lifecycle correctly so that event handlers for that GWT widget work correctly.


-- J.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/8872e073-493a-474e-94ae-fcb762cf3a34o%40googlegroups.com.

Sunday, June 21, 2020

Re: StyleInjector chokes on startup

I'll take the blame for code design, no questions about that :)

Do you think it's worth filing a bug report or this is too much of an edge
case in a code that is going away soon anyway? Note that I didn't test
against org.gwtproject.core.client.Scheduler only
com.google.gwt.core.client.Scheduler (and they do differ, at least regarding
scheduleFinally).


On 19. 06. 2020. 09:42, Thomas Broyer wrote:
> Yes, we can probably consider that a bug in GWT.
> I'd also call this pattern of doing real work in a static initializer a code
> smell:
> http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/
> While still a flaw considering the above link, it's however a common
> practice to call `ensureInjected()` from the class constructor (ideally,
> you'd rather call it in a lifecycle method, such as Activity#start, or
> Widget#onAttach); and that would likely fix your issue here.
>
> On Thursday, June 18, 2020 at 8:33:06 PM UTC+2, Gordan Krešić wrote:
>
> On 18. 06. 2020. 20:25, Gordan Krešić wrote:
> > Probably unrelated with StyleInjector but with Scheduler.scheduleFinally
>
> Ok, I've put a most basic repro case to prove that this is a Scheduler
> issue:
>
> public class Foo {
>
>         static {
>                 Scheduler.get().scheduleFinally(() ->
> GWT.log("Finally!"));
>         }
>
> }
>
> Now initialite Foo on startup (in EntryPoint.onModuleLoad() for example),
> but "Finally!" will be printed only *after* first event loop, like
> described:
>
> Scheduler.get().scheduleFixedDelay(() -> {
>         return false;
> }, 0);
>
>         -gkresic.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscribe@googlegroups.com
> <mailto:google-web-toolkit+unsubscribe@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com
> <https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/a5d5da00-838b-ae4d-2ecd-f78c0d5dd522%40steatoda.com.

Re: Elemental2 and widgets

On 21. 06. 2020. 08:55, Vegegoku wrote:
> sorry, i meant to say : That will *NOT* do the required wiring
>
> On Saturday, June 20, 2020 at 1:55:20 PM UTC+3, Vegegoku wrote:
>
> That will do the required wiring to make elements behave like widgets,
> it will not wire events correctly nor it will wire the attach/detach,
> you can do it but it is not a simple task, thats why elemento moved the
> issue the lib user instead of solving it in the lib itself.

Could you be a bit more specific?

So far, I've tested with only a very simple hierarchy:

RootPanel -> SimpleLayoutPanel -> [widget/Domino border] -> GridLayout ->
other Domino elements

and I didn't see any problems, neither with event handling (click listeners
on GridLayout children) nor with GridLayout.onDetached (didn't test onAttached).

So, where I can expect problems to start manifesting?

Also, back to my initial question: ss there any "best practice" for
graduately migrating widget-based app to DominoUI?

-gkresic.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/bdc0f30a-fd9e-29c5-a2b7-f0afede76545%40steatoda.com.

Saturday, June 20, 2020

Re: Elemental2 and widgets

sorry, i meant to say : That will NOT do the required wiring

On Saturday, June 20, 2020 at 1:55:20 PM UTC+3, Vegegoku wrote:
That will do the required wiring to make elements behave like widgets, it will not wire events correctly nor it will wire the attach/detach, you can do it but it is not a simple task, thats why elemento moved the issue the lib user instead of solving it in the lib itself.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/9aec065a-9c96-446e-b154-40a80ab25074o%40googlegroups.com.

Re: Elemental2 and widgets

That will do the required wiring to make elements behave like widgets, it will not wire events correctly nor it will wire the attach/detach, you can do it but it is not a simple task, thats why elemento moved the issue the lib user instead of solving it in the lib itself.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/0618cfec-9da4-45ec-a8cb-847752f89f8eo%40googlegroups.com.

Friday, June 19, 2020

Re: StyleInjector chokes on startup

Yes, we can probably consider that a bug in GWT.
I'd also call this pattern of doing real work in a static initializer a code smell: http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/
While still a flaw considering the above link, it's however a common practice to call `ensureInjected()` from the class constructor (ideally, you'd rather call it in a lifecycle method, such as Activity#start, or Widget#onAttach); and that would likely fix your issue here.

On Thursday, June 18, 2020 at 8:33:06 PM UTC+2, Gordan Krešić wrote:
On 18. 06. 2020. 20:25, Gordan Krešić wrote:
> Probably unrelated with StyleInjector but with Scheduler.scheduleFinally

Ok, I've put a most basic repro case to prove that this is a Scheduler issue:

public class Foo {

        static {
                Scheduler.get().scheduleFinally(() -> GWT.log("Finally!"));
        }
        
}

Now initialite Foo on startup (in EntryPoint.onModuleLoad() for example),
but "Finally!" will be printed only *after* first event loop, like described:

Scheduler.get().scheduleFixedDelay(() -> {
        return false;
}, 0);

        -gkresic.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/1ecd7663-8a5a-449e-aef5-4008d3735433o%40googlegroups.com.

Thursday, June 18, 2020

Elemental2-1.1.0 released

Hi,

We released and pushed to maven central a new version of Elemental2 today: Elemental2-1.1.0.

Please refer to the github page for an explanation on how to use it. 

Summary of fixes/improvements included in this release:
- Elemental2 have been generated from the last version of closure extern files. Please refer to this page for the list of improvements/fixes on those extern files.
- Fix elemental2-webassembly maven pom file to correctly depend on elemental2-dom
- Update jsinterop-annotations dependency to jsinterop-annotations 2.0.0.
- Fix uncheckedCast overlay call when parameter is a varargs.

Please report any issues to https://github.com/google/elemental2/issues

-Julien

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/64e7691c-983b-4145-acc3-74fe161eca57o%40googlegroups.com.

Re: StyleInjector chokes on startup

On 18. 06. 2020. 20:25, Gordan Krešić wrote:
> Probably unrelated with StyleInjector but with Scheduler.scheduleFinally

Ok, I've put a most basic repro case to prove that this is a Scheduler issue:

public class Foo {

static {
Scheduler.get().scheduleFinally(() -> GWT.log("Finally!"));
}

}

Now initialite Foo on startup (in EntryPoint.onModuleLoad() for example),
but "Finally!" will be printed only *after* first event loop, like described:

Scheduler.get().scheduleFixedDelay(() -> {
return false;
}, 0);

-gkresic.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/16cdd18c-cdd1-0d1a-2c88-11607bdbbc7f%40steatoda.com.

StyleInjector chokes on startup

Probably unrelated with StyleInjector but with Scheduler.scheduleFinally,
but I'll try to explain:

Imagine class that defines ClientBundle as follows:

public class Foo {

public static interface Resources extends ClientBundle {
static final Resources $ = GWT.create(Resources.class);
@Source("Foo.gss")
Foo.Style style();
}
static {
Resources.$.style().ensureInjected();
}

@CssResource.ImportedWithPrefix("Foo")
public static interface Style extends CssResource {
String foo();
}

// ...

}

This class is GUI element that gets initialized through Activities/Places
framework, if that makes any difference.

Problem is, given style is NOT injected on app startup, but IT GETS INJECTED
if a do something as simple as:

Scheduler.get().scheduleFixedDelay(() -> {
return false;
}, 0);

in Foo's contructor.

Since StyleInjector injects styles using:

Scheduler.get().scheduleFinally

it looks like Scheduler doesn't recognize switch from GWT to browser event
loop if scheduleFinally is called sufficiently early during app startup
(like in static initializer of a class).

GWT 2.9.

Like I said, I've found a workaround (albeit a *very* dirty one), but
shouldn't this be treated as a bug in GWT?

-gkresic.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/4d8f9539-f07d-9f7f-117e-39ab1cd0316e%40steatoda.com.

Wednesday, June 17, 2020

Re: Elemental2 and widgets

On 17. 06. 2020. 14:46, Frank Hossfeld wrote:
> Please take a look here: https://gitter.im/hal/elemento for more information
> and here: https://github.com/hal/elemento/issues/82

I've found elemento-widget before, but wasn't sure if it's still relevant.
This commit says it's abandoned:

https://github.com/hal/elemento/blob/47d59fe225370af38facd1d0c2924275f8850d9a/CHANGES.md#deprecations

-gkresic.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/06950951-6019-1949-64d1-59507be3f2f1%40steatoda.com.

Re: Elemental2 and widgets

On 17. 06. 2020. 13:35, Jens wrote:
>
> But keep in mind that GWT widgets have been rewritten to be J2CL compatible
> (they use jsinterop internally now and in the future might be changed to use
> elemental2 dom elements). So it is not an urgent need to switch, unless you
> really want to.

Nice to hear that widgets are still maintained.

However, it's not that I'm migrating away from GWT widgets, it's more
migration to a more modern (by look and feel) widgetset (like Domino UI).

-gkresic.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/303df49c-195a-7841-554d-2c0e09feaf75%40steatoda.com.

Re: Elemental2 and widgets

Please take a look here: https://gitter.im/hal/elemento for more information and here: https://github.com/hal/elemento/issues/82

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/0e46ed5d-409a-41a7-a19e-61e4b751ec98o%40googlegroups.com.

Re: Elemental2 and widgets

Something like (totally untested) might work:

class WidgetAdapter extends Widget {

 
WidgetAdapter(elemental2.dom.Element element) {
    setElement
(Js.<com.google.gwt.dom.client.Element>uncheckedCast(element));
 
}

}


But keep in mind that GWT widgets have been rewritten to be J2CL compatible (they use jsinterop internally now and in the future might be changed to use elemental2 dom elements). So it is not an urgent need to switch, unless you really want to.

-- J.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/372286a2-a3e8-4f0c-b187-66e1a57e6617o%40googlegroups.com.

Elemental2 and widgets

What would be the best way to start migrating large widget-based app to
elemental2? I suppose it should start with leaf widgets and then progress up
the widget hierarchy tree until RootPanel itself is replaced with
elemental2.dom.HTMLElement-derivative, but I can't find a way to even start
mixing elemental2 with widgets.

For example, how would one pass org.dominokit.domino.ui.grid.GridLayout as
param to com.google.gwt.user.client.ui.AcceptsOneWidget.setWidget(IsWidget)?

My google-fu gives me only old samples which references (now removed)
org.jboss.elemento.Elements.asWidget.

Environment:

GWT 2.9.0
elemental2 1.0.0
elemento 1.0.0

-gkresic.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/e423f764-5526-6661-79da-9292b3d7a2a3%40steatoda.com.

Tuesday, June 16, 2020

Re: Upgrade to 2.9.0 from 2.8.2 is giving compilation errors while doing GWT compile

None of those classes are included in the default JRE emulation provided in either GWT 2.8.2 or 2.9.0 - if this previously worked, you might have had something on your classpath which provided those sources as supersource, or .gwt.xml files in those packages to indicate that they could be transpiled from some other sources? GWT 2.9.0 did remove one emulated class, NoSuchMethodException, and added several others (partial emulation for ExecutorService, ScheduledExecutorService, Flow), but none of these appear to intersect with the classes you mentioned.

Can you share more specific logs that show this issue?

Also, under GWT 2.8.2, were there warnings that some classes failed to compile, but that the errors were ignored? You can disable this with -strict/-failOnError so that no potential problems like this can go unnoticed.

On Monday, June 15, 2020 at 7:24:35 AM UTC-5, Priya Kolekar wrote:
Hi All,

We are planning to upgrade GWT 2.8.2 to GWT 2.9.0 with java 11 environment,

But while GWT compile,I am getting lot of errors saying "No source code is available for type <CLASS>; did you forget to inherit a required module?" 
Problematic classes include "java.lang.Thread","java.io.InterruptedIOException" ,"org.w3c.dom.Element", "java.util.Properties"

As I understand,errors are raised because these classes are not emulated by GWT  & GWT is unable to find them.
But this was working fine with 2.8.2 version.

Any idea where its going wrong? Are there any specific things to be considered while upgrading to 2.9?

Also, is log4j-gwt.jar compatible with 2.9.0 version?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/668c1985-9937-46de-a6d4-6236e3091074o%40googlegroups.com.