[00:40:12] *** aslak has quit IRC
[01:21:10] *** struberg has quit IRC
[02:52:00] *** jbossbot has quit IRC
[03:01:20] *** jbossbot has joined #weld-dev
[09:01:08] *** mbg has quit IRC
[09:14:52] *** stuartdouglas has quit IRC
[09:16:30] *** stuartdouglas has joined #weld-dev
[09:19:46] *** struberg has joined #weld-dev
[11:38:11] *** alesj has joined #weld-dev
[13:21:20] *** struberg has quit IRC
[16:10:18] *** oskutka has joined #weld-dev
[16:11:02] *** oskutka has quit IRC
[18:58:02] *** struberg1 has joined #weld-dev
[19:53:50] *** struberg1 has quit IRC
[19:54:25] *** struberg has joined #weld-dev
[20:29:05] *** struberg has quit IRC
[21:10:27] *** alesj has quit IRC
[21:30:07] *** alesj has joined #weld-dev
[22:12:41] *** struberg has joined #weld-dev
[22:13:58] <alesj> stuartdouglas: http://community.jboss.org/message/617115#617115
[22:26:04] <stuartdouglas> alesj: answered
[22:27:55] <alesj> thanks :-)
[22:28:03] <alesj> stuartdouglas: i guess we're all set for 1.1.2.Final?
[22:28:08] <stuartdouglas> yes
[22:28:27] <stuartdouglas> someone just need to hit the button :-)
[22:28:34] <alesj> can you just check if we have all the stuff from branch 1.1 into master?
[22:28:49] <alesj> as i know that for previous 1.1.1 is cut from 1.1 branch
[22:29:01] <alesj> hopefully i merged things with master :-)
[22:29:30] <struberg> there is a CDI spec issue filled which should fix this broken behaviour
[22:29:48] <struberg> of course only for CDI-1.1 ^^
[22:29:50] <jbossbot> jira [CDI-1] Clarify how resource producer fields (for persistence contexts) interact with transaction propagation [Open (Unresolved) Clarification, Major, Unassigned] https://issues.jboss.org/browse/CDI-1
[22:30:06] <stuartdouglas> alesj: I am about to head to the gym, I'll look into it when I get back
[22:30:57] <struberg> CDI-18
[22:30:58] <jbossbot> jira [CDI-18] Global enablement of interceptors, decorators and alternatives [Open (Unresolved) Feature Request, Critical, Unassigned] https://issues.jboss.org/browse/CDI-18
[22:31:41] <alesj> stuartdouglas: ok, thanks
[22:31:53] <alesj> stuartdouglas: if i'm not online, i'll ping you in the morning
[22:32:14] <alesj> and hopefully cut the release before dmlloyd catches me for AS7+MC stuff :-)
[22:55:08] <stuartdouglas> alesj: back, my trip to the gym did not go as planned
[22:55:40] <stuartdouglas> we were going to check out this new gym, that opened near my place, but when we got there it did not have any actual weights, just bikes and treadmills
[22:55:54] <alesj> bike is cool
[22:56:14] <alesj> i just did 20km today / 45min :-)
[22:56:25] <stuartdouglas> but I am not going to pay $15 to ride a bike in a gym, when I can just ride a real bike :-)
[22:56:34] <alesj> yes, real ride
[22:56:37] <stuartdouglas> there have been so many bike riders around the last two days
[22:56:47] <alesj> never did indoor bike
[22:56:50] <alesj> or some machine
[23:01:20] <alesj> stuartdouglas: ok, please check if the 1.1 and master are in synch
[23:01:39] <alesj> and i'll make sure to get this 1.1.2 beast out tomorrow :-)
[23:01:46] <alesj> with osgi bundle included
[23:01:49] <stuartdouglas> alesj: they appear to be, the only missing commits were to do with the release process
[23:01:57] <stuartdouglas> yea, I just forgot the -Drelease
[23:02:11] <alesj> what's the easiest thing to check if they are in synch ? gitk?
[23:02:25] <stuartdouglas> that was what I used
[23:02:57] <alesj> any idea if you'll have some time to do some 1.2 stuff
[23:03:03] <alesj> e.g. the perf opts we discussed
[23:03:19] <stuartdouglas> The thread local proxy stuff? Thats already done
[23:03:27] <alesj> yeah
[23:03:28] <alesj> i mean
[23:03:37] <alesj> the reflect opts
[23:03:41] <alesj> less metadata
[23:03:51] <alesj> at least keeping it less time
[23:03:56] <alesj> re-using jandex
[23:03:57] <alesj> etc
[23:04:04] <alesj> better bootstrap order
[23:04:16] <stuartdouglas> not in the short term
[23:04:27] <stuartdouglas> there are a few things that I am looking into
[23:04:37] <stuartdouglas> but I don't really think that jandex will help
[23:04:50] <alesj> why not?
[23:04:55] <alesj> the info is there in .index
[23:05:01] <alesj> no need to scan
[23:05:15] <alesj> btw: how do i resolve a conflict in svn from cli?
[23:05:19] <stuartdouglas> a few reasons, 1) we still need to load all the classes for the portable extensions PAT event
[23:05:29] <stuartdouglas> svn or git?
[23:05:32] <alesj> svn
[23:05:35] <alesj> some old code :-)
[23:05:43] <stuartdouglas> isn't it just svn resolve?
[23:05:57] <alesj> never done it form cli, IDEA all the way :-)
[23:06:08] <alesj> let me try
[23:06:18] <stuartdouglas> I have never used a gui for version control
[23:06:41] <stuartdouglas> the other reason is that jandex can be missing some info
[23:06:53] <stuartdouglas> if the class inherits from an external library
[23:07:01] <stuartdouglas> although that is not a huge deal
[23:07:09] <stuartdouglas> but the big reason is 1)
[23:07:24] <stuartdouglas> there are a few places we can improve boot performance
[23:07:53] <stuartdouglas> one of them is the ProcessAnnotatedType event, it goes through all the normal observer resolution code
[23:07:59] <stuartdouglas> with is actually a bit slow
[23:08:12] <stuartdouglas> it may be possible to fire it through an optimised code path
[23:09:04] <alesj> i was thinking of providing some spi for bootstrap
[23:09:14] <stuartdouglas> what sort of api?
[23:09:15] <alesj> for AS7 integration to delegate things to MSC
[23:09:33] <alesj> we need to fix proper bootstrap order
[23:09:42] <alesj> e.g. the specialization thing
[23:09:45] <alesj> WELD-912
[23:09:47] <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
[23:09:53] <stuartdouglas> yea, really we just need to split it into more phases
[23:10:00] <alesj> i did that to some extent
[23:10:03] <stuartdouglas> and change the specialisation code
[23:10:05] <alesj> but it's not enough
[23:10:12] <stuartdouglas> so it actually looks into other bean archives
[23:10:28] <alesj> we need a proper graph of how to bootstrap things
[23:10:32] <alesj> and that, yes
[23:11:11] <alesj> can you do some work on ProcessAnnotatedType?
[23:11:16] <alesj> and i'll check the other things
[23:11:32] <stuartdouglas> what sort of time frame are we looking at for 1.2?
[23:11:48] <alesj> hmmm ...
[23:11:56] <alesj> when is 7.0.1 planned?
[23:12:10] <alesj> i would say at least a month
[23:12:12] <alesj> if not even more
[23:12:26] <alesj> as we all have other things to do as well
[23:12:29] <stuartdouglas> 7.0.1 will be out fairly soon
[23:12:32] <alesj> but defintely before J1
[23:12:39] <alesj> which is in start of Oct
[23:13:25] <stuartdouglas> ok, I should have time to look at that before then
[23:13:46] <alesj> cool
[23:14:05] <alesj> do you know which additional scopes does CODI provide?
[23:14:18] <alesj> i saw some Window scope?
[23:14:24] <stuartdouglas> ViewScoped and WindowScoped I think
[23:14:40] <struberg> + ViewAccessScoped
[23:14:52] <struberg> + ConversationScoped
[23:15:01] <struberg> (a different one than the CDI one)
[23:15:36] <alesj> diff how>
[23:15:38] <alesj> ?
[23:15:42] <struberg> btw, the CDI ConversationScoped is broken heavily
[23:15:47] <struberg> but we cant fix that in the spec
[23:15:59] <alesj> yeah, it's not the best ...
[23:16:02] <struberg> it's not bound to any request but bound to beans
[23:16:10] <struberg> and it starts eagerly
[23:16:30] <struberg> so all the validation stuff just works
[23:16:53] <struberg> without creating new beans over and over again like with the CDI default one
[23:17:16] <struberg> there are also ConversationGroups
[23:17:30] <struberg> automatically and programmatically managable
[23:17:35] <alesj> i need to have a closer look then :-)
[23:17:45] <struberg> mom we have a Wiki
[23:17:57] <alesj> http://myfaces.apache.org/extensions/cdi/
[23:18:35] <struberg> yes, there is a wiki link too
[23:20:36] <alesj> ok, i'll definitely have a closer look at this scopes
[23:21:26] <struberg> https://cwiki.apache.org/confluence/display/EXTCDI/Core+Usage#CoreUsage-Scope%2FConversation
[23:22:20] <alesj> struberg: thanks
[23:23:59] <struberg> with binding conversations to beans instead of just splitting the session, we also don't need any sub-conversations
[23:24:05] <struberg> they just work out of the box
[23:24:28] <stuartdouglas> I probably should look at the performance of the custom scopes in weld as well
[23:24:52] <struberg> you have a CarEdit bean which is in the CarEdit conversation and you can easily open a CustomerSearch conversation from inside the CarEdit
[23:25:13] <struberg> yup good idea
[23:25:47] <stuartdouglas> I found out yesterday that annotations with no members have a hashCode of 0
[23:25:51] <struberg> and please do testing with WARs
[23:26:02] <struberg> EARs are utterly non-portable atm
[23:26:02] <stuartdouglas> which seems really stupid :-(
[23:26:31] <struberg> hmm dont remember having seen such things
[23:26:38] <stuartdouglas> I wonder if this is affecting our performance, as I think we do a lot of comparisons on sets on annotations
[23:26:49] <struberg> an AnnotationLiteral is just an instance extending Object
[23:27:00] <struberg> so it must have a hashCode depending on the instance by default
[23:27:13] <stuartdouglas> struberg: have a look in the annotation javadoc for it's hashCode method
[23:27:23] <struberg> oki txs
[23:27:27] <stuartdouglas> the hasCode is defined in terms of the hashCode of it's members
[23:27:34] <stuartdouglas> no members = 0 hashCode
[23:35:56] *** struberg has quit IRC
[23:38:04] <stuartdouglas> wow, there is a big performance difference between @ViewAccessScoped and @RequestScoped
[23:42:46] *** struberg has joined #weld-dev
[23:46:39] <alesj> stuartdouglas: in what case?
[23:47:28] <stuartdouglas> just in general, I have the benchmark that the own guys were running, and changing a request scoped bean to @ViewAccessScoped dropped the throughput considerably
[23:49:51] <struberg> thats clean because viewAccessScoped does much more
[23:50:01] <struberg> and we cannot do any special proxy stuff easily
[23:50:08] <struberg> for 3rd party contexts
[23:50:17] <stuartdouglas> it looks like part of it may already be fixed in 1.1.2 master, as I am testing with an older version





top