[00:03:58] *** rawbdor has quit IRC
[00:06:03] <stuartdouglas> dmlloyd: What sort of concurrency guarantees does msc provide with respect to listeners? In particular does dependencyInstalled have a happens before relationship with serviceStarted/Failed etc?
[00:06:54] <dmlloyd> stuartdouglas: dependencyInstalled/Uninstalled is outside of the normal flow of things, however the MSC controller state cannot change as long as listeners are running
[00:07:28] <stuartdouglas> so will dependencyInstalled always happen before serviceStarted ?
[00:07:29] <dmlloyd> stuartdouglas: so, any number of listeners may be running at once, but you won't have, for example, serviceStarting and serviceStarted running at the same time under any circumstances
[00:07:53] <dmlloyd> stuartdouglas: yeah dependencyInstalled *should* prevent the service from changing state until it is finished.
[00:09:08] <rmaucher> dmlloyd, so you want to have something displayed when there is a request for the root path of a vhost and there is no root webapp ?
[00:09:38] <dmlloyd> rmaucher: yeah, just something other than a blank page
[00:09:50] <dmlloyd> some greeting page or something
[00:10:19] <rmaucher> it's the browser's fault for not displaying the status code anywhere actually
[00:10:33] <rmaucher> so what should be displayed ?
[00:10:54] <dmlloyd> some pretty "welcome to JBoss AS 7" page, at least
[00:11:08] <dmlloyd> I was thinking we could ask James Cobb and company to design something nice
[00:11:19] <rmaucher> pretty means a big HTML blob with CSS and funny embedded gifs
[00:11:20] <dmlloyd> and hopefully not too large :)
[00:11:24] <dmlloyd> yeah
[00:11:27] <rmaucher> :(
[00:13:23] <dmlloyd> what do you think?  possible?  stupid?
[00:13:27] <dmlloyd> both?
[00:13:49] <rmaucher> of course, it is possible
[00:14:31] <rmaucher> and of course, I would prefer a standard webapp
[00:15:15] <dmlloyd> that might be a possibility too, as long as we can make it so that the user doesn't have to consciously undeploy something to deploy a new root page
[00:15:25] <dmlloyd> at least, that's what I'd like to see
[00:15:32] <dmlloyd> I guess it's not that important in the grand scheme
[00:15:53] <dmlloyd> coming up with a nice initial presentation is more important
[00:16:02] *** wolfc has quit IRC
[00:17:51] <rmaucher> users are normally used to removing the default root webapp, it's been like that in all Tomchat verisons and JBoss
[00:19:05] <jamezp> Since you have the nice deployment API, you could come up with something that allows you to browse and deploy a new app then possibly undeploy itself.
[00:19:12] <jamezp> As the start page that is.
[00:19:21] <rmaucher> I have the huge hack implemented for the JSF and JSTL taglibs: https://github.com/rmaucher/jboss-as/commit/fa86cd987a4bb92ea9fab21639fffa7f9682cdac
[00:19:22] <jbossbot> git [jboss-as] fa86cd9.. Rémy Maucherat Hardcode JSF and JSTL taglibs.
[00:20:23] <rmaucher> jamezp, that would require webapp functionality, all I could provide is a static HTML page (and I will whine for days that it's a hack)
[00:20:56] <jamezp> :-)
[00:28:01] *** pferraro has quit IRC
[00:29:20] *** jpearlin has joined #jboss-as7
[00:43:26] *** balunasj has quit IRC
[00:47:29] <baileyje> rmaucher: Thanks.
[00:48:24] <dmlloyd> rmaucher: looks good, you want it merged?
[00:50:43] *** jpearlin has quit IRC
[00:55:23] *** jpearlin has joined #jboss-as7
[00:55:23] <dmlloyd> I'll take that as a "yes" :)
[00:55:23] <stuartdouglas> how often are people seeing the hangs? I only get them very occasionally, which makes debugging somewhat difficult
[00:55:31] <jbossbot> git [jboss-as] push master 7f46b25.. Rémy Maucherat Try to complete the web config.
[00:55:31] <jbossbot> git [jboss-as] push master fa86cd9.. Rémy Maucherat Hardcode JSF and JSTL taglibs.
[00:55:31] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/fccbe64...fa86cd9
[00:57:21] <dmlloyd> stuartdouglas: when I do a clean build, I hit it almost every time.
[00:57:36] <dmlloyd> stuartdouglas: when I cd into testsuite and do 'mvn test' I almost never hit it
[00:57:42] <stuartdouglas> ah
[00:58:01] <jamezp> I hit it almost everytime.
[00:58:14] <stuartdouglas> that is very odd behvaiour
[00:58:28] <rmaucher> dmlloyd, yes, thanks (I did test it, it was looking good enough)
[00:58:32] <jamezp> I guess I usually do a mvn clean first though.
[01:00:15] <jamezp> Oddly enough too it's not usually on the same test. It does vary.
[01:01:18] <jamezp> Just ran it again and it built successfully.
[01:01:38] *** smcgowan has joined #jboss-as7
[01:01:41] *** ChanServ sets mode: +v smcgowan
[01:03:42] <stuartdouglas> I'll try on my linux box...
[01:09:52] *** rmaucher has quit IRC
[01:20:40] <smcgowan> stuartdouglas:  now that we had the email exchange on the hanging tests, both Hudson jobs I referenced are now passing
[01:20:52] <stuartdouglas> yea, its very intermittent
[01:20:59] <smcgowan> i see the ManagedBeanTestCase hang locally for me
[01:21:05] <smcgowan> ok i thought so
[01:21:06] <stuartdouglas> I can only reproduce it once out of every 10-20 builds
[01:26:42] <jamezp> stuartdouglas: Have you tried mvn clean, then build.sh?
[01:27:04] <jamezp> If I do that it hangs every time.
[01:28:41] <stuartdouglas> Found it :-)
[01:28:56] <stuartdouglas> only took around 100 builds on two computers to confirm
[01:30:09] <stuartdouglas> tick() is sometimes being called before depdendencyInstalled
[01:30:32] <dmlloyd> damn
[01:30:42] <stuartdouglas> still needs a little bit more investigation, but at least now I know where the problem is
[01:31:00] <stuartdouglas> thinking about it, that could actually make sense in the case of dependencyFailed
[01:31:38] <stuartdouglas> but I need to check and see exactly what operation is calling tick
[01:31:49] <stuartdouglas> cause I did not think to put that in my debug output
[01:31:53] <stuartdouglas> :-(
[01:35:46] <stuartdouglas> It looks like started is being called before depdencyInstalled
[01:36:22] <stuartdouglas> looking at the MSC code it looks like depdencyInstalled is called asynchronously, is that correct?
[01:36:53] <stuartdouglas> and if so, it this the expected MSC behaviour?
[01:37:40] <stuartdouglas> I can work around it by being much more defensive in the Listener, but if it is a MSC but it would be better to fix it there
[01:37:53] <stuartdouglas> dmlloyd: ^
[01:38:32] <dmlloyd> all listeners are called asynchronously with respect to the thread which initiated the state change
[01:38:45] <dmlloyd> however like I said, as long as there are listeners running, the state machine is "frozen" in time
[01:40:43] <stuartdouglas> can the state change occur when the listeners are queud before they start running?
[01:40:51] <dmlloyd> no
[01:41:50] <stuartdouglas> In that case this is probably a MSC bug then
[01:42:09] <dmlloyd> you sure that started is called then dependencyInstalled on the same controller instance?
[01:42:19] <dmlloyd> or is it startING?
[01:42:48] <dmlloyd> the same action can cause both starting and dependencyInstalled to be called in the same "bunch"
[01:42:59] <dmlloyd> i.e. the last missing dependency arrives
[01:44:40] <stuartdouglas> actually I am not 100% sure
[01:45:45] <stuartdouglas> looking at the last run, dependencyInstalled is actually called first, but depedencyUninstalled has not been called first
[01:46:19] <stuartdouglas> in the case of both in the same 'bunch' will MSC have multiple invocations on the listener at the same time?
[01:47:30] <stuartdouglas> and if there are two services being installed in the same bunch, and service 1 has a dep on service 2
[01:47:54] <stuartdouglas> is the following sequence possible:
[01:48:23] <stuartdouglas> service 1 installed, as service2 is not installed yet, so service1 get a dependencyUninstalled task set up
[01:48:44] <stuartdouglas> service 2 is installed, so service 1 gets a dependencyInstalled task set up
[01:49:26] <stuartdouglas> as they are invoked asynchronously, dependencyInstalled gets called before dependencyUninstalled ?
[01:49:37] <stuartdouglas> or at the same time
[01:51:13] <stuartdouglas> because if I had to guess, I would say that is what is happening in this case
[01:52:46] *** jamezp has left #jboss-as7
[01:54:44] *** asaldhan has quit IRC
[01:56:10] *** pferraro has joined #jboss-as7
[01:56:10] *** ChanServ sets mode: +v pferraro
[02:03:52] <dmlloyd> well I think I've carried JBAS-8978 as far as my little legs can carry it
[02:03:53] <jbossbot> jira [JBAS-8978] Complete async EJB invocation [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8978
[02:04:13] <dmlloyd> can probably get that wrapped up with some help from Jaikiran in the morning
[02:06:04] <stuartdouglas> this is weird, now I am seeing depedencyUninstalled being called twice
[02:08:36] *** asaldhan has joined #jboss-as7
[02:09:36] *** jamezp has joined #jboss-as7
[02:11:54] *** pferraro has quit IRC
[02:17:22] <dmlloyd> I suppose it should come as no surprise to me that there is no simple Service<ResourceAdapter> for resource adapters deployed in .rars
[02:17:32] <dmlloyd> that would make MDB implementation just too easy
[02:27:31] <dmlloyd> I don't understand why there isn't - it seems like a perfect fit
[02:27:44] <dmlloyd> MSC calls ResourceAdapter.start() on start, and .stop() on stop
[02:27:47] <baileyje> Sooooo weird..
[02:27:58] <baileyje> I have a file called "com.sun.faces.spi.annotationprovider "
[02:28:18] <baileyje> When it puts it in the jar it changes it to "com.sun.faces.spi.AnnotationProvider"
[02:28:26] <dmlloyd> there'd be an outward Injector<ActivationThinger> into which you inject an MessageEndpointFactory+ActivationSpec to activate, and uninject to deactivate
[02:28:28] <dmlloyd> would work a charm
[02:28:40] <dmlloyd> baileyje, you must have both files
[02:28:57] <dmlloyd> else the JAR is being updated rather than overwritten
[02:29:12] <dmlloyd> else you have that file in your target dir and due to OS filesystem when it recrates it keeps the old name
[02:31:25] <stuartdouglas> I have a potential fix for the hang issue at https://github.com/stuartwdouglas/jboss-as/tree/hang
[02:31:28] <stuartdouglas> testing it now
[02:31:43] <stuartdouglas> It is kinda ugly :-(
[02:32:40] <stuartdouglas> and I have no idea why but dependencyInstalled and dependencyUnistalled seem to potentially be invoked many times for the same service
[02:32:47] <stuartdouglas> and not nessesarily in order
[02:33:57] <stuartdouglas> oops, there is a bug in it
[02:33:59] <baileyje> dmlloyd: Not sure.  Blew it all away and it seemed to work again
[02:35:13] <dmlloyd> stuartdouglas: well if dependencies come and go rapidly it could cause that, I guess... because they'd all be called asynchronously w.r.t. each other... otherwise I'd classify that behavior as "wrong"
[02:35:26] <dmlloyd> because I can't imagine why dependencies would come and go rapidly
[02:35:41] <stuartdouglas> neither can I
[02:36:03] <dmlloyd> ah I have an idea of what might be happening
[02:36:21] <dmlloyd> say you have a dependency chain A->B->C->D where -> == "depends on"
[02:36:28] <dmlloyd> you install A, it has a missing dep on B
[02:36:39] <dmlloyd> then you install B, dep is satisfied but then C is missing so it's not anymore
[02:36:49] <dmlloyd> then you install C, dep is satisfied then D is missing
[02:36:56] <dmlloyd> then you install D and it comes up "for good"
[02:37:09] <stuartdouglas> ah, and because they are async they appear to run in no particular order
[02:37:26] <dmlloyd> that's just a hypothesis though - the code should protect against that because services default to assuming their deps are uninstalled (I think!)
[02:37:44] <dmlloyd> but I can check that with frainone - she did a lot on that code recently so she'll remember how it all is supposed to work
[02:38:08] <stuartdouglas> For now I will code the listener much more defensivly
[02:38:18] <stuartdouglas> until this can be investigated further
[02:45:04] *** bgeorges has joined #jboss-as7
[02:45:04] *** ChanServ sets mode: +v bgeorges
[02:50:05] <stuartdouglas> dmlloyd: can you merge my master
[02:50:22] <stuartdouglas> I have stopped attempting to track unsatisfied dependencies for now
[02:51:11] <stuartdouglas> Which fixes the hangs as far as I can tell, however it also means that the tests will hang if there is an unsatisfied dep
[02:51:34] <stuartdouglas> which I think we can live with for the moment
[02:54:46] <dmlloyd> yay no hangs
[02:54:57] <dmlloyd> yeah better than hanging pretty much always
[02:55:11] <jbossbot> git [jboss-as] push master 352aae2.. Stuart Douglas Fix weld ARQ bug
[02:55:11] <jbossbot> git [jboss-as] push master af20286.. Stuart Douglas Change SessionObjectReferenceImpl to get the sessionId eagerly
[02:55:12] <jbossbot> git [jboss-as] push master 7096d6a.. Stuart Douglas JBAS-8940 Run manifest processor twice, the first time for OSGI, the second time for additional resource roots.
[02:55:13] <jbossbot> jira [JBAS-8940] OSGi webapps processed by web subsystem [Reopened (Unresolved) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-8940
[02:55:13] <jbossbot> git [jboss-as] push master 4907171.. Stuart Douglas Stop attempting to track unsatisfied dependencies to fix hang
[02:55:13] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/fa86cd9...4907171
[02:55:30] <dmlloyd> guess we fixed a bunch of stuff eh :)
[02:55:51] <stuartdouglas> yea, there were a few other fixes
[02:56:27] <stuartdouglas> can everyone confirm that they no longer get hangs?
[02:56:58] <stuartdouglas> My laptop has been building in a loop for a while, and I have not seen any
[02:57:50] *** JimMa has joined #jboss-as7
[03:02:10] *** frainone has joined #jboss-as7
[03:02:10] *** ChanServ sets mode: +v frainone
[03:14:02] <baileyje> dmlloyd: This jsf module is going to have to be a subsystem if it has processors.
[03:15:04] <dmlloyd> could just wedge the processor in with the web subsystem couldn't you?
[03:15:22] <baileyje> I could.  Or move all the stuff in their.
[03:15:25] <baileyje> there
[03:15:43] <baileyje> It is going to be two classes and a service descriptor.
[03:16:02] <baileyje> it just adds a dep from web -> jsf-impl
[03:16:12] <dmlloyd> yeah I suppose that makes sense
[03:16:16] <baileyje> if I make it a subsystem, then I have all kinds of stuff
[03:16:17] <dmlloyd> kinda simplifies the whole deal
[03:18:16] *** bstans_afk has quit IRC
[03:22:49] *** asaldhan has left #jboss-as7
[03:32:10] *** pferraro has joined #jboss-as7
[03:32:10] *** ChanServ sets mode: +v pferraro
[03:35:05] *** pferraro has left #jboss-as7
[03:42:46] *** jpearlin has quit IRC
[03:51:34] <baileyje> dmlloyd: Ok. I have it working.  I have to run for the night.  I will get it cleaned and have you check it out in the morning..
[03:51:46] <dmlloyd> cool
[03:51:56] <baileyje> pretty simple.
[03:52:17] <baileyje> If I only hadn't burned 2+hours trying to figure out the weird jar entry issue
[03:52:36] <baileyje> I had to dig all the way through the module resource load to figure that out..
[03:52:46] <baileyje> I blame Sun.
[03:52:53] <baileyje> What do they not follow their own pattern.
[03:53:04] <baileyje> Using all lower case for the service marker file
[03:53:14] <dmlloyd> that's fairly dastardly
[03:53:33] <baileyje> anyway, I will get it to you in the AM
[03:53:39] <smcgowan> stuartdouglas:  seeing your comment above about running tests, i kicked off another hudson test run which resulted in two failures:
[03:53:42] <smcgowan> http://hudson.jboss.org/hudson/job/JBoss-AS-7.0.x-testSuite-sun16/lastCompletedBuild/testReport/
[03:54:02] <dmlloyd> sounds good baileyje
[03:54:06] <dmlloyd> thanks dude
[03:54:24] <stuartdouglas> smcgowan: I will look into it
[03:54:36] <smcgowan> are those different than the "classloading" tests brian refers to here: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-March/000763.html
[03:54:37] <stuartdouglas> have you had any hangs since my patch?
[03:54:42] <smcgowan> no hang
[03:54:49] <smcgowan> i ran locally too
[03:54:52] <stuartdouglas> no, they are the same ones
[03:54:56] <stuartdouglas> they were working
[03:57:31] <dmlloyd> maybe the recent change to TLD class-path somehow did it in
[03:57:42] *** jamezp is now known as jamezp_afk
[03:58:05] <stuartdouglas> could be
[03:59:56] <stuartdouglas> dmlloyd: I have done JBAS-9044 in my master
[03:59:57] <jbossbot> jira [JBAS-9044] Merge managedbeans subsystem into ee subsystem [Open (Unresolved) Task, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9044
[04:00:17] <dmlloyd> nice
[04:00:50] <smcgowan> dmlloyd:  the previous test suite run included remy's commit and the tests passed: http://hudson.jboss.org/hudson/job/JBoss-AS-7.0.x-testSuite-sun16/3/
[04:01:48] <dmlloyd> hm interesting
[04:02:25] <smcgowan> i'm gonna get some sleep - catch you all tomorrow
[04:02:32] *** smcgowan has quit IRC
[04:03:03] <stuartdouglas> could be my manifest changes
[04:03:52] <stuartdouglas> although I can't see how
[04:11:56] <jbossbot> git [jboss-as] push master e6c0479.. Stuart Douglas Remove managed beans subsystem
[04:11:56] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/4907171...e6c0479
[04:18:01] <dmlloyd> man we got a buttload of bad/useless maven deps
[04:18:08] <dmlloyd> no wonder people complain about slow builds
[04:18:15] <dmlloyd> might be time to go an an <exclusions> rampage soon
[04:18:41] <stuartdouglas> I never did get around to writing the transitive dep enforcer
[04:20:53] <smarlow> dmlloyd:  regarding JBAS-9040, I think its pretty reasonable for users to place all of the persistence providers on the classpath for any application to use (in terms of the approach that I think we are competing against with whatever we do).  If we have a system configuration file that identifies all of the supported persistence providers, we could (statically) do something similar (except maybe we could inject the provider jar onto the deploym
[04:20:53] <smarlow> ents classpath).  There is also an OSGI JPA scheme that allows for multiple providers (I think  each one is represented by an OSGI Persistence Provider service).
[04:20:53] *** jamezp_afk has quit IRC
[04:20:55] <jbossbot> jira [JBAS-9040] Support for pluggable JPA providers [Open (Unresolved) Sub-task, Major, Scott Marlow] https://issues.jboss.org/browse/JBAS-9040
[04:22:18] <dmlloyd> ok then why don't we do what we are doing for JDBC drivers and detect services/javax.persistence.spi.PersistenceProvider
[04:22:48] <dmlloyd> though I must say, like JDBC drivers, we should consider scoping for such deployments that are included inside of an EAR
[04:23:56] <smarlow> I wasn't online when we last changed how JDBC drivers worked a few days ago :)
[04:24:23] <smarlow> but, I like the idea of making persistent providers work, like something we already have.
[04:25:43] <smarlow> dmlloyd:  would we deploy the provider like you suggested earlier?
[04:26:26] <dmlloyd> yeah drop it in as a TLD and the whole AS can use it
[04:26:53] <dmlloyd> the service registry would necessarily be different though especially since providers are identified by class name
[04:30:26] *** jamezp has joined #jboss-as7
[04:36:17] <smarlow> dmlloyd:  how is that working for JDBC drivers?  Are we looking for the presence of the java.sql.Driver implementation?
[04:36:26] *** irooskov has quit IRC
[04:37:05] <dmlloyd> smarlow, yeah, specifically META-INF/services/java.sql.Driver
[04:37:13] <dmlloyd> or whatever the interface name is
[04:52:25] *** frainone has quit IRC
[05:11:01] *** bgeorges has quit IRC
[05:13:04] *** bgeorges has joined #jboss-as7
[05:13:04] *** ChanServ sets mode: +v bgeorges
[05:16:43] <dmlloyd> didn't someone else just run into this same issue recently:
[05:16:45] <dmlloyd> Caused by: java.lang.ClassNotFoundException: javax.enterprise.inject.CreationException from [Module "org.jboss.as.arquillian.protocol.servlet:main" from local module loader @64482923 (roots: /home/david/src/java/as7/jboss-as/testsuite/smoke/target/modules,/home/david/src/java/as7/jboss-as/testsuite/smoke/../../build/target/jboss-7.0.0.Beta2/modules)]
[05:16:56] <dmlloyd> seems really damned familiar
[05:17:46] <aslak> dmlloyd, yea, wolfc has a thread on it on the as7 list.
[05:18:24] <aslak> dmlloyd, basically the deserializer of the exception is using the wrong cl
[05:18:25] <dmlloyd> hmm yeah
[05:18:58] <dmlloyd> wonder why that's happening now for JSF - or maybe it was happening all along but because jsfunit was a big ball-o-mud module it didn't matter...
[05:20:15] <ALR> dmlloyd: Yes.
[05:20:21] <ALR> Anil had it earlier today
[05:20:35] <ALR> Oh yeah, Carlo even earlier than that
[05:20:49] <ALR> CNFE.  Anil had CNFE because he misspelled his Servlet.
[05:21:01] <dmlloyd> heh yeah
[05:21:36] <dmlloyd> ruh roh, my org.jboss.as.test.embedded.demos.managedbean.ManagedBeanTestCase seems to be hung
[05:23:06] *** smarlow has quit IRC
[05:25:37] <stuartdouglas> dmlloyd: where is it hanging? The same place as before?
[05:25:38] *** jamezp has quit IRC
[05:26:02] <dmlloyd> it's hard to ascertain, I'm trying to figure it out
[05:26:38] <dmlloyd> all services seem to be up
[05:26:45] <dmlloyd> it might be a glitch in the tester
[05:27:02] <dmlloyd> trying to get a thread dump
[05:27:12] *** jamezp has joined #jboss-as7
[05:28:02] <dmlloyd> no server.log of course :|
[05:28:28] <dmlloyd> ah I don't have the hang fixes
[05:28:33] <dmlloyd> gotta rebase this shit
[05:30:47] <stuartdouglas> that would explain it :-)
[05:31:17] <dmlloyd> I hope stan appreciates how much time I'm putting into this issue (JBAS-9000) :)
[05:31:19] <jbossbot> jira [JBAS-9000] Multiple "xalan" are present and other JSFUnit problems [Open (Unresolved) Bug, Critical, David Lloyd] https://issues.jboss.org/browse/JBAS-9000
[05:31:52] <dmlloyd> had to use tattletale to unwind all the deps
[05:32:07] <stuartdouglas> hehe, I 'fixed' some JSFunit problems the other day just by changing it provided scope
[06:06:59] <dmlloyd> wtf is a "manifest resource" in Archive.addManifestResource
[06:07:13] <dmlloyd> do they mean a meta-inf resource?
[06:08:00] <stuartdouglas> res
[06:08:01] <stuartdouglas> yes
[06:08:15] <baileyje> dmlloyd: You are a machine.
[06:08:59] <dmlloyd> baileyje, how is it that we've ended up doing all the hard parts of JSF implementation :)
[06:09:11] <baileyje> ha..
[06:09:42] <dmlloyd> hmm Archive has no simple way to add manifest attributes.  That's annoying.
[06:10:00] <baileyje> We are like assassins.   We take out whatever is needed
[06:10:01] <dmlloyd> this example deployment apparently needs some module deps.
[06:13:13] <baileyje> Generally I think we should avoid that.
[06:13:35] <baileyje> If it needs the modules based on the deployment type or the subsystem, then the deployment should add the deps.
[06:14:03] <baileyje> If it is like this test deployment I am looking at and it needs SLF4J or something that is the deployments responsibility to provide.
[06:14:20] <dmlloyd> not sure what else to make of this exception though
[06:14:23] <baileyje> WHich of course they can do from a classloading descriptor.
[06:14:54] <dmlloyd> http://fpaste.org/BGhq/
[06:15:07] <dmlloyd> tbh it might be a transitive
[06:15:20] <dmlloyd> jsfunit does import htmlunit though
[06:16:45] <baileyje> It seems like it should
[06:17:03] <baileyje> or is it selecting the class based on some config prop or something
[06:17:30] <dmlloyd> dunno, the line at 107 looks like it's trying to load BrowserVersion from the deployment
[06:17:49] <dmlloyd> but the line 90 exception pretty clearly looks like a linkage error from jsfunit
[06:17:57] <dmlloyd> it's kinda weird
[06:26:34] <baileyje> dmlloyd: https://github.com/baileyje/jboss-as/commit/8ee5213ffa1d4285c16a72e896468141a100daf4
[06:26:35] <jbossbot> git [jboss-as] 8ee5213.. John E. Bailey Provide a custom JSF AnnotationProvider which uses the jandex index to find required annotations
[06:26:50] <dmlloyd> argh.  He's somehow duplicated the jsfunit classes in the deployment
[06:26:53] * dmlloyd head -> desk
[06:28:57] <baileyje> ahhhhh..  doh
[06:29:19] <baileyje> I have to get to bed.  I will talk to you in the morning.
[06:29:19] <dmlloyd> I can't even see how he's done it though, that's what's really messing me up here
[06:29:24] <dmlloyd> ok have a good night
[06:29:28] <dmlloyd> I'll merge your stuff after mine
[06:29:40] <baileyje> sorry you have been working a gazzillion hours..
[06:29:55] <dmlloyd> meh.  this is the first day this week I've really put in a lot
[06:30:31] <baileyje> alright.  Talk to you tomorrow.
[06:30:42] <dmlloyd> later
[07:00:20] <dmlloyd> man these tests kinda suck
[07:01:55] <stuartdouglas> I noticed that today as well, -Dmaven.surefire.debug does though (or it used to)
[07:02:09] <dmlloyd> ooo, I'll try that...
[07:02:25] <stuartdouglas> there are like three different runs though
[07:02:31] <dmlloyd> yeah
[07:02:39] <dmlloyd> well I'm hoping I can use -Dtest at the same time...
[07:02:48] <dmlloyd> probably expecting too much though
[07:03:05] * stuartdouglas does not have much faith in -Dtest
[07:04:52] <dmlloyd> hmm but what port does it listen on
[07:05:18] <stuartdouglas> 5005
[07:05:19] *** JimMa has quit IRC
[07:05:26] <dmlloyd> oh, ok
[07:05:57] <dmlloyd> bah get the same thing: Caused by: java.lang.IllegalStateException: Cannot find system property: jboss.home
[07:06:05] <dmlloyd> will try without -Dtest
[07:06:26] <dmlloyd> maybe, I"ll try it the slow way first
[07:07:53] <dmlloyd> whew
[07:07:57] <dmlloyd> thank god my breakpoint fired
[07:08:02] <dmlloyd> wasn't sure it was going to :)
[07:10:40] <dmlloyd> I *knew* it! the classes have been copied into the deployment
[07:10:46] <dmlloyd> man, what a pain in the ass.
[07:10:59] <dmlloyd> this whole thing is insane
[07:11:01] <stuartdouglas> which classes into what deployment?
[07:11:13] <dmlloyd> this JSF test deployment
[07:11:24] <dmlloyd> all the classes from like jsfunit and stuff were copied into the deployment
[07:11:28] *** aslak has quit IRC
[07:11:37] <dmlloyd> so half of the deps aren't working
[07:12:13] <dmlloyd> the thing that kills me I can't tell where it's happening
[07:12:47] <stuartdouglas> At a guess JBossASDeploymentPackager
[07:13:27] <dmlloyd> it's almost acting as if the deps in the /modules/jsf-arquillian-module-def.xml are being ignored
[07:14:10] <stuartdouglas> arq generates auxiliary archives, that in some cases should be added to the deployment, and in some cases ignored
[07:14:48] <stuartdouglas> for other containers this is fine, because they do not have all the test classes as part of the container like we do
[07:15:15] <dmlloyd> if we always bundle this shit in with test deployments then why are we also distributing many of the same artifacts as modules
[07:15:23] <dmlloyd> it's bound to blow up
[07:15:45] <stuartdouglas> JBossASDeploymentPackager .excludedAuxillaryArchives can be used to exclude them from the deployment
[07:16:33] <dmlloyd> is that something the test case should do somehow?
[07:16:34] <stuartdouglas> I am not 100% sure about the why of it all, arq operates quite differently in AS7 to other containers
[07:17:20] <stuartdouglas> no, it's hard coded at the moment
[07:17:35] <stuartdouglas> which is fine, as the stuff that should be excluded is the stuff that is bundled by the container
[07:18:00] *** jamezp has quit IRC
[07:19:18] <dmlloyd> well, I'm going to bed.  The big pile of shit is at http://github.com/dmlloyd/jboss-as/commit/9a8e25c if you wanna play with it
[07:19:19] <jbossbot> git [jboss-as] 9a8e25c.. David M. Lloyd [JBAS-9000] Fix JSFUnit modularity issues
[07:19:21] <jbossbot> jira [JBAS-9000] Multiple "xalan" are present and other JSFUnit problems [Open (Unresolved) Bug, Critical, David Lloyd] https://issues.jboss.org/browse/JBAS-9000
[07:21:59] *** JimMa has joined #jboss-as7
[07:28:26] *** miclorb_ has quit IRC
[07:39:10] <stuartdouglas> dmlloyd: just for when you wake up, the classes are being added by JSFUnitApplicationArchiveProcessor
[07:40:17] <stuartdouglas> It looks like those added classes expect other classes to be there
[07:40:33] <stuartdouglas> these other classes are mean't to be added by JSFUnitArchiveAppender
[07:41:07] <stuartdouglas> however as there is no META-INF/services file for JSFUnitArchiveAppender, they are not being added
[07:41:21] <stuartdouglas> and the whole thing falls apart in a screaming heap
[07:57:52] *** opalka has joined #jboss-as7
[07:57:52] *** opalka has joined #jboss-as7
[07:57:52] *** ChanServ sets mode: +v opalka
[07:58:23] *** Jaikiran has joined #jboss-as7
[07:58:23] *** ChanServ sets mode: +v Jaikiran
[07:58:54] <opalka> morning
[08:01:03] *** JimMa has quit IRC
[08:11:50] <Jaikiran> stuartdouglas: you around?
[08:12:09] <stuartdouglas> Jaikiran: yes
[08:12:21] <Jaikiran> stuartdouglas: regarding JBAS-9047
[08:12:22] <jbossbot> jira [JBAS-9047] WarAnnotationDeploymentProcessor runs later than it should [Open (Unresolved) Bug, Major, Remy Maucherat] https://issues.jboss.org/browse/JBAS-9047
[08:12:28] <stuartdouglas> yes?
[08:12:48] <Jaikiran> isn't EE component install deployers supposed to run in INSTALL phase?
[08:13:21] <stuartdouglas> hmm, I think I worded the issue badly
[08:13:22] <Jaikiran> and the annotation processing DUPs (even when using Jandex) be run in POST_MODULE phase?
[08:13:38] <stuartdouglas> it's stuff like the resource injection annotation processors that should run in Parse
[08:14:34] <stuartdouglas> I am pretty sure dmlloyd wants them to be in parse, I moved them to POST_MODULE to get web component stuff working
[08:14:43] <stuartdouglas> but it was only mean't to be temporary
[08:15:39] * Jaikiran is checking WarAnnotationParsingDUP to see why the order matters for ResourceInjectionDUP
[08:16:46] <stuartdouglas> because it picks up services
[08:16:56] <stuartdouglas> so to do @Resource injection for the servlet
[08:17:07] <stuartdouglas> you need WarAnnotationParsingDUP to pick up the servlet first
[08:17:50] *** JimMa has joined #jboss-as7
[08:19:50] *** jfclere has joined #jboss-as7
[08:19:50] *** ChanServ sets mode: +v jfclere
[08:20:12] <Jaikiran> hmm yeah, i get it now
[08:20:25] <Jaikiran> i was just curious because we have EJB annotation processing DUPs in POST_MODULE
[08:20:58] <stuartdouglas> does it use jandex or load the classes?
[08:21:44] <Jaikiran> it uses jandex
[08:21:48] <Jaikiran> but in our case it doesn't matter
[08:22:08] <Jaikiran> because we create the necessary *ComponentDescriptions pretty early via a different DUP in PARSE phase
[08:22:20] <Jaikiran> so we have something like N annotaiton processing DUPs for EJB
[08:22:42] <stuartdouglas> I am not sure if there is really any harm in having it in POST_MODULE
[08:22:50] <Jaikiran> the top level annotations like @Stateless are picked up by 1 DUP which runs in PARSE and creates the necessary component description
[08:22:51] <stuartdouglas> but you would have to ask dmlloyd
[08:23:12] <Jaikiran> and the rest of the annotation processing DUPs run in POST_MODULE (although they perhaps can run in PARSE too)
[08:23:36] <Jaikiran> yeah, will ping dmlloyd later tonight
[08:23:49] <Jaikiran> thanks for the explanation, though
[08:28:12] <ALR> stuartdouglas: Feel free to tell me if I've missed some stuff currently already accounted for in the AS7 testsuite email I just sent out.
[08:28:22] <ALR> Consider me "new" to the team. :)
[08:28:36] <ALR> My main goal is to define purpose for and reorg the AS7 suite.
[08:28:47] <ALR> Drawing lines of responsibility where appropriate.
[08:28:54] <stuartdouglas> I will have a read
[08:29:03] <stuartdouglas> what we have in there at the moment is pretty basic
[08:29:27] <stuartdouglas> I just did some simple class loading tests that did not really belong in smoke, so I put them there
[08:29:34] <ALR> Yup Saw that.
[08:29:39] <ALR> And also "tests" package
[08:29:45] <ALR> For ClassLoading of EAR, RAR, etc
[08:29:48] <ALR> Which are great
[08:29:58] <ALR> Just IMO should move to something elsewhere focused on internals testing.
[08:44:26] <stuartdouglas> dmlloyd: I think the solution to the current problem with your JSF stuff is in org.jboss.as.arquillian.container.ModuleApplicationArchiveProcessor
[08:44:41] <stuartdouglas> jsfunit needs more dependencies added
[08:44:50] <stuartdouglas> I will try and fix it tonight, but I may not get time
[08:59:36] *** jcosta has joined #jboss-as7
[08:59:46] *** emuckenhuber has quit IRC
[09:01:12] *** slaboure has joined #jboss-as7
[09:18:46] *** pil-dinner is now known as pilhuhn
[09:21:02] <stuartdouglas> dmlloyd: https://github.com/stuartwdouglas/jboss-as/tree/jsfunit should fix your jsfunit problems
[09:34:12] *** emuckenhuber has joined #jboss-as7
[09:34:12] *** ChanServ sets mode: +v emuckenhuber
[09:34:14] *** Jaikiran has quit IRC
[09:34:43] *** rmaucher has joined #jboss-as7
[09:51:41] *** alesj has joined #jboss-as7
[09:51:53] *** ALR has quit IRC
[09:52:47] *** aloubyansky has quit IRC
[09:53:29] *** torben has joined #jboss-as7
[09:53:30] *** torben has joined #jboss-as7
[09:53:30] *** ChanServ sets mode: +v torben
[09:55:38] *** torben_ has joined #jboss-as7
[09:56:07] *** torben_ has quit IRC
[10:02:35] *** emmanuel has joined #jboss-as7
[10:02:35] *** ChanServ sets mode: +v emmanuel
[10:10:58] *** AndyTaylor has joined #jboss-as7
[10:10:58] *** ChanServ sets mode: +v AndyTaylor
[10:16:06] *** Jaikiran has joined #jboss-as7
[10:16:06] *** ChanServ sets mode: +v Jaikiran
[10:19:07] <rmaucher> Can you pull this ? https://github.com/rmaucher/jboss-as/commit/b0d0a3449328691d267532da68596bea41921a23
[10:19:08] <jbossbot> git [jboss-as] b0d0a34.. Rémy Maucherat Remove dead code.
[10:21:08] *** adietisheim has joined #jboss-as7
[10:24:31] *** aloubyansky has joined #jboss-as7
[10:24:31] *** ChanServ sets mode: +v aloubyansky
[10:31:56] *** aloubyansky has quit IRC
[10:41:04] *** wolfc has joined #jboss-as7
[10:41:04] *** ChanServ sets mode: +v wolfc
[11:08:58] *** bgeorges has quit IRC
[11:17:19] *** miclorb has joined #jboss-as7
[11:18:32] *** jhalli_gone is now known as jhalliday
[11:18:36] *** maeste has joined #jboss-as7
[11:18:36] *** ChanServ sets mode: +v maeste
[11:23:12] *** JimMa has quit IRC
[11:24:37] *** jwulf has quit IRC
[11:25:29] *** ALR has joined #jboss-as7
[11:25:29] *** ChanServ sets mode: +v ALR
[11:29:20] *** ALR has quit IRC
[11:50:08] *** Jaikiran1 has joined #jboss-as7
[11:50:18] *** Jaikiran1 has quit IRC
[11:51:03] *** Jaikiran has quit IRC
[11:51:35] *** Jaikiran has joined #jboss-as7
[11:51:35] *** ChanServ sets mode: +v Jaikiran
[11:55:21] *** ALR has joined #jboss-as7
[11:55:22] *** ChanServ sets mode: +v ALR
[12:03:21] *** emmanuel has quit IRC
[12:15:08] *** hbraun has joined #jboss-as7
[12:16:56] *** stansilvert has joined #jboss-as7
[12:26:07] *** epbernard has joined #jboss-as7
[12:26:07] *** epbernard is now known as emmanuel
[12:26:07] *** ChanServ sets mode: +v emmanuel
[12:45:19] *** ALR has quit IRC
[12:48:04] *** mbg has joined #jboss-as7
[12:48:04] *** ChanServ sets mode: +v mbg
[12:54:56] *** smarlow has joined #jboss-as7
[12:54:57] *** ChanServ sets mode: +v smarlow
[12:57:13] *** bgeorges has joined #jboss-as7
[12:59:52] *** bgeorges has quit IRC
[13:01:59] <stuartdouglas> dmlloyd: I put the rename module jira fixes into that jsfunit branch
[13:03:33] *** torben has quit IRC
[13:04:11] *** opalka has quit IRC
[13:25:09] *** miclorb has quit IRC
[13:40:10] <smarlow> stuartdouglas, rmaucher : I think that you had some POST_MODULE stuff that might move back to PARSE phase, if rmaucher moves some of his stuff to PARSE as well.  Any idea if this is going to happen in this release?  I have a DEPENDENCIES phase processor that now needs to run after my one POST_MODULE processor.
[13:41:10] <smarlow> I would prefer to move my POST_MODULE processor to PARSE, where it belongs
[13:42:25] <smarlow> stuartdouglas:  hmm, this is the JPAAnnotationParseProcessor that I want to move to PARSE.  I wonder if switching to use AbstractComponentConfigProcessor, as you suggested would help?
[13:43:27] <smarlow> I think the underlying issue, was that you created the Attachments.COMPOSITE_ANNOTATION_INDEX during POST_MODULE because something in WEB, wasn't available until then
[13:47:03] *** mmoyses has joined #jboss-as7
[13:47:03] *** ChanServ sets mode: +v mmoyses
[13:52:39] *** pferraro has joined #jboss-as7
[13:52:39] *** ChanServ sets mode: +v pferraro
[13:53:12] *** aslak has joined #jboss-as7
[13:53:12] *** aslak has joined #jboss-as7
[13:53:12] *** ChanServ sets mode: +v aslak
[13:56:52] *** balunasj has joined #jboss-as7
[13:56:52] *** balunasj has joined #jboss-as7
[13:56:52] *** ChanServ sets mode: +v balunasj
[14:04:08] <smarlow> stuartdouglas:  the above is for JBAS-9034
[14:04:15] <jbossbot> jira [JBAS-9034] Applications should be able to inject a persistence context/unit from a separate deployment by using a fully scoped (appname#puname) reference [Open (Unresolved) Sub-task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9034
[14:09:37] *** opalka has joined #jboss-as7
[14:09:37] *** opalka has joined #jboss-as7
[14:09:37] *** ChanServ sets mode: +v opalka
[14:11:22] *** torben has joined #jboss-as7
[14:11:22] *** ChanServ sets mode: +v torben
[14:14:20] *** sannegrinovero has joined #jboss-as7
[14:14:20] *** ChanServ sets mode: +v sannegrinovero
[14:14:31] *** torben has quit IRC
[14:25:21] *** torben has joined #jboss-as7
[14:25:21] *** ChanServ sets mode: +v torben
[14:25:49] *** torben has quit IRC
[14:28:13] *** bobmcw has quit IRC
[14:31:43] *** bobmcw has joined #jboss-as7
[14:31:48] *** bobmcw has quit IRC
[14:31:48] *** bobmcw has joined #jboss-as7
[14:31:48] *** ChanServ sets mode: +v bobmcw
[14:32:54] *** pgier has joined #jboss-as7
[14:32:54] *** ChanServ sets mode: +v pgier
[14:36:48] *** smarlow has quit IRC
[14:38:18] *** balunasj is now known as balunasj_busy
[14:40:54] *** frainone has joined #jboss-as7
[14:40:54] *** ChanServ sets mode: +v frainone
[14:40:59] *** torben has joined #jboss-as7
[14:41:00] *** ChanServ sets mode: +v torben
[14:41:30] *** torben has quit IRC
[14:46:14] *** smarlow has joined #jboss-as7
[14:46:14] *** ChanServ sets mode: +v smarlow
[14:50:19] *** asaldhan has joined #jboss-as7
[14:50:19] *** ChanServ sets mode: +v asaldhan
[14:53:19] *** bstansberry has joined #jboss-as7
[14:53:19] *** ChanServ sets mode: +v bstansberry
[15:05:49] *** AndyTaylor has quit IRC
[15:07:23] <wolfc> Jaikiran, I have https://github.com/wolfc/jboss-as/commit/150c36807fdc9382dd98d3a1da14d6fadc0c73ab as a work-around
[15:07:24] <jbossbot> git [jboss-as] 150c368.. Carlo de Wolf JBAS-9055: allow @AccessTimeout on SFSB (Q&D)
[15:07:25] <jbossbot> jira [JBAS-9055] Cleanup @AccessTimeout processing [Open (Unresolved) Task, Major, jaikiran pai] https://issues.jboss.org/browse/JBAS-9055
[15:08:14] *** smcgowan has joined #jboss-as7
[15:08:14] *** ChanServ sets mode: +v smcgowan
[15:11:36] <dmlloyd> thanks stuartdouglas
[15:12:29] <dmlloyd> rmaucher: will look at it asap
[15:13:43] <dmlloyd> Jaikiran: yes, we want annotation processing during PARSE phase.  It may matter later on if other processors expect a complete component list for example.
[15:14:01] <dmlloyd> I wouldn't be surprised if other processors already are, in fact.
[15:17:08] <Jaikiran> bstansberry: fyi JBAS-9051 when you are around
[15:17:09] <jbossbot> jira [JBAS-9051] FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/JBAS-9051
[15:17:52] <jbossbot> git [jboss-as] push master 9a8e25c.. David M. Lloyd [JBAS-9000] Fix JSFUnit modularity issues
[15:17:53] <jbossbot> jira [JBAS-9000] Multiple "xalan" are present and other JSFUnit problems [Open (Unresolved) Bug, Critical, David Lloyd] https://issues.jboss.org/browse/JBAS-9000
[15:17:53] <jbossbot> git [jboss-as] push master c5461d5.. Stuart Douglas JSFUnit dependencies
[15:17:54] <jbossbot> git [jboss-as] push master 5715654.. Stuart Douglas JBAS-9006 rename antlr.antlr to org.antlr
[15:17:54] <jbossbot> jira [JBAS-9006] Rename module "antlr.altlr" to "org.antlr" [Open (Unresolved) Task, Minor, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9006
[15:17:54] <jbossbot> git [jboss-as] push master 67b7650.. Stuart Douglas JBAS-9004 dom4j.dom4j to org.dom4j
[15:17:55] <jbossbot> jira [JBAS-9004] Rename module "dom4j.dom4j" to "org.dom4j" [Open (Unresolved) Task, Minor, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9004
[15:17:55] <jbossbot> git [jboss-as] push master 669763d.. Stuart Douglas JBAS-9008 jline.jline to jline
[15:17:56] <jbossbot> jira [JBAS-9008] Rename module "jline.jline" to just "jline" [Open (Unresolved) Task, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9008
[15:17:56] <jbossbot> git [jboss-as] push master 1cf0301.. Stuart Douglas JBAS-9009 Rename module "wsdl4j.wsdl4j" to "javax.wsdl.api"
[15:17:57] <jbossbot> jira [JBAS-9009] Rename module "wsdl4j.wsdl4j" to "javax.wsdl.api" [Open (Unresolved) Task, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9009
[15:17:57] <jbossbot> git [jboss-as] push master 8befb5e.. Stuart Douglas JBAS-9005 Rename module "cglib.cglib" to "net.sf.cglib"
[15:17:58] <jbossbot> jira [JBAS-9005] Rename module "cglib.cglib" to "net.sf.cglib" [Open (Unresolved) Task, Minor, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9005
[15:17:58] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e6c0479...8befb5e
[15:18:31] <wolfc> crap I had just rebased https://github.com/wolfc/jboss-as/commit/15da95afb67ca4b4e41f76fde00cf887e68f6c22
[15:18:32] <jbossbot> git [jboss-as] 15da95a.. Carlo de Wolf JBAS-9052: Enabled TransactionAttributeAnnotationProcessor
[15:18:39] <jbossbot> jira [JBAS-9052] @TransactionAttribute is not processed [Open (Unresolved) Bug, Critical, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-9052
[15:18:43] <wolfc> dmlloyd, it's probably still pickable :-)
[15:18:56] <bstansberry> jaikiran: I suspect it's due to JBAS-9037
[15:19:06] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Resolved (Done) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[15:19:11] <bstansberry> but it should give up eventually
[15:19:38] <dmlloyd> yeah the above commit only touches a pretty narrow set of code
[15:20:14] <wolfc> I also have the weldejb integration test working https://github.com/wolfc/jboss-as/commits/weld but it depends on a hack
[15:20:33] <wolfc> probably better to wait for JBAS-9055
[15:20:34] <jbossbot> jira [JBAS-9055] Cleanup @AccessTimeout processing [Open (Unresolved) Task, Major, jaikiran pai] https://issues.jboss.org/browse/JBAS-9055
[15:21:44] <wolfc> dmlloyd, out of curiosity, why merge MB into EE?
[15:27:59] <dmlloyd> why not
[15:28:07] <dmlloyd> we need to reduce the number of subsystems we have
[15:28:12] <dmlloyd> MB is like 8 classes
[15:28:17] <dmlloyd> and no config
[15:28:44] <jbossbot> git [jboss-as] push master c0389e0.. Rémy Maucherat Remove dead code.
[15:28:44] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/8befb5e...c0389e0
[15:32:01] *** hbraun has quit IRC
[15:34:02] <dmlloyd> so when I went to bed, there were 114 outstanding issues before GA.  When I woke up there are now 124 :(
[15:34:08] <dmlloyd> we're going in the wrong direction people!
[15:35:27] *** jamezp has joined #jboss-as7
[15:36:09] <baileyje> dmlloyd: Did you get a chance to look at: https://github.com/baileyje/jboss-as/commits/jsf-annotations
[15:36:19] <dmlloyd> no I did not
[15:36:28] <dmlloyd> will do asap though, just gotta get wolfc's in first
[15:36:43] <baileyje> dmlloyd: thanks.
[15:36:46] <baileyje> maeste: There?
[15:36:59] <maeste> baileyje: yup
[15:37:40] <dmlloyd> ah, maeste has a change too.... he's after baileyje
[15:38:17] <baileyje> I have a change which moves the datasource deployment into model operations.  It conflicted with your recent descriptions change.  Any chance you can take a look at my change quick?  Want to make sure you get a look since I clobbered a bit of you DataSource...Provers impl.
[15:38:20] <baileyje> maeste: https://github.com/baileyje/jboss-as/commit/45bad5c97399f8607f32c78666c84cadceb3c742
[15:38:21] <maeste> dmlloyd, baileyje : I'm working on IJ beta5 integration
[15:38:21] <jbossbot> git [jboss-as] 45bad5c.. John E. Bailey Datasource subsystem cleanup.  Deploy datasources using opeartions
[15:38:55] <maeste> baileyje: sure
[15:39:12] <maeste> baileyje: I'm looking
[15:39:16] <baileyje> maeste: thanks,
[15:39:22] <jbossbot> git [jboss-as] push master f38a537.. Carlo de Wolf JBAS-9052: Enabled TransactionAttributeAnnotationProcessor
[15:39:23] <jbossbot> jira [JBAS-9052] @TransactionAttribute is not processed [Open (Unresolved) Bug, Critical, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-9052
[15:39:23] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c0389e0...f38a537
[15:40:41] <wolfc> thanks
[15:41:23] *** Jaikiran is now known as Jaikiran|AFk
[15:41:30] <opalka> dmlloyd, Jaikiran, wolfc Hi David, this commit is not sufficient - https://github.com/jbossas/jboss-as/commit/0e23f0c1db6a811c82d6eb6d83e2fbf63f4978af
[15:41:31] <jbossbot> git [jboss-as] 0e23f0c.. David M. Lloyd Add proper client entry point support
[15:41:46] <dmlloyd> what else do you need?
[15:42:07] <opalka> dmlloyd, As U discussed with Jaikiran on yesterday (I was away already)
[15:42:22] <opalka> dmlloyd, We don't care about available views on Session beans
[15:42:41] <dmlloyd> sure, but the view is your entry point
[15:42:45] <opalka> dmlloyd, for us the only important/interesting thing is @Singleton or @Stateless annotated beans
[15:42:51] <wolfc> chicken/egg, WS is a view
[15:42:55] <dmlloyd> do you bypass interceptors?
[15:42:59] <dmlloyd> or anything like that?
[15:43:00] *** sannegrinovero has quit IRC
[15:43:01] <opalka> dmlloyd, including either @WebService or @WebServiceProvider annotation
[15:43:06] *** sannegrinovero has joined #jboss-as7
[15:43:06] *** sannegrinovero has joined #jboss-as7
[15:43:06] *** ChanServ sets mode: +v sannegrinovero
[15:43:27] <opalka> dmlloyd, No, in AS6 days we used to provide JBossWS SPI abstraction for EJB3
[15:43:33] <dmlloyd> the best fit, it seems to me, is a no-interface view
[15:43:36] <opalka> dmlloyd, they implemented our interface on their EJB3 beans
[15:43:36] <wolfc> WS does not bypass the component interceptors. So it's a clash of definitions.
[15:43:53] <dmlloyd> are you saying you just don't want to do the work? ;)
[15:44:06] <opalka> dmlloyd, Yes, no-interface view wold help a lot
[15:44:18] <opalka> dmlloyd, but now it's not available by default for all session beans
[15:44:28] <dmlloyd> the question is, how/where do we generate a no-interface view when it is otherwise not available
[15:44:35] <wolfc> opalka, no, no, we don't expose a no-interfaceview just like that
[15:44:57] <dmlloyd> we could create a "special" no-interface view, with a Class key of, say, WebService or something, if all else fails
[15:45:00] <wolfc> you want to invoke 'directly' on the bean method.
[15:45:04] <opalka> wolfc, dmlloyd But I don't know if it would be compliant with EJB3 spec to provide no-interface view for every session bean
[15:45:23] *** alesj has quit IRC
[15:45:24] <opalka> wolfc, either invoke methods directly
[15:45:31] <dmlloyd> in any case the entry point is the interceptor, right?
[15:45:55] <opalka> dmlloyd, yes, that would work too, using interceptor in AS7. But in AS6 it wasn't like that (just FYI)
[15:46:26] <dmlloyd> yeah I'd expect it to be fairly different...
[15:46:40] <wolfc> I would say yes, the interceptor is the entry point, but then a problem ensues setting up the InterceptorContext.interceptorIterator
[15:46:43] <opalka> dmlloyd, but this is just implementation detail
[15:46:56] <opalka> wolfc, ???
[15:46:58] <dmlloyd> wolfc, did you have a look at that change?
[15:47:26] <wolfc> we're talking https://github.com/jbossas/jboss-as/commit/0e23f0c1db6a811c82d6eb6d83e2fbf63f4978af#L3R66 ?
[15:47:26] <jbossbot> git [jboss-as] 0e23f0c.. David M. Lloyd Add proper client entry point support
[15:47:40] <dmlloyd> yes
[15:48:10] <wolfc> so in essence WS has identified the proper method and gets back an interceptor
[15:48:26] <wolfc> then it does interceptor.processInvocation(interceptorContext);
[15:48:45] <wolfc> which blows immediately with a cannot proceed
[15:49:09] * opalka listening ...
[15:49:16] <opalka> wolfc, Why it will blow up using Interceptor?
[15:49:18] <dmlloyd> it shouldn't - the client interceptor should nest a chain which should have an associate at the end of it, which then creates a new context
[15:49:30] <dmlloyd> the end result would be the method invocation interceptor which doesn't call proceed
[15:49:48] <dmlloyd> er, the component interceptor I should say
[15:49:50] <dmlloyd> not client
[15:50:05] * opalka seems dmlloyd & wolfc are talking about some impl details I have no idea about ...
[15:50:43] <wolfc> where does WS get interceptorContext from?
[15:50:45] <dmlloyd> baileyje: your fix covers JBAS-8908 correct?
[15:50:46] <jbossbot> jira [JBAS-8908] AS6 ZipException now seen in AS7 [Open (Unresolved) Bug, Blocker, Unassigned] https://issues.jboss.org/browse/JBAS-8908
[15:50:53] <baileyje> dmlloyd: Yeah
[15:51:03] <dmlloyd> wolfc: it should just create one, just like any client would
[15:51:06] *** alesj has joined #jboss-as7
[15:51:09] *** asaldhan has quit IRC
[15:51:38] <wolfc> dmlloyd, in that context interceptorIterator is null
[15:51:50] <wolfc> or do we have a magic interceptor somewhere?
[15:51:53] <opalka> wolfc, dmlloyd Yes I thought we could create custom InterceptorContext, or U see some impl. problems carlo with it?
[15:51:58] <dmlloyd> we have lots of magic interceptors
[15:52:00] <wolfc> :-)
[15:52:00] <dmlloyd> probably too many
[15:52:12] <wolfc> I mean one that doesn't context.proceed();
[15:52:32] <dmlloyd> the component interceptor for a method *should* be a chained interceptor which calls its members in order - the last one doesn't call proceed but instead delegates to another chain, iirc
[15:53:03] <wolfc> ah yes, nasty... :-)
[15:53:54] <maeste> baileyje: oki I had a quick look it seems good to me
[15:53:57] <jbossbot> git [jboss-as] push master 0548667.. John E. Bailey Provide a custom JSF AnnotationProvider which uses the jandex index to find required annotations
[15:53:57] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/f38a537...0548667
[15:54:05] <wolfc> opalka, so you create InterceptorContext (not a custom one), fill it up and interceptor.processInvocation(context);
[15:54:18] <baileyje> maeste: Thanks..  It shouldn't conflict with your IJ changes correct?
[15:54:33] <opalka> wolfc, yes, I expect it could work
[15:54:34] <maeste> baileyje: let me know when you push it to upstream and I'll continue on this base
[15:54:46] <baileyje> maeste: Thanks a lot
[15:54:47] <maeste> baileyje: you are close to push right?
[15:55:02] <baileyje> Yeah.  It is ready.  Just wanted to check with you first
[15:55:03] <wolfc> opalka, better yet, it will work :-)
[15:55:12] *** frainone has quit IRC
[15:55:31] *** alesj has quit IRC
[15:55:39] <maeste> baileyje: cool I've just moved on IJ beta5 and I'm on our IJ codebase atm, so no conflict for sure :)
[15:55:45] <opalka> wolfc, dmlloyd The only problem we have now is how to get the ComponentEntry? WS don't care about views at all
[15:55:50] <baileyje> maeste: great
[15:56:07] <maeste> baileyje: if you have time please push also my pull request
[15:56:14] <maeste> baileyje: it's just a missind dep
[15:56:15] <wolfc> opalka, pass in null :-P
[15:56:25] <maeste> baileyje: but it's needed for MDB
[15:56:30] <opalka> wolfc, will result in IllegalSE :(
[15:56:32] <dmlloyd> opalka: indeed.  One idea is, somehow coerce the EJB deployer into creating a (non-JNDI-bound) no-interface view when a WS deployment is present and use that.
[15:56:43] <dmlloyd> opalka: in this case you'd just pass in the bean class.
[15:56:55] <opalka> wolfc, Any objections ^^^ ?
[15:57:11] <opalka> wolfc, Wouldn't it be against EJB3 spec/TCK ?
[15:57:16] <wolfc> the bean class is already the real no-interface view
[15:57:27] <opalka> wolfc, so no objections ;)
[15:57:28] <wolfc> it would create side-effects probably
[15:57:29] <dmlloyd> wolfc: yeah *but* without interceptors.
[15:57:37] <opalka> dmlloyd, wolfc BTW, I was thinking about the same solution.
[15:57:39] <wolfc> no, with interceptors
[15:58:00] <dmlloyd> oh okay, so you're saying that there is always a no interface view available by this method?
[15:58:05] <dmlloyd> even if it is not explicitly bound?
[15:58:13] <dmlloyd> or requested by the user I mean
[15:58:19] <wolfc> no, it's only available when defined
[15:58:23] <dmlloyd> I suppose binding probably doesn't come into it
[15:58:28] * opalka confirms no-interface view is not available by default if there's e.g. remote view available
[15:58:33] <wolfc> and using the no-interface view has implications down the line
[15:58:38] <dmlloyd> such as?
[15:58:49] * opalka 's curios too ...
[15:58:53] <wolfc> MethodIntf.LOCAL vs MethodIntf.MESSAGE_ENDPOINT
[15:59:12] <opalka> wolfc, ??? ^
[15:59:13] <wolfc> SessionContext.getInvokedBusinessInterface()
[15:59:30] <dmlloyd> the Method passed in to the interceptor has the invoked type on it
[15:59:36] <dmlloyd> from the proper view class
[15:59:42] <dmlloyd> or interface
[15:59:57] <dmlloyd> because it's generated from the proxy's method list
[16:00:08] <dmlloyd> (as opposed to being generated from the bean class)
[16:00:15] * dmlloyd did that on purpose!
[16:00:20] <wolfc> Yeah, but we usually use the class name for user reporting
[16:00:35] <dmlloyd> granted I have no idea what SessionContext.getInvokedBusinessInterface is supposed to return for WS :)
[16:01:06] <wolfc> IllegalStateException
[16:01:23] <dmlloyd> interesting.
[16:01:24] <wolfc> while no-interface the real bean-class
[16:01:34] <dmlloyd> so basically you need to know whether you're being called from a WS method.
[16:01:35] <wolfc> not some rewritten one
[16:01:51] <dmlloyd> yeah the above will hold true for no-interface as well
[16:02:02] <dmlloyd> you'll get the bean method
[16:02:11] <wolfc> as long as nobody calls through the no-interface view they'll be okay
[16:02:26] <baileyje> bstansberry: I had maeste  look over https://github.com/baileyje/jboss-as/commit/b87c2ab81237ec77c67d084c138329d8d5f5693f
[16:02:28] <jbossbot> git [jboss-as] b87c2ab.. John E. Bailey Datasource subsystem cleanup.  Deploy datasources using opeartions
[16:02:29] <dmlloyd> soooo.... maybe we need the other option: bind a *second* no-interface view under a special key
[16:02:59] <bstansberry> so is it ready to go?
[16:03:04] <wolfc> I would say view 'null'
[16:03:10] <baileyje> bstansberry: Yeah.  Unless you see anything else..
[16:03:48] <bstansberry> ok; i'll throw it in this mornings push pile
[16:03:53] <dmlloyd> maeste: your DependecyFix change no longer cleanly applies due to some build adjustments; can you rebase it?
[16:03:55] <bstansberry> thanks man, this is great stuff
[16:04:09] <baileyje> bstansberry: Thanks.  maeste had pull request as well
[16:04:14] <maeste> dmlloyd: sure
[16:04:25] <dmlloyd> thanks
[16:04:46] <bstansberry> yep
[16:06:03] *** jamezp has quit IRC
[16:06:18] <opalka> dmlloyd, wolfc so what's the conclusion? We need to provide special view for 'null' view parameter that will not be identical with no-interface view?
[16:06:33] <opalka> dmlloyd, wolfc or we'll return no-interface view for 'null' parameter?
[16:06:35] *** jamezp has joined #jboss-as7
[16:06:58] *** emuckenhuber is now known as emucken_afk
[16:07:05] <dmlloyd> well, we shouldn't use null, opalka
[16:07:22] *** asaldhan has joined #jboss-as7
[16:07:23] *** ChanServ sets mode: +v asaldhan
[16:07:36] <opalka> dmlloyd, OK, so U have objections for carlo's suggestion
[16:07:53] <dmlloyd> but maybe javax.jws.WebService.class?
[16:07:54] <opalka> dmlloyd, so we need to provide different no-interface view that default one
[16:08:00] <wolfc> while we're talking views. a MDB has a combined view.
[16:08:24] <dmlloyd> yeah I guess so.  An interceptor would have to know to configure the EJBContext correctly.
[16:08:31] <dmlloyd> wolfc: don't even get me started on MDBs :)
[16:08:33] <wolfc> I like javax.jws.WebService.class or something similar
[16:08:42] <dmlloyd> I was looking at it last night and couldn't make heads or tails of the JCA end
[16:08:48] <wolfc> :-)
[16:08:56] <dmlloyd> so we'll have to chat about that... maybe we can pound that out next week
[16:09:16] <wolfc> It's almost done I would say.
[16:09:25] <wolfc> Just need combined view.
[16:09:40] <opalka> wolfc, dmlloyd BTW, WS also needs to work for MDB too
[16:09:47] <wolfc> Huh?
[16:09:50] <opalka> dmlloyd, wolfc does your suggestion will fit MDBs too
[16:10:13] <wolfc> An MDB doesn't have a WS view
[16:10:15] <opalka> wolfc, dmlloyd but to be precise it's not required by TCK
[16:10:42] <dmlloyd> then it's not required ;)
[16:10:47] <wolfc> MDB transaction semantics are very different
[16:10:56] <wolfc> It can not fly
[16:10:56] <maeste> dmlloyd: oki rebased and conflict fixed
[16:10:58] <Jaikiran|AFk> opalka: out of curiosity, if a @SLSB exposes 10 public methods, do a webservice view mean that all those 10 public methods are invokable from the webservice view?
[16:11:01] <dmlloyd> maeste: thanks.
[16:11:03] *** Jaikiran|AFk is now known as Jaikiran
[16:11:17] <Jaikiran> more specifically, what constitutes a webservice view?
[16:11:51] <wolfc> oh oh, now you opened the box :-)
[16:11:53] <opalka> Jaikiran, all methods fulfilling @WebMethod spec. contract
[16:12:19] <opalka> Jaikiran, see JAX-WS spec what is considered @WebMethod
[16:12:21] <Jaikiran> in that case a no-interface view isn't the answer :)
[16:12:32] <opalka> Jaikiran, ;)
[16:12:44] <Jaikiran> so you really need a specific view which exposes only those methods
[16:13:15] <Jaikiran> so the entry point needn't really expect a Class<?>
[16:13:27] <opalka> Jaikiran, wolfc, dmlloyd so I can have completely different view not matching any interface session bean implements
[16:13:31] * opalka 's getting confused ...
[16:14:10] <opalka> Jaikiran, wolfc dmlloyd ^^^ that was a question ;)
[16:14:22] <dmlloyd> well if we use WebService.class as a special marker meaning "the set of methods corresponding to the WS" maybe that could work
[16:14:35] <dmlloyd> it'd be a set of bean methods in this case
[16:14:38] *** alesj has joined #jboss-as7
[16:14:41] <wolfc> WS view is a separate view
[16:14:46] <Jaikiran> from the entry point p.o.v probably yes
[16:14:51] <Jaikiran> but who would create the view?
[16:15:01] <opalka> Jaikiran, good question
[16:15:05] <dmlloyd> good question
[16:15:22] <wolfc> WS creates the view and needs a hook into the EJB
[16:15:37] <dmlloyd> then WS needs to subclass the EJB component description somehow
[16:15:50] <wolfc> Huh?
[16:15:51] <dmlloyd> or EJB needs to create a hook point
[16:15:58] <dmlloyd> because that's where the views are assembled
[16:16:05] <dmlloyd> between description and configuration
[16:16:40] <dmlloyd> unless you see a different way to implement it
[16:16:59] <opalka> dmlloyd, new ideas/suggestions to share ?
[16:17:01] <dmlloyd> the end result has to be that the extra map entry exists on the view map
[16:17:35] <dmlloyd> well actually I suppose we could use a totally separate thing
[16:17:53] <dmlloyd> but that might be a lot of work too
[16:17:56] <wolfc> We need something similar for RS as well
[16:18:11] <dmlloyd> just using the no-interface view is so much easier :)
[16:18:23] <Jaikiran> what's RS?
[16:18:27] <dmlloyd> JAX-RS
[16:18:32] <dmlloyd> resteasy
[16:18:33] <wolfc> it has side effects
[16:19:00] <wolfc> I would rather expose one raw view for everybody to poke upon
[16:19:14] <dmlloyd> consider that the calling client can attach any private data it needs to, so later interceptors can utilize it
[16:19:15] <opalka> wolfc, I like this idea ^^^ ;)
[16:19:32] <dmlloyd> hm okay
[16:19:34] <dmlloyd> that could work
[16:19:53] <dmlloyd> but the raw view would be basically the same to the no-interface view
[16:20:05] <dmlloyd> unless you are talking about changing the interceptors or something
[16:20:11] <wolfc> No, because I think you also can have access to private methods
[16:20:30] <wolfc> opalka, can a @WebMethod be on private methods?
[16:20:37] <opalka> wolfc, no
[16:21:00] <wolfc> good, because I can't find that restriction in the EJB spec
[16:21:15] <dmlloyd> right now the views which are installed include all non-static, non-final methods
[16:21:16] <opalka> wolfc, http://download.oracle.com/javase/6/docs/api/javax/jws/WebMethod.html
[16:21:18] <dmlloyd> including non-public ones
[16:21:31] <dmlloyd> that means the no-interface view too
[16:22:21] <wolfc> only public methods should be in no-interface
[16:22:54] <dmlloyd> ee/src/main/java/org/jboss/as/ee/component/AbstractComponentDescription.java:402 is the place to change that
[16:23:50] <wolfc> as long as there is no test failure I don't mind what it does :-)
[16:24:52] <dmlloyd> if anyone has a moment can they quick verify whether JBAS-8608 still is a valid issue?
[16:24:57] <jbossbot> jira [JBAS-8608] Launch from path with space does not work [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/JBAS-8608
[16:25:12] <dmlloyd> maeste: I get a compilation error...
[16:25:30] <dmlloyd> http://fpaste.org/D5xS/
[16:26:05] <maeste> dmlloyd: let me check...perhaps a wrong conflict solving
[16:26:37] <maeste> dmlloyd: yup it is, let me fix it, just few secs
[16:28:45] <opalka> Jaikiran, wolfc, will U provide 'raw' view? How much complicated task it is? If U're busy I can start playing with it?
[16:29:03] * Jaikiran is catching up with the conversation
[16:29:31] <dmlloyd> I am guessing that wolfc is looking at code and thinking :)
[16:29:37] <opalka> wolfc, also the question is what class to associate with this raw view when looking it up?
[16:29:48] <wolfc> I'm cramming out another bug :-)
[16:30:39] * Jaikiran is going to file a bug about that no-interface view :)
[16:30:56] <Jaikiran> along with a testcase somewhere
[16:31:23] <opalka> wolfc, dmlloyd, Jaikiran we should also decide what view class would be associated with it? Now when accessing no-interface view, U're passing EJB3Impl.class, right?
[16:31:46] <Jaikiran> opalka: yes, if it's no interface view, then Impl.class
[16:32:06] <wolfc> opalka, can an EJB have multiple WS views?
[16:32:14] <opalka> Jaikiran, wolfc, dmlloyd or we'll provide public ComponentEntry createRawClient(final Class<?> viewClass) for it?
[16:32:25] <opalka> wolfc, what U mean?
[16:32:25] <wolfc> without the viewClass :-)
[16:32:32] <opalka> wolfc, of course
[16:32:41] <opalka> wolfc, for example
[16:32:51] <wolfc> dmlloyd, how about: Component.invoke(InterceptorContext) ?
[16:33:18] <opalka> @WebService IfaceA, @WebService(interface=IfaceA.class) @Stateless Impl {}
[16:33:44] <opalka> wolfc, this will result in no-interface EJB3 view to be detected
[16:33:56] <dmlloyd> http://community.jboss.org/message/594140#594140
[16:34:09] <maeste> dmlloyd: oki fixed...fucking eclipse...sorry for that
[16:34:27] <dmlloyd> maeste: perhaps we'll make another IDEA convert out of you :)
[16:34:36] <maeste> dmlloyd: :)
[16:34:47] <Jaikiran> btw, about those marker files thread
[16:34:50] <Jaikiran> just to be clear
[16:35:05] <Jaikiran> i don't mind all those markers files which we might want to maintain
[16:35:14] <dmlloyd> Jaikiran: don't worry Jaikiran, you provided a patch so you're off the hook for buying beer :)
[16:35:20] <dmlloyd> even if the patch wasn't accepted!
[16:35:27] <Jaikiran> woohoo! :)
[16:35:49] <dmlloyd> I don't have a problem with entertaining other ideas, I just can't handle the whining
[16:35:54] <dmlloyd> I get enough of that from my kids :)
[16:36:16] <Jaikiran> :)
[16:41:22] <opalka> wolfc, Jaikiran when can we expect this 'raw' view to be available upstream?
[16:41:31] <wolfc> dmlloyd, https://github.com/jbossas/jboss-as/commit/0e23f0c1db6a811c82d6eb6d83e2fbf63f4978af#L0R333 the interceptorFactoryMap contains perInstance interceptors, not perView
[16:41:31] <jbossbot> git [jboss-as] 0e23f0c.. David M. Lloyd Add proper client entry point support
[16:41:51] <Jaikiran> wolfc: what set of interceptors would apply to this Component.invoke(InterceptorContext) ?
[16:41:55] <wolfc> we don't have nor want interceptors tied to a view
[16:41:57] <Jaikiran> (if we introduce such a method)?
[16:42:03] <baileyje> dmlloyd: Was there anything else for https://github.com/baileyje/jboss-as/commits/jboss-context
[16:42:19] <opalka> dmlloyd, btw, this is what I noticed today, in AbstractComponent
[16:42:21] <opalka>     private final List<LifecycleInterceptorFactory> postConstructInterceptorsMethods;
[16:42:22] <opalka>     private final List<LifecycleInterceptorFactory> preDestroyInterceptorsMethods;
[16:42:23] <dmlloyd> baileyje: didn't even see that you had that, awesome.
[16:42:31] <baileyje> dmlloyd: I just added that.
[16:42:47] <dmlloyd> opalka: yeah lifecycle interceptors have been done and redone a number of times.
[16:42:49] <opalka> dmlloyd, from javadoc only one method can be annotated with @PreDestroy and @PostConstruct annotation on instance
[16:43:28] <Jaikiran> wolfc: hmm yeah, so effectively all interceptors for that component. but how would the calling client know of those interceptors?
[16:43:52] <wolfc> Jaikiran, it won't. the ChainedInterceptor is magic
[16:45:35] <dmlloyd> opalka: yes however each interceptor class can also have one or both methods.
[16:47:36] <opalka> dmlloyd, ok
[16:49:10] <dmlloyd> baileyje: yeah that's probably it I guess.  One thing - the JNDIView MBean doesn't actually work with the component views; it just shows the global references and that's it
[16:49:30] <dmlloyd> so it may not be worth bothering with
[16:49:31] <baileyje> dmlloyd: Yeah.  It needs to be fixed or removed eventually.
[16:49:36] <dmlloyd> at least not unless we enhance it somehow
[16:49:45] <dmlloyd> are things using it, like tests or something?
[16:49:52] *** mmoyses is now known as mmoyses_
[16:49:56] *** jfd has joined #jboss-as7
[16:49:56] *** jfd has quit IRC
[16:49:56] *** jfd has joined #jboss-as7
[16:49:56] *** ChanServ sets mode: +v jfd
[16:50:53] <Jaikiran> we have JNDIView in AS7?
[16:51:04] <wolfc> a fix for JBAS-9060 https://github.com/wolfc/jboss-as/commit/827503cd2502e4f9d94b4d9f4866697a61167771
[16:51:05] <jbossbot> jira [JBAS-9060] SFSB isn't disassociated from a transaction [Open (Unresolved) Bug, Critical, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-9060
[16:51:06] <jbossbot> git [jboss-as] 827503c.. Carlo de Wolf JBAS-9060: Disassociated SFSB instance on release
[16:51:14] <dmlloyd> Jaikiran: yeah.  it doesn't do much though
[16:51:25] <Jaikiran> i see
[16:51:39] <dmlloyd> once contexts become read-only for real, I imagine it will do even less
[16:52:18] <Jaikiran> ideally, we probably should have a JNDIView MBean which at the very least shows global jndi bindings
[16:52:26] <wolfc> dmlloyd, is Stuarts fix for JBAS-9037 in master?
[16:52:27] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Resolved (Done) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[16:52:33] <Jaikiran> it's going to be pretty useful at least for EJB deployments
[16:55:16] <dmlloyd> yes wolfc
[16:55:27] <wolfc> crap, I'm hanging at the same spot
[16:55:55] <dmlloyd> Jaikiran: yeah maybe we could come up with a new one that even lets you browse into modules and stuff
[17:00:07] <baileyje> Jaikiran: That is pretty much what it does now.  Just the globals.
[17:00:26] <baileyje> Eventually it would be nice to allow it to have component namespaces as well
[17:01:55] <dmlloyd> well ti doesn't even really do that because global is a reference isn't it?
[17:03:11] <baileyje> dmlloyd: Depends on what you mean by global..
[17:03:37] <baileyje> It has the bindings from the true global namespace, but not the java:global
[17:03:48] <baileyje> we could easily have it follow refs though..
[17:04:30] <dmlloyd> yeah but we don't have any other bindings in the true global namespace other than the root contexts *and* a couple odds and ends that are going to be deleted
[17:04:43] <dmlloyd> because that stuff won't work once Contexts are read only
[17:04:51] <dmlloyd> unless we enhance the binder service that is
[17:05:01] <baileyje> datasources, and CF ofter go there
[17:06:49] <jbossbot> git [jboss-as] push master 2e78c5e.. Stefano Maestri DependencyFix
[17:06:49] <jbossbot> git [jboss-as] push master 2ae4136.. John E. Bailey [JBAS-8980] Add java:jboss namespace
[17:06:56] <jbossbot> jira [JBAS-8980] Implement vendor-specific global JNDI context [Open (Unresolved) Task, Major, John Bailey] https://issues.jboss.org/browse/JBAS-8980
[17:06:57] <jbossbot> git [jboss-as] push master 0dd9106.. Carlo de Wolf JBAS-9060: Disassociated SFSB instance on release
[17:06:57] <dmlloyd> jira is slow today
[17:06:57] <jbossbot> jira [JBAS-9060] SFSB isn't disassociated from a transaction [Open (Unresolved) Bug, Critical, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-9060
[17:06:57] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/0548667...0dd9106
[17:07:00] <pilhuhn> THe (json) domain description output for attributes is  "attname" : { .. properties without name }   while for operations it is "opname: { operation-name : xx ;  .... } "   is this adding/omision of the name within the properties intentional?
[17:26:06] *** frainone has joined #jboss-as7
[17:26:07] *** ChanServ sets mode: +v frainone
[17:31:03] *** opalka has quit IRC
[17:33:44] *** Jaikiran has quit IRC
[17:39:11] <baileyje> dmlloyd: Are you planning on continuing the async ejb work?
[17:44:16] *** emmanuel has quit IRC
[17:46:17] *** AndyTaylor has joined #jboss-as7
[17:46:17] *** ChanServ sets mode: +v AndyTaylor
[17:47:16] <dmlloyd> baileyje: well I was kinda stuck on it, was hoping someone familiar with EJB would take it over
[17:47:45] <baileyje> dmlloyd: Yeah.  I was looking at it and came to same conclusion.
[17:48:00] <jbossbot> git [jboss-as] push master 3808609.. David M. Lloyd [JBAS-8432] Clean up unused stuff
[17:48:01] <jbossbot> jira [JBAS-8432] Clean up stale/unused XSD and XML files [Open (Unresolved) Task, Major, David Lloyd] https://issues.jboss.org/browse/JBAS-8432
[17:48:01] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/0dd9106...3808609
[17:48:12] <dmlloyd> baileyje: I think I hit all the major points with my impl though
[17:49:51] <dmlloyd> looks like all the other beta2 tasks have takers, which is good
[17:49:57] *** AndyTaylor has quit IRC
[17:50:06] <dmlloyd> the bad news is there are a ton of CR1 tasks - far more than we can hit in the time between beta3 and CR1
[17:50:36] *** mmoyses_ is now known as mmoyses
[17:51:00] <smcgowan> dmlloyd/baileyje:  ALR did the ejb async work in AS 6
[17:51:11] <dmlloyd> yeah I borrowed heavily from his work :)
[17:51:24] <dmlloyd> at least conceptually, the code is basically incompatible
[17:53:09] *** emucken_afk is now known as emuckenhuber
[17:55:17] <dmlloyd> baileyje: JBAS-8513 should no longer be an issue, right?
[17:55:18] <jbossbot> jira [JBAS-8513] Managed bean @Resource injection is premature [Open (Unresolved) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-8513
[17:55:44] <dmlloyd> since the whole ManagedReferenceFactory thing
[17:57:20] <baileyje> Yeah.  I think is should be fixed
[17:57:46] *** pilhuhn is now known as pil-dinner
[18:04:48] *** jcosta has quit IRC
[18:05:53] *** mbg has quit IRC
[18:13:34] <dmlloyd> wolfc: I don't think the hang you're seeing is related to JBAS-9037
[18:13:35] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Reopened (Unresolved) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[18:13:47] <dmlloyd> especially as it is confined to one test
[18:13:54] <dmlloyd> and 9037 could hit any test
[18:17:51] *** slaboure has quit IRC
[18:18:11] *** emuckenhuber has quit IRC
[18:19:30] <dmlloyd> maeste: is JBAS-8709 doable in the beta2 timeframe?
[18:19:38] <jbossbot> jira [JBAS-8709] Create a service for each resource adapter [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-8709
[18:19:47] <dmlloyd> man jira is really slow today
[18:21:19] *** torben has joined #jboss-as7
[18:21:20] *** ChanServ sets mode: +v torben
[18:21:57] *** torben has quit IRC
[18:21:59] *** mmoyses has quit IRC
[18:22:19] *** jhalliday has quit IRC
[18:23:23] *** mmoyses has joined #jboss-as7
[18:23:24] *** ChanServ sets mode: +v mmoyses
[18:24:14] *** ALR has joined #jboss-as7
[18:24:14] *** ChanServ sets mode: +v ALR
[18:35:36] *** jfclere has quit IRC
[18:37:53] <jbossbot> git [jboss-as] push master 026d620.. Alexey Loubyansky JBAS-9053
[18:37:54] <jbossbot> jira [JBAS-9053] cli: buffer index in the command completer needs correction [Open (Unresolved) Bug, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-9053
[18:37:54] <jbossbot> git [jboss-as] push master 0b6d1bf.. Alexey Loubyansky JBAS-9054
[18:37:55] <jbossbot> jira [JBAS-9054] cli: executing 'connect' while connected [Open (Unresolved) Task, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-9054
[18:37:55] <jbossbot> git [jboss-as] push master 4c47547.. Alexey Loubyansky JBAS-9056
[18:37:56] <jbossbot> jira [JBAS-9056] cli: reflect the connection status in the prompt [Open (Unresolved) Task, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-9056
[18:37:56] <jbossbot> git [jboss-as] push master e19e447.. Alexey Loubyansky JBAS-9058
[18:37:57] <jbossbot> jira [JBAS-9058] cli: end completed property with '=' and completed property list with ')' [Open (Unresolved) Task, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-9058
[18:37:57] <jbossbot> git [jboss-as] push master add6a76.. Alexey Loubyansky trim node parsed node name and minor buffer index adjustments in the operation completer
[18:37:57] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/3808609...add6a76
[18:38:38] * dmlloyd hopes to be under 100 issues by the time the day is over
[18:40:19] <jamezp> Looks like you're off to a good start.
[18:46:54] <ALR> Not a lot of love for the boring testsuite thread eh?
[18:48:10] <dmlloyd> it's on my list :)
[18:48:29] <ALR> smcgowan: ^ In reply to our internal emails
[18:48:41] <ALR> The "document" I alluded to was in fact a dev email.
[18:49:12] <smcgowan> ALR:  i have some thoughts, i also replied to the thread with richard and rajesh did you see that
[18:50:00] <smcgowan> ALR:  why don't we reuse what hardy did for the TCKs: http://dev39.qa.atl.jboss.com/~smcgowan/BV-TCK-Assertions/coverage.html
[18:50:01] <ALR> smcgowan: Yep.  And that thread looks to me more about running and keeping track of existing tests
[18:50:17] <ALR> smcgowan: Though I think a bunch of that thread should be made more public too.
[18:50:27] <ALR> Test plans are for more than 3 people to see :)
[18:50:38] <smcgowan> it can be - i'm not sure richard and rajesh are on as7-dev yet
[18:50:41] <smcgowan> i'll tell them
[18:50:51] <smcgowan> EAP test plans?
[18:51:00] <ALR> Well, for instance that link might not be able to
[18:51:05] <smcgowan> right
[18:51:09] <ALR> If it's VPN'd
[18:51:17] <ALR> Coverage reports in general, yes, I like.
[18:51:21] <ALR> I didn't touch on that yet
[18:51:21] <smcgowan>  i don't have a external one to provide
[18:51:25] <ALR> For instance I do something like:
[18:51:33] <smcgowan> actualy i think your scope is too limited
[18:51:36] <smcgowan> for devs
[18:51:41] <ALR> http://jboss.hudson.alrubinger.com/job/ShrinkWrap_Deploy_Site/39/cobertura/
[18:51:46] <jbossbot> git [jboss-as] push master 1e17d7c.. John E. Bailey Datasource subsystem cleanup.  Deploy datasources using opeartions
[18:51:46] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/add6a76...1e17d7c
[18:52:11] <ALR> smcgowan: But the problem with that setup is a bug where the true coverage index isn't reported and we get a lot of false 0%
[18:52:20] <bstansberry> baileyje: ^^^
[18:52:28] <baileyje> bstansberry: Thanks
[18:52:28] <ALR> ShrinkWrap coverage is actually much higher than that
[18:53:07] <dmlloyd> folks please make sure you're either (a) closing your JIRAs when they're merged or (b) making sure they're assigned to the person doing the merge
[18:53:13] <ALR> smcgowan: How is it too limited for devs?
[18:53:14] <bstansberry> I'm going to create a JIRA for the JCA guys to rework the ds-related demos to use this, and comment out the default H2 stuff
[18:53:14] <smcgowan> ALR:  i'm sure what exactly you were proposing other than requiring a JIRA and to avoid jboss-specific implementation
[18:53:37] <smcgowan> how are you going to control the start and stopping of the server?
[18:54:09] <ALR> smcgowan: Let ARQ do it, depending upon the run mode config.  Embedded or managed.
[18:54:52] <smcgowan> ALR: so ARQ does it all, then?
[18:55:11] <smcgowan> i guess i need to see all that it provides before i can comment more on that
[18:55:19] <smcgowan> where's the latest doc?
[18:55:41] <ALR> smcgowan: Check out this: https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/src/test/java/org/jboss/as/testsuite/integration/webejb/ServletInjectionTestCase.java
[18:56:00] *** mbg has joined #jboss-as7
[18:56:00] *** ChanServ sets mode: +v mbg
[18:56:15] <smcgowan> ok
[18:56:59] <smcgowan> http://localhost:8080 ??
[18:57:01] <ALR> smcgowan: What other issues do you think need to be addressed?
[18:57:12] <ALR> smcgowan: Why not localhost:8080?
[18:57:51] <smcgowan> ALR:  really?
[18:58:15] <smcgowan> i would like to be able to specifiy the node - via name or IP adderss
[18:58:34] <ALR> smcgowan: Then factor out the hardcoded stuff :)
[18:58:51] <ALR> This test was clearly written for the standalone/embedded case
[18:58:53] <smcgowan> alright
[18:59:19] <smcgowan> and the other comment was that other test types were out of scope
[18:59:51] <smcgowan> it would be important to categorize test types - which is currently done so why is the "spec" stuff different - will that be it's own
[18:59:52] <ALR> smcgowan: You mean the ones I left out of scope for this discussion?  Stress and benchmarking?
[18:59:59] <smcgowan> test; ie. -Prun-spec-tests
[19:00:12] <smcgowan> yes, why is it out of scope?
[19:00:23] <ALR> Because most importantly I feel we need coverage.
[19:00:41] <smcgowan> but others may not feel that way
[19:00:49] <ALR> And if we nail out the layout for that, then adding a new module (or just moving the existing ones around) for stress and benchmarking is simple.
[19:01:09] <smcgowan> point taken
[19:01:12] *** emuckenhuber has joined #jboss-as7
[19:01:12] *** ChanServ sets mode: +v emuckenhuber
[19:01:25] *** darranl is now known as darranl_afk
[19:01:29] <ALR> You don't have to agree. :)
[19:01:37] <smcgowan> all the requirements should be identified then we can limit scope
[19:01:38] <ALR> But top order I think is getting the coverage in place.
[19:01:46] <smcgowan> QE does have additional ones we should consider
[19:01:52] <baileyje> maeste: Would you like help on JBAS-8709?
[19:01:54] <jbossbot> jira [JBAS-8709] Create a service for each resource adapter [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-8709
[19:02:00] <ALR> smcgowan: Great, just reply to the Thread w/ additional requirements.
[19:02:11] <ALR> And we can either address them here, or shove 'em off until later.
[19:02:21] <ALR> But they'll be inventoried.
[19:02:41] <smcgowan> where is the inventory list?
[19:02:41] <maeste> baileyje: sure
[19:02:50] <wolfc> dmlloyd, I got hit by JBAS-9037 in the ManagedBean test
[19:02:51] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Reopened (Unresolved) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[19:02:52] <maeste> baileyje: but is it really needed
[19:02:56] <maeste> ?
[19:03:05] <maeste> baileyje: we have already a jndiService
[19:03:30] <smcgowan> wolfc:  i saw that yesterday, but thought it was fixed with JBAS-9037 - are you up-to-date
[19:03:31] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Reopened (Unresolved) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[19:03:47] <smcgowan> i don't see it since I sync'd
[19:03:58] <ALR> smcgowan: Nnoexistent.  I wasn't laying out a test plan, perse (which would include things like CI config, coverage configuration, other reports, etc).  Just a development methodology for our testsuite.
[19:04:21] <ALR> I think we're confusing a dev plan for a QA one :)
[19:04:22] <smcgowan> ALR:  that's the difference in our view
[19:04:39] <dmlloyd> maeste: we need a ResourceAdapter in order to activate MDBs
[19:05:05] <wolfc> smcgowan, I'm up to date.
[19:05:26] <ALR> smcgowan: You think that Hudson configs and the like are part of the dev plan?
[19:05:33] <wolfc> dmlloyd, maeste, can we use the regular hornetq-ra?
[19:05:41] <smcgowan> ALR:  i would like to be able to run the tests on Hudson
[19:05:52] <wolfc> I think we can even do a custom ra. They're not that difficult to implement.
[19:06:02] <maeste> baileyje: but this jndiService register a connectionFactory, that is what we normally use for ds and ra lookup
[19:06:04] <smcgowan> that was my balk at localhost, that's not going to work in that environment
[19:06:09] <maeste> dmlloyd: ^^^
[19:06:15] <ALR> smcgowan: Nothing in my design mail prevents that.
[19:06:40] <ALR> smcgowan: And the AS7 suite currently in place already runs in Hudson.
[19:07:09] <maeste> dmlloyd: and it's what I've created for smarlow as original request
[19:07:09] <smcgowan> ALR: i know -
[19:07:34] <maeste> smarlow: you there? are you fine with jndiService or have i missed something?
[19:07:36] <dmlloyd> maeste: smarlow's comment is actually pertaining to a totally different issue
[19:07:39] *** odin_ has joined #jboss-as7
[19:08:00] <dmlloyd> we need Service<ResourceAdapter> specifically for MDBs - the datasource stuff is really unrelated
[19:08:09] <maeste> dmlloyd: anyway I can do that, it's just a specialisation
[19:08:23] <smcgowan> the question i did ask yesterday was what was your scope so i would know whether certain things were being considered
[19:08:36] <wolfc> dmlloyd, shouldn't the connector subsystem provide that?
[19:08:53] <dmlloyd> wolfc: yes, that's why it's assigned to maeste to provide
[19:09:10] <wolfc> oh, I thought the connector subsystem was done
[19:09:44] <dmlloyd> from what we discussed in antwerp, we need MDBs to depend on the ResourceAdapter so they can call activate on it when the MDB is installed to begin inflow
[19:10:01] *** alesj has quit IRC
[19:10:04] <dmlloyd> but that's the extent of my understanding
[19:10:18] <maeste> dmlloyd wolfc: but please explain me. Why do you need it? just express a dependency and injection?
[19:10:29] <wolfc> http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jca/trunk/core/src/main/java/org/jboss/jca/core/spi/rar/
[19:10:37] <dmlloyd> yeah it has to be a service so that the dependencies are managed correctly
[19:10:55] <wolfc> I would expect to inject a Service<ResourceAdapterRepository>
[19:11:11] <wolfc> and somehow express a dependency on the actual RA deployment
[19:11:19] <dmlloyd> why?  we are not interested in that
[19:11:23] <maeste> wolfc, dmlloyd : yup we have a serivice already exposing this ResourceAdapterRepository
[19:11:24] <dmlloyd> we just need the RA
[19:11:46] <dmlloyd> right?
[19:12:33] <smcgowan> ALR:  there are resources being identifed to work on coverage including from QE so that's why there are other considerations as well
[19:12:47] <maeste> dmlloyd, wolfc : what I have understood from jesper (thought it discussed with carlo) is that Service<ResourceAdapterRepository> was for MDB. Isn't it?
[19:13:02] <wolfc> yes
[19:13:04] <dmlloyd> okay, well it's possible I'm behind on the discussion
[19:13:22] <dmlloyd> I don't see how you can activate an MDB from this interface
[19:13:24] <maeste> oki, so the issue could be commented and marked as resolved
[19:13:29] <baileyje> dmlloyd, wolfc : It looks like there is an ejb-jar.xml parser.  Is JBAS-9019 resolved, or is there more that is needed?
[19:13:38] <jbossbot> jira [JBAS-9019] Support for ejb-jar.xml [Open (Unresolved) Sub-task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9019
[19:13:39] <ALR> smcgowan: Super.  To work on adding coverage, or to work on reporting it?
[19:13:40] <dmlloyd> specifically we have to cleanly unregister the MDB when the MDB is removed
[19:13:46] <dmlloyd> and the dependencies have to work
[19:13:59] <smcgowan> ALR:  both
[19:14:07] <wolfc> the MDB calls endpointDeactivation at the proper moment
[19:14:20] <ALR> smcgowan: And again, I didn't draft the mail to dictate out ideas.  All reqs should be added to the Thread.  From that I can make a doc.
[19:14:37] <ALR> (And more importantly, just commit stuff into the tree)
[19:14:43] <wolfc> the only thing that MSC needs to manage is the dependency from the MDB onto the RAR
[19:15:11] <dmlloyd> ok so does that mean that JBAS-8709 can be closed?
[19:15:13] <jbossbot> jira [JBAS-8709] Create a service for each resource adapter [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-8709
[19:15:15] <ALR> We keep talking about more requirements; ... what are they?  Coverage reports - fantastic.  That's build config.
[19:15:18] <ALR> What else?
[19:15:18] <smcgowan> just commit stuff till we figure out the requirements
[19:15:34] <maeste> dmlloyd: yup it's waht I was saying
[19:15:37] <baileyje> dmlloyd: Do we have a service for the RAR?
[19:15:43] <dmlloyd> baileyje: apparently so
[19:15:48] * dmlloyd knows nothing of it though
[19:15:53] <maeste> baileyje, dmlloyd : yup
[19:16:04] <wolfc> cool, then the MDB can just look that one up
[19:16:11] <wolfc> via an Injector contruction
[19:16:19] *** jwulf has joined #jboss-as7
[19:16:47] <maeste> baileyje, dmlloyd, wolfc : https://github.com/jbossas/jboss-as/blob/054866757e0c7653b3e5ea35569637b8e535c799/connector/src/main/java/org/jboss/as/connector/services/JndiService.java
[19:17:10] <maeste> ops wrong one sorry
[19:17:12] <baileyje> It looks like the RARs are added together as a ResourceAdaptersService
[19:17:12] <dmlloyd> not sure what that is
[19:17:29] <maeste> dmlloyd: no sorry wait, it's the wrong service
[19:17:35] <dmlloyd> yeah that's what I thought too baileyje, it looked wrong to me
[19:17:44] <dmlloyd> that service I mean
[19:17:48] <dmlloyd> I couldn't figure out its purpose
[19:17:55] <baileyje> well you couldn't depend on a specific one.
[19:18:04] <wolfc> I got the main bits for MDB up: https://github.com/wolfc/jboss-as/tree/JBAS-8969
[19:18:05] <jbossbot> jira [JBAS-8969] Implement annotation scanner for @MessageDriven. [Open (Unresolved) Sub-task, Major, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-8969
[19:18:20] <maeste> dmlloyd, wolfc , baileyje :https://github.com/jbossas/jboss-as/blob/054866757e0c7653b3e5ea35569637b8e535c799/connector/src/main/java/org/jboss/as/connector/rarepository/RaRepositoryService.java
[19:18:36] <maeste> this one is the one wolfc was referring
[19:18:54] <wolfc> Right, that is the repository. That leaves out MSC dependencies, which the MDB needs.
[19:19:12] <dmlloyd> from an MSC perspective it makes a hell of a lot more sense to have a service per RA
[19:19:33] <dmlloyd> if you need a registry that's fine, the RA service can inject the registry and then install itself into it via lifecycle methods
[19:19:44] <wolfc> Yeah, then we can skip that repo.
[19:20:40] <maeste> dmlloyd, wolfc : oki I think it's doable. I've not been involved on the discussion between jesper and wolfc. If it's what you need I can do a service for each RA
[19:21:43] <wolfc> Jesper stepped away from the dependency issue. Basically the MDB has @ResourceAdapter("my-ra.rar").
[19:22:20] <maeste> wolfc: so finally you need that RA service. right?
[19:22:22] <wolfc> At some point this will lead to MessageDrivenComponent.resourceAdapter and then the MDB can play ball.
[19:22:42] <wolfc> Yes, it makes the most sense to have this come in via a MSC Service.
[19:22:51] <wolfc> That would express both injection and dependency.
[19:23:12] <maeste> wolfc: oki let me have a look at the code....just few mins
[19:23:13] <smarlow> maeste, dmlloyd:  I'm fine with switching to a different datasource lookup service
[19:23:41] <maeste> smarlow: so aren't you fine with JndiService?
[19:23:50] <baileyje> smarlow: Yeah.  JDBC datasource have specified services now.
[19:24:01] <dmlloyd> they're separate from RA services though.
[19:24:05] <baileyje> right
[19:24:07] <maeste> baileyje: oh right
[19:24:21] <dmlloyd> they may overlap internally but from our perspective it's separate
[19:24:33] <baileyje> mainly to support BinderServies which support component injeciton
[19:25:31] <baileyje> maeste: If you are swamped with IJ tasks I can help out with the RA stuff as well.
[19:25:44] <baileyje> but it is up to you.
[19:25:51] <baileyje> There is plenty to do :)
[19:26:41] <smarlow> maeste, baileyje: I'm currently doing a separate jndi lookup of the datasource, after (Util.lookup(pu.getJtaDataSourceName(), DataSource.class))
[19:26:55] <smarlow> it would be nice to just inject it instead.
[19:27:08] <dmlloyd> wolfc: doesn't the selected RA depend on the listener interface used?
[19:27:19] * dmlloyd is curious about your @ResourceAdapter("my-ra.rar")
[19:27:20] <smarlow> maeste:  I don't think jndiService supports that
[19:27:37] <maeste> smarlow: well you can
[19:27:52] <dmlloyd> smarlow, are you injecting datasources from JNDI?
[19:27:57] <maeste> smarlow: just inject an Object thought, so you need to cast after
[19:27:59] <dmlloyd> or attempting to?
[19:28:13] <wolfc> dmlloyd, you can have multiple JMS RA deployed for example
[19:28:16] <dmlloyd> and maeste, are you not using BinderService to register them?
[19:28:38] <dmlloyd> wolfc: okay, I see, so this is a jboss-specific disambiguation mechanism?
[19:28:39] <smarlow> I'm not currently attempting but could :)  I'm using an old fashioned jndi lookup at the moment
[19:28:42] <wolfc> public Set<String> getResourceAdapters(Class<?> messageListenerType);  is handy if the user does not specify a RA
[19:28:46] <smarlow> dmlloyd:  ^
[19:28:52] <baileyje> smarlow: That would be an easy task.  The PersistenceUnitService already has a dependency on the datasource.  All you would need to do is add an injected value.
[19:29:22] <dmlloyd> smarlow: the EE component stuff already has magic in it to express dependencies on JNDI bindings and inject their values.
[19:29:22] <maeste> dmlloyd: well the name is bad. JndiService it's in fact a Service of Object (ConnectionFactory or AdminObject) using the jndiName as serviceName
[19:29:32] <maeste> dmlloyd: nothing related to binding
[19:29:42] <dmlloyd> maeste: I see.
[19:30:16] <maeste> dmlloyd: an alternative was to create specific services
[19:30:52] * dmlloyd is okay with specific services :) though there is a simple service type available in MSC... let me look it up...
[19:30:53] <maeste> dmlloyd: like AdminObjectService or ConnectionFactoryService or DataSourceService or XADatasourceService
[19:31:04] <maeste> yup there is a problem there
[19:31:08] <maeste> a bi one IMHO
[19:31:13] <maeste> *big
[19:31:42] <smarlow> baileyje:  okay, looks like I'm using AbstractDataSourceService know anyway :-)  I'll do the injector thing.  thanks!
[19:31:50] <maeste> there is nothing in JndiName (the only name we have) saying that is an AdminObject, a CF or whatever
[19:32:03] <dmlloyd> org.jboss.msc.service.ValueService, or org.jboss.msc.service.ValueInjectionService is sometimes handy
[19:32:12] *** darranl_afk has quit IRC
[19:34:01] <dmlloyd> maeste: if the goal is to have a service to back something which is bound into JNDI, then BinderService is still your best bet.
[19:34:25] <maeste> dmlloyd: oki I'll look at that one
[19:34:49] <baileyje> smarlow: http://pastebin.com/zXUhbdYb
[19:35:00] <dmlloyd> ultimately everything which is bound into JNDI *must* have a BinderService.  We're going to disallow using Context.bind() to put things in to JNDI because it screws up dependency resolution.
[19:35:44] <baileyje> smarlow: THat is a bit hard to read but the jist is there.
[19:36:17] <smarlow> baileyje:  thanks!  I'll make the switch over.  :)
[19:36:30] <baileyje> smarlow: Yeah.  That would be a bit more efficient.
[19:37:20] <baileyje> smarlow: Wairt.  That isn't exactly correct
[19:38:01] <baileyje> my bad.  That will actually give you a DataSourceService and not a DataSource
[19:38:07] <smarlow> baileyje:  I'm waiting about 5 minutes anyway (tracking down a NPE that I just introduced with a change to inject the TransactionSynchronizationRegistry)
[19:38:47] *** balunasj_busy has quit IRC
[19:39:10] <baileyje> actually I may just fix this.  I don't like that there isn't a Service that will get you the actual DataSource
[19:39:24] <baileyje> Not your stuff, but the DS service
[19:43:15] <dmlloyd> the traditional solution is for the BinderService to inject from the "real" service
[19:43:24] <dmlloyd> (said for maeste's benefit, if he's curios)
[19:43:26] <dmlloyd> curious
[19:44:13] <maeste> dmlloyd, wolfc : Oki I've looked. If you need a ResourceAdapter Service you will have a pull request for monday. I'll use a prefix+deployementName as name if you are fine with that? Please note that we already have a ResourceAdapterDeploymentService which vlaue contain also the RA instance
[19:45:21] * dmlloyd looks
[19:45:25] <wolfc> ResourceAdapterDeploymentService has ResourceAdapterDeployment
[19:45:33] <wolfc> not RA
[19:45:45] <wolfc> I'm also looking at uniqueId, that is useless for me
[19:45:45] <maeste> wolfc: yup that contain COmmonDeployement
[19:45:57] <maeste> wolfc: that contain RA
[19:46:06] <wolfc> urgh
[19:46:23] <maeste> wolfc: anyway as said I can do the RAService
[19:46:24] <dmlloyd> why so complex...
[19:46:38] <dmlloyd> well an RAService will get us off the ground anyway
[19:46:43] <maeste> because it's not the purpose for which is developed
[19:47:08] <wolfc> insert joke here :-)
[19:47:11] <maeste> dmlloyd wolfc : oki sold out. You will have a pull request for monday
[19:47:32] <wolfc> @ResourceAdapter("my-ra.rar") to me "my-ra.rar" is the key.
[19:47:50] <maeste> oki the deploymentName
[19:48:03] <maeste> that's will be
[19:48:06] <dmlloyd> we actually have a convention for per-deployment services
[19:48:10] <dmlloyd> sort of
[19:48:45] <wolfc> Right, but that constitutes the ServiceName
[19:48:47] <dmlloyd> deploymentUnit.getServiceName().append("some-identifier-like-maybe-resourceadapter").append(otherStuffIfNecessary)
[19:48:50] <dmlloyd> right
[19:49:00] <dmlloyd> but it also gives a predictable location to find things by name
[19:49:01] <wolfc> That's another bit of the contract
[19:49:18] <wolfc> The user wants to just name his rar
[19:49:23] <wolfc> So that's the user end of the contract
[19:50:16] <wolfc> I don't mind those uniqueId floating around, but it would have been better if they were Object, not String. They are oblique to me.
[19:50:28] *** smcgowan is now known as smcgowan_afk
[19:50:47] <wolfc> clzName#<num> ... nobody would ever get it right :-)
[19:50:56] <maeste> it's dinner time here...I'll leave irc client opened. Just let me know if you need something special as name...I'd like dmlloyd "standard", but I'm open
[19:51:22] *** maeste is now known as maeste_dinner
[19:51:22] <dmlloyd> yeah name is something we can always adjust
[19:51:40] <dmlloyd> so don't worry too much about it right now - I'm sure it'll all become clear soon enough
[19:51:46] <dmlloyd> anyone waiting on a merge?
[19:52:26] <wolfc> ps. we got a RA in demos/rar. Just add a static Queue and we can drive it from a SLSB.
[19:58:20] *** adietisheim has quit IRC
[19:59:49] * smarlow npe fixed and switched to TransactionSynchronizationRegistry
[20:00:10] <mmoyses> dmlloyd: i can see that we have java:jboss now in JNDI. do you want us to move java:/jaas to java:jboss/jaas ?
[20:00:23] <dmlloyd> mmoyses: yeah.
[20:00:29] <dmlloyd> make sure you use BinderService.
[20:00:36] <mmoyses> okey dokey
[20:01:03] <dmlloyd> mmoyses: JBAS-8981
[20:01:04] <jbossbot> jira [JBAS-8981] Move java:/jaas into appserver-wide global context. [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8981
[20:01:38] <mmoyses> got it
[20:03:23] <smarlow> dmlloyd:  https://github.com/scottmarlow/jboss-as/commit/08cd76e2dcf3014d85cb8719d3432c869dcc614f is a small change, could you please merge it in.  Thanks!
[20:03:24] <jbossbot> git [jboss-as] 08cd76e.. Scott Marlow sort by PHASE order, JBAS-8960 Use TransactionSynchronizationRegistry instead of TransactionLocalDelegate
[20:03:25] <jbossbot> jira [JBAS-8960] Use TransactionSynchronizationRegistry instead of TransactionLocalDelegate [Open (Unresolved) Sub-task, Major, Scott Marlow] https://issues.jboss.org/browse/JBAS-8960
[20:04:12] *** darranl has joined #jboss-as7
[20:04:12] *** darranl has joined #jboss-as7
[20:04:12] *** ChanServ sets mode: +v darranl
[20:04:31] <bstansberry> baileyje: did you see andy miller's question on datasource?
[20:04:46] <baileyje> bstansberry: Where was it?
[20:04:52] <bstansberry> dev list
[20:04:52] <dmlloyd> smarlow: testing now
[20:05:14] <bstansberry> i've been poking to figure it out :)
[20:05:16] * smarlow smarlow needs to write some tests :)
[20:05:37] <bstansberry> one question is the meaning of the "module" element
[20:06:10] <dmlloyd> indeed
[20:06:12] <bstansberry> which I understand how that's used; I'm not so clear on whether <driver-class/> has any meaning any more
[20:06:45] <baileyje> bstansberry: Yeah.  I tried to fix that, but that is IJ core.
[20:07:06] <baileyje> basically module means driver name and version
[20:07:14] <baileyje> with that you don't need the driver class
[20:07:59] <bstansberry> can driver-class just be dropped in the xml? i.e. if IJ needs the value we parse it out of module ?
[20:08:10] <bstansberry> I see that IJ does nothing with module
[20:08:44] <bstansberry> I shouldn't be asking you this stuff :) better for jpederse, maeste_dinner
[20:09:29] <baileyje> bstansberry: Correct.
[20:09:42] <baileyje> Module is only used by AS
[20:09:55] <baileyje> and driver-class is just passed into the DS managed connection impl.
[20:10:02] <baileyje> It could be derived from module
[20:10:13] <baileyje> module should be changed to be <driver>
[20:10:19] <bstansberry> yep
[20:10:27] <baileyje> the issue is they are attempting to have the exact same parser in IJ core and AS
[20:10:31] <baileyje> which is problematic.
[20:10:31] <dmlloyd> and driver doesn't exactly cover XA
[20:10:40] <dmlloyd> which is sort of problem B
[20:10:48] <baileyje> right.  XA still need the xa datasource type
[20:11:00] <dmlloyd> ideally there'd be a service file for XADataSource
[20:11:22] * smarlow walking away for a bit
[20:11:23] <smarlow> dmlloyd, baileyje:  let me know what I need to with datasource lookup (if anything) and if my merge fails any tests...
[20:11:24] <dmlloyd> that's what I'd push for anyway, but as a practical matter that'll annoy the piss out of people probably
[20:11:41] <jbossbot> git [jboss-as] push master 08cd76e.. Scott Marlow sort by PHASE order, JBAS-8960 Use TransactionSynchronizationRegistry instead of TransactionLocalDelegate
[20:11:42] <jbossbot> jira [JBAS-8960] Use TransactionSynchronizationRegistry instead of TransactionLocalDelegate [Resolved (Done) Sub-task, Major, Scott Marlow] https://issues.jboss.org/browse/JBAS-8960
[20:11:42] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/1e17d7c...08cd76e
[20:11:53] *** pil-dinner has quit IRC
[20:12:00] <smarlow> dmlloyd:  thanks!  :)
[20:12:12] <dmlloyd> baileyje: wanna open a JIRA for that XML syntax thing?
[20:12:18] <dmlloyd> make it a critical and throw it on Beta2
[20:12:28] *** pil-dinner has joined #jboss-as7
[20:14:40] *** darranl has quit IRC
[20:16:18] <bstansberry> deploying the driver jar still works, doesn't it?
[20:16:43] <baileyje> bstansberry: Yes
[20:16:54] <bstansberry> good, thought so
[20:17:20] <dmlloyd> just not exactly for XA, necessarily...
[20:19:21] <baileyje> dmlloyd: If an on-demand service has all of its demanders stop, will it also stop?
[20:19:39] <baileyje> when its demand count drops to 0
[20:20:19] <dmlloyd> yes
[20:20:30] <dmlloyd> if you want it to not do that, you have to change its mode in start()
[20:20:46] <dmlloyd> there's a compareAndSetMode() method on ServiceController for just that purpose
[20:21:22] <baileyje> dmlloyd: Just confirming.  That was the behavior I expected and want.
[20:21:23] <baileyje> thanks
[20:23:29] <bstansberry> baileyje: was all of what we discussed ^^^ true in beta1 ?
[20:23:52] <bstansberry> i don't want to give a beta1 answer that's only true on trunk!
[20:24:02] <baileyje> about DSs?
[20:24:19] <bstansberry> yeah
[20:27:08] <baileyje> bstansberry: Yes
[20:27:15] <bstansberry> thanks
[20:38:35] *** pil-dinner is now known as pilhuhn
[20:38:36] *** pilhuhn has joined #jboss-as7
[20:39:26] *** balunasj has joined #jboss-as7
[20:39:26] *** balunasj has joined #jboss-as7
[20:39:26] *** ChanServ sets mode: +v balunasj
[20:41:20] *** balunasj has quit IRC
[20:44:23] *** maeste_dinner is now known as maeste
[20:49:28] *** bobmcw has quit IRC
[20:53:52] <jamezp> dmlloyd: Got anything I could help out with this weekend?
[20:55:10] <dmlloyd> hmm
[20:56:10] <dmlloyd> well, any unassigned issue from the link in the /topic of course
[20:56:20] <dmlloyd> though pretty much everything is being worked on by somebody
[20:56:35] <dmlloyd> maybe you could look into JBAS-8991 and figure out wtf is going on there
[20:56:36] <jbossbot> jira [JBAS-8991] Cannot start beta1 server on RHEL6 with OpenJDK 1.6 [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/JBAS-8991
[20:56:41] <jamezp> That was the feeling I was getting :-)
[20:57:14] <jamezp> Sure, that I could handle.
[21:03:39] <wolfc> dmlloyd, an interesting rar issue: JCA 1.6 20.3 Class Loading Requirements: If a standalone resource adapter is configured to deliver messages to a message-driven bean in an application, the standalone resource adapter must be made available to the application.
[21:04:00] <wolfc> right now I don't get those classes
[21:10:22] <dmlloyd> wolfc: so we'll have to know what module corresponds to the RA deployment and add that as an implied dependency for any application which has MDBs from that RA
[21:11:29] *** sannegrinovero has quit IRC
[21:11:30] <wolfc> dmlloyd, as a workaround, shouldn't I be able to add "Dependencies: deployment.ejb3-rar.rar" to manifest?
[21:11:41] <dmlloyd> no, you'd have to use Class-Path
[21:11:55] <dmlloyd> I think the dependency manifest item doesn't hit that module loader
[21:11:58] <dmlloyd> though I could be wrong there
[21:14:28] *** stalep has quit IRC
[21:15:01] *** stalep has joined #jboss-as7
[21:16:30] *** stalep has quit IRC
[21:16:51] *** bstansberry is now known as bstans_afk
[21:24:21] <baileyje> dmlloyd: Can you review https://github.com/baileyje/jboss-as/commit/bce2b8ea2699e7b09e1116454d4551507fd866c0
[21:24:22] <jbossbot> git [jboss-as] bce2b8e.. John E. Bailey Make sure there is a service that exposes a DataSource instance not just the referenc factory
[21:25:00] *** hbraun has joined #jboss-as7
[21:25:56] *** hbraun has quit IRC
[21:29:36] *** maeste has quit IRC
[21:30:26] *** asaldhan has left #jboss-as7
[21:31:10] <stuartdouglas> So is JBAS-9037 still present?
[21:31:12] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Reopened (Unresolved) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[21:31:38] <dmlloyd> not for me
[21:32:07] <jbossbot> git [jboss-as] push master bce2b8e.. John E. Bailey Make sure there is a service that exposes a DataSource instance not just the referenc factory
[21:32:08] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/08cd76e...bce2b8e
[21:32:48] <stuartdouglas> wolfc: When you were having hang problems did you have my fix in your branch?
[21:32:55] <ALR> dmlloyd: Got a link for Eclipse Formatter for AS7?  Got CheckStyle enforced failures.
[21:32:58] *** pretec has joined #jboss-as7
[21:33:09] <dmlloyd> the eclipse stuff is right in with the AS 7 project, ALR
[21:33:17] <ALR> Ah, I'll add that info to:
[21:33:17] <ALR> http://community.jboss.org/wiki/HackingonAS7
[21:33:18] <ALR>  ?
[21:33:21] <dmlloyd> don't recall the directory, ide-settings or somehitng
[21:33:28] <dmlloyd> sure, if you like
[21:33:30] <ALR> Coolio
[21:33:36] *** pretec has left #jboss-as7
[21:34:26] <jamezp> ALR: jboss-as/ide-configs/eclipse
[21:34:34] *** mmoyses has quit IRC
[21:34:49] <ALR> FOund it.
[21:34:51] <ALR> Thanks
[21:35:08] <wolfc> https://github.com/wolfc/jboss-as/commit/4907171b23553dfd7808a972485e1285ef2cefb7
[21:35:08] <jbossbot> git [jboss-as] 4907171.. Stuart Douglas Stop attempting to track unsatisfied dependencies to fix hang
[21:35:20] <wolfc> stuartdouglas ^?
[21:35:24] <stuartdouglas> yea, that one
[21:35:31] <wolfc> https://github.com/wolfc/jboss-as/commits/JBAS-9037-hang
[21:35:32] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Reopened (Unresolved) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[21:35:37] <wolfc> yes, it was in
[21:35:42] <stuartdouglas> crap :-(
[21:37:30] <stuartdouglas> how often does it hang?
[21:38:21] <wolfc> seldomly
[21:39:02] <wolfc> dmlloyd, neither Dependencies nor Class-Path leads to a workaround http://fpaste.org/pYXN/
[21:39:31] <dmlloyd> "Dependency" iirc, not "Dependencies"
[21:39:34] <dmlloyd> though I could be wrong on that
[21:40:22] <dmlloyd> looks like the dependency didn't register though
[21:40:29] <dmlloyd> I'd double-check that manifest
[21:40:35] <ALR> Are there currently smoke-test errors?  Transient or not?
[21:40:38] <dmlloyd> esp. if maven generates it
[21:40:38] <ALR> 16:36:01,135 ERROR [org.jboss.as] (MSC service thread 1-2) JBoss AS 7.0.0.Beta2 "(TBD)" started (with errors) in 2835ms - Started 88 of 113 services (1 services failed or missing dependencies, 24 services are passive or on-demand)
[21:40:47] <dmlloyd> not that I know of ALR
[21:42:14] *** alesj has joined #jboss-as7
[21:53:05] <stuartdouglas> hmm, I still can't reproduce the hang
[21:53:22] <baileyje> I am no longer seeing them
[21:53:58] <jamezp> I got the most of the time before your fix stuartdouglas, now I've not seen one since.
[21:54:00] <ALR> dmlloyd: Ah, the smoke-test errors are when running in OpenJDK only
[21:54:06] <ALR> I think I remember a JIRA for this.
[21:54:07] <jbossbot> git [jboss-as] push master 768e071.. Heiko Braun bare bone content handler for management console
[21:54:07] <jbossbot> git [jboss-as] push master d67d77e.. Heiko Braun Added content type handling and 404 on directory requests
[21:54:07] <jbossbot> git [jboss-as] push master ea64a52.. Heiko Braun Integrate console resources with http api module
[21:54:07] <jbossbot> git [jboss-as] push master e89eebb.. Heiko Braun reference correct classloader
[21:54:07] <jbossbot> git [jboss-as] push master e6e5d8f.. Heiko Braun reference correct console artifact
[21:54:08] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/bce2b8e...e6e5d8f
[21:54:29] <ALR> dmlloyd: Still fielding pull requests via IRC, or prefer a mail to the list?
[21:55:08] <dmlloyd> I can take requests
[21:55:11] <dmlloyd> (on IRC)
[21:58:10] <wolfc> dmlloyd, crock, it's "Dependencies: " and it needs an explicit new-line at the end
[21:58:57] *** pilhuhn has quit IRC
[21:59:48] <dmlloyd> heh
[22:03:51] <wolfc> stuartdouglas, I'm now hanging in StatefulBeanTestCase. Is there anything you want out of this process?
[22:04:28] <stuartdouglas> Is this on https://github.com/wolfc/jboss-as/commits/JBAS-9037-hang ?
[22:04:30] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Reopened (Unresolved) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[22:05:43] <wolfc> stuartdouglas, no dirty stuff on top of https://github.com/jbossas/jboss-as/commit/0dd9106bdbd627f347fcbc1696b393a9c42ac6e2
[22:05:44] <jbossbot> git [jboss-as] 0dd9106.. Carlo de Wolf JBAS-9060: Disassociated SFSB instance on release
[22:05:45] <jbossbot> jira [JBAS-9060] SFSB isn't disassociated from a transaction [Open (Unresolved) Bug, Critical, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-9060
[22:06:20] <ALR> dmlloyd: https://github.com/jbossas/jboss-as/pull/9
[22:06:38] <ALR> dmlloyd: Resolve the issue when committed to my fork, or when upstream?
[22:06:50] <dmlloyd> upstream, I guess
[22:07:12] <ALR> There's a new Git JIRA workflow in the works, BTW
[22:07:26] <ALR> But it doesn't address another level of resolution, which is what we need:
[22:07:30] <stuartdouglas> wolfc: All I can really think of for you to send me is already attached to the JIRA, I assume the MSC service dump is all ok?
[22:07:35] <ALR> Developer Resolved; Upstream; Closed
[22:07:52] <dmlloyd> another way to get around it is to do: if (((Object)appArchive) instanceof ...
[22:08:04] <ALR> dmlloyd: Yeah, I've done that once before too
[22:08:14] <ALR> In AS somewhere in bootstrap.
[22:08:19] <dmlloyd> ALR: yeah really it makes the most sense to just assign the JIRA to the person merging, somehow
[22:08:24] <dmlloyd> though with multiple people it gets funny
[22:09:22] <ALR> dmlloyd: How do you manage issues w/ many commits?  For single ones I like cherry-pick
[22:09:29] <ALR> But for many I generally rebase then merge
[22:09:35] <dmlloyd> I do both
[22:09:41] <ALR> But that doesn't get my name on the board as Committer.
[22:09:54] <dmlloyd> if it's 1-2 commits I'll cherry-pick otherwise I'll rebase
[22:10:03] <dmlloyd> if there's conflicts I make the author rebase
[22:10:07] <ALR> And just ditch your name as committer/approver in the log?
[22:10:28] <dmlloyd> no it keeps the author's name
[22:10:34] <dmlloyd> unless you do it wrong
[22:10:37] <ALR> Right, but not yours..
[22:10:41] <wolfc> stuartdouglas, actually no, ejb3-sfsb-example.jar has a missing dependency
[22:10:43] <ALR> "Committer", not author
[22:10:44] <dmlloyd> ah well I don't really care about that
[22:10:51] <ALR> It just shows auditing.
[22:10:56] <stuartdouglas> wolfc: there's your problem
[22:11:09] <wolfc> I did not change anything there
[22:11:25] <stuartdouglas> what dep is missing?
[22:11:40] <stuartdouglas> the deployment will hang now when deps are missing
[22:12:15] <wolfc> the module.service of it is also down
[22:12:44] <stuartdouglas> and it only fails intermittently?
[22:13:45] <dmlloyd> if the module service is down it's probably due to missing dep there too
[22:13:51] <stuartdouglas> if the module service is down that probably implies that it is waiting on another deployment
[22:14:00] <dmlloyd> as in you have dependencies: but the dependency isn't deployed
[22:14:12] <wolfc> ah wait, this one is a valid missing dependency. It is missing the rar :-)
[22:14:34] <ALR> Rawr.
[22:15:08] <stuartdouglas> my machine has been building in a loop ever since I woke up and I have not seen a hang in either of your branches
[22:15:16] <stuartdouglas> guess I don't have the magic touch :-)
[22:15:26] <ALR> I want his machine.
[22:15:31] <dmlloyd> well I hereby decree that JBAS-9037 is in fact resolved
[22:15:34] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Reopened (Unresolved) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[22:15:36] <dmlloyd> any hang issue is a new bug
[22:15:39] <dmlloyd> not the same problem
[22:15:56] <wolfc> JBAS-9037 was on another branch
[22:15:57] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Reopened (Unresolved) Bug, Blocker, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9037
[22:15:59] <dmlloyd> by the power vested in me by all my senior officers having the day off...
[22:16:04] <wolfc> it did not have that rar thingy
[22:16:28] <dmlloyd> if the problem isn't in upstream then it doesn't exist imo
[22:16:36] <dmlloyd> there's really no practical way of solving it otherwise
[22:16:44] <dmlloyd> and of course introducing problems upstream is a no-no :)
[22:17:31] <wolfc> Regardless, this has to shape up.
[22:17:47] <wolfc> To me it's a hang, because AS doesn't say anything to me.
[22:17:56] *** maeste has joined #jboss-as7
[22:17:56] *** ChanServ sets mode: +v maeste
[22:18:16] <dmlloyd> sure
[22:18:22] <ALR> Transient errors exist to one, the exist to all. :)
[22:18:24] <dmlloyd> I'll take on JBAS-9010
[22:18:25] <ALR> *they
[22:18:25] <jbossbot> jira [JBAS-9010] Provide more comprehensive error messages for missing dependencies [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9010
[22:18:36] * ALR back to slides.
[22:18:38] <dmlloyd> in the meantime, soldier on
[22:18:44] <dmlloyd> use jconsole to locate missing deps
[22:19:06] <stuartdouglas> That was what I tried to do with my fix that resolved the intermittent failures and introduced the hangs
[22:19:11] <wolfc> the dumps attached to 9037 contain no missing dependencies
[22:22:21] *** jfd has quit IRC
[22:25:18] <dmlloyd> then it's an issue in arquillian
[22:25:19] <dmlloyd> a new issue
[22:25:37] <dmlloyd> that can't be reproduced by anyone
[22:25:42] <ALR> Ooh, an ARQ bug?
[22:25:48] <ALR> Bring it on.  We get so few real ones.
[22:25:58] <stuartdouglas> looking at the thread dump it still seems to be a problem with reporting when the deployment is done
[22:26:01] <dmlloyd> more accurately an issue with our exceedingly goofy arq setup
[22:26:14] <ALR> I saw today. :)
[22:26:22] <dmlloyd> ALR: make it better.  please.
[22:26:31] <dmlloyd> testing is a nightmare
[22:26:34] <ALR> dmlloyd: Once I figure out what it's trying to do, yes.
[22:26:37] <dmlloyd> debugging tests is a nightmare
[22:26:40] <ALR> dmlloyd: Also the ARQ tests are disabled
[22:26:58] <ALR> In the Embedded connector anyway: <skipTests>true</skipTests>
[22:27:15] <ALR> This is something I need to take over from Kabir.
[22:27:21] <dmlloyd> it's yours
[22:27:32] <dmlloyd> kabir has enough other crap to do anyway (and he's on vacation)
[22:27:33] <ALR> I'll ping his for current state and scope then.
[22:27:45] <ALR> Consider me back for dev on Wednesday
[22:30:17] *** smcgowan_afk has quit IRC
[22:37:06] <maeste> dmlloyd: do you have ime to
[22:37:36] <maeste> dmlloyd: do you have time to have a look there https://github.com/maeste/jboss-as/tree/JBAS-8709
[22:37:38] <jbossbot> jira [JBAS-8709] Create a service for each resource adapter [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-8709
[22:38:11] <maeste> dmlloyd: it should do what needed for MDB
[22:38:15] <jbossbot> git [jboss-as] push master e3ef684.. Andrew Lee Rubinger [JBAS-9059] Creative workaround OpenJDK compiler bug
[22:38:17] <jbossbot> jira [JBAS-9059] Cannot build JBoss AS 7 using OpenJDK [Resolved (Done) Bug, Major, David Lloyd] https://issues.jboss.org/browse/JBAS-9059
[22:38:17] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e6e5d8f...e3ef684
[22:39:35] <maeste> ALR: really creative workaround :)
[22:39:37] <dmlloyd> maeste, no additional dependencies needed?
[22:40:15] <maeste> dmlloyd: no if I well understood getChildarget purpose
[22:40:44] <maeste> dmlloyd: it only depends on deploymentservice which depends on some stuffs, but hat should be enough
[22:41:07] <dmlloyd> okay
[22:41:40] *** stansilvert has quit IRC
[22:41:50] * maeste hating this fucking keeboard not working almost ime with T character :|
[22:43:23] <maeste> dmlloyd: I can consider dependencies as transitive right? If A depend on B and B depends on C & D in fact A is depending on all B C D, right?
[22:43:34] <dmlloyd> yes
[22:43:44] <maeste> oki so no other deps needed
[22:43:48] <dmlloyd> in general, fewer redundant dependencies == better performance
[22:43:58] <dmlloyd> though in practice you'd need really a lot of them to actually register
[22:44:17] <jbossbot> git [jboss-as] push master de2ed86.. Stefano Maestri JBAS-8709
[22:44:17] <jbossbot> jira [JBAS-8709] Create a service for each resource adapter [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-8709
[22:44:18] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e3ef684...de2ed86
[22:45:10] <maeste> I'll have a look also to Binder service during the weekend, now I'm going to take a break
[22:58:10] *** rmaucher has quit IRC
[23:26:24] *** pgier has quit IRC
[23:27:16] *** frainone has quit IRC
[23:29:08] *** bstans_afk is now known as bstansberry
[23:35:10] <ALR> maeste: Not that creative, but had to signal in the commit that yes, I'm no moron.
[23:35:20] <ALR> [JBAS-XXX] I'm not a moron
[23:37:18] <wolfc> https://github.com/maeste/jboss-as/commit/c3d47747aa426cd5906d3350f676a9c7f7e2f44f#L1R33
[23:37:18] <jbossbot> git [jboss-as] c3d4774.. Stefano Maestri JBAS-8709
[23:37:20] <jbossbot> jira [JBAS-8709] Create a service for each resource adapter [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-8709
[23:37:23] <wolfc> should be log.infof
[23:38:21] <maeste> wolfc: yup right it was there for my convenience
[23:38:25] <maeste> wolfc: fixing
[23:38:28] <maeste> sorry
[23:38:34] <wolfc> np
[23:38:37] * wolfc is off to bed now
[23:39:08] *** wolfc has quit IRC
[23:40:21] <maeste> dmlloyd: when you have time fixed on same branch log level errorf -> infof
[23:40:45] <maeste> dmlloyd: heading off to bed me too ttyl
[23:42:43] *** maeste has quit IRC
[23:45:04] *** ALR has quit IRC
[23:46:33] *** rmaucher has joined #jboss-as7
[23:48:06] *** mbg has quit IRC
[23:55:45] <bstansberry> dmlloyd: i'm pushing maeste's log fix
[23:55:54] <jbossbot> git [jboss-as] push master 3a1c3bd.. Stefano Maestri fixing log
[23:55:55] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/de2ed86...3a1c3bd
[23:57:37] <bstansberry> if you have a sec to look at https://github.com/bstansberry/jboss-as/commit/bae503847c018b01c262479c7d9fe92c496f16da sometime
[23:57:38] <jbossbot> git [jboss-as] bae5038.. bstansberry at jboss dot com Don't attempt composite rollback if no steps provide an rollback op...
[23:58:28] *** mbg has joined #jboss-as7
[23:58:28] *** ChanServ sets mode: +v mbg
[23:58:34] *** mbg has quit IRC
[23:58:34] <rmaucher> Pull request: another minor fix: https://github.com/rmaucher/jboss-as/commit/9e75d0965e240b36d0fdacecf9aae25b28e1cc4c
[23:58:35] <jbossbot> git [jboss-as] 9e75d09.. Rémy Maucherat Add AS 6 workaround to allow context-root path which don't start with '/'.

   March 18, 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 | >