[00:36:09] *** johnament has joined #weld-dev
[00:40:01] *** aslak has quit IRC
[00:50:23] *** alesj has quit IRC
[03:59:37] *** rruss has quit IRC
[04:11:55] *** johnament has quit IRC
[05:01:04] *** magesh has joined #weld-dev
[08:03:23] *** aslak has joined #weld-dev
[09:10:02] *** kevinpollet has joined #weld-dev
[09:13:44] *** oskutka has joined #weld-dev
[09:17:47] *** rruss has joined #weld-dev
[09:18:07] *** rruss has quit IRC
[09:21:32] *** oskutka has quit IRC
[10:02:33] *** sbryzak has quit IRC
[10:38:46] *** oskutka has joined #weld-dev
[10:38:50] *** alesj has joined #weld-dev
[10:43:12] *** oskutka has quit IRC
[10:49:33] *** epbernard has joined #weld-dev
[11:07:14] *** sbryzak has joined #weld-dev
[11:07:15] *** sbryzak has joined #weld-dev
[11:47:09] <alesj> stuartdouglas: ping?
[11:47:14] <stuartdouglas> alesj: pong
[11:47:19] <alesj> hey
[11:47:31] <alesj> looking at TypeLiteral, and wondering how this actually works :-)
[11:48:05] <alesj> how come we're able to get actual type at runtime?
[11:48:32] <stuartdouglas> because not all type info is erased
[11:48:37] <alesj> stuartdouglas: i guess that superclass trick does it?
[11:48:42] <stuartdouglas> you can still get it out of the reflection api
[11:48:51] <stuartdouglas> what exactly are you not sure about?
[11:49:31] <alesj> usually if i say, List<String> in the code in the middle of a method
[11:49:40] <alesj> there is no way i can get that String, right?
[11:49:44] <stuartdouglas> that gets erased
[11:49:53] <stuartdouglas> but if you have a field that is List<String>
[11:50:01] <stuartdouglas> you can use Field.getGenericType()
[11:50:02] <alesj> sure, that stays
[11:50:35] *** struberg1 has joined #weld-dev
[11:50:36] <alesj> but can i say TypeLiteral<String> in the middle of my code, and get that String?
[11:50:46] <stuartdouglas> no
[11:50:46] <alesj> middle of method
[11:51:00] <alesj> ah, ok, that's what confused me then
[11:51:00] <stuartdouglas> TypeLiteral is like AnnotationLiteral
[11:51:08] <alesj> i thought you could
[11:51:29] <alesj> as i thought i saw this usage in Guice ...
[11:51:37] <stuartdouglas> it just allows you to easily create ParametizedType, WildcardType impls
[11:51:43] <stuartdouglas> that are normally provided by the JDK
[11:55:09] *** maschmid has joined #weld-dev
[11:56:05] <alesj> stuartdouglas: how do we then use TypeLiteral in our code?
[11:58:11] <stuartdouglas> new TypeLiteral<List<String>>() {}.getType()
[11:59:35] <alesj> yeah, but what's the use case?
[12:01:16] <alesj>       public Type getType()
[12:01:16] <alesj>       {
[12:01:17] <alesj>          if (type == null)
[12:01:17] <alesj>          {
[12:01:17] <alesj>             this.type = new TypeLiteral<Instance<Object>>(){}.getType();
[12:01:27] <alesj> what would this return?
[12:02:04] <alesj> ParameterizedType of Instance<Object>?
[12:02:06] <alesj> stuartdouglas: ^
[12:03:04] *** aslak has quit IRC
[12:03:04] *** oskutka has joined #weld-dev
[12:08:45] *** oskutka has quit IRC
[12:10:16] *** oskutka has joined #weld-dev
[12:11:25] *** magesh is now known as magesh_away
[12:12:00] *** epbernard has quit IRC
[12:16:31] <alesj> stuartdouglas: you actually can do this in the middle of the method ;-)
[12:16:53] <alesj> and get all generics info
[12:19:24] <struberg1> stuartdoublas ping
[12:19:31] <struberg1> stuartdouglas :)
[12:19:46] <struberg1> does Weld allos @Disposes for producer fields?
[12:20:01] <struberg1> havent tested it but got a report from an OWB user
[12:20:12] <struberg1> which created an EntityManager per producer FIELD
[12:20:15] *** kevinpollet has quit IRC
[12:20:24] <struberg1> and we cannot dispose it
[12:20:48] <struberg1> 3.3.7 only talks about producer methods
[12:20:49] <struberg1> 3.3.7. Disposer method resolution
[12:20:49] <struberg1> A disposer method is bound to a producer method if:
[12:20:49] <struberg1> ?	the producer method is declared by the same bean class as the disposer method, and
[12:20:49] <struberg1> ?	the producer method is assignable to the disposed parameter, according to the rules of typesafe resolution defined in Section 5.2, ?Typesafe resolution? (using Section 5.2.3, ?Assignability of raw and parameterized types?).
[12:21:06] <struberg1> should I create a CDI issue?
[12:21:38] <alesj> struberg1: what's the issue? or why doesn't plain @Dispose mathod with right params work?/
[12:21:55] <struberg1> because its not stated in the spec ;)
[12:22:02] <stuartdouglas> struberg1: afaik it only works for producer methods
[12:22:07] <alesj> ah, minor detail ;-)
[12:22:13] <struberg1> heh yup, but a gory ;)
[12:22:21] <struberg1> I'll go on and create a CDI clarification issue ;)
[12:22:33] <struberg1> do you have any argument against it?
[12:22:49] <struberg1> thought that should be easy to do
[12:23:39] *** epbernard has joined #weld-dev
[12:24:39] <alesj> stuartdouglas: so, back to TypeLiteral ? how come genericsuperclass is around for runtime code this time?
[12:25:11] <alesj> since that looks like what TL is "abusing" to get the right generic info
[12:27:57] <stuartdouglas> it's because you sub class TypeLiteral
[12:28:23] <stuartdouglas> note the {} in the usage, so you create an ananomouse inner class
[12:28:30] <alesj> yeah
[12:28:37] <alesj> hence the superclass lookup
[12:28:37] <stuartdouglas> that has a super class of TypeLiteral<List<String>>
[12:29:12] <alesj> and this generic info sticks around
[12:29:25] <nickarls> (shameless interruption): regarding WELD-912 ,is it the DeploymentVisitor that would need to make a pass first and order the dependencies?
[12:29:27] <jbossbot> jira [WELD-912] Specializing beans in different bean archives does not work [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/WELD-912
[12:29:37] <stuartdouglas> yea, you can get the info via getGenericSuperclass
[12:29:56] <nickarls> (well, order the deployment order according to dependencies)
[12:29:57] <stuartdouglas> not sure off the top of my head
[12:30:11] <stuartdouglas> it's not so much ordering that it has to do
[12:30:19] <stuartdouglas> as there could be dependencies both ways
[12:30:25] <stuartdouglas> it's more of a multi pass type thing
[12:31:00] <alesj> nickarls: yeah, i think we need to break down beans & co. into small state-machine components
[12:31:08] <alesj> and order this properly
[12:31:15] <alesj> e.g. MSC like
[12:32:00] <nickarls> pete spoke at one point of making beans immutable, this could probably be done with the same mechanism (ordering or multi-pass)?
[13:10:18] *** oskutka has quit IRC
[13:42:19] *** kevinpollet has joined #weld-dev
[13:45:40] *** aslak has joined #weld-dev
[13:48:52] *** kevinpollet is now known as pseudo
[13:49:22] *** pseudo has left #weld-dev
[13:49:34] *** kevinpollet has joined #weld-dev
[14:02:25] *** rmartinelli has joined #weld-dev
[14:17:05] *** magesh_away is now known as magesh
[14:50:02] *** struberg1 has quit IRC
[14:50:21] *** alesj has quit IRC
[14:50:33] *** alesj has joined #weld-dev
[14:50:36] *** struberg has joined #weld-dev
[14:55:50] *** maschmid has quit IRC
[15:21:55] *** pmuir has joined #weld-dev
[15:21:55] *** pmuir has quit IRC
[15:21:55] *** pmuir has joined #weld-dev
[15:46:22] *** rruss has joined #weld-dev
[15:50:37] *** rruss has quit IRC
[16:03:22] *** magesh has left #weld-dev
[16:07:00] *** maschmid has joined #weld-dev
[16:18:29] *** rruss has joined #weld-dev
[16:18:52] *** rruss has quit IRC
[16:21:01] *** rruss has joined #weld-dev
[16:21:32] *** rruss has quit IRC
[17:11:46] *** alesj has quit IRC
[17:37:20] *** epbernard is now known as emmanuel
[17:41:02] *** kevinpollet has quit IRC
[18:36:21] *** kevinpollet has joined #weld-dev
[18:45:08] *** maschmid has quit IRC
[19:03:07] *** cbrock has joined #weld-dev
[19:06:47] *** emmanuel has quit IRC
[19:28:12] *** aslak has quit IRC
[19:28:32] *** aslak has joined #weld-dev
[19:48:33] *** kevinpollet has quit IRC
[20:44:10] *** kevinpollet has joined #weld-dev
[21:26:52] *** pmuir has quit IRC
[22:05:18] *** rruss has joined #weld-dev
[23:23:25] *** oskutka has joined #weld-dev
[23:45:03] *** kevinpollet has quit IRC





top