March 11, 2011 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 11, 2011 NOTICE: This channel is no longer actively logged.
[00:04:31] *** stuartdouglas has quit IRC[00:10:36] *** smcgowan has quit IRC[00:16:54] *** jpearlin has joined #jboss-as7[00:20:08] *** adietisheim has quit IRC[00:23:00] *** rmaucher has quit IRC[00:34:46] *** frainone has joined #jboss-as7[00:34:47] *** ChanServ sets mode: +v frainone[00:36:09] *** aslak has quit IRC[00:36:18] *** ALR has quit IRC[00:43:34] <frainone> dmlloyd: should I create a new POST_MODULE Phase for WebService injection?[00:43:53] <dmlloyd> yeah[00:44:03] <dmlloyd> baileyje's recent @EJB commit might also be informative[00:44:08] <dmlloyd> it's another very similar thing[00:44:40] <frainone> yeah, it is being helpful to fill in some gaps[00:45:36] *** miclorb has quit IRC[01:20:56] *** bstansberry is now known as bstans_afk[01:32:15] *** laubai has joined #jboss-as7[01:52:54] *** rawbdor has quit IRC[02:23:35] *** bstans_afk is now known as bstansberry[02:34:33] *** jamezp has left #jboss-as7[02:36:23] *** smarlow has joined #jboss-as7[02:36:24] *** ChanServ sets mode: +v smarlow[02:37:11] <smarlow> Nihility: I don[02:37:58] <Nihility> Hi[02:38:00] <smarlow> Nihility: I don't think JPA specifies that we should be able to run without a JTA[02:38:09] <smarlow> Hi :)[02:38:19] <smarlow> things are going well here by the way[02:38:27] <Nihility> That's what I was going to ask[02:38:38] <smarlow> a long day but successful[02:39:21] <Nihility> Good to hear[02:40:24] <baileyje> dmlloyd, Nihility : Ok. I am back. Was gone for a bit.[02:40:57] <Nihility> smarlow: So are you calling it a night then?[02:41:32] <smarlow> Nihility: I'll send you a pm[02:42:50] *** miclorb has joined #jboss-as7[02:52:42] <smarlow> so, anything that others can do, that helps jpa integrate into standard as7 stuff that I am still learning. maybe those types of things are more quickly done that way. if anyone wants to plug in the jpa logic too, that is cool to but I think I can get that done[03:02:43] *** JimMa has joined #jboss-as7[03:47:39] *** jpearlin has left #jboss-as7[03:53:09] *** fnasser has quit IRC[03:56:22] *** pferraro has joined #jboss-as7[03:56:22] *** ChanServ sets mode: +v pferraro[04:23:03] *** mbg is now known as mbg|away[04:29:15] *** pferraro has quit IRC[04:40:29] *** bgeorges has joined #jboss-as7[04:40:29] *** ChanServ sets mode: +v bgeorges[04:48:48] *** mbg|away is now known as mbg[05:15:09] *** irooskov has quit IRC[05:15:13] *** smarlow has quit IRC[05:39:50] *** miclorb has quit IRC[05:46:03] *** jwulf has joined #jboss-as7[06:23:18] *** mbg is now known as mbg|away[06:39:31] *** Nihility has quit IRC[06:39:32] *** Nihility_ has joined #jboss-as7[06:39:32] *** ChanServ sets mode: +v Nihility_[06:53:21] *** Nihility_ has quit IRC[07:02:19] *** bstansberry has quit IRC[07:08:36] *** Nihility has joined #jboss-as7[07:08:36] *** ChanServ sets mode: +v Nihility[07:38:14] *** opalka has joined #jboss-as7[07:38:14] *** ChanServ sets mode: +v opalka[07:42:44] <opalka> morning[08:09:00] *** jfclere has joined #jboss-as7[08:09:01] *** ChanServ sets mode: +v jfclere[08:26:58] *** stalep has joined #jboss-as7[08:51:48] *** jcosta has joined #jboss-as7[08:55:29] *** asoldano has joined #jboss-as7[08:55:29] *** ChanServ sets mode: +v asoldano[09:02:26] *** jwulf has quit IRC[09:16:30] *** bgeorges has quit IRC[09:21:23] *** tdiesler has joined #jboss-as7[09:21:23] *** ChanServ sets mode: +v tdiesler[09:23:10] <tdiesler> frainone, ping[09:33:22] *** emuckenhuber has quit IRC[09:34:29] *** jma has joined #jboss-as7[09:34:29] *** JimMa has quit IRC[09:35:15] *** jcosta has quit IRC[09:35:39] *** jcosta has joined #jboss-as7[09:38:35] *** tdiesler has quit IRC[09:38:59] *** tdiesler has joined #jboss-as7[09:38:59] *** ChanServ sets mode: +v tdiesler[09:39:43] *** aslak has joined #jboss-as7[09:39:43] *** aslak has joined #jboss-as7[09:39:43] *** ChanServ sets mode: +v aslak[09:41:02] *** alesj has joined #jboss-as7[09:42:43] *** wolfc has joined #jboss-as7[09:42:43] *** ChanServ sets mode: +v wolfc[09:43:07] <wolfc> Hudson has reproduced the race condition I found earlier: http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x/675/testReport/org.jboss.as.test.embedded.demos.managedbean/ManagedBeanTestCase/org_jboss_as_test_embedded_demos_managedbean_ManagedBeanTestCase/[09:44:26] <wolfc> I spotted another similar issue w.r.t. class loading in the MB test. Lost the log though while trying to reproduce.[09:50:42] *** epbernard has joined #jboss-as7[09:50:52] *** ChanServ sets mode: +v epbernard[09:58:50] *** emuckenhuber has joined #jboss-as7[09:58:50] *** emuckenhuber has joined #jboss-as7[09:58:50] *** ChanServ sets mode: +v emuckenhuber[10:08:42] *** Jaikiran has joined #jboss-as7[10:08:43] *** ChanServ sets mode: +v Jaikiran[10:16:13] *** dimitris_ has joined #jboss-as7[10:16:14] *** dimitris_ has joined #jboss-as7[10:16:14] *** ChanServ sets mode: +v dimitris_[10:20:02] *** adietisheim has joined #jboss-as7[10:25:36] *** AndyTaylor has joined #jboss-as7[10:25:36] *** ChanServ sets mode: +v AndyTaylor[10:30:54] *** tdiesler has quit IRC[10:37:49] *** AndyTaylor has quit IRC[10:40:53] *** kkhan has joined #jboss-as7[10:40:54] *** ChanServ sets mode: +v kkhan[10:56:11] *** tdiesler has joined #jboss-as7[10:56:12] *** ChanServ sets mode: +v tdiesler[11:02:17] *** maxandersen has joined #jboss-as7[11:02:17] *** ChanServ sets mode: +v maxandersen[11:02:21] *** tdiesler has quit IRC[11:03:30] *** tdiesler has joined #jboss-as7[11:03:30] *** ChanServ sets mode: +v tdiesler[11:35:09] *** opalka has quit IRC[11:36:11] *** opalka has joined #jboss-as7[11:36:12] *** ChanServ sets mode: +v opalka[11:47:24] *** tdiesler has quit IRC[11:47:29] *** tdiesler1 has joined #jboss-as7[11:49:05] *** tdiesler1 has quit IRC[11:56:27] *** epbernard has quit IRC[11:59:03] *** rmaucher has joined #jboss-as7[12:09:45] *** epbernard has joined #jboss-as7[12:09:45] *** epbernard is now known as emmanuel[12:09:46] *** ChanServ sets mode: +v emmanuel[12:15:12] *** AndyTaylor has joined #jboss-as7[12:15:12] *** ChanServ sets mode: +v AndyTaylor[12:18:15] *** jma has quit IRC[12:19:29] *** dimitris_ has quit IRC[12:25:33] *** jwulf has joined #jboss-as7[12:29:00] <rmaucher> hi[12:29:34] <rmaucher> the inclusion of an ever expanding list of tests that "have" to run as part of the build process is making things build slow[12:36:08] *** stuartdouglas has joined #jboss-as7[12:36:09] *** ChanServ sets mode: +v stuartdouglas[12:49:44] *** darranl has joined #jboss-as7[12:49:44] *** darranl has joined #jboss-as7[12:49:44] *** ChanServ sets mode: +v darranl[12:53:32] *** bgeorges has joined #jboss-as7[13:02:25] *** asoldano is now known as asoldano_lunch[13:22:32] <wolfc> I agree with rmaucher. We should only be running EJB tests. ;-) The ServerInModuleStartupTestCase and JSFTestCase take too long.[13:22:56] <rmaucher> lol, non ;) we don't need any EJB tests either :D[13:24:08] *** hbraun has joined #jboss-as7[13:24:28] *** smarlow has joined #jboss-as7[13:24:29] *** ChanServ sets mode: +v smarlow[13:28:56] <smarlow> wolfc: Hi, I talked to Nihility last night about leaving the XPC support out for Monday's tagging. If you happen to have interceptor code that can merge in, that is great too. I hacked together the basic non-tx transactional PC support but haven't tested it yet. I'm going to hack together the tx support and then try and do some testing. I'm sure there will be bugs, so best to use the remaining time to find/fix them. :)[13:29:25] <wolfc> smarlow, we don't have lifecycle callbacks[13:29:37] <wolfc> that needs to be fixed firsts[13:30:02] <wolfc> on my branch I have transacted beans[13:30:53] <smarlow> cool, so not having transacted beans on master, will make testing easier :)[13:31:31] <wolfc> as long as you write up spec compliant integration tests you should be okay[13:32:13] <smarlow> wolfc: sounds good, I assume that means using ARQ. which I already have a start at[13:32:49] <smarlow> wolfc: I have no idea what ARQ tests can support at this point though.[13:33:17] <wolfc> I was actually thinking about: @TransactionAttribute(NOT_SUPPORTED)[13:33:39] <wolfc> That will give you non-transacted beans all the way.[13:33:44] <smarlow> sounds good, I get it now. :)[13:33:45] <wolfc> Take a look at the ejb3 demo.[13:34:44] <smarlow> wolfc: should I create a demo like ejb3 or can I do my testing in testsuite/integration?[13:34:45] *** smcgowan has joined #jboss-as7[13:34:46] *** ChanServ sets mode: +v smcgowan[13:35:24] <wolfc> Probably a bit of both. I haven't done any integration test yet.[13:35:56] *** jhalliday has joined #jboss-as7[13:36:22] <smarlow> wolfc: sounds good, I'll start with a demo. Do the demos start an AS instance? If yes, maybe I can enable debugging through standalone.conf with a demo.[13:36:54] <wolfc> by default the demo uses an AS that is manually started.[13:37:22] <wolfc> a demo can be extended with a smoke-test, but we don't want that for JPA. It is too slow to boot.[13:40:17] <smarlow> wolfc: cool, sounds good. In the demo resource tree, I see a few ejb3 archives (ejb3-example.jar + ejb3-mbean.sar). Do you know if they are both part of the ejb3 demo?[13:41:11] <wolfc> Yes, right now we don't have remoting, so a demo must go through a MBean. This is in contrast to Arq which runs within the AS.[13:44:47] *** slaboure has joined #jboss-as7[13:50:39] *** mmoyses has joined #jboss-as7[13:50:39] *** ChanServ sets mode: +v mmoyses[13:56:23] *** dimitris_ has joined #jboss-as7[13:56:23] *** ChanServ sets mode: +v dimitris_[14:08:26] *** tdiesler has joined #jboss-as7[14:08:26] *** ChanServ sets mode: +v tdiesler[14:13:45] *** echelog-2` has joined #jboss-as7[14:13:45] -pratchett.freenode.net- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp[14:14:12] <tdiesler> Hi Flavia, I'd like to talk to you about https://issues.jboss.org/browse/MODULES-65[14:14:17] <jbossbot> jira [MODULES-65] Deadlock when LocalLoader attempts a circular class load [Open (Unresolved) Bug, Major, Thomas Diesler] https://issues.jboss.org/browse/MODULES-65[14:14:49] <frainone> sure[14:15:37] *** asoldano_lunch is now known as asoldano[14:15:39] <tdiesler> basically what we have in OSGi is the notion of lazy activation which gets triggered (among other things) by a class load from a bundle[14:16:27] <tdiesler> The way this is currently implemented is by means of a hook into the LocalLoader like demonstrated by the test case[14:17:04] <tdiesler> As dml points out, this is a hook into the class definition[14:17:18] *** hbraun has quit IRC[14:17:31] <tdiesler> and as it seems we cannot trigger another possibly circular class load from here[14:17:31] <frainone> so, are you saying that a LocalLoader will attempt to load another class different than the one the LocalLoader was requested to load?[14:17:44] <tdiesler> yes[14:17:51] <tdiesler> it activates the bundle[14:18:04] <tdiesler> the BundleActivator may load other classes[14:18:12] <frainone> hm... yes, you cannot trigger it as you did in the test[14:18:18] <tdiesler> and possibly the one that triggered it in a circular way[14:18:28] <frainone> the JDK won't allow it :([14:19:07] <tdiesler> ok, we then need to find some other hook mechanism[14:19:11] *** jpederse has joined #jboss-as7[14:19:23] <tdiesler> into the the class load from a module[14:20:02] <tdiesler> ideally some AfterClassLoadHook[14:20:10] *** jpederse has quit IRC[14:20:10] *** jpederse has joined #jboss-as7[14:20:13] *** echelog-2 has quit IRC[14:20:22] <tdiesler> perhaps you have an idea on how to do this with the current API[14:20:42] <frainone> hm... I see. So, if you had a hook called after the class been loaded, it would fullfill your needs?[14:21:55] <tdiesler> yes[14:22:18] <frainone> from my point of view, it could be done. And your test would be the perfect start point to figure what pieces are needed[14:23:07] <frainone> still, we need dmlloyd input on this[14:24:16] <tdiesler> ok, have a look at ModuleManagerPluginImpl:280[14:24:30] <tdiesler> in jbosgi-framework[14:24:46] <tdiesler> for the whole story. There are filters involved too[14:27:01] <tdiesler> Another good starting point is "4.4.6.2 Lazy Activation Policy" in the OSGi 4.2 Core spec[14:27:52] <frainone> ok, I'll take a look at that later :)[14:29:57] <tdiesler> frainone, I captured our conversation here: https://issues.jboss.org/browse/MODULES-65?focusedCommentId=12587406#comment-12587406[14:29:59] <jbossbot> jira [MODULES-65] Deadlock when LocalLoader attempts a circular class load [Open (Unresolved) Bug, Major, Thomas Diesler] https://issues.jboss.org/browse/MODULES-65[14:31:09] <frainone> tdiesler: tx[14:35:41] *** balunasj has joined #jboss-as7[14:35:41] *** balunasj has joined #jboss-as7[14:35:41] *** ChanServ sets mode: +v balunasj[14:50:51] <dmlloyd> good morning[14:52:23] <tdiesler> dmlloyd, moin[14:53:20] <tdiesler> dmlloyd, do you have some spare time to talk about MOD65 & MOD69 ?[14:54:04] <dmlloyd> sure, I just read the previous conversation[14:54:33] <asoldano> stuartdouglas, ping[14:55:42] <tdiesler> dmlloyd, in a parallel thread could you pls pull https://github.com/jbosgi/jboss-as/commit/8e504ed20d99c94d407676c791f9a0735831d95c and https://github.com/jbosgi/jboss-as/commit/c9ead7b5e5f7dd1b4ffde1b68af8e410861dae09[14:55:43] <jbossbot> git [jboss-as] 8e504ed.. Thomas Diesler [JBAS-8940] OSGi webapps processed by web subsystem[14:55:44] <jbossbot> jira [JBAS-8940] OSGi webapps processed by web subsystem [Resolved (Done) Bug, Major, Thomas Diesler] https://issues.jboss.org/browse/JBAS-8940[14:55:44] <jbossbot> git [jboss-as] c9ead7b.. Thomas Diesler Cleanup Arquillian subsystem module/artifact naming[14:55:45] <dmlloyd> for 69, do you need a way to filter resources by name, or only imports/exports between modules?[14:56:05] <tdiesler> dmlloyd, my VPN isn't working so I cant send pull requests ATM[14:56:52] <tdiesler> dmlloyd, I think the Export-Package directive applies to resources too[14:57:28] <dmlloyd> sure I'm just wondering whether we need to filter on LocalLoaders, or ResourceLoaders or both[14:59:18] <tdiesler> dmlloyd, the owner module itself should be able to load the classes/resources. The filters should be on the exporting side of the wire I think[15:00:10] <tdiesler> dmlloyd, in our case the paths that are visible for the importer[15:00:26] <tdiesler> dmlloyd, if it imports all[15:01:01] <tdiesler> dmlloyd, sorry - not only the paths but specific artifacts too i.e. classes[15:02:19] <dmlloyd> okay so the local loader itself needs to filter. That should be pretty simple.[15:02:49] *** pferraro has joined #jboss-as7[15:02:49] *** ChanServ sets mode: +v pferraro[15:03:18] <tdiesler> dmlloyd, as long as the owner module can still load the class - would that work if you filter on the local loader?[15:04:22] <dmlloyd> yeah well what I'm thinking is, I'll add a layer of filtering LocalLoaders and ResourceLoaders which can optionally decorate existing *Loaders[15:04:31] <dmlloyd> this way, things which don't filter don't pay a cost[15:05:00] <dmlloyd> so the filters will become part of the dependency spec[15:05:07] <dmlloyd> if there's a filter then it will be automatically inserted[15:06:23] <tdiesler> If you filter the LocalLoader, can the owner module still load the filtered artifacts?[15:07:19] <baileyje> good morning[15:08:08] <dmlloyd> correct tdiesler[15:08:11] <dmlloyd> good morning baileyje[15:08:45] <tdiesler> dmlloyd, correct means "yes it can" ? ;-)[15:08:50] <dmlloyd> yes[15:09:56] <tdiesler> dmlloyd, ok. and it only needs to get defined at the owner module spec. i.e. not on the dependency spec of every importer[15:10:42] <dmlloyd> okay. we could probably support it at either place, I think.[15:11:15] <tdiesler> dmlloyd, osgi only needs it for the exporter[15:11:27] <tdiesler> i.e. I filter what I show you[15:12:12] <dmlloyd> does it only need it for things it defines, or does it have to cover reexports too?[15:12:14] <baileyje> smarlow: How is JPA going?[15:12:32] <tdiesler> dmlloyd, the former[15:14:01] *** aloubyansky has joined #jboss-as7[15:14:34] <dmlloyd> tdiesler, regarding JBAS-8940 - won't this cause EE apps which also happen to have OSGi bundle information to not be able to interoperate with EE?[15:14:35] <jbossbot> jira [JBAS-8940] OSGi webapps processed by web subsystem [Resolved (Done) Bug, Major, Thomas Diesler] https://issues.jboss.org/browse/JBAS-8940[15:16:44] <tdiesler> dmlloyd, this is a separate issue which is captured here JBAS-8931[15:16:46] <jbossbot> jira [JBAS-8931] Make packages from OSGi deployments visible to EE [Open (Unresolved) Task, Major, Thomas Diesler] https://issues.jboss.org/browse/JBAS-8931[15:17:36] <tdiesler> dmlloyd, unless we decide otherwise a deployment that contains valid osgi metadata is thought to be targeted for the osgi subsystem[15:18:18] <dmlloyd> I think if we want these things to truly interoperate we can't think in terms of targeting for OSGi vs. the rest of the world - we need a way to combine the deployment sequence as much as possible[15:19:10] <tdiesler> dmlloyd, your jdbc driver is a perfect example. It will work on the osgi world but is currently not visisble to EE. I am thinking of registering a proxy module in the EE ModuleLoader that delegates to the OSGi module - more thought needs to be given however[15:19:12] <smarlow> baileyje: hi. I'm just hacking a demo together that will run in non-transactional mode. I have most of the code for that in place, just need to debug and single step through some of it, make sure stuff happens correctly. I'm sure there will be bugs and questions that I will need help with. But I'm optimistic that we should be able to pull together basic persistence context support. The extended persistence context support will come later.[15:19:42] <tdiesler> dmlloyd, yes I totally agree[15:19:51] <baileyje> smarlow: Ok. Let me know if you need anything[15:19:52] <baileyje> \[15:20:01] <dmlloyd> tdiesler, the deployment module loader can as well host OSGi modules if we need it to. We should come up with a single module loader that works for all deployment types[15:20:09] <smarlow> baileyje: thanks! :)[15:20:57] <tdiesler> dmlloyd, yes the ModuleIdentifier for deployed stuff should be unique in a global namespace[15:22:34] <tdiesler> dmlloyd, this is also true for boot time bundles. Their respective module id should be visible to EE too[15:23:48] <tdiesler> dmlloyd, priority wise I'd like to tackle Core TCK compliance first though - if you don't mind . i.e. thos two remaining MOD issues[15:24:38] *** bgeorges_ has joined #jboss-as7[15:24:38] *** bgeorges has quit IRC[15:24:55] *** jwulf has quit IRC[15:26:12] <tdiesler> dmlloyd, I just double checked Require-Bundle with directive visibility:="reexport" exports every package that the required bundle exports. So the filter should work if defined on the exporter[15:29:39] *** balunasj is now known as balunasj_away[15:33:29] *** bgeorges_ has quit IRC[15:33:47] <tdiesler> dmlloyd, do you want me to have a stab on MODULES-69 ?[15:33:49] <jbossbot> jira [MODULES-69] Allow for OSGi style Class Filtering [Open (Unresolved) Feature Request, Major, David Lloyd] https://issues.jboss.org/browse/MODULES-69[15:33:59] <dmlloyd> nah I already have work in progress on it[15:34:23] <tdiesler> ok, what about the other one? MODULES-65[15:34:27] <jbossbot> jira [MODULES-65] Deadlock when LocalLoader attempts a circular class load [Open (Unresolved) Bug, Major, David Lloyd] https://issues.jboss.org/browse/MODULES-65[15:35:21] <baileyje> dmlloyd: You mentioned something that needed to be done with ORB?[15:35:49] <dmlloyd> yeah ORB and any other implicitly injectable types outlined by EE that we missed[15:36:23] <dmlloyd> there are also some implicitly injectable ones which are dependent on the component type; hopefully your solution works for those as well[15:37:08] *** fnasser has joined #jboss-as7[15:37:18] <baileyje> Yeah. That is what I am looking at. There are managed beans, which would be a @Resource with component as the type.[15:37:35] <dmlloyd> well I'm thinking specifically of e.g. EJBContext[15:37:36] <baileyje> Orb would really just be injecting a service right?[15:37:40] <dmlloyd> right[15:37:51] <dmlloyd> jboss.org[15:37:54] <dmlloyd> dammit did it again[15:37:56] <dmlloyd> jboss.orb[15:38:04] <baileyje> where does the EJBContext come from?[15:38:13] <dmlloyd> I have no idea :)[15:38:23] *** bstansberry has joined #jboss-as7[15:38:24] *** ChanServ sets mode: +v bstansberry[15:38:24] <dmlloyd> presumably it is available at component create time[15:38:32] <dmlloyd> component instance create I mean[15:38:46] <dmlloyd> so there'd be no dependency[15:39:09] <dmlloyd> we just need to make sure that EJB can hook into it somehow - a special BindingSource perhaps[15:40:08] <baileyje> Yeah. I was thinking we could have a generic binding source that gets set for any @Resource that does not have a known type or a lookup/mappedName[15:40:31] <baileyje> The binding source would then need to be resolved at a later time.[15:40:55] <baileyje> The issues, is how do the other subsystem get involved to determine how to resolve[15:41:19] <dmlloyd> yeah we'd need some kind of registry[15:41:46] <dmlloyd> things like EJBContext are different though, they're only valid for their component type[15:41:52] <dmlloyd> I'm not sure how that would affect the idea[15:42:24] <baileyje> RIght. The other subsystems could add processors that check for unresolved sources and see if they can fix it.[15:42:36] <baileyje> That is the way MBs used to do it, but it was not in a generic way[15:42:44] *** kkhan has quit IRC[15:44:35] <dmlloyd> well for things which are globally bound like ORB we can just use the static map we have now[15:44:49] <dmlloyd> for the time being[15:45:03] <baileyje> Right. But more likely a static map with service names and not jndi names[15:45:06] <dmlloyd> maybe we can do something static for the EJB ones too for now, just to get it working[15:45:26] <dmlloyd> yeah service names might be better[15:45:56] <wolfc> EJBContext is a 'global' binding[15:46:44] <wolfc> https://github.com/jbossejb3/jboss-ejb3/blob/master/context/naming/src/main/java/org/jboss/ejb3/context/naming/EJBContextBinder.java[15:46:45] <baileyje> dmlloyd: Otherwise there could be a way to have the subsystems pre-register something to help resolve the resource injections[15:46:56] <wolfc> But it requires refactoring[15:47:26] <wolfc> Basically there are 4 EJBContext: global, component, instance and invocation[15:48:58] *** opalka has quit IRC[15:49:24] <dmlloyd> @Resource SessionContext as well[15:49:35] <wolfc> SessionContext == EJBContext[15:49:53] <wolfc> https://github.com/jbossejb3/jboss-ejb3/blob/master/context/naming/src/main/java/org/jboss/ejb3/context/naming/EJBContextObjectFactory.java[15:50:01] <dmlloyd> okay so in that case we actually would use a JNDI name[15:50:04] <wolfc> The easiest way out is always pick the invocation EJBContext[15:50:09] <dmlloyd> okay, that makes it pretty easy really[15:50:26] <wolfc> And let that one delegate to the proper one[15:50:32] <dmlloyd> we can just have a static map of type->JNDI name (like we do) and just make sure all the injectable things are in JNDI (which they should be)[15:50:36] <dmlloyd> baileyje: wdyt?[15:50:46] *** kkhan has joined #jboss-as7[15:50:48] <baileyje> is it enough to add "java:internal/EJBContext to the list[15:50:54] *** ChanServ sets mode: +v kkhan[15:51:03] <wolfc> Yes, the injection framework would then be done[15:51:06] <dmlloyd> it'd be java:comp/EJBContext would it not?[15:51:17] <dmlloyd> dammit my chrome has gone braindead, one min[15:51:22] <wolfc> java:comp/EJBContext (LinkRef ->) java:internal/EJBContext[15:51:23] <baileyje> it would be whatever wolfc say it will be.[15:51:41] <wolfc> basically a hardcoded @Resource.lookup[15:51:51] <baileyje> but java:comp would make the most sense in this case.[15:52:25] <dmlloyd> what's the deal with java:internal, where did that come from[15:52:30] <baileyje> dmlloyd: Do you think we should handle ORB the sam way?[15:52:40] <dmlloyd> ORB should be bound in JNDI[15:53:12] <dmlloyd> java:comp/ORB[15:53:21] <dmlloyd> the IIOP subsys will ensure that[15:53:30] <baileyje> ok. So basically we are left with ManagedBeans(or any component really). Any other should be added to the static list[15:53:35] <baileyje> s/list/map[15:53:40] <dmlloyd> yeah it looks that way[15:54:03] <baileyje> and MBs can be solved the same way as the @EJB is now[15:54:14] <baileyje> so we can pull a generic BindingSource for that[15:54:16] <dmlloyd> yeah, though probably quite a bit simpler :)[15:54:39] <dmlloyd> I think that MBs and session/singleton EJBs are the only bindable component types[15:54:58] <dmlloyd> (and maybe 2.x entity beans?)[15:55:10] *** mbg|away is now known as mbg[15:55:18] <baileyje> Ok. This is the current static list. http://pastebin.com/UrdmAYat[15:55:32] <baileyje> lets list out all the things we are missing so I can add them in[15:55:37] <dmlloyd> ORB for sure[15:55:57] <wolfc> java:internal is just something I came up with. Because it's easier for Switchboard to handle stuff that is already in JNDI.[15:56:07] <wolfc> AS 7 can do stuff more directly on java:comp[15:56:08] <baileyje> Do we want to cheat and add the EJBContext, etc here?[15:56:09] <dmlloyd> persistence unit/persistence context[15:56:25] <dmlloyd> yeah baileyje I'd say, that'd make things a lot easier[15:56:57] *** AndyTaylor has quit IRC[15:56:59] <baileyje> PU and PC need to be qualified correct? It takes a bit more to determine which one[15:57:23] <baileyje> I don't think there is anything nice like "java:comp/..." for it[15:57:43] <baileyje> well not that could be resolved simply by type[15:58:20] <wolfc> PU and PC need to be bound to a globally unique name, if you want to refer it over JNDI[15:58:44] <wolfc> Jaikiran, how did we do PU/PC in Switchboard?[15:58:52] <wolfc> No global binding as I recall[15:59:44] <baileyje> Yeah. I was just referring to the fact they have to have a unique name.[15:59:52] <baileyje> Which won't work for the static bindings[16:01:19] <baileyje> For somethings like PUs and MBs it may still be nice to have a registry of all the non-resolved @Resources and allow other processors to handle them down the line[16:01:48] <dmlloyd> yeah I don't think there's a default name[16:02:07] <tdiesler> dmlloyd, any comment on MODULES-65 (which is the TCK blocker for us) ;-)[16:02:10] <jbossbot> jira [MODULES-65] Deadlock when LocalLoader attempts a circular class load [Open (Unresolved) Bug, Major, David Lloyd] https://issues.jboss.org/browse/MODULES-65[16:02:26] <baileyje> If it can't be globally resolved to a jndi name, then we should just register it and let it get handled by other subsystems. If at component creation time there are still unresolved, it is a deployment error.[16:03:08] <wolfc> on another topic, I fiddled with the generics in msc: https://github.com/wolfc/jboss-msc/compare/6decb14ee47d1e0a53b0...master[16:03:13] <dmlloyd> env-entry types should be allowed to be unresolved[16:04:08] <dmlloyd> wolfc, you can't change service builder like that; it can't ensure type-safety[16:04:18] <dmlloyd> that's why you have the variations which accept a Class[16:04:33] <dmlloyd> changing Injector<? super I> to <I> is reasonable though[16:04:58] <dmlloyd> when a service is injected, you can only be sure that it is an Object[16:05:07] <dmlloyd> anything more specific has to be runtime-checked[16:05:39] <dmlloyd> also, * imports? for shame :)[16:06:06] <wolfc> ah crap. I had to wipe my intellij config to make it come back up again.[16:06:23] <dmlloyd> if you can reframe this is as only changing ? super I -> I and not adding @Override or moving imports or whatever I'll merge it[16:06:42] <wolfc> why not add @Override?[16:06:48] <dmlloyd> because it confuses the patch[16:07:00] <wolfc> :-)[16:07:03] <dmlloyd> if you want to do a patch which is a project-wide @Override add and nothing else I'll consider it[16:07:06] <dmlloyd> but it should be separate[16:07:12] <wolfc> Right, I'll remove it[16:07:38] <wolfc> Eclipse & Intellij have a different notion of import ordering, which is also a bitch[16:07:51] <frainone> dmlloyd, asoldano: I'm assuming I should be using the same web service spi classes that have been used in AS6 for WebServiceRef injection. Is that alright?[16:07:52] <dmlloyd> I'm not a fan of @Override though because it adds a lot of clutter and is very rarely useful (IDE refactors really eliminate the need for it most of the time)[16:08:34] <wolfc> Intellij can identify methods that are not in use properly. Eclipse doesn't as I recall from long ago.[16:08:43] <dmlloyd> frainone: I do not know. I think some things came over from WS[16:10:25] <asoldano> frainone, you should be looking at the 4.0.0.SNAPSHOT version of jbossws-spi[16:10:55] <asoldano> frainone, sorry, 2.0.0-SNAPSHOT[16:11:10] <dmlloyd> baileyje: you figure you can have that sorted out today sometime?[16:11:24] <baileyje> Yeah.[16:11:33] <baileyje> Should be today for sure[16:12:00] <frainone> asoldano: tx, I'll take a look[16:12:11] <dmlloyd> okay, great.[16:13:18] <asoldano> frainone, ok, any question either ping me or ropalka[16:14:21] <frainone> asoldano: I sure will :)[16:18:54] <bstansberry> darranl: If I understand your e-mail correctly, you think management-interface is OK? It's a bit overloaded but not terribly so.[16:20:54] <bstansberry> emuckenhuber, kkhan: how are things?[16:21:07] <emuckenhuber> bstansberry: https://github.com/emuckenhuber/jboss-as/commit/ece0513c7e0924738abecfd66894930960be4f2e[16:21:08] <jbossbot> git [jboss-as] ece0513.. Emanuel Muckenhuber host level ops[16:21:40] <emuckenhuber> bstansberry: that's at least for the local host ops[16:21:49] <emuckenhuber> well i hope it's supposed to be that easy ;)[16:21:57] <kkhan> I've done https://github.com/kabir/jboss-as/commit/edf290d24f5cc32f4ac58f1ed6693325d8f08d57[16:21:57] <jbossbot> git [jboss-as] edf290d.. kabir Fix problems calling operations targetted for a particular host with remote slaves...[16:22:32] <kkhan> I used to get errors executing host=local,server=server-one:read-resource[16:22:40] <kkhan> but now the result is empty[16:22:47] <kkhan> this is with remote slaves[16:22:56] <bstansberry> kkhan: hmm, so is that progress ;)[16:22:58] <bstansberry> ?[16:23:21] <kkhan> I thought so until I discovered that the results are undefined :-)[16:23:53] <bstansberry> I think the result should be the root node of the server resource[16:24:08] <kkhan> Just checking with a master only[16:24:11] <bstansberry> sorry, root resource of the running server[16:24:20] <kkhan> Yes that works[16:24:31] <kkhan> Still works[16:24:40] <kkhan> so there is slight progress on the remote case[16:25:03] <bstansberry> ok, progress is good :)[16:25:17] <kkhan> Also, when I tried your domain messaging (or whatever it was) demo with a remote slave it just hung[16:25:29] <darranl> hi bstansberry yeah - management-interface(s) doesn't sound as bad - at least from an administrator perspective it is back to English and not an acronym ;-)[16:26:48] <bstansberry> darranl, Nihility: ok, the proposal on the table is "management-interfaces" replaces "management-apis" and in the child elements "xxx-api" becomes "xxx-interface"[16:27:07] <bstansberry> objections can be raised until 10:30 AM EST[16:27:25] <bstansberry> after which the gavel will come down and the motion will carry[16:28:43] <bstansberry> emuckenhuber: with the routing change, if the request is for the local host but is one of the read-only ones, will it fall into the multi-host logic?[16:28:46] <darranl> For anyone not as closely involved in the discussions it is the name to be used for this Jira JBAS-8942[16:28:48] <jbossbot> jira [JBAS-8942] Rename <management> element to <management-apis> in both host.xml and standalone.xml [Coding In Progress (Unresolved) Task, Major, Darran Lofthouse] https://issues.jboss.org/browse/JBAS-8942[16:29:10] <kkhan> Isn't interface overloaded in that we use that word for actual network interfaces?[16:29:22] <kkhan> i.e interface = address[16:29:36] <bstansberry> yes, that's the overloading part[16:29:46] <darranl> we are open for suggestions if anyone can think of a better name ;-)[16:29:50] <emuckenhuber> bstansberry: that's what i'm currently trying to figure out[16:30:05] <kkhan> How about management-thingy?[16:30:07] <darranl> But interface is the I part of API so has some relationship there[16:30:13] <kkhan> :-)[16:30:14] <emuckenhuber> kkhan: i was about to propose the same[16:30:15] <emuckenhuber> :)[16:30:41] <bstansberry> yes, you like to call things "thingy"[16:30:43] *** tdiesler has quit IRC[16:30:59] <bstansberry> what I enjoy most is when you use the term "thingy" i always know what you mean[16:31:10] <darranl> thingy does make some more sense - at least it is not overloaded here ;-)[16:31:40] *** tdiesler has joined #jboss-as7[16:31:40] *** ChanServ sets mode: +v tdiesler[16:31:50] <wolfc> dmlloyd, okay gone full circle. I now know why we have a addDependency(ServiceName, Injector<Object>) :-) https://github.com/wolfc/jboss-msc/compare/6decb14ee47d1e0a53b0...master[16:31:56] <darranl> the alternative I saw was connectors as we have used that word in a couple of locations for server exposed connections[16:32:13] <kkhan> socket? It is interface + port[16:32:18] <bstansberry> I like "doohickey" but I suspect that's too much of an North American-ism[16:32:20] <darranl> so management-connectors, http-connector, native-connector[16:32:43] <darranl> bstansberry, sounds even better than thingy ;)[16:32:44] <bstansberry> kkhan: I think it will end up being more than a pure socket config[16:32:52] <kkhan> connector sounds good[16:33:05] <wolfc> oh crap still two @Overrides[16:33:25] <darranl> yes at the very least in addition to the port I am planning it will have some 'connector' specific security settings e.g. which realm it relates to[16:35:08] <tdiesler> kkhan, the smoke tests are quite slow - any idea why that would be?[16:35:28] <kkhan> Nope[16:35:49] <darranl> So the choice is management-apis, management-interfaces, management-connectors - I think we will have to drop management-thingys and management-doohickeys. Till 10:40 EST to vote?[16:35:55] <dmlloyd> wolfc: and whitespace and import reorgs ;)[16:36:28] <wolfc> dmlloyd, I removed the whitespaces for you and ordered the imports properly :-P[16:36:35] <kkhan> tdiesler: ServerInModuleStartupTestCase is slow because one of the tests deploys to the deployment directory so we wait for the scanner to kick in[16:36:40] <bstansberry> do you see this definition moving further away from the "connector" notion? "interface" is sufficiently broad to cover the entire use case; it's how people interface with the system to manage it. "connector" is more limited in scope to the "connecting" aspect[16:37:00] <kkhan> And the JSF one is slower as well but I don't know much about JSF itself so I can't really say[16:37:09] <kkhan> tdiesler: Any others bothering you?[16:37:23] <alesj> dmlloyd: ping?[16:37:51] <alesj> dmlloyd: deploying weld app in my jetty+as hack results in cycling[16:37:51] <darranl> personally I am happy with interfaces - it's primary purpose is to expose a management 'thing' over an interface[16:38:10] <alesj> dmlloyd: the app gets stopped, restarted, etc ...[16:38:24] <alesj> dmlloyd: a known issue — as I haven't rebased yet[16:38:40] <alesj> i mean, is it a known issue?[16:38:45] <tdiesler> kkhan, build time doubled over the last six weeks http://jbmuc.dyndns.org:8280/hudson/job/JBoss-7.0.0/buildTimeTrend[16:39:18] <darranl> in the future the http-interface could have multiple contexts defined - but doesn't really change if interface or connector makes sense[16:39:48] <dmlloyd> alesj: that's weird[16:40:02] <dmlloyd> alesj: can you pastebin a sampling of your logs?[16:40:10] <wolfc> that reminds me of: http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x/675/testReport/junit/org.jboss.as.test.embedded.demos.managedbean/ManagedBeanTestCase/org_jboss_as_test_embedded_demos_managedbean_ManagedBeanTestCase/[16:40:12] <dmlloyd> it might be a management issue, somehow rolling back is failing[16:40:27] <wolfc> there is a race condition in the deployment[16:41:24] <wolfc> that trace is not reproducable, alesj, does it look like this?[16:41:27] <dmlloyd> wolfc, that issue is fixed in MSC[16:41:33] <wolfc> ah okay, never mind me[16:41:35] <kkhan> More tests I guess + more modules[16:41:38] <darranl> bstansberry, maybe it is only overloaded because the other should have been <network-interfaces>[16:41:41] <dmlloyd> though the same stack frames repeat, it's not actually a loop[16:41:53] <wolfc> nested service enablement?[16:41:54] <dmlloyd> it's because you're that many layers deep in parent/child services[16:42:16] <dmlloyd> so each layer of service target gets a chance to apply its listeners and dependencies[16:42:33] <alesj> there is no error, just looping ...[16:42:47] <bstansberry> bang goes the gavel. management-interfaces it is[16:42:48] <dmlloyd> alesj: looping how? you mean high CPU usage?[16:42:55] <alesj> http://pastebin.com/w387XAig[16:42:56] <kkhan> Yeah, I don't think the overloading matters that much[16:43:03] <bstansberry> darranl: yeah, good point[16:43:10] *** jamezp has joined #jboss-as7[16:43:37] <wolfc> I have rebased onto the new component injection map. https://github.com/wolfc/jboss-as/commits/ejb3-ee[16:43:41] <dmlloyd> alesj: this looks like a problem in the deployment plan code[16:43:42] <bstansberry> I'll raise that in my response to you on the email thread[16:43:50] <dmlloyd> bstansberry: do you know who the current expert is on that stuff?[16:44:06] *** maxandersen has quit IRC[16:44:09] <bstansberry> that would be me[16:44:11] <dmlloyd> 16:32:34,463 ERROR [org.jboss.as.deployment] (pool-6-thread-1) Cannot remove deployment content file C:\development\git-root\jboss-as-jetty\build\target\jboss-7.0.0.Alpha2\standalone\deployments\weld-permalink.war <- I think this is the relevant line[16:44:16] <darranl> thanks all, I will update the Jira[16:44:18] <dmlloyd> probably the FS scanner actually[16:44:25] <dmlloyd> windows locking issue maybe?[16:44:34] <alesj> dmlloyd: yeah, but what's the error?[16:44:36] <dmlloyd> anyway it fails to remove the deployment and then it sees it, thinks it's new, and deploys it again[16:44:39] <alesj> that actually makes it stop[16:44:45] <dmlloyd> then it fails, tries to roll back the deployment[16:44:53] <dmlloyd> deployment is locked, rinse repeat[16:44:57] <alesj> yup[16:44:58] <bstansberry> if it's the FS scanner, it will all be replaced today[16:45:02] <dmlloyd> ah ok[16:45:03] <dmlloyd> good :)[16:45:06] <alesj> :-)[16:45:19] <alesj> but what's the error that makes it stop in the first place?[16:45:37] <jbossbot> git [jboss-as] push master 8e504ed.. Thomas Diesler [JBAS-8940] OSGi webapps processed by web subsystem[16:45:38] <jbossbot> jira [JBAS-8940] OSGi webapps processed by web subsystem [Resolved (Done) Bug, Major, Thomas Diesler] https://issues.jboss.org/browse/JBAS-8940[16:45:38] <jbossbot> git [jboss-as] push master c9ead7b.. Thomas Diesler Cleanup Arquillian subsystem module/artifact naming[16:45:39] <jbossbot> git [jboss-as] push master 8f871ff.. David M. Lloyd [JBCTS-1083] Add some missing deps[16:45:39] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c71f978...8f871ff[16:45:43] <bstansberry> I need to read the earlier part of the thread to understand the context; 1 sec[16:45:55] <dmlloyd> 16:32:34,731 ERROR [stderr] (MSC service thread 1-2) 2011-03-11 16:32:34.731:INFO::started o.e.j.w.WebAppContext{/weld-permalink,org.jboss.as.web.deployment.VFSResource at 25e12e2c},/C:/development/git-root/jboss-as-jetty/build/target/jboss-7 dot 0.0.Alpha2/bin/content/weld-permalink.war[16:45:57] <dmlloyd> I guess?[16:46:25] <dmlloyd> stuartdouglas might have an insight on what this is and why it's logged to stderr[16:46:34] <dmlloyd> it implies that there's other stuff not being logged[16:46:38] <dmlloyd> or being logged improperly[16:46:49] <dmlloyd> oh[16:46:52] <dmlloyd> that's a jetty message[16:46:55] <alesj> :-)[16:46:57] <dmlloyd> can't help you there[16:47:20] <dmlloyd> you should fix jetty logging though, make it import the log module corresponding to the API it wants to use[16:47:38] <alesj> how do i do that?[16:48:16] <alesj> i guess i should do this import as part of jboss-as-web module's imports?[16:48:29] <emuckenhuber> bstansberry: that also includes the readOnly ops: https://github.com/emuckenhuber/jboss-as/commit/80d22f4275150262e7c6cf1ba63ef96b534c6c54[16:48:29] <jbossbot> git [jboss-as] 80d22f4.. Emanuel Muckenhuber host level ops[16:49:44] <rmaucher> still using jetty, yummy :)[16:49:56] <dmlloyd> alesj: wherever you put the jetty module, add the appropriate logging API as an import[16:50:18] <alesj> rmaucher: :-) … trying to see how it compares to jbossweb inside as7[16:50:29] <rmaucher> ok :)[16:50:29] <tdiesler> dmlloyd, here is a framework update that fixes the threadpool issues we talked about yesterday https://github.com/jbosgi/jboss-as/commit/943ec31e6129ec3925ab01920405373c0e15ac7e[16:50:30] <jbossbot> git [jboss-as] 943ec31.. Thomas Diesler Update OSGi Framework - Fixes shutdown of ThreadPools and other threading issues[16:51:02] <alesj> dmlloyd: how do i add import to a module? … i guess that's what's done in build/build.xml?[16:51:40] <alesj> rmaucher: atm it's 2/3 of jbossweb :-)[16:52:03] <tdiesler> alesj, you modify modules.xml for the jetty atrifact[16:52:08] <rmaucher> what does 2/3 mean ?[16:52:20] <dmlloyd> alesj: no, edit the module.xml[16:52:29] <dmlloyd> alesj: how did you manage to add jetty without adding a module.xml??[16:52:55] <kkhan> tdiesler: Comparing http://jbmuc.dyndns.org:8280/hudson/job/JBoss-7.0.0/88/consoleFull and http://jbmuc.dyndns.org:8280/hudson/job/JBoss-7.0.0/140/consoleFull 140 a) has more modules (with possibly more unit tests) and runs 52 smoke tests (the earlier run only ran ServerInModuleStartupTestCase)[16:53:06] <alesj> dmlloyd: good question :-)[16:53:14] <alesj> i think i mostly changed build.xml[16:53:28] <dmlloyd> oh so you put the artifacts right inside the as-web module?[16:53:31] <alesj> and i directly altered web sub-project[16:53:32] <dmlloyd> gross[16:53:58] <dmlloyd> apart from CXF - which is just plain over the top - most of the time separate artifacts == separate modules[16:54:03] <rmaucher> and the motivation for doing that is what ? ditching yet another component ?[16:55:51] <alesj> that's how it's done now: https://github.com/alesj/jboss-as/blob/master/build/build.xml#L467[16:55:56] <alesj> dmlloyd: ^[16:56:09] <dmlloyd> interesting[16:56:25] <dmlloyd> oh no, and we're pulling artifacts into multiple modules[16:56:27] <dmlloyd> that's bad[16:56:37] <dmlloyd> well, that's another thing to add to the list of things to fix[16:56:39] <tdiesler> kkhan, smoke tests take Total time: 1:22.600s on my machine, which is terrible for smoke tests I think[16:57:07] <kkhan> How long did the AS 6 ones take?[16:57:32] <dmlloyd> tdiesler, I'm getting test failures with that patch[16:57:39] <dmlloyd> and they don't take 1:22 on my system more like 0:22[16:57:44] <tdiesler> kkhan, sure for every phenomena in the world there is one that is worse ;-)[16:57:52] <kkhan> :-)[16:58:03] <alesj> dmlloyd: if i add logging to that module now, would that work … afart from it that it's bad overall :-)[16:58:14] <tdiesler> kkhan, I thought we are concerned with making stuff better though[16:59:28] <dmlloyd> ah I guess it just trips that MSC problem more frequently now[16:59:38] <tdiesler> kkhan, next week I'll have some spare cycles - maybe I have a look at why server startup for smoke tests is so slow[16:59:45] <kkhan> Cool[17:00:02] <dmlloyd> alesj: add org.slf4j as a dep to jboss-as-web's module.xml and you should be okay[17:00:10] *** mbg is now known as mbg|away[17:00:24] <dmlloyd> alesj: then maybe you'll at least have a better idea of what's failing[17:01:40] <kkhan> The deployment test in ServerInModuleTestCase can probably be made faster by adjusting the deployment scanner interval[17:02:12] <tdiesler> kkhan, could you remind me again what's the purpose of that surefire-modular thing vs. the Arquillian embedded AS7 container. Is it to pass in various container configs?[17:02:26] *** balunasj_away is now known as balunasj_mtg[17:02:48] <kkhan> It is to make sure that the embedded AS starts with a classpath that is exactly the same as real AS[17:03:12] <kkhan> Without it things can creep through to the app classpath[17:03:20] <tdiesler> kkhan, but we had that with the embedded AS7 container too, no?[17:03:59] <kkhan> Almost, but you still could get leakage outside of modules[17:04:17] <kkhan> This time we start the whole test setup using Modules main[17:04:38] <kkhan> So it is *exactly* what would happen in real AS[17:04:41] <bstansberry> kkhan: that test should use a whole different scanner[17:04:49] <kkhan> Stan did something the week the other week[17:05:02] <bstansberry> right now I think it's leaving a deployment behind in build/target[17:05:19] <tdiesler> kkhan, so the ARQ AS7 containers are dead?[17:05:23] <bstansberry> better to have it scan a tmp dir[17:05:32] <kkhan> tdiesler: They are still used[17:05:39] <kkhan> The difference was before[17:06:11] <bstansberry> alesj: FYI https://github.com/bstansberry/jboss-as/tree/deployment-scanner has the updated deployment scanner that I'll probably merge later today[17:06:23] <kkhan> Client arquillian was run in the app classpath, and then the server was modular[17:06:30] <kkhan> Now EVERYTHING is modular[17:06:41] <tdiesler> kkhan, ok[17:06:46] <kkhan> Modules main -> testrunner -> Arq -> embedded AS[17:06:50] <bstansberry> to deploy foo.war you have to copy foo.war.dodeploy after you copy in the war. delete foo.war.deployed to undeploy it[17:07:26] <kkhan> Stan's issue was his thing worked when deployed into AS[17:07:48] <kkhan> but failed when trying an embedded instance due to classpath leakage[17:07:51] *** epbernard has joined #jboss-as7[17:07:52] *** ChanServ sets mode: +v epbernard[17:08:41] <jbossbot> git [jboss-as] push master 37ac12b.. Thomas Diesler Update OSGi Framework - Fixes shutdown of ThreadPools and other threading issues[17:08:42] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/8f871ff...37ac12b[17:08:43] <kkhan> tdiesler: http://community.jboss.org/wiki/JBossModulesSurefirePlugin[17:08:50] <smarlow> I committed the jpa demo to https://github.com/scottmarlow/jboss-as, it is showing that I have a dependency ordering bug (http://pastie.org/1660018)[17:09:10] <smarlow> AbstractResourceInjection.inject is being called too early[17:09:14] <alesj> dmlloyd: any idea on the exception Scott is mentioning in email thread?[17:10:00] <dmlloyd> alesj: no - maybe he's introducing some outside lib, or somehow he's out of date or something[17:10:03] <dmlloyd> we'd have to ask stuartdouglas[17:10:14] <kkhan> tdiesler: Since the tests are now run without any app classpath, there can be no leakage[17:10:16] <alesj> i'll try a clean build[17:10:18] <dmlloyd> I thought he had replaced javassist already in there[17:10:47] <alesj> nope, not yet for Weld[17:10:48] * smarlow gotta walk away for a minute[17:10:49] *** emmanuel has quit IRC[17:12:26] *** mbg|away is now known as mbg[17:13:19] <dmlloyd> smarlow: is that a hang or an exception or what?[17:13:31] *** frainone has quit IRC[17:13:47] <kkhan> tdiesler: What did you mean by :"that test should use a whole different scanner"?[17:14:38] <kkhan> I think it should be possible instead to before and after that test execute an operation to change the scan interval here: <deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir" path="deployments" />[17:14:42] <kkhan> say to 1 second[17:15:06] <tdiesler> kkhan, I didn't say that ;-)[17:15:21] <kkhan> aha[17:15:26] <kkhan> Sorry[17:15:31] <kkhan> bstansberry: ^^[17:16:03] *** asaldhan has joined #jboss-as7[17:16:03] *** ChanServ sets mode: +v asaldhan[17:16:45] <bstansberry> kkhan: I meant instead of changing the scan interval of the default scanner, use an op that add a whole new deployment-scanner element[17:16:54] <bstansberry> and point it at a tmp dir[17:17:16] <bstansberry> so we don't go copying artifacts into the build/target[17:17:38] <kkhan> ok, I see[17:17:52] <kkhan> That was actually something I wondered a bit about[17:18:16] <kkhan> since I think we change the base dir of the server, so configuration is picked up from another place[17:18:34] <kkhan> but that does not seem to include the deploy dir[17:18:48] <bstansberry> hmm, that sounds buggy[17:19:07] <kkhan> I'll create a JIRA for that one so it does not get lost[17:19:10] <bstansberry> since it's relative-to="jboss.server.base.dir"[17:20:51] <asaldhan> Nihility: dmlloyd: can we please merge the security work a little faster, please?[17:20:54] <kkhan> Might be a problem in the test setup instead[17:21:11] <asaldhan> Nihility: dmlloyd: mmoyses fixed a CCE that is showing up in JBWS testing.[17:21:33] <dmlloyd> what security work[17:21:34] <bstansberry> kkhan: File originalConfigDir = getFileUnderAsRoot(jbossHomeDir, props, ServerEnvironment.SERVER_CONFIG_DIR, "configuration");[17:21:34] <bstansberry> File orginalDataDir = getFileUnderAsRoot(jbossHomeDir, props, ServerEnvironment.SERVER_DATA_DIR, "data");[17:21:54] <dmlloyd> I've barely been in my email[17:21:57] <asaldhan> dmlloyd: mmoyses had a pull request >2 weeks ago.[17:22:01] <dmlloyd> if there's a pull request there I"ll get to it in a while[17:22:01] <bstansberry> that's why deployments isn't covered -- it's changing more fine grained suff[17:22:09] <asaldhan> dmlloyd: according to him, it is still not merged.[17:22:11] <dmlloyd> asaldhan: did someone reply to it?[17:22:21] <kkhan> Yeah, I'll investigate[17:22:24] <asaldhan> dmlloyd: dont think so.[17:22:47] <asaldhan> dmlloyd: https://issues.jboss.org/browse/JBAS-8933[17:22:49] <jbossbot> jira [JBAS-8933] ClassCastException: org.jboss.security.plugins.auth.JaasSecurityManagerBase cannot be cast to org.jboss.security.AuthorizationManager [Resolved (Done) Bug, Major, Marcus Moyses] https://issues.jboss.org/browse/JBAS-8933[17:22:59] <dmlloyd> I'll check it in a minute[17:23:00] <asaldhan> dmlloyd: that is a result of that fix not in master.[17:23:26] <dmlloyd> I'm doing a complete build and test after each merge so it takes a while to get through[17:23:50] <asaldhan> dmlloyd: no problem, man. but if we have some protocol to follow, then it will be good.[17:24:00] <asaldhan> dmlloyd: sometime we forget about pull requests that are sent. :)[17:24:12] <dmlloyd> the protocol is if it's sent to the list and no response in a day or two, bring it up here[17:24:27] <dmlloyd> because honestly I put IRC on a much higher priority than the ML[17:24:27] <asaldhan> mmoyses: take note of protocol. ^[17:24:39] <dmlloyd> I miss posts frequently on the ML[17:24:53] <asaldhan> dmlloyd: ok. np.[17:25:11] <jbossbot> git [jboss-as] push master 0a039ea.. Carlo de Wolf Fixed NPE when @Local is used standalone on the bean[17:25:12] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/37ac12b...0a039ea[17:25:19] <mmoyses> dmlloyd: i did talk to you and brian here... you just discussed if java:/jaas should be allowed and never pulled my change[17:25:54] <dmlloyd> ah, well you should be aware then that sometime after beta1, binding to java:jaas is going to stop working[17:25:58] <dmlloyd> unless that gets resolved[17:26:10] <dmlloyd> everything in your master is ready for a merge otherwise?[17:26:32] <asaldhan> dmlloyd: yeah we will figure out the java:jaas story.[17:27:34] <mmoyses> dmlloyd: i rebased my branch today and sent another pull request after it[17:27:57] <dmlloyd> okay, it's testing now[17:28:17] <aloubyansky> bstansberry: i am about to push the state machine based parsing of parameters... but the composite operation you mentioned in the email results in OFE... something with " => ""[17:29:07] <aloubyansky> bstansberry: it didn't pass model type validator validateParameter[17:29:36] <bstansberry> it's possible the command was off[17:30:53] <dmlloyd> ok this will be my last push for the morning[17:31:02] <smarlow> dmlloyd: the apply injections runs too soon it seems. I'll paste the actual exception which is more meaningful :)[17:31:08] <dmlloyd> I need to get an MSC release tagged so we can fix these intermittent issues[17:31:48] *** mmoyses is now known as mmoyses_[17:32:44] *** tdiesler has quit IRC[17:34:14] <Nihility> asaldhan: you mean the pull request at 8am?[17:35:19] <asaldhan> Nihility: I think mmoyses_'s request from 2+ weeks ago fell thru the cracks. he resubmitted again.[17:35:31] <asaldhan> Nihility: no biggie. we will be little more[17:35:35] <asaldhan> Nihility: insistent. :)[17:35:44] <smarlow> dmlloyd: http://pastie.org/1660101 has the exception and I think it could be a missing service dependency. When a @PersistenceContext annotation is processed (JPAAnnotationParseProcessor) I wonder if I missed having the injection target depend on my injection service.[17:36:08] <asaldhan> Nihility: dmlloyd is taking care of it. The reason is that a bug started showing in WS testing. :)[17:36:10] <kkhan> bstansberry: Should not ':read-resource(recursive=true)' return the model recursively?[17:36:10] <smarlow> dmlloyd: I use "phaseContext.getServiceTarget().addService(injectorName, new PersistenceContextInjectorService(annotation, puServiceName, deploymentUnit));" to add the injector service but maybe that is wrong.[17:36:34] <smarlow> I'll get a url for the code[17:37:03] <bstansberry> kkhan: yes. although I think we stopped it at proxies (at least that was discussed)[17:37:18] <kkhan> This is for a standalone server[17:37:55] <smarlow> dmlloyd, Nihility, baileyje: (not sure who wants to help) the code for ^ is here https://github.com/scottmarlow/jboss-as/blob/master/jpa/src/main/java/org/jboss/as/jpa/processor/JPAAnnotationParseProcessor.java[17:38:04] <asoldano> stuartdouglas, Nihility, dmlloyd: hi! speaking of ws testing, the issue I mentioned to Stuart some days ago regarding NPE in web layer is fixed afaics in stuartdouglas ' fork, perhaps that can be pulled into master?[17:39:27] <smarlow> dmlloyd, Nihility, baileyje: I'll debug some more...[17:39:34] <Nihility> smarlow: i can take a look[17:39:42] <baileyje> smarlow: Will the PersistenceContext and PersistenceUnit be bound into JNDI with unique entries?[17:39:50] <Nihility> wolfc: how is ejb3 looking?[17:40:31] <baileyje> basically when you set the biniding source with ServiceBindingSourceDescription the service name must exist, and will become a dependency of the component with the correct injection.[17:40:36] <wolfc> Nihility, waiting for the cmt tx interceptor merge. We don't have any lifecycle interceptor callbacks.[17:40:50] <wolfc> So the usual JPA and CDI hooks won't work yet.[17:41:33] <baileyje> smarlow: If you where to instead use a JNDI based lookup with a unique entry you could use an object factory to make sure you get the correct instance.[17:41:45] <wolfc> And we need a lot of polishing to make it really usable.[17:42:08] <jbossbot> git [jboss-as] push master 4c62bf0.. Marcus Moyses Allow backward compatibility with java:/jaas for security domains[17:42:08] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/0a039ea...4c62bf0[17:42:14] <baileyje> The service name will work as long that service exists and will allow you to get the correct instance for the component instance.[17:42:31] <Nihility> wolfc: ok before you take off for the day, can you come up with a list of stuff that you want done for it to be usable/owrth releasing[17:43:01] <Nihility> then some of us can try to fill in the holes before monday[17:43:07] <Nihility> well monday night[17:43:08] <Nihility> :)[17:44:01] <wolfc> I'll write up everything that I can think off in order of priority then we can just make a cut somewhere.[17:44:52] <wolfc> I think right now the important bit is writing up tests, so we know where we stand.[17:45:46] * wolfc is going to get some food[17:46:40] *** darranl has quit IRC[17:46:48] <smarlow> baileyje: I just looked, I hacked the binding name to something like "org.jboss.as.demos.jpa.archive.SimpleStatefulSessionBean/entityManager"[17:47:21] <asoldano> Nihility, dmlloyd: besides my question above, time for a very quick question on modules?[17:47:29] <dmlloyd> sure[17:47:40] *** darranl has joined #jboss-as7[17:47:41] *** darranl has joined #jboss-as7[17:47:41] *** ChanServ sets mode: +v darranl[17:47:42] <asoldano> dmlloyd, I'm trying the optional flag in the dependencies[17:48:17] <asoldano> dmlloyd, can I reference a module that does not exist using that optional flag and expect no exception to be raised?[17:48:39] <dmlloyd> no, if you try to link to a class from that module you will get a linkage error[17:48:45] <asaldhan> darranl: u r clear on the STS usage. correct? I think it is definitely applicable.[17:48:47] <dmlloyd> (if it's not present)[17:49:28] <asoldano> dmlloyd, ok, so I'm missing what "optional" is really for... ?[17:49:37] <Nihility> wolfc: ok thanks[17:50:03] *** jamezp is now known as jamezp_afk[17:50:10] <smarlow> baileyje: I think "java:comp/env/persistence/entityManager" would of been more correct[17:50:16] <darranl> asaldhan, yes thanks for the comment, I will definitely look into using it further[17:50:20] <asoldano> dmlloyd, I understood that could be used for setting a dependency on a module that might or might not be there[17:50:38] <baileyje> smarlow: As long as that JNDI location has the correct EM, then yes, that would be more correc[17:50:38] <baileyje> g[17:50:47] <asaldhan> darranl: the arch for PL2 is done in a transport agnostic way. But we still have not done the remoting interfaces yet.[17:50:48] <dmlloyd> asoldano: there are other ways to use a module dep - loadClass, for example or getResource[17:51:05] <aloubyansky> bstansberry, kkhan: actually true, as a value, should be taken in quotes, right? I think it used to work w/o the quotes some time ago...[17:51:13] <asoldano> dmlloyd, ok, I'll try and go that way then :-)[17:51:32] <asoldano> dmlloyd, thanks[17:51:36] <kkhan> aloubyansky: I've no idea, am a cli noob[17:52:14] <smarlow> baileyje: so, do I need to just use a more correct jndi name or should I do more (as you suggested earlier)?[17:52:44] <baileyje> I believe (dmlloyd can say for sure), but if you get the correct JNDI name, you should be set[17:53:04] <aloubyansky> kkhan: it's not a cli feature...[17:53:04] <smarlow> cool! :-) I'll and ask questions after.[17:53:15] <bstansberry> aloubyansky: I'm looking at how dmr treats the conversion of ModelType.STRING to boolean[17:53:21] <smarlow> baileyje: I'll try that, thanks! :)[17:53:39] <bstansberry> 'cause AIUI, the CLI will treat true as a string[17:54:02] <aloubyansky> bstansberry: instead of "true", just 1 works[17:54:58] <aloubyansky> bstansberry: ok, i've pushed the latest and rebased. you can try and if it works for you, please, pull[17:55:10] <bstansberry> great, thanks![17:55:21] <bstansberry> it's going to be merge day[17:55:32] <bstansberry> domain-op, deployment-scanner, cli[17:57:04] *** pgier has joined #jboss-as7[17:57:04] *** ChanServ sets mode: +v pgier[17:59:36] *** emuckenhuber has quit IRC[18:01:49] *** bobmcw has quit IRC[18:03:32] <darranl> Nihility, I already like the schema editing in InteliJ so much better[18:04:39] *** dimitris_ has quit IRC[18:05:32] *** balunasj_mtg is now known as balunasj_away[18:05:38] *** balunasj_away is now known as balunasj_mtg[18:07:03] *** jcosta has quit IRC[18:08:14] <kkhan> bstansberry: https://github.com/kabir/jboss-as/commit/68bd5a91d1454ac9af41e95110a4066a65bd97bc[18:08:15] <jbossbot> git [jboss-as] 68bd5a9.. kabir Speed up the FS deployment test by adding an alternative deployment scanner, and make embedded server factory set the jboss.server.base.dir[18:08:26] <smarlow> baileyje: didn't seem to help . I'm not sure if the location has anything bound to it. I noticed that the BinderService instance has name="env/persistence/entityManager"[18:08:41] <bstansberry> kkhan: ok, thanks[18:08:43] <kkhan> Although I did the sys property change, I found it easier to add a new scanner[18:09:03] <baileyje> smarlow: hmmm.. If there is a binding service it should be there,[18:09:39] <bstansberry> kkhan: true, there's a lack of write-attribute handlers :([18:09:53] <kkhan> exactly[18:10:33] <bstansberry> well, I really want to take a break for complex stuff for a week and do nothing but fill in blanks[18:10:43] <bstansberry> s/for/from[18:10:58] <smarlow> baileyje: I know that the PersistenceContextInjectorService.getValue() didn't get called (it would of returned the ManagedReferenceFactory )[18:11:14] <smarlow> baileyje: I think that means the binding didn't hapen[18:11:17] <smarlow> happen[18:11:29] <bstansberry> any spare cycles you have before the release, please fill in the blanks :)[18:12:50] <kkhan> bstansberry: I'll try to do a bit this weekend. How will we make sure we don't overlap?[18:13:09] <kkhan> if we're not online at the same time[18:13:57] <bstansberry> I'll do nothing but descriptors[18:14:04] <bstansberry> I want add any ops[18:14:08] <baileyje> smarlow: Where is the BinderService being registered ?[18:14:27] <bstansberry> s/want/won't[18:14:52] <alesj> dmlloyd: with added slf4j, I still don't get any decent info about why it fails / loops[18:14:57] <bstansberry> so you can do ops, unless you find descriptors more interesting ;)[18:15:41] *** bobmcw has joined #jboss-as7[18:15:42] *** ChanServ sets mode: +v bobmcw[18:15:43] <dmlloyd> alesj: is it at least not logging to stderr anymore? :)[18:16:04] <alesj> yeah :-)[18:16:15] <bstansberry> emuckenhuber, kkhan: https://github.com/bstansberry/jboss-as/tree/domain-op has your latest stuff. I think it's time to merge this into master. WDYT?[18:16:31] <kkhan> Sounds ok with me[18:16:51] <kkhan> I've still got a bit more to fix but I don't mind working off master[18:17:20] <smarlow> baileyje: https://github.com/scottmarlow/jboss-as/blob/master/jpa/src/main/java/org/jboss/as/jpa/processor/JPAAnnotationParseProcessor.java is doing a "phaseContext.getServiceTarget().addService(injectorName, new PersistenceContextInjectorService(annotation, puServiceName, deploymentUnit));" I'm not sure how or if the BinderService gets pulled in via magic.[18:17:21] <bstansberry> yeah, there's still more to do, but the basic goal of the branch has been achieved[18:17:36] <Nihility> so did we get @EJB working[18:17:37] <Nihility> ?[18:17:38] <smarlow> baileyje: I expected magic but maybe there isn't any.[18:18:42] <bstansberry> we can keep the branch open if we want to do more complex stuff, but the existing stuff should go into master soon -- i.e. before lunch ;)[18:18:44] <smarlow> baileyje: which would certainly explain why its not working...[18:23:00] <kkhan> I think I've mentioned it before but just wanted to point out in case it has been forgotten that all the fancy DC stuff to respawn servers has gone[18:23:37] <baileyje> smarlow: I am not sure what the PersistenceUnitInjectorService is for[18:25:50] <kkhan> s/DC/HC[18:27:33] <smarlow> baileyje: in this case, its the PersistenceContextInjectorService, which gets started and the service name for the PersistenceContextInjectorService, gets passed to bindingDescription.setReferenceSourceDescription(new ServiceBindingSourceDescription(injectorName));[18:27:44] <bstansberry> kkhan: hmm, can you file a JIRA[18:28:21] <smarlow> baileyje: this is done in JPAAnnotationParseProcessor, which is modeled after ResourceInjectionAnnotationParsingProcessor that handles resources.[18:28:29] <bstansberry> that sounds like something that shouldn't fall into a crack, and I think it's on the edge of a crack[18:28:33] <baileyje> smarlow: I would suggest you simplify it..[18:29:15] *** adietisheim has quit IRC[18:29:31] <smarlow> baileyje: so, just use the binderservice directly, instead and bind a object factory?[18:29:33] <baileyje> smarlow: When you run across a @PersistenceUnit, or @PersistenceContent, where should the value come from?[18:29:50] <baileyje> high-level[18:30:42] <baileyje> dmlloyd: https://github.com/baileyje/jboss-as/commit/394ec709d7c722e92a938f5d9afb6b6dfb897ce0[18:30:43] <jbossbot> git [jboss-as] 394ec70.. John E. Bailey Add support for lazy resource injection binding sources.[18:31:22] <jbossbot> git [jboss-as] push master c9b202c.. bstansberry at jboss dot com Rename ServerStartupTransactionalProxyController as HostControllerProxy[18:31:22] <jbossbot> git [jboss-as] push master a6a5751.. bstansberry at jboss dot com Convert domain/host level ops to server ops[18:31:22] <jbossbot> git [jboss-as] push master df07f7e.. bstansberry at jboss dot com Default rollout plan generation; rollout plan validation[18:31:22] <jbossbot> git [jboss-as] push master 59186fe.. bstansberry at jboss dot com Proper output for master DC and slave DC failures...[18:31:23] <jbossbot> git [jboss-as] push master 56def45.. bstansberry at jboss dot com Create update tasks and push to servers[18:31:23] <jbossbot> git [jboss-as] push master ccf7efa.. bstansberry at jboss dot com Rollback handling[18:31:23] <jbossbot> git [jboss-as] push master 05fe7f5.. Emanuel Muckenhuber use serverOp[18:31:24] <jbossbot> git [jboss-as] push master dc1754b.. Emanuel Muckenhuber don't push named paths to servers[18:31:24] <jbossbot> git [jboss-as] push master a5d3b8e.. kabir Handle transactional requests and route execute-on-domain locally[18:31:25] <jbossbot> git [jboss-as] push master 4fe964f.. bstansberry at jboss dot com Domain level deployment operation handling[18:31:25] <jbossbot> git [jboss-as] push master 9163ec6.. bstansberry at jboss dot com Use ModelNode.hasDefined() instead of previous utility method[18:31:26] <jbossbot> git [jboss-as] push master 91846fe.. bstansberry at jboss dot com Fix domain.xml marshalling bugs[18:31:26] <jbossbot> git [jboss-as] push master f28b603.. bstansberry at jboss dot com An operation should not require an address[18:31:27] <jbossbot> git [jboss-as] push master 020cbcc.. bstansberry at jboss dot com Misc fixes to domain deployment handling[18:31:27] <jbossbot> git [jboss-as] push master a6c9a47.. bstansberry at jboss dot com Convert demo deployment handling to detyped API[18:31:28] <jbossbot> git [jboss-as] push master 17f8d70.. Emanuel Muckenhuber domain subsystem mgmt example[18:31:28] <jbossbot> git [jboss-as] push master 8e54406.. bstansberry at jboss dot com Combine DomainModel and HostModel functionality[18:31:29] <jbossbot> git [jboss-as] push master 782ea89.. bstansberry at jboss dot com Fix system property marshalling[18:31:29] <jbossbot> git [jboss-as] push master 7dcfff5.. bstansberry at jboss dot com Remove GroupedServer[18:31:30] <jbossbot> git [jboss-as] push master 5b6b411.. bstansberry at jboss dot com Capture uncommitted model for use in determining server operations[18:31:30] <jbossbot> git [jboss-as] push master 24f64aa.. Emanuel Muckenhuber host level ops[18:31:31] <jbossbot> git [jboss-as] push master bcf558e.. kabir Fix problems calling operations targetted for a particular host with remote slaves...[18:31:31] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/4c62bf0...bcf558e[18:32:04] <kkhan> bstansberry: https://issues.jboss.org/browse/JBAS-8943[18:32:05] <jbossbot> jira [JBAS-8943] Reimplement Server Respawn logic in HC [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8943[18:32:06] *** rawbdor has joined #jboss-as7[18:32:06] <smarlow> for both @PersistentUnit and @PersistenceContext, we depend on the PersistenceUnit (persistence.xml) definition that has been parsed and held by the persistence unit serviceservice[18:32:28] *** jfclere has quit IRC[18:33:02] <baileyje> ok. So there is a service for each..[18:33:11] <baileyje> added by PersistenceUnitDeploymentProcessor[18:33:13] <baileyje> correct?[18:33:19] <smarlow> the injected value, depends on the PersistenceUnit service for proper dependency ordering. The injected value should be a PersistenceContextInjectorService or PersistenceUnitDeploymentProcessor[18:37:01] <baileyje> smarlow: Try adding a dependency to the PersistenceContextInjectorService and PersistenceUnitInjectorService.[18:37:08] <baileyje> Have it depend on the puServiceName[18:37:14] <smarlow> sorry, got distracted[18:37:15] <smarlow> there is a PersistenceUnit service added by PersistenceUnitDeploymentProcessor and that represents the Persistence.xml.[18:37:22] <baileyje> in JPAAnnotationParseProcessor[18:38:16] <smarlow> JPAAnnotationParseProcessor is the one that starts the PC/PU injector services[18:40:10] <smarlow> lets see, JPAAnnotationParseProcessor, when I start the PersistenceContextInjectorService service for an injection instance, I should add a depedency on the pu service. Okay, I'll try that. Thanks[18:40:25] <smarlow> same for the pu injector too.[18:42:41] *** emuckenhuber has joined #jboss-as7[18:42:42] *** emuckenhuber has joined #jboss-as7[18:42:42] *** ChanServ sets mode: +v emuckenhuber[18:44:48] <darranl> bstansberry, do you have a sec?[18:44:59] <bstansberry> sure[18:45:48] <darranl> this renaming of api to interface, almost finish but now I realise all the modules for the http-interface are in projects / artefacts called http-api - should I be updating that as well so it is all consistent ?[18:46:15] <bstansberry> no[18:46:34] <bstansberry> there's a contributor working in that area, and I don't want to break him[18:46:53] <darranl> who else is in that area?[18:46:53] *** epbernard is now known as emmanuel[18:46:57] <bstansberry> jpearlin[18:47:08] <bstansberry> working on posting deployments[18:47:46] <darranl> ok - will hold off on that - longer term is it a change we would want to make?[18:47:59] <bstansberry> probably, although I don't think it's a big deal[18:48:37] <bstansberry> if devs working with the code can't make the translation, well....[18:49:01] *** mmoyses_ is now known as mmoyses[18:49:15] *** bobmcw has quit IRC[18:49:29] <darranl> yeah not to sure how rebasing would go if you have changes in a renamed project - I have quite a few changes in there as well[18:49:48] <jbossbot> git [jboss-as] push master 9c863b1.. David M. Lloyd Upgrade to MSC 1.0.0.Beta7[18:49:48] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/bcf558e...9c863b1[18:49:54] <bstansberry> exactly[18:50:29] <darranl> well in the end we went for interfaces which is the I from API so not the end of the world to leave it as it is ;)[18:51:00] <bstansberry> :)[18:51:02] *** alesj has quit IRC[18:51:06] <bstansberry> we're geniuses![18:51:30] *** bobmcw has joined #jboss-as7[18:51:30] *** ChanServ sets mode: +v bobmcw[18:52:09] *** smcgowan has quit IRC[18:54:15] <darranl> bstansberry, also let me know if you want to go from interfaces to network-interfaces - the code change is generally in the same area I am currently in[18:54:28] <bstansberry> not in the same patch[18:54:39] <bstansberry> i'll let that one percolate on the list for a couple days[18:55:41] <baileyje> dmlloyd: When you get a chance https://github.com/baileyje/jboss-as/commit/32b683c76d8955c780b1e3ec73d2f7732307f40b[18:55:41] <jbossbot> git [jboss-as] 32b683c.. John E. Bailey Add support for lazy resource injection binding sources.[18:55:42] <darranl> bstansberry, no I can either do it as a new commit after the first lot is in or branch my branch to keep it continuous[18:56:40] <kkhan> bstansberry: I think you pushed to master? What happened to my https://github.com/kabir/jboss-as/commit/587e15cbe80fed0ff48dcc2cd74a1ab05d0882f9?[18:56:40] *** jamezp_afk has quit IRC[18:56:40] <jbossbot> git [jboss-as] 587e15c.. kabir Handle transactional requests and route execute-on-domain locally[18:56:42] <bstansberry> k[18:56:50] <kkhan> Since now I am back where I was a few days ago[18:57:30] *** jhalliday has quit IRC[18:57:32] *** jamezp has joined #jboss-as7[18:57:40] * bstansberry looks[18:58:05] <asoldano> stuartdouglas, are you here?[18:58:45] <kkhan> bstansberry: In your domain-op it is https://github.com/bstansberry/jboss-as/commit/a5d3b8eef62641e2c17176ca40ef2471f0f0b2be[18:58:46] <jbossbot> git [jboss-as] a5d3b8e.. kabir Handle transactional requests and route execute-on-domain locally[18:59:04] <bstansberry> yeah, I see it[18:59:30] <dmlloyd> baileyje: ok I'll look at that next[18:59:55] <baileyje> dmlloyd: Sounds good[18:59:58] <bstansberry> kkhan: I see it on master: https://github.com/jbossas/jboss-as/commit/a5d3b8eef62641e2c17176ca40ef2471f0f0b2be[18:59:58] <jbossbot> git [jboss-as] a5d3b8e.. kabir Handle transactional requests and route execute-on-domain locally[19:00:15] * dmlloyd just grabbed a sandwich[19:02:57] <kkhan> bstansberry: Oooops, I guess I forgot to rebase. Apologies...[19:03:09] * bstansberry breathes sigh of relief[19:03:54] <jbossbot> git [jboss-as] push master e6660da.. kabir Speed up the FS deployment test by adding an alternative deployment scanner, and make embedded server factory set the jboss.server.base.dir[19:03:55] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/9c863b1...e6660da[19:04:00] <Nihility> does anyone have any critical blockers[19:04:05] <Nihility> that they would like to raise[19:04:17] <Nihility> obviously JPA and ejb finishing touches are[19:04:26] <Nihility> I just want to make sure I dont miss anything[19:04:34] <Nihility> the plan is to TAG MONDAY EVENING[19:04:55] <kkhan> I am not sure if https://issues.jboss.org/browse/JBAS-8943 qualifies as a blocker or not[19:04:56] <jbossbot> jira [JBAS-8943] Reimplement Server Respawn logic in HC [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8943[19:05:11] <bstansberry> we need to get the master-DC-propagate-to-slave-DC stuff kkhan is working on sorted[19:06:09] <bstansberry> I dont think 8943 should be a blocker[19:07:39] <smarlow> baileyje: I added the PUService dependency on the created PersistenceContextInjectorService + PersistenceUnitInjectorService but no change.[19:08:50] <wolfc> do we have anybody working on lifecycle callbacks via user and system interceptors?[19:09:10] <baileyje> smarlow: Ok. I am going to propose we ditch the *InjectorServices[19:09:37] <baileyje> We should be able to just create custom BindingSourceDescription for each[19:10:53] <Nihility> http://community.jboss.org/docs/DOC-16608[19:11:10] <Nihility> so we dont forget :)[19:12:16] <wolfc> do you want XPC to work?[19:12:23] <wolfc> hmm, want is the wrong term[19:12:29] <wolfc> is it a must have?[19:12:29] <Nihility> need? no[19:12:30] <Nihility> :)[19:12:50] <wolfc> I would also put in EJB TX[19:12:58] <Nihility> ok will add that[19:13:26] <wolfc> EE @Interceptor lifecycle callbacks[19:13:36] *** ChanServ changes topic to "BETA1 MUST HAVE - DOC-16608, TAG ON MONDAY EVENING (US) GO GO GO"[19:13:42] <wolfc> I think we'll need system interceptor lifecycle callbacks[19:14:15] <wolfc> Jaikiran, how far are you on @Singleton, @Lock and @ConcurrencyManagement?[19:14:20] <dmlloyd> yeah I was looking at that a little bit, figuring out what was involved[19:14:35] <jbossbot> git [jboss-as] push master 8c0a7c7.. John E. Bailey Add support for lazy resource injection binding sources.[19:14:36] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e6660da...8c0a7c7[19:15:31] <wolfc> Another must have is real Cache and Pool implementations. Pool is ready to pop in from jboss-ejb3 2.0.0-alpha-1, Cache needs to refactor away from some old constructs.[19:16:55] <wolfc> And we need test coverage for all the permutations that we can make with the current annotation set.[19:17:18] <wolfc> Especially where inheritance is involved.[19:17:19] <dmlloyd> not for beta1 though, I mean we could tag without that[19:17:50] <Nihility> i think we need a basic "proof" that all of these things "work"[19:17:52] <baileyje> smarlow: If I pull your changes, can I build it, or do you still have outstanding changes?[19:18:10] <Nihility> a demo or a few test cases would suffice IMO[19:18:24] <wolfc> Well we already got that[19:18:38] <wolfc> But I would aspire a bit more quality[19:18:55] <smarlow> baileyje: I just pushed the jndi fix, so everything is committed. To run the demo, "cd demos;mvn package -Dexample=jpa"[19:19:07] <baileyje> ok. on your master?[19:19:34] <wolfc> So we don't get silly NPEs on for example ArrayKey or any processor.[19:19:42] <smarlow> baileyje: yes, on https://github.com/scottmarlow/jboss-as[19:20:21] <Nihility> wolfc: i want that as well, however we are going to start doing frequent releases after beta1, so we can be incremental[19:20:32] <Nihility> we need to do weekly builds[19:20:46] <Nihility> so might as well call those BetaXXXX[19:21:21] <wolfc> If we can get the rolling build of Hudson behind a counter then that should be covered.[19:21:39] <Nihility> yeah right now its producing them[19:21:47] <Nihility> but we dont uplaod them anywhere[19:21:48] <wolfc> Still I would like to see us building tests for the next target.[19:22:04] <Nihility> its going to be very important as part of the TCK work[19:22:15] <Nihility> to have coverage that doesnt require waiting 6 hours[19:22:18] <Nihility> for the TCK to run[19:22:19] <Nihility> :)[19:22:24] <kkhan> bstansberry: In BasicTransactionalModelController http://pastebin.com/cpfdftyR the proxy for the local host is a RemoteProxyController[19:22:38] <kkhan> I don't see where it is getting registered though[19:22:41] *** frainone has joined #jboss-as7[19:22:42] <wolfc> The TCK contains sleeps of 10 minutes :-)[19:22:42] *** ChanServ sets mode: +v frainone[19:22:58] <Nihility> bstansberry: kkhan feel free to add to this list, just keep in mind, this is stuff that if we dont do it blocks the release[19:23:51] <Nihility> also after B1 im going to clear out jira[19:24:00] <Nihility> and we are going to use it a way more than we are now[19:24:11] <Nihility> perhaps get a fresh project[19:24:14] <kkhan> Think I found it[19:24:35] <bstansberry> great[19:24:39] <kkhan> Actually, no[19:24:48] <smarlow> baileyje: I have to bail for 30 minutes, thanks for helping :-)'[19:24:59] <baileyje> smarlow: No problem[19:25:31] <wolfc> Nihility, baileyje, from what I've seen of @EJB injection it appears it works except for 16.5.2 footnote 89.[19:25:33] <kkhan> DomainModelImpl contains this http://pastebin.com/kbNPX8Lk[19:26:04] <wolfc> but again we need to test corner cases to make sure :-)[19:26:15] <kkhan> But I don't think that is a remote proxy getting registered[19:26:35] <bstansberry> no, it's not a proxy[19:26:45] <bstansberry> it's a ConcreteNodeRegistration[19:27:38] <Nihility> i need t o make hotkeys[19:27:41] <Nihility> for all of the ee specs[19:27:55] <Nihility> ctrl-shift-F1 = pull up ee.pdf :)[19:28:02] <wolfc> baileyje, have you looked at @Resource EJBContext? I see the mapping, but is there a Service that binds it?[19:28:14] <kkhan> The weird thing is that proxy works when executing on the master but returns nothing when executing on the remote slave[19:28:18] <baileyje> wolfc: I have not looked into binding it yet[19:28:39] <wolfc> The jboss-ejb3 can't be fitted blindly into AS 7.[19:28:58] *** asoldano has quit IRC[19:29:03] <bstansberry> there shouldn't be any host proxy registered with the DomainModelImpl[19:29:05] <wolfc> Hmm, well maybe it can.[19:29:27] <wolfc> But then we would have to float another InvocationContext alongside the one that is already in the system interceptor chain.[19:30:31] <kkhan> Adding some more debug statements[19:33:18] <wolfc> Actually it would be quit simple to make it that way. I can just create an ContextSystemInterceptor that puts up a https://github.com/jbossejb3/jboss-ejb3/blob/master/context/base/src/main/java/org/jboss/ejb3/context/base/BaseSessionInvocationContext.java.[19:34:48] <dmlloyd> what EJBContext impl are we using now?[19:34:56] <wolfc> none[19:35:37] <bstansberry> kkhan: the only calls to registerProxyController I see are the 2 servers registering with the HC[19:36:27] <kkhan> aha, the proxy is for ((host=>blah),(server=>1)) NOT the host[19:36:29] <dmlloyd> so really the instance that is pulled from java:comp/EJBContext depends on the component *instance*[19:36:36] * kkhan misses his debugger[19:36:40] <dmlloyd> is that a correct assessment, wolfc?[19:37:33] * bstansberry misses his debugger too[19:37:48] <wolfc> https://github.com/jbossejb3/jboss-ejb3/blob/master/context/base/src/main/java/org/jboss/ejb3/context/base/BaseInvocationContext.java#L79[19:37:57] <dmlloyd> wolfc, also, when it is looked up, is the instance always shared?[19:38:12] <wolfc> no[19:38:37] <dmlloyd> ok so if I manually look it up 6 times in my EJB method, I get 6 distinct instances (all referring to the same context)?[19:38:38] <wolfc> the instance EJBContext is conceptually equal to ComponentInstance[19:38:58] <dmlloyd> ok so it's shared on a per-ComponentInstance basis[19:39:02] <wolfc> it doesn't work that way[19:39:10] <dmlloyd> which way is it :)[19:39:20] <dmlloyd> one instance or 6[19:39:47] <wolfc> ah misinterpretation, the answer is yes[19:39:57] <dmlloyd> yes it's one or yes it's six?[19:40:18] <wolfc> 6 lookups in one EJB method invocation is 1 instance[19:40:31] <dmlloyd> ok cool[19:40:34] <dmlloyd> that makes sense[19:40:41] <wolfc> a lookup in another method from the same EJB is the same instance[19:40:48] <wolfc> EJB instance[19:40:49] <Nihility> wolfc: so you are saying that @EJB(beanName...) does not work?[19:41:03] <wolfc> Yes, it does, just not that footnote[19:41:16] *** maxandersen has joined #jboss-as7[19:41:16] *** ChanServ sets mode: +v maxandersen[19:41:18] <wolfc> relative bean names[19:41:37] <Nihility> oh the # stuff[19:41:40] <wolfc> right[19:41:55] <darranl> Where is DOC-16608 from the title?[19:42:28] <wolfc> the trick on the instance EJBContext is https://github.com/jbossejb3/jboss-ejb3/blob/master/context/base/src/main/java/org/jboss/ejb3/context/base/BaseEJBContext.java#L58[19:42:45] <wolfc> it then goes the invocation EJBContext / InvocationContext to query the current caller principal[19:42:55] <Nihility> darranl: wiki.jboss.org[19:43:14] <Nihility> shame IRC doesnt do URLs[19:43:20] <wolfc> But that requires that InvocationContext implements EJBContext[19:43:28] <wolfc> Or at least some InvocationContext[19:43:54] <wolfc> https://github.com/jbossejb3/jboss-ejb3/blob/master/context/base/src/main/java/org/jboss/ejb3/context/base/BaseInvocationContext.java#L67[19:43:57] <darranl> Nihility, thanks found it - for some reason updating a document URL with the new number didn't work[19:44:30] <dmlloyd> wolfc yeah I think we'd have to have some threadlocal[19:44:30] <wolfc> and as can be seen you can go from the invocation EJBContext back to the instance EJBContext[19:44:45] <wolfc> https://github.com/jbossejb3/jboss-ejb3/blob/master/context/base/src/main/java/org/jboss/ejb3/context/CurrentInvocationContext.java[19:44:59] <dmlloyd> yup[19:45:24] <wolfc> and for the lookup https://github.com/jbossejb3/jboss-ejb3/blob/master/context/base/src/main/java/org/jboss/ejb3/context/CurrentEJBContext.java#L29[19:45:48] <dmlloyd> possibly overkill, but yeh[19:45:50] <dmlloyd> yeah*[19:45:59] <dmlloyd> so... let's do it :)[19:46:25] <dmlloyd> the only missing piece is the ManagedReferenceFactory to create a reference that resolves to the current EJBContext[19:46:34] <dmlloyd> that should be pretty simple[19:46:42] <wolfc> https://github.com/jbossejb3/jboss-ejb3/tree/master/context/spi/src/main/java/org/jboss/ejb3/context/spi needs some refactoring[19:46:54] <wolfc> BeanManager => EJBComponent[19:47:16] <dmlloyd> it's still early there, barely 8pm![19:47:22] <dmlloyd> plenty of time![19:47:36] <wolfc> hehe, okay, okay hold on.[19:47:41] * wolfc is typing away[19:48:31] *** AndyTaylor has joined #jboss-as7[19:48:31] *** ChanServ sets mode: +v AndyTaylor[19:48:37] <dmlloyd> we should revisit the idea of reducing the number of threadlocals after this release.[19:48:58] <dmlloyd> naming contexts, instance and component-specific stuff, module-specific stuff (i.e. TCCL)[19:53:22] *** balunasj_mtg has quit IRC[19:56:38] <baileyje> wolfc, dmlloyd: Where do you think we should bind the PU in JNDI? Is there a standard path?[19:56:53] <dmlloyd> I don't think so, I'll check again though[19:57:10] <dmlloyd> EE.5.13 has all the facts afaict[19:57:39] <wolfc> a PU is normally not bound[19:57:41] <dmlloyd> I think it's gonna look in comp/env by default[19:57:53] <Nihility> yeah i think its only the ref thats bound[19:57:53] <dmlloyd> if the injection is unqualified I mean[19:57:55] <Nihility> not the PU itself[19:58:05] <dmlloyd> where does it come from?[19:58:21] <Nihility> based on some crazy rules[19:58:22] <wolfc> Yeah, that's the java:comp/env which depends on the class and property name you inject to[19:58:30] <dmlloyd> yeah[19:58:45] <dmlloyd> so set absolute to false and let it build the name (iirc)[19:58:51] <dmlloyd> but as to the source.... not sure[19:58:59] <dmlloyd> hopefully that's already figured out in smarlow's patch[19:59:01] <Nihility> smarlow was explaining some of the rules[19:59:14] *** darranl has quit IRC[19:59:15] <Nihility> basically there is an inheritence scheme[19:59:21] <baileyje> wolfc: Ok. That is what I thought.[19:59:33] *** darranl has joined #jboss-as7[19:59:33] *** darranl has joined #jboss-as7[19:59:34] <Nihility> like all methods in the same TX share the same context[19:59:50] <Nihility> so its a create or reuse type notion[19:59:55] <wolfc> if there is a TX the TX PU is propagated.[20:00:41] <dmlloyd> ugh[20:00:42] <Nihility> smarlow: was talking about needing an invocation stack per thread[20:00:59] <wolfc> baileyje, look at EE.5.2.5 for the fine print[20:01:16] <wolfc> which is about 3 pages :-)[20:01:59] <wolfc> Remember, the spec is not written with common sense in mind, so switch it off. :-)[20:02:24] <Nihility> he was looking at lazily creating these at instance creation time[20:02:35] <baileyje> wolfc: I am familiar with the rules in general. Just curious if the actual PU instance was bound. Not just an instance based on a resource injection[20:02:40] <Nihility> which is why he was having dependency issues[20:02:57] <baileyje> Nihility: Yeah, I am going to not do that.[20:03:20] <Nihility> im almost positive its not bound any other way[20:03:23] <wolfc> baileyje, we do have that as an added feature, but I think we don't want that anymore.[20:03:57] <baileyje> yeah. I will assume it is not bound unless injected in which case it goes in the normal env location for the injection[20:04:56] <wolfc> This should do the trick for BeanManager => EJBComponent https://github.com/wolfc/jboss-ejb3/commit/425e585cf78e17c535c62a3ce2729eebecfc03b2[20:04:57] <jbossbot> git [jboss-ejb3] 425e585.. Carlo de Wolf Renamed BeanManager to Component[20:05:10] <wolfc> dmlloyd, what do you want to do with the CMT tx branch?[20:05:36] <dmlloyd> hm[20:05:42] <dmlloyd> I have to look at it again[20:06:17] <dmlloyd> where is it[20:06:28] <wolfc> https://github.com/wolfc/jboss-as/commits/ejb3-ee[20:06:42] <wolfc> Some bits are not pretty[20:06:43] <dmlloyd> oh, I thought I pushed that one[20:06:57] <dmlloyd> maybe not[20:07:01] <dmlloyd> I think I just pulled that one commit[20:07:19] <wolfc> right, the NPE fix[20:07:37] *** AndyTaylor has quit IRC[20:07:50] <wolfc> https://github.com/wolfc/jboss-as/commit/f77669284b1f35c35915c554467ab542097eb7bf#ejb3/src/main/java/org/jboss/as/ejb3/component/EJBComponentConfiguration.java-P35[20:07:51] <jbossbot> git [jboss-as] f776692.. Carlo de Wolf Initial integration of CMT tx interceptor[20:07:54] <wolfc> is the most ugly bit[20:08:02] <Jaikiran> wolfc: to reply to your question - @Singleton is ready with @Lock in progress. @concurrencymanagement processing is ready too[20:08:20] <wolfc> Jaikiran, did you keep the package rename?[20:08:20] <Jaikiran> i'm just fitting in the @lock/concurrencymanagement interceptors[20:08:39] <Jaikiran> wolfc: it's there, yes. but i can revert it if you want to[20:08:45] <Nihility> Jaikiran: im a fan :)[20:08:52] <dmlloyd> I'm a bit alarmed by https://github.com/wolfc/jboss-as/compare/ejb3-ee#L7R390 wolfc[20:08:55] <wolfc> I would say revert that bit.[20:09:10] <Jaikiran> wolfc: will do. i'll let the packages be the same as before[20:09:49] <wolfc> dmlloyd, the question is, does this make sense: https://github.com/wolfc/jboss-as/commit/cb5c2d5d5bd2760292de57368920e7c1cdc70938#L1R33[20:09:49] <jbossbot> git [jboss-as] cb5c2d5.. Carlo de Wolf Add a ComponentInterceptorFactory for per Component interceptors[20:11:23] <wolfc> I think at some point we need interceptors that tie extra attributes to a component.[20:11:26] <dmlloyd> yes, that seems ok[20:11:45] <wolfc> In that case the componentInterceptor needs to come up later in the game (after component is instantiated)[20:11:56] <dmlloyd> at least I can't think of any trouble with it, though we might want to make sure we don't produce the same instances twice[20:12:11] <dmlloyd> there's some protection against that in the one in jboss-invocation[20:12:47] <wolfc> so I moved L390 to https://github.com/wolfc/jboss-as/commit/bc8eb79d33c1fb3e5a163d2accdcb02546064cf8#L3R65[20:12:47] *** aslak has quit IRC[20:12:49] <jbossbot> git [jboss-as] bc8eb79.. Carlo de Wolf Instantiate the component interceptor after component instantiation[20:13:11] <dmlloyd> yeah that makes sense - I think...[20:13:15] <dmlloyd> yeah[20:13:26] <dmlloyd> the component interceptors should really be tied to the component lifecycle[20:13:26] *** aslak has joined #jboss-as7[20:13:27] *** ChanServ sets mode: +v aslak[20:13:31] <dmlloyd> not the configuration[20:13:36] <wolfc> the only disadvantage is that is a 'spec' injection style.[20:13:50] <dmlloyd> meaning?[20:14:01] <wolfc> it's not a final field anymore[20:14:35] <dmlloyd> yeah that's a bummer[20:14:35] *** aslak has quit IRC[20:14:44] <dmlloyd> but you gotta choose chickens or eggs at some point[20:14:47] <wolfc> I was almost tempted to do it in the constructor, but that would expose constructing objects[20:14:57] *** aslak has joined #jboss-as7[20:14:57] *** ChanServ sets mode: +v aslak[20:15:03] <dmlloyd> yeah I had everything in the constructor before and it was kinda crazy[20:15:06] <wolfc> So I choose chicken :-)[20:15:09] <dmlloyd> maybe we'll end up back there again[20:15:18] <Nihility> i like both[20:15:19] <wolfc> You can't expose constructing objects[20:15:22] <dmlloyd> but for now it's fine as long as we make sure the component interceptor field is volatile[20:15:57] <Nihility> fried egg + chicken... sounds tasty![20:16:01] <wolfc> oh that would need a fix[20:16:20] <dmlloyd> I prefer final so much because it makes thread safety much simpler[20:16:27] <dmlloyd> but in this case it's just not in the cards[20:16:28] <wolfc> I agree[20:16:45] *** smarlow has quit IRC[20:16:48] <dmlloyd> it would be nice if the language would introduce better mutual-initialization semantics[20:17:17] *** emmanuel has quit IRC[20:17:18] <Nihility> you can always minimize the window it is volatile[20:17:29] <dmlloyd> the window isn't the problem[20:17:29] *** ALR has joined #jboss-as7[20:17:29] *** ChanServ sets mode: +v ALR[20:17:35] <dmlloyd> we're publishing hte object at the right time[20:17:39] <bstansberry> kkhan: small thing i noticed when playing[20:17:40] <dmlloyd> just don't want any threads to see a null there[20:17:45] <wolfc> why not make the setter synchronized?[20:17:56] <dmlloyd> synchronized is never faster than volatile[20:18:01] <wolfc> but we only set once[20:18:03] <dmlloyd> volatile reads are basically free[20:18:11] <dmlloyd> synch is for life[20:18:34] <dmlloyd> if you synch on write, you have to synch on read too[20:18:43] <dmlloyd> otherwise you're not guaranteed visibility[20:19:10] <Nihility> unless you piggy back on a lock[20:19:11] <Nihility> :)[20:20:40] <baileyje> So, should the H2DS be deployed?[20:20:52] <dmlloyd> yes but it only works if you turn off osgi first :([20:21:08] *** aslak has quit IRC[20:21:13] <dmlloyd> er, I'm thinking of the H2 driver jar[20:21:17] <dmlloyd> no idea about DSes[20:21:17] <Nihility> why dont we jus tstrip osgi stuff from that jar[20:21:56] <wolfc> any way, I'll add volatile, that takes care of the first two commits. I'll also clean up that commented code.[20:22:30] <dmlloyd> ok and strip https://github.com/wolfc/jboss-as/commit/9ab23f2ee60 from that branch while you're at it[20:22:31] <jbossbot> git [jboss-as] 9ab23f2.. Carlo de Wolf Fixed NPE when @Local is used standalone on the bean[20:22:57] <wolfc> I'll rebase on to upstream, git will remove it for me[20:23:09] <wolfc> It also works the other way around[20:23:15] <dmlloyd> I've seen it not work[20:23:19] <dmlloyd> so I'm always cautious[20:23:39] <baileyje> dmlloyd: I don't see it deploying anything for the datasource even with OSGI disabled.[20:23:45] <dmlloyd> hey, we've hit 100 forks of AS7 on github[20:23:57] <dmlloyd> baileyje: you have to deploy the driver JAR[20:24:01] <dmlloyd> I think[20:24:04] <wolfc> the network view is officially no longer usable :-)[20:24:05] <dmlloyd> I"ve never actually tried it[20:24:08] <baileyje> Yeah. I thought so. let me try[20:24:11] <Nihility> baileyje: its off by default in standalone.xml, or did you mean it doesnt work when it is on?[20:24:13] <wolfc> Any comments on https://github.com/wolfc/jboss-as/commit/83c522925ff8fd9bacbca8698ec60787e3ea4d94[20:24:14] <jbossbot> git [jboss-as] 83c5229.. Carlo de Wolf Allow sub-classes of Description to process component and view methods[20:24:38] <dmlloyd> seems harmless, wolfc, but what are you planning on using it for?[20:25:01] <wolfc> Ultimately we want to tie interceptors to the methods themselves.[20:25:14] <dmlloyd> linus has a policy for the linux tree: any new features introduced have to be used in the same change set :)[20:25:38] <wolfc> The changeset is the complete chain of commits :-)[20:25:38] <Nihility> i violated that a few times[20:25:51] <dmlloyd> me too, Nihility, don't feel bad :)[20:26:02] <wolfc> Besides what's a good story if I gave away the plot[20:26:06] <Nihility> its great you write code that may not work[20:26:08] <Nihility> and call it a day[20:26:11] <Nihility> hahahahaha[20:26:12] *** balunasj has joined #jboss-as7[20:26:12] *** balunasj has joined #jboss-as7[20:26:12] *** ChanServ sets mode: +v balunasj[20:26:26] <dmlloyd> wolfc: is there some case where our current per-method interceptor thing isn't adequate?[20:26:33] <dmlloyd> it's already pretty complex[20:26:40] <dmlloyd> I'd hate to add more cases into it if we can use what we have[20:26:47] <dmlloyd> or alternatively eliminate part of what we have[20:26:54] *** balunasj has quit IRC[20:29:30] <baileyje> wierd. I have the datasource jar deployed, and the connector is not commented out[20:29:33] <wolfc> I don't see method system interceptors.[20:31:19] <wolfc> I see method user interceptors.[20:32:01] <Nihility> arent they the same?[20:32:12] <Nihility> (probably a stupid question)[20:33:10] *** mbg has quit IRC[20:33:14] <dmlloyd> they should be similar[20:33:27] <wolfc> method user interceptors are per ComponentInstance instance[20:33:29] <dmlloyd> though I bet we don't hooks available to add them anymore[20:34:17] <dmlloyd> org.jboss.as.ee.component.AbstractComponentConfiguration#interceptorFactoryMap will let you hook into it[20:34:51] <dmlloyd> that's keyed by view method[20:34:56] <wolfc> Yeah, that's the user method interceptors[20:34:56] <dmlloyd> (by identity)[20:35:25] <dmlloyd> there's no other per-method mechanism[20:35:25] <wolfc> I don't want an interceptor per ComponentInstance instance[20:35:28] <wolfc> right[20:35:52] <dmlloyd> when are you wanting them to run?[20:36:08] <baileyje> So from what I see DataSource deployment no longer works[20:36:20] <Nihility> baileyje: ill take that one then[20:36:26] <dmlloyd> right now it's a single interceptor path for component-level, then per-method for instance level[20:36:36] <baileyje> Take a look at DsDeploymentProcessor[20:36:58] <baileyje> It has a weird condition that requires a deployment to start with "jdbc". I don't think that is valid any more[20:37:14] <Nihility> that is for the internal deps[20:37:14] <wolfc> take for example @DenyAll on a method. I want to inject a system interceptor on that method: DenyAllInterceptor.[20:37:22] <Nihility> jdbc-local.jar[20:37:26] <Nihility> and jdbc-xa.jar[20:37:54] <dmlloyd> wolfc: so basically a per-component, per-method interceptor chain which hits *before* the general component interceptor chain? or after?[20:37:56] <wolfc> It's the same for each ComponentInstance, so overkill to do a per Instance[20:37:59] <Nihility> this might be the classloading thing[20:38:00] <baileyje> So those also need to be dropped in the deployment dir?[20:38:05] <Nihility> maeste: ping[20:38:13] <dmlloyd> wolfc: you could always create an InterceptorFactory which always returns the same instance[20:38:15] <wolfc> Interceptor ordering is another thing[20:38:27] <jpederse> Nihility: he is gone for today, what ?[20:38:33] <wolfc> But we don't have an InterceptorFactory per Method[20:38:37] <dmlloyd> wolfc: the ordering is important though, because the per-method interceptors don't come into play until later[20:38:54] <Nihility> jpederse: did you ever hear from him about that TCCL issue we excahnged emails on?[20:39:00] <wolfc> Do we have interceptor-order for user interceptors?[20:39:03] <dmlloyd> wolfc: yeah, that's what we do have, that interceptorFactoryMap goes from view method to interceptor factory[20:39:13] <dmlloyd> wolfc: the user interceptors run last[20:39:14] <jpederse> baileyje: there is stuff on Stuart's branch - plus JBAS-8925[20:39:16] <jbossbot> jira [JBAS-8925] Failure in the rar demo smoke test [Open (Unresolved) Bug, Blocker, Jason Greene] https://issues.jboss.org/browse/JBAS-8925[20:39:32] <jpederse> baileyje: Stuart is looking at it[20:39:58] <wolfc> I also need it per view method[20:40:02] <wolfc> not per bean method[20:40:35] <dmlloyd> right, that's how all the method maps are[20:40:37] <wolfc> Oh well, we can try again after Beta1. This is still too complex to handle as such currently.[20:40:43] <jpederse> Nihility: that may be part of Stuart's patch... it needs to be set for sure[20:41:04] <wolfc> That can't be, because Method alone is not enough to key upon.[20:41:24] <Nihility> stuartdouglas: hey you areound today[20:41:25] <wolfc> Two different views can expose the same method.[20:41:33] <dmlloyd> yes it is[20:41:37] <baileyje> Nihility, jpederse: be back in 15.[20:41:38] <dmlloyd> they're exposed *by object identity*[20:41:48] <dmlloyd> so even if two views have the exact same method it's a different Method[20:41:54] <wolfc> Right, so how can I have different interceptors then?[20:41:55] <dmlloyd> also, it's extra-fast[20:41:58] <wolfc> huh[20:42:19] <wolfc> That *is* nasty[20:42:33] <dmlloyd> the proxy class has a flat finite list of all of its Methods that we use[20:43:02] <dmlloyd> it's nice because we never invoke upon those Methods, so we can pass them in the invocation context and the user can't screw them up via setAccessible()[20:43:25] <dmlloyd> we have an identity map of Method->Method which we use to invoke on the final class[20:43:47] <dmlloyd> the latter comes from the reflection index so again it's no extra cost that we haven't already paid[20:46:19] <wolfc> InvocationContext.getMethod must return the component method[20:48:19] <wolfc> Anyway, what I current use those methods for is filling up the txAttrs cache https://github.com/wolfc/jboss-as/commit/f77669284b1f35c35915c554467ab542097eb7bf#L9R179[20:48:20] <jbossbot> git [jboss-as] f776692.. Carlo de Wolf Initial integration of CMT tx interceptor[20:48:51] *** epbernard has joined #jboss-as7[20:48:51] *** epbernard is now known as emmanuel[20:48:52] *** ChanServ sets mode: +v emmanuel[20:49:01] *** emmanuel has quit IRC[20:49:13] * dmlloyd scrolls past 9000 lines of whitespace changes[20:49:45] <wolfc> you told me to change that setting :-)[20:49:58] <dmlloyd> only for lines which have been changed![20:50:03] *** kkhan is now known as kabir_afk[20:50:14] <wolfc> somehow Intellij doesn't work correctly with that setting[20:50:22] <wolfc> I keep ending up with whitespace[20:52:05] <dmlloyd> http://imagebin.org/142427[20:52:41] <wolfc> method interceptors != instance interceptors[20:52:46] <Nihility> your handwriting is as bad as mine[20:53:30] <dmlloyd> the first instance one is a DispatcherInterceptor[20:53:36] <dmlloyd> that's where the method lookup happens[20:54:47] <wolfc> DispatcherInterceptor isn't an instance interceptor[20:55:01] <dmlloyd> ok it's the last component one then :)[20:55:05] <wolfc> yes[20:55:19] <wolfc> it's a per VM component interceptor[20:55:37] <Nihility> does ReferenceBindingSourceDescription exist[20:55:47] <dmlloyd> yeah it's stateless, it just looks up the method from the associated component[20:56:07] <Nihility> im trying to merge stuarts work with upstram[20:56:11] <dmlloyd> Nihility: no but org.jboss.as.ee.component.LookupBindingSourceDescription does[20:57:04] <Nihility> ah he created it[20:57:06] <Nihility> i see it now[20:58:27] <Nihility> hmmm looks like EnvEntry...[20:58:40] <baileyje> Nihility: Does his work relate to the DS deployment issue?[20:59:40] <Nihility> yeah somewhat i thought this was already merged[21:04:43] *** kkhan has joined #jboss-as7[21:04:44] *** ChanServ sets mode: +v kkhan[21:08:57] *** alesj has joined #jboss-as7[21:09:17] *** kkhan has quit IRC[21:09:50] *** smarlow has joined #jboss-as7[21:09:50] *** ChanServ sets mode: +v smarlow[21:14:53] *** maxandersen has quit IRC[21:15:41] <wolfc> Okay, so we got either interceptors tied to Component instance or tied to ComponentInstance instance. Currently we don't have interceptors tied to Method instances. Whether we want that now or later I'll leave out for now.[21:15:41] *** smcgowan has joined #jboss-as7[21:15:42] *** ChanServ sets mode: +v smcgowan[21:16:50] <wolfc> We don't have a vocabulary to distinguish lifecycle association and invocation association.[21:17:07] *** aamonten has joined #jboss-as7[21:17:30] *** aamonten has quit IRC[21:17:38] <smarlow> wolfc: "<wolfc> I don't want an interceptor per ComponentInstance instance", I don't have per component instance data either (I will hang my own storage off of TLS), I just need to be invoked for every component instance invocation.[21:17:51] * smarlow just reading irc history to see what I missed...[21:19:17] <wolfc> Yeah, the JPA interceptors need to tie to the ComponentInstance lifecycle.[21:19:39] <wolfc> Then you can associate whatever data you want per ComponentInstance instance.[21:20:58] *** slaboure has quit IRC[21:21:44] *** jfclere has joined #jboss-as7[21:23:10] *** Jaikiran has quit IRC[21:23:20] *** opalka has joined #jboss-as7[21:23:20] *** opalka has joined #jboss-as7[21:23:20] *** ChanServ sets mode: +v opalka[21:25:18] <smarlow> wolfc: both interceptors need to tie to the ComponentInstance lifecycle? The interceptor that tracks SFSB lifecycle would probably work with that but how about the other interceptor that will maintain the SFSB invocation call stack? I don't care which method is invoked, just which bean is invoked.[21:26:13] <wolfc> the SFSB invocation stack interceptor is a lifecycle callback interceptor. we don't have those yet.[21:27:24] <smarlow> okay, just wanted to understand since you said interceptors :-)[21:28:04] <baileyje> smarlow: So one of the issues is the H2DS is not getting deployed.[21:28:17] <baileyje> So the PUService never starts[21:28:22] <wolfc> Hmm, that's actually going to be tricky. The current postConstruct is called in AbstractComponent, while the instance interceptors are not yet there.[21:28:27] <baileyje> which will make all its dependents hang[21:29:46] * wolfc is afk for a bit[21:30:10] <smarlow> sorry phonme[21:31:17] <smarlow> phonme?[21:31:28] <smarlow> sorry, I'm back[21:31:30] <dmlloyd> phone phoneme[21:31:38] <smarlow> :-)[21:32:23] <smarlow> baileyje: thanks for chasing that down. kind of silly[21:32:58] <baileyje> smarlow: I also did a couple other things, but I will wait until we get the DS deployed to figure out if they make sense[21:34:02] <smarlow> baileyje: sounds good, thanks![21:42:44] <smarlow> baileyje: looks like we still have some OSGI issues, I had to disable OSGI to H2DS deployed. Trying the demo now[21:43:14] <baileyje> smarlow: Yeah. It will deploy the driver, but the actual DS won't be installed[21:43:31] <baileyje> even after the OSGI issue, which needs to be removed.[21:43:45] <baileyje> I am not sure what the issue with DS is yet.[21:43:49] <smarlow> "ClassNotFoundException: org.h2.Driver from [Module "deployment.jpa-example.jar:main" "[21:44:16] <baileyje> you dropped the jar in the deployment dir?[21:44:37] <smarlow> yep, I did:[21:44:38] <smarlow> cp ~/work/as7/build/target/jboss-7.0.0.Alpha2/modules/com/h2database/h2/main/h2-1.2.144.jar ~/work/as7/build/target/jboss-7.0.0.Alpha2/standalone/deployments/[21:44:38] <smarlow> cp ~/work/as7/build/target/jboss-7.0.0.Alpha2/standalone/data/system-content/jdbc-local.rar ~/work/as7/build/target/jboss-7.0.0.Alpha2/standalone/deployments/[21:44:58] <baileyje> ahhh.. Interesting,.[21:45:15] <Nihility> looks like all of stuarts patches were merged[21:46:15] <Nihility> baileyje: ^[21:46:46] <Nihility> im looking into deployment[21:46:50] <Nihility> there was a service[21:46:55] <Nihility> that deployed those two jars[21:46:57] <Nihility> in the past[21:47:00] <Nihility> maybe it is not working[21:47:23] <rmaucher> looking at my memory report, I have Module and ModuleClassLoader using the most memory in AS 7[21:47:34] <Nihility> rar exmaple works[21:47:53] <dmlloyd> yeah, rmaucher, because of loaded classes[21:48:06] <dmlloyd> the instances themselves are pretty slim[21:48:31] <dmlloyd> it's the same for startup time: eventually, loading classes is the biggest piece[21:48:44] <dmlloyd> the only solution to both problems is, load fewer classes[21:48:45] <rmaucher> hum, ok; not sure though, the Class instances are third in the memory list[21:48:57] <baileyje> smarlow: Wonder if it is expecting some kind of TCCL in place..[21:48:58] <rmaucher> right :) loading less is good :)[21:49:29] <smarlow> baileyje: I think the DS demo had some classpath entries in MANIFEST.MF[21:49:43] <jbossbot> git [jboss-as] push master 671334f.. Alexey Loubyansky drop '/' prefix for commands, use '/' instead of '~' for the root node, use '/' instead of ',' as a node separator, prefix operations with './' or '/', rename 'to' to 'cn' and 'cd'[21:49:43] <jbossbot> git [jboss-as] push master bc50466.. Alexey Loubyansky state machine-based parsing of parameters and JBAS-8929[21:49:44] <jbossbot> jira [JBAS-8929] CLI address parsing is overly restrictive [Open (Unresolved) Bug, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-8929[21:49:44] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/8c0a7c7...bc50466[21:49:44] <smarlow> so, maybe that is why DS works[21:50:24] <bstansberry> aloubyansky: ^^^ :-)[21:50:56] <smarlow> baileyje: DS demo has: Class-Path: h2-1.2.144.jar[21:51:14] <smarlow> baileyje: and Dependencies: javax.api,com.h2database.h2,org.jboss.integration.jboss-transaction-spi[21:51:18] <bstansberry> aloubyansky: I added "CLI with latest syntax" to the blocker list on http://community.jboss.org/wiki/Beta1MUSTHAVEList[21:51:22] <Nihility> smarlow: baileyje, baileyje this sounds like the TCCL problem[21:52:05] <Nihility> jpederse: so as far as you know there is no ironjacamar TCCL change regarding resources and jndi binding?[21:52:07] <bstansberry> IMO this push ^^^ satisfies that; if you agree, please strike that one off on the wike page[21:52:08] <smarlow> I wonder if the same demo MANIFEST.MF hack would help JPA. wouldn't help users though. I[21:52:18] * smarlow unless they use the same hack :)[21:54:36] <Nihility> baileyje: did we figure out how the jdni stuff is supposed to work there[21:55:53] *** mmoyses has quit IRC[21:58:13] <asaldhan> baileyje: ping your DeployerChainsService class has a com.sun import[21:58:38] <asaldhan> baileyje: removing it, the class is fine.[21:59:34] <asaldhan> baileyje: choked in eclipse. not in the build. interesting.[22:00:27] <jbossbot> git [jboss-as] push master 027751e.. bstansberry at jboss dot com Properly report OFE thrown by MultiStepOperationController[22:00:27] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/bc50466...027751e[22:03:05] <smarlow> baileyje: copying in the DS demo MANIFEST.MF helped workaround the classpath issue[22:04:13] <smarlow> is still got an error but that might of been one I also saw in the EJB3 demo that I cloned (happens near the end of the demo)[22:04:44] * smarlow will step through the code in the debugger to see for sure[22:08:36] <baileyje> Nihility: What jndi stuff?[22:08:49] <Nihility> ROFL[22:08:54] <Nihility> i think i know why it is not working[22:09:05] <Nihility> baileyje: take a look at DataSourcesService[22:09:20] <smarlow> baileyje: I still get the same problem as before.[22:09:36] <baileyje> smarlow: Which problem"[22:09:38] <baileyje> ?[22:09:58] <baileyje> Nihility: You mean it doesn't do anything?[22:10:14] <smarlow> org.jboss.msc.value.InjectedValue.getValue throws java.lang.IllegalStateException[22:10:27] <smarlow> so, the dependency issue[22:10:30] <Nihility> baileyje: yes[22:10:34] <baileyje> that is with the[22:10:37] <smarlow> at least it seems that way[22:10:41] <baileyje> smarlow: with the classpath entry?[22:10:48] <Nihility> baileyje: the way this is supposed to work, is that the config triggers a deployment of those funk jdbc rars[22:11:26] <smarlow> baileyje: yes, I have the MANIFEST.MF hack in place, with the classpath entry[22:11:38] <baileyje> which manifest did you update?[22:11:43] *** darranl has quit IRC[22:12:43] <smarlow> baileyje: hmm, jpa-example.jar/META-INF[22:13:05] <smarlow> I can try the service archive instead[22:14:01] <Nihility> baileyje: hmm maybe i am mixing up two things[22:14:39] <baileyje> smarlow: I think the entry in the manifest is correct in the jpa jar.. Just still not correct in the deployment[22:14:43] <baileyje> give me 5 mins[22:15:00] <asaldhan> Nihility: hey, is the AS7 console based on gwt or seam3?[22:15:36] <Nihility> gwt[22:16:02] <asaldhan> Nihility: not sure why heiko told me it was seam3. anyway. http://relative-order.blogspot.com/2011/03/contributing-to-jboss-7-management.html[22:17:02] <Nihility> heiko braun[22:17:03] <Nihility> ?[22:17:07] <Nihility> he told you it was seam[22:17:08] <Nihility> ?[22:17:08] <asaldhan> Nihility: yeah.[22:17:17] <Nihility> he must have been joking with you[22:17:43] <Nihility> it was never going to be seam[22:18:04] <asaldhan> Nihility: not sure. because for picketlink, I was thinking of doing gwt. Then we were wondering if we ever were to integrate into the AS7 console, then it would be challenging.[22:18:19] <asaldhan> Nihility: so I sent him an email and he said, we are going to be using seam4. :)[22:18:25] <asaldhan> Nihility: seam3[22:18:33] *** ALR has quit IRC[22:19:16] <Nihility> asaldhan: lay off the crack man :)[22:19:32] <asaldhan> Nihility: I took his email the wrong way.[22:19:38] <asaldhan> Nihility: rereading it.[22:19:59] <asaldhan> Q. Will the AS7 console be based on straight gwt or errai?[22:20:03] <asaldhan> A. no[22:20:26] <asaldhan> above that he said, errai has moved toward seam3.[22:20:58] <asaldhan> Nihility: since it was Friday, I must have jumped the gun and assumed as7 was seam3.[22:21:31] <asaldhan> Nihility: I must have been on crack.[22:21:37] <Nihility> haha[22:22:06] * asaldhan reminds himself to read emails 2-3 times on a friday.[22:22:15] <Nihility> asaldhan: i say he was screwing with you[22:22:17] <Nihility> :)[22:22:35] <asaldhan> Nihility: he was not. he was correct. he just said, it wont be straight gwt.[22:22:57] <asaldhan> Nihility: since he mentioned errai is more geared toward seam3, I muddled up in my mind. ;)[22:23:20] <Nihility> thats gwt bases as well[22:23:37] <Nihility> client side javascript[22:23:47] <asaldhan> Nihility: seam3?[22:23:52] <Nihility> errai[22:24:06] <Nihility> seam3 was supporting gwt though[22:24:08] <asaldhan> Nihility: yeah I know. because I had done PL console using errai before falling off.[22:24:12] <Nihility> maybe thats how it all interrelates[22:24:32] <asaldhan> Nihility: I wanted to ressurect pl console and was checking to see if errai was alive.[22:25:56] <Nihility> baileyje, jpederse : i cant find anything that goes from datasources to code that deploys them[22:28:21] <baileyje> I don't see it either[22:29:07] <Nihility> oh its a red herring[22:29:13] <Nihility> there is two paths[22:30:01] <Nihility> its a attached as a processor[22:32:46] <jbossbot> git [jboss-as] push master 00df15c.. Darran Lofthouse [JBAS-8942] Rename <management> element to <management-interfaces> in both host.xml and standalone.xml.[22:32:47] <jbossbot> jira [JBAS-8942] Rename <management> element to <management-interfaces> in both host.xml and standalone.xml [Coding In Progress (Unresolved) Task, Major, Darran Lofthouse] https://issues.jboss.org/browse/JBAS-8942[22:32:48] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/027751e...00df15c[22:33:39] <Nihility> baileyje: this whole process is very strange[22:33:49] <Nihility> baileyje: it happens from the deployer[22:34:58] <Nihility> every deployment[22:35:04] <Nihility> seems to try to deploy datasources[22:36:21] <baileyje> smarlow: Ok.. I have it trying to create a PU[22:36:28] <Nihility> oh yeah i see it[22:36:40] <Nihility> so basically we lost the part[22:36:46] <smarlow> baileyje: cool :)[22:36:48] <Nihility> where we try to deploy the jdbc* stuff[22:37:05] <baileyje> and I am getting ....http://pastebin.com/0p7CcMBN[22:37:10] <dmlloyd> getting rid of those two rars is on my beta2 list :|[22:37:12] * smarlow looking[22:37:31] *** aloubyansky has quit IRC[22:39:29] <smarlow> baileyje: excellent! that is great progress! It looks like Hibernate failed to get a connection for some reason[22:40:45] <baileyje> So one issue I see is that there is both a module and a deployment for H2[22:40:51] <baileyje> which could be a bad thing[22:41:26] <dmlloyd> there should *not* be a module for H2[22:41:33] <dmlloyd> that should go[22:43:46] <baileyje> Right. But we will need some way to get the driver class loaded from LocalManagedConnectionFactory[22:43:49] <Nihility> 2eac472d3890dee7f4414c13b8dbd95e7e392904[22:44:04] <Nihility> that killed the JDBCRARDeployService[22:44:11] <Nihility> dmlloyd: remember why?[22:44:21] <baileyje> dmlloyd just loves to remove stuff[22:44:30] <dmlloyd> there should be an existing registry, baileyje, of driver classes to module[22:44:40] *** ALR has joined #jboss-as7[22:44:40] *** ChanServ sets mode: +v ALR[22:44:57] <smarlow> I don't see any references to com.h2database.h2 in modules source folder (maybe in code)[22:45:53] <Nihility> yeah i can't figure out why it was deleted[22:45:57] <dmlloyd> no I don't remember why Nihility[22:45:59] <Nihility> it seems to have nothing to do with the change[22:46:05] <baileyje> dmlloyd: right. Other deployments will need to get the modules added to their deployments though[22:46:15] <dmlloyd> it might have just been too broken to survive the refactor[22:47:16] * smarlow might be references to it in demos, testsuite[22:47:54] <baileyje> smarlow: It is in the manifest entry for some demos[22:48:09] <dmlloyd> baileyje yeah we should be basically adding the module as a dependency to anything which injects a data source for that driver[22:48:14] <Nihility> dmlloyd: maybe thats why, so the question is then how can a service execute a deployment[22:48:43] <baileyje> dmlloyd: The problem is that deployments can look the DS up without declaring any dep[22:48:54] * stuartdouglas is back from indoctrination[22:49:01] <dmlloyd> Nihility, well, you can create a DeploymentUnitService for it.... and hope nobody creates a real deployment with the same name :)[22:49:06] <stuartdouglas> I mean orienttation[22:49:15] <dmlloyd> disorientation[22:49:31] <dmlloyd> baileyje: yeah those apps are screwed[22:49:40] <smarlow> the DS demo usage also tells you to put com.h2database.h2 in domain.xml or standalone.xml[22:49:41] <baileyje> That isn't an answer[22:49:48] <dmlloyd> baileyje: they need a manual dep else they need to use the JDBC API only[22:49:50] <Nihility> dmlloyd: yeah those are "reserved" names[22:50:08] <Nihility> i have to say i find it funny[22:50:16] <Nihility> that i am working on the EXACT same problem[22:50:21] <Nihility> right before Alpha1[22:50:24] <Nihility> before Beta1[22:50:30] <Nihility> (a couple days before)[22:50:31] <dmlloyd> maybe next time we'll actually fix the issue[22:50:41] <dmlloyd> having to deploy a RAR to support data sources is stupid[22:51:05] <Nihility> agreed[22:51:50] <opalka> stuartdouglas, Is your master ready for merge? It contains fixes we're really missing on AS7 master :([22:51:55] <baileyje> Anyway, I do not agree a deployment needs to have a DS injection to use one. You would be screwing a lot of customers.[22:52:53] <dmlloyd> org.jboss.as.server.deployment.RootDeploymentUnitService[22:53:14] <Nihility> allow me to jump in[22:53:23] <Nihility> the problem is with our dataousrce impl[22:53:40] <stuartdouglas> opalka: not quite yet, I will get it ready now, how do I get the WebServiceContext ?[22:53:42] <Nihility> you should be able to lookup any datasource[22:53:51] <Nihility> WITHOUT A MODULE DEPENDENCY[22:53:51] <stuartdouglas> Is there an easy way?[22:53:56] <dmlloyd> exactly Nihility[22:54:04] <Nihility> its simply not needed[22:54:09] <dmlloyd> JDBC API covers it[22:54:16] <opalka> stuartdouglas, let me have a look ...[22:54:20] <dmlloyd> most of the tiem[22:54:27] <Nihility> the problem is that jca is using TCCL to load the driver[22:54:37] <Nihility> ill foward the convo[22:54:39] <Nihility> one sec[22:54:52] <dmlloyd> yeah apparently despite the recent changes to driver deployment[22:54:54] <baileyje> THey just need a smarter OF[22:55:02] <Nihility> baileyje: exactly[22:55:32] <dmlloyd> why isn't there just a single driver instance to begin with[22:55:35] <dmlloyd> that's what I want to know[22:55:42] <dmlloyd> the driver deployer should create the single instance[22:55:43] <baileyje> We have all kinds go smart OF with regard to modules and msc. They should be able to work something in that will eliminate the TCCL or at least make it correct[22:55:58] <dmlloyd> it sholdn't have to load jack shit[22:56:10] <dmlloyd> it should just grab the Driver instance out of MSC and run with it[22:56:49] *** jfclere has quit IRC[22:56:50] *** jfclere1 has joined #jboss-as7[22:57:16] <baileyje> also, we should really use a binder service anyway[22:57:20] <Nihility> i forwarded you guys my email discussion[22:58:07] <Nihility> there is only two cases a user needs an import[22:58:12] <Nihility> 1) they use vendor jdbc types[22:58:19] <Nihility> 2) they are using @DataSourceDefinitino[22:58:37] <dmlloyd> agreed[22:59:08] <Nihility> jesper basically agreed[22:59:15] <Nihility> its just a matter of doing it[22:59:37] <baileyje> Ok. Should we do it?[22:59:55] <Nihility> yeah i think so[23:00:02] <dmlloyd> I thought we already had[23:00:03] <Nihility> unless stefano already did[23:00:14] <Nihility> @DataSourceDefinitino is done[23:00:29] <Nihility> its datasources in standalone.xml that do not work[23:00:32] <Nihility> (they do not activate)[23:00:43] <Nihility> and when they do they require a module i mport[23:01:10] <Nihility> ill look in his branch[23:01:13] <baileyje> and the module import doesn't work anyway, since the driver ends up in two CLs[23:01:14] <Nihility> my guess is that he didnt do it[23:01:32] <dmlloyd> all datasource should do is set up the service and inject the driver via MSC[23:01:33] <Nihility> really?[23:01:42] <Nihility> but h2 isnt deployed ....[23:01:51] <Nihility> or do you mean in the case where it is[23:01:59] <dmlloyd> to me or john[23:02:03] <Nihility> john[23:02:09] *** aslak has joined #jboss-as7[23:02:09] *** aslak has quit IRC[23:02:09] *** aslak has joined #jboss-as7[23:02:10] *** ChanServ sets mode: +v aslak[23:02:15] <smarlow> stefano did do a org.jboss.as.connector.services.JndiService[23:02:19] <Nihility> in reply to 2 two Cls[23:02:26] <baileyje> if you drop the h2 jar and the jdbc-local into the deployment jar[23:02:31] <baileyje> sorry deployment dir.[23:02:37] <baileyje> it will bind the DS[23:02:37] *** aslak has quit IRC[23:02:46] <baileyje> but will fail on lookup with a CL issue[23:02:59] *** aslak has joined #jboss-as7[23:02:59] *** ChanServ sets mode: +v aslak[23:03:10] <opalka> stuartdouglas, see org/jboss/webservices/integration/injection/WebServiceContextResourceProvider.java in AS6/webservices subsystem[23:03:20] <Nihility> baileyje: there should be no need to do that[23:03:25] <baileyje> if you add the H2 module (which should be removed) to the deployments dep, it will work to a degree[23:03:27] <opalka> stuartdouglas, and tell me know if it contains all the information U need to know[23:03:41] <baileyje> but will get screwy results since the jar is loaded twice[23:03:43] <Nihility> baileyje: the datasource reference has a module link[23:03:48] <Nihility> in standalone.xml[23:03:50] <Nihility> to h2[23:03:54] <Nihility> so we should not have to deploy it[23:03:58] <stuartdouglas> opalka: If it does not I will just do up a hack that injects null[23:04:04] <dmlloyd> stuartdouglas: it looks like web deployments are still not seeing libraries in standalone/lib/ext[23:04:11] <baileyje> Nihility: Ok. Maybe smarlow's branch is out of date.[23:04:16] <baileyje> Does it work on master?[23:04:29] <stuartdouglas> and they have the extension-list items?[23:04:30] *** jamezp has quit IRC[23:04:33] <Nihility> baileyje: no because jbbc-local.jar is not getting deployed like it should[23:04:36] <dmlloyd> stuartdouglas: yeah supposedly[23:04:41] <Nihility> baileyje: if you drop in the rar, it should work[23:04:48] <opalka> stuartdouglas, In AS6 days it was JBossWS responsibility to create WebServiceContext instances.[23:04:52] <dmlloyd> stuartdouglas: if you're working on @WebServiceRef be sure to sync up with frainone[23:04:57] <stuartdouglas> in META-INF now WI/classes/MI?[23:05:15] <dmlloyd> stuartdouglas: I can check that...[23:05:37] <stuartdouglas> I'm not working on @WebServiceRef, I was just looking at @Resource injection for WebServiceContext[23:05:43] *** jamezp has joined #jboss-as7[23:06:03] <opalka> stuartdouglas, To construct it on your own U'll need to do[23:06:07] <opalka> iimport org.jboss.wsf.common.injection.ThreadLocalAwareWebServiceContext;[23:06:08] <opalka> ...[23:06:22] <opalka> ThreadLocalAwareWebServiceContext.getInstance();[23:06:29] <dmlloyd> stuartdouglas: yeah they're just plain JARs with extension-list on them - it works if they're added to WEB-INF/lib but not if they're in standalone/lib/ext[23:06:48] <dmlloyd> so tomcat must still be grabbing those somehow[23:06:55] <Nihility> baileyje, dmlloyd: assuming we went to driver deployment across the board, then instead of a module ref, the app would need to have a driver ref[23:07:06] <Nihility> (in the case where a vendor type is needed)[23:07:14] <stuartdouglas> dmlloyd: ah, so does tomcat still make the deployment fail?[23:07:18] <dmlloyd> they could just have a class-path to the JAR, Nihility[23:07:25] <baileyje> Nihility: Yes. It should be able to just create the[23:07:30] <opalka> stuartdouglas, In AS6 days the WebServiceContext @Resource provider was located in webservices submodule[23:07:38] <baileyje> DS with a dep on the driver[23:07:44] <opalka> stuartdouglas, I think this is the right location for it even now in AS7[23:07:49] <opalka> stuartdouglas, objections?[23:07:50] <dmlloyd> stuartdouglas: I thought rmaucher fixed that but maybe not yet?[23:07:51] <stuartdouglas> I talked to rmaucher about that I while back, and he said he would remove the tomcat code that does the checking[23:08:03] <Nihility> dmlloyd: class-path sounds like a bad idea if the point is to do versioning with Drivers[23:08:17] <rmaucher> I removed the extension validator[23:08:25] <rmaucher> so it's gone[23:08:26] <stuartdouglas> however I am not sure if this has made it in yet[23:08:31] <dmlloyd> Nihility the point is just to avoid polluting all deployments with all drivers really[23:08:42] <dmlloyd> Nihility: and to avoid adding more constructs if possible[23:08:46] <rmaucher> and I've been told that shared libs would be handled through extensions[23:08:50] <stuartdouglas> rmaucher: Is it just gone in upstream or has that made it into AS7?[23:09:00] <rmaucher> it's in AS 7[23:09:06] <dmlloyd> rmaucher: somehow, wars are still working differently from other deployment types[23:09:21] <stuartdouglas> opalka: Yes, I think it should be in the webservices submodule[23:09:35] <stuartdouglas> I will look into the extension-list thing[23:10:03] <Nihility> opalka: ideally jbossws would implement the logic, but take advantage of the AS injection facilities[23:10:30] <rmaucher> dmlloyd, differently ?[23:10:32] <opalka> Nihility, Yes, I'd expected it our team will implement it ;)[23:11:05] <Nihility> opalka: then you guys dont have to worry about the jndi names being created[23:11:09] <dmlloyd> rmaucher: basically WAR deployments are only seeing extensions that are deployed with the WAR - the EE extension processor is not working for some reason[23:11:40] <rmaucher> ah ok[23:11:44] <opalka> Nihility, Yes, we even didn't care about JNDI names in AS6[23:13:47] <stuartdouglas> ok, in that case I could just hack it up so it will no longer cause a deployment error[23:14:36] <opalka> stuartdouglas, fine with me[23:14:48] <dmlloyd> stuartdouglas: it comes from a JSP, if that sheds any light[23:14:53] *** alesj has quit IRC[23:15:31] <dmlloyd> I assume Jasper is using TCCL to compile the JSPs[23:17:47] <smarlow> baileyje: can we sync your changes with my branch? however you prefer is fine.[23:18:39] <Nihility> baileyje: so i will fix this and have jdbc-local auto deploy again[23:18:49] <stuartdouglas> dmlloyd: would it be possible for me to get the war / jars in question?[23:19:05] <baileyje> Nihility: What are we going to do about getting the driver jars deployed?[23:19:31] <Nihility> baileyje: well if the module ref still works i say we just use that, its already in standalone.xml[23:19:45] <baileyje> It doesn't, at least not in master[23:20:20] <Nihility> ah ok so i guess we need to fix jndi''s usage of driver[23:20:21] <opalka> baileyje, Did U fixed this concurrency issue already locally? http://fpaste.org/CITH/[23:20:24] <baileyje> I don't see a module ref[23:20:33] <opalka> baileyje, asking to save some time. If not I can go ahead and provide cherry pick[23:20:34] <Nihility> <module>[23:20:34] <Nihility> org.h2.Driver#1.2[23:20:35] <Nihility> </module>[23:20:39] <Nihility> oh[23:20:41] <Nihility> nm[23:20:46] <Nihility> thats no longer a right module ref[23:20:46] <Nihility> haha[23:20:58] <dmlloyd> stuartdouglas: smcgowan is going to send you an email with the info[23:21:07] <baileyje> yeah. That is just the driver it is expecting[23:21:17] <baileyje> the driver jar still needs to be deployed[23:22:04] <dmlloyd> opalka: if you have a fix for that I'll merge it in, that's fairly serious[23:22:06] <baileyje> opalka: I have not looked at it[23:22:32] <opalka> baileyje, dmlloyd Give me few minutes. I'll fork custom branch and will fix it. Then U can cherry pick David[23:22:59] <baileyje> Nihility: I think the following is needed.[23:23:15] <baileyje> 1. The auto-deploy of the jdbc-*.jar s[23:23:47] <baileyje> 2. The deployment of the driver jar (not necessarily automatic, but would be nice)[23:23:48] <dmlloyd> opalka: somehow that listener got pretty fucked up. using an identity map keyed on service name - non-synchronized access to all those collections[23:23:51] <dmlloyd> bad stuff[23:24:06] <Nihility> ah crap[23:24:09] <Nihility> that does suck[23:24:23] <opalka> dmlloyd, Do U want me to rewrite it? NP for me ...[23:24:23] <baileyje> 3. Somehow getting the OF to no longer use a TCCL to access the Driver class[23:25:31] <dmlloyd> opalka: go ahead[23:25:47] <Nihility> im not sure this new driver model allows us to auto deploy them[23:26:00] <dmlloyd> why would we auto deploy them?[23:26:07] <dmlloyd> oh the rars :([23:26:11] <Nihility> not the rars[23:26:14] <Nihility> the jdbc driver[23:26:40] <dmlloyd> well, I guess it really depends - are we bundling it?[23:26:42] <Nihility> now for all our demos we have to copy the driver into deploy before we use a datasource[23:26:53] <baileyje> The problem is if we auto-deploy the rars, it will bomb the server start.[23:27:04] <baileyje> if the datasource is configured.[23:27:07] <Nihility> ah because the driver doesnt exist[23:27:10] <dmlloyd> none of that makes any sense[23:27:23] <dmlloyd> I mean a DS should just create a dep on the driver MSC service[23:27:33] <dmlloyd> then using the DS creates a dep on the DS service[23:27:49] <baileyje> dmlloyd: I agree. But the DS service needs to be installed[23:28:01] <dmlloyd> it should be initialized on add[23:28:18] <dmlloyd> mode ACTIVE or even PASSIVE, the dependency will keep it idle until the driver appears[23:28:21] <baileyje> it is currently initialized when the jdbc-*.jar is installled[23:28:38] <Nihility> honestly i think this feature was half baked[23:28:41] <Nihility> when it was merged[23:28:45] <dmlloyd> yeah that makes no sense, but then putting the logic in a jdbc* thing is broken in the first place[23:28:52] <baileyje> correct[23:28:54] <dmlloyd> that's a core feature of the subsystem[23:28:59] <Nihility> maybe we should just revert it[23:29:02] <baileyje> BEing a RAR does not make sense,[23:29:49] <Nihility> maybe it can be fixed though[23:29:52] <Nihility> ill look into it[23:30:11] <baileyje> I think ideally there would be no RAR[23:30:19] <Nihility> thats impossible to fix now[23:30:22] <opalka> dmlloyd, Do U know about better fix than this one? - http://fpaste.org/zjqN/[23:30:25] <baileyje> when you install the DS it makes a dep on the Driver.[23:30:35] <baileyje> If the driver jar is not deployed you get a missing dep issue[23:30:43] <Nihility> its still kind of annoying that our demos have to deploy a jdbc driver though[23:31:05] <dmlloyd> opalka: that should be OK to start with[23:31:11] <Nihility> well at least it will test deploy order![23:31:17] <opalka> dmlloyd, OK[23:31:28] <dmlloyd> opalka: if those sets are modified after the listener fires then there might be another issue but we'll see if it happens[23:31:47] <baileyje> dmlloyd: It must of happened.[23:31:48] <Nihility> maybe we could package it together or something[23:32:11] <dmlloyd> baileyje: well, the fact that they aren't synchronized can have very odd effects that make it appear that way[23:32:26] <opalka> dmlloyd, according to my review this should fix the problem[23:32:43] <baileyje> dmlloyd: Yeah.[23:33:49] <Nihility> baileyje: are you going to be on later tonight, i need to step away and do the family thing[23:34:07] <baileyje> I may be on later. Like 11ish[23:34:23] <baileyje> otherwise tomorrow[23:34:28] <Nihility> baileyje: so you are saying that if there is a dep on Driver[23:34:33] <Nihility> it wont work[23:34:35] <Nihility> ?[23:34:56] <baileyje> well it will get things ordered correctly, but I think the CL issue will still pop up.[23:35:02] <baileyje> but I am looking into that now[23:35:09] <Nihility> yeah the cl issue we can fix at the jndi end[23:35:26] <Nihility> im talking about the problem where you asked about "baileyje: If the driver jar is not deployed you get a missing dep issue"[23:36:09] <baileyje> It will work if there is a dep on the driver and the driver jar is deployed[23:36:58] <Nihility> imo thats going to be a major usability problem[23:37:06] <Nihility> someone drops a jar in deploy[23:37:20] <Nihility> for the driver[23:37:28] <Nihility> another for the module[23:37:34] <Nihility> then they restart[23:37:40] <Nihility> race![23:37:53] <smcgowan> stuartdouglas: if you don't have access to that repo url i sent you i'll forward a gzip your way[23:38:17] <jbossbot> git [jboss-as] push master 111c051.. Emanuel Muckenhuber rename executionContext to operation[23:38:17] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/00df15c...111c051[23:38:48] * opalka 's testing local patch ...[23:39:48] <Nihility> dmlloyd: if deployment A has a dependency on deployment B and both are in deployments.xml will they wait for each other correctly[23:40:07] <Nihility> will A wiat for b[23:40:08] <dmlloyd> standalone.xml, yeah[23:40:16] *** frainone has quit IRC[23:40:18] <dmlloyd> they'll set up interdependencies[23:40:21] <Nihility> im trying to see how this driver problem comes into play[23:40:56] <baileyje> Nihility: I think the driver dependency is already there[23:41:07] <Nihility> oh its the rar deployments[23:41:18] <baileyje> See DsDeploymentProcessor.addJdbcDependency[23:41:20] <Nihility> the rar deployments need to depend on every possible jdbc driver[23:41:31] <Nihility> which will never work[23:41:38] <baileyje> why?[23:41:51] <Nihility> hmmm oh they can get it from standalone.xml nevermind[23:41:51] <baileyje> why does it have to depend on all drivers?[23:41:53] <dmlloyd> probably because the RARs are using TCCL[23:42:00] <dmlloyd> amirite?[23:42:04] <baileyje> that is the only issue as I can see[23:42:14] <baileyje> the DS uses TCCL to lookup the driver[23:42:15] <dmlloyd> they should be using service deps only[23:42:15] <Nihility> baileyje: where does the dep problem you mention come from[23:42:21] <dmlloyd> there should not be any class loading going on, period[23:42:26] <Nihility> are you talking about module deps and not service deps maybe?[23:42:42] <Nihility> "baileyje: If the driver jar is not deployed you get a missing dep issue"[23:42:43] <baileyje> I was saying there is a dep problem if you forget the driver jar[23:42:50] <Nihility> OH[23:42:53] <Nihility> so not order[23:42:59] <Nihility> just if its not deployed it doesnt work[23:43:06] <baileyje> yeah. Just when they forget the driver[23:43:07] <dmlloyd> if you then deployed the driver though everything should come up[23:43:11] <baileyje> right[23:43:20] <Nihility> ok you had me all worried[23:43:28] <baileyje> I wasn't saying that was an issue, just that is what would happen[23:43:41] <Nihility> ok got to run[23:43:44] <Nihility> ill bbl[23:43:44] <baileyje> So the only real problem is the TCCL lookup f the driver[23:43:52] <dmlloyd> which should not even be necessary[23:43:53] <Nihility> yeah and i think we can fix that[23:44:04] <dmlloyd> and I get irritated anew every time it comes up :)[23:44:13] <baileyje> and the RAR itself, but that nut can be cracked later.[23:48:14] <baileyje> It already uses a ModularReference for the OF which is good[23:48:17] <opalka> dmlloyd, here U go https://github.com/ropalka/jboss-as/commit/a007cbf33e70b20a0dc6d6a2eb20db154b03ef8f[23:48:18] <jbossbot> git [jboss-as] a007cbf.. Richard Opalka fixing concurrency issue[23:49:34] <opalka> dmlloyd, hotfixes branch[23:49:52] <jbossbot> git [jboss-as] push master f1046ca.. Richard Opalka fixing concurrency issue[23:49:52] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/111c051...f1046ca[23:52:13] <opalka> stuartdouglas, how is WebServiceRef hacking going?[23:54:05] <opalka> stuartdouglas, asking 'cos I'd really like to see your master be applied upstream on Monday :)[23:57:56] <dmlloyd> WSRef is being worked on by frainone[23:58:00] <stuartdouglas> opalka: I just woke up, so I just ducked out to get some milk for coffee[23:58:17] *** jfclere1 has quit IRC[23:59:31] * opalka 's going to bed[23:59:48] *** opalka has quit IRC