[00:00:24] *** pmuir has quit IRC
[00:01:05] *** mbg has quit IRC
[00:04:06] *** cbrock has quit IRC
[01:08:29] *** stuartdouglas has quit IRC
[01:09:29] *** stuartdouglas has joined #weld-dev
[01:37:53] *** rmartinelli has quit IRC
[04:00:33] *** rruss has quit IRC
[04:22:04] *** sbryzak has quit IRC
[04:27:26] *** sbryzak has joined #weld-dev
[04:27:27] *** sbryzak has joined #weld-dev
[05:28:51] *** rruss has joined #weld-dev
[06:20:24] *** magesh has joined #weld-dev
[07:23:53] *** alesj has joined #weld-dev
[07:32:16] *** oskutka has quit IRC
[07:58:13] *** jharting has joined #weld-dev
[08:09:43] *** ge0ffrey has joined #weld-dev
[08:25:07] *** struberg has joined #weld-dev
[08:25:12] <struberg> good morning
[08:25:22] <stuartdouglas> morning
[08:25:26] <struberg> hi stu
[08:25:34] <struberg> time to hack on some cdi spec issues ;)
[08:28:18] *** struberg1 has joined #weld-dev
[08:31:17] *** struberg has quit IRC
[08:38:54] *** oskutka has joined #weld-dev
[08:48:53] *** maschmid has joined #weld-dev
[08:50:31] *** struberg1 is now known as struberg
[08:55:53] <struberg> stu, before I change that
[08:56:18] <struberg> do you see any reason why bean ct and @Inject method params must be passivation capable too for passivationcapable beans?
[08:56:22] <struberg> 6.6.4
[08:56:25] <struberg> If a managed bean which declares a passivating scope:
[08:56:42] <struberg> has a non-transient injected field, bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, ...
[08:57:10] <stuartdouglas> not really
[08:57:24] <struberg> cant see any problem if the params are not serializable, until they get stored 1:1 in those beans
[08:57:37] <struberg> yup, kk will wipe this phrase out for CDI-140
[08:57:39] <jbossbot> jira [CDI-140] improve passivation capable bean validation for @Dependent scoped beans in 6.6.4 [Open (Unresolved) Clarification, Major, Unassigned] https://issues.jboss.org/browse/CDI-140
[08:57:39] <struberg> txs!
[09:03:52] <struberg> any EJB specialist around?
[09:03:59] <stuartdouglas> kinda
[09:04:00] <struberg> EJBs in 3.0 needed a default ct, right?
[09:04:06] <stuartdouglas> yes
[09:04:13] <struberg> the param thingy only got introduced as side effect of CDI
[09:04:16] <stuartdouglas> yes
[09:04:31] <stuartdouglas> they still need a default constructor anyway
[09:04:33] <struberg> kk then the passus of the passivation for Session beans is obsolete too imo
[09:04:35] <stuartdouglas> so they can be proxied
[09:04:41] <struberg> yup
[09:05:11] <struberg> but imo I can safely remove the serializable bean ct param and inject method params there too
[09:16:12] <struberg> btw stu, I think cdi beans need a default ct too
[09:16:16] <struberg> for the very same reason
[09:16:20] <struberg> serialisation
[09:16:22] <stuartdouglas> if they are normal scoped
[09:16:26] <struberg> yup
[09:16:38] <stuartdouglas> in weld we have a non-portable extension that you can use to remove that restriction
[09:16:54] <stuartdouglas> In fact we can even proxy beans with only a private ctor
[09:16:54] <struberg> but how do you create them?
[09:17:01] <struberg> yea oki
[09:17:04] <struberg> thats not a problem
[09:17:14] <stuartdouglas> com.sun.Unsafe on sun JVM's
[09:17:15] <struberg> but it needs at least a private ct
[09:17:22] <struberg> lol kk
[09:17:28] <struberg> but I would not bet on it ;)
[09:17:31] <stuartdouglas> and something else on the others, can't remember what
[09:17:43] <struberg> maybe this will be com.oracle.another.Unsafe soon :D
[09:17:59] <struberg> nothing we can write into the spec I fear
[09:18:04] <stuartdouglas> it should be possibly to do it in a portable manner by abusing serialization
[09:18:09] <stuartdouglas> but I never got around to it
[09:18:35] <stuartdouglas> The private actor case is problematic, because all ctors have to call super() or another constructor
[09:18:46] <struberg> I'd rather write this into the spec that at least a private default ct is needed
[09:18:48] <stuartdouglas> so in the sub class I had to add two ctors that just call each other
[09:18:57] <stuartdouglas> and then instantiate it with Unsafe :-)
[09:19:33] <stuartdouglas> private default ct is not ok without using non-portable stuff
[09:19:39] <struberg> this is not guaranteed in the vmspec to run everywhere
[09:19:45] <struberg> why?
[09:19:58] <struberg> private ct can perfectly be called via reflection isn't?
[09:20:01] <stuartdouglas> The JVM spec requires all constructors to call super() or another constructor
[09:20:04] <stuartdouglas> in the bytecode
[09:20:08] <stuartdouglas> not via reflection
[09:20:43] <stuartdouglas> In fact without my 2 actor calling each other trick most VM's won't even let you load the class
[09:20:46] <struberg> oki, so our proxys wont be able to call it
[09:20:52] <stuartdouglas> exactly
[09:20:58] <struberg> yup then at least protected
[09:21:08] <struberg> but imo we should write that into the spec
[09:21:11] <struberg> will open a CDI for it
[09:21:19] <stuartdouglas> I thought that was already there
[09:21:35] <struberg> humm, you remember the paragraph?
[09:22:30] <stuartdouglas> 5.4.1.
[09:24:11] <struberg> txs
[09:25:58] <struberg> oki, true, defined by the proxy restrictions
[09:27:30] <struberg> I think this part is duplicated
[09:27:31] <struberg> If a producer field declares a passivating scope and:
[09:27:32] <struberg> ?	the container is able to determine that it is not passivation capable by inspecting its type,
[09:27:38] <struberg> and also wrong
[09:27:43] <struberg> 6.6.4 again
[09:28:14] <struberg> 6.6.1 defines
[09:28:16] <struberg> A producer method is passivation capable if and only if it never returns a value which is not passivation capable at runtime. A producer method with a primitive return type or a return type that implements or extends Serializable is passivation capable. A producer method with a return type that is declared final and does not implement Serializable is not passivation capable.
[09:32:15] *** PeteRoyle has quit IRC
[09:32:40] *** mathieuancelin has joined #weld-dev
[09:36:27] <struberg> created CDI-153 for that
[09:36:29] <jbossbot> jira [CDI-153] PassivationCapable producer method/field definition is ambiguous [Open (Unresolved) Clarification, Major, Unassigned] https://issues.jboss.org/browse/CDI-153
[09:49:12] *** PeteRoyle has joined #weld-dev
[10:12:39] <struberg> stu what about @Inject into static fields now?
[10:16:17] *** mkouba has joined #weld-dev
[10:19:44] <stuartdouglas> struberg: not really sure about that one, personally I don't see how it can work
[10:21:37] <struberg> grr that github workflow is broken somehow on the mac
[10:21:55] <struberg> I pulled from jboss/cdi
[10:22:02] <struberg> which got forked from alesj it seems
[10:22:17] <struberg> and now the pull request goes to alesj instead of jboss
[10:22:49] <struberg> ah got it
[10:22:53] <struberg> one can change that
[11:01:03] *** stalep has joined #weld-dev
[11:01:55] *** stalep has quit IRC
[11:12:40] <alesj> stuartdouglas: check email, look like AS7-1671 is not kicking in ...
[11:12:42] <jbossbot> jira [AS7-1671] Classloading issue with a CDI extension which use a library provided by the Application Server [Resolved (Done) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/AS7-1671
[11:13:39] *** alesj has quit IRC
[11:14:31] *** alesj has joined #weld-dev
[11:17:28] *** alesj has quit IRC
[11:36:19] *** alesj has joined #weld-dev
[11:40:21] <struberg> stu you r still awake?
[11:40:35] <struberg> If a producer method declares a passivating scope and:
[11:40:35] <struberg> *doesn't have a primitive return type, and doesn't have a return type that implements or extends Serializable, and doesn't only return Serializable types at runtime
[11:40:36] <struberg> then the container the container must throw an IllegalProductException
[11:40:45] <struberg> oops should be 3 points actually
[11:40:56] <struberg> the 2 are contained in the last one
[11:41:10] <struberg> so I could theoretically scrap them
[11:42:35] <struberg> and only write: "If a producer method declares a passivating scope and returns a non-Serializable type at runtime
[11:42:35] <struberg> then the container the container must throw an IllegalProductException."
[11:49:22] <stuartdouglas> sounds reasonable
[11:50:04] <stuartdouglas> what about Externalisable?
[11:54:55] <struberg> I thought about that too to be honest
[11:55:06] <struberg> but the whole CDI spec completely ignores it atm
[11:55:25] <struberg> can you please write it on the cdi-dev list?
[11:57:13] <struberg> or should I create a CDI issue?
[12:07:49] <struberg> stu i created CDI-154
[12:07:50] <jbossbot> jira [CDI-154] How to treat Externalizable? [Open (Unresolved) Clarification, Major, Unassigned] https://issues.jboss.org/browse/CDI-154
[12:52:09] <struberg> ouch CDI-155
[12:52:10] <jbossbot> jira [CDI-155] specify Instance<T>#destroy() [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/CDI-155
[13:18:58] *** kevinpollet_ has joined #weld-dev
[13:43:28] *** rruss has quit IRC
[13:56:03] *** kevinpollet_ has quit IRC
[14:00:50] *** mathieuancelin has quit IRC
[14:19:11] *** rmartinelli has joined #weld-dev
[14:24:49] *** pmuir has joined #weld-dev
[14:24:50] *** pmuir has quit IRC
[14:24:50] *** pmuir has joined #weld-dev
[14:24:55] <struberg> ahoi pete
[14:25:02] *** pmuir has quit IRC
[14:31:51] *** magesh has quit IRC
[14:42:24] *** kevinpollet_ has joined #weld-dev
[15:18:57] *** rruss has joined #weld-dev
[15:19:30] *** rruss has quit IRC
[15:27:14] *** pmuir has joined #weld-dev
[15:27:15] *** pmuir has quit IRC
[15:27:15] *** pmuir has joined #weld-dev
[15:28:13] *** kevinpollet_ has quit IRC
[15:35:49] *** rruss has joined #weld-dev
[15:51:02] *** magesh has joined #weld-dev
[15:51:29] *** pmuir has quit IRC
[16:26:54] *** jharting has quit IRC
[16:27:14] *** mbg has joined #weld-dev
[16:27:32] *** pmuir has joined #weld-dev
[16:27:33] *** pmuir has quit IRC
[16:27:33] *** pmuir has joined #weld-dev
[16:38:41] *** mbg has quit IRC
[16:45:31] <alesj> pmuir: do we have conversation scope in weld embedded container?
[16:46:04] <pmuir> for arquillian?
[16:46:07] <pmuir> yes, i think so
[16:47:34] <pmuir> alesj: ^^^
[16:52:19] *** mbg has joined #weld-dev
[16:56:16] <maschmid> There is enableConversationScope property disabled by default, see  https://docs.jboss.org/author/display/ARQ/Weld+EE+1.1+-+Embedded
[16:56:52] <alesj> maschmid: ah, ok, thanks!
[16:57:13] <alesj> maschmid, pmuir: any idea why is that not on by default
[17:10:09] *** mkouba has quit IRC
[17:28:00] *** struberg has quit IRC
[17:31:31] *** kevinpollet has joined #weld-dev
[17:33:33] *** struberg has joined #weld-dev
[17:37:31] *** cbrock has joined #weld-dev
[17:37:31] *** cbrock has quit IRC
[17:37:32] *** cbrock has joined #weld-dev
[17:43:54] <pmuir> struberg: ping
[17:46:19] <struberg> pmuir pong
[17:46:31] <pmuir> struberg: just returning your ping :-)
[17:46:43] <struberg> ah kk ;)
[17:46:51] <struberg> had some time to work on the Serializable stuff
[17:47:00] *** ge0ffrey has quit IRC
[17:47:17] <struberg> guess you saw the new jira + pull requests already
[17:47:24] <struberg> take your time...
[17:48:52] <pmuir> yes, i'm looking now
[17:49:30] <pmuir> i talked to marius about this yesterday and we were discussing the best way to fix this, because in some limited situations (where you just do assignment in the ctor) the current validation makes sense
[17:49:43] <pmuir> for CDI-140
[17:49:44] <jbossbot> jira [CDI-140] improve passivation capable bean validation for @Dependent scoped beans in 6.6.4 [Open (Unresolved) Clarification, Major, Unassigned] https://issues.jboss.org/browse/CDI-140
[17:50:06] <struberg> those situations are almost always 1:1 assignments between ct or @Inject method params to class members
[17:50:10] <pmuir> yes
[17:50:21] <struberg> but then the checks for the class itself will catch this anyway
[17:50:46] <pmuir> i don't think so
[17:50:52] <pmuir> CDI doesn't validate any old field?
[17:50:57] <pmuir> just injected ones I think
[17:51:03] <struberg> true
[17:51:08] <struberg> hmm mom
[17:51:20] <struberg> not sure
[17:51:30] <struberg> I think owb checks it ;)
[17:51:34] <pmuir> imo the 1:1 case is probably used about 50% of the time
[17:51:40] <struberg> imo this makes sense btw
[17:51:57] <pmuir> what, checking all fields?
[17:51:59] <struberg> either it must be transient or static
[17:52:04] <struberg> yup
[17:52:13] *** oskutka has quit IRC
[17:52:17] <pmuir> ok, well do you want to file an issue for that as a feature request anyway
[17:52:18] <struberg> would need to check the our code again
[17:52:25] <pmuir> yeah, see what you do and file it
[17:52:42] <struberg> lets first discuss if this behaviour would make sense ;)
[17:52:55] <struberg> I cannot see any problem with it, do you?
[17:53:16] <pmuir> so maybe it does make sense to have an annotation to either enable or disable this validation of ctors and initializer methods
[17:53:18] <pmuir> i can't, no
[17:53:28] <pmuir> or a configuration setting?
[17:53:36] <pmuir> not sure
[17:53:44] <struberg> hmm that sounds weird
[17:53:49] <struberg> because if you re-use jars ...
[17:53:58] <struberg> via config is not a good idea imo
[17:54:22] <struberg> mom I'll look what we really do
[17:54:58] <pmuir> yes, via an annotation makes more sense
[17:55:00] <pmuir> probably
[17:55:16] <pmuir> and atm I'm leaning towards disabled by default, and you can add it if you want
[17:56:33] <struberg> disabled = no serialisation check or ser_check_on?
[17:57:30] <pmuir> no serialization check
[17:58:51] <struberg> yup
[18:00:01] <struberg> and no, in OWB we also only check injectionPoints
[18:00:53] <pmuir> ok
[18:01:07] <struberg> most Serializable issues can most probably only be checked at runtime if any
[18:01:18] <pmuir> so do you want to explore this idea of an annotation before we merge your changes?
[18:01:37] <struberg> or at least after all injection and @PostConstruct got executed
[18:01:40] <struberg> and not even then
[18:01:58] <pmuir> yes, we only get to check this a bit earlier due to knowing the di graph
[18:02:06] <pmuir> it's not a major improvment, just a bit ;-)
[18:02:12] *** maschmid has quit IRC
[18:02:14] <struberg> because if any lazy stuff gets set inside the class after a method call, which is not Serializable ..
[18:03:27] <struberg> I worked through 6.6 today
[18:03:36] <struberg> originally I inteded only to change 6.6.4
[18:04:12] <struberg> but in 6.6.1 there was already an exception added by saying that producers only must get checked at runtime whether they produce serializable instances
[18:04:48] <struberg> so I dropped the 'old' checks for deployment time in 6.6.4 to the possible maximum
[18:05:23] <struberg> which is to do checks only for fields with final classes
[18:06:03] <struberg> You also saw the other issue about Externalizable?
[18:06:37] <struberg> stu came across this in the past
[18:06:47] <struberg> and I wondered too already
[18:08:03] <pmuir> yes
[18:08:20] <pmuir> we also were thinking about the Externalizable issue with the annotation above - similar sort of thing
[18:08:24] <struberg> the "unserializable" was in there before i think ;)
[18:08:58] <struberg> dont like that term to be honest
[18:09:10] <struberg> that's why I used the inverse logic
[18:09:15] <struberg> but its doubled ofc
[18:11:35] <pmuir> I made some comments on CDI-153
[18:11:36] <jbossbot> jira [CDI-153] PassivationCapable producer method/field definition is ambiguous [Open (Unresolved) Clarification, Major, Unassigned] https://issues.jboss.org/browse/CDI-153
[18:11:42] <pmuir> ok you saw them ;-)
[18:11:51] 
[18:12:33] <struberg> dependent producer method or producer field for me sounds more like a producer method which gets triggered as result of a injection into another class
[18:12:45] <struberg> dependent in the term of 'Dependency'
[18:13:15] <struberg> wheras the "producer method of scope @Dependent' is unambiguous
[18:13:36] <struberg> the wording was there before, just moved it and aligned it
[18:14:31] <pmuir> ok, if it was there before, then call
[18:14:32] <pmuir> cool
[18:21:50] *** cbrock has quit IRC
[18:23:36] *** pmuir has quit IRC
[18:39:25] *** struberg has quit IRC
[18:41:03] *** oskutka has joined #weld-dev
[18:41:09] *** oskutka has quit IRC
[18:59:44] *** pmuir has joined #weld-dev
[19:08:02] *** alesj has quit IRC
[19:30:53] *** magesh has left #weld-dev
[19:34:50] *** rruss has quit IRC
[20:12:04] *** cbrock has joined #weld-dev
[20:12:04] *** cbrock has joined #weld-dev
[20:12:43] *** mbg1 has joined #weld-dev
[20:13:08] *** mbg has quit IRC
[20:31:41] *** kevinpollet has quit IRC
[21:06:06] *** alesj has joined #weld-dev
[21:29:59] *** rruss has joined #weld-dev
[21:32:50] *** mbg has joined #weld-dev
[21:32:52] *** mbg1 has quit IRC
[22:18:45] *** struberg has joined #weld-dev
[22:24:53] *** struberg has quit IRC
[22:32:12] *** mbg1 has joined #weld-dev
[22:32:15] *** mbg has quit IRC
[23:47:09] *** kevinpollet has joined #weld-dev
[23:47:11] *** kevinpollet has quit IRC





top