[00:00:29] <stuartdouglas> dmlloyd: How does dependencyUninstalled work with optional deps?
[00:00:47] <stuartdouglas> will it still be called if it is an optional dependency that is missing/unistalled?
[00:01:20] <dmlloyd> no it will only be called if a missing dep prevents service start
[00:04:22] <dmlloyd> though again it may be a transient condition so the deployment shouldn't necessarily blow up the second it gets one
[00:05:30] <stuartdouglas> yea, otherwise nothing would deploy :-)
[00:05:51] <dmlloyd> ideally, the deployment will blow up only if (a) all ACTIVE services which are a part of the over-arching operation which created the deployment (be it server startup, a composite op, whatever) are either started or have a failure of some sort, and (b) the specific deployment has at least one failure
[00:06:32] <dmlloyd> implementing (a) might actually be a little tricky
[00:06:47] <stuartdouglas> dmlloyd: Does this look reasonable: https://github.com/stuartwdouglas/jboss-as/commit/d4a55f21df358a9051c200d507ca97aa89e1024c
[00:06:48] <jbossbot> git [jboss-as] d4a55f2.. Stuart Douglas Fix deployment listener
[00:07:45] <dmlloyd> the listener can get a double-tick then
[00:07:52] <stuartdouglas> when?
[00:07:55] <dmlloyd> tick() can only be called once per service otherwise the count will be off
[00:07:57] <jbossbot> git [jboss-as] push master 8eb15ca.. Emanuel Muckenhuber add describe-operations test case
[00:07:58] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/04f816a...8eb15ca
[00:08:10] <dmlloyd> if dependencyUninstalled() is called then dependencyInstalled() is called
[00:08:36] <stuartdouglas> dependencyInstalled increments the count
[00:08:43] <dmlloyd> yeah but it shouldn't
[00:08:52] <dmlloyd> the count should be incremented only when the listener is attached
[00:09:19] <dmlloyd> that count is how many services have to be "done" before the deployment is "done"
[00:09:50] <stuartdouglas> but, dependencyUninstalled is transient, when it gets called the service may or may not be 'done'
[00:09:51] <dmlloyd> hm it's a bit goofy
[00:09:57] <dmlloyd> I'd have to chart out all the possibilities...
[00:10:01] *** adietisheim1 has quit IRC
[00:11:11] <dmlloyd> you don't want to be in a situation where count goes from 0 to 1 again
[00:11:17] <dmlloyd> once it hits 0 that should be the end of it
[00:11:40] <stuartdouglas> that still is the case, as once it hits 0 there should be no way the dependencyInstalled can be called
[00:11:53] <stuartdouglas> as everything that is going to start, has started
[00:12:25] <stuartdouglas> unless a server has a dep on a non-existant on-demand service that then gets added by a later service...
[00:13:21] *** bstansberry is now known as bstans_afk
[00:13:33] <dmlloyd> yeah if dependencyUninstalled ticks it to 0 but after the error is reported the missing dep comes in it could get wedged
[00:13:49] <dmlloyd> possibly
[00:14:27] <stuartdouglas> It would not get wedged, it would just report the deployment as up slightly before it actually was
[00:14:42] <stuartdouglas> similar to what it does at the moment, but not nearly as likely
[00:15:22] <stuartdouglas> but I don't think there is any real way to help that when you are dealing with on-demand services
[00:16:32] <dmlloyd> well it'd report an error then it would report another message as well
[00:16:42] <dmlloyd> yeah that's why we exclude non-ACTIVE services from the count
[00:16:51] <dmlloyd> if all ACTIVE services come up then we call it a success
[00:17:03] <dmlloyd> PASSIVE/ON_DEMAND/NEVER don't count
[00:17:39] <stuartdouglas> so if you don't like that approach what do you recommend?
[00:18:09] <dmlloyd> I don't mind the approach, I'd just want to be sure that it can't screw up
[00:18:26] <dmlloyd> also it doesn't account for one situation which is important: when you have two interdependent deployments installed by one composite operation
[00:18:35] <dmlloyd> that's a weakness of the existing impl
[00:19:01] <stuartdouglas> what happens in this case?
[00:19:11] <dmlloyd> well, it depends on luck really
[00:19:31] <dmlloyd> but it's possible that both deployments will report failure due to missing dep before they both come up successfully
[00:19:48] <dmlloyd> beacuse all of each deployment's ACTIVE services are either up or missing a dep
[00:19:58] <dmlloyd> or at least one of them
[00:20:19] <stuartdouglas> that should still work
[00:20:38] <dmlloyd> it would work if there were one listener covering both deployments, somehow
[00:21:10] <stuartdouglas> what do you mean by interdependent deployments?
[00:21:36] <dmlloyd> two JARs which inject each others EJBs for example will both produce services depending on services from the opposite JAR
[00:22:29] <dmlloyd> JBAS-9010 captures the requirements for the most part
[00:22:30] <jbossbot> jira [JBAS-9010] Provide more comprehensive error messages for missing dependencies [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9010
[00:22:33] <stuartdouglas> ah, although that only applies to sub deployments
[00:22:45] <dmlloyd> well it also applies to two interdependent top-level deployments
[00:22:53] <dmlloyd> esp. when you consider stuff bound into global for example
[00:23:37] <stuartdouglas> but do we want the deployment op to block until the other top level item becomes availible?
[00:24:03] <dmlloyd> well depending on what you mean by "block"
[00:24:09] <stuartdouglas> or should it deploy, report the missing deps, and then finish starting once the top level item becomes availble
[00:24:12] <dmlloyd> the services won't start but there'd be no blocking threads
[00:24:21] <dmlloyd> yes exactly
[00:24:32] <dmlloyd> but if you deploy both at the same time there should be no complaint
[00:24:39] <stuartdouglas> the deployment handler will block, waiting for the deplyment to finish
[00:24:59] <dmlloyd> the client might block if it's using a blocking API
[00:25:00] <stuartdouglas> e.g. if you are running an arq test, the test run will just stop
[00:25:07] *** emmanuel has quit IRC
[00:25:22] <dmlloyd> the client should unblock with an error when the deployment is considered "done" by the above criteria
[00:25:35] <dmlloyd> until/unless a new service set comes into play, I guess
[00:25:47] <stuartdouglas> there is no way to tell that
[00:25:53] <dmlloyd> yeah there is
[00:26:10] <dmlloyd> the deployment will blow up only if (a) all ACTIVE services which are a part of the over-arching operation which created the deployment (be it server startup, a composite op, whatever) are either started or have a failure of some sort, and (b) the specific deployment has at least one failure
[00:26:38] <dmlloyd> the deployment will still be in the container, unless the client removes it (it's considered a runtime failure not a model failure)
[00:26:59] <stuartdouglas> so in the case of waiting on another deployment it will never unblock if the deployment is not added
[00:27:33] <dmlloyd> the client will unblock as soon as all of the active services are up or marked as dependencyUninstalled
[00:27:46] <dmlloyd> because at that point it knows that santa claus is not coming
[00:28:24] <stuartdouglas> but as dependencyUninstalled is transient is may unblock to early, and that causes smoke tests failures / kills baby seals etc
[00:30:14] *** wolfc has quit IRC
[00:30:40] <dmlloyd> right that's why the other side of the rule exists
[00:31:18] <dmlloyd> as long as a deployment is busy installing services, the deployment service itself never finishes starting, thus the rule is never satisfied until all services which are going to be installed on behalf of a deployment are installed
[00:33:05] <stuartdouglas> so basically, we should just delete the dependencyUninstalled handler, and let the deployment hang in case of missing dependencies?
[00:33:44] <dmlloyd> unless we determine that there are no more services being installed, which we can via the above rule
[00:35:14] <stuartdouglas> my patch does not actually make the deployment blow up as such, what it will do is print a message saying the deployment is blocked waiting for dependencies
[00:35:23] <stuartdouglas> actually it does make it blow up
[00:36:00] <stuartdouglas> but if those deps get added then the deployment will continue, and another message will get printed out saying that it worked
[00:37:27] <stuartdouglas> we have no way of knowing if a given global dependency is going to come up or not, if the deployment hits the stage were it is waiting for a global dep to be installed that should trigger a message to that effect and the handler to unblock
[00:37:58] <stuartdouglas> if the global dep does appear, then the deployment should resume, and another message be printed when it finishes
[00:38:29] <stuartdouglas> although with to deployments going side by side this could result if lots of superfloius messages
[00:39:35] <dmlloyd> yeah we don't want that
[00:39:41] <dmlloyd> it almost seems like we need two listeners
[00:39:56] <dmlloyd> one which covers the overarching in-progress operation, and one for each deployment which tracks it
[00:40:17] <dmlloyd> the overarching listener will inform the deployment listeners when all the services are installed and then the deployment listeners can report
[00:40:31] <dmlloyd> that also has the advantage that the deployment listeners can hang around and report changes in status
[00:40:52] <dmlloyd> i.e. I remove fooejb.jar and bar.war can report "uh hey you just broke me, give fooejb.jar back again plz"
[00:41:21] <dmlloyd> wouldn't necessarily cause an error for the op undeploying fooejb.jar
[00:41:54] <stuartdouglas> this is a fairly big change, as it means we will need to keep the listeners on all the services
[00:41:59] <stuartdouglas> rather than removing them
[00:42:15] <dmlloyd> yeah and we'd also need that operation-wide listener
[00:42:24] <stuartdouglas> so we will need to track the state of all these services so that we can handle the state transition properly
[00:42:29] <dmlloyd> it can wait until beta3 tbh
[00:42:31] *** jamezp has quit IRC
[00:42:55] <stuartdouglas> how about I just delete dependencyUninstalled so the smoke tests work again for now?
[00:43:09] <dmlloyd> sure, I'm overthinking this for the near term :)
[00:43:22] <dmlloyd> you change is probably fine for now tbh
[00:43:28] <dmlloyd> the one you submitted
[00:43:53] <stuartdouglas> it is more user friendly in terms of telling you why you deployment did not work
[00:44:02] <stuartdouglas> rather than using jconsole
[00:44:22] <dmlloyd> we won't treat that as the resolution to JBAS-9010 but it'll solve the immediate issue
[00:44:23] <jbossbot> jira [JBAS-9010] Provide more comprehensive error messages for missing dependencies [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9010
[00:44:42] <stuartdouglas> I might get bstans_afk to test it again
[00:45:02] <stuartdouglas> before it is committed, just to make sure I have not stuffed something
[00:45:11] *** jamezp has joined #jboss-as7
[00:50:15] <dmlloyd> hey jamezp.  Have you found an issue to take up?
[00:50:38] <jamezp> I looked a bit, but haven't decided.
[00:51:02] <jamezp> I need to find something I can balance with my daily work load and not totally f-up :-)
[00:51:24] <dmlloyd> one of the module rename tasks might be good.  it'll also familiarize you with the build process
[00:51:41] <jamezp> Ah, okay. That makes sense.
[00:51:42] <dmlloyd> and they generally have the advantage of either working completely or failing completely :)
[00:51:54] <jamezp> Haha. That I like :-)
[00:52:06] <jamezp> Is it best to just assign it to myself or let you know?
[00:52:23] <dmlloyd> assign it to yourself, but if jira won't let you do that let me know
[00:53:56] *** rmaucher has quit IRC
[00:54:39] <dmlloyd> stuartdouglas, do you happen to know what JBAS-8936 is about?
[00:54:41] <jbossbot> jira [JBAS-8936] @Resource injection from web.xml doesn't work [Open (Unresolved) Bug, Major, Remy Maucherat] https://issues.jboss.org/browse/JBAS-8936
[00:54:53] <dmlloyd> is this something that should be fixed with the componentizing of servlets?
[00:56:25] <stuartdouglas> no, it's about <env-entry> in web.xml
[00:56:43] <dmlloyd> ah okay
[00:56:46] <stuartdouglas> and we don't have any deployment descriptor support for this sort of stuff yet
[00:56:50] <dmlloyd> that's a problem for later :D
[00:57:01] <dmlloyd> well web actually has DD support
[00:57:06] <dmlloyd> but we haven't hooked into it
[00:57:08] <dmlloyd> that's the trouble
[00:57:52] <dmlloyd> carlo is starting on DD support for ejb-jar so presumably we'll be able to reuse some of that...
[00:58:00] <dmlloyd> one would hope...
[00:58:40] <stuartdouglas> are we planning on supporting jsf 1.2?
[00:58:45] <dmlloyd> not that I'm aware of
[00:58:55] <jamezp> dmlloyd: It let me assign this to me https://issues.jboss.org/browse/JBAS-8982
[00:58:57] <jbossbot> jira [JBAS-8982] Rename module "javax.servlet.jstl" to "javax.servlet.jstl.api" for consistency with other javax APIs [Open (Unresolved) Bug, Major, James Perkins] https://issues.jboss.org/browse/JBAS-8982
[00:59:02] <dmlloyd> okay cool
[00:59:09] <jamezp> Thanks BTW.
[01:00:01] <stuartdouglas> hmm, that is going to make the weld TCK interesting, as it relies on jsf 1.2 + facelets a fair bit
[01:00:23] <dmlloyd> heh
[01:00:34] <dmlloyd> can't work with 2.0?
[01:01:32] <stuartdouglas> Maybe, I will have to look into it more, I debugged it and basically if jsf 2.0 sees a 1.2 faces-config it forces JSP, based on the theory that facelets is new in 2.0
[01:01:44] <dmlloyd> heh
[01:01:48] <dmlloyd> nice theory
[01:04:48] <dmlloyd> heh, org.jboss.as.test.embedded.demos.managedbean.ManagedBeanTestCase is frozen
[01:04:57] <dmlloyd> guess that change isn't quite right..
[01:05:31] <stuartdouglas> I will see if I can reproduce
[01:05:41] *** baileyje has quit IRC
[01:05:53] <dmlloyd> second time org.jboss.as.test.embedded.demos.ejb3.jndi.EarDeploymentEjbJndiBindingTestCase freezes
[01:10:26] <jamezp> I just rebased and I got no hangs. Worked perfectly for me.
[01:10:43] <stuartdouglas> this is my transient topic branch
[01:10:44] <dmlloyd> hm
[01:10:54] <stuartdouglas> but I can't reproduce
[01:10:58] <dmlloyd> I simply cherry-picked d4a55f21df358a9051c200d507ca97aa89e1024c
[01:11:06] <dmlloyd> I'll try again with a clean build
[01:11:52] <jamezp> I'm not smart enough to cherry-pick so I just rebased the whole lot.
[01:13:03] <stuartdouglas> I can't help thinking that maybe there is a race condition with the missingDependencies set
[01:14:34] <dmlloyd> hmm all passed this time
[01:14:41] <dmlloyd> failed reliably last time
[01:14:45] <dmlloyd> I must have messed something up
[01:15:36] <dmlloyd> yeah passed again
[01:15:39] <dmlloyd> guess it was a glitch...
[01:15:51] <jbossbot> git [jboss-as] push master 87ec0fd.. Stuart Douglas Fix deployment listener
[01:15:52] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/8eb15ca...87ec0fd
[01:16:00] <dmlloyd> maybe I had a zombie AS running
[01:16:03] * dmlloyd afk for a bit
[01:18:33] *** pferraro has joined #jboss-as7
[01:18:34] *** ChanServ sets mode: +v pferraro
[01:22:31] *** mbg has quit IRC
[01:29:30] *** mbg has joined #jboss-as7
[01:29:31] *** ChanServ sets mode: +v mbg
[01:32:37] *** jamezp has left #jboss-as7
[01:43:53] * dmlloyd back
[01:47:38] *** baileyje has joined #jboss-as7
[01:47:38] *** ChanServ sets mode: +v baileyje
[02:00:27] *** ALR has joined #jboss-as7
[02:00:27] *** ChanServ sets mode: +v ALR
[02:02:20] *** mbg is now known as mbg|away
[02:10:02] *** baileyje has quit IRC
[02:10:20] *** mbg|away is now known as mbg
[02:13:28] *** aslak has quit IRC
[02:17:04] *** mbg has quit IRC
[02:28:48] *** ALR has quit IRC
[02:42:39] *** jamezp has joined #jboss-as7
[02:49:34] *** ALR has joined #jboss-as7
[02:49:34] *** ChanServ sets mode: +v ALR
[02:52:23] *** baileyje has joined #jboss-as7
[02:52:23] *** ChanServ sets mode: +v baileyje
[02:58:25] *** jamezp is now known as jamezp_afk
[03:02:18] *** JimMa has joined #jboss-as7
[03:07:23] <baileyje> emuckenhuber: There?
[03:49:49] *** jpearlin has left #jboss-as7
[03:59:47] *** ALR is now known as ALR|Away
[04:13:40] *** emuckenhuber has quit IRC
[04:26:27] *** emuckenhuber has joined #jboss-as7
[04:26:37] *** emuckenhuber has joined #jboss-as7
[04:26:37] *** ChanServ sets mode: +v emuckenhuber
[04:28:02] *** irooskov has quit IRC
[04:31:06] <jbossbot> git [jboss-as] push master 06c9dd3.. David M. Lloyd Put submodules back in order
[04:31:06] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/87ec0fd...06c9dd3
[04:31:22] *** smarlow has quit IRC
[04:48:10] <baileyje> am I the only one that has ridiculous sporadic test failures with the smoke tests?
[04:48:19] <dmlloyd> yes
[04:48:27] <baileyje> I have for weeks
[04:48:39] <stuartdouglas> even with my change from the morning?
[04:48:58] <baileyje> well, I am in the process or a rebase.  let me see
[04:48:59] <dmlloyd> brian had a lot of sporadic problems; stuartdouglas's change seemed to have fixed it
[04:49:18] <baileyje> which commit?
[04:49:25] <stuartdouglas> http://github.com/jbossas/jboss-as/compare/8eb15ca...87ec0fd
[04:49:44] <baileyje> yeah.  I have that one..
[04:49:53] <dmlloyd> granted I get hangs from time to time
[04:50:06] <dmlloyd> something fishy going on for sure
[04:50:19] <baileyje> strangely it is 100 times worse since that change.  that is the one that just get rebased in.
[04:50:32] <baileyje> Now I fail 4 out of 5.  I used to get like 1 in 10
[04:50:37] <stuartdouglas> Brain did not actually test that version of the fix
[04:51:13] <stuartdouglas> can you go back to before the fix, delete the dependencyUninstalled method, and then see if you have problems?
[04:51:28] <stuartdouglas> or just delete dependencyUninstalled and dependencyInstalled
[04:52:04] <stuartdouglas> The issue is that when services are added before their services are added, dependencyUninstalled was being called, which decreased the count
[04:52:21] <baileyje> I will once I finish this rebase.
[04:52:27] <stuartdouglas> so the handler could return before those services had started
[04:56:29] <dmlloyd> you know I think the hanging problem I see might be caused by the old AS instance not stopping before the new one starts
[04:56:40] <dmlloyd> some kind of conflict maybe
[04:56:50] <stuartdouglas> hmm, I managed to get the hang as well
[04:56:55] <stuartdouglas> thats a first
[04:57:21] <stuartdouglas> actually, no, I have another as running :-)
[04:58:20] <baileyje> Yeah.  I think that is what happens.  So I have been doing a killall prior tot he run
[04:58:49] *** jwulf has quit IRC
[04:58:54] <baileyje> It will hang on part of the aqr based tests
[04:59:17] *** jwulf has joined #jboss-as7
[05:01:28] *** jamezp_afk is now known as jamezp
[05:01:58] <dmlloyd> yeah it's frozen aagain and there's definitely two AS instances running
[05:02:01] <dmlloyd> both created by surefire
[05:02:22] <baileyje> yeah.  I think they are running into eachother somehow
[05:05:04] *** jwulf has quit IRC
[05:05:12] <stuartdouglas> I still can't reproduce it
[05:07:52] <jbossbot> git [jboss-as] push master 2902c00.. David M. Lloyd Remove duplicate artifact
[05:07:52] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/06c9dd3...2902c00
[05:09:14] <baileyje> Yeah.  I am in a state where I can run it through at all.
[05:09:37] <baileyje> fails on some random modular-arquillian
[05:09:44] <stuartdouglas> looks like I just got a hang
[05:10:24] <jamezp> Me too on EarDeploymentEjbJndiBindingTestCase. First one I've gotten today too.
[05:10:37] <dmlloyd> with two java surefire processes running?
[05:10:52] <dmlloyd> I wonder if the forked surefire thing just isn't waiting for the first process to terminate
[05:11:03] <dmlloyd> the API supports it so I don't see why it would not be doing it
[05:11:42] <stuartdouglas> I know the managed container was having trouble shutting down at one point, due to what seemed to be an ARQ issue
[05:12:11] <stuartdouglas> so I added a shutdown handler till the arq issues was fixed
[05:12:31] <stuartdouglas> although I don't think this is the case here
[05:13:14] <stuartdouglas> hmm, in my hang it is waiting for the deployment to finish
[05:13:51] <jamezp> Yeah, definitely 2 processes running for me.
[05:14:23] <dmlloyd> yeah but look at your process table stuartdouglas
[05:14:31] <dmlloyd> maybe it deployed into the wrong process, or something
[05:14:54] <dmlloyd> I noticed that I have no server log at all when the hang happens even though at least one of the two AS processes is fully up and running
[05:15:05] <baileyje> yeah.  Blank log..
[05:20:17] *** asaldhan has left #jboss-as7
[05:22:47] <dmlloyd> ok so I'm heading to bed
[05:22:52] <dmlloyd> I'll leave you guys with this:
[05:23:11] <dmlloyd> http://is.gd/uH4wMl
[05:23:18] <dmlloyd> AS7 issue list
[05:23:22] <dmlloyd> 'night
[05:23:56] <stuartdouglas> night
[05:24:21] <stuartdouglas> baileyje: Is the hang problem the only one you get, or are the tests failing as well
[05:24:22] <stuartdouglas> ?
[05:24:36] <baileyje> just the hang.
[05:24:45] <baileyje> I get two servers running and it hangs
[05:25:38] <stuartdouglas> This is really weird, I also got two servers and a hang, but half way through the test
[05:25:57] <stuartdouglas> also it looks like both services are running the same set of tests
[05:29:31] <stuartdouglas> so this is what my process table looks like: http://pastie.org/pastes/1681337/text
[05:29:51] <stuartdouglas> two servers with the same arguments, one started from the shell
[05:30:23] <stuartdouglas> or something like that, not exactly sure
[05:36:19] *** miclorb has quit IRC
[05:37:34] <stuartdouglas> this is weird, it looks like one of the AS instances is spawning the other AS instance
[05:38:35] *** jwulf has joined #jboss-as7
[05:54:51] *** jamezp has quit IRC
[06:04:56] *** ALR|Away has quit IRC
[06:05:25] *** pferraro has quit IRC
[06:06:38] <baileyje> dmlloyd: Still up:  https://github.com/baileyje/jboss-as/commit/8ff1577180e6b0221e64fcf1426ae1a0c0634173
[06:06:39] <jbossbot> git [jboss-as] 8ff1577.. John E. Bailey Datasource subsystem cleanup.  Deploy datasources using opeartions
[06:15:56] *** miclorb_ has joined #jboss-as7
[06:27:13] *** ALR has joined #jboss-as7
[06:27:13] *** ChanServ sets mode: +v ALR
[06:27:28] *** ALR has quit IRC
[07:40:41] *** Heiko has quit IRC
[08:01:10] *** opalka has joined #jboss-as7
[08:01:10] *** ChanServ sets mode: +v opalka
[08:01:32] <opalka> morning
[08:06:24] *** Jaikiran has joined #jboss-as7
[08:06:24] *** ChanServ sets mode: +v Jaikiran
[08:11:56] *** jwulf has quit IRC
[08:21:32] *** jfclere has joined #jboss-as7
[08:21:36] *** ChanServ sets mode: +v jfclere
[08:33:17] *** adietisheim has joined #jboss-as7
[08:40:46] *** tdiesler has joined #jboss-as7
[08:40:46] *** ChanServ sets mode: +v tdiesler
[08:44:45] <nickarls> morning, O fellow-of-unconvenient-timezones
[08:46:58] *** irooskov has joined #jboss-as7
[08:50:47] <Jaikiran> good morning :)
[08:56:20] *** rmaucher has joined #jboss-as7
[09:10:07] <opalka> Jaikiran, What's the equivalent of JBossMetaData in AS6 in AS7?
[09:10:32] <opalka> Jaikiran, there used to be JBossMetaData attached to DU in AS6
[09:10:33] <Jaikiran> opalka: EJBComponentDescription for now
[09:10:39] <Jaikiran> oh that's not yet ready
[09:10:47] <Jaikiran> it's not the same in AS7
[09:10:56] <Jaikiran> we won't be using JBMETA going forward
[09:11:09] <Jaikiran> what are you looking at?
[09:11:12] <opalka> Jaikiran, and what we'll be using?
[09:11:27] <Jaikiran> opalka: depends on where you need it and why
[09:11:37] <opalka> Jaikiran, I need MD from jboss.xml
[09:11:50] <opalka> Jaikiran, if it's going to be present in AS7 (I believe so)
[09:11:52] <Jaikiran> opalka: we haven't yet decided anything about jboss.xml
[09:11:59] <opalka> Jaikiran, aha
[09:12:07] <rmaucher> well, personally, I remain happy about JBMETA ...
[09:12:08] <opalka> Jaikiran, from TCK PoV it's needed
[09:12:11] <Jaikiran> at present there is no support for DD (including jboss.xml) in AS7 for EJbs
[09:12:18] <Jaikiran> rmaucher: :)
[09:12:29] <opalka> rmaucher, ;)
[09:12:48] <opalka> Jaikiran, right, I forgot there's no support for DDs in AS7 yet
[09:12:49] <Jaikiran> opalka: not really. the TCK pieces allow you to customize the deployments for any vendor specific DDs
[09:12:52] *** epbernard has joined #jboss-as7
[09:12:52] *** epbernard is now known as emmanuel
[09:12:52] *** ChanServ sets mode: +v emmanuel
[09:12:56] <Jaikiran> we may or may not use them in AS7
[09:13:08] <opalka> Jaikiran, I don't understand what U mean?
[09:13:22] <Jaikiran> opalka: i mean, jboss.xml isn't mandatory in TCK
[09:13:27] <opalka> Jaikiran, In order to pass TCK6 we needed to provide some extra information in jboss.xml to define different mappings
[09:13:38] <opalka> Jaikiran, Believe me for JBossWS it is :(
[09:13:47] <Jaikiran> we need to provide extra info sure
[09:14:06] <Jaikiran> but i don't know whether we will continue with jboss.xml or some other way :)
[09:14:31] <opalka> Jaikiran, frankly I don't care what the way we'll go, I just need some form of customization of deployments ;)
[09:14:40] <Jaikiran> yep, that should be possible
[09:14:43] *** ALR has joined #jboss-as7
[09:14:43] *** ChanServ sets mode: +v ALR
[09:14:57] <Jaikiran> i haven't yet got a chance to discuss this with wolfc or dmlloyd and when it is scheduled
[09:15:04] <opalka> Jaikiran, anyway thanks for remaining me DDs are not supported yet
[09:15:54] <Jaikiran> that's the only thing I'm sure about Beta1 :)  i don't exactly know what EJB3 functionality is fully working :)
[09:16:27] <opalka> Jaikiran, LOL
[09:16:30] <Jaikiran> or for that matter what Java EE and domain functionalities are shipped in Beta1
[09:16:34] <Jaikiran> from a user p.o.v
[09:16:46] <Jaikiran> waiting for Jason to send out the announcement when he's back
[09:17:00] <opalka> Jaikiran, OK, I have EJB3 related question 4 U
[09:17:04] <Jaikiran> sure
[09:17:15] <opalka> Jaikiran, ther used to be
[09:17:29] *** irooskov has quit IRC
[09:17:38] * opalka 's searching sources ...
[09:18:19] * opalka found it
[09:18:29] <opalka> Jaikiran, there used to be ejbMetaData.determineContainerName() in AS6
[09:18:39] <Jaikiran> opalka: won't function in AS7
[09:18:43] <opalka> Jaikiran, How/where I can find equivalent piece of info in AS7?
[09:18:55] <Jaikiran> AS7 is completely based off ServiceNames
[09:19:16] <opalka> Jaikiran, Yes I know. I'm looking for different way that will work
[09:19:18] <Jaikiran> each component (for example, an EJB component or container) has its own ServiceName
[09:19:34] <opalka> Jaikiran, where this service name is created?
[09:19:50] <Jaikiran> @see ComponentInstallProcessor and search for startServiceName
[09:19:53] <Jaikiran> opalka: ^
[09:20:16] * opalka 's having a look
[09:20:21] *** jwulf has joined #jboss-as7
[09:22:52] *** emuckenhuber has quit IRC
[09:22:57] <opalka> Jaikiran, OK, thx for info ;)
[09:23:03] <opalka> Jaikiran, that's all for now ;)
[09:23:07] <Jaikiran> you're welcome
[09:25:46] <opalka> Jaikiran, I just passed first JBossWS EJB3 integration test ;)
[09:26:03] <Jaikiran> excellent! i got an EJB3 test passing too (finally) :)
[09:26:11] <opalka> Jaikiran, LOL
[09:27:56] * opalka can't believe it was that easy ?
[09:28:18] <opalka> Jaikiran, OK, I need to debug the test if I'm not having hallucination ;)
[09:28:27] <Jaikiran> ha ha
[09:31:05] <opalka> Jaikiran, ha ha
[09:31:10] <opalka> Jaikiran, I was lucky choosing the test
[09:31:24] <opalka> Jaikiran, The test is just checking if EJB3 JBossWS handler is called
[09:32:02] * opalka need to code EJB3 invocation process
[09:32:21] *** torben has joined #jboss-as7
[09:32:21] *** torben has joined #jboss-as7
[09:32:21] *** ChanServ sets mode: +v torben
[09:39:53] *** pil-afk is now known as pilhuhn
[09:53:39] <opalka> Jaikiran, OK, in order to same me some time
[09:53:45] <opalka> Jaikiran, we used to do this in AS6 - http://fpaste.org/T4ZT/
[09:54:00] <opalka> Jaikiran, what is the equivalent of ServiceEndpointContainer?
[09:54:11] <opalka> Jaikiran, SessionBeanComponent ?
[09:54:22] *** emuckenhuber has joined #jboss-as7
[09:54:22] *** emuckenhuber has joined #jboss-as7
[09:54:22] *** ChanServ sets mode: +v emuckenhuber
[09:54:34] <Jaikiran> opalka: yes, although it's not yet aligned to that ServiceEndpointContainer SPI
[09:55:03] <opalka> Jaikiran, and how should I get EJB3 instance from it & invoke the method upon it?
[09:58:08] <Jaikiran> well you wouldn't be getting the EJB3 instance
[09:58:18] <Jaikiran> you would let the component do it for you
[09:58:33] <opalka> Jaikiran, OK, I need to invoke some method upon it, how?
[09:58:40] * Jaikiran is checking the APIs
[10:06:49] <Jaikiran> opalka: the closest i see is AbstractComponent.getComponentView(wsView).methodToInvoke();
[10:07:14] <Jaikiran> i might be wrong though, i need to dig in a bit deeper to see if there's anything else
[10:11:04] <opalka> Jaikiran, I don't see such method there :(
[10:11:22] <opalka>     public Map<Class<?>, ServiceName> getViewServices() {
[10:11:22] <opalka>         return Collections.unmodifiableMap(viewServices);
[10:11:22] <opalka>     }
[10:11:32] <Jaikiran> opalka: line 400 on AbstractComponent
[10:11:54] <opalka> Jaikiran, org.jboss.as.ee.component.AbstractComponent ?
[10:12:00] <Jaikiran> yes
[10:12:26] <opalka> Jaikiran, I have one day old distribution, maybe it changed ...
[10:12:34] <Jaikiran> i don't think so
[10:12:36] <Jaikiran> one sec
[10:13:51] <opalka> Jaikiran, yes, it changed ;)
[10:13:58] * opalka needs to update his master ...
[10:14:08] <Jaikiran> interesting :)
[10:14:18] <Jaikiran> oh yeah, looks like carlo added it just recently
[10:40:38] *** bgeorges has joined #jboss-as7
[10:57:43] *** Jaikiran is now known as Jaikiran|AFK
[10:59:10] *** hbraun has joined #jboss-as7
[11:24:29] *** stalep has joined #jboss-as7
[11:25:06] *** JimMa has quit IRC
[11:31:39] *** Jaikiran|AFK is now known as Jaikiran
[11:36:40] *** bgeorges has quit IRC
[11:41:47] <opalka> Jaikiran, I have this
[11:41:54] <opalka> Jaikiran, IfaceA
[11:42:15] <opalka> Jaikiran, @Stateless @WebService ImplB implements IfaceA
[11:42:32] <Jaikiran> ok
[11:42:32] <opalka> Jaikiran, U're saying I have to call
[11:42:41] <opalka>          final StatelessSessionComponent ejbContainer = this.getEjb3Container();
[11:42:41] <opalka>          final ComponentView ejb3View = ejbContainer.getComponentView(IfaceA.class);
[11:42:45] <opalka> Jaikiran, ?
[11:43:00] <Jaikiran> let me check what the spec says for a webservice view
[11:43:31] <opalka> Jaikiran, There can be EJB3s without interface they implements, right?
[11:43:38] <Jaikiran> yep
[11:43:42] <Jaikiran> no-interface view beans
[11:43:45] <opalka> Jaikiran, for me it would be more convenient to pass ImplB.class
[11:43:55] <Jaikiran> that won't always work
[11:44:04] <Jaikiran> infact, from a WS point of view, i am not sure what view is exposed
[11:44:07] <Jaikiran> let me see the spec
[11:45:28] <Jaikiran> hmm it isn't a typical EJB3 view
[11:45:52] <Jaikiran> so that getComponentView isn't appropriate in this case
[11:46:33] *** jcosta has joined #jboss-as7
[11:46:39] *** ChanServ sets mode: +v jcosta
[11:47:23] <opalka> Jaikiran, OK, any further suggestions how to proceed here?
[11:47:37] <opalka> Jaikiran, I need to get the EJB3 instance on which I can call methods via reflection
[11:48:04] <Jaikiran> opalka: i think we'll have to wait for dmlloyd. i haven't looked deep into the current component infrastructure
[11:48:05] <hbraun> emuckenhuber: ping
[11:48:18] <hbraun> emuckenhuber: quick question
[11:48:25] <emuckenhuber> sure
[11:48:28] <opalka> Jaikiran, OK, I'll study the code base in the meantime
[11:48:55] <opalka> dmlloyd, once U pop up, please see our above conversation with Jaikiran ^^^^
[11:49:14] *** alesj has joined #jboss-as7
[11:49:45] <hbraun> emuckenhuber: is there a way to distinguish node's that have subresources, i.e. /profile=default/* opposed to /interface=external
[11:49:46] <hbraun> ?
[11:50:02] <hbraun> emuckenhuber: maybe subresources is a misleading term
[11:52:29] <emuckenhuber> hbraun: hmm, there is a "read-children-types" operation
[11:53:00] <hbraun> right, that looks like what I need
[11:53:19] <hbraun> tnx
[11:53:44] <emuckenhuber> this basically queries our internal registration for "subresources"
[11:59:01] *** emmanuel has quit IRC
[12:01:00] *** rmaucher has quit IRC
[12:04:19] *** wolfc has joined #jboss-as7
[12:04:19] *** ChanServ sets mode: +v wolfc
[12:06:57] *** aslak has joined #jboss-as7
[12:06:57] *** aslak has joined #jboss-as7
[12:06:57] *** ChanServ sets mode: +v aslak
[12:14:05] *** smarlow has joined #jboss-as7
[12:14:05] *** ChanServ sets mode: +v smarlow
[12:16:44] *** darranl has joined #jboss-as7
[12:16:44] *** darranl has joined #jboss-as7
[12:16:44] *** ChanServ sets mode: +v darranl
[12:17:05] *** epbernard has joined #jboss-as7
[12:17:05] *** ChanServ sets mode: +v epbernard
[12:17:05] *** epbernard is now known as emmanuel
[12:22:50] *** emmanuel has quit IRC
[12:36:42] *** hbraun has quit IRC
[12:41:16] <pilhuhn> emuckenhuber Hi, for the json api output - is there a ?xxx to say "pretty-print" ?
[12:42:02] <pilhuhn> I.e. "don't remove spaces and newlines from the JSON "
[12:42:04] *** miclorb_ has quit IRC
[12:50:01] *** torben has quit IRC
[12:52:52] <emuckenhuber> pilhuhn: http://localhost:9990/domain-api/?json.pretty=true
[12:53:52] <pilhuhn> ah - thanks -- I have seen it before , but obviously remembered the wrong term
[12:56:06] *** balunasj has joined #jboss-as7
[12:56:06] *** balunasj has joined #jboss-as7
[12:56:06] *** ChanServ sets mode: +v balunasj
[13:09:01] *** jhalliday has joined #jboss-as7
[13:25:19] <wolfc> stuartdouglas, are you still awake by chance?
[13:26:00] *** nickboldt has quit IRC
[13:26:11] *** jwulf has quit IRC
[13:26:17] <wolfc> getting "IllegalStateException: Context is already active" when trying https://github.com/wolfc/jboss-as/commits/weld
[13:26:31] *** epbernard has joined #jboss-as7
[13:26:40] *** ChanServ sets mode: +v epbernard
[13:36:05] *** mmoyses has joined #jboss-as7
[13:36:05] *** ChanServ sets mode: +v mmoyses
[13:50:31] *** jpederse has joined #jboss-as7
[13:56:15] *** pgier has joined #jboss-as7
[13:56:15] *** ChanServ sets mode: +v pgier
[13:59:14] *** jpederse has quit IRC
[13:59:44] *** jpederse has joined #jboss-as7
[14:04:22] *** jpederse has quit IRC
[14:04:22] *** jpederse has joined #jboss-as7
[14:06:14] *** ALR has quit IRC
[14:06:58] *** nickboldt has joined #jboss-as7
[14:06:58] *** ChanServ sets mode: +v nickboldt
[14:07:18] *** nickboldt has quit IRC
[14:07:24] *** nickboldt has joined #jboss-as7
[14:07:24] *** ChanServ sets mode: +v nickboldt
[14:08:41] *** bgeorges has joined #jboss-as7
[14:08:48] *** pferraro has joined #jboss-as7
[14:08:48] *** ChanServ sets mode: +v pferraro
[14:09:47] <smarlow> <wolfc>	right now we have no ComponentInstance lifecycle callbacks on system interceptors
[14:09:53] <smarlow> wolfc:  has ^ changed yet?
[14:10:06] <wolfc> no
[14:10:46] *** hbraun has joined #jboss-as7
[14:11:13] <Jaikiran> dmlloyd: could you pull in this fix in jboss-invocation https://github.com/jaikiran/jboss-invocation/commit/ad955a0ef86c276c9a09f4a8288c82d44cae8b88
[14:11:14] <jbossbot> git [jboss-invocation] ad955a0.. jaikiran JBAS-9033 InvocationContext.getContextData() should return an empty map (instead of null) in the absence of context data
[14:11:15] <jbossbot> jira [JBAS-9033] InvocationContext.getContextData() returns null when used in a interceptor [Open (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/JBAS-9033
[14:11:46] *** nickboldt1 has joined #jboss-as7
[14:11:46] *** ChanServ sets mode: +v nickboldt1
[14:11:55] *** nickboldt has quit IRC
[14:14:01] *** fnasser has joined #jboss-as7
[14:14:01] *** ChanServ sets mode: +v fnasser
[14:14:09] <wolfc> Jaikiran, it looks like a different type of problem
[14:14:19] <Jaikiran> wolfc: which one?
[14:14:26] <wolfc> JBAS-9033
[14:14:27] <jbossbot> jira [JBAS-9033] InvocationContext.getContextData() returns null when used in a interceptor [Open (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/JBAS-9033
[14:15:15] <wolfc> The contextData must be set before being used.
[14:15:24] <wolfc> via setContextData
[14:15:47] <Jaikiran> do we switch the context data while passing it along to user interceptors?
[14:16:05] <Jaikiran> we == the AS component layer
[14:21:53] <wolfc> Jaikiran, for a WS call the context data is different. In essence it depends on the view invoked.
[14:22:24] <wolfc> It's probably best to fill it via a client interceptor for now.
[14:25:54] *** pferraro has left #jboss-as7
[14:26:39] *** jfd has joined #jboss-as7
[14:26:41] *** jfd has quit IRC
[14:26:41] *** jfd has joined #jboss-as7
[14:26:41] *** ChanServ sets mode: +v jfd
[14:30:45] *** rmaucher has joined #jboss-as7
[14:33:06] *** hbraun has quit IRC
[14:34:25] * Jaikiran is back
[14:35:04] <Jaikiran> wolfc: talking of WS, opalka had some questions on passing on a WS invocation to a SLSB endpoint
[14:35:05] *** epbernard is now known as emmanuel
[14:38:33] <opalka> wolfc, Jaikiran Good news using some fugly hacks I'm passing first EJB3 WS integration tests
[14:38:42] <opalka> wolfc, Jaikiran I need to know how to do it right
[14:39:01] <opalka> wolfc, Jaikiran my usecases need to on the beginning the following usecases
[14:39:49] <opalka>  * EJB3 beans with no interface view
[14:39:57] <opalka>  * EJB3 beans with iface view
[14:40:22] <opalka> wolfc, Jaikiran I need to know how to properly lookup EJB3 bean and how to invoke methods upon it (covering both aforementioned usecases)
[14:40:33] <opalka> dmlloyd, ^^^ might help here too ;)
[14:41:47] *** asaldhan has joined #jboss-as7
[14:41:47] <wolfc> opalka, what's wrong with a lookup of the java:global name?
[14:41:47] *** ChanServ sets mode: +v asaldhan
[14:42:13] <wolfc> hmm, you wouldn't be able to pass the contextData.
[14:42:22] <opalka> wolfc, for example
[14:42:36] <opalka> wolfc, there were also some callbacks from EJB3 to WS we used to support
[14:47:40] <dmlloyd> Jaikiran: I get conflicts with that patch, somehow
[14:47:51] <Jaikiran> dmlloyd: the invocation one?
[14:48:16] <dmlloyd> yeah
[14:48:23] <dmlloyd> can't even cherry-pick it
[14:48:27] <Jaikiran> hmm strange
[14:48:40] <Jaikiran> it's a pretty simple commit with a recently clone repo
[14:48:43] <dmlloyd> hmmm
[14:48:47] <dmlloyd> something is very wrong here
[14:48:58] <dmlloyd> apparently we're divergent
[14:49:09] <dmlloyd> both jason and I have released beta3 apparently
[14:50:42] <dmlloyd> somehow history got rewound to february 16
[14:50:46] <dmlloyd> and then released from that
[14:50:57] <dmlloyd> all the commits since then aren't upstream anymore...
[14:51:52] <dmlloyd> ah, I got it sorted
[14:51:53] <dmlloyd> whew
[14:52:36] <Jaikiran> :)
[14:52:44] <jbossbot> git [jboss-invocation] push master ad955a0.. jaikiran JBAS-9033 InvocationContext.getContextData() should return an empty map (instead of null) in the absence of context data
[14:52:46] <jbossbot> jira [JBAS-9033] InvocationContext.getContextData() returns null when used in a interceptor [Open (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/JBAS-9033
[14:52:46] <dmlloyd> pushed
[14:52:46] <jbossbot> git [jboss-invocation] push master URL: http://github.com/jbossas/jboss-invocation/compare/095d6c0...ad955a0
[14:52:49] <opalka> wolfc, dmlloyd We also used to pass org.jboss.wsf.spi.invocation.integration.InvocationContextCallback to EJB3 so EJB can lookup things like WebServiceContext etc.
[14:53:11] <wolfc> that has to change
[14:53:19] <opalka> wolfc, agreed
[14:53:50] <wolfc> basically the injection framework will inject an instance WebServiceContext, how you associate with the invocation is your problem :-)
[14:54:05] <dmlloyd> it seems to be that WS will be invoking EJB much in the same way that remote will, by using a ComponentInvocationHandler
[14:54:08] <opalka> wolfc, WebServiceContext isn't problem at all
[14:54:21] <opalka> dmlloyd, listening ...
[14:54:35] * opalka 's opeing ComponentInvocationContext class in IDE ...
[14:54:36] <dmlloyd> baecause you're basically creating invocations and sending them in without a method call, right?
[14:55:22] <opalka> dmlloyd, well our usecase is
[14:55:39] <opalka> dmlloyd, we un/marshall XML data to Java objects, prepare arguments and identify method to be invoked
[14:55:59] <opalka> dmlloyd, then lookuping appropriate method on EJB and finally invoking it
[14:56:26] <opalka> dmlloyd, U probably meant ComponentInvocationHandler
[14:56:41] <dmlloyd> yeah that's very similar to how network invocation will happen for remote EJBs
[14:56:47] <dmlloyd> isn't that what I said?
[14:56:51] <wolfc> :-)
[14:57:01] <opalka> dmlloyd, I think it is.
[14:57:04] <wolfc> but you would also need to have the contextData pass over
[14:57:26] <opalka> wolfc, what U mean with contextData? EJB3Context
[14:57:47] <dmlloyd> yeah this is true - there are no client interceptors on CIH
[14:58:12] * opalka 's wondering what CIH is - maybe ComponentInvocationHandler?
[14:58:20] <dmlloyd> yeah
[14:58:27] <dmlloyd> I've already gotten tired of typing it out :)
[14:58:40] <wolfc> EJB 3.1 FR 12.6 footnote 32: If interceptors are invoked as a result of the invocation on a web service endpoint, the map returned by getContextData will be the JAX-WS MessageContext [32].
[14:58:59] <opalka> wolfc, yes
[14:59:03] <asaldhan> dmlloyd: minor change to .gitignore please pull  https://github.com/anilsaldhana/jboss-as/commit/3db2d7a14bd174fab8f556a9599ce2fd1d590dbe
[14:59:03] <jbossbot> git [jboss-as] 3db2d7a.. Anil Saldhana change .gitignore
[14:59:40] *** balunasj is now known as balunasj_mtg
[14:59:56] <opalka> dmlloyd, so what is the suggested way of WS EJB3 integration? Providing JBossWS CIH or what?
[15:00:05] * opalka 's still not familiar with AS7 architecture
[15:00:36] *** bstans_afk is now known as bstansberry
[15:02:41] <dmlloyd> opalka: maybe direct invocation of an Interceptor makes more sense
[15:02:43] *** torben has joined #jboss-as7
[15:02:43] *** torben has joined #jboss-as7
[15:02:43] *** ChanServ sets mode: +v torben
[15:03:22] <jbossbot> git [jboss-as] push master 3db2d7a.. Anil Saldhana change .gitignore
[15:03:22] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/2902c00...3db2d7a
[15:04:06] <Jaikiran> dmlloyd: btw, here are few AS7 commits https://github.com/jaikiran/jboss-as/commits/ejb3
[15:05:32] *** hbraun has joined #jboss-as7
[15:05:40] <dmlloyd> ok testing now
[15:05:44] <dmlloyd> hopefully the tests won't hang on me
[15:06:16] <smarlow> stuartdouglas:  I noticed your changes to JPAAnnotationParseProcessor.  I'm not completely following your suggestion about "iterate over components looking for annotations, not the other way around". Are we missing something when we iterate through the COMPOSITE_ANNOTATION_INDEX attached to the DU?  Or causing complications for CDI perhaps?
[15:06:50] <smarlow> stuartdouglas:  no rush to discuss, whenever your around is fine.
[15:07:31] <opalka> dmlloyd, with Interceptor U mean org.jboss.ejb3.metamodel.Interceptor ?
[15:07:49] <dmlloyd> no I mean org.jboss.invocation.Interceptor
[15:08:41] * smarlow reading through recent history to see what we are supposed to be doing to implement SFSB interceptors for XPC support...
[15:09:03] *** frainone has joined #jboss-as7
[15:09:03] *** ChanServ sets mode: +v frainone
[15:09:20] <dmlloyd> maybe what I'll do is change ComponentInvocationHandler to not implement InvocationHandler anymore and instead provide a method to get an entry point Interceptor for a Method
[15:09:30] <dmlloyd> that way the caller can provide an invocation context
[15:09:37] <dmlloyd> that'd fit the remoting case better too
[15:09:41] <dmlloyd> Jaikiran: what do you think of that idea
[15:09:58] <opalka> wolfc, org.jboss.invocation.InterceptorContext field private Map<String, Object> contextData; is intended to be used for - EJB 3.1 FR 12.6 footnote 32: If interceptors are invoked as a result of the invocation on a web service endpoint, the map returned by getContextData will be the JAX-WS MessageContext [32].
[15:10:34] <wolfc> right, so depending on the way we invoke it is filled up. It should not be filled by default.
[15:10:37] <wolfc> Jaikiran, ^
[15:10:58] <Jaikiran> aha!
[15:12:01] <wolfc> So instead of https://github.com/jaikiran/jboss-invocation/commit/ad955a0ef86c276c9a09f4a8288c82d44cae8b88
[15:12:01] <jbossbot> git [jboss-invocation] ad955a0.. jaikiran JBAS-9033 InvocationContext.getContextData() should return an empty map (instead of null) in the absence of context data
[15:12:03] <jbossbot> jira [JBAS-9033] InvocationContext.getContextData() returns null when used in a interceptor [Open (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/JBAS-9033
[15:12:15] <wolfc> getContextData() should throw IllegalStateException if null
[15:14:24] <opalka> dmlloyd, that idea of providing a method to get an entry point Interceptor for a Method sounds like it should simplify our integration problems
[15:15:51] <opalka> dmlloyd, and I'll use this method
[15:15:52] <opalka>     public ComponentInvocationHandler createClient(final Class<?> viewClass) {
[15:15:52] <opalka>         // todo for remote inv.
[15:15:53] <opalka>         return null;
[15:15:53] <opalka>     }
[15:15:58] *** pilhuhn is now known as pil-afk-biab
[15:16:03] <opalka> dmlloyd, for providing custom IH, right?
[15:16:52] <opalka> dmlloyd, this is the method of org.jboss.as.ee.component.AbstractComponent
[15:18:35] <opalka> dmlloyd, I will just need an reference on StatelessSessionComponent and will operate upon it, did I get it right?
[15:19:11] <dmlloyd> yeah that's the theory anyway
[15:20:24] <dmlloyd> let me whip something up...
[15:20:27] <Jaikiran> wolfc: i don't think throwing a IISE from that getContextData() is correct
[15:20:37] <Jaikiran> it clearly contradicts the javadoc
[15:20:45] <wolfc> InterceptorContext != InvocationContext
[15:20:56] <wolfc> And besides you are not supposed to return null :-)
[15:21:12] <Jaikiran> oh so you are talking about interceptorContext.getContextData()?
[15:21:19] <opalka> dmlloyd, ok ;)
[15:21:53] <jbossbot> git [jboss-as] push master c248858.. jaikiran Include @EJB annotation processing for super classes
[15:21:53] <jbossbot> git [jboss-as] push master ba6b0f8.. jaikiran Better error reporting during resource injection
[15:21:53] <jbossbot> git [jboss-as] push master 4ac60c9.. jaikiran JBAS-9031 Allow injection to take place on field/method of super class(es) of components
[15:21:54] <jbossbot> jira [JBAS-9031] @EJB injection on a field/method in a Servlet/Filter class' superclass doesn't work [Open (Unresolved) Bug, Major, jaikiran pai] https://issues.jboss.org/browse/JBAS-9031
[15:21:54] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/3db2d7a...4ac60c9
[15:22:01] <Jaikiran> dmlloyd: thanks!
[15:23:43] <Jaikiran> dmlloyd: wolfc: what are the goals for Beta2?
[15:23:51] <Jaikiran> and when is Beta2?
[15:23:53] <wolfc> as much as possible :-)
[15:24:08] <dmlloyd> beta2 is on Apr1
[15:24:12] <dmlloyd> JIRA has the tasks
[15:24:14] <Jaikiran> well, right now i'm working the other way - looking at tck and then fixing the code
[15:24:16] <dmlloyd> MDB is the big one
[15:24:22] * Jaikiran checks JIRA
[15:24:30] <wolfc> I've started on the annotation processor
[15:24:40] <dmlloyd> DD parsing is the other
[15:24:42] <Jaikiran> of MDB?
[15:25:37] <Jaikiran> dmlloyd: oh btw, just remembered this one https://issues.jboss.org/browse/JBAS-9032
[15:25:38] <jbossbot> jira [JBAS-9032] @EJB injection with same "name" on two different fields leads to DuplicateServiceException [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9032
[15:26:36] <dmlloyd> ok I set its fix-for to Beta2
[15:26:39] <wolfc> Do we have for each injection multiple injection targets?
[15:26:48] <dmlloyd> yeah
[15:27:02] <dmlloyd> that's probably what we should use eh
[15:27:25] <dmlloyd> we may not have a good way to look up existing injections to detect a duplicate though
[15:27:38] <dmlloyd> to reuse an existing BindingDescription I mean
[15:27:49] *** smcgowan has joined #jboss-as7
[15:27:50] *** ChanServ sets mode: +v smcgowan
[15:27:54] <smarlow> dmlloyd, wolfc:  are we going to have lifecycle callbacks?
[15:28:01] <smarlow> for beta2?
[15:28:09] <dmlloyd> ah I didn't open a JIRA for that...
[15:28:45] *** Jaikiran is now known as Jaikiran|brb
[15:36:14] <opalka> dmlloyd, when can I expect your suggestion to be available upstream? (maybe what I'll do is change ComponentInvocationHandler to not implement InvocationHandler anymore and instead provide a method to get an entry point Interceptor for a Method)
[15:36:36] <dmlloyd> in an hour or two I guess?
[15:36:47] <opalka> dmlloyd, cool
[15:37:30] *** bgeorges has quit IRC
[15:38:04] <baileyje> dmlloyd, bstansberry: Could one of you review this:  https://github.com/baileyje/jboss-as/commit/784369be44c2b46004ec7eb9a938102a27660c09
[15:38:04] <jbossbot> git [jboss-as] 784369b.. John E. Bailey Datasource subsystem cleanup.  Deploy datasources using opeartions
[15:38:13] <bstansberry> sure
[15:38:24] <dmlloyd> ah sorry about that baileyje, I got distracted
[15:38:30] <dmlloyd> too many shiny objects around here
[15:38:41] <baileyje> No problem.  I just rebased it.
[15:39:12] <bstansberry> btw, ParseAndMarshalModelsTestCase is going to bite the dust sometime
[15:39:23] <bstansberry> i.e. next time anyone has to hack it
[15:39:32] <baileyje> hehe..
[15:39:45] <bstansberry> it's unfortunately fragile
[15:40:14] <bstansberry> the goal is important, but not easy to achieve
[15:40:48] *** pil-afk-biab is now known as pilhuhn
[15:41:24] <baileyje> bstansberry: It did catch me incorrectly deparsing some things.  So it is pretty usefull.
[15:41:44] <bstansberry> yeah, that's why I didn't kill it already :)
[15:43:15] <bstansberry> I suppose I could be anal and require that all subsystems cleanly round-trip anything they put in a standard config
[15:43:18] *** opalka has quit IRC
[15:43:49] <bstansberry> and remove all hacks from the testcase
[15:44:24] <smarlow> dmlloyd, wolfc:  JBAS-9035 is for the interceptors needed for JPA.  If someone still wants to create stub implementations, I would appreciate that.  Or I could dive in otherwise.  :)
[15:44:25] <jbossbot> jira [JBAS-9035] JPA needs a SFSB lifecycle callback and a SFSB invocation interceptor [Open (Unresolved) Sub-task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9035
[15:44:52] *** frainone has quit IRC
[15:47:48] <bstansberry> baileyje: in Constants.java:   static final String XA_DATA_SOURCE = "xa-adata-source";
[15:47:51] <bstansberry> typo
[15:48:21] <baileyje> bstansberry: Ok.  One sec.  Let me fix and repush
[15:48:51] <bstansberry> better wait until I get done :-)
[15:48:58] <bstansberry> before repushing
[15:49:49] <baileyje> sounds good
[15:51:43] <bstansberry> baileyje:  DataSourceDisable, I don't think it invokes on the ResultHandler (or throws OFE) in all branches
[15:51:52] *** AndyTaylor has joined #jboss-as7
[15:51:52] *** ChanServ sets mode: +v AndyTaylor
[15:52:04] <baileyje> bstansberry: Ok. Let me dig
[15:52:11] <bstansberry> i.e. dataSourceController != null but ServerControllerState != UP
[15:53:15] <baileyje> right.  Just saw that..
[15:53:32] <dmlloyd> Jaikiran|brb, opalka, baileyje would you mind reviewing: http://github.com/dmlloyd/jboss-as/commit/03be279
[15:53:33] <jbossbot> git [jboss-as] 03be279.. David M. Lloyd Add proper client entry point support
[15:53:55] <dmlloyd> it was easier than I thought
[15:54:03] <bstansberry> same with DataSourceEnable
[15:54:19] <dmlloyd> oops, one more delete to make...
[15:54:30] <baileyje> yeah.  I assumed and started working over there too
[15:54:54] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/0e23f0c
[15:54:55] <jbossbot> git [jboss-as] 0e23f0c.. David M. Lloyd Add proper client entry point support
[15:55:11] *** Jaikiran|brb is now known as Jaikiran
[15:55:34] <Jaikiran> dmlloyd: the one thing i'm not sure about WS is what viewClass it's going to pass for that entry point. maybe opalka knows better
[15:55:51] <dmlloyd> yeah that's a little interesting...
[15:56:03] <Jaikiran> from what i see in the spec, it really doesn't show any EJB view semantics while invoking SLSB as a WS endpoint
[15:56:07] <dmlloyd> for remoting it's a bit more obvious
[15:56:23] <Jaikiran> remoting itself can have multiple views
[15:56:34] <dmlloyd> yeah but they're just regular views
[15:56:40] <Jaikiran> yep
[15:57:20] <dmlloyd> so we might also need another "createRawClient" or something which creates a sort of no-interface view
[15:57:29] <dmlloyd> do the system interceptors work differently for WS?
[15:57:37] *** frainone has joined #jboss-as7
[15:57:37] *** ChanServ sets mode: +v frainone
[15:57:45] <Jaikiran> no, it's the same. all system interceptors should apply
[16:01:36] <bstansberry> baileyje: I don't think DataSourceExtension createEmptyAddSubsystemOperation is right
[16:02:12] <bstansberry> well, the DataSourcesSubsystemDescribeHandler needs to be different in general
[16:02:45] <bstansberry> that's an op that's invoked on the DomainController when a host needs to create the server-level ops to start a server
[16:03:09] <bstansberry> so it's response is basically the set of operations that would recreate the given model
[16:03:52] <bstansberry> so now it would reply with a DataSourceSubsystemAdd plus the relevant DataSourceAdd(s) and JdbcDriverAdd(s)
[16:05:28] *** mbg has joined #jboss-as7
[16:05:28] *** ChanServ sets mode: +v mbg
[16:05:31] *** smcgowan has quit IRC
[16:05:46] *** mbg has quit IRC
[16:05:47] *** mbg has joined #jboss-as7
[16:05:47] *** verne.freenode.net sets mode: +v mbg
[16:07:03] <baileyje> bstansberry: Do you have a good example I could look at..  I was just crashing through this.
[16:07:15] <baileyje> The description part that is/
[16:07:23] <bstansberry> probably web subsystem
[16:07:45] <baileyje> Ok.  I  will take a look there
[16:07:58] <bstansberry> emuckenhuber wrote that and he came up with the whole concept, so he should have done it right ;)
[16:09:19] <baileyje> Is WebSubsystemDescribe the one?
[16:10:05] <Jaikiran> dmlloyd: now that you are here, what are your thoughts on using the newly implemented stax based parsers in JBMETA for ejb-jar.xml parsing?
[16:10:26] <Jaikiran> or do you want that to be redone to move those parsers into AS7 and directly create the *Description?
[16:10:32] <bstansberry> baileyje: yes
[16:10:44] <Jaikiran> i see that currently web uses those parsers and generates JBMETA and uses it
[16:11:41] *** balunasj_mtg is now known as balunasj_busy
[16:11:43] <dmlloyd> I'm on a call but we can chat as soon as it's done
[16:12:34] <baileyje> bstansberry: Ok.  So it is creating and add operation for each possible child.
[16:12:34] <Jaikiran> sure, np
[16:14:08] *** nickboldt1 has quit IRC
[16:14:13] *** nickboldt has joined #jboss-as7
[16:14:14] *** ChanServ sets mode: +v nickboldt
[16:21:55] <rmaucher> ok, so I'm still stuck on JBAS-8916 (and all related): I'd need to have access to the modules JARs (where TLDs are *.tld files located somewhere under META-INF), preferably through a VirtualFile, and I see no way to do that at the moment
[16:22:01] <rmaucher> ant ideas ?
[16:22:04] <jbossbot> jira [JBAS-8916] Need shared TLD's for JSTL and JSF [Open (Unresolved) Task, Critical, Remy Maucherat] https://issues.jboss.org/browse/JBAS-8916
[16:23:08] *** bobmcw has quit IRC
[16:24:23] *** bobmcw has joined #jboss-as7
[16:24:23] *** ChanServ sets mode: +v bobmcw
[16:26:13] *** hbraun has quit IRC
[16:27:32] <wolfc> I've opened up JBAS-9037 and attached a jstack. I still have the process, anything else wanted?
[16:27:34] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/JBAS-9037
[16:28:27] <alesj> dmlloyd: what's the easiest way to skip whole xml element in ModulesXmlParser?
[16:28:48] <alesj> e.g. I don't care about <dependencies> content
[16:29:10] * Jaikiran checks JBAS-9037
[16:29:17] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/JBAS-9037
[16:29:25] *** jamezp has joined #jboss-as7
[16:30:45] <Jaikiran> wolfc: anything in server.log?
[16:32:41] <wolfc> Jaikiran, I've killed the process and attached the output to the issue. It includes a MSC service dump.
[16:32:53] *** nickboldt has quit IRC
[16:37:58] *** aloubyansky has joined #jboss-as7
[16:37:58] *** ChanServ sets mode: +v aloubyansky
[16:56:40] <rmaucher> so, any comment on JBAS-8916 ?
[16:56:42] <jbossbot> jira [JBAS-8916] Need shared TLD's for JSTL and JSF [Open (Unresolved) Task, Critical, Remy Maucherat] https://issues.jboss.org/browse/JBAS-8916
[16:58:20] <wolfc> https://github.com/wolfc/jboss-as/commit/9af1ec658d39771a9fbe317d853f7b1026af60ec
[16:58:21] <jbossbot> git [jboss-as] 9af1ec6.. Carlo de Wolf JBAS-8969: Processing @MessageDriven
[16:58:22] <jbossbot> jira [JBAS-8969] Implement annotation scanner for @MessageDriven. [Open (Unresolved) Sub-task, Major, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-8969
[16:58:39] <wolfc> It also takes care of JBAS-8970 for the most part
[16:58:41] <jbossbot> jira [JBAS-8970] Implement MDB Component type [Open (Unresolved) Sub-task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8970
[16:59:25] <wolfc> I'll try to see if I can get actual inflow tomorrow
[16:59:51] *** jfd has quit IRC
[16:59:58] <wolfc> who has a nice rar for me to play with?
[17:02:00] <smarlow> dmlloyd:  could you please pull https://github.com/scottmarlow/jboss-as/commit/07de3339eed74539eacaf4f8dc9e329d707ab4ba.  The non-tx changes will probably help with TCK testing.  I also fixed the integration tests by removing JPAMockSFSBContainerTestCase, which I'll replace with other tests
[17:02:02] <jbossbot> git [jboss-as] 07de333.. Scott Marlow JPA demo changes....
[17:02:51] <baileyje> bstansberry: DOes this look more like it?  http://pastebin.com/8yLr4Rh5
[17:03:30] <bstansberry> bileyje: one sec
[17:03:55] <bstansberry> baileyje too
[17:05:47] <asaldhan> Jaikiran: are u familiar with the testsuites module?
[17:08:14] <Jaikiran> asaldhan: not really
[17:08:28] <Jaikiran> i too am looking at a place to introduce new tests
[17:08:28] <asaldhan> Jaikiran: who would know? ALR?
[17:08:39] <Jaikiran> asaldhan: either ALR or dmlloyd
[17:09:10] <wolfc> I've been adding tests there
[17:09:27] <asaldhan> wolfc: do those tests need AS7 to be running?
[17:09:46] <wolfc> you can run them in two modes: managed or remote
[17:10:02] <wolfc> in managed they boot up an AS 7 instance
[17:10:11] * asaldhan thanks wolfc
[17:10:20] <asaldhan> wolfc: I have been looking for managed mode.
[17:10:27] <bstansberry> baileyje: looks good
[17:10:29] <asaldhan> wolfc: need to add some tests for web security. :)
[17:10:44] <baileyje> bstansberry: Ok.  Did you see anything else in the original commit?
[17:10:59] <bstansberry> on a call
[17:11:40] <wolfc> asaldhan: https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/src/test/java/org/jboss/as/testsuite/integration/webejb/ServletInjectionTestCase.java
[17:11:55] <wolfc> although that performCall sucks :-)
[17:12:32] <asaldhan> wolfc: np.  how does AS7 get started?  Arq handles that?
[17:12:33] *** jamezp has quit IRC
[17:13:21] *** jfd has joined #jboss-as7
[17:13:21] *** ChanServ sets mode: +v jfd
[17:14:30] *** jamezp has joined #jboss-as7
[17:14:44] <wolfc> asaldhan, yes
[17:15:18] <asaldhan> wolfc: thx. :)
[17:15:21] <wolfc> https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/pom.xml#L81
[17:19:21] <asaldhan> wolfc: sweet.
[17:22:13] <bstansberry> baileyje: I didn't see anything else, but I didn't really look in detail at the changes you made to the description stuff that maeste did; probably you should check with him?
[17:23:30] <dmlloyd> OK call is done
[17:23:37] *** fnasser has quit IRC
[17:24:23] <dmlloyd> Jaikiran: I think the parsers should directly create the description.  But I also think it should be done by April 1, and this is the most important thing.  So, you can use your best judgement.
[17:25:01] <dmlloyd> rmaucher: can you explain a bit what information you're trying to get from where, and the trouble you're running into?
[17:25:16] <dmlloyd> smarlow: okay I"ll check it out.
[17:25:47] <rmaucher> it's about getting TLDs from some module dependencies (like JSF, JSTL)
[17:25:47] <dmlloyd> rmaucher: I'm not really familiar with how TLD processing works.
[17:26:16] <dmlloyd> so you're trying to look at a deployment and get all the relevant TLDs, but you also want JSF/JSTL to come in?
[17:26:19] <baileyje> bstansberry: I just used my updated version for the datasource since it fit the operation based datasources better
[17:26:21] <rmaucher> TLDs are *.tld files contained in the META-INF folders of JARs
[17:26:56] <dmlloyd> so is it META-INF/*.tld or more like META-INF/**/*.tld?  or do they normally live in a specific directory
[17:27:08] *** rawbdor has joined #jboss-as7
[17:27:11] <rmaucher> dmlloyd, yes, basically, if JSF is a dependency of a module, the JSF TLDs have to be processed
[17:27:20] <rmaucher> META-INF/**/*.tld
[17:27:53] <dmlloyd> rmaucher: I have a feeling that the answer lies in the way that JSF and JSTL is imported.  For a web deployment, I assume you're simply importing javaee.api?
[17:28:13] <rmaucher> (you don't need to mention that JSP is the most annoying spec in EE land, it is known fact ;) )
[17:28:21] <dmlloyd> haha, yeah I accept that as a given :)
[17:28:54] <rmaucher> at the moment, JSF, EE and a number of other dependencies are added to WARs
[17:28:56] <dmlloyd> so you're not using simple class loading right, because there's no way to enumerate directory contents?
[17:29:21] <dmlloyd> and does it process TLDs anew for every deployment or do you need it to be cached somehow?
[17:29:24] <rmaucher> yeah, I could use classloading for services, but TLDs won't work
[17:29:43] <rmaucher> I can do it either way really
[17:30:26] <dmlloyd> for the purposes of JSF and JSTL we could hardcode something which simply compiles the TLDs from those two modules statically, but I don't know if this is really suitable for you
[17:30:32] <rmaucher> reprocessing TLDs would be a bit slower (if you have like 1000 deployments) but it is easier if deployments (eventually) have different dependencies
[17:30:53] <rmaucher> that works for me
[17:31:32] <rmaucher> if there's a JSTL and JSF deployers wherever that have the metadata, it's fine
[17:32:01] <dmlloyd> the tricky part is enumerating the files
[17:32:53] <rmaucher> the more cached and harcoded it is, the fastest things will be (TLD processing is expensive, there're big and there are lots of them)
[17:33:31] <rmaucher> but obviously a user wouldn't be able to have his own shared taglibs (which I don't really care about)
[17:34:39] <dmlloyd> yeah I think supporting taglibs as installed modules is probably more complex than we want to get into right now
[17:35:05] <dmlloyd> deployments are easier because there's VFS
[17:35:39] <rmaucher> yes, and modules aren't VFS
[17:35:43] <dmlloyd> so maybe we can just hardcode the list of TLD files which need processing sometime early on
[17:35:57] <dmlloyd> it's ugly but effective
[17:36:00] <dmlloyd> kind of like me!
[17:36:15] <rmaucher> ok
[17:36:42] <dmlloyd> looks like there aren't too many of them
[17:36:54] <rmaucher> Stan suggested that in JBAS-8916, but I didn't think you would ok it
[17:37:03] <jbossbot> jira [JBAS-8916] Need shared TLD's for JSTL and JSF [Open (Unresolved) Task, Critical, Remy Maucherat] https://issues.jboss.org/browse/JBAS-8916
[17:37:08] <rmaucher> JSTL + JSF, and that's it
[17:37:17] <dmlloyd> well this kind of thing can always be revisited
[17:37:35] <dmlloyd> we can invent a super-elegent caching TLD system later :)
[17:37:51] <rmaucher> ah nice ;)
[17:37:53] *** mmoyses has quit IRC
[17:38:23] <rmaucher> so I simply hardcode a path from the modules folder then ?
[17:38:52] <rmaucher> on the plus side, I'll store the TLDs (so they'll get processed only once when first deploying a webapp)
[17:38:56] <dmlloyd> well if it's a list of relative paths you can just use getResourceAsStream() from the module CL or something
[17:39:40] <rmaucher> ok, getResourceAsStream works fine with META-INF (usually ;) )
[17:40:39] <dmlloyd> you'll have to call it right on the JSF impl and JSTL api jars
[17:40:42] <dmlloyd> modules I mean
[17:40:50] <dmlloyd> module class loaders I mean
[17:40:52] <rmaucher> ok
[17:40:57] * dmlloyd communication problem
[17:41:00] *** frainone has quit IRC
[17:41:09] <rmaucher> I think I can do that, they're dependencies
[17:41:41] <dmlloyd> if all else fails there's always moduleLoader.loadModule("com.sun.jsf-impl").getClassLoader()
[17:42:39] <rmaucher> ok :)
[17:47:23] <jbossbot> git [jboss-as] push master 0e23f0c.. David M. Lloyd Add proper client entry point support
[17:47:23] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/4ac60c9...0e23f0c
[17:47:28] <dmlloyd> since nobody objected ;)
[17:51:39] <jhalliday> dmlloyd: ping
[17:52:05] <dmlloyd> what's up jhalliday
[17:53:09] <jhalliday> there are a lot of config properties in JBossTS that we chose not to expose through the AS domain model, but nevertheless occasionally need tweaking. in the absence of a transaction-jboss-beans.xml what's the best way to do that?
[17:54:07] <dmlloyd> the domain model concept includes a sort of "unsupported" concept of a generic properties map
[17:54:11] <dmlloyd> you could use that
[17:54:27] <dmlloyd> this way it's still manageable yet you're not necessarily obligated to support it
[17:55:02] <jhalliday> hmm, so it still has some way of doing bean property injection from xml?
[17:56:43] <dmlloyd> no it has to be wired up manually in the handler
[17:56:48] *** pferraro has joined #jboss-as7
[17:56:48] *** ChanServ sets mode: +v pferraro
[17:57:04] <jhalliday> ahh ok, so I write java to query the property map and call my bean setters?
[17:57:50] <dmlloyd> yeah more or less
[17:58:00] <jhalliday> fair enough. got an example somewhere?
[17:58:01] <dmlloyd> it uses a ModelNode map internally
[17:58:07] <dmlloyd> that I'm not sure of
[17:58:23] <dmlloyd> bstansberry: do you know of any current subsystem examples using general-purpose properties?
[17:58:44] <baileyje> dmlloyd https://github.com/baileyje/jboss-as/commit/c354b32dd4f5e72fb92a125a9f33c60bb94e3fbe
[17:58:45] <jbossbot> git [jboss-as] c354b32.. John E. Bailey [JBAS-9007] - Rename junit module
[17:58:46] <jbossbot> jira [JBAS-9007] Rename module "junit.junit" to "org.junit" [Open (Unresolved) Task, Minor, John Bailey] https://issues.jboss.org/browse/JBAS-9007
[17:59:08] <bstansberry> osgi has a general property thing
[17:59:54] <jhalliday> can I add a directory to a module's classloader?
[17:59:57] <bstansberry> dmlloyd: doesn't remoting?
[18:01:30] *** jcosta has quit IRC
[18:01:46] <dmlloyd> not sure
[18:02:06] <dmlloyd> jhalliday: it depends - what module, and what directory?
[18:02:53] <jhalliday> transactions, because TS already has the ability to config itself from a file, if only it can find the file... if we could put it on the classpath that's an alternative to the domain thing.
[18:03:13] <jhalliday> in older AS it's server/conf
[18:03:31] <jbossbot> git [jboss-as] push master 188fba6.. Scott Marlow JPA demo changes....
[18:03:31] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/0e23f0c...188fba6
[18:04:34] <jhalliday> the other way is to add to the domain model a config file url property, effectively giving us a generic way to drop in an extensible set of properties.
[18:05:17] <dmlloyd> baileyje: I see existing usages in: $ grep junit.junit testsuite/smoke/src/test/resources/modules/*.xml
[18:06:15] <dmlloyd> jhalliday: we can't have mutable configuration outside the domain, so if possible we should programmatically configure that stuff (via properties if necessary)
[18:06:55] <baileyje> dmlloyd: Those are referring to maven artifacts.
[18:07:15] <jhalliday> there is no way I'm exposing over 100 properties though the domain model, especially since most of them never get overridden in normal use. but we need some mechanism for handling corner cases.
[18:07:28] <dmlloyd> jhalliday: the test is, if it is a feature we want to support in EAP it gets a domain-level entity (and a backwards-compatibility guarantee of upwards of forever).  If it's a feature that we may need for support purposes but we want to be able to drop or change it at any time then it becomes a generic key-value property of the subsystem.
[18:07:51] <dmlloyd> baileyje: ok, cool.
[18:07:54] <jhalliday> right, the one's i'm on about are all the latter
[18:08:24] <baileyje> dmlloyd: You are reffering to the $junit:junit$ references correct?
[18:08:30] <dmlloyd> jhalliday, okay then that's the way we should support it.  It still has to be in the domain model though
[18:08:32] <dmlloyd> baileyje: yeah.
[18:08:43] <baileyje> Yeah.  That is pulling the maven artifact.
[18:09:06] <jhalliday> ok, then I need an example or docs for working with this generic property map
[18:09:39] <bstansberry> dmlloyd, jhalliday: the remoting subsystem has properties, but unfortunately just parses them and then ignores them :(
[18:09:50] *** alesj has quit IRC
[18:10:12] *** pilhuhn is now known as pil-dinner
[18:10:56] * bstansberry will file a JIRA in a sec
[18:14:02] <jbossbot> git [jboss-as] push master a5ae4fa.. John E. Bailey [JBAS-9007] - Rename junit module
[18:14:03] <jbossbot> jira [JBAS-9007] Rename module "junit.junit" to "org.junit" [Open (Unresolved) Task, Minor, John Bailey] https://issues.jboss.org/browse/JBAS-9007
[18:14:03] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/188fba6...a5ae4fa
[18:14:44] <bstansberry> jhalliday: in the osgi/service module package org.jboss.as.osgi.parser the OSGIExtension and OSGISubsystemAdd classes are dealing with a generic properties thing
[18:15:04] <bstansberry> remoting module has some stuff too, but just drops the properties
[18:15:20] *** balunasj_busy has quit IRC
[18:19:17] <jhalliday> that does not look generic at all - the schema is explicitly declaring a propertyType
[18:22:05] <dmlloyd> it's generic from the user's perspective
[18:22:12] *** AndyTaylor has quit IRC
[18:22:21] <baileyje> dmlloyd: https://github.com/baileyje/jboss-as/commit/4b26855a7487d2fb7925cb195750b6cbbc95019c
[18:22:21] <jbossbot> git [jboss-as] 4b26855.. John E. Bailey [JBAS-9002] - Rename hibernate module
[18:22:22] <jbossbot> jira [JBAS-9002] Module rename "org.hibernate.hibernate" -> "org.hibernate" [Open (Unresolved) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9002
[18:22:34] <dmlloyd> he's a machine
[18:22:41] <jhalliday> right, but basically it's just taking the existing jbossts properties file and embedding it in an xml file
[18:23:00] <baileyje> just taking a break with some mindless task knocking out
[18:23:25] <dmlloyd> works for me, while the build runs I triage JIRAs :)
[18:24:12] <dmlloyd> jhalliday: ideally the user would use the same key-value property syntax for jbossts as for other things.  How you interpret the data is up to you though
[18:24:36] *** Jaikiran has quit IRC
[18:24:47] <dmlloyd> bstansberry: did you see aloubyansky's pull request?
[18:25:17] <bstansberry> the one on the list, yes, I'll get to it
[18:25:20] <bstansberry> i'll reply
[18:25:32] <aloubyansky> thanks
[18:25:52] <jhalliday> ok, but why have each module reinvent the wheel? shouldn't the server have some generic code to define the generic properties xml and turn it into e.g. a java.util.Properties for the module to work with?
[18:25:53] <aloubyansky> i've looking into the test hangs from the testsuite
[18:26:27] <bstansberry> jhalliday: sounds good
[18:26:28] <aloubyansky> is there a way to run a single test from the testsuite?..
[18:27:32] <jhalliday> hell, just embed the xml schema for the Properties format that the jdk can already deal with.
[18:28:40] *** bobmcw has quit IRC
[18:29:19] <dmlloyd> there are utility methods to parse properties elements for you
[18:29:24] <dmlloyd> iirc
[18:29:43] <dmlloyd> not sure it turns it into a Properties though
[18:30:15] <jhalliday> well I can steal the osgi code for it, but I'm not convinced that cut n paste is the answer.
[18:30:22] <bstansberry> the parser has to create an operation expressed in jboss-dmr
[18:30:26] <dmlloyd> it is the answer for today :)
[18:30:27] *** stansilvert has joined #jboss-as7
[18:31:39] *** frainone has joined #jboss-as7
[18:31:40] *** frainone has quit IRC
[18:31:40] *** frainone has joined #jboss-as7
[18:31:40] *** ChanServ sets mode: +v frainone
[18:31:43] <jhalliday> ok, next question: when do I get an ORB to play with?
[18:31:48] <bstansberry> i have no objection to utilities to go from xml to a jboss-dmr ModelNode structure and then another to go from jboss-dmr to java.util.Properties
[18:32:25] <baileyje> stuartdouglas: DId you fix JBAS-8920
[18:32:31] <jbossbot> jira [JBAS-8920] Deployment fails with empty classpath manifest [Open (Unresolved) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-8920
[18:32:49] <jbossbot> git [jboss-as] push master ab5f01e.. John E. Bailey [JBAS-9002] - Rename hibernate module
[18:32:50] <jbossbot> jira [JBAS-9002] Module rename "org.hibernate.hibernate" -> "org.hibernate" [Open (Unresolved) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9002
[18:32:51] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/a5ae4fa...ab5f01e
[18:35:22] *** pgier has quit IRC
[18:35:23] *** jamezp has quit IRC
[18:36:17] *** bobmcw has joined #jboss-as7
[18:36:17] *** ChanServ sets mode: +v bobmcw
[18:37:00] *** jamezp has joined #jboss-as7
[18:37:23] <dmlloyd> jhalliday: JBAS-9021
[18:37:24] <jbossbot> jira [JBAS-9021] IIOP subsystem [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9021
[18:37:27] * dmlloyd shrugs
[18:37:34] <dmlloyd> soon?  maybe?
[18:37:41] <dmlloyd> problem is we don't have an ORB dude
[18:38:30] <dmlloyd> someone has to do the drudge work of integrating JacORB (JBAS-8972) and then building the IIOP subsystem on that
[18:38:31] <jbossbot> jira [JBAS-8972] Integrate JacORB [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8972
[18:39:04] <dmlloyd> I'm sure I"ll be doing it this summer if nobody else steps up, which would be unfortunate as I know jack crap about IIOP
[18:39:50] <jhalliday> let me put it this way: if it's not done in the next three weeks or so then TS is shipping with no JTS
[18:40:40] <jhalliday> which would suit me fine actually :-)
[18:40:54] *** smcgowan has joined #jboss-as7
[18:40:54] *** ChanServ sets mode: +v smcgowan
[18:45:17] <dmlloyd> well it's all required for EAP
[18:45:33] <dmlloyd> so it's really a question of resources
[18:45:48] * dmlloyd speaking as the guy who picks up the slack when nobody else is able or willing to help
[18:46:46] <jhalliday> sounds like it's time to tell management to find an orb guy or do without jts then.
[18:49:22] <dmlloyd> talk to dimitris and bruno - maybe someone from PM too like Rich?
[18:49:33] <dmlloyd> well maybe just dimitris and bruno for now
[18:49:41] *** sguilhen has joined #jboss-as7
[18:49:44] <dmlloyd> cc jason and myself
[18:50:50] <jhalliday> already did a while back, just missed you off the cc list on the basis that Jason should disseminate info to the AS team as needed. sounds like he didn't in this instance.
[18:50:56] <sguilhen> dmlloyd: ping, I've been looking into the AS6 IIOP implementation and plan on moving the relevant code to a new project to be integrated with AS7 later
[18:51:28] *** pgier has joined #jboss-as7
[18:51:28] *** ChanServ sets mode: +v pgier
[18:51:38] <dmlloyd> excellent, shall I assign the relevant JIRAs to you?
[18:51:45] <dmlloyd> note that the timeline is fairly restrictive
[18:52:29] *** pgier has quit IRC
[18:52:33] <sguilhen> dmlloyd: sure, go ahead, I think we're almost good to release PicketLink, so I should have more time to dedicate to the IIOP integration
[18:52:43] <dmlloyd> baileyje: you have any idea what JBAS-8991 is all about?
[18:52:44] <jbossbot> jira [JBAS-8991] Cannot start beta1 server on RHEL6 with OpenJDK 1.6 [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/JBAS-8991
[18:52:58] <dmlloyd> sguilhen: excellent!
[18:54:09] *** torben has quit IRC
[18:54:22] <baileyje> dmlloyd: no idea
[18:54:27] <baileyje> Have you tried it?
[18:54:38] <baileyje> I don't have RHEL handy
[18:55:04] <dmlloyd> dunno seems like an odd error though
[18:55:17] <dmlloyd> thought maybe it was related to their particular OpenJDK
[18:55:21] <dmlloyd> I wonder if I can get a zip of that
[19:00:10] <dmlloyd> there, all issues reported against 7 are now triaged and assigned to a release
[19:00:22] * dmlloyd will try to stay on top of future issues
[19:00:34] <dmlloyd> 116 total
[19:03:06] *** pgier has joined #jboss-as7
[19:03:06] *** ChanServ sets mode: +v pgier
[19:04:31] <dmlloyd> jhalliday: so you guys are planning a new 5.x series?
[19:04:52] *** emuckenhuber has quit IRC
[19:05:19] <jhalliday> dmlloyd: ahh, you need the other roadmap doc too if you're asking that. one sec.
[19:05:27] <dmlloyd> I'm just curious really
[19:05:29] <dmlloyd> no important reason
[19:05:37] * dmlloyd is always interested in the new stuff
[19:06:15] *** jfclere has quit IRC
[19:06:29] <baileyje> dmlloyd: JBAS-8920 seems to be resolved.
[19:06:31] <jbossbot> jira [JBAS-8920] Deployment fails with empty classpath manifest [Open (Unresolved) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-8920
[19:06:38] <dmlloyd> great.
[19:06:58] <dmlloyd> one problem with bugs that aren't assigned to a release is that they sometimes get fixed and nobody closes the issue
[19:07:21] *** mmoyses has joined #jboss-as7
[19:07:21] *** ChanServ sets mode: +v mmoyses
[19:07:23] <dmlloyd> you can close the issue with a fix version of Beta1
[19:07:40] *** torben has joined #jboss-as7
[19:07:40] *** ChanServ sets mode: +v torben
[19:08:05] *** stansilvert has quit IRC
[19:09:48] <smcgowan> rmaucher:  is there additional configuration step to hit localhost:8080 from AS 7 after installed?
[19:10:18] <rmaucher> if you don't deploy a webapp, you won't see much
[19:10:34] <smcgowan> they see blank - i guess there's no landing page
[19:10:49] <rmaucher> indeed, there's nothing
[19:11:13] <smcgowan> ok- seems to be the first thing everyone is trying
[19:12:24] <dmlloyd> I suppose we ought to have something pretty to look at eh
[19:12:33] <dmlloyd> maybe an error page too
[19:12:50] <dmlloyd> maybe we should have james & co design something fancy :)
[19:12:59] <smcgowan> dmlloyd: ya, welcome screen at least
[19:13:14] <dmlloyd> rmaucher: what do you think
[19:13:20] <baileyje> dmlloyd: I closed it and put a comment pointing to the correct fix commit.
[19:13:27] <dmlloyd> thanks
[19:14:28] <baileyje> dmlloyd: You have any more info on what is missing for JBAS-9017
[19:14:29] <jbossbot> jira [JBAS-9017] Support for application.xml [Open (Unresolved) Sub-task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9017
[19:14:59] <dmlloyd> I don't think we have a parser for it at all
[19:15:01] *** aloubyansky has quit IRC
[19:15:05] <dmlloyd> I could be wrong though
[19:15:12] <baileyje> Yeah.  We do.
[19:15:15] <dmlloyd> oh
[19:15:20] <baileyje> We have application.xml and jboss-app.xnml
[19:15:28] <dmlloyd> rock
[19:15:39] <dmlloyd> guess we can close that one as fixed in Beta1 then
[19:15:54] <baileyje> unless someone removed it
[19:16:12] <dmlloyd> we might have to look at somehow supporting the start order thing
[19:16:30] <baileyje> EarMetaDataParsingProcessor and JBossAppMetaDataParsingProcessor
[19:16:41] <rmaucher> I think we should have a default webapp like AS 6, I suppose
[19:17:22] <dmlloyd> rmaucher, would it be possible to have a non-deployment provide the default page if e.g. no ROOT.war is deployed?
[19:17:31] <dmlloyd> somehow build it into the web subsys?
[19:18:28] <dmlloyd> maybe something that exists in its own module, so that the console web server can also use it in the HC
[19:19:14] *** ALR has joined #jboss-as7
[19:19:14] *** ChanServ sets mode: +v ALR
[19:19:26] <baileyje> dmlloyd: Yeah.  It parses the "InitializeInOrder", but we don't use it
[19:22:00] <jhalliday> smarlow: ping
[19:23:38] <jamezp> dmlloyd: I don't think I missed anything. https://github.com/jamezp/jboss-as/commit/782f6fd48c0b5aa04b93158940c1af2b23e9eb34
[19:23:39] <jbossbot> git [jboss-as] 782f6fd.. James Perkins Rename javax.servlet.jstl to javax.servlet.jstl.api. JBAS-8982
[19:23:40] <jbossbot> jira [JBAS-8982] Rename module "javax.servlet.jstl" to "javax.servlet.jstl.api" for consistency with other javax APIs [Open (Unresolved) Bug, Major, James Perkins] https://issues.jboss.org/browse/JBAS-8982
[19:24:19] <smarlow> jhalliday:  pong
[19:24:41] *** pferraro has quit IRC
[19:25:25] <baileyje> dmlloyd: I resolved the parsing jira and opened JBAS-9041
[19:25:26] <jbossbot> jira [JBAS-9041] Add support for EAR module initialize in order [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9041
[19:25:50] <jhalliday> smarlow: re: JBTM-828, we have a recovery system architecture that allows callbacks to be registered and executes them under a TCCL set using the CL of the registered class. Is that going to cause problems?
[19:25:53] <jbossbot> jira [JBTM-828] Please avoid TCCL [Open (Unresolved) Bug, Major, Jonathan Halliday] https://issues.jboss.org/browse/JBTM-828
[19:25:58] <dmlloyd> jamezp: okay, testing now
[19:26:16] <dmlloyd> baileyje: perfect, thanks.
[19:29:06] <smarlow> jhalliday, jpederse:  You might have something to say about about the resource recovery support in as7.  Have we plugged that in yet?
[19:29:54] <jhalliday> the recovery system itself is in, because it's part of TS. not sure about the autoregistration of callbacks by e.g. datasource deployment code
[19:29:56] <dmlloyd> darranl: did you see the post on as7-dev about the auth cache?
[19:30:02] * dmlloyd thought you might have an idea
[19:30:12] *** torben has quit IRC
[19:31:06] <jpederse> smarlow: next drop - end of the month
[19:32:19] <jhalliday> smarlow: not sure you answered my question...
[19:32:33] <bstansberry> yuck. JBAS-9042
[19:32:34] <jbossbot> jira [JBAS-9042] Smoke tests hang in management request handling code [Open (Unresolved) Bug, Blocker, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9042
[19:32:51] *** torben has joined #jboss-as7
[19:32:51] *** ChanServ sets mode: +v torben
[19:33:03] * smarlow 1 sec, on phone with DR's office...
[19:33:17] <dmlloyd> bstansberry: might be related to JBAS-9037?
[19:33:18] <jbossbot> jira [JBAS-9037] Hang in org.jboss.as.test.embedded.demos.ejb3.SingletonBeanTestCase [Open (Unresolved) Bug, Blocker, Unassigned] https://issues.jboss.org/browse/JBAS-9037
[19:34:22] <bstansberry> dmlloyd: probably
[19:34:56] <dmlloyd> baileyje: did you deliver the fix for JBAS-8024?
[19:34:57] <jbossbot> jira [JBAS-8024] Weld deployments fail with "Error in zip file" message [Resolved (Done) Bug, Critical, John Bailey] https://issues.jboss.org/browse/JBAS-8024
[19:36:46] *** torben has quit IRC
[19:37:57] <smarlow> jhalliday:  do you have a URL to the javadoc for the interface used for the registration + callbacks?  jpederse showed it to me before but need a refresher
[19:38:44] <jpederse> smarlow: why do you need it ? xa datasources will be registered automatically
[19:39:37] <smarlow> jpederse:  the real question, is:
[19:39:39] <smarlow> <jhalliday> smarlow: re: JBTM-828, we have a recovery system architecture that allows callbacks to be registered and executes them under a TCCL set using the CL of the registered class. Is that going to cause problems?
[19:39:40] <jbossbot> jira [JBTM-828] Please avoid TCCL [Open (Unresolved) Bug, Major, Jonathan Halliday] https://issues.jboss.org/browse/JBTM-828
[19:40:46] <jhalliday> smarlow: I cna give you that, but it's not related to the question as we use the architecture internally too.
[19:42:15] <jpederse> smarlow: yeah, it is a SPI
[19:42:26] <jbossbot> git [jboss-as] push master 56c7833.. Alexey Loubyansky JBAS-8965
[19:42:28] <jbossbot> jira [JBAS-8965] cli: switch to state machine based parsing for the whole operation request [Open (Unresolved) Task, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-8965
[19:42:28] <jbossbot> git [jboss-as] push master e662e07.. Alexey Loubyansky JBAS-8951 and ignore whitespaces between separators in the opreation request
[19:42:29] <jbossbot> jira [JBAS-8951] cli: ignore leading whitespaces in the command string [Open (Unresolved) Bug, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-8951
[19:42:29] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/ab5f01e...e662e07
[19:43:12] <jhalliday> smarlow: http://www.docjar.com/docs/api/org/jboss/tm/XAResourceRecoveryRegistry.html
[19:44:14] <baileyje> dmlloyd: No fix for 8024 that I know of
[19:44:18] <smarlow> jhalliday, jpederse:  so the registered class, is a ironjacamar implementation of XAResourceRecovery.  And the TCCL is set to that classes CL
[19:44:50] <smarlow> jhalliday, jpederse:  just asking if I'm following correctly? ^
[19:44:56] <jhalliday> smarlow: no, like I said that's not the only place we use the pattern.
[19:45:08] <baileyje> dmlloyd: If I remember I had to do a hack in AS6
[19:46:24] <jpederse> smarlow: yes, we provide an implementation of the XAResourceRecovery interface
[19:46:30] <smarlow> jhalliday:  okay, I thought we might want to answer the question for specific cases.  I guess the XAResourceRecovery implementation use is one and there are other internal cases.
[19:46:35] <jpederse> smarlow: the new configuration is here
[19:46:43] <jpederse> smarlow: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jboss-jca/trunk/common/src/main/resources/schema/datasources_1_0.xsd?revision=110917&view=markup
[19:46:51] <jpederse> smarlow: see recoverType
[19:47:53] <dmlloyd> baileyje: ok I was just wondering if we could use a similar hack for whatever the issue was.
[19:48:07] <baileyje> dmlloyd: I just can't remember what the hell I did
[19:48:46] <baileyje> dmlloyd: This is sooo bad.
[19:48:59] <baileyje> look at processClasspath
[19:49:24] <baileyje> if it ends in .jar it forces it to be a jar:... URL
[19:49:27] <jbossbot> git [jboss-as] push master dbacb84.. James Perkins Rename javax.servlet.jstl to javax.servlet.jstl.api. JBAS-8982
[19:49:28] <jbossbot> jira [JBAS-8982] Rename module "javax.servlet.jstl" to "javax.servlet.jstl.api" for consistency with other javax APIs [Open (Unresolved) Bug, Major, James Perkins] https://issues.jboss.org/browse/JBAS-8982
[19:49:28] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e662e07...dbacb84
[19:49:30] <dmlloyd> thanks jamezp
[19:49:46] <jamezp> Thank you! I'll see if there is something else I can do.
[19:49:55] <dmlloyd> baileyje: ah.  what path is it starting with? codeSource or something?
[19:51:07] <dmlloyd> baileyje: it wouldn't be the first thing assuming that you're dealing with a jar: URL.
[19:51:21] <smcgowan> i agree with jperkins on the jbas-8982 issue - was going to bring that up as well, glad its changed
[19:51:22] <baileyje> it doesn't assume.  It makes it that way
[19:51:33] <dmlloyd> baileyje: I mean the target thing which consumes the URL
[19:51:57] <dmlloyd> smcgowan: I went on a JIRA-filing spree.
[19:52:34] <smcgowan> dmlloyd:  did you see this one: JBAS-9036
[19:52:35] <jbossbot> jira [JBAS-9036] Replace EE APIs with the org.jboss.spec versions [Open (Unresolved) Bug, Major, Shelly McGowan] https://issues.jboss.org/browse/JBAS-9036
[19:52:38] <smarlow> jhalliday:  just to give me a better idea, are you branching something for AS7?  Or are you trying to support AS 5 still with the artifacts that you deliver for AS7?
[19:52:51] <baileyje> dmlloyd: The thing that needs it is expecting a JarFile object
[19:53:34] <smcgowan> dmlloyd:  not sure about CDI, BV, javax.inject as they are part of the RI
[19:53:35] <smarlow> jhalliday:  I'm asking just so that I understand what you are up against better
[19:53:42] <dmlloyd> smcgowan: no I didn't see that.  It seems doable - easy even - but we just need to check with the maintainers of those subsystems
[19:54:01] <dmlloyd> baileyje: craptastic.
[19:54:15] <dmlloyd> baileyje: what code is that, something inside JSF?
[19:54:16] <jhalliday> smarlow: the code in question runs standalone and in other embedding contexts too, I'm just trying to accommodate the AS7 as best I can, but that use case does not get to dictate the model without a very good reason.
[19:54:21] <baileyje> Oh.  Right it can be overridden by a "com.sun.faces.spi.annotationprovider" property.
[19:54:23] <baileyje> yeah. JSF
[19:54:42] <dmlloyd> okay so what we want to do is write our own, right?  maybe using jandex or something for extra coolness
[19:55:08] <smarlow> jhalliday:  we tend to hit these TCCL problems unexpectedly :)
[19:55:18] <dmlloyd> com.sun.faces.spi.AnnotationProvider I guess
[19:55:24] <jhalliday> write more tests :-)
[19:55:31] <smcgowan> dmlloyd: i have those three already in the specs project but not released
[19:56:12] <dmlloyd> smcgowan: I saw they were in the projects, just assumed they were released I guess.  I keep a checkout of the specs project in my AS7 workspace for convenience
[19:56:42] <smcgowan> dmlloyd:  those three have not been brought in as the project maintainers do not agree about the specs project
[19:56:55] <dmlloyd> ah so it's one of THOSE things :)
[19:57:00] <smarlow> jhalliday:  more tests are definitely needed :-)  But its more of, you add one new feature/enhancement/bug fix and get slammed up against the TCCL wall. ;)
[19:57:02] <baileyje> dmlloyd: You have a local checkout of AS6?  Think you could do a find for "com.sun.faces.spi.AnnotationProvider"
[19:57:11] <baileyje> for a file named that
[19:57:21] <dmlloyd> baileyje: that class is in the jsf-impl JAR
[19:57:29] <dmlloyd> baileyje: unfortunately there's no sources for it in maven :|
[19:57:39] <baileyje> yeah.  I have been looking in docjar
[19:57:44] <dmlloyd> annoying
[19:57:47] <baileyje> jsf-impl allows override
[19:57:53] <baileyje> with a service/com.sun.faces.spi.AnnotationProvider file
[19:57:59] <baileyje> services/com.sun.faces.spi.AnnotationProvider
[19:58:02] <dmlloyd> there's basically one method
[19:58:03] <dmlloyd> public abstract java.util.Map<java.lang.Class<? extends java.lang.annotation.Annotation>,java.util.Set<java.lang.Class<?>>> getAnnotatedClasses(java.util.Set<java.net.URL> urls);
[19:58:09] <baileyje> Not sure if that is what we did in AS6
[19:58:12] <smcgowan> dmlloyd:  i'll discuss that topic again with jason when he gets back - it's not a big deal, but moving forward with EAP it would be easier for productizing
[19:58:24] <baileyje> dmlloyd: I will see if I can add something.
[19:58:37] <smcgowan> and the artifact names clearly identify the API version according to spec
[19:58:40] <jhalliday> well in this instance I'm leaving the recovery CL code alone until it's proven to be broken.  meanwhile the good news is I think I clobbered pretty much all the other TCCL usage.
[19:58:59] <dmlloyd> smcgowan: okay.  I see the sense of it but it'll be interesting to see how it plays out politically
[19:59:02] <jhalliday> and the even better news is it's dinner time. :-)
[19:59:27] <smarlow> jhalliday:  that sounds great about clobbering all the other TCCL usage!  It was pretty wide spread, from what you said before!
[19:59:32] <smcgowan> dmlloyd:  that's the issue
[19:59:48] *** jhalliday is now known as jhalli_gone
[20:01:25] <dmlloyd> baileyje: the servlet context is passed in to the constructor.  you could potentially just ignore the URLs argument and just return stuff from the associated deployment, if there's some way to go from ServletContext to deployment
[20:01:53] <dmlloyd> baileyje: ServletContext.getClassLoader() might help for that, possibly...
[20:02:21] <baileyje> dmlloyd: They should be VFS URLs.
[20:02:37] <dmlloyd> true
[20:02:41] <baileyje> But it would be great to get the deployment and use the annotation index.
[20:03:12] <dmlloyd> yeah maybe we could set up aliases for the deployment services with their resource root paths or something
[20:03:20] <dmlloyd> seems like there's options
[20:04:09] *** jwulf has joined #jboss-as7
[20:04:35] <baileyje> dmlloyd: I was thinking of finding a way to add a web deployer that attaches the index somehoe..
[20:04:37] <baileyje> how
[20:04:51] <baileyje> I will come up with something
[20:05:14] <dmlloyd> yeah I guess if we know what annotations are going to be looked up we could build the index and push it into the web deployment somehow
[20:05:22] <dmlloyd> instead of referring back to the index at runtime
[20:06:05] <baileyje> dmlloyd: Yeah.  That was my thought.
[20:06:17] <baileyje> preload it somehow.
[20:06:30] <baileyje> Maybe we can tag something onto the servlet context
[20:06:31] <dmlloyd> we can also minimize the index size that way too
[20:06:39] <dmlloyd> yeah that'd be pretty handy
[20:06:50] <dmlloyd> that'd make the annotation provider impl a cinch
[20:07:49] *** tdiesler has quit IRC
[20:09:31] <baileyje> be back to work on it in 30
[20:16:53] *** rawbdor has quit IRC
[20:20:22] *** jpederse has quit IRC
[20:21:48] *** pferraro has joined #jboss-as7
[20:21:49] *** ChanServ sets mode: +v pferraro
[20:28:32] <ALR> Looks like I missed Thomas.  Does he usually reappear later on?
[20:28:44] <ALR> (Perhaps he's a crazy night owl like some of us) :)
[20:29:42] <dmlloyd> baileyje: can you santiy-check http://github.com/dmlloyd/jboss-as/commit/886f865 please?
[20:29:43] <jbossbot> git [jboss-as] 886f865.. David M. Lloyd [JBAS-9001] Fix commons-collections module name
[20:29:45] <jbossbot> jira [JBAS-9001] Improper/possible duplicate module naming for commons-collections [Open (Unresolved) Bug, Major, David Lloyd] https://issues.jboss.org/browse/JBAS-9001
[20:29:58] <dmlloyd> ALR: he's pretty unpredictable, usually mornings (our time) is when he can be found though
[20:30:07] <ALR> Makes sense.
[20:30:23] <ALR> The pressure's on for AS7 spec-ey testsuite
[20:30:35] <ALR> And doesn't look like it can wait until after I'm back from ATL on Wed
[20:30:43] <ALR> So...digging into it.
[20:30:58] <dmlloyd> pinning down exact requirements seems like the hardest part...
[20:31:03] <ALR> Agreed.
[20:31:07] <ALR> I have my opinions.
[20:31:18] <bstansberry> can I get a trivial thumbs up on https://github.com/bstansberry/jboss-as/commit/e760dce9f51561b340f575282b549f98f649775e ?
[20:31:19] <jbossbot> git [jboss-as] e760dce.. bstansberry at jboss dot com Don't attempt rollback when compensating op is undefined
[20:31:45] <dmlloyd> bstansberry: approved
[20:32:11] <jbossbot> git [jboss-as] push master 8ff0349.. bstansberry at jboss dot com Don't attempt rollback when compensating op is undefined
[20:32:11] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/dbacb84...8ff0349
[20:32:48] * bstansberry needs to clear random stuff from his workspace
[20:33:52] *** tdiesler has joined #jboss-as7
[20:33:52] * dmlloyd notes with pleasure that people are really picking up beta2 issues
[20:33:52] *** ChanServ sets mode: +v tdiesler
[20:34:09] <dmlloyd> tdiesler: ALR is looking for you
[20:34:31] <ALR> tdiesler: Ah perfect.  Got a few?
[20:35:17] *** tdiesler has quit IRC
[20:35:20] <dmlloyd> haha
[20:35:21] <dmlloyd> guess not
[20:35:24] <ALR> Don't blame him.
[20:35:37] <ALR> (*I* don't blame him)
[20:36:09] <ALR> Let that be a lesson to anyone else who enjoys forking projects for personal releases. :P
[20:48:34] *** adietisheim1 has joined #jboss-as7
[20:48:57] *** adietisheim has quit IRC
[20:53:42] *** alesj has joined #jboss-as7
[21:00:20] <baileyje> dmlloyd: Looks good
[21:01:02] *** mmoyses has quit IRC
[21:01:19] <jbossbot> git [jboss-as] push master 7d0a9a9.. David M. Lloyd [JBAS-9001] Fix commons-collections module name
[21:01:20] <jbossbot> jira [JBAS-9001] Improper/possible duplicate module naming for commons-collections [Open (Unresolved) Bug, Major, David Lloyd] https://issues.jboss.org/browse/JBAS-9001
[21:01:20] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/8ff0349...7d0a9a9
[21:03:26] <baileyje> Which subsystems currently use faces?  Just weld?
[21:03:28] *** irooskov has joined #jboss-as7
[21:09:37] <dmlloyd> well, web I guess
[21:09:39] <dmlloyd> indirectly
[21:10:03] <ALR> Hmm, I also have tdiesler on my list to discuss SW OSGi support.
[21:10:11] <ALR> Which is sticky to say the least.
[21:10:32] <baileyje> yeah.  I am trying to figure out the best place to put the service file for the Annotationprovider
[21:11:45] <dmlloyd> baileyje, maybe in a new jboss-specific module imported by jsf-impl
[21:11:49] <dmlloyd> ?
[21:12:03] <baileyje> dmlloyd: Yeah.  That could work.  Part of the AS codebase?
[21:12:23] <dmlloyd> yeah could do, though AS needs another module like a hole in the head
[21:17:54] <asaldhan> aslak: there?
[21:18:04] <asaldhan> ALR: dude
[21:18:28] <asaldhan> ALR: I am trying to write some integration tests in as7
[21:18:45] <dmlloyd> can I get an OK on a trivial rename: http://github.com/dmlloyd/jboss-as/commit/fccbe64
[21:18:45] <jbossbot> git [jboss-as] fccbe64.. David M. Lloyd Rename Disinjection -> Uninjection
[21:19:01] <asaldhan> ALR: arq is complaining about deployment.  I am not getting extra information as to why my web archive failed in as7
[21:19:37] <asaldhan> ALR: the problem is addition of web.xml.  If I dont add the web.xml, the deployment is fine.  How do I get more info from arq as to what exactly failed.
[21:19:56] <aslak> asaldhan, what is the complaint ?
[21:20:22] <asaldhan> aslak: it probably is a web.xml validation.
[21:20:28] <asaldhan> aslak: getting u the trace
[21:21:26] <asaldhan> Caused by: java.util.concurrent.ExecutionException: java.lang.Exception: {&quot;Composite operation failed and was rolled back. Steps that failed:&quot; =&gt; {&quot;Operation step-2&quot; =&gt; &quot;Deployment failed.  Service failures: [org.jboss.msc.service.StartException in service jboss.deployment.unit.\&quot;web-secure.war\&quot;.INSTALL: Failed to process phase INSTALL of deployment \&quot;web-secure.war\&quot;]&quot;}}
[21:21:29] <asaldhan> aslak: ^
[21:21:33] <jamezp> dmlloyd: Don't know the weight of my opinion, but it looks right to me :-)
[21:22:02] <ALR> asaldhan: Looking
[21:22:04] <dmlloyd> :D
[21:22:10] <dmlloyd> good enough for me!
[21:22:22] <jbossbot> git [jboss-as] push master fccbe64.. David M. Lloyd Rename Disinjection -> Uninjection
[21:22:23] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/7d0a9a9...fccbe64
[21:22:42] <ALR> asaldhan: Something I can pull/run?
[21:22:52] <asaldhan> ALR: nah
[21:23:05] <asaldhan> all I did was   webArchive.setWebXML(URL)
[21:23:32] <asaldhan> ALR: so definitely AS7 did not like my web.xml   So I am wondering if I can see why it choked.
[21:23:33] <ALR> And you're not getting enough context out of ARQ?
[21:23:38] <asaldhan> ALR: no
[21:23:53] <ALR> In my experience ARQ always wraps up deployment exceptions
[21:24:05] <ALR> Anything else that may have lead to it might be in the AS server logs
[21:24:24] <asaldhan> ALR: let me see
[21:25:02] <smcgowan> ALR/aslak:  another one for you: https://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-testSuite-openjdk/2/console
[21:25:08] <smcgowan> just started that job with OpenJDK
[21:25:47] *** slaboure has joined #jboss-as7
[21:25:53] <ALR> java.lang.RuntimeException: this handler is evil
[21:25:54] <ALR> Haha
[21:25:55] <asaldhan> ALR: aslak: I did not realize I could get the log entries from AS log. All got.
[21:26:04] <ALR> asaldhan: So you're good?
[21:26:10] <asaldhan> ALR: aslak: good for now. :)
[21:26:26] <ALR> If AS isn't throwing enough context in the deployment exception, might wanna look into why there.
[21:26:50] *** ChanServ changes topic to "JBoss AS 7 development - Beta1 released @ http://is.gd/wmNXB2 - Beta2 tags on Apr. 1, issues @ http://is.gd/tL7fgk - Get started: http://community.jboss.org/wiki/HackingonAS7"
[21:27:00] <ALR> For instance in MC sometimes they'd rethrow another exception as the deployment error due to a previous unrelated failure
[21:27:06] <ALR> Hence the need to consult server logs
[21:27:13] <asaldhan> ALR: right.
[21:28:26] <baileyje> dmlloyd: Does it make sense to add this as a JSF module under as?
[21:28:42] <baileyje> where else could we put it?
[21:28:56] <baileyje> just another project?
[21:29:27] <asaldhan> ALR: aslak: thanks to both of u for Arq/SW
[21:29:39] <dmlloyd> yeah another project would be the only other option, but considering that it would likely have a dep on as-server that might be a bit clunky
[21:29:40] <ALR> Aw shucks.
[21:30:13] <asaldhan> ALR: Caused by: java.lang.ClassNotFoundException: jorg.jboss.as.testsuite.integration.websecurity.SecuredServlet from [Module "deployment.web-secure.war:main" from Service Module Loader]
[21:30:18] <baileyje> dmlloyd: Yeah.  I will start with another module in AS.  we can move later if it doesn't fit just right
[21:30:21] <asaldhan> ALR: I thought I added into the webarchive
[21:30:37] <asaldhan> ALR: war.addClasses(SecuredServlet.class);
[21:31:01] <smcgowan> asaldhan:  type:  jorg.jboss.as ??
[21:31:03] <smcgowan> typo
[21:31:11] <ALR> asaldhan: Module CL visibility problem?
[21:31:14] <ALR> Or user error?
[21:31:17] <ALR> asaldhan: Also use:
[21:31:22] <ALR> archive.toString(true)
[21:31:27] <ALR> To debug what's actually in there
[21:32:03] <asaldhan> ALR: not user error.  I am just doing  SecuredServlet.class
[21:32:11] <asaldhan> ALR: definitely SW issue. :)
[21:32:29] <dmlloyd> jorg.jboss.as...?
[21:32:49] * asaldhan is ashamed of his web.xml typo
[21:33:11] <aslak> hehe
[21:33:12] <alesj> dmlloyd: does it make sense to add RemoteModuleLoader to Modules?
[21:33:14] <ALR> asaldhan: I'm not seeing the problem though.  You add the servlet, and yet it can't be found?
[21:33:31] <asaldhan> ALR: since I need web.xml also, I had a typo there.
[21:33:50] <ALR> asaldhan: Typo == user error...
[21:33:57] <ALR> What's the SW issue then?
[21:34:07] <asaldhan> ALR: accepts now.
[21:34:24] <asaldhan> ALR: I spoke too soon without realizing that the typo can be in web.xml
[21:34:30] <ALR> Oh gotcha
[21:34:49] <dmlloyd> alesj: I dunno, I'm not sure that it isn't an anti-pattern :)
[21:35:04] <alesj> why?
[21:35:23] <dmlloyd> because I don't understand the use case
[21:35:26] <alesj> we could then ship AS with 1 jar + few config files
[21:35:41] <dmlloyd> what would the benefit be?  most servers live behind firewalls anyway
[21:35:47] <smcgowan> ALR:  no, this one: http://pastebin.com/T3EH108H
[21:36:00] <dmlloyd> the AS7 download is tiny as it is
[21:36:11] <alesj> 70M vs. 100kb
[21:36:39] <dmlloyd> 52M to be precise. :)
[21:36:44] <alesj> + add CLI command to remove module
[21:36:49] <ALR> smcgowan: Let's see the test class?
[21:36:53] <alesj> + replace it on your repo
[21:37:04] <alesj> and you have a new runtime
[21:37:06] <smcgowan> ALR:  that's building AS with OpenJDK
[21:37:33] <aslak> smcgowan, ALR jdk bug in generics casting i believe.. needs to be rewritten WebArchive.class.cast()
[21:37:42] <ALR> Yeah.
[21:37:53] <ALR> Different JDKs treat generics unpredictably sometimes.
[21:38:08] <ALR> From my readings in getting these errors before, it's an underspecified spec
[21:38:19] <aslak> smcgowan, i believe Karel upgraded to 1.6_22 on the hudson server which has fixed the issue
[21:38:21] <ALR> So aligning Sun, Eclipse, and OpenJDK compilers sometimes takes unnecessary casting.
[21:38:55] <smcgowan> aslak:  let me check which version I have, and then see if an update is there
[21:40:09] *** mmoyses has joined #jboss-as7
[21:40:09] *** ChanServ sets mode: +v mmoyses
[21:40:11] <asaldhan> ALR: dmlloyd:  my webapp is still failing even though I corrected the web.xml typo.  Any place it can get cached?  I removed standalone/tmp/work stuff too
[21:41:10] <dmlloyd> did you remember to undeploy it first?
[21:41:24] *** balunasj has joined #jboss-as7
[21:41:24] *** balunasj has joined #jboss-as7
[21:41:24] *** ChanServ sets mode: +v balunasj
[21:41:56] <smarlow> dmlloyd:  I added a rough thought on pluggable providers (JBAS-9040) to the jira.  when we discussed setting up the provider classloader before, you mentioned that you had some ideas, that i would like to hear when you have a minute.  :)  I'm stumped as to where the provider jars should go (other than deploying them somehow).
[21:41:58] <jbossbot> jira [JBAS-9040] Support for pluggable JPA providers [Open (Unresolved) Sub-task, Major, Scott Marlow] https://issues.jboss.org/browse/JBAS-9040
[21:42:00] <asaldhan> dmlloyd: deploying it from testcase. I need to check how to undeploy
[21:43:26] <baileyje> rmaucher: Are we allowed to add attributes into the servlet context for our own use?
[21:44:19] *** maxandersen has joined #jboss-as7
[21:44:19] *** ChanServ sets mode: +v maxandersen
[21:45:01] <dmlloyd> smarlow: it really depends on what the user experience should be
[21:45:58] <dmlloyd> smarlow, we could simply automatically pick up any META-INF/services/javax.persistence.spi.PersistenceProvider from deployments and if found, add it to the list for that deployment
[21:46:30] <dmlloyd> our javax.persistence.spi.PersistenceProviderResolver implementation would look at the current deployment via TCCL or similar to know what providers to report
[21:46:47] <dmlloyd> that way deployments always get hibernate unless they bundle their own provider
[21:46:53] <dmlloyd> then they always get that provider
[21:47:06] <dmlloyd> or rather they get a list with their provider followed by hibernate
[21:47:41] <smarlow> dmlloyd:  I think including the provider, with the deployment, could be our default strategy if nothing else comes to mind.  :)
[21:48:04] <dmlloyd> not sure if other ASes have a different strategy
[21:48:34] *** jamezp has quit IRC
[21:48:55] <smarlow> I'll look around at the others, to see if I can get any ideas :)
[21:51:59] <smarlow> dmlloyd:  how about having a way to deploy a provider in the AS that can be used by any application deployment.  We could version the providers as well.
[21:53:02] *** jamezp has joined #jboss-as7
[21:53:37] <smarlow> dmlloyd:  we could have a service per provider.  I'm fuzzy on how some of that would interface with as7 though (e.g. injecting ModuleDependency into deployments for a provider service)
[21:55:06] <dmlloyd> smarlow, do all the factory methods in JPA always go through javax.persistence.spi.PersistenceProviderResolverHolder?
[21:58:03] <smarlow> dmlloyd:  there are other kinds of factories that are on other classes.  But the other classes come from something, that originated from the PersistenceProviderResolver (at least that is how we would write it to happen).
[21:58:21] *** slaboure has quit IRC
[21:58:58] <smarlow> dmlloyd:  for example, javax.persistence.spi.PersistenceProvider has a createEntityManagerFactory
[21:59:19] <smarlow> which returns a EntityManagerFactory
[21:59:29] <asaldhan> ALR: figured out all my user errors. :)
[21:59:52] <smarlow> dmlloyd:  the EntityManagerFactory creates EntityManager's
[22:00:36] <ALR> asaldhan: Nice.
[22:01:01] <ALR> asaldhan: But if you think SW or ARQ can do a better job communicating your user errors, push those issues to us
[22:01:12] <ALR> And if the problem is at the AS7 level...push 'em there.
[22:01:18] *** pferraro has quit IRC
[22:01:56] <asaldhan> ALR: what if they are user errors? ;)
[22:03:48] * smarlow looking around the universe to see what others do for provider packaging
[22:07:32] *** maxandersen has quit IRC
[22:08:20] <dmlloyd> smarlow: okay so conceivably we could do the same thing.  I guess it all comes down to, do we want to support additional providers installed AS-wide or do we limit it in scope to deployments.  I see pros and cons for each.
[22:09:46] *** rawbdor has joined #jboss-as7
[22:09:46] *** ChanServ sets mode: +v rawbdor
[22:11:22] <smarlow> dmlloyd:  yup and I would prefer not to do it both ways.  :)
[22:11:31] <smarlow> at least not in this release
[22:11:32] *** epbernard has joined #jboss-as7
[22:11:37] <dmlloyd> yeah agreed
[22:11:41] *** ChanServ sets mode: +v epbernard
[22:11:50] *** emmanuel has quit IRC
[22:12:56] *** mmoyses has quit IRC
[22:14:00] *** epbernard has quit IRC
[22:14:03] *** epbernard1 has joined #jboss-as7
[22:14:03] *** epbernard1 is now known as emmanuel
[22:14:03] *** ChanServ sets mode: +v emmanuel
[22:14:08] *** emmanuel has quit IRC
[22:14:08] *** emmanuel has joined #jboss-as7
[22:14:09] *** niven.freenode.net sets mode: +v emmanuel
[22:14:17] <smarlow> dmlloyd:  looking at some of the comments on http://community.jboss.org/wiki/EJB3JPA20supportforAS7, Ales mentioned the idea of bundling the provider with the app.  Nicklas said: "Ideally it would be as easy to add new or select persistence providers as with JSF implementations in AS  6"
[22:15:24] <dmlloyd> adding them container-wide can cause complications when you have other apps running independently
[22:15:52] <dmlloyd> smarlow, didn't you say that you could also select a provider by class name in the descriptor?
[22:16:10] *** emmanuel has quit IRC
[22:16:40] <smarlow> dmlloyd:  yes, that is the only way to choose, by classname (no logical provider name)
[22:17:15] <smarlow> JPA 8.2.1.4:  The provider element specifies the name of the persistence provider's javax.persis-tence.spi.PersistenceProvider class. The provider element is optional, but should be specified if the application is dependent upon a particular persistence provider being used.
[22:18:56] <dmlloyd> does the provider have to be one from the PersistenceProviderResolver.getPersistenceProviders() list?
[22:19:03] <dmlloyd> or can it just be in hte class path?
[22:19:13] <rmaucher> baileyje, it is allowed
[22:19:37] <smarlow> dmlloyd:  I'll check, I think they were liberal about that.
[22:21:13] <smarlow> dmlloyd:  I'm wrong, they are very specific about it must be used.
[22:21:50] <jamezp> dmlloyd: AFAIK it's usually found via the classpath.
[22:22:20] <dmlloyd> ah.
[22:22:44] <dmlloyd> smarlow, and if none is specified, does it use the first in the list?  or the last, or some other policy?
[22:23:55] <smarlow> dmlloyd:  no ordering, in theory, we would pick our default from the list based on a configuration setting on code
[22:24:11] <dmlloyd> hm, okay.
[22:24:32] <dmlloyd> oh, of course, because we get to control it.
[22:24:34] <smarlow> dmlloyd:  which would be Hibernate unless we made that configurable.  I resisted configuration so far :-)
[22:25:46] <dmlloyd> well what I'm thinking is, we can use the services deployer for both cases.  If the service is declared in the root of a deployment (i.e. a persistence provider is deployed as a JAR) then it would be added to the list container-wide, but at the end (with our stuff at the beginning)...
[22:26:02] *** emuckenhuber has joined #jboss-as7
[22:26:02] *** ChanServ sets mode: +v emuckenhuber
[22:26:14] <dmlloyd> if the service is declared in a secondary root (i.e. WEB-INF/lib/provider.jar or whatever) then the provider is only visible to that deployment
[22:26:25] <dmlloyd> but it's at the *front* of the list and is used by default
[22:26:33] <dmlloyd> (for only that deployment of course)
[22:26:58] <dmlloyd> for the middle case where the JAR is in an EAR then the provider should be the default for everything in that EAR
[22:27:02] <smarlow> dmlloyd:  we can introduce properties that could distinguish which provider is desired (e.g. version tags).
[22:27:46] <dmlloyd> maybe.  That might be tricky though.
[22:27:55] <dmlloyd> might be easier to use e.g. the JAR name of the provider or something
[22:28:53] <dmlloyd> we could always just solve that problem leter.
[22:28:54] <dmlloyd> later*
[22:29:23] <smarlow> definitely.  I think we need some per provider configuration as well (and possibly classes).
[22:29:56] <smarlow> dmlloyd:  I have to walk away for a bit.  Would to discuss a little later.
[22:30:06] <dmlloyd> okay no problem.  I'll keep thinking about it.
[22:44:46] *** aloubyansky has joined #jboss-as7
[22:49:02] *** smcgowan has quit IRC
[22:52:20] *** jfd has quit IRC
[22:55:06] *** miclorb_ has joined #jboss-as7
[22:59:23] <stuartdouglas> smarlow: with the JPAAnnotationParseProcessor change, I was suggesting that it extend AbstractComponentConfigProcessor, as it is more efficient to iterate over the components, rather than find the annotations and then try and match them up with a Component
[22:59:55] <ALR> stuartdouglas: import statements are ditched by the compiler, right?
[23:00:05] <stuartdouglas> yes
[23:00:09] <ALR> ie. not available for introspection in bytecode
[23:00:14] <ALR> stuartdouglas: Thanks.
[23:00:28] <smarlow> stuartdouglas:  okay, it sounded like a performance thing but I wasn't sure.  thanks for clarifying.
[23:00:39] <stuartdouglas> although you can pull stuff out of the const pool to get an idea of what may have been imported
[23:00:46] <stuartdouglas> but that is pretty dodge
[23:05:35] <ALR> stuartdouglas: Yup, I remember this discussion from before...that's dark arts for my tastes. :)
[23:07:11] <wolfc> stuartdouglas, good morning. Just the man I was waiting for. :-)
[23:07:25] * stuartdouglas slept in today
[23:07:44] <wolfc> it's 9am at your end, not?
[23:07:57] <stuartdouglas> yes
[23:08:15] <wolfc> I got a weld test that I can't get up and running, https://github.com/wolfc/jboss-as/tree/weld
[23:08:44] <stuartdouglas> I will have a look
[23:08:53] <wolfc> getting "IllegalStateException: Context is already active"
[23:12:08] <wolfc> What strikes me as weird is WeldBeanManagerServiceProcessor doing a bindBeanManager for every component through WeldContextSetup which keeps a ThreadLocal
[23:13:55] <stuartdouglas> WeldContextSetup is an Arquillian JMX runner only thing
[23:14:10] <stuartdouglas> that sets up the contexts for the JMS based tests
[23:15:03] *** mbg has quit IRC
[23:15:18] <stuartdouglas> and the spec requires java:comp/BeanManager to be availible for every component
[23:15:36] *** alesj has quit IRC
[23:15:37] <wolfc> but now stuff gets re-used over multiple components
[23:15:43] <wolfc> that's not supposed to happen
[23:16:30] <stuartdouglas> What do you mean?
[23:16:46] <stuartdouglas> ah, actually I see what you mean
[23:16:50] <stuartdouglas> yea that is wrong
[23:17:22] <stuartdouglas> WeldContextSetup should not be in the loop
[23:17:46] *** pferraro has joined #jboss-as7
[23:17:47] *** ChanServ sets mode: +v pferraro
[23:18:13] <wolfc> I'm actually chasing down a potential bug in WeldEjbServices.resolveEjb. That methods needs to initiate a session, not SessionObjectReferenceImpl.
[23:18:40] <stuartdouglas> ok, that should be fixed in my master
[23:19:55] <wolfc> I still see it https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java/org/jboss/as/weld/deployment/SessionObjectReferenceImpl.java
[23:20:08] <stuartdouglas> no, the arq fix
[23:20:11] <wolfc> but if you can fix WeldContextSetup I can continue on the test to make sure
[23:20:20] <stuartdouglas> that was the one I fixed :-)
[23:20:29] <wolfc> ah, neat
[23:20:40] <stuartdouglas> does it matter that the session is created lazily?
[23:20:56] <wolfc> yes, else propagation doesn't work
[23:21:05] <stuartdouglas> ah, oh
[23:21:26] <dmlloyd> is JPA usable without the rest of EE?  what about weld?
[23:21:35] <asaldhan> aslak: ALR: when I annotate @RunWith(arq), does the test execute on AS7?
[23:22:06] <asaldhan> aslak: ALR: in my test, I used httpclient api and as7 logs complain about the lack of httpclient.
[23:22:18] <asaldhan> so the test itself gets executed inside AS7.  Interesting. :)
[23:22:49] <stuartdouglas> dmlloyd: not sure about weld, it would probably boot, but there may be missing services if they tried to use JPA
[23:23:09] <ALR> asaldhan: Is httpclient visible inside the deployment CL?
[23:23:14] <stuartdouglas> Is that a requirement that weld run with the other sub systems disabled?
[23:23:23] <dmlloyd> that's what I'm trying to determine
[23:23:39] <dmlloyd> I would like to identify all the subsystems which break if EE is not present
[23:23:44] <asaldhan> ALR: I doubt it.  But I thought the test case would execute in the client env and not inside AS7
[23:23:50] <ALR> Weld has standalone bootstrap.
[23:23:51] <dmlloyd> it's our #1 non-optional subsystem dep
[23:23:52] <ALR> JPA too.
[23:24:15] <dmlloyd> things that *can* exist without EE should be made to do so if EE isn't loaded
[23:24:18] <ALR> Though I have a feeling that my answer is so obvious, you're really asking another question entirely.
[23:24:30] <stuartdouglas> it should be doable
[23:24:34] <dmlloyd> ALR: not obvious to me - I"ve never tried
[23:24:36] <wolfc> I fear we have a problem with injection if weld is enabled
[23:24:45] <stuartdouglas> what problem?
[23:24:50] <ALR> dmlloyd: Ah cool.  Yeah, Weld has an SE mode.
[23:25:24] <wolfc> take a session bean for example, Weld instantiates it and injects it. I think the EE framework will over-inject it.
[23:25:58] <dmlloyd> then the question becomes - is such a mode desirable?  is there a use case for starting up, say, container devoid of anything EE related but maybe containing just weld or just JPA or something, using like raw MSC services or something like that
[23:26:15] <dmlloyd> or am I overreaching for use cases that don't exist
[23:26:19] <stuartdouglas> hmm, I worked around that for other component types by doing my own injection that ignores EE injection points
[23:27:05] <stuartdouglas> How did you work around this in AS6
[23:27:18] <stuartdouglas> or did it just inject twice and no one noticed?
[23:27:37] <aslak> asaldhan, you probably want to add @Run(RunModeType.AS_CLIENT) when doing e.g. Servlet endpoint testing. then Arquillian will execute the test in your normal jvm but perform the deployment
[23:28:02] <asaldhan> aslak: nice.
[23:28:12] <stuartdouglas> actually, do you mean the WeldInjectionFactory stuff?
[23:29:36] <asaldhan> aslak: thank you. that did the trick. :)
[23:29:37] <wolfc> in AS 6 Weld & EE work together in jboss-switchboard
[23:29:53] <wolfc> injection happens via an interceptors, so Weld can override the EE injector.
[23:31:23] *** bstansberry is now known as bstans_afk
[23:35:38] <wolfc> http://community.jboss.org/wiki/InjectionManagerinAS6
[23:35:38] *** frainone has quit IRC
[23:36:16] <stuartdouglas> I think it is actually ok, because weld will not inject the session beans itself
[23:36:28] <stuartdouglas> and WeldInjectionFactory only does CDI injection points, not EE ones
[23:37:18] <dmlloyd> wolfc: do we have an expected location to access SessionContext from a system interceptor for EJB invocations?
[23:37:28] <dmlloyd> from the instance I guess?
[23:37:31] *** pgier has quit IRC
[23:38:26] <wolfc> dmlloyd, I now have SessionBeanComponentInstance.getSessionContext()
[23:39:15] * dmlloyd is going to do a little more on JBAS-8979
[23:39:16] <jbossbot> jira [JBAS-8979] Rename "ejb3" subsystem to "ejb" [Open (Unresolved) Task, Minor, Unassigned] https://issues.jboss.org/browse/JBAS-8979
[23:39:19] <dmlloyd> er
[23:39:21] <dmlloyd> wrong one
[23:39:28] * dmlloyd is going to do a little more on JBAS-8978
[23:39:35] <jbossbot> jira [JBAS-8978] Complete async EJB invocation [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8978
[23:39:53] <wolfc> ah that one has some fine print as well
[23:40:25] <wolfc> 1. the tricky bit is having remote async invocations
[23:40:43] <wolfc> 2. async invocation is a client concern and thus should use a client side executor service
[23:40:52] <wolfc> 3. which is also why the API is wrong
[23:51:37] *** balunasj has quit IRC
[23:52:26] *** adietisheim1 has quit IRC
[23:54:03] *** balunasj has joined #jboss-as7
[23:54:03] *** balunasj has joined #jboss-as7
[23:54:03] *** ChanServ sets mode: +v balunasj
[23:54:52] <stuartdouglas> dmlloyd: I have a few minor fixes in my master that should be ready to pull
[23:55:25] <dmlloyd> wolfc: yeah the odd thing is, SessionContext.wasCancelCalled() and propagating cancellation requests.
[23:55:48] <dmlloyd> wolfc: this would be actually not too hard to set up on the client side, if not for that.  In fact there are a lot of advantages for doing so
[23:57:25] <wolfc> dmlloyd, my original thoughts were having the client create the Future and sending that

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