12:28 p.m.
In several places, the specification reiterates that an event type may not
contain a type variable. However, it appears that this restriction is only
enforced at runtime when the event object is passed to either Event#fire()
or BeanManager#fireEvent() method. I would suggest that an validation check
be added so that the container detects an illegal Event definition at
deployment type. Here's an example of an illegal definition (from my
understanding):
public class VoterRegistration<T> { ... }
@Any Event<VoterRegistration<Democrat>> democratRegisteredEvent;
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
12:41 p.m.
On Fri, 2009-07-24 at 12:28 -0400, Dan Allen wrote:
In several places, the specification reiterates that an event type
may
not contain a type variable. However, it appears that this restriction
is only enforced at runtime when the event object is passed to either
Event#fire() or BeanManager#fireEvent() method. I would suggest that
an validation check be added so that the container detects an illegal
Event definition at deployment type. Here's an example of an illegal
definition (from my understanding):
public class VoterRegistration<T> { ... }
@Any Event<VoterRegistration<Democrat>> democratRegisteredEvent;
What is illegal about this definition? The Event declaration does not
contain any type variables or wildcards as you have written it here.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
12:46 p.m.
No, the spec prohibits type variables in event objects and event
types, it doesn't prohibit type parameters.
This isn't legal
public class Foo{
@Produces <T> Bar make(@Any Event<T> event) {
...
}
and we do need to error at deployment time for such a declaration. Do
we?
What you show *is* valid.
It's also not valid to actually pass an event object with a type
variable, but it's extremely hard to actually find code that will
compile and pass the above deployment test, but still do this and do
this so I can't find an example right now ;-)
On 24 Jul 2009, at 17:28, Dan Allen wrote:
In several places, the specification reiterates that an event type
may not contain a type variable. However, it appears that this
restriction is only enforced at runtime when the event object is
passed to either Event#fire() or BeanManager#fireEvent() method. I
would suggest that an validation check be added so that the
container detects an illegal Event definition at deployment type.
Here's an example of an illegal definition (from my understanding):
public class VoterRegistration<T> { ... }
@Any Event<VoterRegistration<Democrat>> democratRegisteredEvent;
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
1 p.m.
On Fri, 2009-07-24 at 17:46 +0100, Pete Muir wrote:
No, the spec prohibits type variables in event objects and event
types, it doesn't prohibit type parameters.
This isn't legal
public class Foo{
@Produces <T> Bar make(@Any Event<T> event) {
...
}
and we do need to error at deployment time for such a declaration. Do
we?
There already is a test exactly like this:
org.jboss.jsr299.tck.tests.event.broken.inject.withTypeVariable.EventInjectionWithUndefinedTypeVariableTest,
but apparently the RI does not detect the error. The test is also not currently assigned
to any assertion, but the spec clearly states that this is not allowed; however, it states
that a IllegalArgumentException is to be thrown, both runtime and not (Section 10.3.1).
What you show *is* valid.
It's also not valid to actually pass an event object with a type
variable, but it's extremely hard to actually find code that will
compile and pass the above deployment test, but still do this and do
this so I can't find an example right now ;-)
On 24 Jul 2009, at 17:28, Dan Allen wrote:
> In several places, the specification reiterates that an event type
> may not contain a type variable. However, it appears that this
> restriction is only enforced at runtime when the event object is
> passed to either Event#fire() or BeanManager#fireEvent() method. I
> would suggest that an validation check be added so that the
> container detects an illegal Event definition at deployment type.
> Here's an example of an illegal definition (from my understanding):
>
> public class VoterRegistration<T> { ... }
>
> @Any Event<VoterRegistration<Democrat>> democratRegisteredEvent;
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://in.relation.to/Bloggers/Dan
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
5:05 p.m.
There already is a test exactly like this:
org.jboss.jsr299.tck.tests.event.broken.inject.withTypeVariable.EventInjectionWithUndefinedTypeVariableTest,
but apparently the RI does not detect the error. The test is also not
currently assigned to any assertion, but the spec clearly states that this
is not allowed; however, it states that a IllegalArgumentException is to be
thrown, both runtime and not (Section 10.3.1).
I'm currently reviewing all the tests and assertions for events, so I'll
cover this oversight.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
5:03 p.m.
I'm going to tread carefully when arguing this point because I am far from a
master at generics. Unfortunately, it seems that the non-normative section
of the generics documentation is not consistent with the generics API. For
instance, in the documentation, a type parameter is described as a special
kind of type variable. But in the generics API, they are two separate things
(ParameterizedType and TypeVariable). But I may be mistaken.
With that said, the example I gave fails in Web Beans. Let me give a full
example:
public class Artist<T> { ... }
public class Solo { ... }
public class TuneSelect {
@Any Event<Artist<Solo>> soloArtistEvent;
public void soloArtistPlaying(Artist<Solo> artist)
{
soloArtistEvent.fire(artist);
}
}
Here's the exception Web Beans spits out.
java.lang.IllegalArgumentException: Event type
org.jboss.jsr299.tck.tests.event.eventTypes.Artist is not allowed because it
is a generic
at
org.jboss.webbeans.BeanManagerImpl.fireEvent(BeanManagerImpl.java:798)
at org.jboss.webbeans.event.EventImpl.fire(EventImpl.java:76)
=> same result for soloArtistEvent.fire(new Artist<Solo>())
If you believe that should be valid, then I will simply mark it as
ri-broken.
I see what you are saying though in that what is not allowed is a type which
is tied to the method parameters, hence acting as a type variable.
-Dan
On Fri, Jul 24, 2009 at 12:46 PM, Pete Muir <pmuir(a)redhat.com> wrote:
No, the spec prohibits type variables in event objects and event
types, it
doesn't prohibit type parameters.
This isn't legal
public class Foo{
@Produces <T> Bar make(@Any Event<T> event) {
...
}
and we do need to error at deployment time for such a declaration. Do we?
What you show *is* valid.
It's also not valid to actually pass an event object with a type variable,
but it's extremely hard to actually find code that will compile and pass the
above deployment test, but still do this and do this so I can't find an
example right now ;-)
On 24 Jul 2009, at 17:28, Dan Allen wrote:
In several places, the specification reiterates that an event type may not
> contain a type variable. However, it appears that this restriction is only
> enforced at runtime when the event object is passed to either Event#fire()
> or BeanManager#fireEvent() method. I would suggest that an validation check
> be added so that the container detects an illegal Event definition at
> deployment type. Here's an example of an illegal definition (from my
> understanding):
>
> public class VoterRegistration<T> { ... }
>
> @Any Event<VoterRegistration<Democrat>> democratRegisteredEvent;
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://in.relation.to/Bloggers/Dan
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
7:13 a.m.
On 24 Jul 2009, at 22:03, Dan Allen wrote:
I'm going to tread carefully when arguing this point because I am
far from a master at generics. Unfortunately, it seems that the non-
normative section of the generics documentation is not consistent
with the generics API. For instance, in the documentation, a type
parameter is described as a special kind of type variable. But in
the generics API, they are two separate things (ParameterizedType
and TypeVariable). But I may be mistaken.
I would advise using the JLS which clearly describes type variables
and type parameters as two separate things which don't form a parent-
child structure.
With that said, the example I gave fails in Web Beans. Let me give a
full example:
public class Artist<T> { ... }
public class Solo { ... }
public class TuneSelect {
@Any Event<Artist<Solo>> soloArtistEvent;
public void soloArtistPlaying(Artist<Solo> artist)
{
soloArtistEvent.fire(artist);
}
}
Here's the exception Web Beans spits out.
java.lang.IllegalArgumentException: Event type
org.jboss.jsr299.tck.tests.event.eventTypes.Artist is not allowed
because it is a generic
at
org.jboss.webbeans.BeanManagerImpl.fireEvent(BeanManagerImpl.java:798)
at org.jboss.webbeans.event.EventImpl.fire(EventImpl.java:76)
=> same result for soloArtistEvent.fire(new Artist<Solo>())
If you believe that should be valid, then I will simply mark it as
ri-broken.
Right this should pass. Please make sure you also file a WBRI - every
time you mark something ri-broken, it needs an associated WBRI...
BTW this is quite easy to fix - we need to upgrade events to use the
type parameter resolution stuff that Takeshi wrote for us.
I see what you are saying though in that what is not allowed is a
type which is tied to the method parameters, hence acting as a type
variable.
-Dan
On Fri, Jul 24, 2009 at 12:46 PM, Pete Muir <pmuir(a)redhat.com> wrote:
No, the spec prohibits type variables in event objects and event
types, it doesn't prohibit type parameters.
This isn't legal
public class Foo{
@Produces <T> Bar make(@Any Event<T> event) {
...
}
and we do need to error at deployment time for such a declaration.
Do we?
What you show *is* valid.
It's also not valid to actually pass an event object with a type
variable, but it's extremely hard to actually find code that will
compile and pass the above deployment test, but still do this and do
this so I can't find an example right now ;-)
On 24 Jul 2009, at 17:28, Dan Allen wrote:
In several places, the specification reiterates that an event type
may not contain a type variable. However, it appears that this
restriction is only enforced at runtime when the event object is
passed to either Event#fire() or BeanManager#fireEvent() method. I
would suggest that an validation check be added so that the
container detects an illegal Event definition at deployment type.
Here's an example of an illegal definition (from my understanding):
public class VoterRegistration<T> { ... }
@Any Event<VoterRegistration<Democrat>> democratRegisteredEvent;
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
7:28 a.m.
On Fri, 2009-07-24 at 17:03 -0400, Dan Allen wrote:
I'm going to tread carefully when arguing this point because I am
far
from a master at generics. Unfortunately, it seems that the
non-normative section of the generics documentation is not consistent
with the generics API. For instance, in the documentation, a type
parameter is described as a special kind of type variable. But in the
generics API, they are two separate things (ParameterizedType and
TypeVariable). But I may be mistaken.
With that said, the example I gave fails in Web Beans. Let me give a
full example:
public class Artist<T> { ... }
public class Solo { ... }
public class TuneSelect {
@Any Event<Artist<Solo>> soloArtistEvent;
public void soloArtistPlaying(Artist<Solo> artist)
{
soloArtistEvent.fire(artist);
}
}
Here's the exception Web Beans spits out.
java.lang.IllegalArgumentException: Event type
org.jboss.jsr299.tck.tests.event.eventTypes.Artist is not allowed
because it is a generic
at
org.jboss.webbeans.BeanManagerImpl.fireEvent(BeanManagerImpl.java:798)
at org.jboss.webbeans.event.EventImpl.fire(EventImpl.java:76)
=> same result for soloArtistEvent.fire(new Artist<Solo>())
If you believe that should be valid, then I will simply mark it as
ri-broken.
This has been fixed. A really long time ago event objects were supposed
to be simple types. This just never got changed in the bean manager.
I see what you are saying though in that what is not allowed is a type
which is tied to the method parameters, hence acting as a type
variable.
-Dan
On Fri, Jul 24, 2009 at 12:46 PM, Pete Muir <pmuir(a)redhat.com> wrote:
No, the spec prohibits type variables in event objects and
event types, it doesn't prohibit type parameters.
This isn't legal
public class Foo{
@Produces <T> Bar make(@Any Event<T> event) {
...
}
and we do need to error at deployment time for such a
declaration. Do we?
What you show *is* valid.
It's also not valid to actually pass an event object with a
type variable, but it's extremely hard to actually find code
that will compile and pass the above deployment test, but
still do this and do this so I can't find an example right
now ;-)
On 24 Jul 2009, at 17:28, Dan Allen wrote:
In several places, the specification reiterates that
an event type may not contain a type variable.
However, it appears that this restriction is only
enforced at runtime when the event object is passed to
either Event#fire() or BeanManager#fireEvent() method.
I would suggest that an validation check be added so
that the container detects an illegal Event definition
at deployment type. Here's an example of an illegal
definition (from my understanding):
public class VoterRegistration<T> { ... }
@Any Event<VoterRegistration<Democrat>>
democratRegisteredEvent;
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in
Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
7:39 a.m.
On 25 Jul 2009, at 12:28, David Allen wrote:
> If you believe that should be valid, then I will simply mark it
as
> ri-broken.
This has been fixed. A really long time ago event objects were
supposed
to be simple types. This just never got changed in the bean manager.
Ok, we will need to rework all this code so that this work is done
using type variable resolution - doing it any other way introduces
subtle inheritance bugs.
This whole area needs a big rework, we seem to do the same checks over
and over, and not properly use the utility routines (for example we do
exactly these checks in checkEventType, again not using the resolved
parameters).
WBRI-299
12:17 p.m.
This whole area needs a big rework, we seem to do the same checks over and
over, and not properly use the utility routines (for example we do exactly
these checks in checkEventType, again not using the resolved parameters).
WBRI-299
I could help but notice the significance of the issue number ;)
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
5:46 p.m.
On Fri, Jul 24, 2009 at 12:46 PM, Pete Muir<pmuir(a)redhat.com> wrote:
This isn't legal
public class Foo{
@Produces <T> Bar make(@Any Event<T> event) {
...
}
Actually that *is* legal. Except for the @Produces annotation (not
sure what that's doing there).
Section 10.4.1 says:
"The event parameter type may contain a type variable or wildcard."
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5:49 p.m.
I guess I should elaborate. Event object types may not contain type
variables. Event parameter types may. If you think about nothing else
but this problem for about three days without stopping to eat or
drink, it will become incredibly clear why this is the only thing that
could possibly be correct. :-)
On Wed, Aug 5, 2009 at 5:46 PM, Gavin King<gavin.king(a)gmail.com> wrote:
On Fri, Jul 24, 2009 at 12:46 PM, Pete Muir<pmuir(a)redhat.com>
wrote:
> This isn't legal
>
> public class Foo{
>
> @Produces <T> Bar make(@Any Event<T> event) {
> ...
>
> }
Actually that *is* legal. Except for the @Produces annotation (not
sure what that's doing there).
Section 10.4.1 says:
"The event parameter type may contain a type variable or wildcard."
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
7:53 a.m.
On 5 Aug 2009, at 22:46, Gavin King wrote:
On Fri, Jul 24, 2009 at 12:46 PM, Pete Muir<pmuir(a)redhat.com>
wrote:
> This isn't legal
>
> public class Foo{
>
> @Produces <T> Bar make(@Any Event<T> event) {
> ...
>
> }
Actually that *is* legal. Except for the @Produces annotation (not
sure what that's doing there).
I'm injecting an Event object into a Producer method. That seems
totally valid to me?
5375
days inactive
5388
days old
12 comments
4 participants
participants (4)
-
Dan Allen -
David Allen -
Gavin King -
Pete Muir