[00:42:19] <stuartdouglas> mbg: You around?
[01:03:56] *** alesj has quit IRC
[02:20:36] <jbossbot> git [core] push master c1a6be4.. Stuart Douglas WELD-969 Prevent NPE if no context is registered
[02:20:37] <jbossbot> jira [WELD-969] org.jboss.jsr299.tck.tests.context.ContextTest is failing [Open (Unresolved) Bug, Critical, Stuart Douglas] https://issues.jboss.org/browse/WELD-969
[02:20:37] <jbossbot> git [core] push master 35ab511.. Stuart Douglas Test runner usability improvements
[02:20:37] <jbossbot> git [core] push master 6324cc5.. Stuart Douglas WELD-968 Building @AroundTimeout interceptor metadata for all methods
[02:20:38] <jbossbot> jira [WELD-968] Weld does not interceptor timeout methods without an @Timeout annotation [Open (Unresolved) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/WELD-968
[02:20:38] <jbossbot> git [core] push master 8c33736.. Stuart Douglas gitignore
[02:20:39] <jbossbot> git [core] push master URL: http://github.com/weld/core/compare/4fd9ea0...8c33736
[02:49:09] <jbossbot> git [core] push master b94f829.. Stuart Douglas WELD-970 Do not stop validation of first failure
[02:49:10] <jbossbot> jira [WELD-970] Validator should not stop on first exception, but should continue to validate all beans [Open (Unresolved) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/WELD-970
[02:49:10] <jbossbot> git [core] push master URL: http://github.com/weld/core/compare/8c33736...b94f829
[04:46:22] <mbg> stuartdouglas: now
[04:58:36] *** sbryzak has joined #weld-dev
[04:58:37] *** sbryzak has quit IRC
[04:58:37] *** sbryzak has joined #weld-dev
[05:36:57] <stuartdouglas> mbg: never mind, I just had a jboss-interceptors question
[05:37:12] <stuartdouglas> but I figured itout
[05:40:40] <mbg> stuartdouglas: oh ok.
[05:41:32] <stuartdouglas> while you are here, do you know if there are any plans to merge jboss-interceptors into weld core?
[07:05:50] <mbg> stuartdouglas: I had one, just haven't been too good to act on it
[07:15:07] <mbg> stuartdouglas: little or no time, basically
[07:15:24] <stuartdouglas> fair enough
[07:16:18] <mbg> yeah, I think that's definitely the thing to do. coupled with using jboss-invocation perhaps
[07:18:11] <stuartdouglas> I think jboss-invocation can wait for the next major release
[07:30:17] *** magesh has joined #weld-dev
[07:39:39] *** sbryzak has quit IRC
[08:08:38] *** pchowaniec has joined #weld-dev
[08:29:59] *** struberg has joined #weld-dev
[08:35:27] *** mkouba has joined #weld-dev
[08:41:44] *** nickarls has quit IRC
[08:41:49] *** nickarls has joined #weld-dev
[08:52:26] *** ge0ffrey has joined #weld-dev
[09:03:56] *** maschmid has joined #weld-dev
[09:27:09] *** mathieuancelin has joined #weld-dev
[09:37:27] *** pchowaniec has quit IRC
[11:45:26] *** pchowaniec has joined #weld-dev
[12:41:39] *** alesj has joined #weld-dev
[13:09:38] *** mbg has quit IRC
[13:31:26] *** pchowaniec has left #weld-dev
[13:49:34] *** rmartinelli has joined #weld-dev
[14:16:13] *** sbryzak has joined #weld-dev
[14:16:13] *** sbryzak has joined #weld-dev
[14:25:43] *** oskutka has joined #weld-dev
[14:58:13] *** oskutka has quit IRC
[14:58:50] *** oskutka has joined #weld-dev
[15:30:23] *** sbryzak has quit IRC
[15:45:12] *** pmuir has joined #weld-dev
[15:45:13] *** pmuir has quit IRC
[15:45:13] *** pmuir has joined #weld-dev
[16:03:25] *** sbryzak has joined #weld-dev
[16:03:25] *** sbryzak has joined #weld-dev
[16:06:35] *** mbg has joined #weld-dev
[16:15:15] *** mkouba has quit IRC
[16:18:28] *** mkouba has joined #weld-dev
[16:24:25] <struberg> pmuir got some time to quickly discuss CDI-121?
[16:24:27] <jbossbot> jira [CDI-121] TransactionScope [Open (Unresolved) Feature Request, Minor, Richard Hightower] https://issues.jboss.org/browse/CDI-121
[16:24:46] <struberg> or anyone else like stu or mbg
[16:24:53] <pmuir> struberg: yes, but i'm in a meeting so may come and go
[16:25:20] <struberg> is it possible / makes sense to define this without defining @Transactional ?
[16:25:43] <struberg> I mean a TransactionScope is only good if the lifecycle is exactly defined
[16:26:00] <struberg> and by just saying its JTA bound would leave out lots of scenarios
[16:26:35] <struberg> + manual starting of the transaction in other ways would also need to get handled
[16:27:40] <struberg> javax.ejb.TransactionAttribute and stuff would need to get moved to an own api jar anyway imo
[16:29:31] <pmuir> hmm
[16:29:40] <pmuir> unpicking what you are saying slightly
[16:30:03] <struberg> maybe I'm in a brain deadend and it's easy to solve
[16:30:25] <struberg> I just thought about how we could implement that
[16:30:42] <alesj> how else, w/o JTA, would you handle this?
[16:30:49] <alesj> i guess there can be custom tx impl
[16:30:52] <struberg> in a way that our cdi-api is still ejb agnostic
[16:30:54] <alesj> which would  also work
[16:31:03] <pmuir> you are asking that we would spec this with an abstraction over tx?
[16:31:16] <struberg> just as plain JPA transactions for example
[16:31:19] <alesj> but that means you're repeating the same mistake Hibernate did; having its own tx API/impl/etc
[16:31:28] <struberg> like we have in CODI with @Transactional atm
[16:31:40] <struberg> and just start a context at the outermost level
[16:31:48] <struberg> and close it once you leave it
[16:31:49] <alesj> doing it this way, CDI would have to have Tx API, imo
[16:31:57] <pmuir> let's split this into a discussion about what we can spec, what we can test and what we can implement
[16:32:03] <pmuir> with/without jta
[16:32:07] <struberg> yup
[16:32:14] <alesj> so you could abstract away diff tx usages
[16:32:22] <struberg> imo the cdi-api should try to be agnostic of other EE specs
[16:32:26] <struberg> we did well so far
[16:32:27] <alesj> JPA vs. full JTA vs. GAE Tx vs. ...
[16:32:36] <struberg> yup exactly
[16:33:11] <alesj> hmmm, i would rather see those custom impl get adapter layer for JTA
[16:33:15] <alesj> than having this in CDI
[16:33:19] <struberg> yup
[16:33:27] <alesj> CDI ?> JTA
[16:33:30] <alesj> other should adapt
[16:33:53] <alesj> since JTA, with UT and Tx is simple API
[16:34:00] <struberg> 99% of all use cases will be the EntityManager producer anyway ^^
[16:34:18] <alesj> if you don't need to add XA and Synch
[16:34:53] <struberg> if we spec JTA then we must go the fully blown route
[16:34:59] <struberg> capturing all features
[16:35:34] <struberg> we probably would even need to support remote contexts
[16:35:47] <struberg> because JTA transactions are distributed also
[16:35:57] <struberg> thus the context might also need to be distributed...
[16:36:01] <struberg> (just ideas)
[16:37:10] <alesj> i have some prototype working on that, as i need it elsewhere ...
[16:37:19] <alesj> but i wouldn't go ther ewith Tx for the start
[16:37:23] <alesj> too complex
[16:37:38] <alesj> since it's as you're saying, EM 99% mostly
[16:37:56] <struberg> but if we do it in the spec
[16:38:01] <struberg> then we must specify it 100%
[16:38:02] <struberg> :(
[16:38:06] <pmuir> struberg: I think your point is good - we should either introduce full TX control to CDI or none
[16:38:26] <pmuir> I *think* it's possible to spec it without that
[16:38:28] <struberg> imo all other situations would lead to complains
[16:38:31] <pmuir> harder to test
[16:38:35] <pmuir> even harder to impl
[16:38:59] <alesj> pmuir: i would say you would have zero working impls then :-)
[16:39:10] <struberg> :)
[16:39:16] <pmuir> alesj: well it would be required to impl it ;-)
[16:39:25] <pmuir> and tested it would have to just be via JTA
[16:39:36] <pmuir> we can't actually introduce a TX abstraction in CDI ;-)
[16:39:50] <alesj> why not?
[16:39:54] <struberg> not without repeating whats already there in the EJB spec
[16:39:54] <alesj> call it Xt :-)
[16:40:04] <struberg> and JTA spec
[16:40:04] <pmuir> we have one in EE - JTA
[16:40:35] <pmuir> ok, let me add some notes to the issue
[16:40:55] <struberg> I mean having @TransactionScoped in the spec would be cool
[16:41:07] <struberg> but I have no idea how we could implement / specify it
[16:41:16] <struberg> without clashing with EJB/JTA
[16:41:28] <pmuir> struberg: yeah, I think it's more important to work on declarative tx
[16:41:30] <struberg> and still remain agnostic
[16:41:31] <pmuir> and have that first
[16:41:48] <struberg> think that was CDI-27
[16:41:49] <jbossbot> jira [CDI-27] Support declarative transactions on managed beans [Open (Unresolved) Tracker, Major, Pete Muir] https://issues.jboss.org/browse/CDI-27
[16:42:24] <struberg> oki that was it
[16:42:29] <struberg> txs pete and alesj
[16:43:40] <pmuir> struberg: yeah, i will chase the EJB EG on CDI-27
[16:43:41] <jbossbot> jira [CDI-27] Support declarative transactions on managed beans [Open (Unresolved) Tracker, Major, Pete Muir] https://issues.jboss.org/browse/CDI-27
[16:48:16] <jbossbot> git [core] push master 023afec.. Marek Schmidt Add/fix ftest-jboss-remote-7 profiles
[16:48:16] <jbossbot> git [core] push master a559cbf.. Marek Schmidt forgotten version update
[16:48:16] <jbossbot> git [core] push master URL: http://github.com/weld/core/compare/b94f829...a559cbf
[17:00:04] *** sbryzak_ has joined #weld-dev
[17:00:04] *** sbryzak_ has joined #weld-dev
[17:00:14] *** alesj has quit IRC
[17:04:46] *** alesj has joined #weld-dev
[17:05:45] *** sbryzak_ has quit IRC
[17:09:00] *** magesh has quit IRC
[17:09:18] *** sbryzak has quit IRC
[17:12:06] *** alesj has quit IRC
[17:42:16] *** mkouba has quit IRC
[17:45:22] *** sbryzak has joined #weld-dev
[17:45:22] *** sbryzak has joined #weld-dev
[17:52:21] *** alesj has joined #weld-dev
[17:59:42] *** sbryzak has quit IRC
[18:01:04] *** maschmid has quit IRC
[18:01:46] *** mathieuancelin has quit IRC
[18:17:10] <jbossbot> git [core] push master fe766b0.. Ales Justin Merge remote-tracking branch 'jharting/build.properties'
[18:17:10] <jbossbot> git [core] push master URL: http://github.com/weld/core/compare/a559cbf...fe766b0
[18:27:01] *** alesj has quit IRC
[18:56:42] *** alesj has joined #weld-dev
[19:09:08] *** kevinpollet has joined #weld-dev
[19:39:10] *** oskutka has quit IRC
[19:51:57] *** ge0ffrey has quit IRC
[19:57:11] *** sbryzak has joined #weld-dev
[19:57:11] *** sbryzak has joined #weld-dev
[20:04:07] *** pmuir has quit IRC
[20:05:42] *** pmuir has joined #weld-dev
[20:09:08] *** mbg1 has joined #weld-dev
[20:11:19] *** mbg has quit IRC
[20:11:56] *** sbryzak has quit IRC
[20:12:10] *** pmuir has quit IRC
[20:17:05] *** pmuir has joined #weld-dev
[20:26:33] *** sbryzak has joined #weld-dev
[20:26:33] *** sbryzak has joined #weld-dev
[20:27:02] *** sbryzak_ has joined #weld-dev
[20:27:03] *** sbryzak_ has quit IRC
[20:27:03] *** sbryzak_ has joined #weld-dev
[20:42:39] *** kevinpollet has quit IRC
[21:22:08] *** kevinpollet has joined #weld-dev
[21:22:45] *** rruss has joined #weld-dev
[21:26:28] *** jbott has quit IRC
[21:26:28] *** OndrejZizka has quit IRC
[21:27:06] *** OndrejZizka has joined #weld-dev
[21:27:54] *** rruss has quit IRC
[21:28:07] *** rruss has joined #weld-dev
[21:29:22] *** mbg has joined #weld-dev
[21:29:40] *** jbott has joined #weld-dev
[21:30:09] *** mbg1 has quit IRC
[21:30:13] *** sbryzak_ has quit IRC
[21:30:13] *** sbryzak has quit IRC
[21:32:13] *** rruss has quit IRC
[21:36:35] *** alesj has quit IRC
[21:36:54] *** alesj has joined #weld-dev
[21:43:50] *** sbryzak_ has joined #weld-dev
[21:46:27] *** sbryzak has joined #weld-dev
[21:46:27] *** sbryzak has quit IRC
[21:46:27] *** sbryzak has joined #weld-dev
[22:03:38] *** rmartinelli has quit IRC
[22:10:03] <struberg> pmuir ping
[22:10:09] <struberg> still around?
[22:10:19] *** sbryzak_ has quit IRC
[22:10:19] *** sbryzak has quit IRC
[22:10:30] <pmuir> hi struberg
[22:10:41] <struberg> could we specify that javax.ejb.TransactionAttribute might get handled as InterceptorBinding in CDI beans?
[22:10:48] <struberg> just thinking ...
[22:11:03] <struberg> not sure what that would mean for EJBs in return
[22:11:29] <struberg> so instead of @Transactional(transaction=REQUIRES_NEW)
[22:11:52] <struberg> we could use @javax.ejb.TransactionAttribute(value=REQUIRES_NEW)
[22:13:00] <struberg> TransactionAttribute is a simple annotation atm
[22:13:13] <struberg> we could add this as interceptor binding via our Extension SPI
[22:13:48] <struberg> but might have drawbacks on the ejb side ...
[22:25:45] *** sbryzak_ has joined #weld-dev
[22:25:45] *** sbryzak_ has quit IRC
[22:25:45] *** sbryzak_ has joined #weld-dev
[22:28:14] *** sbryzak has joined #weld-dev
[23:07:50] <struberg> pmuir? ^
[23:09:42] <pmuir> struberg: yeah, this is something like what it will be
[23:09:48] <pmuir> i think
[23:09:57] <struberg> should I dump it to CDI-121?
[23:09:59] <jbossbot> jira [CDI-121] TransactionScope [Open (Unresolved) Feature Request, Minor, Richard Hightower] https://issues.jboss.org/browse/CDI-121
[23:10:18] <pmuir> no
[23:10:21] <struberg> kk
[23:10:27] <pmuir> CDI-27
[23:10:28] <jbossbot> jira [CDI-27] Support declarative transactions on managed beans [Open (Unresolved) Tracker, Major, Pete Muir] https://issues.jboss.org/browse/CDI-27
[23:10:35] <struberg> oki ;)
[23:11:09] <pmuir> CDI-121 is just about a transaction scope, CDI-27 is about extending declarative tx to CDI managed beans
[23:11:10] <jbossbot> jira [CDI-121] TransactionScope [Open (Unresolved) Feature Request, Minor, Richard Hightower] https://issues.jboss.org/browse/CDI-121
[23:11:10] <jbossbot> jira [CDI-27] Support declarative transactions on managed beans [Open (Unresolved) Tracker, Major, Pete Muir] https://issues.jboss.org/browse/CDI-27
[23:14:46] *** mbg has quit IRC
[23:15:03] <struberg> oki added the comment to CDI-27
[23:15:04] <jbossbot> jira [CDI-27] Support declarative transactions on managed beans [Open (Unresolved) Tracker, Major, Pete Muir] https://issues.jboss.org/browse/CDI-27
[23:15:11] <pmuir> thanks mark
[23:15:20] <struberg> np and gn8 :)
[23:16:58] *** mbg has joined #weld-dev
[23:19:30] *** struberg has quit IRC
[23:21:04] *** mbg has quit IRC
[23:26:05] *** mbg has joined #weld-dev
[23:34:16] *** oskutka has joined #weld-dev
[23:42:39] *** mbg has quit IRC
[23:42:54] *** mbg has joined #weld-dev
[23:49:43] *** oskutka has quit IRC
[23:50:41] *** oskutka has joined #weld-dev





top