<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Gavin King wrote:
<blockquote
cite="mid:db199550911200735j3b29f315oae9def0f6acb77e1@mail.gmail.com"
type="cite">
<pre wrap="">Nono, that's wrong. I think what should really happen is this:
= Abstract method annotated @Inject, @PostConstruct or @PreDestroy
results in a DE
</pre>
</blockquote>
That's pretty much what I thought as well - but I missed @PostConstruct
and @PreDestroy.<br>
<blockquote
cite="mid:db199550911200735j3b29f315oae9def0f6acb77e1@mail.gmail.com"
type="cite">
<pre wrap="">= Other abstract methods have a generated impl that simply calls the
same method on the delegate (and returns the result)
</pre>
</blockquote>
Actually, we could just ignore the method (as if it wasn't defined at
all) if it is abstract and think the whole problem in terms of
decorating method *implementations*. I don't know why exactly would
someone add something like this (hence my original thought that we
could just signal this as an error), but perhaps if one uses a
Decorator hierarchy it makes sense (then there's the question why you
would want to do that, but I think we're just looking for closure wrt
spec consistency, not best practices).<br>
<blockquote
cite="mid:db199550911200735j3b29f315oae9def0f6acb77e1@mail.gmail.com"
type="cite">
<pre wrap="">
Does that make sense?
</pre>
</blockquote>
So after what I wrote above, a *no* at this point would be insane :D<br>
<blockquote
cite="mid:db199550911200735j3b29f315oae9def0f6acb77e1@mail.gmail.com"
type="cite">
<pre wrap="">
On Fri, Nov 20, 2009 at 9:30 AM, Gavin King <a class="moz-txt-link-rfc2396E" href="mailto:gavin.king@gmail.com"><gavin.king@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">We could say that annotating an abstract method of a decorator with
@Inject is a DE. Same for @PostConstruct and @PreDestroy.
Alternatively, we could just say that the container ignores them,
which seems to be more or less what happens if they are declared on an
abstract bean.
What the spec definitely needs to do is say that if an abstract method
of a decorator is called at runtime, an UnsupportedOperationException
results. This is a big oversight.
On Fri, Nov 20, 2009 at 3:19 AM, Marius Bogoevici <a class="moz-txt-link-rfc2396E" href="mailto:mariusb@redhat.com"><mariusb@redhat.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The specification allows for decorators to be abstract classes, but this
is currently not supported in Weld (defect WELD-298).
Since allowing decorator classes to be abstract is the only stated
requirement, here are the general lines I think we should follow for
supporting this:
- abstract decorator classes can have injected fields, injected
constructor parameters and concrete initializer methods, but abstract
initializer methods should be forbidden (DefinitionException), or at the
very least be non-portable.
- abstract decorator classes cannot have abstract decorating methods
(DefinitionException)
WDYT?
Marius
_______________________________________________
weld-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/weld-dev">https://lists.jboss.org/mailman/listinfo/weld-dev</a>
</pre>
</blockquote>
<pre wrap="">
--
Gavin King
<a class="moz-txt-link-abbreviated" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>
<a class="moz-txt-link-freetext" href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a>
<a class="moz-txt-link-freetext" href="http://hibernate.org">http://hibernate.org</a>
<a class="moz-txt-link-freetext" href="http://seamframework.org">http://seamframework.org</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>