May 25, 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 25, 2011 NOTICE: This channel is no longer actively logged.
[00:01:40] <stuartdouglas> morning[00:02:44] <misty> morning! when is your flight?[00:03:16] <misty> looks like you will be here in time to watch State of Origin :D[00:03:43] <stuartdouglas> Flight leaves at 4[00:03:47] <stuartdouglas> so I land around 5:30[00:03:51] *** mbg has quit IRC[00:03:56] *** mbg1 has joined #jboss-as7[00:03:56] *** ChanServ sets mode: +v mbg1[00:06:06] <misty> cool, I saw your email (at 10:30PM!)[00:06:09] <misty> you can tell you work remote :)[00:07:03] <stuartdouglas> yea, it does not help that everyone I work with is in a different tz[00:08:07] *** mbg1 has quit IRC[00:11:28] *** kcbabo has quit IRC[00:38:01] <jamezp> dmlloyd: I've another one whenever you're ready https://github.com/jamezp/jboss-as/commit/44d180325501956768cfa7d76eabada19a1b746d[00:38:02] <jbossbot> git [jboss-as] 44d1803.. James Perkins AS7-809 Created message bundle and logger interfaces. Added logging tooling for translations. Updated objects to use the message bundle and logger interfaces.[00:38:03] <jbossbot> jira [AS7-809] Convert modules to use JBoss Logging and message bundles [Open (Unresolved) Task, Major, James Perkins] https://issues.jboss.org/browse/AS7-809[00:39:13] <dmlloyd> cool. I'll start merging these once we finish this controller rework[00:40:19] <jamezp> No problem. The only catch currently is I'm working on the SNAPSHOT release of jboss-logging-processor.[00:47:27] *** jbride has joined #jboss-as7[00:50:04] *** tdiesler has joined #jboss-as7[00:50:53] *** miclorb has joined #jboss-as7[00:54:06] *** aslak has quit IRC[01:01:48] *** jc3 has quit IRC[01:02:11] *** jc3 has joined #jboss-as7[01:02:12] *** jc3 has joined #jboss-as7[01:02:12] *** ChanServ sets mode: +v jc3[01:06:18] *** tdiesler has quit IRC[01:06:47] *** pferraro has joined #jboss-as7[01:06:47] *** ChanServ sets mode: +v pferraro[01:06:51] *** pferraro has quit IRC[01:13:07] <jamezp> dmlloyd: I had to make a minor change. Not sure you if you're keeping a log, but this is the commit to use. https://github.com/jamezp/jboss-as/commit/412780bb2b8e214694fd6fb08f7ec15965a2c500[01:13:08] <jbossbot> git [jboss-as] 412780b.. James Perkins AS7-809 Created message bundle and logger interfaces. Added logging tooling for translations. Updated objects to use the message bundle and logger interfaces....[01:13:09] <jbossbot> jira [AS7-809] Convert modules to use JBoss Logging and message bundles [Open (Unresolved) Task, Major, James Perkins] https://issues.jboss.org/browse/AS7-809[01:22:58] *** pferraro has joined #jboss-as7[01:22:59] *** ChanServ sets mode: +v pferraro[01:23:23] *** pferraro has left #jboss-as7[01:37:22] *** slaboure has quit IRC[01:39:49] *** fnasser has quit IRC[01:40:21] <dmlloyd> when the time comes I'll probably just grab the branch, jamezp[01:40:41] <jamezp> Perfect, thanks.[01:50:45] <stuartdouglas> can someone merge https://github.com/stuartwdouglas/jboss-as/tree/JBCTS-1106[01:50:47] <jbossbot> jira [JBCTS-1106] Redirected to: https://issues.jboss.org/login.jsp?permissionViolation=true&os_destination=%2Fsi%2Fjira.issueviews%3Aissue-xml%2FJBCTS-1106%2FJBCTS-1106.xml[01:52:49] *** odin_ has quit IRC[01:53:28] *** alexsmirnov has quit IRC[01:53:32] *** odin_ has joined #jboss-as7[01:55:08] *** pferraro has joined #jboss-as7[01:55:08] *** ChanServ sets mode: +v pferraro[01:55:30] *** jpearlin has joined #jboss-as7[02:01:36] *** jwulf has joined #jboss-as7[02:02:48] *** pferraro has quit IRC[02:26:07] *** kcbabo has joined #jboss-as7[02:26:07] *** ChanServ sets mode: +v kcbabo[02:34:57] *** jamezp is now known as jamezp_afk[02:41:48] *** frainone has quit IRC[02:47:53] *** Binbingone is now known as Binbin[02:50:24] *** asaldhan has quit IRC[02:52:04] *** JimMa has quit IRC[02:56:52] *** lazarotti has quit IRC[03:02:28] *** sgilda has quit IRC[03:12:21] * dmlloyd back[03:41:26] *** kcbabo has quit IRC[03:41:28] <bobmcw> dmlloyd: got any MockDeploymentPhaseContext or anything to allow unit-testing of DeploymentProcessors?[03:47:55] <bobmcw> a-ha, TestController[03:48:01] <dmlloyd> I guess we do :)[03:49:05] <bobmcw> well, sorta[03:49:05] <bobmcw> https://github.com/jbossas/jboss-as/blob/master/threads/src/test/java/org/jboss/as/threads/ThreadsSubsystemTestCase.java[03:49:26] <dmlloyd> phew[03:49:35] <bobmcw> are you anti-testing?[03:49:41] <bobmcw> do you hate children?[03:49:42] <dmlloyd> I'm pro-testing[03:49:46] <dmlloyd> I'm anti-writing tests[03:49:53] <dmlloyd> especially when they look like this one[03:50:08] <dmlloyd> I mean didn't it occur to anyone to store the expected model as a string in a .txt file?? :)[03:50:25] <bobmcw> says the guy who uses ModelNode for 32 different purposes?[03:51:32] <bobmcw> none of this really helps testing my deploy() though, I don't think[03:53:52] <bobmcw> I feel like you tire of me quickly. :)[03:54:12] <dmlloyd> nah you're cool[03:54:36] <dmlloyd> just thinking about how one would really effectively unit test a deployer in isolation[03:54:49] <dmlloyd> it's not easy[03:54:50] <bobmcw> back in the days of old, we'd stand up just-enough JBossMC[03:54:59] <bobmcw> with the whole reloaded stuff from ALR[03:55:08] <bobmcw> just need an msc-reloaded or easy bootstrap[03:55:19] <bobmcw> from inside junit and rspec[03:55:22] <dmlloyd> it's a bit tricker than that because operations also have to be tested in domain mode[03:55:30] <bobmcw> screw ops, I just want my deployers[03:55:33] <ALR> bobmcw: It's called AS7.[03:55:41] <ALR> Which starts in about the same time as Reloaded did :)[03:55:44] <bobmcw> ALR: give me a @Before method[03:55:47] *** jamezp_afk is now known as jamezp[03:55:48] <bobmcw> for my unit tests[03:55:52] <dmlloyd> yeah I guess deployment chains could exist in a simple MSC[03:55:55] <bobmcw> AbstractAS7TestCase[03:56:13] <bobmcw> or AbstractDefaultAS7TestCaseFactoryLocatorImpl[03:56:15] <bobmcw> whatevs[03:56:46] <bobmcw> I know AS7 boots fast, but I'd like to fail-fast on my build, in units early in my modules[03:56:56] <bobmcw> instead of waiting until we test inside the AS with something ARQ-like[03:57:40] * bobmcw whinges[04:04:07] *** Binbin has quit IRC[04:04:53] <dmlloyd> yeah a 2-second test is no good when you have 1500 tests[04:05:29] <dmlloyd> reusing the same JVM would trim a lot off of it[04:07:04] *** jpearlin has left #jboss-as7[04:08:12] *** lgao has joined #jboss-as7[04:09:07] <bobmcw> really it's more that our integs (which touch AS) are at the end of the build of about 12 modules[04:09:12] <bobmcw> I'd like to unit each of those as I go[04:09:18] <bobmcw> I could just arquillian-alike more often[04:09:48] <bobmcw> but under 1s would be stellar[04:09:53] <bobmcw> just inside a non-forked junit jvm[04:17:49] *** JimMa has joined #jboss-as7[04:40:20] *** stuartdouglas has quit IRC[04:48:31] *** jamezp has quit IRC[04:57:47] *** stliu has joined #jboss-as7[04:57:47] *** ChanServ sets mode: +v stliu[05:03:58] <jbossbot> git [jboss-as] push master c5ef28a.. Stuart Douglas JBCTS-1106 PostConstruct on JSF managed beans[05:03:59] <jbossbot> jira [JBCTS-1106] Redirected to: https://issues.jboss.org/login.jsp?permissionViolation=true&os_destination=%2Fsi%2Fjira.issueviews%3Aissue-xml%2FJBCTS-1106%2FJBCTS-1106.xml[05:03:59] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/2cd9d94...c5ef28a[05:10:09] *** pferraro has joined #jboss-as7[05:10:09] *** ChanServ sets mode: +v pferraro[05:10:33] *** pferraro has left #jboss-as7[05:32:44] *** jwulf has quit IRC[05:34:37] <jbossbot> git [jboss-as] push master 5f6c4d9.. Scott M Stark AS7-648, initial update to support process id configuration[05:34:56] <jbossbot> git [jboss-as] push master 1527060.. starksm AS-648, update to support configuration of process id[05:34:59] <jbossbot> git [jboss-as] push master 543d7ec.. starksm AS7-648, add new files[05:34:59] <jbossbot> git [jboss-as] push master cbff052.. Scott M Stark Further checkpoint of AS-648. Still have a class loading issue...[05:34:59] <jbossbot> git [jboss-as] push master a85bc99.. Scott M Stark AS7-648, Fix dependency issues and add support for specifying the var dir[05:34:59] <jbossbot> git [jboss-as] push master dbfb507.. Scott M Stark Update to jbossjts 4.15.1.Final and use its uuid process id impl[05:34:59] <jbossbot> git [jboss-as] push master 0ef406e.. bstansberry at jboss dot com [AS7-648] Add missing import[05:35:00] <jbossbot> git [jboss-as] push master d556641.. bstansberry at jboss dot com [AS7-895] Disable test until issue is fixed[05:35:00] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c5ef28a...d556641[05:37:37] *** pgier has quit IRC[05:45:18] *** jwulf has joined #jboss-as7[05:53:54] *** Nihility has quit IRC[06:07:19] <jbossbot> git [jboss-as] push master c4d82b8.. David Bosschaert [AS7-439] Make popular logging systems available in OSGi...[06:07:21] <jbossbot> jira [AS7-439] Verify log messages from OSGi bundles feed to aggreaged logfile [Coding In Progress (Unresolved) Task, Major, David Bosschaert] https://issues.jboss.org/browse/AS7-439[06:07:21] <jbossbot> git [jboss-as] push master 739fba1.. bstansberry at jboss dot com Add new osgi config to domain mode testsuite config[06:07:21] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/d556641...739fba1[06:10:43] <jwulf> anyone around atm?[06:12:16] <dmlloyd> nobody here but us chickens[06:12:56] <jwulf> lol[06:13:17] *** magesh has joined #jboss-as7[06:13:20] <jwulf> dmlloyd, i'm getting an error about my jboss-web.xml file when deploying to AS7[06:13:30] <jwulf> jboss web is included in AS 7?[06:13:44] <jwulf> has there been some drastic change to the parsing of jboss-web.xml?[06:13:56] <dmlloyd> yes and sort of[06:14:10] <dmlloyd> the parser was rewritten for performance reasons[06:14:20] <dmlloyd> so there's probably a few quirks with it[06:14:26] <dmlloyd> can you fpaste your output?[06:16:12] <jwulf> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse "/content/TopicIndex.war/WEB-INF/jboss-web.xml"[06:16:13] <jwulf> at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:66)[06:16:14] <jwulf> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)[06:16:14] <jwulf> ... 4 more[06:16:14] <jwulf> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[5,5][06:16:15] <jwulf> Message: Unexpected element 'class-loading' encountered[06:16:17] <jwulf> at org.jboss.metadata.parser.util.MetaDataElementParser.unexpectedElement(MetaDataElementParser.java:109)[06:16:22] <jwulf> at org.jboss.metadata.parser.jbossweb.JBossWebMetaDataParser.parse(JBossWebMetaDataParser.java:182)[06:16:24] <jwulf> at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:64)[06:16:27] <jwulf> ... 5 more[06:16:42] <dmlloyd> fpaste = use a pastebin like fpaste.org :-)[06:16:42] <jwulf> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse "/content/TopicIndex.war/WEB-INF/jboss-web.xml"[06:16:48] <jwulf> Message: Unexpected element 'class-loading' encountered[06:17:01] <jwulf> accha, thanks for the disambiguation[06:17:06] <jwulf> i thought it might be a typo[06:17:08] <dmlloyd> looks like it's not recognizing the class-loading element anymore[06:17:37] <dmlloyd> jwulf, in fedora there's actually a command called "fpaste" which you can pipe things through which will upload stuff to fpaste.org for you and give back the URL[06:17:49] <dmlloyd> great for if you're stuck with no GUI or something![06:17:54] <jwulf> oh really![06:17:56] <jwulf> cool[06:17:57] <jwulf> thanks[06:18:21] <jwulf> waaaay cool[06:18:39] <jwulf> dmlloyd, any idea where this changed behaviour would be documented?[06:19:30] <dmlloyd> documented? :)[06:19:36] <misty> wow that is really cool[06:19:39] <misty> the fpaste command[06:20:20] *** bstans_afk has quit IRC[06:26:20] *** jamezp has joined #jboss-as7[06:28:19] *** Nihility has joined #jboss-as7[06:28:19] *** ChanServ sets mode: +v Nihility[06:29:48] <jwulf> dmlloyd, where do i get the latest nightly build from?[06:29:56] <jwulf> i'll reproduce it with that, and log a bug[06:32:15] <dmlloyd> I don't think we have one, but you can build one easily if you have maven 3, just: git clone git://github.com/jbossas/jboss-as.git; cd jboss-as; mvn clean install[06:32:27] <dmlloyd> if not, then replace mvn clean install with: sh build.sh[06:32:47] <misty> jwulf: that is already documented in the etherpad[06:32:52] <dmlloyd> once maven 3 finishes downloading the internet, it only takes a few minutes[06:36:36] <misty> jwulf: linked you[06:39:06] <jwulf> dmlloyd, found it: http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x/[06:39:36] <dmlloyd> ah, I didn't realize there was a download link[06:41:21] <misty> dmlloyd: last time you sent out the cloak email, I was using misty_wrk[06:41:24] <misty> sorry for the trouble[06:41:32] *** magesh1 has joined #jboss-as7[06:42:12] *** magesh has quit IRC[06:42:41] <misty> dmlloyd: my nicks are misty and misty_wrk[06:43:58] <dmlloyd> okay I'll add you[06:44:20] <dmlloyd> ah I see the problem[06:44:24] <dmlloyd> you need to link your two nicks[06:45:19] <misty> I thought I had[06:45:25] *** misty is now known as misty_wrk[06:45:30] <dmlloyd> they're on separate accounts, it would appear[06:45:30] *** misty_wrk has quit IRC[06:45:30] *** misty_wrk has joined #jboss-as7[06:45:44] <misty_wrk> oh no[06:46:09] <dmlloyd> regular misty and superhero misty_wrk? :)[06:46:19] <misty_wrk> well misty is ancient[06:46:25] <misty_wrk> maybe I need to unregister this one[06:46:28] *** adinn has joined #jboss-as7[06:46:28] *** ChanServ sets mode: +v adinn[06:46:33] <dmlloyd> you could do that[06:46:46] <dmlloyd> and I see adinn already has a cloak, so I just spammed him an extra time for no reason :)[06:47:39] *** misty_wrk is now known as misty_wrk_[06:47:50] *** misty_wrk_ is now known as misty_wrk[06:48:10] <adinn> The Byteman always wears his cloak![06:48:19] *** misty_wrk is now known as misty[06:48:41] *** misty is now known as misty_wrk[06:48:51] *** misty_wrk is now known as misty[06:48:58] <misty> good lawd[06:49:01] <misty> I think I did it[06:49:12] <misty> hi adinn :)[06:49:21] <jfclere> jwulf: Message: Unexpected element 'class-loading' encountered in the jboss-web.xsd: it says:[06:49:22] <jfclere> <!-- FIXME classloading delegation and package filtering ? -->[06:49:22] <jfclere> It is not supported[06:49:37] <adinn> Hi misty :-)[06:49:39] *** stuartdouglas has joined #jboss-as7[06:49:39] *** ChanServ sets mode: +v stuartdouglas[06:50:22] <misty> dmlloyd: I think my head has exploded, but have I set everything up properly?[06:50:32] * stuartdouglas Just got to the airport[06:50:48] * dmlloyd mop mop[06:51:06] <dmlloyd> yup, perfect[06:51:36] <misty> hi stuartdouglas[06:51:39] <misty> dmlloyd: cool :)[06:51:49] <misty> glad I didn't have to lose a nick that has been registered since 1996[06:52:24] <dmlloyd> yeah and if you part with RH, you still keep the nick[06:52:31] * dmlloyd points at that turncoat miclorb[06:52:45] <dmlloyd> should have given him @redhat/turncoat[06:52:47] <dmlloyd> :)[06:54:05] *** jwulf has quit IRC[06:55:17] <misty> lol[06:55:28] <misty> not that you're holding a grudge or anything[06:55:33] <dmlloyd> I would never[06:56:01] <adinn> stuartdouglas: you're at BNE airport?[06:56:16] <stuartdouglas> no, Sydney[06:56:21] <adinn> ah ok[06:56:37] <stuartdouglas> will be in Brisbane in about 2.5 hours[06:56:49] <adinn> excellent :-)[06:57:36] <stuartdouglas> does anyone want to meet up for dinner or a beer when I get there?[06:58:18] *** jamezp is now known as jamezp_afk[06:58:49] <adinn> afraid jonathan and I are booked this evening. tomorrow and friday are both good though.[06:59:12] *** magesh1 is now known as magesh[06:59:53] *** lgao is now known as lgao_[07:00:03] <adinn> ah, miclorb: == michael neale! hi michael :-)[07:00:25] <Nihility> oh hi adinn[07:01:17] *** lgao_ is now known as lgao[07:01:39] <misty> stuartdouglas: tomorrow might be better[07:01:44] <misty> I will be in the office then[07:02:14] *** magesh is now known as magesh1[07:02:19] <adinn> greetings NIL[07:02:21] <misty> stuartdouglas: your hotel has a restaurant / bar that is pretty decent for casual food[07:02:56] <misty> stuartdouglas: and the Transcontinental Hotel is right across the street for a bigger selection of beer[07:04:05] *** magesh1 is now known as magesh[07:05:19] <misty> sigh, why did I update to f15[07:06:43] <dmlloyd> because it rocks.... as long as you don't use gnome :)[07:07:22] <miclorb> adinn: who is this?[07:07:56] <dmlloyd> if his IRC client is to be believed, we shall call him "Mr. Purple"[07:08:04] <adinn> adinn == Andrew Dinn[07:08:14] <adinn> beats Mr Pink[07:08:34] <misty> dmlloyd: that's funny becuse to me, you are purple and adinn is teal[07:08:40] <misty> purple is in the eye of the beholder[07:08:53] <dmlloyd> it's also in the /whois of the beholdee![07:09:05] <misty> hooray, I have fixed spotify in f15, all is ok again[07:10:43] <misty> adinn: do you have time for me to pick your brains about txbridge?[07:11:03] <adinn> yes I do[07:11:33] <misty> oh, I see the purple now[07:11:38] <misty> another pidgin user :)[07:11:40] <misty> will go to pm[07:13:41] <miclorb> adinn: oh hai ! long time no speak[07:13:49] <miclorb> adinn: any funny stories?[07:14:11] <miclorb> everyone is just shades of bllue for me[07:14:16] <miclorb> I really shoudl try another client[07:14:21] <miclorb> and some less typos[07:15:58] <misty> limechat, sounds suss[07:16:00] <misty> :)[07:16:36] <miclorb> anyone have erlang questions, I'm your man.[07:19:04] *** stuartdouglas_ has joined #jboss-as7[07:19:39] <stuartdouglas_> Bugger, my computer locked up[07:19:54] <stuartdouglas_> Stupid Linux mint[07:21:50] *** JimMa is now known as JimMa_[07:21:52] <adinn> neither funny stories nor blue ones I am afraid but nice to hear from you[07:23:04] *** JimMa_ is now known as JimMA[07:23:20] *** JimMA is now known as JimMa[07:25:04] *** JimMa is now known as JimMa_[07:25:28] *** stuartdouglas_ has quit IRC[07:26:30] *** stuartdouglas_ has joined #jboss-as7[07:26:44] *** JimMa_ is now known as jimma[07:26:56] <nickarls> stuartdouglas: ah, the CDI specialization thingie turned out to be on the Weld side[07:27:36] <stuartdouglas_> Yes, gf does it to[07:27:59] <nickarls> flatten out the archive? or break?[07:28:14] *** jimma is now known as JimMa[07:28:29] *** jhalliday has joined #jboss-as7[07:28:47] *** magesh has quit IRC[07:29:25] <stuartdouglas_> Gf does not work either[07:29:39] *** stuartdouglas has quit IRC[07:29:42] *** stuartdouglas_ is now known as stuartdouglas[07:32:01] <nickarls> so there will be a Weld-release synch with the AS? Or just livin' on the edge and use a Weld snapshot for the AS release?[07:32:55] <nickarls> as I would guess the primary reason for @Specialize is to override stuff in frameworks and other bundles archives.[07:34:27] *** slaboure has joined #jboss-as7[07:35:47] <stuartdouglas> nickarls: There will be a weld release for the as[07:36:26] <stuartdouglas> Someone has to fix the bug first though[07:37:09] *** magesh has joined #jboss-as7[07:37:23] <nickarls> yeah, that's always the downside.[07:39:16] *** slaboure has quit IRC[07:40:50] *** magesh is now known as magesh1[07:42:22] *** stuartdouglas has quit IRC[07:42:31] *** JimMa is now known as jimmaq[07:44:05] *** jimmaq is now known as jimmaq_[07:44:22] *** jimmaq_ is now known as jimmaq[07:45:24] *** jimmaq has quit IRC[07:45:47] *** JimMaq has joined #jboss-as7[07:45:50] <nickarls> is it a NP-complete problem?[07:47:25] *** jfclere has quit IRC[07:51:54] *** JimMaq is now known as Jimmaq[07:53:06] *** Jimmaq has quit IRC[07:53:26] *** JimMaq has joined #jboss-as7[07:55:32] *** Binbin has joined #jboss-as7[07:56:39] *** mlinhard has joined #jboss-as7[07:56:39] *** ChanServ sets mode: +v mlinhard[08:07:41] *** jfclere has joined #jboss-as7[08:07:41] *** ChanServ sets mode: +v jfclere[08:10:36] *** tdiesler has joined #jboss-as7[08:10:36] *** ChanServ sets mode: +v tdiesler[08:24:50] *** tdiesler1 has joined #jboss-as7[08:25:59] *** tdiesler has quit IRC[08:27:29] *** pilhuhn has joined #jboss-as7[08:27:29] *** ChanServ sets mode: +v pilhuhn[08:27:34] *** tdiesler1 has quit IRC[08:28:00] *** tdiesler has joined #jboss-as7[08:28:00] *** ChanServ sets mode: +v tdiesler[08:30:15] *** rmaucher has joined #jboss-as7[08:31:49] *** emuckenhuber has joined #jboss-as7[08:31:49] *** emuckenhuber has joined #jboss-as7[08:31:49] *** ChanServ sets mode: +v emuckenhuber[08:39:49] *** slaboure has joined #jboss-as7[08:46:19] *** asoldano has joined #jboss-as7[08:46:19] *** ChanServ sets mode: +v asoldano[08:47:43] *** wolfc has joined #jboss-as7[08:47:43] *** ChanServ sets mode: +v wolfc[08:49:18] *** Jaikiran has joined #jboss-as7[08:49:19] *** ChanServ sets mode: +v Jaikiran[09:09:05] *** adietisheim has joined #jboss-as7[09:10:23] *** misty has left #jboss-as7[09:12:20] *** aslak has joined #jboss-as7[09:12:20] *** ChanServ sets mode: +v aslak[09:14:29] *** magesh1 is now known as magesh[09:15:50] *** adietisheim has quit IRC[09:15:50] *** kevinpollet has joined #jboss-as7[09:16:54] *** adietisheim has joined #jboss-as7[09:16:54] *** tdiesler has quit IRC[09:18:12] *** galderz has joined #jboss-as7[09:18:12] *** ChanServ sets mode: +v galderz[09:21:10] *** jhalliday has quit IRC[09:21:14] *** adinn has left #jboss-as7[09:23:09] *** torben has joined #jboss-as7[09:23:09] *** ChanServ sets mode: +v torben[09:24:47] *** adietisheim has quit IRC[09:27:01] *** hardy_ has joined #jboss-as7[09:31:47] *** adietisheim has joined #jboss-as7[09:34:15] *** tdiesler has joined #jboss-as7[09:34:15] *** ChanServ sets mode: +v tdiesler[09:49:43] *** emuckenhuber has quit IRC[09:53:52] *** tdiesler has quit IRC[09:57:56] *** miclorb has quit IRC[09:58:27] <pilhuhn> This is always fragile here[09:58:28] <pilhuhn> [INFO] JBoss Application Server: Arquillian Managed Container FAILURE [10.953s][09:59:29] *** emuckenhuber has joined #jboss-as7[09:59:29] *** ChanServ sets mode: +v emuckenhuber[10:03:29] *** ALR has quit IRC[10:06:46] <Jaikiran> i have seen it fail too on a hudson instance[10:06:59] <Jaikiran> apparently it fails because the server takes more than 10 seconds to start[10:07:06] <Jaikiran> which is strange[10:07:20] <Jaikiran> and i haven't yet found a way to configure the wait timeout for those tests[10:07:49] <Jaikiran> iirc, the test is IntegrationTestCase (or some similar name)[10:08:46] *** tdiesler has joined #jboss-as7[10:08:46] *** ChanServ sets mode: +v tdiesler[10:13:15] <wolfc> I changed that timeout[10:13:33] <wolfc> I think I only did that for arq2, not arq...[10:14:00] <Jaikiran> within java code?[10:14:27] <wolfc> https://github.com/jbossas/jboss-as/commit/ecd56d8356cb9d3374aa6b48d73f7fd2bf9ac04c[10:14:28] <jbossbot> git [jboss-as] ecd56d8.. Carlo de Wolf Increase startup timeout and always destroy the process if timed out[10:15:17] <Jaikiran> ok[10:16:06] <wolfc> on machines which have a small amount of cores MSC can't show off its true capabilities ;-)[10:18:19] <Jaikiran> :)[10:21:15] *** davidbos has joined #jboss-as7[10:25:21] *** tdiesler has quit IRC[10:28:10] *** tdiesler has joined #jboss-as7[10:28:10] *** ChanServ sets mode: +v tdiesler[10:29:58] <pilhuhn> Jaikiran interestingly enough the next build (just ran build.sh again) succeeded.[10:33:33] <tdiesler> folks, anybody on fedora?[10:36:37] <asoldano> tdiesler, not a very recent version, but yes[10:40:03] *** hbraun has joined #jboss-as7[10:41:08] *** miclorb has joined #jboss-as7[10:46:11] <tdiesler> asoldano, do you have an ip filter for vpnc setup?[10:48:21] *** maeste has joined #jboss-as7[10:48:21] *** ChanServ sets mode: +v maeste[10:50:04] *** jfclere is now known as jfclere_[10:51:07] *** kkhan has joined #jboss-as7[10:51:07] *** ChanServ sets mode: +v kkhan[10:51:38] *** tdiesler1 has joined #jboss-as7[10:52:11] *** tdiesler1 has quit IRC[10:52:15] *** jfclere_ is now known as jfclere[10:52:27] *** tdiesler has quit IRC[10:52:33] *** tdiesler has joined #jboss-as7[10:52:34] *** ChanServ sets mode: +v tdiesler[10:52:51] *** davidbos has quit IRC[10:53:29] *** AndyTaylor has joined #jboss-as7[10:53:29] *** ChanServ sets mode: +v AndyTaylor[10:55:40] *** zroubali has joined #jboss-as7[10:59:37] *** alesj has joined #jboss-as7[11:04:32] *** darranl_afk is now known as darranl[11:11:07] *** zroubali has quit IRC[11:23:49] *** wolfc has quit IRC[11:26:50] *** wolfc has joined #jboss-as7[11:26:50] *** ChanServ sets mode: +v wolfc[11:28:29] *** emuckenhuber has quit IRC[11:39:54] *** slaboure has quit IRC[11:40:02] *** stliu has quit IRC[11:40:12] *** stuartdouglas has joined #jboss-as7[11:41:11] *** slaboure has joined #jboss-as7[11:41:56] *** miclorb has quit IRC[11:41:58] <hbraun> bon giorno[11:42:13] <pilhuhn> :)[11:42:20] <Jaikiran> stuartdouglas: wolfc: just a fyi so that we don't end up duplicating work - i'm working on https://issues.jboss.org/browse/AS7-896[11:42:22] <jbossbot> jira [AS7-896] @Resource of type enum fail with "Can't handle @Resource for ENC name" [Coding In Progress (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/AS7-896[11:42:31] <hbraun> oh, actually it's "buon giorno"[11:42:33] <nickarls> is there any known issues with @Resource injections currently? I have a @Resource(lookup="java:/Mail") private Session mailSession;?[11:42:52] <nickarls> and get a "cannot handle, missing lookup"[11:43:06] <wolfc> nickarls: can you pastebin a trace?[11:43:35] <Jaikiran> that should work, since you have specified lookup value[11:43:40] <Jaikiran> but yeah, pastebin the trace[11:43:55] <nickarls> http://pastebin.com/wA93j0wg[11:45:16] <Jaikiran> nickarls: might be a jbmeta issue. as a quick workaround, can you try setting @Resource(mappedName="java:/Mail")?[11:45:32] <Jaikiran> in the meantime, i'll see what the problem is[11:47:19] <nickarls> bah, hold that. bad build, works now![11:47:53] <Jaikiran> ok :)[11:48:01] <nickarls> I had mappedName and that didn't work but the compiled class with lookupName didn't make it to the WAR at first attempt[11:48:13] <wolfc> nickarls: can you also update to the latest[11:48:46] <nickarls> wolfc: its 15 minutes old ;-)[11:48:53] <wolfc> then mine is old :-)[11:48:58] *** miclorb has joined #jboss-as7[11:49:11] <Jaikiran> just a fyi - if it isn't working with mappedName, then that is a issue too. since we want legacy/existing apps which use mappedName to work too[11:49:23] <Jaikiran> so if you have an issue with that, let us know[11:50:39] <nickarls> the stacktrace I pasted came from a @Resource with mappedName[11:51:05] <Jaikiran> ok, i'll add a testcase and get it fixed[11:55:17] <nickarls> any theories on http://pastebin.com/HGKxWEeW ? seam-persistence module?[11:56:26] <Jaikiran> did the tx subsystem boot up properly[11:56:35] <Jaikiran> i mean did the server startup without any errors?[11:56:54] <Jaikiran> it looks like the tx subsystem failed to boot on that instance[11:57:12] *** emuckenhuber has joined #jboss-as7[11:57:12] *** emuckenhuber has joined #jboss-as7[11:57:12] *** ChanServ sets mode: +v emuckenhuber[11:57:26] <nickarls> 12:55:37,183 ERROR [org.jboss.as.controller] operation ("add") failed - address: ([("subsystem" => "transactions")]): java.util.NoSuchElementException: No child 'process-id' exists[11:57:31] <nickarls> in boot log is suspicious[11:57:53] <Jaikiran> doesn't look like the latest clean version[11:58:02] <Jaikiran> i mean the standalone.xml you have seems outdated[11:59:29] <darranl> Just seen that error myself[11:59:40] *** asoldano has quit IRC[11:59:44] <Jaikiran> i had seen that earlier, due to an outdated standalone.xml[11:59:44] <nickarls> I used a copy a few days old to get my datasource in, I'll check[11:59:54] <Jaikiran> yeah, it changed this morning[11:59:59] <Jaikiran> so older ones wont work[12:00:03] <nickarls> livin' on the edge[12:00:07] <Jaikiran> :)[12:00:25] <darranl> the error looks like it is probably in the wrong place though, that should have been picked up during parsing[12:01:13] *** opalka has joined #jboss-as7[12:01:13] *** ChanServ sets mode: +v opalka[12:02:16] <nickarls> where in the source tree can I find the original standalone.xml?[12:03:06] <Jaikiran> build/resources/standalone[12:03:32] <hbraun> nickarls: reminds me of gun's 'n roses[12:03:52] <Jaikiran> build/src/main/resources/standalone/configuration to be precise[12:03:57] <nickarls> yep[12:04:26] <Jaikiran> out of curiosity, how do add your app datasources there?[12:04:28] <Jaikiran> manually?[12:04:38] <nickarls> yep[12:04:55] <Jaikiran> and you have the standalone.xml checked in for the project?[12:05:13] <Jaikiran> just trying to understand how other users might end up using this stuff[12:05:36] *** torben has quit IRC[12:05:54] *** torben has joined #jboss-as7[12:05:54] *** ChanServ sets mode: +v torben[12:07:21] <nickarls> currently I just have a directory I drop onto the build to get the oracle driver in place and DS configured[12:07:53] *** davidbos has joined #jboss-as7[12:08:38] *** jhalliday has joined #jboss-as7[12:08:57] <wolfc> this is actually a very annoying problem and we need to have a more friendly solution[12:08:58] <darranl> I have created the following to look at the validation - https://issues.jboss.org/browse/AS7-897[12:09:00] <jbossbot> jira [AS7-897] Using an older standalone.xml a NoSuchElementException: No child 'process-id' exists during add handler execution. [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/AS7-897[12:10:18] <wolfc> darranl: what exactly do you mean by that issue? it is not a bug.[12:10:46] <darranl> wolfc, it is a bug as the XML parser failed to detect invalid XML and then submitted an invalid add operation[12:11:04] <wolfc> darranl: we don't do validation, because of speed[12:11:19] <darranl> the error should have been in the context of a missing attribute in the XML[12:11:23] <wolfc> I don't even think we have xsds for those[12:11:25] <nickarls> bah, WELD-912 killed the deployment[12:11:26] <jbossbot> jira [WELD-912] Specializing beans in different bean archives does not work [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/WELD-912[12:13:21] *** kevinpollet has quit IRC[12:13:22] <darranl> It is not about performing validation against the xsd, if you have a look at something like parseJvm in CommonXML missing mandatory attributes should be detectable and an error thrown[12:14:25] *** pmuir has joined #jboss-as7[12:14:26] *** pmuir has joined #jboss-as7[12:14:26] *** ChanServ sets mode: +v pmuir[12:14:44] <wolfc> darranl: I see what you mean, I also see that it should have worked[12:15:47] <wolfc> darranl: https://github.com/jbossas/jboss-as/blob/master/transactions/src/main/java/org/jboss/as/txn/TransactionExtension.java#L227[12:17:08] <darranl> yeah so it does seem to have a check for the missingRequired - I will have a closer look in a few minutes[12:18:00] <wolfc> it's missing a throw[12:18:02] <wolfc> I'll fix it now[12:22:27] <wolfc> Jaikiran: did you also add an AS test for that regression in env-entry?[12:22:45] <Jaikiran> wolfc: locally yes, while fixing that issue[12:22:51] <Jaikiran> haven't pushed it[12:22:58] <Jaikiran> the fix is WIP[12:23:11] <Jaikiran> testsuite2/spec btw[12:23:18] <wolfc> as long as a test is going to be in place[12:23:23] <wolfc> back to the use case of adding DS (or other stuff)[12:23:42] <Jaikiran> yep, there's a long thread on this in the AS7 dev forum[12:24:01] <Jaikiran> basically the old way of allowing user specific config file within the application won't be supported[12:24:21] <Jaikiran> so this is going to drive users to start adding the datasources to the standalone.xml[12:24:35] <Jaikiran> we do advertise multiple ways including CLI and other stuff to do this[12:24:41] <Jaikiran> but all that requires a server start[12:25:03] <Jaikiran> and obviously isn't straightforward compared to just copying a app specific file[12:25:05] <wolfc> yeah, here's my bit: http://fpaste.org/YOds/[12:25:15] <wolfc> I use xsl[12:25:27] <Jaikiran> so i was actually expecting to see users start messing/fiddling with the standalone.xml in their own unique ways[12:25:58] *** opalka has quit IRC[12:26:06] *** opalka has joined #jboss-as7[12:26:06] *** opalka has joined #jboss-as7[12:26:06] *** ChanServ sets mode: +v opalka[12:26:24] <Jaikiran> i was thinking of a way to allow app specific configs like DS etc to be allowed within a app packaging but still follow the subsystem syntax/schema[12:27:03] <davidbos> hbraun: ping[12:27:09] <Jaikiran> for example, a app-specific-standalone-overlay.xml (or whatever oyu call it) with app specific configs which would then be "copied over" to the standalone.xml by the server[12:27:15] <Jaikiran> internally[12:27:20] <Jaikiran> but haven't given it more thought[12:27:23] <pilhuhn> darranl the model description for security seems odd. When I do a :read-resource on security-domain=other I get tons of stuff. But this does not show for read-children-types or anything[12:27:24] <wolfc> wasn't there already an idea to deploy admin operations?[12:27:36] <Jaikiran> the custom archive format?[12:28:17] <darranl> pilhuhn, I haven't actually looked at the security subsystem domain descriptions for a while, you should catch mmoyses when he gets online - shouldn't be too long now[12:28:40] <pilhuhn> k, thanks[12:29:29] <wolfc> or maybe a place where we run-once admin operations from[12:29:43] <wolfc> could be something as simple as a text file[12:30:53] <Jaikiran> ideally the goal of all this should be that deploying these resources should require the server to be up and running[12:31:20] <Jaikiran> the user could just package it along with his app and whenever his app gets picked up during deployment, that's when all this processing should automagically happen[12:31:31] <Jaikiran> yeah, a text file would do too[12:31:56] <Jaikiran> we just need something on the server to identify that text file and trigger the appropriate operations at the right time[12:32:38] <Jaikiran> *shouldn't require the server to be up and running[12:39:59] *** slaboure has quit IRC[12:42:55] <nickarls> would it be difficult to make VFS use a DB as backing storage? It would be nice to deploy over database links ;-)[12:43:41] *** davidbos has quit IRC[12:44:07] *** davidbos has joined #jboss-as7[12:47:18] <kkhan> wolfc: Which branch is your jboss-metadata upgrade on?[12:47:32] <kkhan> Ah metadata-beta3[12:47:46] <wolfc> how did you find that?[12:47:47] <kkhan> I just got scared by the long list of branches :-)[12:47:51] <wolfc> it's also on other branches[12:47:53] <wolfc> :-)[12:48:11] <kkhan> The name gave it away[12:48:55] <wolfc> I'll pick more cryptic ones next time :-P[12:49:07] <wolfc> you can always curl and am the patch[12:49:08] <kkhan> Thanks :-)[12:50:01] <wolfc> kkhan: it's also on top of the pull request[12:50:24] <kkhan> I saw something about curl mentioned once but never looked into it[12:50:39] *** JimMaq has quit IRC[12:53:20] <wolfc> kkhan: curl https://github.com/jbossas/jboss-as/pull/43.patch | git am[12:53:55] <kkhan> Thanks![12:54:30] <wolfc> Did you also see https://github.com/jbossas/jboss-as/pull/43 ?[12:54:57] <jbossbot> git [jboss-as] push master a62779e.. Carlo de Wolf Upgrade to jboss-metadata 7.0.0.Beta3[12:54:57] <jbossbot> git [jboss-as] push master 4fb77f0.. Carlo de Wolf AS7-897: throw exceptions when parsing[12:54:59] <jbossbot> jira [AS7-897] Using an older standalone.xml a NoSuchElementException: No child 'process-id' exists during add handler execution. [Pull Request Sent (Unresolved) Bug, Major, Carlo de Wolf] https://issues.jboss.org/browse/AS7-897[12:54:59] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/739fba1...4fb77f0[12:55:04] <kkhan> That one?[12:55:56] *** slaboure has joined #jboss-as7[12:56:49] <wolfc> yup, thanks[12:57:54] *** miclorb has quit IRC[12:59:29] *** kcbabo has joined #jboss-as7[12:59:30] *** ChanServ sets mode: +v kcbabo[13:00:26] *** stansilvert has quit IRC[13:05:40] <Jaikiran> dmlloyd: baileyje: you around?[13:09:00] *** torben is now known as torben|afk[13:10:17] *** stansilvert has joined #jboss-as7[13:16:53] <Jaikiran> kkhan: got a minute?[13:17:01] <kkhan> Jaikiran: yup[13:17:27] <Jaikiran> kkhan: is there a testcase/code which i can refer to for invoking management APIs from within a test?[13:19:02] <kkhan> Jaikiran: BasicOperationsUnitTestCase[13:19:20] <kkhan> That invokes ops on the server via the client, if that is what you mean[13:19:33] <Jaikiran> yep, that's what i was looking for. thanks![13:22:09] *** kevinpollet has joined #jboss-as7[13:23:27] *** sgilda has joined #jboss-as7[13:24:46] *** jhalliday has quit IRC[13:30:43] <kkhan> darranl: My https://github.com/kabir/jboss-as/tree/remoting_3_2 now works for domains with local and remote DC's[13:31:49] <kkhan> Still loads of crap/println's in there, so I need to tidy it up a bit but the main thing is there. Not that clients currently seem to hang on to threads so I'll look into that after lunch[13:31:58] <kkhan> s/Not/Note[13:35:22] <darranl> thanks kkhan[13:35:53] <kkhan> /NICK kabir_lunch[13:37:47] *** pilhuhn is now known as pil-afk-bbl[13:40:52] *** kkhan is now known as kabir_lunch[13:42:51] *** kabir_lunch has quit IRC[14:02:23] <tdiesler> Nihility, ping[14:06:32] *** kcbabo has quit IRC[14:11:15] *** tcrawley has joined #jboss-as7[14:11:15] *** ChanServ sets mode: +v tcrawley[14:12:34] *** kcbabo has joined #jboss-as7[14:12:34] *** ChanServ sets mode: +v kcbabo[14:27:43] *** wolfc has quit IRC[14:33:06] *** trustin has joined #jboss-as7[14:33:06] *** ChanServ sets mode: +v trustin[14:34:09] <trustin> Someone got some time to help me writing an extension? I'm stuck at subsystem configuration.[14:37:20] <trustin> yay fixed[14:37:32] <hbraun> darranl: ping[14:37:40] <darranl> hi hbraun[14:37:58] <hbraun> did you find some time to look at the problem?[14:38:29] <darranl> hbraun, yes sent the pull request in earlier - just dropped the stale=true and the browser now prompts again after the failed auth[14:38:44] <darranl> the stale=true was confusing the browser as it thought the password it had was valid[14:38:51] <hbraun> ah, then I can pull locally and verify the changes[14:38:54] <hbraun> thanks[14:38:55] *** tdiesler has quit IRC[14:42:49] *** mmoyses has joined #jboss-as7[14:42:49] *** ChanServ sets mode: +v mmoyses[14:45:56] <dmlloyd> good morning[14:46:06] <dmlloyd> Jaikiran: what's up[14:46:21] *** lgao has quit IRC[14:46:27] <hbraun> good morning[14:46:53] <Jaikiran> dmlloyd: i was actually having a code in an EJB which was doing a new InitialContext().bind("java:blah") and it threw a "context is read-only error"[14:47:05] <Jaikiran> so was wondering if binding from components wasn't allowed[14:47:22] <dmlloyd> it isn't right now, but it will be soon[14:47:35] <Jaikiran> ok[14:47:36] <dmlloyd> requires the shared JNDI change[14:47:48] <Jaikiran> is there a JIRA/branch where this is happening?[14:47:57] <dmlloyd> Nihility is working on it[14:47:59] <Jaikiran> ok[14:48:17] <dmlloyd> the semantics are, programmatic bindings are owned by the deployment that makes them[14:48:36] <dmlloyd> and unbind() is only allowed on bindings created this way by the same deployment[14:49:32] *** darranl is now known as darranl_afk[14:49:54] *** zroubali has joined #jboss-as7[14:49:54] *** ChanServ sets mode: +v zroubali[14:50:02] <Jaikiran> oh wait, i was actually talking about this code being in the user application for example from within an EJB implementation[14:50:19] *** tdiesler has joined #jboss-as7[14:50:19] *** ChanServ sets mode: +v tdiesler[14:50:37] *** bstansberry has joined #jboss-as7[14:50:37] *** ChanServ sets mode: +v bstansberry[14:52:00] <dmlloyd> Jaikiran: okay, our implementation code should always be using services to create bindings. Right now that means BinderService but soon it'll be a little different[14:54:05] *** maxandersen has joined #jboss-as7[14:54:06] *** ChanServ sets mode: +v maxandersen[14:54:48] <dmlloyd> for cases like hornetq where they do it programmatically we will be able to support it but the "owner" has to be defined somehow[14:54:58] <hbraun> darranl_afk: how did you verify it?[14:55:24] <davidbos> darranl_afk, emuckenhuber: do you know the how to get around the JVM crash when debugging the Host Controller?[14:57:38] *** asoldano has joined #jboss-as7[14:57:38] *** ChanServ sets mode: +v asoldano[14:59:15] *** Binbin is now known as Binbingone[14:59:20] *** alesj has quit IRC[15:00:04] *** alesj has joined #jboss-as7[15:00:37] <hbraun> dmlloyd: ^[15:00:46] *** alesj has quit IRC[15:00:56] <hbraun> did anyone find a solution yet?[15:01:18] <dmlloyd> use jdb?[15:01:23] <hbraun> haha[15:01:33] <hbraun> pro style[15:01:34] *** alesj has joined #jboss-as7[15:01:40] <hbraun> no serisouly[15:01:45] <davidbos> dmlloyd: actually, I get issues with JDB that I also get with other IDE's[15:01:50] <dmlloyd> I don't know, I haven't really had a chance to dig into it[15:01:58] <hbraun> dmlloyd: ak, thanks[15:02:05] <dmlloyd> iirc we found two different crash scenarios depending on OS/Java version/etc.[15:02:31] <hbraun> dmlloyd: did anyone create an issue for this?[15:02:34] <dmlloyd> no[15:03:52] <davidbos> dmlloyd: I was debugging a little into it and it seemed to point to the ServiceContainerImpl.ContainerExecutor[15:04:03] <dmlloyd> really?[15:04:05] <dmlloyd> a server crash?[15:04:25] <dmlloyd> I think that'd have to be a coincidence, that code is nothing special[15:04:25] <hbraun> https://issues.jboss.org/browse/AS7-901[15:04:29] <jbossbot> jira [AS7-901] Figure out why the JPDA remote debugger crashes in domain mode [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/AS7-901[15:04:34] <davidbos> dmlloyd: I can dig a little deeper[15:04:49] <dmlloyd> btw jdb is a lot nicer if you run it within rlwrap[15:04:59] <dmlloyd> command history etc.[15:05:00] <hbraun> rlwrap?[15:05:11] <dmlloyd> yeah it wraps a console program using GNU readline[15:05:17] *** kkhan has joined #jboss-as7[15:05:17] *** ChanServ sets mode: +v kkhan[15:05:25] <dmlloyd> used to use it all the time in my solaris days[15:05:49] *** pferraro has joined #jboss-as7[15:05:49] *** ChanServ sets mode: +v pferraro[15:07:30] *** zroubali has quit IRC[15:09:39] *** magesh has quit IRC[15:10:56] *** fnasser has joined #jboss-as7[15:14:53] *** darranl_afk is now known as darranl[15:15:52] <jbossbot> git [jboss-as] push master aceedbf.. jaikiran AS7-900 Consider mappedName attribute value while processing @Resource and @EJB annotations[15:15:53] <jbossbot> jira [AS7-900] @Resource and @EJB don't currently support mappedName attribute value [Pull Request Sent (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/AS7-900[15:15:53] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/4fb77f0...aceedbf[15:16:11] <Jaikiran> thanks![15:16:18] *** maxandersen is now known as maxandersen_away[15:16:23] <Jaikiran> nickarls: latest upstream should now work for mappedName too ^[15:16:23] *** jamezp_afk has quit IRC[15:16:29] *** maxandersen_away has quit IRC[15:16:55] *** jamezp_afk has joined #jboss-as7[15:23:42] <davidbos> dmlloyd: well, maybe ServiceContainerImpl.ContainerExecutor is not the actual place where the crash happens, but at least it consistently happens when installing the jboss.network.public service[15:24:11] <davidbos> dmlloyd: I got it down to instance.commitInstallation() - somewhere in there it crashes.[15:24:24] <dmlloyd> I think it likely has more to do with class loading[15:24:32] <dmlloyd> but as to why... I'm not sure[15:24:42] <dmlloyd> why it gets to a certain point I mean[15:25:02] <dmlloyd> might be because two JVMs start up at the same time and there's an inherent race condition in hotspot or something[15:26:46] <Jaikiran> stuartdouglas: if you are around, did we decide on whether to move the Module creation to a earlier phase in deployment?[15:27:09] <dmlloyd> you mean, move stuff which needs a Module later in the deployment[15:27:09] <davidbos> dmlloyd: if there is a race condition it's funny that it *always* happens for in that jboss.network.public service[15:27:43] <dmlloyd> davidbos: it might be interesting to insert a random sleep (say 1-10 seconds) in the main method so they start up staggered, see if the problem still occurrs[15:28:08] <davidbos> dmlloyd: interesting ... I'll try that[15:28:13] *** mgoldmann has joined #jboss-as7[15:28:13] *** ChanServ sets mode: +v mgoldmann[15:28:23] <Jaikiran> i meant this http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002132.html[15:29:17] *** sguilhen has left #jboss-as7[15:31:29] <tdiesler> Nihility, ping[15:32:45] *** jbosslog has quit IRC[15:33:22] *** opalka has quit IRC[15:33:58] <Nihility> tdiesler: hi there[15:35:55] *** clebert has joined #jboss-as7[15:35:55] *** ChanServ sets mode: +v clebert[15:37:57] <hbraun> bstansberry: ping[15:38:01] <Nihility> tdiesler: regarding AS7-837, jboss-modules installs a redirection factory that is visible to the JAXP JDK API classes which are on the system classpath. That redirection factory first checks TCCL, and if not found there, it falls back to a default module (javax.xml.jaxp-provider). So you shouldnt need TCCL to point to annything, and if it does it shouldnt matter (unless it pulls the wrong impl). The exception would be if the redirection factory[15:38:01] <Nihility> somehow not being installed. This could be a problem specific to the testsuite[15:38:02] <jbossbot> jira [AS7-837] Web parsing may fail due to XMLInputFactory could not be instantiated [Coding In Progress (Unresolved) Bug, Major, David Bosschaert] https://issues.jboss.org/browse/AS7-837[15:38:03] *** kcbabo has quit IRC[15:38:06] <hbraun> bstansberry: think that#s feasible for 7.0? https://issues.jboss.org/browse/AS7-757[15:38:07] <jbossbot> jira [AS7-757] Provide an operation to distinguish domain & standalone [Open (Unresolved) Enhancement, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-757[15:38:24] <Nihility> hbraun: do you think we will have standalone working in the console for CR1?[15:38:52] <hbraun> Nihility: yes, I did port everythingover yesterday[15:39:02] <Nihility> hbraun: awesome![15:39:09] <hbraun> Nihility: i just cannot release another snapshot[15:39:23] <hbraun> Nihility: because of that f***g nexus[15:39:23] <bstansberry> hbraun: pong[15:39:35] <bstansberry> f***g nexus!![15:39:35] <hbraun> it really drives me crzy[15:39:52] <hbraun> yeah, crzy, isn't it? ;)[15:40:03] <Nihility> fucking nexus[15:40:10] <Nihility> you dont have to censor![15:40:10] <Nihility> :)[15:40:22] <Jaikiran> Nihility: got a question about Jandex - is it wise/feasible to add a API like ClassInfo#isEnum?[15:40:24] <hbraun> bstansberry: this would make a perfect wednesday: https://issues.jboss.org/browse/AS7-757[15:40:25] <jbossbot> jira [AS7-757] Provide an operation to distinguish domain & standalone [Open (Unresolved) Enhancement, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-757[15:40:29] *** bgeorges has joined #jboss-as7[15:40:32] <hbraun> bstansberry: don't you think?[15:41:01] <bstansberry> haha, ok[15:41:02] *** maeste has quit IRC[15:41:07] <hbraun> bstansberry: no, actually I just wanted to check if we get it for 7.0 or not?[15:41:10] <Nihility> Jaikiran: yeah sure, basically that would just check if it extends java.lang.Enum[15:41:13] <bstansberry> yes, for sure[15:41:18] <hbraun> otherwise I'll work around it[15:41:21] <hbraun> greta[15:41:24] <hbraun> great[15:41:26] *** smarlow has joined #jboss-as7[15:41:26] *** ChanServ sets mode: +v smarlow[15:41:48] *** maeste has joined #jboss-as7[15:41:48] *** ChanServ sets mode: +v maeste[15:43:19] *** jpederse has joined #jboss-as7[15:43:20] *** ChanServ sets mode: +v jpederse[15:44:26] *** frainone has joined #jboss-as7[15:44:26] *** ChanServ sets mode: +v frainone[15:44:28] <hbraun> bstansberry: what about https://issues.jboss.org/browse/AS7-801[15:44:30] <jbossbot> jira [AS7-801] Subsystem "datasource": Management operations result in inconsistent state [Open (Unresolved) Bug, Blocker, Brian Stansberry] https://issues.jboss.org/browse/AS7-801[15:44:50] <hbraun> bstansberry: just need a heads up[15:45:02] <bstansberry> that for sure will be done; working that is why you're not seeing all the small ones getting cleaned up[15:45:26] <hbraun> bstansberry: np[15:45:51] <bstansberry> hbraun: are you doing anything with the tx subsystem for 7.0?[15:45:56] * bstansberry has forgotten[15:46:05] <hbraun> bstansberry: and I thought you playing video games with jason all day long[15:46:12] <bstansberry> better question, have you already done anything?[15:46:32] <bstansberry> haha, no i take breaks from the games for a little porn[15:46:46] <hbraun> hehe[15:46:50] <davidbos> dmlloyd: fyi - a random sleep in the main method makes no difference, the JVM crashes regardless[15:46:59] <hbraun> bstansberry: regarding TX: not yet, still waiting for https://issues.jboss.org/browse/AS7-769[15:47:00] <jbossbot> jira [AS7-769] Expose transaction manager through web management interface [Open (Unresolved) Feature Request, Major, Heiko Braun] https://issues.jboss.org/browse/AS7-769[15:47:15] <bstansberry> k[15:47:21] <hbraun> bstansberry: actually this one: https://issues.jboss.org/browse/AS7-778[15:47:22] <jbossbot> jira [AS7-778] Expose transaction manager statistics [Open (Unresolved) Sub-task, Major, Unassigned] https://issues.jboss.org/browse/AS7-778[15:47:37] <hbraun> but I consoder it a nice to have[15:47:49] <bstansberry> asking 'cause scott stark had pointed out how that subsys has complex attributes instead of child resources[15:47:59] <bstansberry> which i'd fix but was concerned about breaking you[15:48:07] <hbraun> ok[15:48:18] <hbraun> bstansberry: is this one postponed: https://issues.jboss.org/browse/AS7-793 ?[15:48:19] <jbossbot> jira [AS7-793] Expose thread queue usage/metrics [Open (Unresolved) Feature Request, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-793[15:48:27] <hbraun> yes, it is[15:48:31] <hbraun> now I remember[15:48:42] <hbraun> I'll schedule it for 7.1[15:49:04] *** trustin has left #jboss-as7[15:49:09] <bstansberry> we'll see if the jvm stuff gets done. which brings me to...[15:49:17] <bstansberry> emuckenhuber: hello :)[15:49:20] <emuckenhuber> bstansberry: hi[15:49:22] <hbraun> we said that this one is more important: https://issues.jboss.org/browse/AS7-702[15:49:23] <jbossbot> jira [AS7-702] Expose server VM metrics through domain model [Open (Unresolved) Feature Request, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-702[15:49:44] <bstansberry> right[15:49:53] <dmlloyd> davidbos: crashes in the same spot?[15:50:06] <bstansberry> emuckenhuber: what's new?[15:51:18] <emuckenhuber> bstansberry: hmm, quick question related to default values - do we want to represent them in the model now? or just in the description?[15:51:29] <emuckenhuber> i remember there was a discussion, but can't find the email thread any more[15:51:31] <bstansberry> model[15:52:08] <emuckenhuber> hmm, ok thanks[15:53:19] *** fnasser has quit IRC[15:54:51] <bstansberry> emuckenhuber: are you focused on that?[15:55:40] <emuckenhuber> bstansberry: not really, just quickly went quickly through the web related jiras you assigned me to see what needs to be done[15:55:49] <bstansberry> k[15:56:03] <bstansberry> today i'm doing new-controllers stuff[15:56:52] <bstansberry> 1) get all the controller tests in master (BasicModelControllerUnitTestCase etc, children in server module) ported and passing w/ new-controllers[15:57:08] <bstansberry> 2) some ProxyController-ish stuff[15:57:23] <davidbos> dmlloyd: yes, crashes exactly the same spot - somewhere down instance.commitInstallation() for the jboss.network.public service[15:57:28] <bstansberry> hopefully will be a more productive day than recent ones[15:57:31] <dmlloyd> interesting.[15:57:50] <dmlloyd> emuckenhuber: after this call if you'd like to chat I'm available[15:58:11] *** stliu has joined #jboss-as7[15:58:11] *** ChanServ sets mode: +v stliu[15:58:38] <emuckenhuber> dmlloyd: ok cool, that would be great[15:58:40] *** wolfc has joined #jboss-as7[15:58:40] *** ChanServ sets mode: +v wolfc[15:58:52] <bstansberry> the new ProxyController-ish stuff would relate to ModelNodeRegistration, your area of interest[16:02:39] *** maeste has quit IRC[16:09:34] *** sebersole has joined #jboss-as7[16:09:34] *** ChanServ sets mode: +v sebersole[16:10:45] *** mgoldmann has quit IRC[16:12:31] *** pgier has joined #jboss-as7[16:12:31] *** ChanServ sets mode: +v pgier[16:15:35] *** asaldhan has joined #jboss-as7[16:15:35] *** ChanServ sets mode: +v asaldhan[16:18:11] *** maeste has joined #jboss-as7[16:18:11] *** ChanServ sets mode: +v maeste[16:21:33] *** pferraro has quit IRC[16:24:20] *** JimMaq has joined #jboss-as7[16:32:47] *** davidbos has quit IRC[16:38:28] *** maeste has quit IRC[16:38:50] *** maeste2 has joined #jboss-as7[16:38:50] *** ChanServ sets mode: +v maeste2[16:39:15] <dmlloyd> Jaikiran: do you know the answer to http://community.jboss.org/message/606799#606799 ?[16:40:57] <Jaikiran> dmlloyd: replying there[16:41:21] <dmlloyd> thanks[16:43:14] *** mlinhard has quit IRC[16:43:40] <Jaikiran> replied[16:44:07] *** AndyTaylor has quit IRC[16:44:15] <tdiesler> dmlloyd, I'd like to get your input on AS7-858 (again)[16:44:17] <jbossbot> jira [AS7-858] Cannot load module when applying resolver results [Reopened (Unresolved) Bug, Major, Thomas Diesler] https://issues.jboss.org/browse/AS7-858[16:44:17] *** Nihility has quit IRC[16:44:53] <dmlloyd> tdiesler: okay[16:45:06] <tdiesler> dmlloyd, in a single thread I add a ModuleSpec to the ServiceML. A little later the module load fails[16:45:14] <dmlloyd> Jaikiran: is there any way with annotations to customize what the EJB views are bound as?[16:45:42] <dmlloyd> tdiesler: and you're certain it wasn't unloaded?[16:45:44] <Jaikiran> dmlloyd: i didn't get that question[16:45:51] <Jaikiran> you mean which views are exposed by a bean?[16:46:16] <dmlloyd> Jaikiran: no I mean a way to specify a JNDI binding for the view[16:46:49] <Jaikiran> dmlloyd: no, it's not there currently. neither via spec nor via our custom annotations[16:48:11] <tdiesler> dmlloyd, yes http://fpaste.org/aciP/[16:48:40] <tdiesler> dmlloyd, the code in Q is here http://fpaste.org/eymc/[16:49:13] <tdiesler> dmlloyd, you see it does addModules followed by loadModules[16:49:15] <dmlloyd> is there not a nested stack trace?[16:50:21] <tdiesler> dmlloyd, sure but that does not say more http://fpaste.org/Tyyy/[16:51:00] <tdiesler> dmlloyd, this must be a race of some sort. It works in most cases and is also affected by logging[16:51:45] <dmlloyd> a race condition can't exist in a single-threaded environment[16:51:59] <dmlloyd> the problem doesn't occur with trace logging enabled?[16:52:06] <dmlloyd> org.jboss.modules trace logging I mean[16:52:40] <wolfc> I've seen something similar in embedded mode[16:52:50] <wolfc> It would be nice to know the module loader in question[16:52:55] <tdiesler> dmlloyd, it might be an MSC issue. i.e. the service that holds the ModuleSpec is not found somehow[16:52:59] *** jamezp_afk has quit IRC[16:53:11] <dmlloyd> it might be a lot of things really[16:53:28] <dmlloyd> modules trace logging will confirm that the module is defined and not undefined[16:53:38] <dmlloyd> so we can start eliminating possibilities[16:54:09] <tdiesler> dmlloyd, lets see if I can catch it with modules trace enabled.[16:54:58] *** pferraro has joined #jboss-as7[16:54:58] *** ChanServ sets mode: +v pferraro[16:56:25] *** tdiesler has quit IRC[16:59:17] <darranl> dmlloyd, when is a good time to go over the Remoting/EJB3 thing you mentioned you wanted to discuss yesterday? After today I am off for a couple of days but want to start going over where this interceptor is integrating over the weekend.[17:00:11] <dmlloyd> after this call, after or concurrently with my chat with emuckenhuber?[17:00:44] *** pferraro has quit IRC[17:00:48] <darranl> ok thanks, either works for me[17:01:33] <dmlloyd> okay call is done[17:01:35] *** pferraro has joined #jboss-as7[17:01:35] *** ChanServ sets mode: +v pferraro[17:02:09] <dmlloyd> emuckenhuber: okay so on new controllers, since both ops and model descriptions are address-based it seems like the existing registry could continue to work, with an added provision for deployment-scoped stuff?[17:04:31] <emuckenhuber> dmlloyd: well i don't really see a problem with the model descriptions and ops - rather that there is no really consistent way to navigate through the tree[17:04:38] <emuckenhuber> once there are proxies etc.[17:05:36] <dmlloyd> emuckenhuber: can you give an example?[17:06:28] <emuckenhuber> hmm, e.g. read-children-names for hosts and servers[17:06:46] <emuckenhuber> usually it does modelNode.keys()[17:06:57] <emuckenhuber> which does not apply for the proxies[17:08:52] *** Nihility has joined #jboss-as7[17:08:52] *** Nihility has joined #jboss-as7[17:08:52] *** ChanServ sets mode: +v Nihility[17:09:29] <emuckenhuber> also the recursive read-resource op - basically just does model.clone()...[17:09:33] <maeste2> hbraun: ping[17:09:49] <hbraun> maeste2: pong[17:09:50] <emuckenhuber> so i would rather like to have some separate navigation tree - where you can just override some getMOdel()[17:09:58] <maeste2> hbraun: on AS7-898[17:09:59] <jbossbot> jira [AS7-898] Error creating XA datasource in domain mode [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/AS7-898[17:10:03] <hbraun> yes[17:10:24] <maeste2> hbraun: porbably the reason is because you are passing the properties as undefined[17:10:34] <hbraun> yes i nkow[17:10:37] <hbraun> know[17:10:40] <maeste2> hbraun: and I'm using has() instead of hasDefined()[17:10:44] <hbraun> IMO we should both fix it[17:10:53] <maeste2> hbraun: yup, my question is[17:11:07] <maeste2> hbraun: can I reproduce it useing the webconsole on master?[17:11:24] <hbraun> i am struggling witht he new release[17:11:37] <hbraun> hopefully I can upload beta9 by end of today[17:11:44] <hbraun> then you can reproduce it[17:11:56] <maeste2> hbraun: oki, so I have fixed my part, could/want you test on my branch[17:11:59] <hbraun> currently working with eng-ops to improve the nexus settings[17:12:14] <hbraun> ok, i'll drop you a note when it's uploaded[17:12:15] <maeste2> hbraun: if you can't I'll try it when you are done[17:12:25] <hbraun> yes[17:12:50] <maeste2> hbraun: k, I'll wait for it[17:13:29] <dmlloyd> emuckenhuber: I see, you're having a global op handler rather than registering a read op handler on each registered subnode[17:14:03] <dmlloyd> darranl: what are the actual requirements for the security interceptors? simply to associate a Subject?[17:15:29] <bstansberry> dmlloyd: auto-registering a handler for each subresource would only work if we removed the check that barf if another handler gets registered for the same op name[17:15:31] <darranl> dmlloyd, that is the part I need to dig into now, I think that is potentially the first part but to also perform the authorization check and I am also not sure if it needs to handle the RunAs behaviour as well[17:15:35] <dmlloyd> emuckenhuber: back in the dark ages when this was written, I assumed that each registered node would get global ops added to it separately.[17:15:53] <dmlloyd> bstansberry: that check should be only per-node right?[17:16:23] <bstansberry> yeah, but what if the thing doing the registration wants to override the global handler?[17:16:26] <dmlloyd> darranl: our interceptors are split into 2 or 3 roles. The client interceptor, the view interceptor, and the component interceptor.[17:16:53] <dmlloyd> bstansberry: yeah that would have to be allowed somehow for sure[17:17:18] <dmlloyd> bstansberry: I'm not proposing that necessarily as a solution, just reconciling what I remember with what we're doing today[17:17:44] <emuckenhuber> dmlloyd, bstansberry: well having separate op-handlers would most likely make recursive reads more complex?[17:18:08] <bstansberry> maybe not[17:18:12] <dmlloyd> back then I imagined that the one doing the registering would actually add the global handlers, though that's probably a bit inconvenient :)[17:18:21] <bstansberry> haha, yeah[17:18:45] <bstansberry> my goal == subsystem authors don't have to do complex stuff[17:18:54] * bstansberry has failed miserably at his goal[17:19:18] <dmlloyd> nah remember: it could be worse![17:19:21] * bstansberry fears new-controllers is actually going to be even harder on subsystem authors :([17:19:48] <dmlloyd> if there are usability issues with the API, now's the time to raise the flag[17:20:02] <bstansberry> I will, or won't, today[17:21:11] <bstansberry> my comment above was based on previously we did a lot of runtime ollback work auto-magically; now it's the task of the handlers[17:21:40] <bstansberry> which is better, just more for the handler author to do right[17:21:48] <dmlloyd> yeah, that is true[17:22:09] <bobmcw> if my stuff gonna hafta change? can you give me a heads-up, or fork torquebox.git and do it for me? :)[17:22:22] <bstansberry> I predict the latter[17:22:26] <dmlloyd> we will have to make sure we establish a good best-practice - i.e. things which add services should be factored out and shared since removal ops may have to re-add on rollback[17:22:43] <bstansberry> baileyje: ^^^[17:22:58] <dmlloyd> that's the one that I don't like[17:23:09] <bstansberry> ?[17:23:28] <dmlloyd> not only do we have to force op handlers to generate compensating ops, but we also have to implement each reverseable op twice, in essence[17:23:44] <dmlloyd> it would be nice if we could somehow leverage the compensating op, but I don't see how we could do it[17:23:54] <bstansberry> yeah[17:24:58] <bstansberry> we could ditch the compensating ops, unless hbraun pil-afk-bbl or aloubyansky have developed an unreported love for them[17:25:00] <bstansberry> but...[17:25:14] * bstansberry fears we are off on tangents and are ignoring emuckenhuber[17:25:39] *** stliu has quit IRC[17:25:43] <hbraun> bstansberry: i don't yet make use of them[17:25:46] <dmlloyd> I'd vote for ditching compensating ops... and also for not ignoring emuckenhuber :)[17:26:08] <darranl> I'd vote for that - I can drop one of my TODOs ;-)[17:27:11] <bstansberry> emuckenhuber: back to your original point, which as I see it is a tighter relationship between the registry and the model[17:27:43] <hbraun> does that mean any op execute on the domain will obey to the all or nothing approach?[17:27:54] <dmlloyd> darranl: anyway normally the client interceptor *factory* should be serializable (at least that's my current notion) but the other two need not be.[17:28:15] <bstansberry> hbraun: the rules for a domain op are specified by the rollout plan[17:28:38] <dmlloyd> darranl: the weird thing is though, with remote invocation, the calling principal comes from the connection, at least potentially. If you connect as "darranl", then that's your principal and there's no reason to use JAAS on the client[17:28:41] <hbraun> bstansberry: so, compensating op's don't play a role here?[17:29:04] <dmlloyd> hbraun: it's a question of implementaiton[17:29:06] <bstansberry> right. we were using them as a means of rolling back stuff[17:29:18] <bstansberry> but we are moving away from that[17:29:18] <darranl> dmlloyd, yes in the past JAAS on the client was just to associate on a ThreadLocal but didn't perform actual auth[17:29:24] <dmlloyd> hbraun: the new op handlers are required to be able to roll back any modification.[17:29:56] <bstansberry> the issue hbraun is seeing is ops pass on all the hc's but fail on *every* server[17:30:06] <bstansberry> that's a policy question[17:30:40] <bstansberry> by default at least, if that happens, the op should be reverted on the HCs (i.e. not update the domain/host models)[17:30:43] <hbraun> well, all i am saying is I cannot foresee all the implications it has, when dropping the compensating ops[17:30:51] <hbraun> i didn't touch the complex use cases yet[17:30:51] *** fnasser has joined #jboss-as7[17:31:01] <hbraun> like operation or deployment plans[17:31:12] <dmlloyd> there are no other users of them hbraun. the new controllers are transactional[17:31:15] <hbraun> but if you say it will not be related, then fine[17:31:35] <dmlloyd> the question about retaining compensating ops becomes about user interface[17:31:50] <dmlloyd> basically it enables a sort of "undo"[17:32:02] <bstansberry> what can still happen is some op succeeds on all the hc's and on some servers, and the rollout-plan specifies that that is acceptable[17:32:06] <dmlloyd> but then it's a fairly expensive feature[17:32:07] <hbraun> so compensating ops are merely a way to rollback from the client side and only for single operations?[17:32:26] <dmlloyd> well even a multi-step operation can have a compensating op[17:33:32] <hbraun> well, the console will not support undo (is in ctrl-z)[17:34:03] <emuckenhuber> bstansberry: not sure if tighter relationship is the right description :)[17:35:09] <bstansberry> well, it's an actual contract, whereas right now there is none[17:35:31] <emuckenhuber> what i originally wanted is to have an authoritative view on how to navigate thorugh the tree as well as a clear separation between attributes and chidlren[17:35:52] <emuckenhuber> so that this navigatioNode.getModel() gives you the attributes only[17:36:29] *** hardy_ has quit IRC[17:36:30] <emuckenhuber> and children are separate - so that a e.g. non-recursive read operation does not need to prune the children[17:37:16] <emuckenhuber> although that shouldn't be really visible to any client - mainly for the controller...[17:37:36] <bstansberry> how about for op handlers?[17:38:22] <bstansberry> that's the drawback I see -- if op handlers expect to be able to navigate to child resources via modelNode.get("connector", "http") etc[17:38:34] *** sannegrinovero has joined #jboss-as7[17:38:34] *** sannegrinovero has quit IRC[17:38:34] *** sannegrinovero has joined #jboss-as7[17:38:34] *** ChanServ sets mode: +v sannegrinovero[17:39:07] <emuckenhuber> well reading shouldn't be any issue i think - writing might should require a nested operation or we provide access[17:39:30] <emuckenhuber> since i think that this is not the most common case[17:40:10] <emuckenhuber> it might also make it easier to introduce some security checks in future - but i might be wrong ;)[17:41:18] <bstansberry> I told kkhan a while ago that I have a totally broken subbranch where I started trying to get global ops working, which led into proxy controllers[17:41:34] <bstansberry> new-controllers-proxies it will be called when i push it[17:41:35] <kkhan> I can't even build new-controller :-)[17:41:49] <bstansberry> haha, of course not![17:41:58] *** jamezp has joined #jboss-as7[17:42:18] <kkhan> Ah, I thought it was meant to compile[17:42:49] <bstansberry> sorry, no :([17:43:15] <bstansberry> we elected not to do "New*" for every op handler[17:43:20] *** mmoyses has quit IRC[17:43:36] <kkhan> bstansberry: ok so how can I help?[17:44:11] <bstansberry> emuckenhuber: perhaps you can take a look at this subbranch when I push it and see what it would take to do the global ops using a NavigationNode approach[17:44:55] <bstansberry> kkhan: give me a few minutes[17:45:19] <emuckenhuber> bstansberry: ok, sure[17:45:52] <bstansberry> dmlloyd: the fundamental question IMO is whether adding an explicit server-side-only contract between the registry stuff and the model node structure makes sense[17:47:02] <dmlloyd> well maybe having the model be a single monolithic chunk is a bad idea[17:47:25] <dmlloyd> I mean it'd be just as easy to have a separate node for each resource[17:47:35] <dmlloyd> and it'd sure make write transactions more efficient[17:47:42] <bstansberry> true[17:48:05] <dmlloyd> the registry already ties them all together another way[17:49:02] <dmlloyd> best of all it's a change that won't affect the op handlers :)[17:49:07] <dmlloyd> well most of them![17:49:45] <emuckenhuber> yeah, it was pretty easy to do that with the old server controller - never tried with the domain stuff though :)[17:49:55] <bstansberry> well, except every "add" handler is creating empty child nodes for each child type[17:50:10] <emuckenhuber> true, but we could tie that together with the registry[17:50:12] <bstansberry> although getting rid of that is actually a benefit[17:50:22] *** JimMaq has quit IRC[17:50:33] <dmlloyd> yeah it cleans up the global ops a lot because there's no ambiguity between an attribute and a resource[17:51:15] <bstansberry> tangent: we need to make "resource" a real concept[17:51:26] <dmlloyd> the old way we did global ops might work out well here: you specify a global op which applies to all nodes, but a node can override a global op[17:51:32] <dmlloyd> yeah agreed there[17:51:48] <bstansberry> e.g. emuckenhuber 's NavigationNode looks an awful lot like a Resource to me[17:51:49] <dmlloyd> it'd have to move to the registry[17:51:53] <emuckenhuber> yes[17:52:10] <dmlloyd> I don't have that one[17:52:47] <bstansberry> it's the source he linked in his email proposing this conversation[17:53:15] <bstansberry> https://github.com/emuckenhuber/jboss-as/blob/new-controllers/controller/src/main/java/org/jboss/as/controller/registry/NavigationNode.java[17:53:35] <emuckenhuber> well it's a lot like ModelNode - since it was quick to change the code ;)[17:54:06] *** galderz has quit IRC[17:54:37] *** slaboure has quit IRC[17:54:45] <dmlloyd> I dunno I'd argue for it all to be on registry[17:55:01] <dmlloyd> ops to get/modify the resource at that address[17:55:02] *** aslak has quit IRC[17:55:03] <dmlloyd> add/remove operations[17:55:16] <dmlloyd> drop the whole subtree[17:55:26] <dmlloyd> and, the write transaction stuff could easily be there as well[17:56:02] <dmlloyd> if the whole tree shared a write lock (which it has to anyway), each node on the registry could keep a read and a modify copy, and the modify copy is only visible from the lockign thread[17:56:38] <dmlloyd> if we add to that, restoring the ability for per-node op handlers to override global ones, seems like we solve all the problems at once[17:57:00] *** kevinpollet has quit IRC[17:57:01] <dmlloyd> an op is still located by navigating the registry first, even if it's a global default op[17:57:10] <dmlloyd> proxy op handlers work again for dealing with global ops[17:57:50] <dmlloyd> and we can still have the logic where step handlers can only access their sub-tree of resources as well as operation registration[17:58:09] <dmlloyd> we need a strong alignment between operation address and resource address else it'll be chaos[17:58:31] <bstansberry> for sure[17:59:04] *** frainone has quit IRC[17:59:23] *** aslak has joined #jboss-as7[17:59:23] *** aslak has quit IRC[17:59:23] *** aslak has joined #jboss-as7[17:59:23] *** ChanServ sets mode: +v aslak[17:59:54] <emuckenhuber> the only thing i don't like having it all on the registry are that you register handlers using wildcards[18:00:27] <dmlloyd> yeah that's for the case where I have one op that applies to, say, any deployment[18:00:45] <dmlloyd> resources only exist at "real" addresses though[18:01:04] <dmlloyd> and when an op is resolved, it first checks for exact match, then wildcard(s), then global default, then fail[18:01:52] <emuckenhuber> ok, that sounds reasonable[18:01:58] <dmlloyd> so I picture the conceptual address looking like this: "foo=bar,baz=*,**" meaning exactly bar of foo, then any of baz, then any recursively under that as a default[18:02:32] <dmlloyd> for cases like "foo=*,baz=zap" vs "foo=bar,baz=*" I think the original code preferred the latter (exact match first)[18:02:40] <dmlloyd> though I don't see that coming up much[18:04:33] *** dimitris_ has joined #jboss-as7[18:04:33] *** dimitris_ has joined #jboss-as7[18:04:33] *** ChanServ sets mode: +v dimitris_[18:05:29] <bstansberry> emuckenhuber: your problem with the wildcards related to requests for, e.g. /socket-binding-group=x/socket-binding=*:read-attribute(name=port)[18:05:53] <bstansberry> the ambiguity in the meaning of *[18:06:25] <emuckenhuber> hmm, yeah that's what i'm thinking about atm[18:06:59] <kkhan> Is NewModelControllerImpl where I should start looking?[18:07:40] <bstansberry> there and NewOperationContextImpl; that's the essence of it[18:08:57] <emuckenhuber> bstansberry: hmm crap, i need to leave for a couple of minutes.. i'll ping you again when i'm back[18:09:05] <bstansberry> np[18:09:20] <dmlloyd> perhaps there is not a need to support reading from a wildcard[18:09:24] <dmlloyd> or is there?[18:09:48] <dmlloyd> I think it's reasonable for only wildcard operations to match at wildcard addresses[18:10:07] <dmlloyd> but this also means that a wildcard may only be used in the last segment, which may be undesirable[18:10:18] <dmlloyd> there's basically two possible approaches:[18:10:26] <bstansberry> yeah, that's undesirable[18:11:04] <dmlloyd> well before I go into that, if read-attribute is a global default op, then my last stement is a lie[18:11:11] <dmlloyd> you could have wildcards wherever you want[18:11:23] <dmlloyd> because only the global op will match it anyway[18:11:29] <dmlloyd> but it *will* be matched[18:11:41] <dmlloyd> then the global op just handles * with a simple iteration/recursive match[18:11:55] <dmlloyd> so I guess it's not so much of a problem after all[18:12:12] <bstansberry> yes, that might deal with it[18:12:53] <dmlloyd> to handle full recursion it probably makes sense to support ** as an address key[18:13:11] <dmlloyd> /socket-binding-group=*/**=*[18:13:34] <dmlloyd> for the purposes of op location ** is the same as *[18:13:42] <dmlloyd> the op can then do with it what it wants[18:14:11] <dmlloyd> could make dealing with recursive structures easier[18:14:12] *** torben|afk has quit IRC[18:15:10] <dmlloyd> particulary log filters[18:15:42] <dmlloyd> you could do something like, read /subsystem=logging/filter=*/**=*/level=INFO or something[18:16:04] <dmlloyd> dunno, it's a general concept but having support for that could solve a number of problems too[18:16:15] <dmlloyd> recursive read becomes read:/**=*[18:16:22] <dmlloyd> or however it's formatted[18:16:27] <dmlloyd> /**=*:read I guess[18:17:56] <dmlloyd> perhaps we can even wedge XML serialization in there :)[18:18:05] <dmlloyd> if we haven't already![18:20:18] <kkhan> Is OperationMessageHandler where baileyje's auditing stuff is invoked from?[18:20:53] <dmlloyd> I doubt it, that's basically just a logging facility[18:21:26] <kkhan> Just trying to understand why it is there :-)[18:21:30] <dmlloyd> like for logging progress reports[18:21:37] <dmlloyd> so I run an op from the CLI[18:21:41] <dmlloyd> it's a big, long operation[18:21:52] <dmlloyd> I"ll see messages like "Applying to server xyz..."[18:21:57] *** alesj has quit IRC[18:22:02] <kkhan> aha[18:22:07] <dmlloyd> when there's a problem it'll show immediately[18:22:20] *** alexsmirnov has joined #jboss-as7[18:22:42] <dmlloyd> gives us something to show while we're updating our progress bar in a GUI[18:22:43] <dmlloyd> etc.[18:23:32] <dmlloyd> might also be worth adding "stepsCompleted" and "stepsRemaining" counts...[18:23:51] <dmlloyd> though stepsRemaining can and will grow so it might be a bit demoralizing to see your progress meter shrink :)[18:24:49] <dmlloyd> I think I will make that change (later)[18:25:09] <Nihility> Jaikiran: hey i think we probably do need to implement resource enlistment on @DataSourceDefinition[18:25:54] <Nihility> Jaikiran: I dont see a resource out there that does it on its own[18:26:15] <Jaikiran> Nihility: yeah, i think that's how we did it in AS6[18:26:18] <Jaikiran> from what i remember[18:26:23] <darranl> dmlloyd, various vendors have had progress meters going in the wrong direction for ages ;-)[18:27:06] <Nihility> Jaikiran: the annoying thing is that that means we have to wrap it in a proxy[18:28:03] <Jaikiran> right[18:28:13] <dmlloyd> bstansberry: I'm thinking it might be a good idea to allow ops to detect whether the current running operation is going to be rolled back regardless of what happens in their step. (as an enhancement of course, after we merge this beast)[18:28:20] <Jaikiran> we do have tests around that in ejb30/lite/packaging[18:28:29] <Jaikiran> those aren't functional due to other reasons now[18:28:44] <bstansberry> dmlloyd. like a context.isRollbackOnly() ?[18:28:45] <Nihility> Jaikiran: you are saying the TCK does test enlistment of @DataSourceDefinition?[18:28:52] <dmlloyd> bstansberry: that way they won't remove services that will have to be re-added again[18:28:53] <dmlloyd> bstansberry: yeah.[18:29:15] <dmlloyd> bstansberry: the tricky part is, right now we do our verification *after* everything is done[18:29:33] <Jaikiran> Nihility: from what i remember it tests the DS operations within a ejb method and *i think* expects the tx enrollment semantics[18:29:39] <Jaikiran> let me give a quick check[18:29:43] <dmlloyd> bstansberry: and it's the plan, not the ops, that decide whether we're rolling back...[18:30:02] <dmlloyd> bstansberry: so the context would have to be able to know when the conditions for rollback have been met[18:30:20] <dmlloyd> bstansberry: maybe it's too complex :) the benefit would be largely limited to non-distributed operations[18:30:20] <bstansberry> yep[18:30:34] <bstansberry> i kind had that notion in the concurrent rollout stuff[18:30:38] <bstansberry> kind of[18:31:11] <dmlloyd> though it'd help in a different way on distributed operations[18:31:13] <bstansberry> there was a central registry where as each thread that was pushing changes out to servers got done with a server, it reported[18:31:32] <dmlloyd> since if rollback criteria were reached, the domain-level op would stop trying to apply it everywhere[18:31:34] <bstansberry> and threads wouldn't push to a server w/o checking first w/ the registry[18:31:57] <dmlloyd> yeah, soudns like we're converging on the same concept[18:32:08] <Nihility> Jaikiran: ok well that should be a simple fix[18:32:12] <Nihility> ill leave a note for that[18:32:14] *** mgoldmann has joined #jboss-as7[18:32:15] *** ChanServ sets mode: +v mgoldmann[18:32:19] <dmlloyd> basically the context has to be trainable to know when rollback criteria are met[18:32:24] <dmlloyd> if we do that, the rest is pretty easy[18:32:29] <Jaikiran> Nihility: just checked. it justs checks for a getConnection() and nothing more[18:32:33] <Jaikiran> so pretty basic[18:32:42] <Nihility> ah[18:32:43] <dmlloyd> so we have to evaluate what the range of rollback criteria are[18:33:28] <bstansberry> that's there.[18:34:00] <bobmcw> man, if only we had people who understood transactions in this company... we should hire some, from HP or something[18:34:09] <bobmcw> ask MarkL if he knows anyone[18:34:19] * bobmcw waits for maven to run[18:34:42] <bstansberry> org.jboss.as.domain.controller.plan.ConcurrentGroupServerUpdatePolicy and related stuff[18:36:53] <dmlloyd> bstansberry: okay so really it sounds like we need a layer to interpret the execution plan and apply it to the context[18:36:56] <bstansberry> emuckenhuber kkhan : https://github.com/bstansberry/jboss-as/tree/new-controllers-proxies[18:37:06] <dmlloyd> because the model controller doesn't know anything about servers[18:37:14] <dmlloyd> all it knows is, this op failed, this op succeeded[18:37:45] <dmlloyd> if we could get it into the controller that'd be best though, so if the op can somehow hook into the evaluation process we could reuse these exact classes[18:38:01] *** sannegrinovero has quit IRC[18:38:06] <dmlloyd> if we had a way of translating op success/failure to server success/failure I mean[18:38:14] <bstansberry> dmlloyd: one sec[18:38:42] <bstansberry> emuckenhuber, kkhan : that branch started as an effort to get the global handlers working[18:39:16] <kkhan> Is any of that working in the main branch?[18:39:42] <bstansberry> quickly sequed into looking at how proxied calls would work, since many recursive ops end up calling proxies[18:40:30] <bstansberry> the main part for proxies is ProxyStepHandler, which would get added as a step, and then invoked and then would be responsible for calling the proxy and integrating its result[18:40:36] <bstansberry> kkhan: any of what?[18:40:59] *** sannegrinovero has joined #jboss-as7[18:40:59] *** ChanServ sets mode: +v sannegrinovero[18:41:07] <dmlloyd> ideally ProxyStepHandler would be transactional, and would use the result of completeStep() to apply a commit/rollback answer to the proxied operation[18:41:12] <kkhan> You said " that branch started as an effort to get the global handlers working", so I'm not clear about what if anything works where :-)[18:41:49] <dmlloyd> are you trying to get an angle on the remoting integration kkhan?[18:42:12] <bstansberry> kkhan: nothing in new-controllers works anywhere[18:42:13] <kkhan> First I'm trying to understand the new controllers, is there anything runnable?[18:42:17] *** asoldano has quit IRC[18:43:00] <bstansberry> dmlloyd: oy, yeah[18:43:03] <dmlloyd> if you want an easy start, just implement a remoting protocol which accommodates the NewModelController execute method for proxies[18:43:15] <dmlloyd> and one which implements NewModelControllerClient[18:43:19] <dmlloyd> bstansberry: ...back onto the deployment plan topic... or, perhaps we can simply enable setRollbackOnly on the op context and allow ops to control it after all, and just utilize that in domain ops to implement execution plans - that would relieve a lot of API pressure[18:43:24] <bstansberry> I write this partiallym then got sicke[18:43:27] <bstansberry> sick[18:43:29] <kkhan> ok, thanks[18:43:38] *** sannegrinovero has quit IRC[18:43:48] <bstansberry> so I realize now it's even less complete than I thought :([18:44:12] <kkhan> I'm sick too :-( Cold + eye infection :-S[18:44:39] <dmlloyd> the proxy handler for remoting would use the API kkhan is going to work up[18:44:46] <dmlloyd> it should all fit together[18:45:23] <dmlloyd> note that the API for communicating remotely (and transactionally) with a domain participant ("slave") should not be part of the public client library though[18:45:29] <bstansberry> the thing to look at in that branch is the ProxyOperationControl[18:45:40] <bstansberry> it's not[18:45:52] <dmlloyd> okay I just want to make sure that's out there[18:45:53] <dmlloyd> :)[18:45:59] <bstansberry> sure, good[18:46:00] <kkhan> ok, I think I'll start porting my remoting bits and pieces over and take it from there[18:46:24] <dmlloyd> okay feel free to ask questions rather than be stuck - it may not be possible for this to be up & running for a few days[18:47:56] <bstansberry> when this conversation ends i'll spend a couple more minutes on ProxyStepHandler just so it's a bit more apparent what the problems it was trying to solve are[18:48:20] <dmlloyd> bstansberry: so then for deployment plans, if we have a context set/isRollbackOnly, we could use a step handler which is auto-prepended to domain controller operations which parses the plan and does all the dirty work of figuring out host/server distribution, adding proxy ops as necessary which know how and when to give up processing due to failure[18:48:24] <bstansberry> basically they relate to getting a result from the proxy and properly integrating it with the parent operation that's led to the call to the proxy[18:48:44] <dmlloyd> yeah, cool, sounds exactly what is needed[18:49:38] <bstansberry> dmlloyd: yes, that's exactly how I saw it.[18:49:45] <dmlloyd> cool[18:50:04] <dmlloyd> then.... I'll add the rollback thing to the context[18:50:18] <bstansberry> the part that's needed is the input from the HC's telling what the server operations are[18:50:34] <dmlloyd> yeah, more proxy steps[18:50:44] <dmlloyd> so DC adds HC query steps, then those steps add server steps[18:51:00] <dmlloyd> if any step exceeds the criteria they setRollbackOnly[18:51:13] *** sannegrinovero has joined #jboss-as7[18:51:13] *** sannegrinovero has joined #jboss-as7[18:51:13] *** ChanServ sets mode: +v sannegrinovero[18:51:20] <dmlloyd> then the whole thing unwinds and the after-completeStep() code of each proxy step does the rollback/commit[18:51:27] <dmlloyd> perfect[18:51:40] <dmlloyd> what could possibly go wrong![18:51:42] <bstansberry> it's a bit more fine-grained though[18:51:55] <bstansberry> the rules for rollback apply at different levels[18:52:16] <dmlloyd> yeah but since it's all a flat chain, the criteria can be shared among all the proxying step handlers equally[18:52:19] <bstansberry> first the server itself, which is the same as what we see in standalone[18:52:39] <bstansberry> then the server group[18:53:21] <bstansberry> then whether one server group faiing results in all others rolling back[18:54:51] <dmlloyd> we can put all that logic into one class with methods like serverInGroupFailed, hostFailed, hostSucceeded, etc. and that instance can be passed to all the step handlers which proxy, and it can decide whether to trigger rollback[18:55:27] <dmlloyd> then for local server operations, the execution plan is, presumably, somewhat simpler[18:55:55] <dmlloyd> rollback-on-runtime-failure[18:56:15] *** frainone has joined #jboss-as7[18:56:15] *** ChanServ sets mode: +v frainone[18:56:38] <dmlloyd> should be fairly straightforward I think... the service verification handler can probably implement that automatically tbh[18:58:41] <dmlloyd> do we still have "operation-headers", bstansberry?[18:58:57] <dmlloyd> looks like it's different depending on whether it's a composite op?[18:59:07] *** vtunka has quit IRC[18:59:43] <bstansberry> dmlloyd: yes, we have "operation-headers"[18:59:57] <bstansberry> the rollout plan is in there, "rollback-on-runtime-failure" is in there[18:59:58] <Jaikiran> stuartdouglas: wolfc: just a fyi - i have taken care of the ejb30/lite/singleton/concurrency tests. will request a merge tomorrow morning (after some more local testing)[19:00:13] <bstansberry> anything else we dream up would be in there[19:00:38] <bstansberry> e.g. a flag to say "go ahead and execute in the runtime even though the server is restart-required[19:00:43] <dmlloyd> bstansberry: okay in the FormatOf... document it shows composite ops bypassing that[19:01:07] <dmlloyd> I assume that's an oversight?[19:01:23] *** Jaikiran has quit IRC[19:01:31] <bstansberry> yeah, my wiki maintenance practices leave something to be desired[19:01:52] <dmlloyd> just want to make sure we can handle that consistently in any op[19:04:50] *** clebert has quit IRC[19:07:22] <wolfc> dmlloyd: I've added https://github.com/wolfc/jboss-as/commit/837b6cd51225e4df95edad17199c85583875ae5c to AS7-434. Which at least takes AS off the modules fork.[19:07:23] <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[19:07:24] <jbossbot> git [jboss-as] 837b6cd.. Carlo de Wolf AS7-434: add a dependency on CLASSPATH in EjbDependencyDUP[19:15:03] <bstansberry> dmlloyd: I updated that wiki page[19:15:13] <dmlloyd> okay cool[19:19:03] <dmlloyd> okay cool wolfc[19:19:10] <dmlloyd> we can analyze that further later on[19:20:06] <wolfc> I'm not too thrilled about having a hard-coded standalone.xml that we need to keep in sync[19:20:51] <dmlloyd> yeah we should change that for 7.1 at the latest[19:20:55] <dmlloyd> hopefully 7.0[19:21:09] <dmlloyd> once the new controllers are in it might be easier to generate a programmatic config[19:21:25] <pmuir> pgier: do you plan to support as7 in the jboss maven plugin by the time as7 goes final?[19:22:06] <Nihility> pgier: pmuir: on that topic jamezp did a simple plugin for as7 using the deployment apis[19:22:24] <pmuir> Nihility: perfect, is it released to maven?[19:22:29] <pmuir> i need to avoid snapshots[19:22:36] <pmuir> jamezp: ^^^[19:22:53] <pmuir> i don't care what I use, as right now i have ant embedded in maven[19:22:59] <pmuir> anything is better than that![19:23:08] <Nihility> pmuir: i am not sure if he ever pushed a non-snapshot release for it but he could do that anytime imo[19:23:17] <pmuir> ok, what tz is he?[19:23:24] <pmuir> i'll try to catch up with him[19:23:57] <Nihility> hes in the west are of the us IIRC[19:24:07] <pmuir> ok so he should be around[19:24:11] <pmuir> i'll see if he wakes up[19:24:13] <dmlloyd> jamezp wake up![19:24:15] <dmlloyd> :)[19:24:30] *** galderz has joined #jboss-as7[19:24:30] *** ChanServ sets mode: +v galderz[19:25:27] <jamezp> Oops, sorry. Reading now.[19:27:40] *** galderz has quit IRC[19:27:45] <jamezp> pgier Nihility: This is my repository, I need to get a README for it though https://github.com/jamezp/jboss-as-deploy-plugin[19:28:28] <pmuir> jamezp: is the plugin stable enough to do a beta release and push to the jboss nexus repo in the next week?[19:29:50] <jamezp> pmuir: Good question :-) AFAIK I'm the only one that's tested it. It works for me, but I did have some problems undeploying a named deployment.[19:30:37] <jamezp> I can definitely spend some time testing it and getting it fixed up if needed.[19:31:14] <pmuir> ok, here is the deal[19:31:18] <pmuir> you write a readme[19:31:23] <pmuir> I will test it tomorrow[19:31:24] <pmuir> hows that?[19:31:45] <pmuir> basiclly right now the main ugly bit of my stuff is deploying from maven[19:31:48] <jamezp> Sounds like a plan. I'll do it now.[19:32:00] <pmuir> apart from the ugliness that maven forces on us of course ;-)[19:32:09] <jamezp> Haha[19:32:40] <hbraun> emuckenhuber: ping[19:32:58] <hbraun> how do i create an empty property list ?[19:33:10] <hbraun> did ask that q already?[19:34:44] *** adietisheim has quit IRC[19:35:32] <hbraun> bstansberry: ping[19:36:26] <bstansberry> hbraun: pong[19:36:31] *** jfclere has quit IRC[19:36:45] <hbraun> i am looking for an equivalent to ModelNode.setEmptyList()[19:36:53] <hbraun> just for property lists[19:37:25] <hbraun> cause if an empty list is decoded with asPropertyList() it will blow up[19:37:54] <hbraun> does that make sense to you?[19:38:19] <hbraun> bstansberry: ^[19:38:23] <bstansberry> will ModelNode.setEmptyObject() do that trick?[19:38:31] <hbraun> maybe[19:38:33] <hbraun> let me check[19:39:39] <hbraun> yes it does[19:39:41] <hbraun> tnx[19:40:44] *** emuckenhuber has quit IRC[19:40:57] <Nihility> jamezp: dmlloyd http://www.youtube.com/watch?v=8u9cKXMP3z8[19:41:04] <bstansberry> cool. internally there's a fair bit of auto-conversion between objects and property lists, but wasn't sure if it would handle your use case[19:41:22] <Nihility> some weird dudes rant about gnome 3[19:41:31] <Nihility> since you guys were saying it sucked[19:42:00] <hbraun> bstansberry: yes, it does[19:42:36] <hbraun> still we could improve the asPropertyList() to gracefuly return a list insetad of blowing up[19:42:59] <bstansberry> ?[19:43:09] <asaldhan> Nihility: seems aussie guy[19:43:19] <hbraun> bstansberry: is that or me?[19:43:23] <hbraun> for me?[19:43:27] <bstansberry> yeah[19:43:35] <jamezp> Nihility: So far I couldn't agree more. It's pretty crap.[19:44:10] <hbraun> well, if a client doesn't properly encode the payload, the server side ModelNode.asPropertyList() blows up[19:44:33] <hbraun> i.e. I need to todo ModelNode.setEmptyObject() if there are no properties[19:44:59] <hbraun> bstansberry: nevermind[19:45:08] <Nihility> jamezp: my favorite wm was enlightenment, although it seems like they will never finish E17[19:45:09] <hbraun> bstansberry: i'am getting too tired[19:45:15] <hbraun> bstansberry: another time ;)[19:45:29] <asaldhan> Nihility: I use KDE[19:45:44] <bstansberry> hbraun: :)[19:46:40] <jamezp> Nihility: Like an idiot I upgraded without checking out screen shots or really looking into it at all.[19:47:45] <dmlloyd> for f15 I'm going to upgrade this weekend using XFCE, and my trusty local build of sawfish wm :)[19:47:55] <dmlloyd> xfce is pretty good imo.[19:48:09] <dmlloyd> I'm more concerned about the increasingly fragile state of nvidia support[19:48:28] <jamezp> I should have tried that, but I somehow broke Gnome and I couldn't even log in.[19:48:29] <dmlloyd> nouveau is getting better, but not good enough yet, and nvidia binary has the 3D support but is gradually deteriorating[19:49:10] <dmlloyd> I have a friend's system running xfce on f15 and they love it - and they totally suck at computers[19:49:52] <hbraun> +1 on xfce[19:50:05] <hbraun> if you like it minimal[19:50:17] * dmlloyd does[19:50:17] <jamezp> I'll have to check that out. I installed KDE, then uninstalled it. After that nothing worked.[19:50:22] <dmlloyd> heh[19:50:32] <dmlloyd> might want to start fresh from the xfce live CD tbh[19:50:51] <dmlloyd> I have it downloaded on an SD card, all ready to go[19:50:56] <jamezp> KDE looks too much like Windows for my liking.[19:50:57] <dmlloyd> (who burns CDs anymore?)[19:51:38] <jamezp> The last time I did was Fedora 14 to take to Raliegh so I could install it on my laptop when I got it.[19:51:47] <jamezp> Before that, I honestly don't even remember.[19:52:14] <Nihility> jamezp: a famous quote from Linus years ago "This 'users are idiots, and are confused by functionality' mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it. I don't use Gnome, because in striving to be simple, it has long since reached the point where it simply doesn't do what I need it to do. Please, just tell people to use KDE.""[19:53:27] <jamezp> Haha. I actually really like Gnome 2.3x, but I'm fairly new to Linux.[19:56:11] <Nihility> i liked it in the early day[19:56:13] <Nihility> s[19:56:21] <Nihility> it became more annoying as time went on[19:56:32] <Nihility> im not a fan of KDE either though[19:56:46] <Nihility> but i dont use linux for desktop anymore[19:57:02] *** emuckenhuber has joined #jboss-as7[19:57:02] *** emuckenhuber has joined #jboss-as7[19:57:02] *** ChanServ sets mode: +v emuckenhuber[19:57:02] <jamezp> I'm using my Mac now :-)[19:59:06] <Nihility> haha[19:59:07] *** hbraun has quit IRC[19:59:10] <Nihility> finally a REAL UI[19:59:47] <jamezp> I do love the OS X UI. Can't get much more polished than that.[20:00:23] <dmlloyd> it's okay[20:00:32] <dmlloyd> I don't like how they hobble you in so many ways though[20:00:39] <dmlloyd> I like my focus-follows-pointer[20:01:03] <Nihility> it was hard getting used to menu at the top[20:01:27] <jamezp> I like the little shiny bits, the the text that appears in reverse on the doc when you have a document open.[20:01:53] <jamezp> I love the unified menu too. I don't like how closing all the windows doesn't always close the app though.[20:02:18] <Nihility> interesting surprise about OSX[20:02:25] <Nihility> is that all the advanced stuff is in keybindings[20:02:34] *** darranl is now known as darranl_afk[20:02:39] <dmlloyd> yeah I mean it's usable[20:02:39] <Nihility> and once you know them you dont have to use the mouse for much[20:02:57] <dmlloyd> I just still like linux better, it just flows easier I guess[20:03:01] <dmlloyd> I like my X11 apps[20:03:10] <dmlloyd> and those don't integrate very well on the mac[20:03:19] <dmlloyd> I mean they integrate *fairly* well[20:03:25] <dmlloyd> but like there's no systray integration[20:03:35] <jamezp> X11 looks like crap on a mac.[20:03:38] <dmlloyd> or very poor I should say[20:03:40] <Nihility> what X11 apps do you use?[20:03:47] <dmlloyd> so with xchat on mac I never get notifications[20:03:53] <jamezp> I tried GIMP and I just couldn't take it.[20:04:08] *** sannegrinovero has quit IRC[20:04:09] <jamezp> Adium on Mac is really nice I think.[20:04:11] <Nihility> i use colloquy[20:04:17] <Nihility> which has gotten alot better[20:04:28] <Nihility> it also has a bouncer built in[20:04:31] <Nihility> which is pretty cool[20:04:35] <jamezp> Yeah, that's not bad either.[20:05:11] <bobmcw> LimeChat ftw[20:05:28] <bobmcw> LimeChat does growl nicely[20:06:40] <jamezp> Adium has nice Growl too.[20:06:41] *** pmuir has quit IRC[20:08:07] *** mlinhard has joined #jboss-as7[20:08:07] *** ChanServ sets mode: +v mlinhard[20:08:23] <bobmcw> I use Adium, but only for normal IM stuff[20:08:26] *** tdiesler has joined #jboss-as7[20:08:26] *** ChanServ sets mode: +v tdiesler[20:09:09] <wolfc> I'm seeing instability w.r.t. transactions[20:11:12] *** ALR has joined #jboss-as7[20:11:12] *** ChanServ sets mode: +v ALR[20:16:28] <pil-afk-bbl> bstansberry No, I have not[20:16:32] *** pil-afk-bbl is now known as pilhuhn[20:16:47] <bstansberry> great, thanks :)[20:19:54] <emuckenhuber> bstansberry: hey, sorry took me longer than i thought...[20:21:19] *** alesj has joined #jboss-as7[20:21:40] <bstansberry> np[20:22:50] <emuckenhuber> bstansberry: so priority is to get the global ops and test cases working again in your proxy branch?[20:24:02] <bstansberry> emuckenhuber: that and to convert the discussion above into something real[20:24:47] <bstansberry> i'm throwing the global ops at you because that seems to be a real driving use case for this change[20:25:49] *** pmuir has joined #jboss-as7[20:25:49] *** ChanServ sets mode: +v pmuir[20:26:06] *** jamezp has quit IRC[20:31:50] *** maeste2 has quit IRC[20:32:53] <emuckenhuber> bstansberry: ok[20:33:00] <emuckenhuber> bstansberry, dmlloyd: thanks for the input btw[20:33:42] <dmlloyd> emuckenhuber: did you follow our meandering tangent?[20:34:45] <emuckenhuber> dmlloyd: about the rolling back stuff?[20:35:31] *** jamezp has joined #jboss-as7[20:36:00] <dmlloyd> yeah, that and op registration, and isolating resources from each other, etc.[20:37:52] *** lazarotti has joined #jboss-as7[20:41:12] <emuckenhuber> dmlloyd: hmm, i was reading the logs - however now i'm not quite sure i followed everything what was discussed[20:42:36] <dmlloyd> okay if you have any questions feel free to ask[20:49:50] *** mmoyses has joined #jboss-as7[20:49:50] *** ChanServ sets mode: +v mmoyses[20:51:30] <dmlloyd> bstansberry: okay my branch has a prepare step operation hook and setRollbackOnly()[20:51:50] <bstansberry> k[20:52:55] <jbossbot> git [jboss-as] push master 266c556.. Darran Lofthouse [AS7-882] Re-send a 401 challenge after failure to verify the users credentials.[20:52:56] <jbossbot> jira [AS7-882] Re-send a 401 challenge after failure to verify the users credentials for Digest auth (Domain Management) [Open (Unresolved) Task, Major, Darran Lofthouse] https://issues.jboss.org/browse/AS7-882[20:52:56] <jbossbot> git [jboss-as] push master 12dcca1.. Darran Lofthouse Corrected order of constants (Supposed to be alphabetical.)[20:52:56] <jbossbot> git [jboss-as] push master 614932f.. Darran Lofthouse [AS7-833] Properties file based repository of users for domain management.[20:52:57] <jbossbot> jira [AS7-833] Incorporate changes to AS7-701 [Resolved (Done) Bug, Major, Heiko Braun] https://issues.jboss.org/browse/AS7-833[20:52:58] <jbossbot> jira [AS7-701] server-config model carries both "system-property" and "system-properties" subresource [Resolved (Done) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-701[20:52:58] <jbossbot> git [jboss-as] push master 8c62128.. Darran Lofthouse [AS7-892] InitialContextFactoryBuilder should use Class.forName passing in the ClassLoader instead of using it directly.[20:52:58] <jbossbot> jira [AS7-892] InitialContextFactoryBuilder should use Class.forName passing in the ClassLoader instead of using it directly [Open (Unresolved) Task, Major, Darran Lofthouse] https://issues.jboss.org/browse/AS7-892[20:52:59] <jbossbot> git [jboss-as] push master 8a4ba3c.. Darran Lofthouse Workaround to clear the ContextClassLoader to allow access to the System ClassLoader when loading the dir context factory.[20:52:59] <jbossbot> git [jboss-as] push master 830f072.. Darran Lofthouse [AS7-882] Additional change to correctly handle scenario where username is not found or not provided.[20:52:59] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/aceedbf...830f072[20:54:47] <bstansberry> emuckenhuber: kkhan : just pushed a change to new-controllers-proxies[20:55:10] <bstansberry> to beef up ProxyStepHandler a bit, better illustrate some of the issues around it[20:56:17] <bstansberry> I don't want to maintain that as a branch though; i pushed it out there so you guys could see what was in it, build on it if you think useful, laugh at it, whatever[20:56:21] *** torben has joined #jboss-as7[20:56:22] *** torben has quit IRC[20:56:22] *** torben has joined #jboss-as7[20:56:22] *** ChanServ sets mode: +v torben[20:57:10] <bstansberry> I'm going to focus on other areas of new-controllers today[20:57:58] <dmlloyd> bstansberry: anything you want me to look at? else I"ll keep plugging on bootstrap[20:58:22] <dmlloyd> in particular I could detour over to the registry for a while[20:59:18] <bstansberry> dmlloyd: https://github.com/bstansberry/jboss-as/commit/bc209e054abeb75e53341c5da5d123b9c512c132 is more of a thought experiment than anything[20:59:19] <jbossbot> git [jboss-as] bc209e0.. bstansberry at jboss dot com Beef up ProxyStepHandler a bit[21:00:24] <nickarls> what's the difference between arquillian and arquillian2 dirs?[21:00:28] <dmlloyd> hm interesting, so you're looking at how proxy ops actually interact with the local physical model[21:00:36] * dmlloyd points nickarls at ALR[21:00:58] * nickarls glares at ALR[21:00:58] <ALR> nickarls: arquillian2 is updated to the more recent releases of Arquillian[21:01:00] <dmlloyd> bstansberry, so is this intending to get the result model into the overall result?[21:01:10] <ALR> And will soon be the only one left[21:01:18] <ALR> Same for demos2 and testsuite2[21:02:33] <bstansberry> dmlloyd: yeah.[21:03:16] <nickarls> ALR: so if I would write a test for WELD-912 ,I would place it in arq2/container-managed?[21:03:17] <jbossbot> jira [WELD-912] Specializing beans in different bean archives does not work [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/WELD-912[21:03:31] <ALR> nickarls: arq2/testsuite2[21:03:35] <bstansberry> dmlloyd: imagine a recursvie read-resource invocation[21:03:52] <nickarls> or is it easier to write it under weld and run it on as7?[21:03:54] <ALR> nickarls: And if it's just using spec-only APIs, then put it under spec" in there[21:04:09] <ALR> nickarls: IMO tests should go at the closest level to the source of the problem[21:04:15] <ALR> AS tests are integration tests really[21:04:24] <ALR> If you can isolate the issue within Weld, I'd say put it there.[21:04:37] <dmlloyd> I don't think the real impl will necessarily use the exact model controller interface, but conceptually I think this is reasonable[21:05:00] <nickarls> it's Weld but only fails on AS7, I'll check if it can be configured to run on embedded AS7 or something[21:05:31] <bstansberry> dmlloyd: yeah. it's actually not NewModelController.execute that's called; it's NewProxyController.execute[21:06:29] <bstansberry> lol, i forgot i'd switched branches and couldn't figure out why this code had disappeared from my ide :)[21:06:45] <bstansberry> sometimes git is a little *too* convenient[21:06:51] <dmlloyd> :)[21:10:01] <jamezp> pmuir: FYI, I know some things have changed in the deployment API since I wrote the maven plug-in. Seems to be working very oddly ATM.[21:10:22] <jamezp> I'm working on fixing it now, but just wanted to give you a heads up.[21:13:39] <bstansberry> dmlloyd: baileyje : emuckenhuber : kkhan : new-controllers is rebased to master and pushed (w/ dmlloyd's latest)[21:14:21] <baileyje> bstansberry: Ok. I am trudging through some cleanup of the add and remove ops[21:15:33] *** mmoyses has quit IRC[21:16:34] *** adietisheim has joined #jboss-as7[21:17:12] <bstansberry> yeah, that was just[21:17:21] <bstansberry> fyi[21:17:54] *** adietisheim has quit IRC[21:20:22] *** adietisheim has joined #jboss-as7[21:20:49] *** clebert has joined #jboss-as7[21:20:50] *** ChanServ sets mode: +v clebert[21:21:35] *** adietisheim has quit IRC[21:25:56] *** adietisheim has joined #jboss-as7[21:31:23] *** smcgowan has joined #jboss-as7[21:31:23] *** ChanServ sets mode: +v smcgowan[21:49:30] *** lazarotti is now known as alazarot[21:51:09] *** alazarot is now known as lazarotti[22:14:15] *** dimitris_ has quit IRC[22:28:15] *** lazarotti has quit IRC[22:38:26] *** pferraro has left #jboss-as7[22:50:51] *** alexsmirnov has quit IRC[22:53:00] *** pilhuhn has quit IRC[22:54:06] *** wolfc has quit IRC[22:55:09] *** mlinhard has quit IRC[22:57:10] *** jpederse has quit IRC[22:58:25] <jamezp> pmuir: Push a fix and the README. Test away and give me feed back :-)[23:10:07] *** alesj has quit IRC[23:10:12] *** clebert has quit IRC[23:16:35] <tdiesler> dmlloyd, I think I found the culprit.[23:17:22] <tdiesler> dmlloyd, It generally raises the question whether MSC could detect that TCCL leak.[23:17:57] *** alexsmirnov has joined #jboss-as7[23:18:19] <dmlloyd> it can't, really, however I have an enhancement to clear TCCL after each service start/stop and listener invocation.[23:18:25] <tdiesler> dmlloyd, i.e. if a service sets the TCCL without resetting it - it leaks to the next service that happs to use the same thread[23:18:51] <dmlloyd> yeah TCCL leaks have caused a large number of problems so far.[23:18:58] <tdiesler> dmlloyd, is it not an error condition?[23:19:16] <dmlloyd> I don't think it can be defined as an error[23:19:29] <dmlloyd> but it is a pretty dumb thing to do :)[23:19:36] <dmlloyd> and pretty rude![23:19:54] <dmlloyd> anyway if we clear it after each user task it should solve most issues[23:20:02] <tdiesler> dmlloyd, why not? if there is no TCCL before you call start - there should be none after you return from start[23:20:06] <dmlloyd> and we should probably configure our thread pools to do so[23:20:23] <dmlloyd> I can't guarantee that tdiesler, especially in the face of async service start/stop[23:21:38] <tdiesler> dmlloyd, I don't understand. There must be some code in msc that calls start, at this point you should not have a TCCL, right?[23:22:01] <dmlloyd> yeah you wouldn't, though we've talked about making the TCCL be equal to the service's class loader[23:22:10] <dmlloyd> which might be a desirable option[23:23:38] <tdiesler> dmlloyd, in my case its a 3rd party bug. It sets the TCCL to somthing other than the service's CL[23:24:07] <tdiesler> dmlloyd, in which case code that comes after it that assumes the service's CL would break[23:24:23] <dmlloyd> yeah I still think the solution is simply to clear the TCCL after each user task[23:24:45] <dmlloyd> the old TCP adage: be liberal in what you accept and strict in what you send[23:25:20] *** torben has quit IRC[23:27:38] *** clebert has joined #jboss-as7[23:27:38] *** ChanServ sets mode: +v clebert[23:30:09] *** rmaucher has quit IRC[23:30:29] *** rmaucher has joined #jboss-as7[23:35:06] *** rmaucher has quit IRC[23:35:32] *** rmaucher has joined #jboss-as7[23:35:46] *** rmaucher has left #jboss-as7[23:36:02] <dmlloyd> bstansberry, does the rollback-on-runtime-failure flag apply to operations which make runtime changes to the HC as well?[23:36:06] <dmlloyd> or is it server-only?[23:36:38] <bstansberry> logically it woud be both[23:36:41] *** mgoldmann has quit IRC[23:36:44] <bstansberry> would[23:36:50] <dmlloyd> okay, then I'll make that handling generic[23:43:43] *** sebersole has quit IRC[23:44:26] *** frainone has quit IRC[23:46:37] <tdiesler> dmlloyd, I created AS7-903 for you[23:46:38] <jbossbot> jira [AS7-903] 3rd party code may leak TCCL [Open (Unresolved) Bug, Major, David Lloyd] https://issues.jboss.org/browse/AS7-903[23:47:13] <dmlloyd> thanks[23:47:23] *** hulli has joined #jboss-as7[23:47:53] <jbossbot> git [jboss-as] push master e99fd5d.. Stuart Douglas Implemented proper SFSB destruction for CDI managed SFSB's[23:47:53] <jbossbot> git [jboss-as] push master 03f1bc5.. Stuart Douglas Add interceptor that throws EJBException on invocation of non-business methods[23:47:53] <jbossbot> git [jboss-as] push master 41d3761.. Stuart Douglas Remove methods from deployment descriptor[23:47:53] <jbossbot> git [jboss-as] push master 356bc0a.. Stuart Douglas env-entry fix[23:47:54] <jbossbot> git [jboss-as] push master 8a48d55.. Carlo de Wolf AS7-434: do not store model and expose a ModelControllerClient[23:47:54] <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[23:47:54] <jbossbot> git [jboss-as] push master 2db4548.. Carlo de Wolf AS7-434: add a dependency on CLASSPATH in EjbDependencyDUP[23:47:55] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/830f072...2db4548[23:48:40] <hulli> hello[23:48:40] *** kcbabo has joined #jboss-as7[23:48:40] *** ChanServ sets mode: +v kcbabo[23:49:04] <dmlloyd> tdiesler, fixed in upstream MSC[23:55:28] *** bstansberry_ has joined #jboss-as7[23:55:28] *** ChanServ sets mode: +v bstansberry_[23:56:34] *** smcgowan has quit IRC[23:56:41] *** bstansberry has quit IRC[23:56:41] *** bstansberry_ is now known as bstansberry[23:57:00] *** aslak has quit IRC[23:57:37] <dmlloyd> bstansberry: if a step declares rollback only, do we skip processing subsequent steps?[23:57:52] <dmlloyd> I'm thinking "yes" but want to make sure you think that's reasonable[23:58:08] *** emuckenhuber has quit IRC[23:58:25] * dmlloyd acknowledges his comparatively minuscule experience with op handlers[23:58:31] *** clebert has quit IRC[23:58:42] <bstansberry> hmm[23:59:24] * bstansberry thinks about rollback-only