[04:31:39] *** OndraZizka has quit IRC
[04:31:55] *** OndraZizka has joined #weld-dev
[04:32:12] *** OndraZizka has left #weld-dev
[18:15:53] *** struberg has joined #weld-dev
[18:18:04] <struberg> stuartdouglas ping
[18:19:05] <struberg> all the TCK tests in the 'broken' package are not executed, right?
[18:19:16] <struberg> thus most of the 6.6.4 tests are not tested
[18:19:25] <struberg> and weld doesn't do a few checks it should do
[18:19:35] <struberg> which leads to seam does work in weld but not in OWB
[18:19:44] <struberg> because we _do_ this tests ;)
[19:30:31] <struberg> stu ping
[19:32:58] <struberg> It seems that EnvironmentUtils#isEEEnvironment() doesn't work relyably
[19:45:16] *** aslak has joined #weld-dev
[19:47:05] *** struberg has quit IRC
[19:48:41] *** aslak has quit IRC
[19:52:51] *** struberg has joined #weld-dev
[20:02:20] *** struberg has quit IRC
[20:08:09] *** struberg has joined #weld-dev
[20:28:48] *** struberg has quit IRC
[20:29:11] *** struberg has joined #weld-dev
[21:24:05] *** struberg has quit IRC
[21:37:25] *** struberg has joined #weld-dev
[22:22:49] *** alesj has joined #weld-dev
[23:18:02] <stuartdouglas> struberg: pong
[23:18:34] <struberg> ahoi
[23:18:36] <struberg> got my mail?
[23:18:44] <stuartdouglas> yes, just replying to it now
[23:18:46] <struberg> seems that the DefaultBean isnt working at all in OWB
[23:19:01] <stuartdouglas> any idea why not?
[23:19:25] <struberg> this Synthetic stuff is just not a Qualifier ^^
[23:19:50] <struberg> the beans have the following qualifier: @org.jboss.seam.solder.reflection.Synthetic(index=3, namespace="org.jboss.seam.solder.defaultbean")
[23:20:11] <stuartdouglas> synthetic is a qualifier
[23:20:23] <struberg> but not == @Default!
[23:20:45] <alesj> stuartdouglas: got my email about weld-osgi bundle?
[23:21:00] <stuartdouglas> alesj: yes, I am not sure why that did not make it into the repo
[23:21:14] <stuartdouglas> I have never released weld before so maybe I did something wrong
[23:21:33] <alesj> can we somehow push this in now?
[23:21:59] <stuartdouglas> not sure, I think it should be possible, but I would have to read up on how to do it
[23:22:11] <alesj> or, perhaps reply on the email, check if pmuir is in Cc, and see if he knows how to do this
[23:22:25] <alesj> or/and why it didn't make it in in the 1st place
[23:22:36] <stuartdouglas> struberg: @Synthetic is used to 'hide' the original definition of the bean
[23:23:04] <struberg> but it doesnt get used at the injection point
[23:23:15] <struberg> so this thing does never resolve
[23:23:17] <stuartdouglas> A new bean is then installed that wraps the hidden one with different qualifiers
[23:23:27] <struberg> why all this?
[23:24:15] <stuartdouglas> basically the idea is that if the user does not supply there own bean that meets the injection point, solder provides one for them
[23:24:36] <struberg> thats whyt @Specializes is for
[23:24:39] <struberg> and @Alternative
[23:24:46] <struberg> so why introduce just another mechanism?
[23:24:58] <struberg> another _eeeeexpensive_ mechanism
[23:25:06] <struberg> (I should add more e)
[23:25:09] <stuartdouglas> there were a couple of reasons
[23:25:27] <stuartdouglas> this does not require any configuration on the users part
[23:26:17] <stuartdouglas> and in some cases it provides for completely transparent overriding, e.g. if you add the Faces module the EL extension provided by solder will automatically use the faces ELContext
[23:27:26] <struberg> but that is internal stuff
[23:27:44] <struberg> so why not just use the mechanics which are _specially_ made for such cases in the spec?
[23:28:07] <stuartdouglas> yea, thinking about it now the benefits do not really outweigh the cost
[23:28:33] <struberg> at least it's _extremely' expensive to do all this scanning
[23:28:41] <struberg> did you folks try this all on a FAT project?
[23:28:49] <stuartdouglas> struberg: @Specializes only works for concrete classes, not interfaces
[23:29:01] <struberg> if people post that their dummy playground projects take 7 seconds just for scanning
[23:29:14] <struberg> then I fear really worse things for a FAT real world project with 5000++ classes
[23:29:28] <struberg> for interfaces you don't need anything
[23:29:35] <stuartdouglas> struberg: and to use @Alternative you need to open up the solder jar and change it's beans.xml
[23:29:55] <stuartdouglas> also @Specialises does not really work properly in weld at the moment
[23:29:56] <struberg> not if we finally fix the BDA definition stuff
[23:30:11] <struberg> I told Gavin 2 years ago that this is utterly broken
[23:30:19] <stuartdouglas> yea, that is horrible
[23:31:31] <struberg> thats why I meant to ship a small maintenance release of the 1.0 CDI spec
[23:31:35] <stuartdouglas> struberg: I did some performance testing with weld se close to a year ago now, with solder and 10,000 classes I was seeing startup times of around 12s I think
[23:31:37] <struberg> with this part clarified
[23:31:44] <struberg> because the spec contradicts itself a bit in this area
[23:32:02] <struberg> 12s on 10000 classes is quite fine
[23:32:12] <struberg> I just read the recent mail on the seam-dev list
[23:32:22] <struberg> and that one sounded pretty horrible to be honest ;)
[23:33:51] <struberg> still digging why I cannot resolve the qualifier
[23:35:44] <struberg> stu: is there some code in seam which also swaps out the Qualifiers for each and every injection point?
[23:36:14] <stuartdouglas> there used to be, that was some code that gavin wrote really early on
[23:36:17] <stuartdouglas> that I removed
[23:36:36] <struberg> and how is this working in Weld?
[23:37:00] <stuartdouglas> That code was removed ages ago
[23:37:06] <struberg> I mean I have an injection point which has FlushModeManagerImpl wth Qualifier @Default
[23:37:16] <struberg> @Inject FlushModeManager fmm;
[23:37:39] <struberg> and the Bean just provides FlushModeManagerImpl with Qualifier @Synthetic
[23:37:44] <struberg> so how does it work?
[23:37:53] <struberg> I wonder how this works in weld
[23:38:12] <stuartdouglas> In afterBeanDiscovery it should realise that there is no FlushModeManager that has been provided
[23:38:15] <stuartdouglas> and install the default one
[23:39:29] <struberg> which class?
[23:39:54] <stuartdouglas> DefaultBeanExtension.afterBeanDiscovery
[23:40:25] <struberg> haha lol
[23:40:29] <struberg> oki this cant ever work
[23:40:34] <struberg> this  is random stuff I fear
[23:40:41] <struberg> there are multiple afterBeanDiscovery
[23:40:47] <struberg> 1 which addBean()
[23:40:55] <struberg> 2.) which swaps the Synthetic stuff
[23:40:58] <struberg> guess what...
[23:41:15] <stuartdouglas> what other afterBeanDiscovery?
[23:42:21] <struberg> ManagedPersistenceContextExtension
[23:43:12] <stuartdouglas> the SMPC is not a default bean
[23:43:51] <struberg> but the FlushModeManager is used exactly in that very bean
[23:44:02] <struberg> thus it gets transitively resolved
[23:44:19] <struberg> thats what it looks like at least
[23:44:23] <stuartdouglas> what, are you resolving at addBean?
[23:44:36] <stuartdouglas> you can't do that, there might be more beans to come
[23:45:05] <struberg> I dont resolve in addBean
[23:45:27] <struberg> mom need to take a closer look
[23:49:39] <stuartdouglas> The thing is that any extension that wants to deal with an annotation on a field does not have any other way of doing it other than just iterating over the fields
[23:50:14] <stuartdouglas> and also there is no addAnnotatedType that can be used after all the installed beans have been seen
[23:50:32] <stuartdouglas> IMHO these two things are two of the biggest problems that the SPI has
[23:51:50] <stuartdouglas> also while the event based SPI seems to fit in with the CDI programming model, it's performance is kinda terrible, and it is not as convenient as an SPI that just handed you all the beans etc
[23:51:58] <stuartdouglas> instead of having to observe them one at a time
[23:58:14] <struberg> yup this also has downsides





top