August 2, 2011 
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
August 2, 2011 [00:08:28] *** jeand_ has quit IRC [00:08:53] <mhuniewicz> aslak, okay, all other tests pass, which means upgrade was successful. :) [00:09:13] <aslak> yeah! :) [00:10:42] <mhuniewicz> Booyah! [00:10:51] <mhuniewicz> But the JBoss 7 one... [00:11:27] <mhuniewicz> javax.persistence.TransactionRequiredException: Transaction is required to perform this operation (either use a transaction or extended persistence context) [00:11:49] <mhuniewicz> aslak, is it safe to assume that injection works and I must now convert my classes to EJB classes? [00:13:44] <aslak> mhuniewicz, or possible change the data source to be non transactional but yea.. either convert to ejb or inject a UserTransaction [00:14:31] <mhuniewicz> I'll battle that tomorrow... [00:14:55] <mhuniewicz> aslak, did you have a chance to look at the PersistenceContext stuff? [00:15:39] <aslak> mhuniewicz, hehe, no sorry.. i'm putting it on my list for tomorrow.. [00:15:53] <mhuniewicz> No pressure! [00:20:57] <mhuniewicz> aslak, thanks A LOT for help today. :) [00:26:47] <aslak> mhuniewicz, my pleasure.. :) [00:27:51] *** dblevins has quit IRC [00:28:14] <mhuniewicz> night night! [00:28:20] *** mhuniewicz has quit IRC [00:35:40] *** dblevins has joined #jbosstesting [00:36:09] *** johnament has joined #jbosstesting [00:40:01] *** aslak has quit IRC [00:50:23] *** alesj has quit IRC [02:07:18] *** ldimaggi has joined #jbosstesting [02:45:39] *** lightguard_jp has quit IRC [03:59:37] *** rruss has quit IRC [04:11:55] *** johnament has quit IRC [04:25:31] *** ALR has joined #jbosstesting [05:23:36] *** ldimaggi has quit IRC [05:37:47] *** OndraZizka has quit IRC [05:38:01] *** OndraZizka has joined #jbosstesting [05:59:17] *** dblevins has quit IRC [05:59:42] *** dblevins has joined #jbosstesting [08:03:23] *** aslak has joined #jbosstesting [08:07:07] *** kpiwko has joined #jbosstesting [08:07:45] * nickarls appears [08:21:14] *** kpiwko1 has joined #jbosstesting [08:23:06] *** kpiwko has quit IRC [08:25:23] *** lfryc has joined #jbosstesting [08:40:31] *** galderz has joined #jbosstesting [08:45:01] *** ge0ffrey has joined #jbosstesting [08:46:33] *** kpiwko has joined #jbosstesting [08:48:52] *** kpiwko1 has quit IRC [08:54:43] *** galderz has quit IRC [09:01:41] *** galderz has joined #jbosstesting [09:04:36] *** Jaikiran has joined #jbosstesting [09:06:27] *** jhuska has joined #jbosstesting [09:08:40] <aslak> ALR, ping [09:08:50] <ALR> aslak: Hey [09:08:56] <aslak> ALR, good morning.. [09:09:01] <ALR> Morning [09:09:05] <aslak> ALR, do you remember much of jboss 6 embedded ? [09:09:06] <aslak> :) [09:09:07] <aslak> http://community.jboss.org/message/618729#618729 [09:09:22] <aslak> i've seen that error 100 times before, but i never remember what's the cause [09:10:02] *** kevinpollet has joined #jbosstesting [09:10:04] <ALR> Right...unable to parse... [09:10:26] <ALR> I think it might be that they also need depchain in import scope. [09:10:36] <ALR> Under depMgmt [09:10:48] <aslak> i noticed that as well, but doe sit really matter ? [09:11:20] <ALR> Yes. [09:11:28] <ALR> import scope is what puts in the exclusions. [09:11:40] <ALR> Otherwise all exclusions in the depchain (and above) POMs are ignored [09:11:51] <ALR> And I think there's some dep leaking in which causes XB to choke [09:11:55] <ALR> That would be my first guess [09:11:56] <ALR> http://anonsvn.jboss.org/repos/jbossas/projects/embedded/examples/tags/6.0.0.Final/pom.xml [09:12:15] <ALR> I'll reply. [09:12:16] <aslak> ok, so the exclusions are in the deepcains depmgm section ? [09:12:27] <aslak> but not in the depchain itself [09:12:38] <aslak> or i mean, not in depchain deps [09:12:57] <ALR> The exclusions themselves are in AS component-matrix [09:13:04] <ALR> But that's above depchain. [09:13:11] <ALR> So depchain gets 'em transitively. [09:13:43] <aslak> hmm, ok [09:13:44] *** oskutka has joined #jbosstesting [09:14:38] <aslak> .. more coffee .. [09:14:42] <ALR> Repied. [09:14:44] <ALR> *Replied [09:14:47] <aslak> thanks [09:17:47] *** rruss has joined #jbosstesting [09:21:32] *** oskutka has quit IRC [09:24:25] *** galderz has quit IRC [09:26:00] *** tdiesler has joined #jbosstesting [09:27:20] *** bgeorges has quit IRC [09:45:01] *** dblevins has quit IRC [09:49:36] *** tommysdk has joined #jbosstesting [09:49:52] *** dblevins has joined #jbosstesting [09:54:57] *** galderz has joined #jbosstesting [09:59:05] *** tommysdk has quit IRC [10:07:04] <aslak> tdiesler, ping [10:08:24] <aslak> tdiesler, working on this, AS7-1156, wanted to discuss why we need it at all.. [10:08:26] <jbossbot> jira [AS7-1156] The JMX-AS7 Protocol should default to Remote [Coding In Progress (Unresolved) Feature Request, Major, Aslak Knutsen] https://issues.jboss.org/browse/AS7-1156 [10:15:14] *** jeand_ has joined #jbosstesting [10:38:46] *** oskutka has joined #jbosstesting [10:38:50] *** alesj has joined #jbosstesting [10:43:12] *** oskutka has quit IRC [11:12:28] *** Jaikiran1 has joined #jbosstesting [11:14:37] *** Jaikiran has quit IRC [11:18:11] <aslak> ALR, you know much about how the as7 deps etc work ? [11:18:15] <aslak> for a service [11:18:21] <ALR> aslak: For a service? [11:18:41] <aslak> ALR, e.g. the arq service. [11:19:06] <aslak> Manifest.mf Dependencies, is that what's triggering a Service startup, or is that just for classpath ? [11:19:49] <ALR> Should just be for CP [11:19:56] <ALR> But of that I'm not 100% sure [11:20:47] <aslak> ALR, trying to figure out if we can get the ArqService to deploy without starting osgi. since that adds about 5 sec deploy time and is rarely used by the users [11:21:10] <aslak> brb.. [11:22:15] *** rbattenfeld has joined #jbosstesting [11:22:15] <ALR> aslak: Ah, so you're really wondering what's triggering the OSGi subsystem to come out of on-demand. [11:22:31] <ALR> rbattenfeld: I just pushed some stuff to SD-54 [11:22:33] <ALR> And rebased it. [11:23:40] <rbattenfeld> ALR: Cool! That means I have to sync. [11:23:57] <rbattenfeld> ALR: just someting else ... [11:24:48] <rbattenfeld> ALR: I should create a JIRA for jaikiran. Do you know how to attache a demo app to the JIRA? [11:25:10] <aslak> ALR, yes [11:25:21] <ALR> rbattenfeld: This is for AS7? [11:25:37] <rbattenfeld> ALR: no JBoss 6.1 [11:26:00] <ALR> rbattenfeld: When you have a JIRA... More Options > Attach Files [11:26:14] <ALR> aslak: Maybe just ask Thomas? [11:26:30] <ALR> IDK what the conditions are which trigger OSGi [11:26:38] <rbattenfeld> ALR: Oh, I see. first to create and then to attach. Good, thanks [11:27:52] <aslak> ALR, yea, just tdiesler doesn't seem to be around atm, thought maybe you knew [11:35:48] <ALR> Time for me to rest a bit [11:36:25] <ALR> rbattenfeld: SHRINKDESC-54 subtasks should give us a good sense of what's on the docket looking forward [11:36:26] <jbossbot> jira [SHRINKDESC-54] Develop/split EE Spec and JBoss-specific descriptors in API / Impl Split [Open (Unresolved) Task, Major, Ralf Battenfeld] https://issues.jboss.org/browse/SHRINKDESC-54 [11:38:42] <rbattenfeld> ALR: Good. I can take over the remaining tasks. Is that ok? [11:40:43] <ALR> rbattenfeld: Absolutely. [11:40:55] <ALR> If I find one I definitely want, I'll assign it to myself. [11:40:58] <ALR> And you can do the same. [11:41:09] <ALR> Any that you leave unassigned I might pick off though [11:41:27] <ALR> So you can mark the ones you definitely want and can get to quickly. [11:42:08] <ALR> And feel free to let me know if any are unclear. For instance SHRINKDESC-67 might need more discussion [11:42:09] <jbossbot> jira [SHRINKDESC-67] Rename "setX(param)" methods which return the "this" instance to "x(param)" [Open (Unresolved) Sub-task, Major, Unassigned] https://issues.jboss.org/browse/SHRINKDESC-67 [11:43:09] <rbattenfeld> ALR: I will have a look:-) [11:44:30] <ALR> Sure, ping me w/ any issues [11:44:36] <ALR> alr at jboss dot org [11:44:42] <ALR> Peace. [11:44:52] *** ALR has quit IRC [11:45:19] *** rbattenfeld has left #jbosstesting [11:55:09] *** maschmid has joined #jbosstesting [12:03:04] *** aslak has quit IRC [12:03:04] *** oskutka has joined #jbosstesting [12:05:48] *** galderz has quit IRC [12:06:11] *** galderz has joined #jbosstesting [12:08:45] *** oskutka has quit IRC [12:10:16] *** oskutka has joined #jbosstesting [12:11:45] *** Jaikiran has joined #jbosstesting [12:14:44] *** pilhuhn has joined #jbosstesting [12:14:44] *** pilhuhn has joined #jbosstesting [12:20:15] *** kevinpollet has quit IRC [12:31:16] *** galderz has quit IRC [12:31:52] *** galderz has joined #jbosstesting [12:32:34] *** ldimaggi has joined #jbosstesting [12:36:22] *** lightguard_jp has joined #jbosstesting [12:36:31] *** lightguard_jp has quit IRC [13:10:18] *** oskutka has quit IRC [13:11:35] *** galderz1 has joined #jbosstesting [13:11:39] *** galderz has quit IRC [13:24:36] *** jose_freitas has joined #jbosstesting [13:42:19] *** kevinpollet has joined #jbosstesting [13:44:02] *** ldimaggi has quit IRC [13:45:40] *** aslak has joined #jbosstesting [13:48:52] *** kevinpollet is now known as pseudo [13:49:24] *** pseudo has left #jbosstesting [13:49:34] *** kevinpollet has joined #jbosstesting [13:57:00] *** lfryc has quit IRC [13:57:27] *** mgoldmann has quit IRC [13:58:42] *** jeand_ has quit IRC [13:58:42] *** jeand_ has joined #jbosstesting [14:08:05] *** galderz1 has quit IRC [14:21:50] *** tommysdk has joined #jbosstesting [14:39:10] *** galderz has joined #jbosstesting [14:44:36] *** kpiwko has quit IRC [14:50:21] *** alesj has quit IRC [14:50:33] *** alesj has joined #jbosstesting [14:52:20] *** mgoldmann has joined #jbosstesting [14:55:50] *** maschmid has quit IRC [15:02:32] *** ldimaggi has joined #jbosstesting [15:12:02] *** vnvarsete has quit IRC [15:22:47] *** tommysdk has quit IRC [15:42:02] *** galderz has quit IRC [15:46:22] *** rruss has joined #jbosstesting [15:50:37] *** rruss has quit IRC [15:55:41] <jose_freitas> hey guys, g'afternoon [16:07:00] *** maschmid has joined #jbosstesting [16:18:29] *** rruss has joined #jbosstesting [16:18:52] *** rruss has quit IRC [16:21:01] *** rruss has joined #jbosstesting [16:21:32] *** rruss has quit IRC [16:23:45] *** galderz has joined #jbosstesting [16:40:15] *** ge0ffrey has left #jbosstesting [16:48:15] *** ldimaggi has quit IRC [16:48:35] *** ldimaggi has joined #jbosstesting [16:50:06] *** galderz has quit IRC [16:50:34] *** galderz has joined #jbosstesting [17:11:46] *** alesj has quit IRC [17:41:02] *** kevinpollet has quit IRC [18:02:30] *** Jaikiran has quit IRC [18:34:46] *** galderz has quit IRC [18:36:21] *** kevinpollet has joined #jbosstesting [18:42:50] *** galderz has joined #jbosstesting [18:45:08] *** maschmid has quit IRC [18:50:03] *** jhuska has quit IRC [18:50:37] *** galderz has quit IRC [18:51:26] *** pilhuhn is now known as pil-dinner-bbl [18:56:19] *** ianbrandt has joined #jbosstesting [19:04:14] *** mgoldmann has quit IRC [19:17:43] *** rbattenfeld has joined #jbosstesting [19:28:12] *** aslak has quit IRC [19:28:32] *** aslak has joined #jbosstesting [19:31:17] <jose_freitas> aslak: how can I access a web.xml inside a WebArchive? [19:34:51] <aslak> jose_freitas, you can't really.. it's not on your classpath [19:34:59] <aslak> jose_freitas, if your talking about from e.g. a Servlet [19:35:31] <aslak> jose_freitas, you can in theory lookup the deployment object via jmx etc and get the descriptor from there, but.. [19:36:22] <jose_freitas> actually I'd like to add a tag on web.xml or faces-config [19:36:36] <jose_freitas> so maybe the way to do it is to write a new one and replace? [19:39:18] <aslak> jose_freitas, oh, you mean within the @Deployment ? [19:39:25] <aslak> or arq spi somewhere.. [19:39:36] <aslak> before deploy to server is what i'm trying to say.. :) [19:40:13] <jose_freitas> yes, in @Deployment [19:42:06] *** ALR has joined #jbosstesting [19:42:18] <aslak> Descriptors.importAs(WebAppDescriptor.class).from( [19:42:18] <aslak> applicationArchive.get(WEB_XML_PATH).getAsset().openStream()) [19:42:50] <ALR> aslak: This looks interesting, what'd I miss? [19:43:02] <aslak> ALR, hehe [19:43:28] <jose_freitas> aslak: the thing is that I create a deploy in a "parent class", so the web.xml provided by it it's really generic [19:43:53] <jose_freitas> so projects that use it would like to add some new clauses to web.xml and faces-config [19:44:32] <aslak> jose_freitas, sure.. just import the generic web.xml [19:45:40] <jose_freitas> yes, and how can I add things on it later? [19:46:48] <aslak> jose_freitas, this is what you do later [19:48:12] <jose_freitas> hm [19:48:33] *** kevinpollet has quit IRC [19:48:33] <jose_freitas> nice [19:48:34] <jose_freitas> thanks [19:49:09] <jose_freitas> :) [19:51:43] <aslak> WebArchive war = getDeployment(); [19:51:43] <aslak> war.setWebXml(new StringAsset( [19:51:43] <aslak> Descriptors.importAs(WebAppDescriptor.class).from( [19:51:43] <aslak> war.get(WEB_XML_PATH).getAsset().openStream()) [19:51:43] <aslak> .servlet("MyNewServlet) [19:51:44] <aslak> .exportToString())) [19:51:46] <aslak> ish [19:51:48] <aslak> :) [19:52:11] <aslak> ALR, we need to fix this integration.. :) [19:52:43] <ALR> aslak: I'm not following that above. [19:52:58] *** rbattenfeld has left #jbosstesting [19:53:01] <ALR> Oh, yes I am. [19:53:21] <jose_freitas> yes, it's kinda hard way to use it [19:53:21] <jose_freitas> hehehe [19:53:26] <ALR> aslak: But that's not the integration point. [19:53:44] <ALR> The integration point is DescriptorAsset [19:53:56] <aslak> ALR, sure, but it doesn't help much [19:54:04] <ALR> What are we finding difficult? [19:54:06] <aslak> ALR, you only save the exportToString part [19:54:29] <aslak> war.getWebXML().servlet("myserlvet") [19:54:33] <ALR> I mean, you're trying to keep the full fluency. [19:54:37] <ALR> I'd be doing 2 lines. [19:54:45] <ALR> 1 to create mutate the Descriptor [19:54:58] <ALR> 1 to create the archive and add the descriptor to it. [19:55:03] <aslak> ALR, not, it's not about that [19:55:05] <aslak> no [19:55:31] <aslak> it's the import of a stream form the archive for so to add it back [19:55:37] <ALR> Hehe, I assumed that's what you were worried about. [19:56:29] <ALR> Right, why are you doing it that way? [19:56:37] <ALR> That's what I meant about the 2-line approach [19:56:49] <aslak> war.getDescriptor("WEB-INF/web.xml", WebAppDescriptor.class).servlet()... [19:56:54] <ALR> Why not mutate the descriptor before adding it to the archive, not after? [19:57:12] <aslak> ALR, because someone else added it [19:57:16] <ALR> k [19:57:19] <ALR> Lemme think. [19:58:14] <ALR> DescriptorType d = archive.as(DescrpitorArchive.class).getDescriptor(ArchivePath,DescriptorType.class); ? [19:58:58] <aslak> mmm.. possible [20:01:11] <aslak> that atleast can be done as a pure extension [20:02:39] <ALR> aslak: Already is [20:02:46] <ALR> We'd just need to add it there [20:04:16] <aslak> desc-ext you mena.. yea [20:04:18] <aslak> mean [20:06:53] <jose_freitas> btw aslak, when reinserting the file, I should delete the old one, right? because of that bug/feature that keeps the first instance of the file. [20:07:15] <aslak> jose_freitas, mm.. probably [20:09:03] <aslak> jose_freitas, you should be able to use war.delete(String).getAsset().openStream() instead of war.get()... [20:09:50] <jose_freitas> it doesn't accept String [20:09:58] <jose_freitas> just an ArchivePath [20:10:09] <aslak> aa.. hmm [20:10:22] <aslak> well, ArchivePaths.create(String) then [20:10:44] <jose_freitas> thanks, I was looking for a way to create it :) [20:10:49] <aslak> ALR, api inconsistency ? get and contains support both ArchivePath and String, delete only AP ? [20:11:06] <jose_freitas> delete return a Node [20:11:09] <jose_freitas> it breaks the chain [20:11:24] <ALR> aslak: Yes. We need delete(String) [20:11:47] <jose_freitas> is there a reason to return Node? [20:12:01] <aslak> jose_freitas, it returns what was deleted [20:12:07] <ALR> So you get back what was removed [20:12:10] <ALR> Or null if nothing [20:12:40] <ALR> If we returned void, we'd need to throw some exception to let the user know it was a NO-OP [20:12:55] <ALR> Plus this is consistent w/ how the Map API is, so should be familiar to folks. [20:13:04] * ALR opening a ticket. [20:13:26] <jose_freitas> true [20:15:44] <ALR> https://twitter.com/#!/ALRubinger/status/98456212546396160 [20:18:30] <aslak> :) [20:39:29] <jbossbot> git [descriptors] push SHRINKDESC-54 a956c17.. ralfbattenfeld [SHRINKDESC-63] Support XSDs with simpleContent elements [20:39:30] <jbossbot> jira [SHRINKDESC-63] Support XSDs with simpleContent elements [Resolved (Done) Sub-task, Major, Ralf Battenfeld] https://issues.jboss.org/browse/SHRINKDESC-63 [20:39:30] <jbossbot> git [descriptors] push SHRINKDESC-54 URL: http://github.com/shrinkwrap/descriptors/compare/af3d11a...a956c17 [20:44:10] *** kevinpollet has joined #jbosstesting [21:07:46] <aslak> ALR, do you know anything about container-managed-clustering ? [21:08:26] *** pil-dinner-bbl is now known as pilhuhn [21:08:36] *** bleathem has joined #jbosstesting [21:09:02] *** bleathem has quit IRC [21:09:33] *** jeand has joined #jbosstesting [21:09:49] *** jeand_ has quit IRC [21:17:55] <ALR> aslak: Nope. [21:22:11] *** nilian has joined #jbosstesting [21:27:26] *** mhuniewicz has joined #jbosstesting [21:29:05] <mhuniewicz> ALR, hi [21:29:25] <ALR> mhuniewicz: Yo [21:30:18] <mhuniewicz> ALR, I developed a bit of code with CDI but I need transaction support. Turns out, to have it using annotations I need to use EJB. Would you say that CDI lies in the view layer and EJB is for the logic layer? [21:30:40] <ALR> Nope, CDI is business logic. [21:30:45] <ALR> It just doesn't have Tx by default. [21:30:50] <ALR> So you can have CDI call EJB [21:30:55] <ALR> Or you can enable Tx atop CDI [21:32:15] <mhuniewicz> In terms of the first solution, I put some effort into thinking about scopes and I'm mostly using Request and Application scopes. With EJB 3.1, am I limited to Stateless, Stateful and Singleton? [21:32:25] <mhuniewicz> How does EJB relate to scopes? [21:33:03] <ALR> Those are the scopes in EJB. [21:33:16] <ALR> Stateful for all intents and purposes *is* a conversational scope. [21:33:35] <ALR> But it's not the same/tied to CDI conversation scope [21:34:45] <mhuniewicz> What if I have a stateless bean that asks for something to be injected from the Request scope? Is that even valid? [21:35:09] <jose_freitas> ALR, but you can apply cdi scopes to stateful ejbs, no? [21:35:22] <jose_freitas> like creating a requestScoped stateful ejb [21:36:49] <ALR> mhuniewicz: No, that's not valid. [21:37:08] <ALR> But you can inject SLSBs into requestScoped CDI beans and that'll work fine [21:37:14] *** tdiesler has quit IRC [21:37:26] * ALR is looking for Seam Transactions. I'd thought that was a project. [21:37:32] <ALR> And if it's not, why not? [21:37:40] <ALR> Simple annotation to add Tx support to CDI. [21:37:42] <ALR> It'd be easy. [21:37:45] <ALR> Interceptor model. [21:38:10] <jose_freitas> ALR, seam persistence is what you're looking for, transaction is going to be separated, but it's not yet, If I'm not mistaken [21:38:22] <ALR> Ah, they baked Tx into persistence? [21:38:26] <jose_freitas> yes [21:42:19] <mhuniewicz> ALR, does it mean I have to implement it myself or...? [21:42:53] <ALR> mhuniewicz: I would. Or find a way to call into EJB that doesn't disrupt your scoping. [21:43:05] <ALR> mhuniewicz: Or reach out to the Seam guys and offer to pull Tx out of Persistence. [21:43:13] <ALR> IMO Persistence should depend upon Tx, not include it. [21:43:43] <jeand> hey guys [21:43:44] <mhuniewicz> ALR, isn't that a flaw? Or a missing feature? I wish I could just say @Transactional. [21:44:31] <jeand> aslak, we resume the work on Mobicents Sip Servlets integration with Arquillian [21:44:31] <ALR> mhuniewicz: A flaw in CDI, no. Tx is left out of scope in the spec with the intent that the extensions SPI are used to provide it. [21:44:45] <mhuniewicz> ALR, a flaw in JEE? [21:44:56] <ALR> mhuniewicz: A flaw in Seam3, that's up for debate. Again, IMO, they should be separate. [21:45:03] <jeand> we are back to the way we were some time ago when I did a push request [21:45:04] <jose_freitas> ALR, you're right, that's why it's gonna be separated [21:45:23] <jeand> therefore I would like to push it again [21:45:40] <ALR> mhuniewicz: Again, recommend you reach out to the Seam team and offer to separate 'em. [21:45:43] <ALR> Shouldn't be too hard. [21:46:04] <aslak> jeand, heya [21:46:09] <jeand> Georges Vagenas will send you a mail [21:46:19] <jeand> to query for how to push it to you [21:46:24] <aslak> jeand, awesome.. [21:46:26] <ALR> mhuniewicz: https://github.com/seam/persistence/tree/develop/api/src/main/java/org/jboss/seam/transaction [21:46:30] <jeand> it is located here https://github.com/gvagenas/arquillian-container-mobicents-sip-servlets [21:46:42] <aslak> jeand, any reason not to have it on the mobicents side ? [21:47:22] <mhuniewicz> ALR, is there a JSR for this or something? I'm trying to stick to vanilla JEE. [21:48:14] <jeand> aslak, not really I was thinking those things would be in arquillian repo [21:48:21] <ALR> mhuniewicz: Then your only option for pure JEE is to call into an EJB *or* do bean-provided Tx management by injecting TransactionManager [21:49:04] <jeand> but if we can keep it on mobicents side that's fine [21:49:11] <ALR> Java EE at this point does not account for Tx in CDI. CDI is a programming model and intentionally leaves out services like Security, Tx, etc [21:49:31] <ALR> EJB on the other hand bakes those in by default. [21:49:46] *** tdiesler has joined #jbosstesting [21:49:47] <ALR> mhuniewicz: Or take a hybrid approach. [21:49:54] <ALR> mhuniewicz: Make a SLSB. [21:50:24] *** tdiesler has quit IRC [21:50:26] <aslak> jeand, as the Arq APIs have stabalized, there is nothing wrong with it being a part of the mobicents repo. it will follow the mobicents release cycle anyway [21:50:48] <aslak> jeand, and you will be using it, so you want the control right ? :) [21:50:53] <jeand> indeed [21:50:56] <jeand> cool then :-) [21:50:58] <mhuniewicz> ALR, I thought of CDI for the web part and it uses EJBs. [21:51:04] <jeand> better like this indeed [21:51:15] <ALR> mhuniewicz: https://github.com/jbossejb3/oreilly-ejb-6thedition-book-examples/blob/master/testsupport/src/main/java/org/jboss/ejb3/examples/testsupport/txwrap/TxWrappingBean.java [21:51:26] <ALR> mhuniewicz: Make something like that. [21:51:35] <aslak> jeand, we just include some info on what it is, examples etc in the arq doc to show of, but it can live on your side.. :) [21:51:40] <ALR> Then inject it into any CDI bean in any scope. Because it's a SLSB it won't matter [21:52:04] <jose_freitas> http://www.oracle.com/technetwork/issue-archive/2011/11-jan/o11java-195110.html [21:52:04] <ALR> mhuniewicz: Then for just the bits you want wrapped in a Tx, put that logic into a Callable or List of Callables [21:52:16] <ALR> mhuniewicz: And send that List off to the TxWrappingEJB [21:52:16] <jose_freitas> there's a great article by adam bien on that link [21:52:33] <mhuniewicz> Aha, I see. [21:52:41] <jeand> aslak, ok we will plan the release [21:52:43] <mhuniewicz> Is this example from the book? [21:52:48] <jeand> and send you all needed information [21:52:52] <ALR> mhuniewicz: yes [21:52:56] <jeand> when we are good to go [21:52:56] <aslak> jeand, cool :) [21:53:09] <aslak> jeand, how is mobicents and as7 ? [21:53:14] <mhuniewicz> Maybe I should buy it then. Are you doing any signing in London soon? ;) [21:53:25] <ALR> mhuniewicz: Hehe. [21:53:26] <jeand> aslak, we are going to release MSS 1.6 in the next few days [21:53:45] <jeand> aslak, and then we are going full throttle on AS7 integration [21:53:57] <jeand> once it is done we are going to deliver arq on MSS on AS7 [21:54:01] <jeand> as well [21:54:04] <aslak> jeand, nice :) [21:54:21] <ALR> jeand: Hurry up. I hate my current VOIP provider. [21:54:27] <jeand> ALR, LOL [21:54:36] <jeand> which one is it ? [21:54:52] *** nilian has quit IRC [21:54:54] <ALR> jeand: Vonage. Actually they were quite good. But just another bill. [21:55:38] <jeand> ALR, I need to ping them to make them switch to Mobicents then :-) [21:56:27] <ALR> Lower costs. [21:56:28] <ALR> Good. [22:00:02] <jose_freitas> ALR, can I ask you something too? [22:00:13] <ALR> jose_freitas: Shoot [22:01:37] <jose_freitas> you said that stateful by definition is conversation scoped, but when we have a @RequestScoped @Stateful Bean, what happens inside? does the container keeps one requestScoped proxy to a conversational ejb? [22:02:09] <jose_freitas> and who is managing the lifecycle of the ejb in this case? [22:02:16] <ALR> It's not "Conversation Scoped" as defined by CDI. [22:02:22] <ALR> But a SFSB has a conversational scope. [22:02:37] <ALR> In that it has one backing instance for each caller/proxy. [22:02:56] <ALR> I have no idea what a @RequestScoped @Stateful is, TBH [22:03:00] <ALR> Or if that's possible [22:03:07] <ALR> I'm not really a CDI expert. [22:03:09] <jose_freitas> https://github.com/seam/examples/blob/master/booking/src/main/java/org/jboss/seam/examples/booking/booking/BookingAgent.java [22:03:34] <jose_freitas> in this case BookingAgent is explicity using cdi conversation scope [22:03:46] <jose_freitas> https://github.com/seam/examples/blob/master/booking/src/main/java/org/jboss/seam/examples/booking/booking/BookingHistory.java [22:03:52] <jose_freitas> here is a sessionscoped ejb [22:04:32] <ALR> If I were to guess, and this is a guess, then the SFSB there has a conversational scope which starts and ends w/ the HTTP request [22:04:43] <ALR> Keeping in mind that even @RequestScoped isn't a CDI thing [22:04:46] <ALR> But a Faces thing [22:05:03] <jose_freitas> there're two @RequestScoped annotations [22:05:07] * ALR has to get on a call [22:05:09] <ALR> Sorry [22:05:10] <ALR> Be back [22:05:12] *** lightguard_jp has joined #jbosstesting [22:05:12] <jose_freitas> ok [22:05:18] *** rruss has joined #jbosstesting [22:09:10] <mhuniewicz> aslak, a TopLink guy told me that he doesn't know if supporting null persistence unit name is JPA. [22:09:15] <mhuniewicz> I though it was. [22:10:02] <aslak> mhuniewicz, yea, looking at the javadoc it doesn't specify [22:10:27] <aslak> mhuniewicz, no defined name might be the @PersistenceContext annotation only and belong to EE [22:11:28] <mhuniewicz> aslak, is he right then? [22:12:43] <aslak> mhuniewicz, maybe.. would need to read the jpa and ee specs [22:13:53] <mhuniewicz> aslak. he first closed it, then made it into an enhancement. [22:18:40] *** rbattenfeld has joined #jbosstesting [22:28:34] *** ldimaggi has quit IRC [22:31:41] <mhuniewicz> aslak, when using Arquillian to run a test on JBoss 7 I am getting this: A component named 'DefaultObjectTrackDataHandler' is already defined in this module [22:32:29] <rbattenfeld> ALR: how urgent is the beans descriptor? [22:32:59] <ALR> rbattenfeld: It's no more urgent than anything else in 1.2.0-X [22:33:02] <mhuniewicz> aslak, when I remove the EJB class from the @Deployment method, I'm getting No EjbLookup registry has been provided CDI @EJB injection [field] @EJB private. [22:33:12] <ALR> rbattenfeld: But it will be a launch criteria for 1.2.0-X [22:33:18] <ALR> Probably one of the most use descriptors. [22:33:52] <ALR> Well, let me rephrase. It's not more urgent than 1.2.0-X, but it is one of the most important things in 1.2.0-X [22:34:03] <rbattenfeld> ALR: ok, I am analysing it. The style is pretty much different than the others... [22:37:39] <aslak> mhuniewicz, ? [22:37:54] <mhuniewicz> aslak, I'm using Arquillian to run tests with embedded JBoss 7. [22:38:43] <aslak> mhuniewicz, embedded 7 ? [22:38:53] <mhuniewicz> aslak, yes. [22:39:48] <aslak> mhuniewicz, where did you get that? [22:39:59] <mhuniewicz> Get what? [22:40:08] <aslak> embedded 7 [22:41:47] <mhuniewicz> <groupId>org.jboss.as</groupId> [22:41:49] <mhuniewicz> <artifactId>jboss-as-arquillian-container-managed</artifactId> [22:41:50] <mhuniewicz> <version>7.0.0.CR1</version> [22:41:52] <mhuniewicz> aslak, there [22:42:05] <aslak> mhuniewicz, aa, managed, not embedded [22:42:15] <mhuniewicz> Oh, sorry. [22:43:57] <mhuniewicz> aslak, so, first of all, should the EJB be listed in @Deployment? [22:44:33] <aslak> mhuniewicz, sure, @Deployment defines what you want to deploy [22:45:19] <mhuniewicz> aslak, I need to have it injected in the test. Should I use @EJB or @Inject? [22:45:56] <aslak> mhuniewicz, doesn't really matter.. [22:46:00] <aslak> :) [22:46:25] <mhuniewicz> What could be wrong then... [22:46:39] <mhuniewicz> I just replaced @RequestScoped with @Stateful for now. [22:47:00] <mhuniewicz> I annotated the CLASS, but it implements an interface. Could that be the problem? [22:47:33] <rbattenfeld> ALR: the beans.xsd is really different. There is not even a root element defined... That means, we have to define more details in the schemasXXX.xml so that the later scripts know what to do. Besides that the jboss uses xs: as namespace [22:50:04] <aslak> mhuniewicz, hmm.. do you use @Named ? [22:50:18] <mhuniewicz> aslak, no. I'm not. [22:50:24] <ALR> rbattenfeld: OK. So that's interesting about it. [22:50:55] <aslak> mhuniewicz, can you pastebin the stacktrace ? [22:51:20] <mhuniewicz> aslak, certainly. [22:51:39] <mhuniewicz> aslak, http://pastebin.com/w9kCGDDx [22:53:14] <aslak> mhuniewicz, hmm, do you have the same EJBs packaged multiple timesin different jars or similar? [22:53:35] <mhuniewicz> aslak, let me see.. [22:54:43] <mhuniewicz> aslak, good guess, it's added once as a class and once inside a jar! [22:55:14] <mhuniewicz> aslak, I'll try to prevent that. [22:55:15] <aslak> mhuniewicz, yeah! 1 point to me.. ;) [22:55:27] <mhuniewicz> 1 more and you'll reach a hundred. ;) [22:56:27] <aslak> then a golden star.. [22:56:28] <aslak> :) [22:58:45] <mhuniewicz> uh oh [22:58:58] <mhuniewicz> aslak, problem - I'm using resolveAsFiles(new ScopeFilter("test"))) [22:59:16] <mhuniewicz> and it adds all my libs which are indeed test deps. But, I'm using exclusions too. [22:59:30] <mhuniewicz> While exclusions work for Hibernate, they don't work for my own stuff... [23:04:17] <rbattenfeld> ALR: by the way, I couldn't find the services files for the new descriptors. Are they in a separate folder? [23:06:37] <ALR> rbattenfeld: They're in gen. [23:07:13] <ALR> And likely they should be in api-whatever or impl-whatever [23:07:20] <ALR> I'll open an issue for that [23:08:43] <ALR> SD-70 [23:09:07] <rbattenfeld> ALR: fine [23:10:25] *** jeand has quit IRC [23:18:10] <mhuniewicz> aslak, fixed. Still, I'm getting: Caused by: java.lang.RuntimeException: No EjbLookup registry has been provided CDI @EJB injection [field] @EJB private [23:18:44] <rbattenfeld> ALR: I was also looking at the connector_1_5.xsd. You mentioned that this spec is javaee 5? I am using this link for all the specs: "http://java.sun.com/xml/ns/javaee/" according this link, the jca 1.5 is j2ee 1.4 [23:19:05] <ALR> rbattenfeld: It's both [23:19:21] <ALR> JCA did not get a revision inbetween 1.4 and EE 5 [23:20:27] <ALR> See the date: http://www.jcp.org/en/jsr/detail?id=112 :) [23:20:56] <aslak> mhuniewicz, pastebin [23:21:50] <rbattenfeld> ALR: with the same definition? That is the issue, jca 1.5 requires I guess web service spec from j2ee 1.4 and uses 'j2ee' as namespace [23:21:50] <mhuniewicz> aslak, http://pastebin.com/99NsJuac [23:22:26] <rbattenfeld> ALR: yes, there is no changes in between but ... [23:23:11] <ALR> hmm [23:23:19] <ALR> rbattenfeld: Let me ask Jesper on that [23:23:22] <ALR> He's out JCA lead [23:23:24] <ALR> *our [23:23:25] *** oskutka has joined #jbosstesting [23:23:53] <rbattenfeld> ALR: the context is still j2ee 1.4. [23:25:48] <ALR> Yup [23:26:08] <ALR> All I know is that we used JCA 1.5 in EJB 3.0 for EE 5. [23:26:18] <ALR> So how that relates to XML is beyond what I dealt with [23:26:28] <ALR> The jboss-metadata project did this already BTW [23:26:35] <ALR> That's where I'm pulling some test resources from [23:26:50] <ALR> In the test module; for instance there's a couple fully-populated XML files there to help in testing [23:27:52] <rbattenfeld> ALR: yes, that is very helpful and important [23:28:47] <ALR> What'd be cool is if I can figure a good way to take a bunch of existing jboss-metadata tests and retool them to our API [23:28:54] <ALR> Basically port them [23:29:34] <rbattenfeld> ALR: that would be super:-) [23:30:10] <mhuniewicz> ALR, if I have a class that used to be @RequestScoped and now I want it to be EJB 3.1 Stateful bean, is it enough to replace the previous annotation with @Stateful? [23:30:41] <ALR> Uh huh. [23:31:04] <ALR> And you'll get a no-interface view, assuming the class has no interfaces. [23:31:13] <aslak> mhuniewicz, the UndeclaredThrowableException exception your getting you fix by adding this: https://gist.github.com/1053571 [23:31:19] <ALR> If it does, it'll default to a local business interface view [23:31:31] <rbattenfeld> ALR: it is late now. I will processed with beans and jboss separation tomorrow. Cheers! [23:31:37] <mhuniewicz> ALR, it has one interface. Is that OK? [23:32:06] <ALR> mhuniewicz: Yes, just designate how you want the EJB to be exposed. [23:32:08] <aslak> mhuniewicz, not sure about the other one.. [23:32:14] <ALR> Using @Local(InterfaceName.class) [23:32:14] <mhuniewicz> aslak, does it mean I have to start the server myself? [23:32:27] <ALR> or @LocalBean < To show you want consumers to have a no-interface view [23:32:58] *** rbattenfeld has left #jbosstesting [23:33:03] <mhuniewicz> ALR, so it's not enough to add @Stateful? [23:33:09] <aslak> mhuniewicz, no, it's a 'bug' in the jmx-protocol it uses. it just does something stupid if you don't use that config.. :) [23:33:12] <mhuniewicz> I have no experience with EJB 3.1. [23:34:19] <ALR> mhuniewicz: EJBs have views. [23:34:43] <ALR> Meaning, unlike a pure POJO, the proxy that's bound will expose either a business interface [23:34:48] <ALR> Or a no-interface [23:35:08] <ALR> Depending upon what your client is expecting, you want to ensure you're making the right view available [23:35:15] <ALR> I happen to prefer business interface views. [23:35:32] <ALR> Because it ensures the client uses no internals in the EJB and sees only the contracted business methods [23:35:39] <ALR> So in that case I'd do: [23:35:58] <ALR> @Stateful @Local(MyBusinessInterface.class) public class MyBean implements MyBusinessInterface [23:36:02] <ALR> And then in the client: [23:36:10] <ALR> @EJB private MyBusinessInterface ejb [23:36:54] <mhuniewicz> ALR, I'll try that in a sec. [23:37:28] <mhuniewicz> aslak, is jbossHome needed? [23:37:53] <aslak> mhuniewicz, jbossHome or env JBOSS_HOME [23:40:39] *** pilhuhn has quit IRC [23:40:48] <mhuniewicz> aslak, Cannot obtain MBeanServerConnection to: service:jmx:rmi:///jndi/rmi://127.0.0.1:1090/jmxrmi [23:41:30] <mhuniewicz> I think I DO need to start it myself. [23:42:02] <aslak> mhuniewicz, your still using the managed container right ? [23:42:23] <mhuniewicz> aslak, no, the thing told me to set it to REMOTE. I didn't? [23:42:53] <aslak> no.. :) [23:43:11] <aslak> you can use managed, you just need to use that configuration for arq.xml [23:43:15] <aslak> the <protocol> part [23:43:40] <mhuniewicz> It's already this: <protocol type="jmx-as7"> [23:44:00] <aslak> that REMOTE is not the container type, but the configuration for the Protocol, which is different [23:44:20] <mhuniewicz> Oh so that should say REMOTE, but dependency should be managed? [23:44:26] <aslak> yes [23:44:50] <aslak> or dependency can be remote, but then you'll hvae to start it your self.. :) [23:45:03] *** kevinpollet has quit IRC [23:52:20] <mhuniewicz> Oh boy. [23:52:24] <mhuniewicz> So it knows about it [23:52:43] <mhuniewicz> '[...] bindings for session bean named DefaultObjectTrackDataHandler in deployment unit deployment "MacOsLibraryWithServiceIT.war" are as [...]' [23:54:34] <mhuniewicz> Still, this [23:54:35] <mhuniewicz> http://pastebin.com/8DyfaHVG [23:56:43] <mhuniewicz> ALR, does this look familiar by any chance? Caused by: java.lang.RuntimeException: No EjbLookup registry has been provided CDI @EJB injection [field] @EJB private [23:56:43] <aslak> mhuniewicz, what is your deployment structure and where have you placed your ejbs ? [23:57:33] *** jose_freitas has quit IRC [23:57:33] <ALR> mhuniewicz: Hmm, no. [23:57:39] <ALR> Maybe @Inject is what they expect? [23:57:59] <mhuniewicz> aslak, Arquillian builds it for me. It's a WAR file. [23:58:16] <aslak> mhuniewicz, hehe [23:58:21] <mhuniewicz> aslak, the classes are in WEB-INF/classes. [23:58:41] <mhuniewicz> There's no web.xml. There's a beans.xml. [23:58:48] <mhuniewicz> Eh? [23:58:57] <aslak> mhuniewicz, ejbs in jar in lib ? [23:59:20] <mhuniewicz> It's a war.