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.

I don't know the answer. I am currently digging into the GWT internals. 

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):
https://github.com/errai/errai/blob/3.0/errai-common/src/main/java/org/jboss/errai/common/metadata/RebindUtils.java

Combined with the MetaDataScanner that knows where the @Templated class is, we should be able to come up with a solution.

I am still digging though….

Christian

On 2013-03-27, at 2:12 PM, Eric Wittmann <eric.wittmann@redhat.com> wrote:

Ah ha.  That makes sense.  In any case, all @ApplicationScoped beans by
definition (I assume) would be loaded and available by the time any
templates were being rendered (regardless of the presence of @LoadAsync).

I think this question is put to bed.  :)  Thanks.

Now what about the other 2?  :)

-Eric

On 03/27/2013 02:09 PM, Christian Sadilek wrote:
However, only a bean annotated with @LoadAsync can possibly be loaded
asynchronously. So, if you just look up your own bean within
TemplateUtil and that bean is not annotated with @LoadAsync, you should
be fine. The callback will always be invoked synchronously then.

Christian

On 2013-03-27, at 1:44 PM, Christian Sadilek <csadilek@redhat.com
<mailto:csadilek@redhat.com>> wrote:

If async IOC is active, the callback will be invoked asynchronously
(at least when it first downloads the source for the corresponding
bean). You can take a look at the new ListWidget implementation which
needs to wait until all callbacks have been executed as well:
https://github.com/errai/errai/blob/master/errai-ui/src/main/java/org/jboss/errai/ui/client/widget/ListWidget.java

Another option is to make use of the InitVotes system:
https://github.com/errai/errai/blob/master/errai-common/src/main/java/org/jboss/errai/common/client/api/extension/InitVotes.java

This is unfortunate but there seems to be no way around it when
supporting async bean management.

Cheers,
Christian

On 2013-03-27, at 1:29 PM, Eric Wittmann <eric.wittmann@redhat.com
<mailto:eric.wittmann@redhat.com>> wrote:

Is the bean lookup going to be done synchronously though (regardless of
the impl)?  That's very important in this case.  The TemplateUtil is
going to be invoked several times in sequence (different methods).  If
one of the TemplateUtil methods does something asynchronously that's a
problem.  If not, is there a wait-notify pattern that should be used?

-Eric

On 03/27/2013 01:24 PM, Christian Sadilek wrote:
Actually we have just abstracted that. When you ask for the async
bean manager IOC.getAsyncBeanManager() it will work in either case.
If synchronous bean management is enabled it will return an adapter
where the callback will just immediately be invoked.

So, just always use the async bean manager API.  That code can of
course also be generated, if you wanted/needed to.

On 2013-03-27, at 1:19 PM, Eric Wittmann <eric.wittmann@redhat.com
<mailto:eric.wittmann@redhat.com>> wrote:

I think the advent of the async bean manager may have complicated this
though, right?  I don't *think* I can simply get the bean manager and
ask it for the bean (there are a couple of different getters now - one
to get the sync bean manager and one to get the async bean manager).

One thing I tried that worked but that I don't like:  turn the
@ApplicationScoped bean into a singleton and reference it using a
static
method.  Ugly but worked.  Ideally I think TemplateUtil should
itself be
an injected bean, rather than a class with some static methods.

But that just moves the problem to "how do I reference an injected bean
in code generated by a Decorator/Extension?"  :)

On 03/27/2013 01:13 PM, Lincoln Baxter, III wrote:
To answer Question #3, this would either need to be coded into the
call
to TemplateUtil from the BootstrapperImpl code (done in
DecoratorTemplated.java) or I believe there is a convenience
utility to
get the BeanManager in Errai:

CDI.current() or something like that. Mike?


On Tue, Mar 26, 2013 at 12:20 PM, Eric Wittmann
<eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>
<mailto:eric.wittmann@redhat.com>> wrote:

  Hey guys.  I've sketched out a proposed approach (not 100%
compete but
  ok to start) for i18n.  Would appreciate it if you could take a
look
  at it.

  At the bottom you will find 3 questions that I would (in
particular)
  love your thoughts on.

https://docs.google.com/document/d/1BapD4FHMNur0OYdIg-vwXYHWW_2Mhra_Ki2nYAh9qxY/pub

  -Eric
  _______________________________________________
  errai-dev mailing list
errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>
<mailto:errai-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/errai-dev




--
Lincoln Baxter, III
http://ocpsoft.org <http://ocpsoft.org/>
"Simpler is better."


_______________________________________________
errai-dev mailing list
errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/errai-dev

_______________________________________________
errai-dev mailing list
errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/errai-dev


_______________________________________________
errai-dev mailing list
errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/errai-dev

_______________________________________________
errai-dev mailing list
errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/errai-dev




_______________________________________________
errai-dev mailing list
errai-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev

_______________________________________________
errai-dev mailing list
errai-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev