[00:21:24] <alesj> stuartdouglas: ok on that email?
[00:21:52] <stuartdouglas> alesj: The osgi bundle one ?
[00:22:07] <alesj> yes
[00:22:29] <alesj> stuartdouglas: ^
[00:22:46] *** sbryzak has joined #weld-dev
[00:22:48] <stuartdouglas> I have not looked into it yet
[00:28:40] <struberg> I might have found an OWB bug too
[00:28:57] <struberg> which in conjunction with the tricks of seam might lead to errors in OWB
[00:30:51] <struberg> yup, now this magic works
[00:31:02] <struberg> we missed a hasCode in one of our wrappers ;)
[00:35:39] <struberg> stu one question left: how should the BeanManagerLocator does his job for environments without writable JNDI context?
[00:35:49] <struberg> e.g. in pure lean Servlets?
[00:41:06] <stuartdouglas> struberg: weld servlet sticks it in the servlet context
[00:41:32] <stuartdouglas> it uses the service loader pattern to load BeanManagerProviders
[00:42:03] <stuartdouglas> so you need to provide one for non-standard environments
[00:42:26] <struberg> hum, but thats nowhere in the spec
[00:42:30] <struberg> so you cannot rely on it
[00:42:47] <struberg> what about just observing some event and storing the BeanManager there?
[00:42:50] <struberg> thats what we do in CODI
[00:43:14] <struberg> of course with a HashMap<ClassLoader, BeanManager>
[00:43:21] <struberg> so we can distinguish between webapps
[00:43:24] <stuartdouglas> thats a good idea
[00:43:29] <struberg> on the current context classloader
[00:43:42] <stuartdouglas> but will not work in AS7
[00:43:46] <struberg> OSGi?
[00:43:49] <stuartdouglas> as there may be multiple CL's per deployment
[00:44:18] <struberg> should not matter much since the TCCL must always be correct
[00:44:22] <struberg> thats part of the Java spec
[00:44:35] <stuartdouglas> yes, but there is different correct CL's
[00:44:41] <stuartdouglas> depending on the context
[00:44:50] <struberg> kk
[00:44:56] <stuartdouglas> even if you have two wars there are two different cl's
[00:44:59] <struberg> it would work as last resort at least ;)
[00:45:13] <struberg> yup, thats exactly why it works
[00:45:21] <struberg> each webapp has its own BeanManager anyway
[00:46:02] <stuartdouglas> but if one war has no classes, only a web.xml, then no event will be fired and it will not be stored
[00:46:30] <struberg> true
[00:46:55] <struberg> but thats a freak show :)
[00:47:01] <struberg> pathologic use case ;)
[00:47:23] <stuartdouglas> not really, I have already seen an AS7 bug caused by someone doing this
[01:07:30] *** alesj has quit IRC
[01:12:26] <struberg> stu, your Synthetic magic works now in OWB too
[01:12:33] <stuartdouglas> cool
[01:12:35] <struberg> i tweaked something for it ;)
[01:13:21] <struberg> but I'm still not conviced about the serializable EntityManager ;)
[01:14:07] <stuartdouglas> you need it to be passivation capable to have conversation scoped entity managers
[01:14:22] <struberg> yup
[01:14:27] <struberg> but EMs are not
[01:14:35] <stuartdouglas> the hibernate EM is
[01:14:43] <struberg> it's marked as
[01:14:48] <struberg> but it isnt
[01:14:55] <struberg> I can show you by crashing it ;)
[01:15:07] <struberg> just adding the Serializable interface doesnt solve the underlying problem
[01:15:56] <stuartdouglas> hmm, it does have a readObject and writeObject
[01:16:30] <struberg> but the underlying database connection cannot move the lock to another node
[01:16:55] <stuartdouglas> why are you Serializing while a transaction is active?
[01:17:22] <struberg> because JPA can hold it open
[01:17:44] <struberg> why using a ConversationScoped EM if you dont have open transactions spanning multiple requests?
[01:18:01] <struberg> if so, then just use @RequestScoepd and em.merge afterwards
[01:18:07] <struberg> solves a lot memory btw ;)
[01:18:10] <stuartdouglas> because a transaction spanning multiple requests is pure evil?
[01:18:25] <struberg> exactly what I say ;)
[01:18:40] <stuartdouglas> conversation scoped em's do not hold a transaction open
[01:18:55] <struberg> they hold dirty objects
[01:18:57] <stuartdouglas> they just keep your entities in the PU over multiple requests
[01:19:04] <stuartdouglas> to prevent excessive merging
[01:19:20] <struberg> and whenever you do a complex query, those dirty objects WILL GET WRITTEN TO THE DB
[01:19:25] <struberg> and a transaction will get opened
[01:19:31] <struberg> that stands in the JPA spec^^
[01:19:49] <struberg> I think the exact wording is 'non-trivial query'
[01:19:50] <stuartdouglas> unless you use hibernates manual flush mode
[01:20:06] <struberg> but thats not portable then
[01:20:44] <struberg> + manual flush mode has quite a few restrictions
[01:20:54] <stuartdouglas> no, if you are not using hibernate then there is probably not much point using a conversation scoped EM
[01:21:02] <stuartdouglas> what sort of restrictions?
[01:21:13] <struberg> for example grouped by queries
[01:21:18] <struberg> with having and stuff
[01:21:31] <stuartdouglas> what has that got to do with manual flush mode?
[01:21:51] <struberg> oki, you do an em.persist of a new entity
[01:21:58] <struberg> and then you do a query
[01:22:10] <stuartdouglas> the new entity will not show up in the query
[01:22:13] <struberg> in JPA it is guaranteed that the new entity will be included in the result
[01:22:27] <stuartdouglas> that is part of the documented behaviour of the manual flush mode
[01:22:28] <struberg> but if the query is complex
[01:22:45] <struberg> then you cant do that relieably in memory
[01:22:54] <struberg> but thats not JPA anymore
[01:23:04] <struberg> then its a hibernate extension
[01:23:11] <struberg> but not a jpa extension
[01:24:17] <stuartdouglas> One of the main motivations behind seam persistence was to emulate the Seam 2 conversation scoped PC
[01:24:32] <struberg> ah oki
[01:24:39] <stuartdouglas> It's not strictly JPA compliant, but that does not mean it is not useful
[01:24:45] <struberg> then this should get mentioned clearly in the docs
[01:24:58] <stuartdouglas> if you do not want a conversation scoped pc just use @PersistenceContext to get a transaction scoped PC
[01:26:03] <stuartdouglas> even without manual flush mode EM's with a scope longer than transaction can still be useful
[01:26:25] <stuartdouglas> but you really should not be serialising them while the transaction is still open
[01:26:37] <stuartdouglas> What server does this?
[01:26:56] <struberg> every server
[01:27:02] <struberg> it's not guaranteed in the servlet spec
[01:27:16] <struberg> so theretically can happen on every server
[01:28:51] <stuartdouglas> imho if you start writing out objects that are participating in a transaction to disk you are asking for trouble in a big way
[01:29:01] <stuartdouglas> It implies that the request has not actually finished
[01:29:14] <stuartdouglas> and the objects could be in the process of being modified as they are written
[01:29:51] <struberg> it is troublesome enough if you have dirty objects in your EM
[01:30:10] <struberg> Seam2 had problems in clusters with that too
[01:56:35] *** struberg has quit IRC
[02:57:32] *** johnament has joined #weld-dev
[05:59:20] *** johnament has quit IRC
[06:30:18] *** mbg has joined #weld-dev
[07:04:42] *** magesh has joined #weld-dev
[07:08:26] *** mbg is now known as mbg|away
[07:15:45] *** mbg|away is now known as mbg
[07:15:56] *** mbg has quit IRC
[08:16:27] *** oskutka has joined #weld-dev
[08:18:46] *** jharting has joined #weld-dev
[08:51:06] *** maschmid has joined #weld-dev
[09:00:01] *** struberg has joined #weld-dev
[09:31:39] *** alesj has joined #weld-dev
[10:04:33] *** stuartdouglas has quit IRC
[10:06:23] *** stuartdouglas has joined #weld-dev
[10:59:30] *** aslak has joined #weld-dev
[11:28:55] *** alesj has quit IRC
[11:47:36] *** alesj has joined #weld-dev
[12:39:55] *** pmuir has joined #weld-dev
[12:47:31] *** pmuir has quit IRC
[13:22:56] *** emmanuel has joined #weld-dev
[13:39:27] *** rmartinelli has joined #weld-dev
[14:49:41] *** emmanuel has quit IRC
[14:56:45] *** epbernard has joined #weld-dev
[14:56:45] *** epbernard is now known as emmanuel
[15:31:42] *** jharting has quit IRC
[16:00:03] *** mbg has joined #weld-dev
[16:33:27] *** rruss has joined #weld-dev
[17:01:42] *** balunasj has joined #weld-dev
[17:06:31] *** alesj has quit IRC
[17:11:31] *** magesh has left #weld-dev
[17:14:03] *** balunasj has quit IRC
[17:32:43] *** jbossbot has quit IRC
[17:32:59] *** jbossbot has joined #weld-dev
[17:37:04] *** jbossbot has quit IRC
[17:37:20] *** jbossbot has joined #weld-dev
[18:01:58] *** cbrock has joined #weld-dev
[18:18:57] *** oskutka has quit IRC
[18:22:25] *** maschmid has quit IRC
[19:12:51] *** emmanuel has quit IRC
[19:24:19] *** oskutka has joined #weld-dev
[19:25:01] *** oskutka has quit IRC
[19:35:33] *** mbg is now known as mbg|away
[19:47:18] *** mbg|away is now known as mbg
[19:49:41] *** mbg has quit IRC
[21:07:09] *** mbg has joined #weld-dev
[21:27:45] *** alesj has joined #weld-dev
[22:18:21] *** rmartinelli has quit IRC
[22:46:57] *** epbernard has joined #weld-dev
[22:46:58] *** epbernard is now known as emmanuel
[22:54:05] *** cbrock has quit IRC
[22:59:41] <alesj> stuartdouglas: seen pmuir's email?
[23:28:01] *** struberg has quit IRC
[23:31:44] *** struberg has joined #weld-dev
[23:37:47] *** struberg has quit IRC
[23:38:29] *** struberg has joined #weld-dev
[23:41:22] *** struberg has quit IRC
[23:58:22] *** emmanuel has quit IRC





top