[00:08:20] *** struberg has joined #weld-dev
[00:34:24] *** kevinpollet has quit IRC
[00:39:50] *** struberg has quit IRC
[00:40:17] *** rmartinelli_ has joined #weld-dev
[00:42:21] *** mbg has quit IRC
[00:42:50] *** mbg has joined #weld-dev
[00:43:23] *** rmartinelli has quit IRC
[00:45:35] *** struberg has joined #weld-dev
[00:45:55] <struberg> stu mbg I have a question regarding a TCK test
[00:45:57] <struberg> https://issues.apache.org/jira/browse/OWB-589
[00:46:17] <struberg> @Produces
[00:46:17] <struberg> @MyOwnQualifier
[00:46:17] <struberg> public String getSomeString(NonserializableDependency dependency) {
[00:46:17] <struberg> return dependency.getSomeString();
[00:46:17] <struberg> }
[00:46:18] *** rmartinelli_ has quit IRC
[00:46:33] <struberg> according to martin koci this used to work in welc-1.1.1
[00:46:38] <struberg> but there is a TCK test for it
[00:46:50] <struberg> PassivatingProducerMethodWithNonPassivatingParameterTest
[00:46:56] <struberg> testing exactly that
[00:47:10] <struberg> did this get excluded in the weld-1.1.1 build?
[00:47:24] <stuartdouglas> I don't think so
[00:47:39] <struberg> but the TCK test checks exactly that
[00:47:56] <struberg> I know that we fixed that restriction in CDI-1.1
[00:47:57] <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
[00:48:03] <struberg> but the current TCK just tests for it
[00:48:26] <stuartdouglas> struberg: it should only fail if the producer is non-dependent soped
[00:48:35] <stuartdouglas> the test producer is @SessionScoped
[00:48:43] <stuartdouglas> the example is your jira is @Dependent
[00:49:42] <struberg> stu nope
[00:49:54] <struberg> it must also fail for @SessionScoped producers according to the CDI-1.0 spec
[00:49:56] <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
[00:50:07] <struberg> check 6.6.4
[00:50:37] <struberg> If a producer method declares a passivating scope and:
[00:50:48] <struberg> has a parameter that does not resolve to a passivation capable dependency,
[00:50:56] <struberg> then the container automatically detects the problem and treats it as a deployment problem.
[00:51:06] <struberg> of course this is now history
[00:51:21] <stuartdouglas> struberg: that is my point, it only needs to fail for SessonScoepd
[00:51:28] <stuartdouglas> it does not need to fail for dependent scoped
[00:51:43] <stuartdouglas> and the example you have in your jira is dependent scoped
[00:52:37] <struberg> ok I c what u mean
[00:54:40] <struberg> btw, the behaviour got changed with CDI-1.1
[00:54:41] <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
[00:54:55] <struberg> where to report/contribute fixes to the TCK?
[00:55:56] <stuartdouglas> send a pill request on github
[00:56:13] <stuartdouglas> https://github.com/jboss/cdi-tck
[00:58:01] <struberg> kk
[01:09:59] *** mbg has quit IRC
[01:26:43] *** struberg has quit IRC
[02:02:10] *** alesj has joined #weld-dev
[02:03:02] <alesj> stuartdouglas: what was the AS7-2001 issue?
[02:03:04] <jbossbot> jira [AS7-2001] Weld does not throw a definition error for unresolved dependencies when injecting into web components on AS7 [Resolved (Done) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/AS7-2001
[02:03:18] <stuartdouglas>  just a bug in AS7's error checking
[02:03:29] <stuartdouglas> it was un uresolved dependency
[02:03:38] <stuartdouglas> but it was not being reported as such
[02:03:47] <alesj> ah, ok
[02:03:48] <alesj> what does @ServiceHandler do?
[02:03:54] <stuartdouglas> I did not actually deploy the app to see what the actual missing dependency was
[02:03:54] <alesj> from Solder
[02:04:22] <stuartdouglas> It allows you to use interfaces and abstract classes as beans
[02:04:37] <alesj> ok, i'll check it in more details
[02:04:45] <stuartdouglas> and handle invocations to them using an interceptor type class
[02:05:02] <stuartdouglas> you just can't call InvocationContext.proceed(), as there is nothing to proceed to
[02:05:05] <alesj> interceptor type class?
[02:05:11] <stuartdouglas> it should be part of the 1.1 spec
[02:05:20] <stuartdouglas> a class with an @AroundInvoke method
[02:05:31] <stuartdouglas> that handles all invocations on the interface
[02:05:42] <alesj> ic
[02:06:07] <alesj> so, what should we do with Event generic payload?
[02:06:14] <alesj> leave it out for 1.1.3?
[02:06:20] <stuartdouglas> I don't have time to look at that for now
[02:06:29] <alesj> and fix that in 1.2
[02:06:34] <alesj> or when we have time
[02:06:44] <alesj> how much work would that be?
[02:06:45] <stuartdouglas> I don't need the 1.1.3 release right now
[02:06:53] <stuartdouglas> I don't think it will be that much work
[02:07:04] <stuartdouglas> I think it is more just relaxing some restrictions
[02:07:12] <alesj> e.g. can jharting work on it?
[02:07:19] <stuartdouglas> he should be able to
[02:07:38] <alesj> why did you need 1.1.3 in the first place?
[02:07:43] <alesj> and not now :-)
[02:07:51] <stuartdouglas> I wanted to get it into 7.0.2
[02:07:57] <stuartdouglas> but that ship has sailed
[02:08:02] <stuartdouglas> and it was not super important
[02:08:20] <stuartdouglas> as the bugs that I fixed were mostly ones that I found, rather than ones other people reported
[02:08:35] <stuartdouglas> but I do need it before the next 7.1 release
[02:08:55] <alesj> ok
[02:08:59] <alesj> when is that?
[02:09:03] <stuartdouglas> not sure
[02:09:12] <stuartdouglas> when it is ready :-)
[02:15:46] <alesj> hmmm, I don't think @ServiceHandlerType is what AssistedInject does
[02:16:06] <alesj> stuartdouglas: ^
[02:16:15] <stuartdouglas> alesj: no, but you can implement it using that
[02:16:42] <alesj> so you would impl a factory using @SHT, right
[02:16:47] <alesj> a generic one
[02:16:50] <stuartdouglas> yes
[02:17:00] <stuartdouglas> and then you would just need to annotate the factory interface
[02:17:19] <stuartdouglas> with the service handler annotation
[02:19:41] *** alesj has quit IRC
[02:30:07] *** pmuir has joined #weld-dev
[02:50:59] *** pmuir has quit IRC
[03:03:18] *** pmuir has joined #weld-dev
[03:10:12] *** pmuir has quit IRC
[05:08:52] *** rruss has joined #weld-dev
[05:22:21] *** magesh has joined #weld-dev
[07:46:52] *** bdlink has joined #weld-dev
[07:49:01] *** bdlink has quit IRC
[07:56:30] *** sbryzak has quit IRC
[07:57:25] *** sbryzak has joined #weld-dev
[07:57:25] *** sbryzak has joined #weld-dev
[08:02:30] *** rruss has quit IRC
[08:05:32] *** ge0ffrey has joined #weld-dev
[08:16:25] *** mbg has joined #weld-dev
[08:22:22] *** struberg has joined #weld-dev
[08:49:51] *** rruss has joined #weld-dev
[08:53:03] *** oskutka has joined #weld-dev
[09:01:06] *** maschmid has joined #weld-dev
[09:03:18] *** kevinpollet has joined #weld-dev
[09:04:06] *** mathieuancelin has joined #weld-dev
[09:18:50] *** pchowaniec has joined #weld-dev
[09:19:08] *** pchowaniec has left #weld-dev
[09:21:20] *** jharting has joined #weld-dev
[10:07:21] *** kevinpollet has quit IRC
[10:08:33] *** jharting has quit IRC
[10:17:46] *** kevinpollet has joined #weld-dev
[10:20:36] *** rruss has quit IRC
[10:45:10] *** jharting has joined #weld-dev
[10:47:10] *** jharting has quit IRC
[10:48:13] *** jharting has joined #weld-dev
[13:26:02] *** mkouba has joined #weld-dev
[14:03:07] *** rmartinelli has joined #weld-dev
[14:26:30] *** alesj has joined #weld-dev
[14:51:57] *** alesj has quit IRC
[15:30:31] *** mathieuancelin has quit IRC
[15:31:40] *** mathieuancelin has joined #weld-dev
[15:32:30] *** struberg has quit IRC
[15:33:05] *** struberg has joined #weld-dev
[15:54:37] *** rruss has joined #weld-dev
[15:55:51] *** struberg has quit IRC
[16:18:52] *** emmanuel has joined #weld-dev
[16:48:18] *** mbg_ has joined #weld-dev
[16:55:36] *** pmuir has joined #weld-dev
[16:58:18] *** pmuir has quit IRC
[17:06:35] *** emmanuel has quit IRC
[17:12:18] *** mbg_ has quit IRC
[17:39:03] *** mkouba has quit IRC
[17:47:02] *** maschmid has quit IRC
[17:53:26] *** jharting has quit IRC
[17:58:25] *** mathieuancelin has left #weld-dev
[17:59:10] *** oskutka has quit IRC
[17:59:59] *** kevinpollet has quit IRC
[18:55:14] *** epbernard has joined #weld-dev
[18:55:15] *** epbernard is now known as emmanuel
[19:00:19] *** ge0ffrey has quit IRC
[19:10:26] *** struberg has joined #weld-dev
[19:33:47] *** alesj has joined #weld-dev
[19:50:46] *** struberg has quit IRC
[19:52:27] *** emmanuel has quit IRC
[19:53:12] *** rruss has quit IRC
[20:05:06] *** epbernard has joined #weld-dev
[20:05:07] *** epbernard is now known as emmanuel
[20:16:19] *** maschmid has joined #weld-dev
[20:17:16] *** jharting has joined #weld-dev
[20:24:21] *** emmanuel has quit IRC
[20:25:16] *** jharting has quit IRC
[20:26:34] *** struberg has joined #weld-dev
[21:07:06] *** struberg has quit IRC
[21:12:20] *** rruss has joined #weld-dev
[21:33:03] *** maschmid has quit IRC
[21:35:04] *** oskutka has joined #weld-dev
[21:38:22] *** oskutka has quit IRC
[21:51:47] *** alesj has quit IRC
[21:52:40] *** alesj has joined #weld-dev
[21:55:44] *** alesj has quit IRC
[22:06:00] *** maschmid has joined #weld-dev
[22:21:42] *** struberg has joined #weld-dev
[22:44:00] *** rmartinelli has quit IRC
[23:13:53] *** epbernard has joined #weld-dev
[23:13:53] *** epbernard is now known as emmanuel
[23:17:07] *** cbrock has joined #weld-dev
[23:18:43] *** magesh1 has joined #weld-dev
[23:20:42] *** magesh has quit IRC
[23:27:02] *** struberg has quit IRC
[23:35:02] *** emmanuel has quit IRC





top