<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">About the other 2 :). Both seem to boil down to the same type of problem. How do I, for a given MetaClass instance, find out which module they were defined in.<div><br></div><div>I don't know the answer. I am currently digging into the GWT internals. </div><div><br></div><div>If there's no way to do it we'd need to implement something ourselves. We already scan all module xml files for source paths (see RebindUtils::getOuterTranslatablePackages):</div><div><a href="https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jboss/errai/common/metadata/RebindUtils.java">https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jboss/errai/common/metadata</a><a href="https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jboss/errai/common/metadata/RebindUtils.java">/RebindUtils.java</a></div><div><br></div><div>Combined with the MetaDataScanner that knows where the @Templated class is, we should be able to come up with a solution.</div><div><br></div><div>I am still digging though….</div><div><br></div><div>Christian</div><div><div><br><div><div>On 2013-03-27, at 2:12 PM, Eric Wittmann <<a href="mailto:eric.wittmann@redhat.com">eric.wittmann@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Ah ha. That makes sense. In any case, all @ApplicationScoped beans by <br>definition (I assume) would be loaded and available by the time any <br>templates were being rendered (regardless of the presence of @LoadAsync).<br><br>I think this question is put to bed. :) Thanks.<br><br>Now what about the other 2? :)<br><br>-Eric<br><br>On 03/27/2013 02:09 PM, Christian Sadilek wrote:<br><blockquote type="cite">However, only a bean annotated with @LoadAsync can possibly be loaded<br>asynchronously. So, if you just look up your own bean within<br>TemplateUtil and that bean is not annotated with @LoadAsync, you should<br>be fine. The callback will always be invoked synchronously then.<br><br>Christian<br><br>On 2013-03-27, at 1:44 PM, Christian Sadilek <<a href="mailto:csadilek@redhat.com">csadilek@redhat.com</a><br><<a href="mailto:csadilek@redhat.com">mailto:csadilek@redhat.com</a>>> wrote:<br><br><blockquote type="cite">If async IOC is active, the callback will be invoked asynchronously<br>(at least when it first downloads the source for the corresponding<br>bean). You can take a look at the new ListWidget implementation which<br>needs to wait until all callbacks have been executed as well:<br><a href="https://github.com/errai/errai/blob/master/errai-ui/src/main/java/org/jboss/errai/ui/client/widget/ListWidget.java">https://github.com/errai/errai/blob/master/errai-ui/src/main/java/org/jboss/errai/ui/client/widget/ListWidget.java</a><br><br>Another option is to make use of the InitVotes system:<br>https://github.com/errai/errai/blob/master/errai-common/src/main/java/org/jboss/errai/common/client/api/extension/InitVotes.java<br><br>This is unfortunate but there seems to be no way around it when<br>supporting async bean management.<br><br>Cheers,<br>Christian<br><br>On 2013-03-27, at 1:29 PM, Eric Wittmann <eric.wittmann@redhat.com<br><mailto:eric.wittmann@redhat.com>> wrote:<br><br><blockquote type="cite">Is the bean lookup going to be done synchronously though (regardless of<br>the impl)? That's very important in this case. The TemplateUtil is<br>going to be invoked several times in sequence (different methods). If<br>one of the TemplateUtil methods does something asynchronously that's a<br>problem. If not, is there a wait-notify pattern that should be used?<br><br>-Eric<br><br>On 03/27/2013 01:24 PM, Christian Sadilek wrote:<br><blockquote type="cite">Actually we have just abstracted that. When you ask for the async<br>bean manager IOC.getAsyncBeanManager() it will work in either case.<br>If synchronous bean management is enabled it will return an adapter<br>where the callback will just immediately be invoked.<br><br>So, just always use the async bean manager API. That code can of<br>course also be generated, if you wanted/needed to.<br><br>On 2013-03-27, at 1:19 PM, Eric Wittmann <eric.wittmann@redhat.com<br><mailto:eric.wittmann@redhat.com>> wrote:<br><br><blockquote type="cite">I think the advent of the async bean manager may have complicated this<br>though, right? I don't *think* I can simply get the bean manager and<br>ask it for the bean (there are a couple of different getters now - one<br>to get the sync bean manager and one to get the async bean manager).<br><br>One thing I tried that worked but that I don't like: turn the<br>@ApplicationScoped bean into a singleton and reference it using a<br>static<br>method. Ugly but worked. Ideally I think TemplateUtil should<br>itself be<br>an injected bean, rather than a class with some static methods.<br><br>But that just moves the problem to "how do I reference an injected bean<br>in code generated by a Decorator/Extension?" :)<br><br>On 03/27/2013 01:13 PM, Lincoln Baxter, III wrote:<br><blockquote type="cite">To answer Question #3, this would either need to be coded into the<br>call<br>to TemplateUtil from the BootstrapperImpl code (done in<br>DecoratorTemplated.java) or I believe there is a convenience<br>utility to<br>get the BeanManager in Errai:<br><br>CDI.current() or something like that. Mike?<br><br><br>On Tue, Mar 26, 2013 at 12:20 PM, Eric Wittmann<br><eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com><br><mailto:eric.wittmann@redhat.com>> wrote:<br><br> Hey guys. I've sketched out a proposed approach (not 100%<br>compete but<br> ok to start) for i18n. Would appreciate it if you could take a<br>look<br> at it.<br><br> At the bottom you will find 3 questions that I would (in<br>particular)<br> love your thoughts on.<br><br>https://docs.google.com/document/d/1BapD4FHMNur0OYdIg-vwXYHWW_2Mhra_Ki2nYAh9qxY/pub<br><br> -Eric<br> _______________________________________________<br> errai-dev mailing list<br>errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org><br><mailto:errai-dev@lists.jboss.org><br>https://lists.jboss.org/mailman/listinfo/errai-dev<br><br><br><br><br>--<br>Lincoln Baxter, III<br>http://ocpsoft.org <http://ocpsoft.org/><br>"Simpler is better."<br><br><br>_______________________________________________<br>errai-dev mailing list<br>errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org><br>https://lists.jboss.org/mailman/listinfo/errai-dev<br><br></blockquote>_______________________________________________<br>errai-dev mailing list<br>errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org><br>https://lists.jboss.org/mailman/listinfo/errai-dev<br></blockquote><br><br>_______________________________________________<br>errai-dev mailing list<br>errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org><br>https://lists.jboss.org/mailman/listinfo/errai-dev<br><br></blockquote>_______________________________________________<br>errai-dev mailing list<br>errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org><br>https://lists.jboss.org/mailman/listinfo/errai-dev<br></blockquote><br></blockquote><br><br><br>_______________________________________________<br>errai-dev mailing list<br><a href="mailto:errai-dev@lists.jboss.org">errai-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/errai-dev<br><br></blockquote>_______________________________________________<br>errai-dev mailing list<br><a href="mailto:errai-dev@lists.jboss.org">errai-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/errai-dev<br></blockquote></div><br></div></div></body></html>