May 9, 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 | >
May 9, 2011 NOTICE: This channel is no longer actively logged.
[00:13:04] *** misty has joined #jboss-as7[00:22:04] *** jpearlin1 has quit IRC[00:38:01] *** aslak has quit IRC[01:06:24] *** miclorb_ has joined #jboss-as7[02:29:20] *** jwulf has quit IRC[02:59:17] *** misty has quit IRC[03:15:26] *** liweinan has joined #jboss-as7[03:17:17] *** jwulf has joined #jboss-as7[03:18:14] *** misty has joined #jboss-as7[03:55:24] *** rawblem has joined #jboss-as7[03:56:50] *** bobmcw has joined #jboss-as7[03:56:50] *** ChanServ sets mode: +v bobmcw[04:25:50] *** irooskov has quit IRC[04:29:47] *** irooskov has joined #jboss-as7[04:30:13] *** JimMa has joined #jboss-as7[04:30:17] *** jamezp has joined #jboss-as7[04:32:30] *** rawblem has quit IRC[04:33:24] *** rawblem has joined #jboss-as7[04:37:43] *** miclorb_ has quit IRC[05:09:23] *** jamezp is now known as jamezp_afk[05:25:21] *** misty has quit IRC[05:29:08] *** baileyje has joined #jboss-as7[05:29:08] *** ChanServ sets mode: +v baileyje[05:38:59] *** magesh has joined #jboss-as7[05:41:03] *** misty has joined #jboss-as7[05:46:16] *** jwulf has quit IRC[06:37:12] *** magesh has quit IRC[06:38:24] *** irooskov has quit IRC[06:40:53] *** magesh has joined #jboss-as7[06:45:01] *** miclorb has joined #jboss-as7[06:47:59] *** lgao has joined #jboss-as7[06:51:16] *** bgeorges has quit IRC[07:20:36] *** magesh has quit IRC[07:27:05] *** misty has quit IRC[07:47:21] *** lgao has quit IRC[07:50:44] *** lgao has joined #jboss-as7[08:05:00] *** rawbdor has quit IRC[08:05:35] *** rawblem has quit IRC[08:10:18] *** jfclere has joined #jboss-as7[08:10:18] *** ChanServ sets mode: +v jfclere[08:11:48] *** rawbdor has joined #jboss-as7[08:12:19] *** rawblem has joined #jboss-as7[08:19:35] *** Jaikiran has joined #jboss-as7[08:19:35] *** ChanServ sets mode: +v Jaikiran[08:19:58] <Jaikiran> stuartdouglas: you around/[08:19:59] <Jaikiran> ?[08:25:59] <stuartdouglas> Jaikiran: ping[08:26:04] <stuartdouglas> or really pong[08:26:10] <Jaikiran> :)[08:26:14] <stuartdouglas> I figured out that some test failure[08:26:20] <Jaikiran> during the weekend, i got the smkoe tests passing[08:26:21] <Jaikiran> oh[08:26:22] <Jaikiran> https://github.com/jaikiran/jboss-as/commits/new-ee-framework[08:26:30] <Jaikiran> looks like we were working on the same thing![08:26:40] <Jaikiran> i now am fixing the integration test failures[08:27:01] <stuartdouglas> I was investigating other interceptor problems, I thought the smoke test was a singleton problem[08:27:16] <Jaikiran> yeah, i turned out to be a interceptors issue[08:27:24] <Jaikiran> which was being used by the singleton bean[08:27:31] <Jaikiran> i fixed in the interceptors processing[08:27:42] <Jaikiran> in the component description to get it working[08:27:50] <Jaikiran> *fixed the[08:28:42] <stuartdouglas> hmm, I approached it differently to you[08:29:07] <stuartdouglas> the visited stuff was the same[08:29:17] * Jaikiran is checking your changes[08:30:00] <stuartdouglas> but I think that the managed reference interceptor needs to be modified so it does not release the reference after each invocation[08:30:09] <Jaikiran> the javadoc of the ManagedReference suggest that the get should return the same instance and *not* create a new one on each invocation[08:30:29] <Jaikiran> so i just cached that instance in the ManagedReference instead of invoking a value.getValue each time[08:30:43] <Jaikiran> it wasn't really releasing it each time[08:30:47] <stuartdouglas> but there are lots of managedReferences[08:31:06] <Jaikiran> the ManagedReferenceLifecycleInterceptor was incorrectly creating new instance each time[08:31:18] <Jaikiran> instead of reusing the one created by the ManagedReferenceCreateInterceptor[08:31:59] <stuartdouglas> do you mean the ManagedReferenceInterceptor?[08:32:27] * Jaikiran opens code[08:32:32] <stuartdouglas> because the ManagedReferenceInterceptor is releasing the ManagedReference after each invocation[08:32:41] *** galderz has joined #jboss-as7[08:32:45] *** galderz has joined #jboss-as7[08:32:45] *** ChanServ sets mode: +v galderz[08:33:07] <stuartdouglas> oops, hang on, I read that wrong[08:33:30] <stuartdouglas> it is only realeasing it if the invocation fails[08:34:08] <stuartdouglas> but even so, it is still getting a new reference from the managedReferenceFactory on each invocation[08:36:18] <Jaikiran> which is ok since that interceptor is added only for the instantiation chain and not the invocation chain[08:36:19] *** jamezp_afk has quit IRC[08:36:56] <Jaikiran> and on each instantiation it's correct to create a new managed reference IMO[08:37:13] <stuartdouglas> ah, so I totally misread that :-([08:37:54] <Jaikiran> took me a while too. too much of interceptor logic flying around :)[08:38:15] <stuartdouglas> do you see the other failures in testsuite2 now?[08:38:21] <Jaikiran> yes[08:38:26] <Jaikiran> i think i know the issue[08:38:34] <Jaikiran> i just need to check the spec to see how it has to be handle[08:38:36] <Jaikiran> handled[08:38:38] <stuartdouglas> how is EjbContext mean't to be handled in a war?[08:38:45] *** jamezp has joined #jboss-as7[08:38:50] <stuartdouglas> the spec is quite vaugue[08:39:09] <Jaikiran> we used to (re)bind java:comp/EJBContext in earlier versions[08:39:18] <Jaikiran> and then let the runtime invocation pickup the correct one[08:39:25] <Jaikiran> based on the a CurrentInvocationContext stuff[08:39:59] <Jaikiran> but in the current AS version I don't think that re-binding will be possible given that the bindings are driven by services and can lead to duplicate services[08:40:09] <Jaikiran> so just looking at the deployers to see how this can be fixed[08:40:21] <Jaikiran> shouldn't take long to fix this actually[08:40:21] <stuartdouglas> in a war that basically means binding java:module/EjbContext[08:40:41] <stuartdouglas> which is quite doable, but then it will be accessible to stuff that is not an ejb[08:42:14] <Jaikiran> hmm that shouldn't be allowed[08:43:25] <stuartdouglas> yea, but with the current setup java:comp == java:module, so if we have a java:comp/EjbContext everyone can see it (even though they won't actually be able to use it)[08:44:34] <Jaikiran> oh, i was thinking that java:comp would have a separate namespace but at runtime would redirect (based on the invocation context) to java:module. i didn't know that java:comp is literally java:module for web apps[08:45:28] <Jaikiran> i think that should be fine, since we can throw an error if someone uses that java:module/EJBContext outside of an EJB[08:47:07] <Jaikiran> btw do you know if running these integration tests (in addition to smoke tests) during each build is intentional?[08:48:03] <stuartdouglas> not sure, I think they are still a work in progress[08:49:50] <stuartdouglas> personally I want to change the way the tests are run to make them easier to debug, the smoke tests are a PITA at the moment[08:53:06] <Jaikiran> yep[08:55:30] *** magesh has joined #jboss-as7[08:58:34] *** opalka has joined #jboss-as7[08:58:34] *** ChanServ sets mode: +v opalka[08:58:59] *** maeste has joined #jboss-as7[08:58:59] *** ChanServ sets mode: +v maeste[09:00:11] <opalka> morning[09:00:34] <stuartdouglas> opalka: morning[09:08:26] *** pil-afk has joined #jboss-as7[09:09:43] *** tdiesler has joined #jboss-as7[09:09:43] *** ChanServ sets mode: +v tdiesler[09:14:03] *** jwulf has joined #jboss-as7[09:16:58] *** galderz has quit IRC[09:19:06] *** jwulf has quit IRC[09:25:18] *** adietisheim has joined #jboss-as7[09:25:18] *** ChanServ sets mode: +v adietisheim[09:40:32] *** magesh has quit IRC[09:41:44] *** miclorb has quit IRC[09:42:52] *** maxandersen has joined #jboss-as7[09:42:52] *** ChanServ sets mode: +v maxandersen[09:43:14] *** emuckenhuber has joined #jboss-as7[09:43:14] *** emuckenhuber has joined #jboss-as7[09:43:14] *** ChanServ sets mode: +v emuckenhuber[09:43:28] *** maxandersen1 has joined #jboss-as7[09:43:31] *** asoldano has joined #jboss-as7[09:43:31] *** ChanServ sets mode: +v asoldano[09:43:41] *** maxandersen has quit IRC[09:45:31] *** pil-afk is now known as pilhuhn[09:45:31] *** pilhuhn has joined #jboss-as7[09:55:16] *** emuckenhuber has quit IRC[09:56:09] *** maxandersen1 has quit IRC[10:00:13] *** wolfc has joined #jboss-as7[10:00:13] *** ChanServ sets mode: +v wolfc[10:00:58] *** aslak has joined #jboss-as7[10:00:58] *** aslak has quit IRC[10:00:58] *** aslak has joined #jboss-as7[10:00:58] *** ChanServ sets mode: +v aslak[10:06:37] *** emuckenhuber has joined #jboss-as7[10:06:37] *** ChanServ sets mode: +v emuckenhuber[10:11:45] *** maxandersen has joined #jboss-as7[10:11:45] *** ChanServ sets mode: +v maxandersen[10:21:08] *** rawbdor has quit IRC[10:24:42] *** rmaucher has joined #jboss-as7[10:28:06] *** mgoldmann has joined #jboss-as7[10:28:06] *** ChanServ sets mode: +v mgoldmann[10:32:44] *** emmanuel has joined #jboss-as7[10:32:45] *** emmanuel has joined #jboss-as7[10:32:45] *** ChanServ sets mode: +v emmanuel[10:45:24] *** vtunka has joined #jboss-as7[10:45:24] *** ChanServ sets mode: +v vtunka[10:50:34] *** galderz has joined #jboss-as7[10:50:34] *** ChanServ sets mode: +v galderz[10:57:46] *** Jaikiran is now known as Jaikiran|Lunch[11:08:36] *** hbraun has joined #jboss-as7[11:08:45] <hbraun> good morning[11:11:36] *** kkhan has joined #jboss-as7[11:11:36] *** ChanServ sets mode: +v kkhan[11:15:08] *** mgoldmann has quit IRC[11:19:40] *** aslak has quit IRC[11:19:47] <opalka> hbraun, morning Heiko[11:20:00] <hbraun> morning[11:27:18] <jbossbot> git [jboss-as] push master a7744d7.. Richard Opalka [AS7-697][AS7-689] refactoring WS management operations[11:27:21] <jbossbot> jira [AS7-697] Add operation handler to list all deployed webservice endpoints [Open (Unresolved) Task, Major, Jim Ma] https://issues.jboss.org/browse/AS7-697[11:27:22] <jbossbot> jira [AS7-689] standalone server: If I shutdown the server, the client gets a IOException->ExecutionException->EOFException("Connection closed") [Open (Unresolved) Bug, Major, Jason Greene] https://issues.jboss.org/browse/AS7-689[11:27:22] <jbossbot> git [jboss-as] push master eec9d9a.. Richard Opalka [JBWS-3289] refactoring packages[11:27:23] <jbossbot> jira [JBWS-3289] Refactor packages to be in sync. with new abstractions [Open (Unresolved) Sub-task, Major, Richard Opalka] https://issues.jboss.org/browse/JBWS-3289[11:27:23] <jbossbot> git [jboss-as] push master 8b2976c.. Heiko Braun Fix https://issues.jboss.org/browse/AS7-721: parsing of xa datasource properties[11:27:24] <jbossbot> jira [AS7-721] XA datasource properties not parsed correctly [Open (Unresolved) Bug, Major, Heiko Braun] https://issues.jboss.org/browse/AS7-721[11:27:24] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/47b7a51...8b2976c[11:27:33] <opalka> kkhan, thx[11:28:20] <kkhan> opalka: np[11:28:23] <kkhan> One thing though[11:28:30] <opalka> kkhan, listening ...[11:28:40] <kkhan> WSSubsystemProviders.Descriptions.getEndointsList() needs populating :-)[11:29:12] <opalka> kkhan, We'll fix it later[11:29:28] <kkhan> opalka: Cool, just wanted to remind you :-)[11:30:03] <opalka> kkhan, Alessio is working on Beta1 release ATM[11:30:18] <opalka> kkhan, and me & Jim will be working on EAP issues next two days[11:30:30] <kkhan> ok, np[11:30:39] *** cvasilak has joined #jboss-as7[11:31:15] *** asoldano is now known as asoldano_away[11:35:12] *** slaboure has joined #jboss-as7[11:35:46] <hbraun> kkhan: tnx[11:36:41] *** alesj has joined #jboss-as7[11:40:30] *** jwulf has joined #jboss-as7[11:55:03] *** AndyTaylor has joined #jboss-as7[11:55:03] *** ChanServ sets mode: +v AndyTaylor[11:55:44] *** magesh has joined #jboss-as7[11:56:55] *** darranl has joined #jboss-as7[11:56:55] *** ChanServ sets mode: +v darranl[12:01:18] <pilhuhn> opalka Hi[12:01:25] <opalka> pilhuhn, hi[12:01:35] <pilhuhn> that "attribute unwrapping" thingy is not yet in the latest build?[12:01:36] <pilhuhn> "namespace" => "urn:jboss:domain:webservices:1.0",[12:01:37] <pilhuhn> "attributes" => {"configuration" => {[12:01:37] <pilhuhn> "description" => "Holder attribute for the actual configuration values",[12:01:48] <opalka> pilhuhn, it's not :([12:02:07] <pilhuhn> ok. Just wanted to know if I am doing something wrong[12:02:13] <opalka> pilhuhn, np[12:03:57] *** jbossbot has quit IRC[12:04:10] *** aslak has joined #jboss-as7[12:04:10] *** aslak has quit IRC[12:04:10] *** aslak has joined #jboss-as7[12:04:10] *** ChanServ sets mode: +v aslak[12:05:09] *** dmlloyd has quit IRC[12:06:15] *** jbossbot has joined #jboss-as7[12:06:15] *** ChanServ sets mode: +v jbossbot[12:07:09] *** Guest57740 has joined #jboss-as7[12:07:33] <pilhuhn> opalka is there a sample app with webservices somewhere around, that I can use to test the metrics and so on?[12:08:06] *** galderz has quit IRC[12:08:09] <opalka> pilhuhn, well what about metrics I'm going to rewrite them[12:08:19] <pilhuhn> ok, then I wait[12:08:58] <opalka> pilhuhn, I'd suggest you ;)[12:09:56] *** jwulf_ has joined #jboss-as7[12:11:04] *** jwulf has quit IRC[12:20:31] *** Jaikiran|Lunch is now known as Jaikiran[12:22:32] <JimMa> pilhuhn, It's the command to read the endpont metrics attribute now : /subsystem=webservices:read-attribute(context=WSW2JRLR4002TestService_web,endpoint=W2JRLR4002Test,name="startTime")[12:22:51] <JimMa> pilhuhn, context is the webcontext name to deploy the webservice endpoint .[12:23:08] <pilhuhn> hm[12:23:13] <JimMa> pilhuhn, As opalka said, he could change that in his refactor.[12:24:16] <pilhuhn> I would have expected something like /subsystem=webservcies/context=WS.._web:read-attribute(name=startTime)[12:24:30] <pilhuhn> not sure about context vs. endpoint[12:25:01] <JimMa> pilhuhn, There could use one context to deploy multiple ws endpoints.[12:25:19] <pilhuhn> If a context can have multiple endpoints then probably /subsystem=webservices/context=foo/endpoint=bar:read-attribute()[12:25:29] <pilhuhn> and perhaps other attributes on the level of context[12:25:44] <JimMa> pilhuhn, I think /subsystem=webservcies/endpoint=Blan:read-attribute(name=startTime) is what you expected.[12:25:58] <pilhuhn> or this yes[12:26:14] *** asoldano_away is now known as asoldano[12:26:18] <pilhuhn> depending on if you want/need to export information on context level[12:26:26] <pilhuhn> s/export/expose/[12:26:33] <JimMa> pilhuhn, Understood.[12:27:11] <JimMa> pilhuhn, Let's wait opalka's change for that .[12:27:42] <pilhuhn> sure[12:28:04] <pilhuhn> JimMa I think we are on the right track[12:29:32] *** slaboure has quit IRC[12:29:34] *** kcbabo has joined #jboss-as7[12:29:34] *** ChanServ sets mode: +v kcbabo[12:30:52] <JimMa> pilhuhn, yeah. :-)[12:35:39] *** pmuir has joined #jboss-as7[12:35:39] *** ChanServ sets mode: +v pmuir[12:37:13] *** maxandersen is now known as max_lunch[12:44:47] *** pilhuhn is now known as pil-lunch[12:44:55] *** JimMa has quit IRC[12:55:22] <wolfc> Jaikiran, good afternoon[12:55:38] <Jaikiran> wolfc: good afternoon[12:56:26] <wolfc> Is https://github.com/jaikiran/jboss-as/commits/new-ee-framework the latest branch?[12:56:46] <Jaikiran> wolfc: yes. i have 1 local fix which will be committed after one of the test starts passing[12:56:54] <Jaikiran> other than that it's the latest and passes smoke tests[12:57:02] <wolfc> Nice, is there a tck run against it?[12:57:05] <Jaikiran> the plan is to merge it upstream pretty soon[12:57:21] <Jaikiran> not yet, once the integration tests pass tonight, we'll set it up against TCK[12:57:29] <Jaikiran> we got the smoke tests passing during the weekend[12:57:31] <stuartdouglas> I also have the weld integration coming along in my ejb branch, but it is still a work in progress[12:57:55] <wolfc> as long as the weldejb test passes ;-)[12:58:08] *** slaboure has joined #jboss-as7[12:58:31] <stuartdouglas> not a chance at the moment[12:59:28] *** tdiesler has quit IRC[13:01:27] <stuartdouglas> I should get it finished off tomorrow, it's a bit of a pain really[13:01:56] <stuartdouglas> I don't think we we be able to keep using ManagedReferenceFactories to create the instances, as weld needs a bit more control[13:02:38] <wolfc> The actual instances probably need to come from the weld's bean creator[13:02:51] <wolfc> What was that thingy called again[13:03:02] <stuartdouglas> yes, I currently have a ManagedReferenceFactory that does that[13:03:27] <stuartdouglas> but then you need to re-use the CreationalContext from that, and use it after resource injections to run intializer methods[13:03:33] <wolfc> Keep in mind that we should be able to run without Weld, but that's not the hard requirement.[13:03:53] <stuartdouglas> if there is not beans.xml weld does not activate[13:19:53] *** sgilda has joined #jboss-as7[13:21:46] <wolfc> Jaikiran, you are looking into the integration failures?[13:21:52] <Jaikiran> wolfc: yes[13:21:53] <Jaikiran> almost done[13:21:57] <Jaikiran> just one minor fix[13:27:21] *** bbrowning has joined #jboss-as7[13:27:22] *** ChanServ sets mode: +v bbrowning[13:31:54] *** maeste is now known as maeste_lunch[13:33:34] *** rawblem has quit IRC[13:37:27] *** asoldano is now known as asoldano_lunch[13:39:18] *** magesh1 has joined #jboss-as7[13:40:43] *** magesh has quit IRC[13:41:50] <wolfc> Jaikiran, until we have a finalized setup for EJB-E I also want my JBAS-9181 branch to be part of the TCK tests[13:41:53] <jbossbot> jira [JBAS-9181] Redirected to: https://issues.jboss.org/si/jira.issueviews:issue-xml/AS7-434/AS7-434.xml[13:41:53] <jbossbot> jira [AS7-434] Implement EJB 3.1 FR 22 Embeddable Usage [Open (Unresolved) Task, Critical, Carlo de Wolf] https://issues.jboss.org/browse/AS7-434[13:42:38] <Jaikiran> wolfc: isn't that available upstream?[13:43:38] <wolfc> nope[13:44:11] *** mgoldmann has joined #jboss-as7[13:44:11] *** ChanServ sets mode: +v mgoldmann[13:48:03] <Jaikiran> wolfc: is this branch the latest for JBAS-9181? https://github.com/jbossejb3/jboss-as/commits/testing[13:48:04] *** magesh1 is now known as magesh[13:48:04] <jbossbot> jira [JBAS-9181] Redirected to: https://issues.jboss.org/si/jira.issueviews:issue-xml/AS7-434/AS7-434.xml[13:48:05] <jbossbot> jira [AS7-434] Implement EJB 3.1 FR 22 Embeddable Usage [Open (Unresolved) Task, Critical, Carlo de Wolf] https://issues.jboss.org/browse/AS7-434[13:48:05] *** galderz has joined #jboss-as7[13:48:06] *** ChanServ sets mode: +v galderz[13:48:30] <wolfc> Jaikiran, that is the branch picked up by george[13:48:47] <Jaikiran> yep, i was planning to rebase it with upstream so that george triggers the tck runs[13:49:05] <wolfc> I need to rebase JBAS-9181 anyway[13:49:07] <jbossbot> jira [JBAS-9181] Redirected to: https://issues.jboss.org/si/jira.issueviews:issue-xml/AS7-434/AS7-434.xml[13:49:08] <jbossbot> jira [AS7-434] Implement EJB 3.1 FR 22 Embeddable Usage [Open (Unresolved) Task, Critical, Carlo de Wolf] https://issues.jboss.org/browse/AS7-434[13:49:23] <wolfc> http://github.com/wolfc/jboss-as/tree/JBAS-9181[13:52:14] *** magesh has left #jboss-as7[13:53:27] *** maeste_lunch is now known as maeste[13:53:36] *** hardy has joined #jboss-as7[14:00:00] *** max_lunch is now known as maxandersen[14:11:38] *** kcbabo is now known as babo_brb[14:19:33] *** sebersole has joined #jboss-as7[14:19:34] *** ChanServ sets mode: +v sebersole[14:20:55] *** sebersole has quit IRC[14:32:50] *** jwulf_ has quit IRC[14:33:19] *** liweinan has quit IRC[14:37:39] *** mmoyses has joined #jboss-as7[14:37:47] *** ChanServ sets mode: +v mmoyses[14:45:38] <hbraun> maeste: would you like to comment on https://issues.jboss.org/browse/AS7-723 ?[14:45:40] <jbossbot> jira [AS7-723] Creating XA datasource requires driver name and version [Open (Unresolved) Bug, Major, Heiko Braun] https://issues.jboss.org/browse/AS7-723[14:46:32] <maeste> hbraun: yup, it's what we have discussed friday[14:47:00] <hbraun> yes, i am trying to keep track of what needs to be done.[14:47:21] <maeste> hbraun: and I'm working on what we have discussed (point driver just by name)[14:47:29] <hbraun> you can/want to reference the related IJ issue if it exists[14:47:33] <maeste> hbraun: oki, I'll comment before the end of the day[14:47:39] <hbraun> tnx[14:47:46] <maeste> hbraun: with related issues[14:47:58] <maeste> hbraun: IJ and AS7 (to be opened)[14:49:22] *** emmanuel has quit IRC[14:52:04] *** sebersole has joined #jboss-as7[14:52:04] *** ChanServ sets mode: +v sebersole[14:53:59] *** balunasj has joined #jboss-as7[14:54:00] *** balunasj has joined #jboss-as7[14:54:00] *** ChanServ sets mode: +v balunasj[14:54:17] *** babo_brb is now known as kcbabo[14:54:23] *** balunasj is now known as balunasj_gtd[14:54:51] *** kcbabo has quit IRC[14:55:08] *** kcbabo has joined #jboss-as7[14:55:08] *** ChanServ sets mode: +v kcbabo[14:57:05] *** sebersole has quit IRC[14:57:23] *** sebersole has joined #jboss-as7[14:57:23] *** ChanServ sets mode: +v sebersole[14:57:31] *** sebersole has quit IRC[14:57:58] *** sebersole has joined #jboss-as7[14:57:58] *** ChanServ sets mode: +v sebersole[14:58:16] *** jdcasey has joined #jboss-as7[14:59:09] *** fnasser has joined #jboss-as7[15:00:28] *** smarlow has joined #jboss-as7[15:00:28] *** ChanServ sets mode: +v smarlow[15:05:06] *** asoldano_lunch is now known as asoldano[15:06:46] *** frainone has joined #jboss-as7[15:06:46] *** ChanServ sets mode: +v frainone[15:08:23] *** lgao has quit IRC[15:13:29] *** Guest57740 has quit IRC[15:13:29] *** Guest57740 has joined #jboss-as7[15:13:36] *** Guest57740 is now known as dmlloyd[15:21:19] *** pferraro has joined #jboss-as7[15:21:19] *** ChanServ sets mode: +v pferraro[15:23:39] <mmoyses> kkhan: can you please pull https://github.com/mmoyses/jboss-as/commit/cfc212d36fe6d693d9a5a1bae44d6b6eecf791b6[15:23:42] <jbossbot> git [jboss-as] cfc212d.. Marcus Moyses adding ssl socket factories[15:24:35] *** baileyje has quit IRC[15:27:28] *** baileyje has joined #jboss-as7[15:27:29] *** ChanServ sets mode: +v baileyje[15:27:30] <rmaucher> mmoyses: I still don't agree with a SSL takeover by your component[15:28:29] *** jpederse has joined #jboss-as7[15:28:50] <mmoyses> rmaucher: don't you think we need a centralized way of setting SSL instead of having each subsystem create its own solution?[15:29:49] <dmlloyd> what is the purpose of this? centralized config?[15:29:54] *** pil-lunch is now known as pilhuhn[15:30:26] <rmaucher> it would be nice in theory, but realistically, I can't use it, so I don't see what it achieves[15:30:41] *** ccrouch has joined #jboss-as7[15:30:41] *** ChanServ sets mode: +v ccrouch[15:30:42] <dmlloyd> some kind of connection between SSL and a security domain?[15:32:10] <dmlloyd> I do not agree with having security domain be a giant bucket for anything with a casual association with "security"[15:32:30] <Jaikiran> dmlloyd: almost there https://github.com/jaikiran/jboss-as/commits/new-ee-framework[15:32:43] <Jaikiran> just one failure remaining in "spec" tests which appears to be a chicken-egg kind of issue[15:32:48] <mmoyses> it's a JSSE security domain[15:32:49] <Jaikiran> w.r.t SFSBs[15:32:54] *** pferraro has quit IRC[15:33:03] <Jaikiran> i'm tracking that down now. but rest of it is working[15:33:30] <rmaucher> mmoyses: which I'm not going to use[15:33:53] <jfclere> How does that works with native (openssl)?[15:34:10] *** epbernard has joined #jboss-as7[15:34:10] *** epbernard is now known as emmanuel[15:34:10] *** ChanServ sets mode: +v emmanuel[15:34:37] <Jaikiran> stuartdouglas: fyi ^[15:35:06] <wolfc> Jaikiran, is that pushed onto github?[15:35:26] <Jaikiran> wolfc: the commits have all been pushed and that new-ee-framework branch is the lates[15:35:28] <Jaikiran> latest[15:35:33] <Jaikiran> i don't have any local changes as of now[15:35:48] <Jaikiran> https://github.com/jaikiran/jboss-as/commits/new-ee-framework[15:36:13] <dmlloyd> jfclere: I would expect there to be a configuration piece atop the implementation piece. Native should use (for the most part) the same set of parameters, just applied in a different way[15:36:35] <dmlloyd> remoting doesn't use socket factories either[15:36:58] *** tdiesler has joined #jboss-as7[15:36:58] *** ChanServ sets mode: +v tdiesler[15:38:06] <wolfc> Jaikiran, stuartdouglas: it still doesn't look right w.r.t. weld. SessionObjectReferenceImpl must not instantiate a new ComponentInstance.[15:38:33] <Jaikiran> wolfc: my branch has no weld related changes. stuart is working on that separately[15:40:23] <mmoyses> dmlloyd: how does remoting create ssl sockets?[15:40:40] <wolfc> Jaikiran: I'm seeing 18 errors and 1 failure, correct?[15:41:05] <dmlloyd> mmoyses: it uses SSLEngine, basically[15:41:11] <dmlloyd> configured via XNIO[15:41:16] <Jaikiran> wolfc: should be just one error (or failure) in testsuite2/spec tests[15:41:26] <Jaikiran> can you pastebin that?[15:43:02] <wolfc> Jaikiran: here's one : http://fpaste.org/tzyZ/[15:43:39] <Jaikiran> wolfc: is this in the old integration testsuite?[15:43:45] <Jaikiran> i haven't checked that, good point[15:43:51] * Jaikiran runs those now[15:44:14] <dmlloyd> what I'm looking for is, a set of utilities in a module to support management operations relating to configuring SSL, and managing it in the config model, along with utilities which can apply those parameters to create or acquire an SSLContext[15:45:23] <Jaikiran> wolfc: yeah, testsuite/integration has 18 errors and 1 failure. I'll take a look[15:45:24] <mmoyses> that's what a jsse security domain does[15:45:50] *** pgier has joined #jboss-as7[15:45:50] *** ChanServ sets mode: +v pgier[15:45:59] <dmlloyd> why do you call it a "security domain" then[15:46:03] <dmlloyd> kinda makes no sense[15:46:34] <dmlloyd> the other important thing is that, like the threads subsystem (soon), the configuration for the SSL sockets in question should live with the subsystem that configures them, not centralized out, imo[15:46:51] <dmlloyd> so each subsystem would utilize the common utilities to avoid having to rewrite that code[15:46:57] <dmlloyd> but the XML syntax is consistent between subsystems[15:47:06] <dmlloyd> as is the model representation[15:49:49] <mmoyses> i see. calling it a security domain is a legacy thing i guess. it was called JaasSecurityDomain in previous AS[15:50:20] <dmlloyd> Jaikiran: what is the purpose of this: https://github.com/jaikiran/jboss-as/compare/dmlloyd:ejb...jaikiran:new-ee-framework#L0R72[15:50:57] <Jaikiran> dmlloyd: https://github.com/jaikiran/jboss-as/compare/dmlloyd:ejb...jaikiran:new-ee-framework#L2R53[15:51:03] *** clebert has joined #jboss-as7[15:51:03] *** ChanServ sets mode: +v clebert[15:51:56] <Jaikiran> dmlloyd: in this specific case, multiple EJB components within a .war deployment were ending up setting up java:comp/EJBContext[15:52:18] <Jaikiran> I could think of 2 ways to avoid the duplicates (and the resulting failure)[15:52:23] *** aloubyansky has joined #jboss-as7[15:52:30] <dmlloyd> okay, that's just a temporary thing then though, because it doesn't handle unbinding correctly[15:52:43] <dmlloyd> I'm working on the proper fix so that unbinding is right[15:53:00] <Jaikiran> yeah, kind of temporary, because the similar thing is required at ComponentInstall Processing and other places[15:53:11] <Jaikiran> also, i saw that "Part 1" of this was commited by you recently[15:53:16] <Jaikiran> so i guessed it's still WIP[15:54:25] <dmlloyd> merged it[15:54:37] <Jaikiran> thanks![15:54:54] *** vtunka has quit IRC[15:55:03] <mmoyses> dmlloyd: https://github.com/mmoyses/jboss-as/commit/cfc212d36fe6d693d9a5a1bae44d6b6eecf791b6#diff-6[15:55:05] <jbossbot> git [jboss-as] cfc212d.. Marcus Moyses adding ssl socket factories[15:55:17] <mmoyses> the jsse security domain in action :)[15:55:52] <mmoyses> https://github.com/mmoyses/jboss-as/commit/cfc212d36fe6d693d9a5a1bae44d6b6eecf791b6#diff-0[15:55:53] <jbossbot> git [jboss-as] cfc212d.. Marcus Moyses adding ssl socket factories[15:56:01] <mmoyses> uses it to create SSLContexts[15:58:54] *** smcgowan has joined #jboss-as7[15:58:55] *** ChanServ sets mode: +v smcgowan[16:00:14] *** maxandersen has quit IRC[16:04:14] *** sannegrinovero has joined #jboss-as7[16:04:14] *** ChanServ sets mode: +v sannegrinovero[16:05:28] *** jamezp has quit IRC[16:06:18] *** asaldhan has joined #jboss-as7[16:06:18] *** ChanServ sets mode: +v asaldhan[16:08:44] *** vtunka has joined #jboss-as7[16:08:44] *** ChanServ sets mode: +v vtunka[16:10:50] <jpederse> dmlloyd: call ?[16:11:08] <rmaucher> yes call[16:11:36] <dmlloyd> yar.[16:11:39] <dmlloyd> okay, one sec[16:14:04] <dmlloyd> JBAS-9010[16:14:05] <jbossbot> jira [JBAS-9010] Redirected to: https://issues.jboss.org/si/jira.issueviews:issue-xml/AS7-527/AS7-527.xml[16:14:07] <jbossbot> jira [AS7-527] Provide more comprehensive error messages for missing dependencies [Resolved (Done) Task, Blocker, David Lloyd] https://issues.jboss.org/browse/AS7-527[16:15:23] <hbraun> maeste: https://issues.jboss.org/browse/AS7-724[16:15:25] <jbossbot> jira [AS7-724] XA Datasource get removed from XML when booted in domain mode [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/AS7-724[16:15:48] <hbraun> maeste: this leads to https://issues.jboss.org/browse/AS7-719 and related errors[16:15:51] <jbossbot> jira [AS7-719] En/Disable datasource returns error although state change is applied [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/AS7-719[16:15:58] <maeste> hbraun: I think it's related to AS/-719[16:16:04] <maeste> hbraun: I think it's related to AS7-719[16:16:15] <maeste> hbraun: one of my next tasks ;)[16:16:34] <hbraun> maeste: yes, but it's the other way around[16:16:48] <hbraun> AS7-724 is the one that causes the trouble[16:16:48] <maeste> hbraun: yup[16:16:50] <jbossbot> jira [AS7-724] XA Datasource get removed from XML when booted in domain mode [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/AS7-724[16:19:28] <hbraun> maeste: where do I fond RA examples again?[16:19:32] <hbraun> find[16:21:54] *** cvasilak has quit IRC[16:23:27] *** sannegrinovero has quit IRC[16:23:30] *** vtunka has quit IRC[16:26:42] <hbraun> maeste: ping[16:27:18] *** sannegrinovero has joined #jboss-as7[16:27:18] *** sannegrinovero has quit IRC[16:27:18] *** sannegrinovero has joined #jboss-as7[16:27:18] *** ChanServ sets mode: +v sannegrinovero[16:28:25] <baileyje> dmlloyd ping[16:28:34] <dmlloyd> yo[16:30:19] <baileyje> One second. May have answered my own question.[16:30:19] <hbraun> darranl: ping[16:30:31] <darranl> hi hbraun[16:31:01] <hbraun> darranl: hi. I assume the basic authentication works for the HTTP API[16:31:35] <hbraun> darranl: will it be anbled by default?[16:31:39] <hbraun> enabled[16:31:46] <darranl> hbraun, I have digest on standalone, just testing the initialisation on domain mode[16:32:31] <hbraun> ah ok[16:32:44] <hbraun> then i postpone this issue for another week[16:32:53] <hbraun> got plenty of other items to work on[16:33:46] <maeste> hbraun: pong[16:34:12] <hbraun> maeste: i am looking for an example RA that I can deploy[16:34:24] <hbraun> maeste: IIRC you mentioned one in samples?[16:34:29] <Jaikiran> kkhan: got a minute?[16:34:41] <maeste> hbraun: yup sure[16:34:46] <maeste> hbraun: 2 secs[16:34:51] <hbraun> maeste: 1[16:34:56] <hbraun> maeste: 2[16:35:00] <maeste> hbraun: lol[16:36:07] <maeste> hbraun: well you just need a rar right?[16:36:19] <maeste> hbraun: you can use the one from demos[16:36:23] <maeste> hbraun: in AS7[16:36:58] <hbraun> yes[16:37:05] <hbraun> where is it?[16:37:05] *** maxandersen has joined #jboss-as7[16:37:05] *** ChanServ sets mode: +v maxandersen[16:37:23] <hbraun> stuoid question[16:37:26] <hbraun> sorry[16:37:40] <hbraun> there are plenty[16:37:44] <hbraun> ./demos/target/classes/archives/rar-example.rar[16:37:46] *** vtunka has joined #jboss-as7[16:37:46] *** ChanServ sets mode: +v vtunka[16:37:52] <hbraun> sorry for wasting your time[16:39:23] <Jaikiran> dmlloyd: are you handling merges to upstream these days?[16:40:21] <dmlloyd> hmm, I suppose I should, there's a big pile of them...[16:45:03] <hbraun> maeste: pong[16:45:25] <hbraun> maeste: what does it take it to have it show up under resource-adapters?[16:45:47] <dmlloyd> looks like kkhan has merged pretty much everything[16:45:48] <hbraun> maeste: most of the demos just contain the ra.xml or ij.xml[16:45:48] <dmlloyd> neat[16:45:53] <maeste> hbraun: nothing for standard options[16:46:04] <hbraun> is ij.xml required?[16:46:29] <maeste> hbraun: no, if you set resource-adapters at least[16:46:47] <maeste> hbraun: and moreover ij is not required if you don't need vendor specific feature[16:46:50] <maeste> vendor=us[16:47:28] <hbraun> what do you mean with "set resource-adapter" ?[16:47:46] <maeste> hbraun: if you are looking for something you can put in resource-adapters I'm lloking for an example for you[16:48:15] <maeste> hbraun: I mean add a resource-dapater in domain.xml matching the ra deployed in the rar[16:48:26] <hbraun> oh, i see[16:48:32] <hbraun> i was talking about deployment[16:48:39] <hbraun> but directly adding it fine as well[16:48:52] <hbraun> even better[16:48:53] *** AndyTaylor has quit IRC[16:49:01] <hbraun> yes, that would be great[16:49:07] <hbraun> just needsome test data[16:50:45] *** mbg has joined #jboss-as7[16:50:45] *** ChanServ sets mode: +v mbg[16:51:06] *** mbg has quit IRC[16:51:06] *** mbg has joined #jboss-as7[16:51:06] *** verne.freenode.net sets mode: +v mbg[16:51:16] <maeste> hbraun: https://github.com/maeste/IronJacamar/blob/master/deployers/src/test/resources/ra16out-ra.xml[16:51:35] <maeste> hbraun: it is what you have to put in domain.xml[16:51:41] <maeste> hbraun: for this rar:[16:51:44] <hbraun> great tnx[16:52:20] <maeste> hbraun: https://github.com/maeste/IronJacamar/tree/master/deployers/src/test/resources/ra16out.rar[16:53:08] <hbraun> maeste: where does the later go?[16:53:35] <maeste> jpederse: you have to generate a rar from this one and deploy it[16:54:13] <maeste> jpederse: what the JCA subsystem will do is to match the connectionFactory class name and add to the deployed ra the properties specified in domain.xml[16:54:38] <hbraun> can you send the binary to me?[16:54:46] <hbraun> i don't want to checkout IJ[16:55:17] <jpederse> maeste: that was for hbraun, right ?[16:55:24] <hbraun> jpederse: yes[16:55:26] <hbraun> ;)[16:55:32] <jpederse> hbraun: :)[16:55:39] <hbraun> maeste: why does it reference the archive?[16:55:49] <maeste> jpederse: yup 2 conversation with 2 people on different channel :)[16:55:58] <maeste> hbraun: ?[16:56:22] <hbraun> maeste: the example you send me does refer to <archive>ra16out.rar</archive>[16:56:36] <maeste> hbraun: ah ok.[16:56:38] <kkhan> Jaikiran:[16:56:40] <kkhan> Hey[16:56:49] *** stansilvert has joined #jboss-as7[16:57:33] *** jamezp has joined #jboss-as7[16:57:51] *** jamezp has left #jboss-as7[16:57:59] *** jamezp has joined #jboss-as7[16:58:13] <maeste> hbraun: to lookup in our metadata repository correctly, in case of multiple deployment of the same RA[16:58:27] <baileyje> dmlloyd: https://github.com/baileyje/jboss-as/compare/4ec737f98bffaf62581d...b79f31cb08380c41b37b[16:58:38] <maeste> hbraun: in fact the matching is done on archive and connectionFactory class name[16:59:18] <dmlloyd> baileyje: requires a jboss-invocation release?[16:59:21] <jpederse> maeste: : almost correct ;)[16:59:35] <jpederse> hbraun: <archive> identifies the resource adapter to use[16:59:35] <baileyje> dmlloyd: Yeah. That is against your ejb branch[16:59:42] <dmlloyd> oh okay[16:59:43] <dmlloyd> cool[16:59:51] <jpederse> hbraun: the class name identifies the managed connection factory to configure[17:00:18] *** sannegrinovero has quit IRC[17:00:19] <dmlloyd> got it thanks[17:00:28] <baileyje> thanks.[17:00:36] <hbraun> jpederse: what do nevdors typically proovide?[17:00:47] <hbraun> jpederse: the connection factoey impl as well?[17:00:54] <jpederse> hbraun: the whole thing[17:01:02] <jpederse> hbraun: we just have to configure[17:01:12] <jpederse> hbraun: well, we implement the container of course ;)[17:01:25] <jpederse> hbraun: a .rar is just metadata and classes[17:01:36] <jpederse> hbraun: the JCA deployer creates the actual objects[17:01:40] <jpederse> hbraun: the JCA container[17:01:43] <hbraun> yes, but why the archive name if you already have the factory class?[17:01:52] <jpederse> hbraun: and then injects the JCA container into the resource adapter instance[17:02:23] <jpederse> hbraun: because there can be multiple deployments of the same resource adapter archive[17:02:34] <jpederse> hbraun: and the same class can be in multiple archives[17:02:58] <jpederse> hbraun: primarily the class name is used to identify the correct MCF[17:03:06] <hbraun> multiple deployments means different ra.xml?[17:03:11] <jpederse> hbraun: since there can be multiple MCFs in an archive[17:03:13] <hbraun> or different binary versions?[17:03:28] <jpederse> hbraun: if there is only one MCF => no class name is required[17:03:44] <jpederse> hbraun: multiple deployments means[17:04:11] <jpederse> jbossbot: <arhive>a.rar</..><... jndi-name="Something">[17:04:20] <jpederse> hbraun: : <arhive>a.rar</..><... jndi-name="SomethingElse">[17:04:41] <jpederse> hbraun: easiest example to understand is data sources[17:04:53] <jpederse> hbraun: all data sources are backed by the same resource adapter[17:05:02] <jpederse> hbraun: it is just configured in multiple ways[17:05:26] <jpederse> hbraun: so <archive> is hard coded within the deployer chain[17:05:54] *** opalka has quit IRC[17:06:12] <hbraun> jpederse: i don't understand the last bit[17:06:37] <jpederse> hbraun: so lets take the wizard[17:06:49] <jpederse> hbraun: step 1 is to select the resource adapter archive[17:07:04] <jpederse> hbraun: step 2 is to configure all MCFs and admin objects[17:07:11] <jpederse> hbraun: step 3 Finish[17:07:27] <jpederse> hbraun: then you can do it all over again using the same resource adapter archive[17:07:34] <jpederse> hbraun: but configure it differently[17:07:38] <hbraun> jpederse: which leads to the question i posted today[17:08:08] <hbraun> jpederse: how to query the available ra-archives (or JDBC drivers)[17:08:22] <hbraun> jpederse: AFAIK it's currently not possible[17:08:23] <jpederse> hbraun: maeste is working on those services[17:08:47] <hbraun> jpederse, maeste: I didn't know that[17:08:55] *** frainone is now known as frainone_lunch[17:09:04] <hbraun> jpederse, maeste: what timeframe?[17:09:30] <jpederse> hbraun: this week[17:09:34] *** frainone_lunch has quit IRC[17:09:43] <jpederse> hbraun: maeste can give a precise day[17:10:03] <hbraun> jpederse: can anyone of you respond to my mail and point me to the Jira's?[17:10:09] <hbraun> jpederse: so I can track progress[17:10:20] <maeste> jpederse, hbraun : Wed should be good[17:11:08] <maeste> hbraun: yup I was going to, I have just created one: AS7-726[17:11:09] <jbossbot> jira [AS7-726] create a driver repository service [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/AS7-726[17:11:14] <hbraun> maeste: you mean can then say: /subsystem=datasources:list-drivers[17:11:15] <hbraun> ?[17:11:38] <jpederse> hbraun: that is the idea[17:11:40] <maeste> hbraun: yup it's an operation, not a service[17:11:42] *** adietisheim has quit IRC[17:11:45] <maeste> hbraun: but yep[17:11:52] <hbraun> maeste: cool[17:12:08] <maeste> hbraun: service is of course needed to do that[17:12:29] <jpederse> maeste: the MDR service is already exposed, right ?[17:12:39] <jpederse> maeste: so hbraun can query that for RAs[17:12:40] <hbraun> jpederse, maeste: I think this will solve most of the problems I had with the configuration wizard[17:12:45] <maeste> jpederse: yup[17:12:52] <jpederse> hbraun: there you go :)[17:12:59] <baileyje> dmlloyd: So. For the Audit logging, we are going to need to capture the hash created by doing a configuration store. Does you see an issue updating the ConfigurationPersister to provide a hash as a result of the store method[17:13:48] <jpederse> hbraun: MetadataRepository::getResourceAdapters()[17:14:41] <hbraun> jpederse: I only speak dmr over http[17:14:45] <dmlloyd> baileyje, yeah the hash should be based on the semantic model value, not on the hash of the XML text[17:14:53] <dmlloyd> baileyje: in particular there may not *be* XML[17:14:56] <jpederse> hbraun: oh, yeah, right[17:15:04] <jpederse> maeste: ^[17:15:14] <hbraun> jpederse: I am not so much into Java[17:15:18] <jpederse> maeste: we to expose that call then[17:15:22] <hbraun> ;)[17:15:22] <baileyje> dmlloyd: Ok. As long as we can safely check the value on boot to determine if any changes occured to the xml[17:15:28] <baileyje> if the xml exists.[17:15:40] <dmlloyd> baileyje: yeah well that's the thing, we should be checking if the *model* changed[17:15:43] <dmlloyd> somehow[17:15:47] <maeste> jpederse: this one or the RaRepository one?[17:15:51] <baileyje> dmlloyd: I agree.[17:16:18] <baileyje> dmlloyd: The question is.... How can we do that repeatably?[17:16:23] <dmlloyd> baileyje: ideally, we'd be able to define the log as a series of: update (serialized DMR?) + hash where hash = sha1(previous hash + this update)[17:16:26] <dmlloyd> or something like that[17:16:31] <dmlloyd> but reboots kind of screw that up[17:16:40] <jpederse> maeste: what ?[17:16:52] <baileyje> Yeah. I have an audit log impl that does that.[17:17:10] <dmlloyd> the question is how do you get the first hash (i.e. on boot)[17:17:35] <baileyje> Current update + previous has, and jason thought it would be good to keep the hash of the model/xml that resulted from the update.[17:18:45] <jpederse> maeste: ah, MDR vs. RAR[17:18:45] <dmlloyd> well then in that case it makes more sense to define the log as: update + hash where hash = sha1(current model hash + this update)[17:18:54] <jpederse> maeste: RAR is only for live instances[17:19:00] <dmlloyd> though that makes it not tamperproof[17:19:08] <jpederse> maeste: I think hbraun only needs the MDR ones[17:19:19] <jpederse> maeste: for the wizard[17:19:20] <dmlloyd> the underlying issue is that the log has to record change history, whereas the model reflects current state[17:19:24] <maeste> jpederse: oki[17:19:31] <jpederse> maeste: the rest is just standard operation calls[17:20:13] <baileyje> dmlloyd: I was not entirely clear what storing the current state does other than allow you a way to check if the model has diverged due to a manual change[17:20:47] <dmlloyd> well keeping a tamper proof log of changes is fine but if someone can just swap out the XML and reboot, the log would be none the wiser[17:21:06] <baileyje> dmlloyd: Right.[17:21:06] <jpederse> maeste: hmm, wait[17:21:26] <maeste> hbraun: just to be sure. Have alook on what MDR is exposing and let me know if you need anything more as management operation https://github.com/maeste/IronJacamar/blob/master/core/src/main/java/org/jboss/jca/core/spi/mdr/MetadataRepository.java[17:21:45] <maeste> hbraun: hmm, wait :)[17:21:56] <baileyje> dmlloyd: The thought was we can't do anything about that other than mark the audit log showing a manual change occured, and begin from there[17:21:59] <jpederse> maeste: he would need the getConnector() / getIronJacamar too[17:22:16] <dmlloyd> so maybe it should be: update + A + B, where A = sha1(new current model hash) and B = sha1(previous update + A)?[17:22:17] <jpederse> maeste: in order to fill out all the field with default values[17:22:28] <jpederse> maeste: this is tricky...[17:22:37] <maeste> jpederse: yup right[17:22:37] <dmlloyd> then we have a logged change of "new model introduced via reboot" or whatever[17:22:56] <dmlloyd> dunno, it's a tricky prob[17:23:01] <baileyje> dmlloyd: Yeah. That is what we were talking about.[17:23:43] <baileyje> The log would be tamper proof, but the config isn't.[17:25:03] <Jaikiran> kkhan: sorry, was away[17:25:09] <Jaikiran> can you pull this change upstream https://github.com/jaikiran/jboss-as/commit/066bbbcdae4e459d281fe7d84c80986091d3433f[17:25:11] <jbossbot> git [jboss-as] 066bbbc.. jaikiran Enable DatasourceDefinitionDeployer[17:25:15] <jpederse> hbraun: you have deployment of .rar's for 7.0.0.Final ?[17:26:00] <hbraun> jpederse: you are asking me? you mean through the console?[17:26:07] <jpederse> hbraun: yup[17:26:27] <hbraun> jpederse: well, we support deployments already[17:26:46] <jpederse> hbraun: because we need to expose operations that would allow you to configure an instance[17:26:50] <hbraun> jpederse: don't know if it's any different then a JDBC driver or simple jar file[17:27:12] <jpederse> hbraun: yup, but deploying a resource adapter doesn't do anything unless it contains a META-INF/ironjacamar.xml file[17:27:19] <jpederse> hbraun: it is different[17:27:52] <jpederse> hbraun: I say lets focus on datasources first[17:28:01] <jpederse> hbraun: and do resource adapters later[17:28:27] <jpederse> hbraun: it is ok to just being able to deploy a .rar[17:28:40] <jpederse> hbraun: then people can add an ironjacamar.xml file[17:29:16] <hbraun> jpederse: fine[17:29:40] <jpederse> hbraun: those two datasources (that represent the XML) are huge, and we need to support all those features in the console[17:29:43] <jpederse> hbraun: perfect[17:29:46] *** balunasj_gtd has quit IRC[17:30:07] <jpederse> * data structures[17:30:08] <hbraun> jpederse: but we would need to discuss it Bruno and Dimitris[17:30:13] <kkhan> Jaikiran: looking[17:30:21] <jpederse> hbraun: sure[17:30:24] <hbraun> jpederse: but until further notice I agree[17:30:30] *** aloubyansky has quit IRC[17:32:17] *** Nihility has joined #jboss-as7[17:32:17] *** ChanServ sets mode: +v Nihility[17:33:02] *** ALR has joined #jboss-as7[17:33:02] *** ChanServ sets mode: +v ALR[17:33:26] *** pferraro has joined #jboss-as7[17:33:26] *** ChanServ sets mode: +v pferraro[17:33:53] <Jaikiran> kkhan: it's mainly for enabling the @DataSourceDefinition deployer, for some tck tests[17:37:13] <jbossbot> git [jboss-as] push master 066bbbc.. jaikiran Enable DatasourceDefinitionDeployer[17:37:13] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/8b2976c...066bbbc[17:37:16] <kkhan> Jaikiran: ^^[17:38:08] <Jaikiran> kkhan: thanks![17:41:31] *** alesj has quit IRC[17:44:07] *** Jaikiran is now known as Jaikiran|Dinner[17:45:36] <mmoyses> dmlloyd: you mentioned each subsystem will be able to create threads inside the subsystem. where can i see this?[17:45:58] <dmlloyd> you mean the thread pool definitions?[17:46:13] <mmoyses> yes[17:46:26] <dmlloyd> threads subsystem right now[17:46:30] <dmlloyd> but we're going to factor that out[17:46:54] *** pilhuhn is now known as pil-afk-bbl[17:46:57] <dmlloyd> AS7-390[17:46:58] <jbossbot> jira [AS7-390] Eliminate the threads subsystem [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/AS7-390[17:48:13] <mmoyses> i'll see if i can do something similar for ssl then[17:48:40] <mmoyses> rmaucher: would that work for you?[17:50:22] <rmaucher> I don't see the value[17:54:14] <mmoyses> so we don't have to replicate code to achieve the same thing[17:55:09] <mmoyses> and to have one common solution for when customers ask "how do i mask the password for the tomcat https connector"[17:56:39] <rmaucher> wow, like that feature no Tomcat user ever asked for ? besides, I think calling a helper method to do only that should not require having a custom socket factory[17:59:01] <mmoyses> tomcat users may no have asked it but i can assure you EAP users have[17:59:08] <hbraun> dmlloyd: got a second?[17:59:17] <dmlloyd> sure[17:59:31] <hbraun> dmlloyd: in response to your last email[17:59:47] <hbraun> "profile-defined driver"[18:00:22] <Nihility> rmaucher: mmoyses on that topic, some customers at jbw were asking about having central/common SSE/SSL configs[18:00:25] <rmaucher> ok, so the web subsystem can call a helper method to do the password replacement when configuring the socket factory[18:00:28] <hbraun> it's declared on profile level, but no guarantee it is actually deployed[18:00:38] <dmlloyd> hbraun: precisely[18:00:43] <dmlloyd> hbraun: well, wait now[18:01:09] <dmlloyd> hbraun: if a jdbc driver module is declared at the profile level and it does not exist in the module repository, then the server should spew errors on boot[18:01:19] <hbraun> dmlloyd: yes it does[18:01:20] <dmlloyd> iow, it's guaranteed as much as we can guarantee anything[18:02:21] <hbraun> dmlloyd: jdbc drives as deployments are only identified as being drives when they are deployed on a server[18:02:41] <dmlloyd> right. thus, you cannot query for them at the domain level.[18:02:52] <dmlloyd> you have to actually ask a server.[18:02:57] <hbraun> dmlloyd: yes, brain did actually explain it to me a while ago[18:03:01] <mmoyses> Nihility: i think it's a good idea to have a common way of configuring ssl. maybe just adding a <ssl> element that is parsed by a common module[18:03:15] <hbraun> dmlloyd: ok, now that's clea to me[18:03:17] <hbraun> clear[18:03:54] <hbraun> dmlloyd: a registry would either mean querying all servers or servers to notify the DC[18:04:06] <hbraun> dmlloyd: I mean a registry on the domain level[18:05:15] <hbraun> dmlloyd: but a driver that just resides within the content repository is merely a binary[18:05:33] <rmaucher> mmoyses: you're really wasting your time, I won't be able to use a JSSE obly solution, and you can't use OpenSSL elsewhere[18:05:41] <dmlloyd> well there's no guarantee that the deployment is *in* the content repository either[18:06:04] <hbraun> you mea the one you might be referencing from y profile?[18:06:27] <dmlloyd> yeah right now we allow profile-level datasources to refer to deployment-level drivers[18:06:45] <hbraun> deployment-level == server level[18:06:47] <dmlloyd> because we don't have any other distribution mechanism[18:06:49] <dmlloyd> right[18:07:24] <dmlloyd> but I mean we could possibly explore using the content repository to distribute JARs specifically identified as JDBC drivers for example, or something like that[18:07:30] <dmlloyd> not sure that's practical for 7.0[18:07:32] *** alexsmirnov has joined #jboss-as7[18:08:07] <hbraun> yes, but a useless, because overly complex DS configuration UI isn't practical either[18:08:21] <hbraun> i mean we have a solution atm[18:08:32] <hbraun> but I don't believe anybody will be using it[18:09:08] <hbraun> dmlloyd: thanks for the clarification[18:09:21] <hbraun> dmlloyd: i have to think about a possible way forward[18:13:20] <mmoyses> Nihility: dmlloyd: maybe we can't use a common ssl solution for web as remy indicates but do you think there is value for it for remoting, iiop, and others?[18:13:56] <dmlloyd> mmoyses: at a configuration level we definitely can and should have a common configuration format and representation for everything, web included[18:14:11] <dmlloyd> if we have that it really doesn't matter what we do at an implementation level[18:14:23] <dmlloyd> as long as the configuration can accommodate all implementations[18:14:34] <asaldhan> dmlloyd: yeah. we need common security blocks and subsystems refer to it indirectly.[18:14:35] <dmlloyd> i.e. that may mean avoiding implementation-specific things like "trust store"[18:14:37] <Nihility> mmoyses: i think the challenge is representing openssl stuff, not sure how we solve that[18:14:55] <dmlloyd> openssl concepts are very similar to jsse concepts[18:15:04] <rmaucher> OpenSSL does not have cert stores like JSSE, so there would be some work to be done there[18:15:07] <dmlloyd> sometimes the name and storage formats are different[18:15:11] <Nihility> openssl uses pkcs7 files[18:15:17] <dmlloyd> JSSE can too, now[18:15:20] <dmlloyd> fwiw[18:15:23] <Nihility> but not other keystore formats[18:15:43] <asaldhan> dmlloyd: we can derive a common config for both jsse and openssl[18:16:00] <asaldhan> dmlloyd: but the config should go in security blocks in the domain model.[18:16:01] <dmlloyd> it's pretty easy to change things to pkcs7 if we can push keys as byte streams to openssl[18:16:24] <dmlloyd> asaldhan, I'm not sure I agree with that[18:16:29] <rmaucher> I'm not sure I can do that[18:16:47] <dmlloyd> because if I have 5 network services spread across 5 subsystems, I should be able to see the SSL config right there with it[18:16:57] <dmlloyd> we ran into this same issue with thread pools[18:17:08] <dmlloyd> spreading out the config is really just a pain[18:17:39] <asaldhan> dmlloyd: common security blocks by reference? You should be able to also specify inline config.[18:17:54] <asaldhan> dmlloyd: if 10 subsystems define security config, the thing is just large.[18:17:57] <dmlloyd> yeah by reference, that's how we did thread pools[18:18:05] <Nihility> hmm im always two minds about that[18:18:07] <dmlloyd> well depends on what you mean by "security config"[18:18:17] <dmlloyd> we're just talking about SSL context config right now[18:18:22] <dmlloyd> not auth, or anything else[18:18:36] <dmlloyd> that would be a different discussion imo[18:18:39] <asaldhan> dmlloyd: ssl is not specific to web alone.[18:18:59] <dmlloyd> of course not, but are you really going to use the same SSL config for remoting vs iiop vs web vs whatever else?[18:19:00] <rmaucher> but SSL has specific uses[18:19:01] * asaldhan has not fully groked the breadth of this discussion. Just stating his thought.[18:19:24] <rmaucher> like, we're not going to be able to make OpenSSL look like JSSE anytime soon[18:19:30] <Nihility> i think its more things like keystore configs that stand a chance at being shared[18:19:40] <asaldhan> Nihility: yeah get it now.[18:19:50] <asaldhan> dmlloyd: rmaucher: no point in moving openssl settings out of web.[18:20:00] * asaldhan shuts up[18:20:12] <dmlloyd> from an admin perspective we want all SSL configs to look the same[18:20:25] <rmaucher> yah[18:20:26] <Nihility> ideally we have common locations for resources[18:20:27] <dmlloyd> just like we want all thread pool configs to look the same, and socket server configs, etc.[18:20:38] <Nihility> thats the real reason we had threads in one spot[18:20:42] <dmlloyd> to the extent that it is possible[18:20:52] <rmaucher> threads are simpler than SSL ;)[18:21:00] <dmlloyd> thread pools are a unique problem in that there are many types of them[18:21:02] * asaldhan has found that in eap, the admins for sec are different from developers who own individual apps.[18:21:08] <dmlloyd> and only certain types are applicable to certain situations[18:21:19] <dmlloyd> right now if you mismatch them you get behavior ranging from errors to weirdness[18:21:42] <dmlloyd> SSL is a little less crazy that way, in that you still have the same sorts of parameters[18:21:59] *** hbraun has quit IRC[18:22:31] *** hbraun has joined #jboss-as7[18:26:24] *** jfclere has quit IRC[18:27:24] <Nihility> mmoyses: asaldhan hey btw for your default auth cache, instead of using infnispan im going to just bring in the LIRS map impl it uses into AS[18:27:34] *** mbg1 has joined #jboss-as7[18:27:34] *** ChanServ sets mode: +v mbg1[18:27:57] <Nihility> mmoyses: asaldhan you get the same benefits, but wihtout the overhead[18:27:58] <asaldhan> Nihility: that feature is something that should be enabled on demand. should not be on by default[18:28:11] *** mbg has quit IRC[18:28:24] <Nihility> asaldhan: auth cache?[18:28:34] <asaldhan> Nihility: auth cache with infinispan.[18:28:51] <asaldhan> mmoyses: did u introduce infinispan by default into auth cache?[18:29:06] <asaldhan> Nihility: auth cache is usually single node and does not need infinispan.[18:29:19] <asaldhan> Nihility: just for the distributed case, we need infini[18:29:33] <Nihility> asaldhan: yeah mmoyses was using local mode infinispan for an LRU map[18:29:36] <mmoyses> yep. because of evictio[18:29:48] *** mbg1 has quit IRC[18:29:48] *** mbg1 has joined #jboss-as7[18:29:48] *** pratchett.freenode.net sets mode: +v mbg1[18:30:05] <asaldhan> Nihility: 95% of the time, we deal with single node. so if LIRS is ok, go ahead, Nihility[18:30:28] <asaldhan> mmoyses: u agree?[18:32:01] <mmoyses> i guess as long as we can flush expired entries we are fine with any implementation. i was using a local infinispan cache because all the functionalities are there[18:32:09] <Nihility> asaldhan: mmoyses the class is BoundedConcurrentHashMap thats how infinispan does it[18:32:23] <mmoyses> it adds like 150ms to the startup for me so I thought it wasn't a big deal[18:32:41] <Nihility> yeah kabir was seeing half a second[18:32:47] <Nihility> i should double check that[18:33:26] <Nihility> but yeah BCHM will be very cheap, just a map[18:33:35] <Nihility> and it has an eviction policy you use[18:33:43] <mmoyses> i'll give it a shot then[18:33:45] <asaldhan> Nihility: maybe infinispan can use BCHM[18:33:48] <dmlloyd> 1ms is not a big deal, 150m is[18:33:56] <dmlloyd> it's a question of scale really[18:34:05] <dmlloyd> when you have a 2-second startup time, 200ms = 10% of that[18:34:17] <asaldhan> dmlloyd: agreed on startup time[18:34:23] <Nihility> asaldhan: it does use BCHM, the problem is when you use infinispan, you launch all the other things it does, and it does some dynamic reflection discovery stuff[18:34:51] <asaldhan> Nihility: ahh. I hope we have a common local caching scheme in AS7 that we can all rely on[18:34:52] <mmoyses> right, but if any other subsystem uses infinispan in standalone server then that 150ms will be there anyway[18:35:04] <dmlloyd> yeah[18:35:08] <dmlloyd> that's a valid point[18:35:18] <dmlloyd> hopefully we'll succeed in crunching that time down some more[18:35:25] *** mbg1 has quit IRC[18:35:28] <Nihility> if it was 100 ms[18:35:32] <Nihility> i wouldnt be as worried[18:35:33] <asaldhan> dmlloyd: Nihility: maybe we need a caching thread and figure out who is using inifini[18:35:35] <Nihility> its 500 that i worry about[18:35:51] *** mbg has joined #jboss-as7[18:35:51] *** ChanServ sets mode: +v mbg[18:35:54] <Nihility> the only thing using it right now is clustering[18:35:58] <dmlloyd> 0 is the only amount that doesn't worry me :)[18:36:05] <jpederse> Nihility: JPA 2LC ?[18:36:08] <mmoyses> right now auth cache is responsible for eagerly starting infinispan but maybe that changes with hibernate as second level cache or whatever[18:36:11] <asaldhan> Nihility: clustering is not part of standalone by default, I presume.[18:36:14] <Nihility> well there will always be some cost since infinispan is a subsystem[18:36:40] <Nihility> jpederse: yeah if someone enables 2lc sure, but we dont have that on by default[18:36:44] <mmoyses> asaldhan: we are not bringing up jgroups on standalon, just infinispan[18:36:45] * asaldhan wonders if there is a post-server startup hooks[18:37:20] <asaldhan> mmoyses: post-startup hook = authcache uses infinispan.[18:37:47] <mmoyses> anyway, i'll change the default impl used by the auth cache. infinispan will not be the default for standalone[18:38:35] <Nihility> yeah imo BCHM is better copied anyway[18:38:49] <Nihility> because then you dont have to have infinispan / jgroups and all deps[18:38:59] <Nihility> so if someone in the future[18:39:03] <Nihility> slims the server[18:39:03] <jpederse> Nihility: link - we need it too[18:39:24] <jpederse> prepared statement cache[18:39:33] <Nihility> sure second ill get it[18:39:43] <asaldhan> Nihility: put it as a wiki article man. :)[18:39:46] <Nihility> dmlloyd: we really need to do a jboss-concurrent lib[18:39:47] <Nihility> hahaha[18:39:51] <asaldhan> Nihility: so everyone who needs it gets it.[18:40:01] *** alexsmirnov has quit IRC[18:40:15] <jpederse> Nihility: yes, that would be great - jboss-common-core is a b....[18:40:16] *** emuckenhuber has quit IRC[18:40:21] <asaldhan> Nihility: by the way, I wanted to send an email to figure out the ejb3 security thing.[18:40:33] *** alexsmirnov has joined #jboss-as7[18:40:34] <Nihility> https://github.com/n1hility/infinispan/blob/master/core/src/main/java/org/infinispan/util/concurrent/BoundedConcurrentHashMap.java[18:40:35] <asaldhan> Nihility: I am wondering if Jaikiran|Dinner is available for it[18:40:52] <Nihility> note that LIRS is much faster than LRU[18:41:03] <Nihility> but has mostly the same benefits[18:41:16] <Nihility> their impl lets you pick either though[18:42:24] <Nihility> hibernate 2Lc im less worried about because its used as a clustered cache most often[18:42:33] <Nihility> so infinispan is kind of a natural dep[18:43:27] <Nihility> although i fully admit[18:43:31] <Nihility> that local 2lc is common[18:43:49] <Nihility> granted PersitenceContext is already a cache[18:43:49] *** jamezp has quit IRC[18:45:09] *** frainone has joined #jboss-as7[18:45:09] *** ChanServ sets mode: +v frainone[18:45:47] *** jamezp has joined #jboss-as7[18:46:45] <mmoyses> Nihility: do you want me to create an AuthenticationManager impl that uses a ConcurrentMap as the cache?[18:47:02] <mmoyses> in picketbox in mean[18:47:41] <Nihility> mmoyses: i think the best short term solution, is to copy that class into your impl, longer term david and i are going to maintain a concurrency datastructure project[18:47:48] <Nihility> and that one will certainly be there[18:48:02] <Nihility> (and whoever else wants to contribute to it)[18:48:37] <Nihility> that class will give you concurrent map with eviction[18:50:24] *** bstansberry has joined #jboss-as7[18:50:24] *** ChanServ sets mode: +v bstansberry[18:50:36] <mmoyses> ok[18:50:50] <Nihility> mmoyses: ill be sure to send out an email once we do that[18:52:53] *** slaboure has quit IRC[18:54:56] *** mmoyses is now known as mmoyses_[18:57:05] <Nihility> dmlloyd: hey where is the code to your fork of httpserver[18:57:53] <dmlloyd> github[18:58:13] <dmlloyd> https://github.com/dmlloyd/httpserver[18:59:03] <Nihility> dmlloyd: ok darran has a patch, do you want to move it to jbossas, or merge it in your tree?[19:00:03] <dmlloyd> both[19:00:10] <bstansberry> darran's patch should go in soon; i wanted to do it friday but had no time in the airport[19:00:28] <bstansberry> but... bbiab[19:00:29] <darranl> Nihility, jbossas would be nice if possible - I think that would mean Kabir would be able to pull more later if I need?[19:00:38] <dmlloyd> right[19:00:48] <dmlloyd> well, I think so anyway :)[19:01:24] <bstansberry> unless someone is working it; i'll merge it in a few when i get back from getting daughter at busstop[19:01:28] *** bstansberry is now known as bstans_afk[19:03:04] *** jdcasey has quit IRC[19:04:08] *** darranl has quit IRC[19:05:27] *** emuckenhuber has joined #jboss-as7[19:05:27] *** emuckenhuber has joined #jboss-as7[19:05:27] *** ChanServ sets mode: +v emuckenhuber[19:07:38] *** emmanuel has quit IRC[19:17:42] *** galderz has quit IRC[19:18:42] <jamezp> dmlloyd: Could you take a quick look at this and let me know if I'm on the right track here? https://gist.github.com/962910[19:20:49] <dmlloyd> what are you using for the module identifier?[19:20:57] <dmlloyd> perhaps it should just be a constant[19:21:28] <jamezp> I wasn't sure :-) I was just getting ready to go through and look at the tests to see how they worked.[19:22:43] <dmlloyd> rather than use CP_SEPARATORS you should just use File.pathSeparatorChar or whatever it is[19:23:10] <jamezp> Right, that makes more sense.[19:23:49] <dmlloyd> we don't need to support optional/export for the dependencies list[19:24:00] <dmlloyd> just a comma-separated list of module IDs is fine[19:24:49] <jamezp> Okay. I think I'm getting a better idea of what all this does, but I'm still learning as I go.[19:25:02] <dmlloyd> this looks conceptually just fine[19:26:10] <jamezp> Cool. Just wanted to make sure I was at least getting it to a point. I'll update it with your suggestions and get a better working version going then.[19:26:11] <jamezp> Thanks![19:26:18] <dmlloyd> np[19:28:23] *** mgoldmann has quit IRC[19:30:17] *** galderz has joined #jboss-as7[19:30:17] *** ChanServ sets mode: +v galderz[19:31:41] *** galderz has quit IRC[19:33:48] *** hardy has quit IRC[19:37:03] *** slaboure has joined #jboss-as7[19:41:13] *** AndyTaylor has joined #jboss-as7[19:41:13] *** ChanServ sets mode: +v AndyTaylor[19:42:54] *** pferraro has quit IRC[19:43:18] *** sebersole has quit IRC[19:49:22] *** kkhan has quit IRC[19:53:47] *** asoldano has quit IRC[20:01:49] *** mmoyses_ is now known as mmoyses[20:01:57] *** Jaikiran|Dinner has quit IRC[20:02:51] *** adietisheim has joined #jboss-as7[20:03:36] *** adietisheim1 has joined #jboss-as7[20:06:55] *** adietisheim has quit IRC[20:11:42] *** AndyTaylor has quit IRC[20:22:02] *** hardy has joined #jboss-as7[20:22:09] *** bstans_afk is now known as bstansberry[20:23:39] *** pil-afk-bbl is now known as pilhuhn[20:41:52] <smarlow> ALR: I was going to move a testsuite/integration test to test2/something but wasn't sure where it should go, since it uses both EE specifications and the Hibernate API (injects into a Hibernate session from persistence context). Since its not pure spec, I assume testsuite2/API is best?[20:43:31] *** pmuir has quit IRC[20:44:09] <ALR> smarlow: Yes, testsuite2/api[20:44:25] <smarlow> ALR: cool, thanks[20:44:25] <ALR> And you can add Hibernate APIs to compile-time deps if you need[20:44:39] <ALR> (Just not other runtime stuff)[20:44:46] <ALR> I'll have a look at the pull request if ya want :)[20:46:01] <smarlow> ALR: really, thanks, I need someone to pull a AS7 change if your able to merge them now? Or maybe you mean the testsuite2 change?[20:46:17] * smarlow needs help merging https://github.com/scottmarlow/jboss-as/commit/2ce6f4b3db97405779f93bab655262fc669ac581 if anyone can do that[20:46:19] <jbossbot> git [jboss-as] 2ce6f4b.. Scott Marlow upgrade to Hibernate 3.6.4.Final to resolve JBCTS-1103, should soon upgrade to Hibernate 4.0 so no jira is needed for this upgrade.[20:48:20] * ALR pulling in New Stuff[20:49:34] <ALR> smarlow: It comes into upstream/master cleanly[20:49:46] <ALR> I meant the testsuite2 changes you have[20:50:37] <smarlow> ALR: okay, I'll start moving to testsuite2 and will have changes.[20:51:21] *** maeste has quit IRC[20:54:07] *** pferraro has joined #jboss-as7[20:54:07] *** ChanServ sets mode: +v pferraro[20:57:16] *** maxandersen is now known as max_dinner[20:58:11] *** aslak has quit IRC[20:58:39] *** jamezp has left #jboss-as7[20:59:20] *** jamezp has joined #jboss-as7[20:59:34] *** aslak has joined #jboss-as7[20:59:34] *** aslak has quit IRC[20:59:34] *** aslak has joined #jboss-as7[20:59:34] *** ChanServ sets mode: +v aslak[20:59:54] *** jamezp has left #jboss-as7[21:03:55] *** jamezp has joined #jboss-as7[21:04:27] *** jamezp is now known as jamezp_afk[21:05:16] <smcgowan> ALR: any known issue running Arquillian on Solaris? http://hudson.jboss.org/hudson/job/JBoss-AS-7.0.x-Solaris/[21:05:20] <bstansberry> dmlloyd: so we're publishing our own httpserver impl under the com.sun.httpserver group id?[21:05:35] <ALR> smcgowan: Nope. Let's see heah.[21:06:08] <smcgowan> ALR: may 5 build failed due to the arquillian integration test, today's build with a security test that just hung forever and timed out[21:06:22] <ALR> http://hudson.jboss.org/hudson/job/JBoss-AS-7.0.x-Solaris/lastCompletedBuild/testReport/org.jboss.as.test.spec.ejb3/[21:06:47] <ALR> Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [0] ms[21:07:28] <ALR> Looks like the server is just taking forever to start[21:07:30] <smcgowan> ALR: ok i see that but it should work right?[21:07:43] <ALR> It's just a simple timeout[21:07:57] <ALR> More than 10 seconds.[21:08:16] <ALR> Gotta find why the server's taking so long to get up.[21:08:20] <ALR> In that environment.[21:08:32] <jpederse> smcgowan: just move to CloudBees already...[21:08:46] <smcgowan> i know, it works for you guys, right[21:08:49] <bstansberry> ALR: that failure message is broken[21:08:58] <bstansberry> whoever wrote that should be flogged[21:09:10] * bstansberry winces from the flogging[21:09:25] <ALR> I thought I'd fixed that one specifically actually.[21:09:26] <ALR> One sec[21:10:10] <ALR> Mayhaps not[21:10:19] <ALR> I fixed it in some previous fork likely.[21:13:24] *** kcbabo has quit IRC[21:17:55] <baileyje> dmlloyd: What is the best format to get the hash from the model? From the string version? ObjectOutput? any ideas?[21:21:52] *** hbraun has quit IRC[21:24:34] <pilhuhn> shouldn't stuff that shows up in :read-resource also show up in :read-resource-description ( even if only as a dummy element ) ?[21:25:32] <bstansberry> pilhuhn: yes[21:25:56] <ALR> Testsuite failing now?[21:25:56] <bstansberry> what doesn't[21:25:58] <bstansberry> ?[21:26:01] * pilhuhn is missing e.g. MaxUsedCount for data sources[21:26:07] <ALR> Running org.jboss.as.test.spec.ejb3.SingletonBeanTestCase[21:26:07] <ALR> Running org.jboss.as.test.spec.ejb3.AsyncBeanTestCase[21:26:07] <ALR> Running org.jboss.as.test.spec.ejb3.StatefulBeanTestCase[21:26:11] <pilhuhn> and all the other metrics on the h2 datasource[21:26:31] <pilhuhn> [domain@localhost:9999 data-source=java:/H2DS] :read-resource(include-runtime=true)[21:26:34] <pilhuhn> vs[21:26:42] <pilhuhn> [domain@localhost:9999 data-source=java:/H2DS] :read-resource-description(include-runtime=true)[21:27:27] *** baileyje has quit IRC[21:27:36] <bstansberry> maeste's gone[21:27:41] * bstansberry goes to file a JIRA[21:27:54] <pilhuhn> ok , thanks[21:28:28] * pilhuhn really wishes there were one complete subsystem that has everything from adding/removing children, editing attributes, working metrics.[21:28:45] <pilhuhn> Would be good as a blue print for other devs too[21:32:23] *** mgoldmann has joined #jboss-as7[21:32:23] *** ChanServ sets mode: +v mgoldmann[21:37:53] <ALR> bstansberry: I've got a pull request for AS7-730, but my Hudson and local are showing testsuite failures[21:37:55] <jbossbot> jira [AS7-730] Arquillian Managed Container Startup Timeout Message is wrong [Open (Unresolved) Bug, Major, Andrew Rubinger] https://issues.jboss.org/browse/AS7-730[21:38:04] <ALR> Is that consistent w/ the current state of upstream/master?[21:38:28] *** hbraun has joined #jboss-as7[21:38:35] <bstansberry> ALR: those 3 ^^^ have been intermittently failing here and there[21:38:43] *** hbraun has quit IRC[21:38:50] <bstansberry> that's part of what wolfc was talking about today[21:42:07] *** pilhuhn has quit IRC[21:42:08] <ALR> Also web auth though[21:42:14] <ALR> http://jboss.hudson.alrubinger.com/job/AS7/10/testReport/[21:42:17] <ALR> Which I wasn't expecting[21:43:24] <smcgowan> ALR: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/001828.html[21:43:33] *** jdcasey has joined #jboss-as7[21:44:49] <ALR> smcgowan: Thx. :) I'm sooooo behind on about all forum and mail lists due to last week.[21:44:54] <ALR> Got through INBOX though :)[21:47:05] <smcgowan> ALR: and http://hudson.jboss.org/hudson/job/JBoss-AS-7.0.x-testSuite-sun16/145/testReport/[21:51:30] *** alexsmirnov has quit IRC[21:53:36] *** alexsmirnov has joined #jboss-as7[21:56:50] <ALR> smcgowan: Caused by: java.lang.IllegalStateException: No implementation found for org.jboss.arquillian.spi.client.container.DeployableContainer, please check your classpath[21:57:02] <ALR> That one I've a fix for too.[21:57:15] <ALR> Just can't get past the transient stuff in the build. :)[21:58:08] <smcgowan> were you on the call this morning when carlo was discussing that[22:02:16] *** baileyje has joined #jboss-as7[22:02:16] *** ChanServ sets mode: +v baileyje[22:06:15] *** max_dinner is now known as maxandersen[22:06:25] *** baileyje has quit IRC[22:06:29] <jpederse> ~pgier++[22:06:51] *** baileyje has joined #jboss-as7[22:06:51] *** ChanServ sets mode: +v baileyje[22:07:59] <ALR> No, I missed this one. :([22:10:00] *** jamezp_afk is now known as jamezp[22:10:58] <dmlloyd> bstansberry: so far, yeah, but we can always change that.[22:11:15] *** baileyje has quit IRC[22:11:23] <dmlloyd> baileyje: ObjectOutput, I guess... at least I can't think of a better answer than that...[22:11:28] <bstansberry> I'll change it before pushing out darran's stuff[22:11:32] <dmlloyd> byte[] superHashCode()? :-)[22:11:37] <bstansberry> i forked it into jbossas[22:12:01] *** baileyje has joined #jboss-as7[22:12:01] *** ChanServ sets mode: +v baileyje[22:13:23] <dmlloyd> baileyje: ObjectOutput, I guess... at least I can't think of a better answer than that...[22:13:24] *** baileyje has quit IRC[22:13:28] <dmlloyd> grp[22:14:05] *** baileyje has joined #jboss-as7[22:14:05] *** ChanServ sets mode: +v baileyje[22:14:41] *** maxandersen has quit IRC[22:14:46] <dmlloyd> baileyje: ObjectOutput, I guess... at least I can't think of a better answer than that...[22:14:59] <baileyje> yeah. That is what I figured.[22:15:19] *** hardy has quit IRC[22:16:48] *** maxandersen has joined #jboss-as7[22:16:48] *** ChanServ sets mode: +v maxandersen[22:28:27] *** miclorb has joined #jboss-as7[22:28:50] *** bstansberry has quit IRC[22:44:30] *** stansilvert has quit IRC[22:45:49] <wolfc> ALR, just to recap: we're seeing transient failures in different tests. The ejb3 spec ones are just more prone to fail then other tests. It looks like the test is executing before deployment is fully done (all services started, instead of just installed).[22:46:24] <ALR> The server timeout worries me too,[22:46:34] <ALR> Wonder if we should bump that value.[22:46:58] <wolfc> I have seen that as well. I can't figure out why AS sometimes takes 10 seconds to process a request.[22:49:04] <wolfc> I'm going to ponder on it with my eyes closed for a while. :-)[22:49:44] *** alesj has joined #jboss-as7[22:53:37] <alesj> Nihility: are the AS7 JBW presentations already available?[22:54:00] <Nihility> nope[22:54:05] <Nihility> i never gave it to them[22:54:08] <Nihility> hahahaha[22:54:12] <Nihility> well at least mine isnt[22:54:14] <Nihility> i should do that[22:54:21] *** jpederse has quit IRC[22:56:38] *** smcgowan has quit IRC[22:59:29] <alesj> Nihility: while you do that, can you Cc me as well :-)[22:59:40] <Nihility> haha ok[23:00:06] <alesj> we — the Slovenia JUDCon/JBW gang :-) — are doing a "Post JUDCon/JBW JUG" next week[23:00:17] <alesj> well, leaving out the amounts of beer :-)[23:00:38] <alesj> and the topics are gonna be AS7, Ispan, Arq, CDI and OpenShift[23:00:43] *** jdcasey has quit IRC[23:00:54] <alesj> demoing them all at the end ;-)[23:04:04] *** adietisheim1 has quit IRC[23:05:20] <Nihility> nice![23:08:49] *** irooskov has joined #jboss-as7[23:10:31] *** wolfc has quit IRC[23:24:35] <alesj> in one go[23:25:05] <alesj> Nihility: is there some "most stable" Infinity-integration branch for AS7?[23:27:07] *** mmoyses has quit IRC[23:27:46] <alesj> Nihility: and thanks for the slides![23:28:13] <ALR> alesj: Sweeet[23:28:25] <ALR> Let me know if you want some slides here too.[23:30:34] <stuartdouglas> morning[23:30:47] <jamezp> morning[23:34:26] *** jwulf has joined #jboss-as7[23:35:24] <Nihility> alesj: latest master should have good infinispan support[23:37:07] <alesj> ALR: I guess you mean ARQ slides? … I won't say no :-), so send them over[23:37:33] *** kcbabo has joined #jboss-as7[23:37:33] *** ChanServ sets mode: +v kcbabo[23:37:38] <alesj> Nihility: cool, didn't know Ispan was already in … very cool[23:41:01] <mbg> alesj: try retrieving a cachecontainer from JNDI, that is pretty cool ;)[23:42:26] <alesj> mbg: cachecontainer?[23:46:18] <mbg> alesj: yup. one that's defined in the clustering service (see clustering-standalone.xml for example)[23:47:18] <mbg> alesj: I used one in my Spring demo, you can basically cluster-cache your app in 2 lines of code[23:48:38] <alesj> mbg: isn't this the same ispan config from AS6?[23:49:29] <mbg> alesj: it's in a different place[23:49:53] <mbg> but yeah, similar to it[23:56:36] *** alesj has quit IRC[23:57:02] <stuartdouglas> I am 99% sure that those transient test failures mentioned in the log are caused by races conditions in ServierControllerImpl.ServerStateMonitorListener[23:59:48] <stuartdouglas> because dependencyProblem does not necessarily occur before dependencyProblemCleared (and a few other similar ones) it is possible for the tick count to hit 0 before the deployment is stopped