March 30, 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 | >
March 30, 2011 NOTICE: This channel is no longer actively logged.
[00:04:02] *** bstans_afk is now known as bstansberry[00:21:41] *** irooskov_ has quit IRC[00:21:43] *** jpearlin has joined #jboss-as7[00:26:25] *** fnasser has quit IRC[00:31:17] *** mbg|away is now known as mbg[00:36:43] <stuartdouglas> I have a fix for the integration test regressions at https://github.com/stuartwdouglas/jboss-as/commit/ee76a7a5b0b58fc0b6727cb7c6348013fb6ff01f[00:36:43] <jbossbot> git [jboss-as] ee76a7a.. Stuart Douglas Fix integration test regressions[00:40:52] <jamezp> Not that I have any say, but looks good to me.[00:41:01] *** asoldano_away has quit IRC[00:59:02] *** jwulf has joined #jboss-as7[01:07:37] *** aslak has quit IRC[01:14:56] *** rawbdor has quit IRC[01:27:24] *** sannegrinovero has quit IRC[01:32:49] <Nihility> stuartdouglas just merged a fix for that[01:33:00] *** smarlow has joined #jboss-as7[01:33:01] *** ChanServ sets mode: +v smarlow[01:33:17] *** mbg is now known as mbg|away[01:35:29] <stuartdouglas> Nihility: ok, I will rebase that out of my master then[01:36:11] <stuartdouglas> hmm, I could have sworn I did a fetch just before I did that fix[01:36:31] *** irooskov has joined #jboss-as7[01:37:50] <smarlow> Nihility: thanks for the merge[01:44:10] *** irooskov has quit IRC[01:49:18] <bstansberry> dmlloyd (or anyone familiar with dmr parsing) https://github.com/bstansberry/jboss-dmr/commit/43c66969995112b53eb329ebd6a57567a131c94d and a dmr release will let us fix JBAS-9140[01:49:19] <jbossbot> jira [JBAS-9140] Incorrect value for boolean parameter [Open (Unresolved) Bug, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-9140[01:49:20] <jbossbot> git [jboss-dmr] 43c6696.. bstansberry at jboss dot com Fix boolean and long parsing issues (thanks to aloubyansky)[01:52:17] *** irooskov has joined #jboss-as7[01:57:50] <jpearlin> Nihility: I pushed the smoke test for the deployment upload: https://github.com/jdpgrailsdev/jboss-as/commit/ea86c8a1693baf166bb19aa3d5f781a860a6bfb8[01:57:51] <jbossbot> git [jboss-as] ea86c8a.. Jonathan Pearlin Added smoke test for deployment upload via http.[01:58:24] * smarlow rebooting to heal vpn issue (hopefully)[01:59:06] <Nihility> bstansberry: That looks correct but iirc Json has lowercase Boolean values[02:00:28] <bstansberry> Nihility: are you talking about in the @Rule in JSONParserImpl ?[02:01:53] *** smarlow has quit IRC[02:02:03] <bstansberry> those are the String form of the token enum at the top of the class[02:02:23] *** smarlow has joined #jboss-as7[02:02:23] *** ChanServ sets mode: +v smarlow[02:02:27] * bstansberry pretends to have deep understanding[02:02:52] <Nihility> ah I was just about to mention that I did not see the full file since I'm on a phone[02:04:11] <stuartdouglas> dmlloyd: The latest version of my resource injection patch is at https://github.com/stuartwdouglas/jboss-as/compare/master[02:05:51] <stuartdouglas> It fixes a number of problems that resource injection has at the moment to do with bindings being doubled up, and also adds tests for these situations[02:05:58] <Nihility> bstansberry: duh that's the token area not the lexer[02:06:13] <Nihility> approved![02:06:21] <bstansberry> thanks[02:07:02] <jbossbot> git [jboss-dmr] push master 43c6696.. bstansberry at jboss dot com Fix boolean and long parsing issues (thanks to aloubyansky)[02:07:02] <jbossbot> git [jboss-dmr] push master URL: http://github.com/jbossas/jboss-dmr/compare/39829c8...43c6696[02:07:46] <Nihility> jpearlin: Thx I will check it out[02:07:56] *** irooskov has quit IRC[02:12:44] <Nihility> jamezp: Want to do a jndi enhancement?[02:13:26] <jamezp> Nihility: Sure, is it something that needs to be done right away?[02:14:14] <Nihility> one is not time sensitiv at all the other is marginally semsitiv[02:14:56] <jamezp> I'll take it then.[02:15:21] <Nihility> the non sensitive one?[02:16:06] <jamezp> When is the sensitive one due? If I have a couple weeks I'm probably good to do either.[02:16:09] *** irooskov has joined #jboss-as7[02:16:34] <jamezp> Just don't want to commit to something I may not have time finish and make life more difficult for others :-)[02:17:35] <Nihility> ok well lets start with this one, we used to have a thing that debugged called jndiview it dumps all the jndi entries on the server[02:18:10] <Nihility> it no longer is complete after we moved to service based contexts[02:19:03] <jamezp> Okay.[02:19:56] <Nihility> so somehow we should track all jndi contexts (needs thought) and then just traverse them and potentialoy follow references[02:20:27] *** jpearlin has quit IRC[02:20:52] <stuartdouglas> what is the other jndi issue?[02:21:12] *** jpearlin has joined #jboss-as7[02:21:45] <jamezp> Is the JNDI stuff in the naming module?[02:21:59] <Nihility> the other issue which is important but not in the beta2 list is mapping everythjng in global correctly acoording to the good xhoixe of those contradicting spwc rules[02:22:55] <stuartdouglas> hehe[02:23:07] <Nihility> java:global/app/subdir/module/localejb[02:23:34] <Nihility> bbiab[02:27:16] <bstansberry> can anyone have a look at https://github.com/bstansberry/jboss-as/commit/120b9230bc583b51170aac67269a9b13dc9c64af ?[02:27:17] <jbossbot> git [jboss-as] 120b923.. bstansberry at jboss dot com [JBAS-9146] Deployment plans should roll back on each server by default[02:27:18] <jbossbot> jira [JBAS-9146] ServerDeploymentManager deployment plans should rollback by default [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9146[02:33:04] *** jamezp has left #jboss-as7[02:33:38] *** jamezp has joined #jboss-as7[02:37:56] *** jamezp is now known as jamezp_afk[02:51:40] *** JimMa has quit IRC[03:10:18] *** asaldhan has quit IRC[03:26:09] *** miclorb has quit IRC[03:31:57] *** jamezp_afk is now known as jamezp[03:36:39] <Nihility> jamezp: hey if brian had you assigned to stuff[03:36:51] <Nihility> jamezp: he should win[03:36:52] <Nihility> :)[03:37:11] <jamezp> Ah okay. Yeah, he had something for me.[03:38:20] <stuartdouglas> Nihility: Something that has occured to me is that at the moment we a are pulling all our annotation information out of CompositeIndex[03:38:29] <stuartdouglas> which only has annotation information for the current deployment[03:38:56] <stuartdouglas> so if say, a component in a war has an interceptor deployed in a different deployment, it won't work[03:39:44] <Nihility> you mean a totally separate deployment[03:39:48] <stuartdouglas> or if components from different deployments inherit from one another[03:39:48] <Nihility> or something thats in the ear[03:39:56] <stuartdouglas> in the ear[03:40:43] <Nihility> i think the composite index for a deployment should follow the classloader deployment imports[03:40:48] <Nihility> but not static module boundaries[03:40:57] <stuartdouglas> but then it will pick up annotations from the other deployment[03:41:05] <stuartdouglas> so EJB's will be processed twice[03:41:06] <stuartdouglas> etc[03:41:09] <stuartdouglas> I think the way to fix it is to split CompositeIndex into two separate classes with different scopes[03:41:21] <stuartdouglas> a ClassInfoStore that follows the visibility rules[03:41:25] <Nihility> actually[03:41:34] <stuartdouglas> and the existing CompositeIndex that is scoped to the deployment[03:41:35] <Nihility> thats probably correct[03:41:49] <Nihility> if i have ejbs in a jar[03:42:01] <Nihility> and that jar is class-path refd[03:42:09] <Nihility> from an ejb deployment[03:42:12] <stuartdouglas> in that case it is correct[03:42:21] <stuartdouglas> but what if the classes are from another ejb-jar?[03:42:54] <stuartdouglas> you should still be able to inherit from them / use their interceptors[03:43:00] <stuartdouglas> but you can't at the moment[03:43:34] <Nihility> hmm im not sure i tend to say that should work as well[03:44:06] <Nihility> the interesting thing is the beans would be scoped to two different deployments[03:44:19] <Nihility> which is certainly entertaining[03:44:28] <stuartdouglas> hmm[03:44:31] <Nihility> let me check the spec because it has some limits that are imposed[03:47:26] <stuartdouglas> @Resource should definitely work, 'Even though this annotation is not marked Inherited, if used all superclasses MUST be examined to discover all uses of this annotation'[03:47:47] <stuartdouglas> so even if the super class is in a different DU, we still need the annotation information[03:56:29] *** JimMa has joined #jboss-as7[03:57:09] <stuartdouglas> Is it just me or is there no portable way to ensure that a war has access to an ejb-jar, according to the spec class-path only has to have to work for libraries, rather than deployments[03:58:06] <Nihility> nah the ejb spec is pretty clear about this[03:58:15] <Nihility> take a look at the packaging section[03:59:34] <stuartdouglas> ah[03:59:46] <Nihility> actually 20.3 makes it clear[03:59:47] *** baileyje has quit IRC[03:59:51] <stuartdouglas> I was just looking at the EE platform spec[03:59:58] <Nihility> that bean implementation classes[04:00:05] <Nihility> can be in a different jar[04:03:11] <stuartdouglas> yea, but only if the bean is defined in ejb-jar.xml[04:03:22] <stuartdouglas> 'An enterprise bean class with a component-defining annotation defines an enterprise bean component when packaged within the WEB-INF/classes directory or in a .jar file within WEB-INF/lib. An enterprise bean can also be defined via WEB-INF/ejb-jar.xml.'[04:05:01] *** jpearlin has quit IRC[04:07:03] <stuartdouglas> I can't see anything that indicates that annotations from classes outside the deployment should not be read[04:13:17] <stuartdouglas> Nihility: So what do you think, is this going to be a problem?[04:14:53] <Nihility> yeah i think you are right[04:15:05] <Nihility> i see lots of references that say an ejb-jar must have one class[04:15:12] <Nihility> that is annotated with @EJB[04:15:15] <Nihility> erm[04:15:20] <Nihility> @Stateless etc[04:15:26] <Nihility> to be considered[04:16:25] <Nihility> so yeah we need two composite indexes it seems[04:17:09] <stuartdouglas> I might start working on that then, as I can't go much further on my resource injection stuff without review[04:19:27] *** mbg|away is now known as mbg[04:20:59] <stuartdouglas> unless there is something else you want me to look at?[04:21:55] <Nihility> sure sounds good[04:22:26] *** miclorb has joined #jboss-as7[04:22:28] <Nihility> so it seems like the "component defining" index[04:22:34] <Nihility> is in the ejb case[04:22:40] <Nihility> just the jar so not really composite[04:22:50] <Nihility> but in the war case it must encompass everything in lib[04:23:11] <Nihility> stuartdouglas: let me go through the issues on beta2[04:23:14] <Nihility> we have ike 40 issues[04:50:15] <jbossbot> git [jboss-dmr] push 1.0.0.Beta4 URL: http://github.com/jbossas/jboss-dmr/compare/2d13d61...0000000[04:52:26] <jbossbot> git [jboss-dmr] push master 09d2ea0.. Jason T. Greene Next is 1.0.0.Beta5[04:52:26] <jbossbot> git [jboss-dmr] push master URL: http://github.com/jbossas/jboss-dmr/compare/43c6696...09d2ea0[04:54:37] *** pferraro has joined #jboss-as7[04:54:37] *** ChanServ sets mode: +v pferraro[04:56:27] *** pgier has quit IRC[05:03:22] *** miclorb has quit IRC[05:05:42] <Nihility> stuartdouglas: so is your patch you wanted reviewed[05:05:52] <Nihility> is that for JBAS-8936[05:05:53] <Nihility> ?[05:05:54] <jbossbot> jira [JBAS-8936] @Resource injection from web.xml doesn't work [Open (Unresolved) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-8936[05:06:23] <stuartdouglas> yea, but its a big one https://github.com/stuartwdouglas/jboss-as/compare/master[05:06:54] <stuartdouglas> JBAS-8936 is more of a side effect, it fixes quite a few resource binding problems and also adds deployment descriptor based binding support[05:06:55] <jbossbot> jira [JBAS-8936] @Resource injection from web.xml doesn't work [Open (Unresolved) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-8936[05:07:29] <stuartdouglas> at the moment it supports env-entry, persistence-(unit/context)-ref, resource-(env)-ref and ejb-ref to some extent[05:07:50] <stuartdouglas> but I really need david to review it as he did not like the first approach[05:09:57] <stuartdouglas> it also fixes duplicate binding problems when two classes use the same interceptor or inherit from the same class[05:13:14] *** baileyje has joined #jboss-as7[05:13:14] *** ChanServ sets mode: +v baileyje[05:16:10] *** pferraro has quit IRC[05:20:24] <jbossbot> git [jboss-as] push master e1774ee.. bstansberry at jboss dot com [JBAS-9180] Use correct operation for adding deployments in DomainXml[05:20:25] <jbossbot> jira [JBAS-9180] DomainXml creates invalid operations for deployments [Open (Unresolved) Bug, Critical, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9180[05:20:26] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/27dd065...e1774ee[05:25:29] *** frainone has quit IRC[05:25:57] <baileyje> bstansberry: Can you take a look at https://github.com/baileyje/jboss-as/commit/c274439cce6f2c8958a74a539f5f257a076ff912[05:25:58] <jbossbot> git [jboss-as] c274439.. John E. Bailey [JBAS-9051] - Add a deployment timeout to the filesystem deployment scanner[05:25:59] <jbossbot> jira [JBAS-9051] FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments [Open (Unresolved) Bug, Critical, John Bailey] https://issues.jboss.org/browse/JBAS-9051[05:26:27] *** mbg is now known as mbg|away[05:26:42] <bstansberry> baileyje: sure[05:34:51] <baileyje> I forgot to push that earlier[05:34:54] <bstansberry> baileyje: the xsd says the default for that attribute is "false" not "60"[05:35:10] <baileyje> whoops. I will fix.[05:36:15] <bstansberry> while you're at it, can you delete the javadoc on testDeploymentTimeout() ;-)[05:37:03] <bstansberry> ouch, i forgot about the DiscardTaskExecutor[05:37:13] <bstansberry> sorry about that; more work than I thought[05:37:28] <baileyje> hehe[05:37:39] *** miclorb has joined #jboss-as7[05:37:45] <Nihility> baileyje: woo you are back[05:38:08] <Nihility> baileyje: can you look at your 3 issues and tell me if you are going to get them in by Friday[05:38:43] <baileyje> Nihility: Well two are done. basically[05:38:58] <baileyje> the third was waiting on some stuff dmlloyd was looking into[05:39:06] <Nihility> ok great[05:44:19] *** mbg|away is now known as mbg[05:44:47] *** smarlow has quit IRC[05:49:58] <Nihility> baileyje: did you see what i was telling jamezp about reviving JNDIview[05:50:09] <baileyje> Not sure I did[05:50:25] <Nihility> i was saying that once he gets done with brians tasks[05:50:44] <Nihility> he could change JNDIView to dump ALL contexts[05:50:58] <Nihility> and follow References[05:51:03] <baileyje> bstansberry: https://github.com/baileyje/jboss-as/commit/f126e9816443d6564678e8aaade32422db04ac16#diff-13[05:51:04] <jbossbot> git [jboss-as] f126e98.. John E. Bailey [JBAS-9051] - Add a deployment timeout to the filesystem deployment scanner[05:51:05] <jbossbot> jira [JBAS-9051] FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments [Open (Unresolved) Bug, Critical, John Bailey] https://issues.jboss.org/browse/JBAS-9051[05:51:09] <Nihility> organized by serviec or something[05:51:19] <baileyje> yeah. Would be nice to have that[05:53:23] <Nihility> jira tip[05:53:32] <Nihility> you can actually set the page size in your profile[05:53:41] <Nihility> which makes search results not have 50 million pages[05:56:35] <bstansberry> baileyje: testing[06:04:46] <jbossbot> git [jboss-as] push master f126e98.. John E. Bailey [JBAS-9051] - Add a deployment timeout to the filesystem deployment scanner[06:04:47] <jbossbot> jira [JBAS-9051] FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments [Open (Unresolved) Bug, Critical, John Bailey] https://issues.jboss.org/browse/JBAS-9051[06:04:47] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e1774ee...f126e98[06:05:44] <bstansberry> baileyje. thanks![06:05:49] *** bstansberry is now known as bstans_zzz[06:05:51] <baileyje> bstansberry: Thanks[06:09:04] *** pgier has joined #jboss-as7[06:09:05] *** ChanServ sets mode: +v pgier[06:21:49] *** pgier has quit IRC[06:33:39] *** jamezp has quit IRC[06:38:10] <jbossbot> git [jboss-as] push master cbfe5c7.. bstansberry at jboss dot com [JBAS-9146] Deployment plans should roll back on each server by default[06:38:11] <jbossbot> jira [JBAS-9146] ServerDeploymentManager deployment plans should rollback by default [Open (Unresolved) Task, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9146[06:38:11] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/f126e98...cbfe5c7[06:53:23] *** maeste has joined #jboss-as7[06:53:24] *** ChanServ sets mode: +v maeste[07:32:24] *** wolfc has joined #jboss-as7[07:32:24] *** ChanServ sets mode: +v wolfc[07:45:37] *** anguenot has joined #jboss-as7[07:57:01] *** irooskov has quit IRC[07:58:20] <nickarls> when adding a new datasource, is the driver module ref the module in the datasource or the driver module="x" in the drivers under datasources?[08:05:04] <nickarls> never mind, old blog post, modules under datasource is gone[08:05:55] *** mbg has quit IRC[08:13:06] *** cs02rm0 has quit IRC[08:14:44] *** alesj has joined #jboss-as7[08:16:53] *** maeste has quit IRC[08:17:57] <nickarls> hmm, where to start looking for what caused "{"Composite operation failed. Steps that failed:" => {"Operation step-2" => "Deployment failed. Service failures: [org.jboss.msc.service.StartException in service jboss.deployment.unit.\"LTK.war\".PARSE: Failed to process phase PARSE of deployment \"LTK.war\"]"}}" in a .failed file?[08:20:56] <nickarls> ah, there was an error in the log about a missing driver version[08:24:43] *** cs02rm0 has joined #jboss-as7[08:34:57] *** rmaucher has joined #jboss-as7[08:35:51] *** aslak has joined #jboss-as7[08:35:51] *** aslak has joined #jboss-as7[08:35:51] *** ChanServ sets mode: +v aslak[08:43:21] *** slaboure has joined #jboss-as7[08:45:09] *** mgoldmann has joined #jboss-as7[08:45:09] *** ChanServ sets mode: +v mgoldmann[08:52:29] *** stalep has joined #jboss-as7[08:53:28] *** stalep has quit IRC[08:56:13] *** stalep has joined #jboss-as7[09:05:54] *** pil-dinner has joined #jboss-as7[09:17:30] *** miclorb has quit IRC[09:20:19] *** ccrouch has quit IRC[09:21:49] *** miclorb has joined #jboss-as7[09:25:15] *** miclorb has quit IRC[09:31:04] *** torben has joined #jboss-as7[09:31:04] *** ChanServ sets mode: +v torben[09:31:12] *** Jaikiran has joined #jboss-as7[09:31:12] *** ChanServ sets mode: +v Jaikiran[09:31:58] *** adietisheim has joined #jboss-as7[09:35:44] *** miclorb_ has joined #jboss-as7[09:48:49] *** ccrouch has joined #jboss-as7[09:48:55] *** ChanServ sets mode: +v ccrouch[09:57:07] *** asoldano has joined #jboss-as7[09:57:07] *** ChanServ sets mode: +v asoldano[09:59:32] *** lgao has joined #jboss-as7[10:23:06] *** tdiesler has joined #jboss-as7[10:23:06] *** ChanServ sets mode: +v tdiesler[10:27:10] *** darranl has quit IRC[10:31:37] *** opalka has joined #jboss-as7[10:31:37] *** opalka has joined #jboss-as7[10:31:38] *** ChanServ sets mode: +v opalka[10:35:33] <opalka> morning[10:38:49] <nickarls> opalka: morning. and a question follows to warm up your brain ;-)[10:39:04] <nickarls> how come I get a "service jboss.data-source.java:/LTKDatasource" missing dep[10:39:12] <nickarls> when I have defined it like[10:39:31] <nickarls> <datasource jndi-name="java:/LTKDatasource" enabled="true" use-java-context="true" ...[10:40:01] <opalka> nickarls, I have no idea :([10:41:47] *** darranl has joined #jboss-as7[10:41:48] *** darranl has joined #jboss-as7[10:41:48] *** ChanServ sets mode: +v darranl[10:43:20] <Jaikiran> nickarls: should the jndi-name be just LTKDatasource without the prefix and then let use-java-context do its job/[10:43:27] <Jaikiran> *shouldn't[10:43:35] <Jaikiran> ?[10:54:49] *** Jaikiran has quit IRC[10:55:26] *** jhalliday has joined #jboss-as7[10:55:47] *** jfclere has joined #jboss-as7[10:55:48] *** ChanServ sets mode: +v jfclere[10:58:06] *** tdiesler has quit IRC[10:58:11] <nickarls> jaikiran: that didn't help either (I copied from the H2DS sample)[11:03:49] *** tdiesler has joined #jboss-as7[11:03:50] *** miclorb_ has quit IRC[11:03:56] *** miclorb__ has joined #jboss-as7[11:03:58] *** ChanServ sets mode: +v tdiesler[11:09:44] *** anguenot has quit IRC[11:11:07] *** maeste has joined #jboss-as7[11:11:08] *** ChanServ sets mode: +v maeste[11:15:32] *** pil-dinner is now known as pilhuhn[11:15:32] *** pilhuhn has joined #jboss-as7[11:16:38] *** jcosta has joined #jboss-as7[11:16:38] *** ChanServ sets mode: +v jcosta[11:28:26] *** miclorb_ has joined #jboss-as7[11:29:00] *** miclorb__ has quit IRC[11:30:29] *** miclorb_ has quit IRC[11:34:15] *** sannegrinovero has joined #jboss-as7[11:34:16] *** sannegrinovero has joined #jboss-as7[11:34:16] *** ChanServ sets mode: +v sannegrinovero[11:46:45] *** anguenot has joined #jboss-as7[11:54:42] *** miclorb has joined #jboss-as7[11:56:46] *** AndyTaylor has joined #jboss-as7[11:56:46] *** ChanServ sets mode: +v AndyTaylor[11:58:32] *** alesj has quit IRC[12:07:33] *** aslak has quit IRC[12:08:05] *** aslak has joined #jboss-as7[12:08:05] *** ChanServ sets mode: +v aslak[12:08:21] *** aslak has quit IRC[12:09:25] *** emmanuel has quit IRC[12:09:33] <pilhuhn> JBAS-9182[12:09:35] <jbossbot> jira [JBAS-9182] Unify failure description key [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9182[12:17:24] *** alesj has joined #jboss-as7[12:18:55] *** aslak has joined #jboss-as7[12:18:55] *** aslak has joined #jboss-as7[12:18:56] *** ChanServ sets mode: +v aslak[12:23:12] *** alesj has left #jboss-as7[12:34:18] *** asoldano is now known as asoldano_lunch[12:34:50] *** maeste is now known as maeste_lunch[12:45:28] *** anguenot_ has joined #jboss-as7[12:46:58] *** anguenot has quit IRC[12:46:58] *** anguenot_ is now known as anguenot[13:07:29] <pilhuhn> Does anyone know the format for <domainController> in host.xml if the DC is not on <local/> ?[13:09:17] *** lgao has quit IRC[13:11:14] *** miclorb has quit IRC[13:16:57] *** maeste_lunch is now known as maeste[13:17:27] *** asoldano_lunch is now known as asoldano[13:23:57] *** slaboure has quit IRC[13:27:41] *** anguenot has quit IRC[13:32:40] *** JimMa has quit IRC[13:40:35] *** epbernard has joined #jboss-as7[13:40:35] *** epbernard is now known as emmanuel[13:40:35] *** ChanServ sets mode: +v emmanuel[13:46:24] *** slaboure has joined #jboss-as7[13:48:50] *** hbraun has joined #jboss-as7[13:52:48] *** jpederse has joined #jboss-as7[13:53:03] *** jpederse has quit IRC[13:53:03] *** jpederse has joined #jboss-as7[13:54:21] *** hbraun has quit IRC[13:54:22] <darranl> pilhuhn, should be <remote host="192.168.100.1" port="9999"/>[13:54:38] <pilhuhn> darranl cool, thanks[13:55:03] *** pmuir has joined #jboss-as7[13:55:03] *** ChanServ sets mode: +v pmuir[14:00:18] *** bjornna has joined #jboss-as7[14:04:42] *** bjornna has quit IRC[14:07:43] *** mmoyses has joined #jboss-as7[14:07:43] *** ChanServ sets mode: +v mmoyses[14:11:13] *** pferraro has joined #jboss-as7[14:11:13] *** ChanServ sets mode: +v pferraro[14:15:51] *** pferraro has quit IRC[14:17:23] *** jfclere has quit IRC[14:20:33] *** jwulf has quit IRC[14:21:35] *** fnasser has joined #jboss-as7[14:22:28] *** jfclere has joined #jboss-as7[14:22:28] *** ChanServ sets mode: +v jfclere[14:29:37] <pilhuhn> darranl what do I need to modify? <host name="xx" and the DC - anything else?[14:32:44] <darranl> pilhuhn, you should just place that <remote ...> element within the <domain-controller> element and remove the <local> element[14:33:10] <pilhuhn> k[14:55:32] *** pferraro has joined #jboss-as7[14:55:32] *** ChanServ sets mode: +v pferraro[15:06:40] *** smarlow has joined #jboss-as7[15:06:40] *** ChanServ sets mode: +v smarlow[15:12:00] *** smarlow has quit IRC[15:13:18] *** frainone has joined #jboss-as7[15:13:18] *** ChanServ sets mode: +v frainone[15:18:16] *** jamezp has joined #jboss-as7[15:23:50] *** smarlow has joined #jboss-as7[15:23:57] *** ChanServ sets mode: +v smarlow[15:27:47] *** pmuir has quit IRC[15:32:31] <dmlloyd> wolfc / jaikiran: is JBAS-9019 ready to merge?[15:32:32] <jbossbot> jira [JBAS-9019] Support for ejb-jar.xml [Open (Unresolved) Sub-task, Major, jaikiran pai] https://issues.jboss.org/browse/JBAS-9019[15:32:53] <wolfc> Jaikiran, any last minute additions?[15:33:29] <wolfc> ah wait he's not here[15:35:48] <wolfc> dmlloyd, merge https://github.com/jaikiran/jboss-as/commits/default-local-view as it is now. He is probably without connection, so he may have more stuff. But it is a step forward in the right direction.[15:36:22] <dmlloyd> okay, does it include the ejb-dd stuff?[15:36:27] <wolfc> yes[15:36:30] <dmlloyd> graet.[15:36:44] <jbossbot> git [jboss-as] push master b20caae.. jaikiran Refactor to allow processing of MDBs in ejb-jar.xml[15:36:44] <jbossbot> git [jboss-as] push master 24a7c04.. jaikiran Allow for implicit no-interface view on EJBs (EJB3.1 spec, section 4.9.8) and few other minor cosmetic changes[15:36:45] <jbossbot> git [jboss-as] push master b24c76d.. Carlo de Wolf Implement implicit local view EJB 3.1 FR 4.9.7 & 4.9.8...[15:36:45] <jbossbot> git [jboss-as] push master 4ae6835.. jaikiran Rename ImplicitNoInterfaceViewProcessor to ImplicitLocalViewProcessor...[15:36:45] <jbossbot> git [jboss-as] push master 799708c.. jaikiran Add default local view for EJBs[15:36:45] <jbossbot> git [jboss-as] push master 237ecc8.. jaikiran More ejb-jar.xml processing support[15:36:45] <jbossbot> git [jboss-as] push master acffadf.. jaikiran Let the DD based SLSB be processed for default local view[15:36:46] <jbossbot> git [jboss-as] push master e11cbfa.. jaikiran Fix loading of primitive method params[15:36:46] <jbossbot> git [jboss-as] push master 867c6fe.. jaikiran Add ability for merging ejb-jar.xml and annotated views of EJBs[15:36:47] <jbossbot> git [jboss-as] push master 1c44f28.. jaikiran Refactor ejb-jar.xml and annotation merging[15:36:47] <jbossbot> git [jboss-as] push master ce24888.. jaikiran Add a partial DD + annotation based EJB deployment testcase[15:36:48] <jbossbot> git [jboss-as] push master 844f8bb.. jaikiran Minor javadoc additions[15:36:48] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/cbfe5c7...844f8bb[15:37:17] <opalka> dmlloyd, please review - https://github.com/ropalka/jboss-as/tree/sar-nested-archives-support[15:37:49] <dmlloyd> SAR nested archives, eh? not sure I like the soudn of that :)[15:37:59] <opalka> dmlloyd, I'm not sure too[15:38:05] <opalka> dmlloyd, we have some legacy tests[15:38:06] *** pferraro has quit IRC[15:38:06] <dmlloyd> what is the motivation and what are the semantics?[15:38:21] <opalka> dmlloyd, and I know that TX team uses .sar archives with nested WS JSE endpoints in it[15:38:50] <opalka> dmlloyd, The tests we have simply include EJB & WAR WS endpoints[15:38:51] <wolfc> thanks[15:39:11] <opalka> dmlloyd, in bundled separate archives inside .sar[15:40:02] <dmlloyd> Nihility: what do you think[15:40:05] <opalka> dmlloyd, If we're not going to support it it's fine with me too. But in such case I'd create JBAS jira and we'll mark it as won't fix and I'll exclude the tests with reference to that JIRA[15:40:37] <dmlloyd> my concern is that right now all of our nested deployment code assumes the outer deployment is an EAR[15:41:01] <opalka> dmlloyd, yes I know. In the past there used to be some problems with SAR[15:41:17] <opalka> dmlloyd, for example JNDI doesn't work in web archives bundled in .sar in AS6[15:41:26] <opalka> dmlloyd, maybe U can see some issues here in AS7 too?[15:41:39] <opalka> s/some/similar/[15:41:58] <opalka> dmlloyd, BTW, why do we have support for .sar archives? Was it really required/necessary?[15:43:02] <opalka> wolfc, what is the state of EJB3 WS integration considering latest AS7 pull ?[15:43:53] <Nihility> i have no problem with allowing sars to be nested children, as it doesnt really mean much but as deployments that contain children i think we need to discourage that[15:44:41] <Nihility> dmlloyd: btw stuart discovered a flaw with the notion of a composite index[15:44:56] <Nihility> dmlloyd: we are going to need 2 composites unfortunately[15:45:38] <dmlloyd> what composite index[15:45:44] <dmlloyd> annotations?[15:45:47] <Nihility> yes[15:46:05] <Nihility> the problem is in some cases we want to see everything in class visibiliity[15:46:14] <Nihility> (@Resource)[15:46:28] <dmlloyd> opalka, basically we have SARs for compatibility purposes only. I'm not really that happy that we support them myself[15:46:40] <Nihility> in other cases we need to restrict the annotation set to be just the deployment (and a few additional places)[15:47:10] <Nihility> those cases are what ejb calls "component defining annotations"[15:47:36] <Nihility> so in other words @Stateful should only be looked for in an ejb-jar (and no place else)[15:47:36] <dmlloyd> Nihility: and I'm guessing this becomes a problem with deployments which import others via class-path? I.e. a class in B.jar extends a class in A.jar and the @Resource is in A.jar?[15:47:47] <Nihility> exactly[15:47:51] * dmlloyd nods[15:47:54] <dmlloyd> well, I'm okay with that[15:47:55] <Nihility> however in a war[15:47:59] <Nihility> this is the strange part[15:48:13] <Nihility> @Stateful also needs to be looked for in WEB-INF/lib[15:48:52] <Nihility> to make things even stranger[15:49:06] <Nihility> you can have stateful session beans be anywhere if you use the DD way of things[15:49:10] <opalka> Nihility, Yes, this is the 'feature' I don't understand why it popped up in EE spec - I mean EJBs defined in WAR archives[15:49:55] <Nihility> so in the ejb case we have the deployments index and the classpath composite index[15:50:15] <Nihility> but in the war case we have a composite of the deployment and everything in web-inf/lib and a classpath composite[15:51:54] <Nihility> JBAS-9187[15:51:55] <jbossbot> jira [JBAS-9187] Use the SubjectFactoryService in connector's services [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9187[15:52:22] <opalka> Nihility, dmlloyd OK, I'll create feature request JBAS JIRA - implement support for nested EJBs & WARs in .sar archives and will mark it as rejected/won't fix ?[15:53:17] <jbossbot> git [jboss-as] push master a59ddd5.. Heiko Braun Update to console 1.0.0.Beta3[15:53:17] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/844f8bb...a59ddd5[15:53:18] <dmlloyd> yeah I think that's the thing to do, opalka.[15:53:28] <dmlloyd> remember you can always use an EAR.[15:53:36] <jpederse> Nihility: for security domain backed datasources - and resource adapters too of course[15:53:37] * opalka nods[15:53:44] <dmlloyd> Nihility: did you merge stuart's stuff?[15:54:13] <dmlloyd> I'm still not super-happy about the whole thing but there's no time to argue before the release imo[15:54:14] <Nihility> dmlloyd: no its quite big and since you had concerns previously i wanted to let you have a chance to skim it[15:54:44] *** Jaikiran has joined #jboss-as7[15:54:44] *** ChanServ sets mode: +v Jaikiran[15:55:08] <dmlloyd> hey Jaikiran. I merged your default-local-view branch.[15:55:15] <Jaikiran> dmlloyd: cool![15:55:23] <dmlloyd> after discussing briefly with carlo[15:55:38] <Jaikiran> i'll push some of my dd based interceptor stuff in a while once i have tests passing[15:55:43] <Nihility> dmlloyd: so the same issues as you mentioned before are still there[15:55:45] <Jaikiran> that should add more dd support[15:55:49] <Nihility> ?[15:56:55] <dmlloyd> well sort of. Basically my general problem is that there are too many classes, some of which are partially redundant compared to other classes, and that the code is getting very hard to navigate even though what it is doing isn't complex enough to warrant that[15:57:01] <dmlloyd> it just needs cleanup[15:57:32] *** asaldhan has joined #jboss-as7[15:57:32] *** ChanServ sets mode: +v asaldhan[15:58:09] <dmlloyd> it comes down to maintenance - I'm responsible for a _huge_ amount of code so if something is not obvious in its purpose or function it can really jam me up[15:58:22] *** pferraro has joined #jboss-as7[15:58:22] *** ChanServ sets mode: +v pferraro[15:58:37] <asaldhan> Nihility: thx for closing the JIRA issue. forgot that I need to close. :)[15:59:34] *** mbg has joined #jboss-as7[15:59:35] *** ChanServ sets mode: +v mbg[15:59:59] <Nihility> It's quite the change having jiras represent reality[16:00:04] <Nihility> :)[16:00:29] <tdiesler> dmlloyd, got time for a msc Q?[16:00:38] *** maeste has quit IRC[16:00:41] <dmlloyd> sure[16:00:59] <asaldhan> Nihility: I presume once a pull is merged, wait a day to close?[16:01:16] <dmlloyd> no, resolve it[16:01:19] <dmlloyd> with the right fix-for version[16:01:23] <tdiesler> dmlloyd, I changed the internals of the framework such that every bundle is a service bundle.foo.INSTALLED[16:01:43] <tdiesler> dmlloyd, bundle.foo.INSTALLED depends on bundle.foo.DEPLOYED[16:02:30] <Nihility> dmlloyd: we can ask stuartdouglas to revise it today[16:02:31] <dmlloyd> okay[16:02:48] <tdiesler> dmlloyd, in AS I install a number of bundle through the management API I see all the DEPLOYED services getting installed, but they don't come UP for some reason[16:03:18] <dmlloyd> Nihility: nah there's probably no time - it might be better to have an IRC meeting next week with me, Jaikiran, wolfc, stuartdouglas, baileyje to discuss everything[16:03:19] *** smcgowan has joined #jboss-as7[16:03:19] *** ChanServ sets mode: +v smcgowan[16:03:20] <tdiesler> dmlloyd, it bundle.foo.INSTALLED times out before foo.DEPLOYED comes up[16:03:46] <tdiesler> dmlloyd, could this be some thread pool issue[16:03:52] <tdiesler> ?[16:04:00] <dmlloyd> tdiesler: no, unless your start() methods block for a long time[16:04:02] <dmlloyd> which they should not[16:04:24] <dmlloyd> if you have a blocking start() operation, you should use a thread pool and async start on the MSC service to prevent the container from deadlocking[16:04:40] <tdiesler> dmlloyd, I installed a ServiceListener on the DEPLOYED services - I see the listenerAdded method being called[16:04:54] <tdiesler> but no starting, failed, etc[16:05:04] <dmlloyd> did you look in jconsole to see the status?[16:05:34] <tdiesler> dmlloyd, status of the DEPLOYED services is DOWN[16:05:47] <dmlloyd> yeah but there's a reason[16:05:57] <dmlloyd> could be a missing dependency, could be another failed service[16:05:59] <tdiesler> dmlloyd, they do not seem to progress beyond listenerAddded[16:06:13] <dmlloyd> listenerAdded is not really part of the state machine[16:06:27] <tdiesler> dmlloyd, no the dependecies are trivial and they are all UP[16:06:36] <dmlloyd> and mode is ACTIVE?[16:06:49] <dmlloyd> is the parent service UP as well?[16:07:52] <tdiesler> dmlloyd, I do serviceContainer.subTarget() to install the pair of foo.DEPLOYED and foo.INSTALLED[16:08:20] <tdiesler> dmlloyd, no initial mode involved - so it should be ACTIVE[16:08:41] <dmlloyd> ah you should always use the target given by the operation handler or by the deployment unit phase context[16:08:51] <dmlloyd> otherwise undeploy and server shutdown may not work properly[16:08:58] <dmlloyd> but that's probably a different issue[16:09:05] <tdiesler> dmlloyd, note this works fine when I bootstrap the SC myself in the standalone mode[16:09:12] <tdiesler> dmlloyd, only having trouble in AS[16:09:23] <dmlloyd> I'd have to see a service dump[16:10:22] *** AndyTaylor1 has joined #jboss-as7[16:10:44] *** AndyTaylor has quit IRC[16:11:52] *** bstans_zzz is now known as bstansberry[16:12:43] <tdiesler> dmlloyd, http://pastie.org/1735208 see how 10.INSTALLED depends on 10.DEPLOYED which is DOWN. 10.DEPLOYED however has all its dependencies UP[16:12:55] <dmlloyd> stuartdouglas: I'll need a rebase on that branch[16:13:40] *** aloubyansky has joined #jboss-as7[16:13:42] <pilhuhn> bstansberry Hi Brian[16:13:50] *** opalka has quit IRC[16:13:59] <bstansberry> hi heiko[16:14:05] <pilhuhn> bstansberry are there known restrictions atm for using multiple hosts in a domain?[16:14:33] <pilhuhn> I see the host without DC registering on the DC, but this is more or less all[16:14:38] <dmlloyd> tdiesler: the other possibility is some listener is in mid-execution and blocking. can you look at an MSC thread dump and see?[16:14:49] <pilhuhn> also see JBAS-9186[16:14:50] <jbossbot> jira [JBAS-9186] DC allows for registration of multiple hosts with same name [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9186[16:14:51] <dmlloyd> tdiesler: actually I take it back, I see the problem[16:15:02] <dmlloyd> tdiesler: you have four services starting[16:15:09] <dmlloyd> tdiesler: they're consuming all of the MSC service threads[16:16:14] *** AndyTaylor1 has quit IRC[16:16:16] <dmlloyd> tdiesler: start() cannot block. If you're going to block inside of start(), you *must* set up your own thread pool and use async start + your thread pool to carry out the blocking task[16:17:03] *** AndyTaylor has joined #jboss-as7[16:17:03] *** ChanServ sets mode: +v AndyTaylor[16:17:53] <bstansberry> pilhuhn: what are you trying to do that doesn't work?[16:18:21] <pilhuhn> e.g. list /host=<non-dc-host> on a cli connected to the DC[16:18:42] * bstansberry goes to try[16:19:12] <pilhuhn> this just hangs and for a while ( and I think throws a Timeout exception)[16:19:44] <pilhuhn> The other host is registered and shows on tab-completion of ls /host=[16:20:53] <pilhuhn> DC shows a connection timeout exception in the logs[16:21:11] <pilhuhn> And tcpdump shows connection attempts to 192.168.122.1[16:21:41] <tdiesler> dmlloyd, in AS I have a service that triggers each pair of DEPLOYED and INSTALLED services. The call blocks until the INSTALLED service is UP. I get a timeout instead. Does this explain it?[16:21:41] <pilhuhn> I've checked the config and do not see that IP in there[16:22:10] <aloubyansky> bstansberry: about host:port and --connect, how does this look like (it's a help description) https://github.com/aloubyansky/jboss-as/commit/0196189c9c1dad39ddf0a93c27dce998c79d0167[16:22:11] <jbossbot> git [jboss-as] 0196189.. Alexey Loubyansky JBAS-9185 added some help description[16:22:11] <jbossbot> jira [JBAS-9185] host and port as command line arguments for launching script [Open (Unresolved) Task, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-9185[16:22:30] <dmlloyd> tdiesler: yeah if you're talking about e.g. jboss.osgi.deployment."jboss-osgi-reflect.jar"[16:22:56] <dmlloyd> tdiesler: having services manually start and wait for other services is going to be problematic though[16:23:01] <dmlloyd> error-prone[16:24:19] <baileyje> jpederse: There?[16:25:02] <darranl> pilhuhn, actually one additional change - make sure the name at the top of the host.xml is unique[16:25:04] <bstansberry> aloubyansky: why the controller param?[16:25:21] <jpederse> baileyje: yup[16:25:24] <aloubyansky> bstansberry: what would you prefer?[16:25:39] <pilhuhn> darranl that is what I've been saying earlier and JIRA'd as 9186[16:26:13] <baileyje> jpederse: Do you know if maeste had a chance to use the RecoverymanagerService and verify it is what he needs?[16:26:22] <bstansberry> not really a preference, more a question why not just --connect xyz.com:9999[16:26:23] <aloubyansky> bstansberry: my logic was 'the controller to connect to'[16:26:25] <jpederse> baileyje: yup, we are good[16:26:30] <tdiesler> dmlloyd, I could change the integration API such that the OSGi layer returns the service name for the INSTALLED service. The AS service could setup a listener instead of blocking[16:26:31] <baileyje> great, thanks[16:26:32] <jpederse> baileyje: you can close[16:27:12] <dmlloyd> tdiesler, that's really not a lot better - the thing to do is set up dependencies. Also like I said you really should not be accessing the container directly to add services - you should use the deployer serviceTarget[16:27:22] <aloubyansky> bstansberry: i thought of something to distinguish the arguments... in case there will be more[16:27:34] <bstansberry> aloubyansky: ok[16:27:38] <bstansberry> that makes sense[16:27:48] <aloubyansky> originally, i had host=... port=...[16:27:57] *** bgeorges has joined #jboss-as7[16:28:00] <aloubyansky> but then thought host:port would be shorter[16:28:04] <dmlloyd> tdiesler, without dependencies we can not guarantee the integrity of the state machine[16:28:12] <jpederse> baileyje: thank you - bstansberry is looking at the last part for Beta2 :)[16:28:18] <aloubyansky> then i had to choose a name...[16:28:35] <bstansberry> aloubyansky: make sure we can handle IPv6 addresses[16:28:41] <baileyje> jpederse: great.[16:28:46] <baileyje> bstansberry: let me know if you need anything else looked[16:28:49] <bstansberry> i.e. with ':' as part of the IP[16:28:59] <bstansberry> ok[16:29:00] *** pgier has joined #jboss-as7[16:29:00] *** ChanServ sets mode: +v pgier[16:29:30] <tdiesler> dmlloyd, ok I need to think this over a little - merci[16:30:21] <bstansberry> pilhuhn: I can connect. to a remote host[16:30:28] <aloubyansky> bstansberry: ok, it's currently not gonna work...[16:30:40] <pilhuhn> bstansberry and you get the domain data of it?[16:30:58] <bstansberry> what i suspect is happening is the management socket on the remote host is bound to 0.0.0.0[16:31:24] <pilhuhn> yep[16:31:29] <bstansberry> when that server connects, it tells the master what IP to connect to, and 0.0.0.0 is no good, so it tries to pick one[16:31:38] <pilhuhn> eww[16:31:43] <bstansberry> sounds like that's not working[16:32:16] <bstansberry> that "pick one" thing was something I just crammed in before beta1; it needs a proper solution[16:33:06] <bstansberry> to experiment with a remote node, change it's host config so it uses a non-wildcard address for its managment socket[16:33:11] <pilhuhn> indeed - the remote has that IP as the one for its "virbri0" (kvm-clients) interface[16:33:22] <bstansberry> yeah[16:33:36] <pilhuhn> Shall I open a JIRA?[16:33:46] <bstansberry> yes, i'd appreciate it[16:33:56] <pilhuhn> ok, will do[16:35:22] *** anguenot has joined #jboss-as7[16:36:46] *** mbg is now known as mbg|away[16:37:10] *** mbg|away is now known as mbg[16:38:24] <pilhuhn> bstansberry ok that works with setting the ip explicitly[16:38:25] <jbossbot> git [jboss-as] push master 1fded40.. Stefano Maestri JBAS-9187[16:38:26] <jbossbot> jira [JBAS-9187] Use the SubjectFactoryService in connector's services [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9187[16:38:26] <jbossbot> git [jboss-as] push master e47102d.. Stefano Maestri JBAS-9107[16:38:27] <jbossbot> jira [JBAS-9107] A rar deployment must always activate or error out [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9107[16:38:27] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/a59ddd5...e47102d[16:38:28] <pilhuhn> thanks[16:38:54] <jpederse> bstansberry: thanks[16:39:28] <bstansberry> jpederse: you're welcome[16:40:03] *** ALR has joined #jboss-as7[16:40:03] *** ChanServ sets mode: +v ALR[16:41:37] <pilhuhn> bstansberry JBAS-9189[16:41:38] <jbossbot> jira [JBAS-9189] Interface selection for sockets bound to 0.0.0.0 is very likely to fail [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9189[16:41:56] <bstansberry> thanks![16:46:37] *** pmuir has joined #jboss-as7[16:46:37] *** pmuir has joined #jboss-as7[16:46:37] *** ChanServ sets mode: +v pmuir[16:48:08] *** asoldano has quit IRC[16:54:25] *** jhalliday has quit IRC[16:56:06] *** aloubyansky has quit IRC[16:56:39] <pilhuhn> bstansberry another question: just connecting to http://localhost:9990/domain-api on the DC (without option recursive) lists the DC host, but not the remote - is than on purpose?[16:58:53] <bstansberry> pilhuhn: you mean a :read-resource on the root just returns:[16:58:55] <bstansberry> "host" => {"local" => undefined}[16:59:05] <bstansberry> and there should be a second entry?[16:59:37] *** slaboure has quit IRC[16:59:55] <pilhuhn> sorta yes - I was just using the http enpoint on 9990 - and yes I would expect to see the remotes ("slaves") listed there as well. If option recursive is set, this remote shows up[16:59:59] <bstansberry> yeah, I see that; I'll look into it; that's not right[17:00:45] <pilhuhn> I'll write a JIRA for you[17:01:06] <bstansberry> oooh, that's tricky! (talking to myself)[17:01:06] *** jamezp has quit IRC[17:02:23] *** jamezp has joined #jboss-as7[17:02:52] <pilhuhn> JBAS-9191[17:02:54] <jbossbot> jira [JBAS-9191] :read-resource on / of a multi-host domain only lists the DC [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9191[17:09:48] *** jfclere has quit IRC[17:12:54] *** mgoldmann has quit IRC[17:25:45] *** jhalliday has joined #jboss-as7[17:29:22] *** frainone has quit IRC[17:34:18] <mbg> what's the name under which the TransactionManager is bound in JNDI?[17:36:14] <jhalliday> it's not[17:37:10] *** mmoyses is now known as mmoyses_[17:38:28] <mbg> jhalliday: cool. so will it ever be?[17:39:50] <jhalliday> unlikely. inject the service instead.[17:40:24] <jhalliday> or just use UserTransaciton, there is not much that you really need TM for[17:43:07] <tdiesler> dmlloyd, I assume that all DUPs in one phase get called in series for a set of deployments. Therafter all DUPs in the next phase get called with the same set of deployments, right?[17:44:08] <dmlloyd> no, they are called concurrently[17:44:27] <dmlloyd> the only guarantee is that each phase is called after its predecessor for the same deployment only[17:44:37] <dmlloyd> deployments are not run in lock-step[17:48:36] <tdiesler> dmlloyd, so a DUP in PHASE+1 for deployment X may get called before the DUPs in PHASE+0 from deployment Y has finished?[17:49:45] <dmlloyd> yes[17:49:58] <dmlloyd> the key is to use dependencies for *everything*[17:51:27] <tdiesler> dmlloyd, this relates to JBAS-8517[17:51:29] <jbossbot> jira [JBAS-8517] Add support for two phase bundle deployments [Open (Unresolved) Feature Request, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-8517[17:51:37] *** anguenot has quit IRC[17:52:06] <tdiesler> dmlloyd, how do I detect that all bundles in one set of deployments got installed before I attempt to staret them?[17:52:58] <dmlloyd> well you'd have to use dependencies if that's the behavior you need[17:53:13] <Nihility> jhalliday: are you mmusgrove on github?[17:53:20] *** jclingan has joined #jboss-as7[17:53:24] <dmlloyd> the hard part would be knowing what bundles are in a "set of deployments", which is a concept which does not really exist[17:54:02] <mbg> jhalliday: actually, I am trying to use Hibernate currentSession management with JTA which relies on getting access to a TM. but, i guess that's more of a question for emmanuel[17:54:05] <jhalliday> Nihility: umm, no, that would be Michael Musgrove.[17:54:53] <jhalliday> mbg: yeah, the hibernate service should be using the transaction service not JNDI[17:55:44] <tdiesler> dmlloyd, I added this to the jira[17:57:58] <Nihility> jhalliday: ok i had no idea who that was (don't know michael), and there is a pull request with TX stuff[17:58:23] <jhalliday> he's one of my tx team minions.[17:58:24] <Nihility> github doesnt seem to display a name for some reason[17:58:43] *** jcosta has quit IRC[18:01:05] *** jamezp has quit IRC[18:01:56] *** jamezp has joined #jboss-as7[18:02:34] *** jfd has joined #jboss-as7[18:02:34] *** jfd has quit IRC[18:02:34] *** jfd has joined #jboss-as7[18:02:34] *** ChanServ sets mode: +v jfd[18:03:22] <jbossbot> git [jboss-as] push master 1a7df8b.. bstansberry at jboss dot com Disentangle ModelController class hierarchy a bit[18:03:22] <jbossbot> git [jboss-as] push master 754165d.. bstansberry at jboss dot com Avoid NPE when there is no transaction[18:03:22] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e47102d...754165d[18:04:33] <smarlow> mbg: if your doing container managed JPA stuff with Hibernate, we set "hibernate.transaction.manager_lookup_class" to org.jboss.as.jpa.hibernate.HibernateTransactionManagerLookup[18:05:04] <smarlow> ^ avoids the JNDI lookup of TM[18:05:23] *** jclingan has quit IRC[18:05:58] <dmlloyd> tdiesler, if a new bundle is deployed, should all existing bundles roll back their state so that they can all be started in lock-step?[18:06:29] <dmlloyd> tdiesler: alternatively is there a way to establish specific dependencies between bundles so you don't have to do a flat two-phase startup of all of them?[18:08:02] <emmanuel> dmlloyd: yo, can you make jbossbot convert OGM-XX into http://opensource.atlassian.com/projects/hibernate/browse/OGM-XX[18:08:19] <dmlloyd> sure... probably...[18:08:32] <mbg> smarlow: cool. thanks. I was looking into that stuff indeed.[18:08:48] *** jbossbot has quit IRC[18:08:48] <tdiesler> dmlloyd, it applies to a set of bundles getting installed through hot-deployment. You'd expect a hot-deployed bundle to also get started. Also at server startup all bundle deployments should get installed before they get started[18:09:17] *** jbossbot has joined #jboss-as7[18:09:17] *** ChanServ sets mode: +v jbossbot[18:09:52] <emmanuel> dmlloyd: works thanks[18:09:55] <dmlloyd> no prob[18:09:56] <tdiesler> dmlloyd, it is inherently not possible to establish dependencies between bundles. This is the job of the resolver that create a graph of wires depending on package exports/imports[18:10:16] <dmlloyd> tdiesler, can the resolver do it then?[18:10:27] <dmlloyd> create service dependencies from the wiring?[18:10:46] <pilhuhn> Is there a way to search for stuff? E.g. I want to ask the DC on which host "server-four" is registered (i.e. what is the host part of (host=>??)(server-config=>server-four) =[18:11:42] <tdiesler> dmlloyd, chicken and egg. The resolver only knows about bundles when they got installed[18:12:24] <tdiesler> dmlloyd, the question is when do I trigger the resolver. i.e. how do I know that the complete set for resolution is already there[18:13:57] <dmlloyd> can the resolver work incrementally?[18:14:20] <dmlloyd> i.e. leave some bundles with unsatisfied dependencies to wait, while fully resolvable bundles are started?[18:14:37] <tdiesler> dmlloyd, I have a workaround that relies on a listener that collects the pending bundles in listenerAdded, when a bundle installed or failed to install it is removed from the list. When there are no more bundles in the list I attempt to start the set[18:22:28] *** ALR has quit IRC[18:25:25] *** maxandersen has joined #jboss-as7[18:25:25] *** ChanServ sets mode: +v maxandersen[18:26:09] *** pilhuhn is now known as pil-dinner[18:26:23] <maxandersen> dmlloyd: bstansberry: i'm pulling my hair on trying to grok the domain API ;) ….am I missing some API reference to figure out which operations to call and how to deduce the information in it ?[18:27:59] <bstansberry> maxandersen: http://community.jboss.org/wiki/DetypedDescriptionoftheAS7ManagementModel shows you the operation that lets you find out about other operations[18:29:00] <dmlloyd> tdiesler: something that may help you - it is allowed for services to create other services. This is in fact how multi-phase deployment works - each phase creates the next on start, and it is automatically destroyed on stop[18:29:15] <dmlloyd> tdiesler: so perhaps your resolver can be the thing which creates the services, somehow.[18:29:22] <dmlloyd> or maybe the concept can be used by you some other way.[18:29:25] <bstansberry> jamezp: have you had a chance to do anything on that deployment stuff?[18:29:46] <jamezp> bstansberry: Just a small amount this morning.[18:30:17] <dmlloyd> guys, anyone know if we should be expecting the JSR-160 connector to work?[18:30:25] <jamezp> Basically just removed added the deploy to the DeploymentAddHandler and removed it from the StanaloneXml.[18:30:32] <dmlloyd> andy miller tried it and says the port isn't being bound, but not sure if that was PEBCAK[18:31:28] <bstansberry> ok. do you think you'll be able to do the parts I didn't mark as "lower priority" for Beta2?[18:31:29] <maxandersen> bstansberry: yes I've read that one….but would be good to at least have some starting point to know where deployments are handled …which part of the tree would that be in exactly ?[18:31:39] <jamezp> bstansberry: But so far, it seems fairly straight forward. I don't expect it to take all that long once I get a chance to really get working on it.[18:31:57] <jamezp> Let me double check.[18:32:31] <bstansberry> jamezp: ok, no pressure, I've just had one of my Beta2 tasks bumped to Beta3 so have some spare cycles[18:33:10] <bstansberry> so I'd like to get the non "lower priority" part of that in Beta2[18:33:54] <jamezp> I could be done with that then. It looks like it's only the updating the two classes correct?[18:34:03] <bstansberry> maxandersen wants some docs and I'd prefer to doc how it works with those tweaks you're doing :)[18:34:47] <maxandersen> bstansberry: or just some examples …preferably some that does not use the java api ;)[18:35:32] <bstansberry> jamezp: yes, just those 2 classes[18:35:51] <jamezp> Let me commit my branch then and see if it looks okay.[18:36:14] *** mmoyses_ is now known as mmoyses[18:40:25] <jamezp> bstansberry: It almost seemed too easy so maybe I missed something. https://github.com/jamezp/jboss-as/commit/a960d9d81b6cf32d8252118ca7ee288ed8161f0b[18:40:26] <jbossbot> git [jboss-as] a960d9d.. James Perkins JBAS-9147 Deploy at add time. Remove deployment at start.[18:40:27] <jbossbot> jira [JBAS-9147] Deployment-related OperationHandler improvements [Open (Unresolved) Task, Major, James Perkins] https://issues.jboss.org/browse/JBAS-9147[18:41:42] <jamezp> Oh, and sorry about the changes to the imports. Just started using IDEA and I'm still figuring some things out :-)[18:43:15] <bstansberry> jamezp: :)[18:43:45] <bstansberry> the other part is the DeploymentRemoveHandler[18:43:56] *** torben has quit IRC[18:44:11] <bstansberry> in DeploymentAdd handler, you have to be careful about invoking on the ResultHandler[18:44:51] <bstansberry> DeploymentHandlerUtil.deploy(subModel, context, resultHandler); will invoke on the result handler, so if that's called you can't do it at the bottom of the method[18:45:00] <jamezp> I can get that DeploymentRemoveHandler done then. That should be easy enough.[18:45:33] <jamezp> Ah, okay. That could explain some odd results I was going to talk to you about.[18:46:43] <bstansberry> don't worry about the imports, i.e. don't spend time trying to undo the change[18:47:47] <jamezp> Okay. IDEA kept changing them to .* imports and driving me nuts. Then it mixed them all around.[18:53:41] *** frainone has joined #jboss-as7[18:53:41] *** ChanServ sets mode: +v frainone[18:54:09] *** jfd has quit IRC[18:57:00] *** rmaucher has quit IRC[18:57:13] <jamezp> bstansberry: So maybe something more like this? https://gist.github.com/894798[18:57:57] *** rawbdor has joined #jboss-as7[18:58:18] <bstansberry> jamezp: yep[18:58:27] <dmlloyd> jamezp: IDEA-67276 - that's been annoying me too :)[18:58:28] <jbossbot> youtrack [IDEA-67276] IDEA adds * imports against my will [Submitted, 1, null] http://youtrack.jetbrains.net/rest/issue/IDEA-67276[18:58:51] <bstansberry> wow 67276 -- that's impressive[18:59:11] <jamezp> Haha[18:59:55] <jamezp> I might be able to get this all done tonight then.[19:02:56] <bstansberry> :)[19:04:09] *** mbg is now known as mbg|away[19:04:37] <pferraro> bstansberry: I've updated the pull request for the jgroups subsystem incorporating feedback since monday - can you re-review?[19:05:11] <bstansberry> pferraro: ok[19:05:29] *** jfd has joined #jboss-as7[19:05:30] *** ChanServ sets mode: +v jfd[19:05:54] <pferraro> bstansberry: the changes are summarized in my reply on the pull-request list[19:06:19] <bstansberry> grrr -- stupid vpn has dropped again[19:06:33] <dmlloyd> bstansberry, can you think of anything off the top of your head which would cause a binding which is supposed to go to "192.168.1.22" to instead be bound to "192.168.1.2" (there is no configured interface in standalone.xml nor any system interface with this IP address)[19:07:52] <bstansberry> there's the domain management thing heiko and i were discussing but somehow i doubt you're setting up a slave DC[19:08:43] <bstansberry> what do you mean "there is no configured interface in standalone.xml" ?[19:09:44] <bstansberry> you mean no <inet-address value="192.xxxx"/> ?[19:12:21] <bstansberry> pferraro: to squash commits, use git rebase -i[19:13:01] <pferraro> bstansberry: thx[19:13:12] <bstansberry> when you use it, it opens an editor with a good explanation of how to manipulate things[19:14:52] <dmlloyd> right, bstansberry[19:14:59] <dmlloyd> there's a 192.126.1.22 but no .2[19:15:19] <dmlloyd> so I'm suspecting there might be a parser error somewhere - or maybe a bad entry in his hosts file[19:15:28] <bstansberry> can you pastebin your config?[19:15:56] <dmlloyd> http://pastebin.com/BGX1eheR <- it's andy millers but yeah[19:20:11] <bstansberry> dmlloyd: thanks[19:20:33] <dmlloyd> http://pastebin.com/7AYtpUd0 <- ifconfig[19:22:54] <dmlloyd> bstansberry: okay the problem is probably related to web specifically[19:23:00] <dmlloyd> and we know they have some "issues" with binding[19:23:49] <bstansberry> is there an error in the logs?[19:24:19] <dmlloyd> okay it might be PEBCAK after all. might just be netstat truncating it.[19:24:30] <dmlloyd> yup, false alarm[19:24:43] <bstansberry> ok, in beta1 web bound to 0.0.0.0[19:24:44] <dmlloyd> thanks for checking it out though.[19:24:46] <bstansberry> which is fixed[19:25:26] <bstansberry> so that might be what led to the use of netstat[19:25:56] <dmlloyd> nah he's trying to connect to the JSR-160 connector[19:25:59] <dmlloyd> and not having much luck[19:28:51] *** jhalliday has quit IRC[19:34:15] <bstansberry> pferraro: .addDependency(ServiceName.JBOSS.append("mbean", "server"), MBeanServer.class, this.mbeanServer)[19:34:25] <bstansberry> can that be .addOptionalDependency() ?[19:34:40] <bstansberry> i.e. avoid a hard dependency on jmx[19:34:44] <pferraro> bstansberry: yes[19:35:18] <bstansberry> dmlloyd: hmm, i think the demos are using that connector[19:35:34] *** darranl has quit IRC[19:35:42] <bstansberry> kabir's jndi hack[19:36:27] <dmlloyd> I am kinda suspecting that it's a firewall issue at this point[19:37:48] <dmlloyd> ah it may be an ipv6 thing[19:38:18] <dmlloyd> it's actually binding to ::ffff:192.168.1.22[19:38:34] <dmlloyd> bstansberry: didn't we have an inet4-address matcher or something like that?[19:39:20] <bstansberry> just <any-ipv4-address/>[19:39:24] <dmlloyd> ah it must be the parsing...[19:39:35] <dmlloyd> it parses 192.168.1.22 into an ipv6 address by default[19:40:55] <pferraro> bstansberry: ok - jmx dependency is now optional[19:43:02] *** ALR has joined #jboss-as7[19:43:02] *** ChanServ sets mode: +v ALR[19:46:11] *** mbg|away is now known as mbg[19:51:33] <baileyje> I gotta drop offline for a couple hours. I will be back on this afternoon[19:58:00] *** balunasj has joined #jboss-as7[19:58:01] *** balunasj has joined #jboss-as7[19:58:01] *** ChanServ sets mode: +v balunasj[19:58:27] *** balunasj has quit IRC[19:58:46] <bstansberry> dmlloyd: what's parsing that into a ipv6 address?[19:59:18] <dmlloyd> InetAddress.getByName(), presumably[19:59:51] <bstansberry> must be a JDK difference then[20:00:31] <bstansberry> although I haven't tried :-). but the code is clear enough[20:04:32] *** Jaikiran has quit IRC[20:07:17] *** emmanuel has quit IRC[20:07:54] *** bjornna has joined #jboss-as7[20:10:00] <dmlloyd> hm yeah you're right[20:10:09] <dmlloyd> I'm not really sure why it's binding via IP6 then[20:13:16] <bstansberry> pferraro: we need to find a better way to get you the server name[20:13:53] <pferraro> bstansberry: better than ServerEnvironment?[20:14:02] <bstansberry> yeah[20:14:17] <jpederse> dmlloyd: does -Djava.net.preferIPv4Stack=true help ?[20:14:28] <bstansberry> or make the ServerEnvironment contract more robust[20:14:29] <dmlloyd> jpederse, I dunno I suggested it and didn't hear back[20:14:38] <jpederse> dmlloyd: ah[20:14:48] <bstansberry> right not it's a bit of a mishmash[20:15:09] <bstansberry> the idea was to store state that's read from Main()[20:16:10] <bstansberry> but if there's anything in that that can be overridden from standalone.xml, either we should restrict access to it or make sure that it has the correct value[20:17:10] <bstansberry> what you're doing is ok; more of an FYI that it's something that I have to tighten up and that might change[20:17:27] <bstansberry> no matter what though, there would be a service you can inject to get the value[20:18:21] *** bjornna has quit IRC[20:19:00] *** sannegrinovero has quit IRC[20:20:51] * smarlow taking a quick look at memory leaks after running the JPA demo 100 times...[20:22:51] <bstansberry> pferraro: JBAS-9193[20:22:52] <jbossbot> jira [JBAS-9193] Tighten up the ServerEnvironment and HostControllerEnvironment contracts [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9193[20:23:07] * bstansberry is amazed at the rapidly increasing JIRA #[20:23:33] <bstansberry> after 9 months of broken JIRA, seems we all had an itch to scratch[20:26:46] <pferraro> bstansberry: btw - one thing I added was a default-stack attribute - that way, in the likely event that all clustered services are using the same stack - they can toggle to a different stack with a single setting[20:28:25] *** jwulf has joined #jboss-as7[20:29:03] *** darranl has joined #jboss-as7[20:29:03] <bstansberry> yeah, that's a good idea[20:29:04] *** darranl has quit IRC[20:29:04] *** darranl has joined #jboss-as7[20:29:04] *** ChanServ sets mode: +v darranl[20:35:45] <bstansberry> pferraro: JGroupsSubsystemDescribe needs some more stuff. WebSubsystemDescribe is a good example[20:37:02] <bstansberry> basically the result needs to have all the operations a HostController would pass into a newly starting AS instance to get it to have a matching config for the subsystem[20:37:40] <bstansberry> so an add the subsystem and then recursively for each child resource[20:38:55] <bstansberry> lastly, a small thing: can the implementation logic for your DescriptionProviders go into LocalDescriptions ?[20:39:19] <pferraro> bstansberry: sure[20:39:28] <bstansberry> instead of: + public ModelNode getModelDescription(Locale locale) {[20:39:28] <bstansberry> + ResourceBundle bundle = LocalDescriptions.getResourceBundle(locale);[20:39:28] <bstansberry> + ModelNode node = new ModelNode();[20:39:28] <bstansberry> + node.get(ModelDescriptionConstants.OPERATION_NAME).set(ModelDescriptionConstants.DESCRIBE);[20:39:29] <bstansberry> + node.get(ModelDescriptionConstants.DESCRIPTION).set(bundle.getString("jgroups.describe"));[20:39:29] <bstansberry> + node.get(ModelDescriptionConstants.REQUEST_PROPERTIES).setEmptyObject();[20:39:29] <bstansberry> + node.get(ModelDescriptionConstants.REPLY_PROPERTIES, ModelDescriptionConstants.TYPE).set(ModelType.LIST);[20:39:30] <bstansberry> + node.get(ModelDescriptionConstants.REPLY_PROPERTIES, ModelDescriptionConstants.VALUE_TYPE).set(ModelType.OBJECT);[20:39:30] <bstansberry> + re[20:39:54] <bstansberry> + public ModelNode getModelDescription(Locale locale) {[20:39:54] <bstansberry> + return LocalDescriptions.getFooDescription(locale);[20:40:04] <bstansberry> the latter bit is what I mean[20:40:12] <pferraro> bstansberry: gotcha[20:40:20] <bstansberry> the idea is to not load all that code during boot[20:40:41] <bstansberry> put it all in a class that only gets loaded if someone asks for descriptions[20:44:12] <smarlow> wolfc: when @Remove is implemented, will it be called when an application is undeployed? I'm wondering if I can depend on that happening? My alternative is switching to a SFSBPCMap/SFSBCallStack per deployment (not a bad idea if I can always get access to the per deployment storage)[20:48:05] *** balunasj has joined #jboss-as7[20:48:05] *** balunasj has joined #jboss-as7[20:48:05] *** ChanServ sets mode: +v balunasj[20:48:48] * smarlow current callers into SFSBPCMap/SFSBCallStack are some services, some interceptors and TransactionScopedEntityManager which doesn't yet know what deployment it is in. Clustering might call in also.[20:50:24] <smarlow> wolfc: even if I can depend on the @Remove being called during undeployment, it would be better to use per deployment storage.[20:50:48] * smarlow is entering another jira for ^[20:59:39] <wolfc> smarlow, it'll be called on undeployment, if the SFSB is not to be retained. The only problem is a system exception. In that case the bean is to be discarded.[21:00:38] <wolfc> smarlow, clustering is a special case. The XPC needs to be clustered by itself.[21:02:50] <smarlow> for the system exception case, I need to clean up the storage if its after injection has happened or we are in the middle of an invocation.[21:03:53] <wolfc> after an invocation (or during)[21:05:02] <smarlow> I'm okay for the invocation actually, because I'm active before/after it :)[21:05:30] <wolfc> it's a bit of semantics[21:05:46] <wolfc> from an user perspective everything during the invocation[21:05:56] <wolfc> everything happens[21:09:35] <smcgowan> bstansberry: JBAS-9051 appears resolved with baileyje's commit. didn't have that when we discussed the issue this morning[21:09:37] <jbossbot> jira [JBAS-9051] FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments [Resolved (Done) Bug, Critical, John Bailey] https://issues.jboss.org/browse/JBAS-9051[21:10:14] <bstansberry> good[21:10:42] *** opalka has joined #jboss-as7[21:10:42] *** opalka has joined #jboss-as7[21:10:42] *** ChanServ sets mode: +v opalka[21:10:51] <smcgowan> you guys are quick[21:11:05] <smarlow> wolfc: for catching the system exception "destroy" case, do we need a system level lifecycle mechanism (or at least knowledge in the current lifecycle callbacks of system versus app level)?[21:11:28] <wolfc> smarlow, I'm not sure yet.[21:13:41] *** balunasj has quit IRC[21:13:57] *** adietisheim has quit IRC[21:16:45] *** darranl has quit IRC[21:17:44] <pil-dinner> [Host Controller] 21:16:32,182 WARN [org.jboss.as.host.controller] (pool-1-thread-13) existing server [%s] with state: STARTED[21:17:49] *** pil-dinner is now known as pilhuhn[21:18:07] <wolfc> smarlow, preferably I would like to stay in complete control of an instance even in case of a discard.[21:18:30] <wolfc> smarlow, but little is allowed by spec once an instance needs to be discarded.[21:23:07] <bstansberry> anyone have any clue why I'm domain mode a couple directory structures appear in the root of the dist?[21:23:22] <bstansberry> "ObjectStore" and "PutObjectStoreDirHere"[21:23:56] <dmlloyd> heh, that sounds familiar[21:23:57] <smcgowan> bstansberry: in AS 6 it relied on a system property being set[21:23:58] <dmlloyd> txn subsystem?[21:24:04] <smcgowan> it is TX[21:24:24] <dmlloyd> I think those are the placeholder names I stuck in there back when the domain management system, wasn't[21:24:32] <bstansberry> yes, i assumed tx[21:25:21] <bstansberry> dmlloyd: any idea where you stuck them :)[21:25:23] <bstansberry> ?[21:25:30] <bstansberry> i can keep poking[21:25:42] <dmlloyd> I originally put that stuff in the txn service[21:25:45] <dmlloyd> but it's all been changed[21:27:09] <dmlloyd> hmm it doesn't appear anywhere in the source tree(s)[21:27:10] <smcgowan> bstansberry: i realize it's different, but here is the issue for AS 6: JBAS-8743 which we put into the final tag at the last momemt[21:27:11] <jbossbot> jira [JBAS-8743] ObjectStore directory created in run directory [Closed (Done) Bug, Major, Ales Justin] https://issues.jboss.org/browse/JBAS-8743[21:27:24] <bstansberry> thanks[21:27:33] <bstansberry> it goes in the right spot in standalone mode[21:27:53] <dmlloyd> transactions/src/main/java/org/jboss/as/txn/ArjunaTransactionManagerService.java is the place to fix it if anywhere[21:34:11] *** irooskov has joined #jboss-as7[21:44:20] <smarlow> wolfc: I created JBAS-9194 for the memory leak. I wonder if we should wire the SFSBCreateInterceptor/SFSBDestroyInterceptor directly to the SFSBContainer?[21:44:22] <jbossbot> jira [JBAS-9194] Memory leak in SFSBCall and SFSBPCMap [Open (Unresolved) Sub-task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9194[21:45:51] <wolfc> smarlow, no, the JPA subsystem should not be a direct dependency of EJB3 and vica versa[21:45:51] *** jamezp has quit IRC[21:47:03] *** jamezp has joined #jboss-as7[22:02:20] *** bjornna has joined #jboss-as7[22:02:33] *** aslak has quit IRC[22:05:55] <baileyje> so where are we at?[22:06:57] *** opalka has quit IRC[22:10:00] *** aslak has joined #jboss-as7[22:10:01] *** aslak has joined #jboss-as7[22:10:01] *** ChanServ sets mode: +v aslak[22:10:26] *** jpederse has quit IRC[22:11:45] *** irooskov has quit IRC[22:12:34] <smarlow> wolfc: I see the choices as having a system level lifecycle callback or I could get defensive (use WeakReferences maybe via ConcurrentReferenceHashMap) and occasionally cleanup my collections in the background[22:14:00] *** jamezp1 has joined #jboss-as7[22:15:31] *** irooskov has joined #jboss-as7[22:16:00] *** irooskov has quit IRC[22:16:45] *** jamezp has quit IRC[22:16:48] *** irooskov has joined #jboss-as7[22:18:21] <pferraro> bstansberry: ok - LocalDescription refactor is complete[22:18:34] *** jamezp1 has quit IRC[22:19:21] <bstansberry> pferraro: is the describe stuff in there?[22:23:25] *** bjornna has quit IRC[22:31:09] <pferraro> bstansberry: yep[22:31:10] *** pferraro is now known as pferraro_afk[22:31:40] *** jbossbot has quit IRC[22:31:57] *** jbossbot has joined #jboss-as7[22:31:57] *** ChanServ sets mode: +v jbossbot[22:32:13] <bstansberry> ok, i'll pull it down and check it out in a minute[22:34:14] *** mmoyses has quit IRC[22:39:54] <stuartdouglas> morning all[22:40:41] *** pilhuhn has quit IRC[22:40:52] <bstansberry> hi stuart[22:41:02] <nickarls> evening[22:42:57] <nickarls> how are datasources defined in AS7? I have tried <datasource jndi-name="LTKDatasource" enabled="true" use-java-context="true" ... and java:/LTKDatasource but I still get a "service jboss.data-source.java:/LTKDatasource" missing dep[22:43:25] <baileyje> nickarls: What datasource driver does it use?[22:43:46] <nickarls> an oracle one[22:43:57] <nickarls> defined a new module from the H2 example[22:44:34] <baileyje> Ok. Do you have the driver being installed? You should see a log message as well as a service defined if you fire up jconsole[22:45:21] <nickarls> I'm on a different machine now but I recall seeing a line in the log (after the H2 one)[22:45:47] <nickarls> it complained about missing version # and I fixed it so I think it's picked up[22:45:52] <baileyje> well the datasources don't have very many deps.[22:46:14] <baileyje> So your best bet is to run jconsole dump the services and see what deps are missing for the DS[22:50:52] <nickarls> I used http://www.mastertheboss.com/jboss-application-server/308-jboss-as-7-introduction.html?showall=1 but it's probably outdated now that I compare it with the module.xml of the sample[22:51:24] <nickarls> the system module vs the javax.api[22:53:40] <dmlloyd> that's not the most accurate tutorial, for sure :)[22:54:00] <nickarls> such is life on the beta-edge[22:54:08] <nickarls> noticed the driver module conf had moved, too[22:54:34] <dmlloyd> anyone know who wrote this?[22:55:22] <nickarls> all this touching of marker files for deployment is cute but there is no native touch for windows users ;-)[22:55:32] <nickarls> ok, there is autodeployment scanning now so it helps[22:56:04] <nickarls> http://community.jboss.org/wiki/DataSourceConfigurationinAS7 looks more up to date[22:58:33] *** jamezp has joined #jboss-as7[23:08:50] *** stansilvert has joined #jboss-as7[23:11:21] *** bjornna has joined #jboss-as7[23:11:48] *** ALR has quit IRC[23:12:51] *** ALR has joined #jboss-as7[23:12:52] *** ChanServ sets mode: +v ALR[23:13:09] <mbg> smarlow: is there a way to look up the EM/EMF for a deployed PU in JNDI?[23:13:23] <bstansberry> dmlloyd, Nihility, baileyje: can anyone have a quick look at https://github.com/bstansberry/jboss-as/commit/be229bf75ab15b458ccd7c7ad22fee1e77d058b1[23:13:24] <jbossbot> git [jboss-as] be229bf.. bstansberry at jboss dot com Some path-related fixes[23:13:43] <dmlloyd> approve[23:14:16] *** jfd has quit IRC[23:14:22] <jbossbot> git [jboss-as] push master be229bf.. bstansberry at jboss dot com Some path-related fixes[23:14:22] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/754165d...be229bf[23:14:55] <bstansberry> the tx directory thing is a mystery probably somewhere in arjuna. i filed a jira[23:15:05] <bstansberry> back to clustering :)[23:15:11] *** pferraro_afk has quit IRC[23:18:50] <wolfc> bstansberry, you can try setting jboss.tmp.dir somewhere. I don't fully recall which property it takes where.[23:19:21] <wolfc> I do know it does some ugly System.getProperty.[23:20:29] <bstansberry> there's a config bean in the integration that exposes setters for this path[23:20:45] <bstansberry> and they are being invoked with the right value[23:20:57] <smarlow> mbg: you mean something like Ctx.lookup("java:comp/env/persistence/MyEntityManager")[23:21:02] <bstansberry> the config bean is a arjuna thing[23:21:28] <bstansberry> so if there needs to be more than that, they need to tell us what :)[23:21:39] <smarlow> mbg: that is probably worth a try, I'm not sure if we have java:comp/env wired up yet though[23:22:01] * smarlow I remember seeing it discussed but not sure anymore...[23:22:10] <mbg> smarlow: ok, thx. I'll try a bit more then :)[23:22:18] <stuartdouglas> it should be working for annotation based injections[23:22:43] <smarlow> mbg: ^[23:23:29] <wolfc> smarlow, purely based on spec you should not be counting on having @PostConstruct or similar lifecycle callbacks. Still I wouldn't spent too much time into this yet. We'll get to it when we do memory profiling.[23:23:31] <stuartdouglas> dmlloyd: Nihility I have rebased my resource injection patch on master[23:23:37] <mbg> stuartdouglas: you mean @PersistenceContext EMF myEMF; ?[23:23:45] <stuartdouglas> yea[23:24:09] <stuartdouglas> with the patch in my master you will also be able to do <persistence-unit-ref> etc[23:24:19] <smcgowan> stuartdouglas: i'm having problems with that: see JBCTS-1095[23:24:34] <smarlow> wolfc: I switched to using a ConcurrentReferenceHashMap for now but didn't finish.[23:24:37] <smcgowan> just talking to smarlow about it[23:25:00] <mbg> stuartdouglas: cool thanks. I'm a bit pig-headed about doing JNDI since I'm porting a couple of Spring apps to AS7[23:25:35] <smarlow> stuartdouglas, smcgowan: shelly is having a problem with a service not starting (JBCTS-1095)[23:26:00] <mbg> persistence-unit-ref is what I am looking for, I guess that I shouldn't expect jboss.entity.manager.factory.jndi.name to work, eh?[23:28:24] <stuartdouglas> smarlow: smarlow I think that should be fixed in my master[23:28:33] <stuartdouglas> JBCTS-1095 that is[23:28:35] <stuartdouglas> testing now[23:29:46] <smcgowan> stuartdouglas: hoping you were going to say that, i thought you were working on it[23:30:00] <smarlow> stuartdouglas: thanks![23:30:49] <stuartdouglas> hmm, no it is not fixed[23:31:01] <stuartdouglas> I will look into it[23:32:29] *** wolfc has quit IRC[23:33:40] <stuartdouglas> smcgowan: It looks like jboss.data-source.java:/DB1 is the underlying cause[23:33:53] <jbossbot> git [jboss-as] push master 3146d8a.. Paul Ferraro Initial revision of jgroups subsystem[23:33:53] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/be229bf...3146d8a[23:34:11] *** smarlow has quit IRC[23:34:17] <stuartdouglas> for me, although if you have it configured it may be that it will work for you[23:41:31] <Nihility> stuartdouglas: can you look into a bug for me[23:41:36] <stuartdouglas> sure[23:41:58] <Nihility> stuartdouglas: if an ear has an invalid class-path ref (non-existant jar) it blocks forever[23:43:05] <stuartdouglas> Would this be a reference to a sibiling deployment?[23:43:26] <stuartdouglas> if so, if you add the sibling deployment then deployment should continue as normal[23:43:39] <smcgowan> stuartdouglas: ah, ok, that's true, i worked around the persistence.xml to point to the jndi-name of the derby datasource[23:44:17] <smcgowan> you'll see in the attachment that the DB1 is up[23:44:40] <Nihility> stuartdouglas: it was a mistake, basically ear was getting the manifest of the war, which the war has an ejb sibling in the ear[23:44:51] <smcgowan> stuartdouglas: i have issues looking up anything in the env naming context so once your changes are committed, i can test it here[23:45:14] <Nihility> ear -> class-path: foo-ejb.jar[23:45:23] <Nihility> foo-ejb.jar is not in the deployments directory[23:45:28] <Nihility> (its inside the ear)[23:45:36] <Nihility> this of course is invalid[23:45:39] <stuartdouglas> Nihility: I will look into it[23:45:42] <Nihility> but should it really wait[23:45:48] <Nihility> erm have a blocking dep[23:45:54] <Nihility> something to think about/research[23:45:56] <Nihility> bbl to talk abou tit[23:46:08] <stuartdouglas> I am not sure, but last time we talked about it that was what we decided[23:47:40] <stuartdouglas> smcgowan: Once I fix up the datasources it deploys for me[23:47:54] <smcgowan> stuartdouglas: neat[23:50:56] *** miclorb has joined #jboss-as7[23:52:43] *** maxandersen has quit IRC[23:55:26] *** smcgowan has quit IRC[23:57:32] *** maxandersen has joined #jboss-as7[23:57:32] *** ChanServ sets mode: +v maxandersen[23:57:55] *** maxandersen has quit IRC[23:58:16] *** maxandersen has joined #jboss-as7[23:58:16] *** ChanServ sets mode: +v maxandersen