[00:09:14] *** maeste_afk has quit IRC
[00:09:54] *** maeste_afk has joined #jboss-as7
[00:11:20] *** jpederse has quit IRC
[00:11:21] *** maeste_afk has quit IRC
[00:11:34] *** kkhan has quit IRC
[00:11:53] *** maeste_afk has joined #jboss-as7
[00:13:01] *** opalka has quit IRC
[00:16:13] <jbossbot> git [jboss-as] push master 023dc7c.. bstansberry at jboss dot com Minor deployment handler cleanups
[00:16:13] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/946536b...023dc7c
[00:23:13] *** asaldhan has left #jboss-as7
[00:24:45] <dmlloyd> @Resource EJBContext
[00:24:49] <dmlloyd> we need to get that working too
[00:24:55] <dmlloyd> not just SessionContext
[00:28:17] *** maeste_afk has quit IRC
[00:32:44] <dmlloyd> we might need a new BindingSourceDescription
[00:33:15] <dmlloyd> it would be a "fallback" one for unqualified @Resource to be resolved at component install time by the component type, or something
[00:36:46] *** frainone has quit IRC
[00:39:44] *** rawblem has quit IRC
[00:45:57] *** jwulf has joined #jboss-as7
[00:58:01] *** bstansberry is now known as bstans_afk
[01:06:11] *** stuartdouglas has joined #jboss-as7
[01:06:11] *** ChanServ sets mode: +v stuartdouglas
[01:16:08] *** stuartdouglas has quit IRC
[01:30:49] *** maxandersen has quit IRC
[01:34:53] *** fnasser has quit IRC
[01:36:02] *** fnasser has joined #jboss-as7
[01:49:12] *** aslak has quit IRC
[01:50:13] *** bstans_afk is now known as bstansberry
[02:11:56] *** jwulf has quit IRC
[02:12:14] *** jwulf has joined #jboss-as7
[02:25:01] *** jpearlin has joined #jboss-as7
[02:26:07] *** fnasser has quit IRC
[02:30:28] *** pferraro has joined #jboss-as7
[02:30:28] *** ChanServ sets mode: +v pferraro
[02:31:24] *** jamezp has left #jboss-as7
[02:37:59] *** pferraro has quit IRC
[03:02:48] *** pgier has quit IRC
[03:04:26] <jpearlin> Nihility:  here is the file upload stuff with the modified boundary stream:  https://github.com/jdpgrailsdev/jboss-as/commit/21658c57e4d1135e2cdca98e20b484f245809be1
[03:04:27] <jbossbot> git [jboss-as] 21658c5.. Jonathan Pearlin Modified to remove POST request headers from extracted deployment....
[03:04:48] <jpearlin> I am still going to do a little more clean-up regarding the stream stuff, as I think it has some edge cases between reading the header and body
[03:04:56] <jpearlin> but it should be good enough to start playing with
[03:15:32] *** smarlow has quit IRC
[03:34:40] <ALR> Git pros:
[03:34:45] <ALR> I got a commit I wanna undo.
[03:35:00] <ALR> Revert will keep the history and add a new commit, applying the reverse diff
[03:35:08] <ALR> But I just wanna wipe the thing from ever having happened.
[03:35:28] <dmlloyd> git reset --hard xxxx
[03:35:32] <dmlloyd> where xxxx is the ID you want to go back to
[03:35:42] <ALR> Ah that's all?
[03:35:45] <dmlloyd> you're really backing up in time
[03:35:45] <ALR> I've done that.
[03:35:57] <dmlloyd> okay, had you pushed out the revision you don't want somewhere as well?
[03:36:14] <ALR> Nope.
[03:36:22] <dmlloyd> okay then you should be fine
[03:36:23] <ALR> When I do that, it's just a --force
[03:36:25] <ALR> Right?
[03:36:33] <ALR> If I had applied it remotely I mean.
[03:36:36] <dmlloyd> only if you are changing history somehow yeah
[03:36:38] <ALR> I'd have done:
[03:36:42] <dmlloyd> if you go backwards
[03:36:43] <ALR> git push origin master --force
[03:36:48] <dmlloyd> right
[03:36:50] <ALR> Coolio.
[03:36:54] <ALR> I thought there was more to it.
[03:36:55] <ALR> Thanks
[03:37:07] <ALR> git reset --hard HEAD^ is my friend.
[03:37:14] <dmlloyd> yeah
[03:37:27] <dmlloyd> for some reason I never use that syntax, I always use the ID
[03:38:00] <ALR> You're probably better off that way
[03:50:03] <ALR> SW 1.0.0-alpha-12 is getting cut.
[03:50:13] <ALR> So I'll update AS7.
[03:50:30] <ALR> Unless of course, ARQ mandates that the previous version be used.
[03:50:40] <ALR> And an ARQ release should be out soon.
[03:55:29] <dmlloyd> progress
[04:01:44] *** mbg has joined #jboss-as7
[04:01:44] *** ChanServ sets mode: +v mbg
[04:02:45] *** jpearlin has left #jboss-as7
[04:04:17] *** ALR has quit IRC
[04:11:56] *** mbg has quit IRC
[04:13:35] *** ALR has joined #jboss-as7
[04:13:35] *** ChanServ sets mode: +v ALR
[05:49:48] *** echelog-2 has joined #jboss-as7
[06:00:43] *** echelog-2 has joined #jboss-as7
[06:58:58] *** jwulf has joined #jboss-as7
[07:55:22] *** bstansberry has quit IRC
[08:06:29] *** jfclere has joined #jboss-as7
[08:06:29] *** ChanServ sets mode: +v jfclere
[08:11:02] *** mbg is now known as mbg|away
[08:16:50] *** jwulf has quit IRC
[08:17:36] *** miclorb_ has quit IRC
[08:19:30] *** Jaikiran has joined #jboss-as7
[08:19:30] *** ChanServ sets mode: +v Jaikiran
[08:22:40] *** adietisheim has joined #jboss-as7
[08:36:27] *** miclorb_ has joined #jboss-as7
[08:41:32] *** opalka has joined #jboss-as7
[08:41:32] *** opalka has joined #jboss-as7
[08:41:32] *** ChanServ sets mode: +v opalka
[08:42:15] <opalka> morning
[08:58:20] *** asoldano has joined #jboss-as7
[08:58:20] *** ChanServ sets mode: +v asoldano
[09:05:07] *** mbg|away is now known as mbg
[09:12:24] *** emmanuel has joined #jboss-as7
[09:12:24] *** ChanServ sets mode: +v emmanuel
[09:14:45] <nickarls> moaning
[09:19:43] *** tdiesler has joined #jboss-as7
[09:19:44] *** ChanServ sets mode: +v tdiesler
[09:23:22] *** wolfc has joined #jboss-as7
[09:23:22] *** ChanServ sets mode: +v wolfc
[09:38:23] *** jma has joined #jboss-as7
[09:39:04] *** JimMa has joined #jboss-as7
[09:40:31] *** Jaikiran has quit IRC
[09:45:05] *** Jaikiran has joined #jboss-as7
[09:45:06] *** ChanServ sets mode: +v Jaikiran
[09:45:51] *** miclorb_ has quit IRC
[10:05:55] *** jhalliday has joined #jboss-as7
[10:21:26] *** alesj has joined #jboss-as7
[10:21:27] *** aslak has joined #jboss-as7
[10:21:50] *** aslak has quit IRC
[10:21:50] *** aslak has joined #jboss-as7
[10:21:50] *** ChanServ sets mode: +v aslak
[10:28:46] *** opalka has quit IRC
[10:32:21] *** miclorb has joined #jboss-as7
[10:33:10] *** emuckenhuber has quit IRC
[10:36:09] *** Jaikiran has quit IRC
[10:37:49] <adietisheim> hi guys, is there any more recent (ex. nightly) binary release of AS7 than the one on jboss.org i could use?
[10:40:26] *** maeste has joined #jboss-as7
[10:40:27] *** ChanServ sets mode: +v maeste
[10:40:36] <alesj> adietisheim: clone it from github and simply build it
[10:40:57] <alesj> or, hmmm, i would guess Hudson should have some
[10:42:07] <wolfc> http://hudson.jboss.org/hudson/view/JBoss%20AS/
[10:42:20] <wolfc> Not sure why the windows variant is failing though.
[10:42:46] <wolfc> Oh it's missing a git installation.
[10:42:53] <wolfc> Probably the normal build will suffice.
[10:43:39] <adietisheim> wolfc: great! thanks! since I shall start doing tools I guessed it would be best to use latest and greatest ;)
[10:45:01] <adietisheim> alesj: sure, could check out but honestly I'd love to stick to the bare minimum I need so binary is perfect for now
[10:47:00] <alesj> np
[10:51:42] *** Darran_L has joined #jboss-as7
[11:02:11] *** emuckenhuber has joined #jboss-as7
[11:02:11] *** emuckenhuber has joined #jboss-as7
[11:02:11] *** ChanServ sets mode: +v emuckenhuber
[11:12:21] *** jcosta has joined #jboss-as7
[11:12:21] *** ChanServ sets mode: +v jcosta
[11:19:12] *** Darran_L has quit IRC
[11:25:35] *** Darran_L has joined #jboss-as7
[11:26:16] *** kkhan has joined #jboss-as7
[11:26:16] *** ChanServ sets mode: +v kkhan
[11:27:37] *** AndyTaylor has joined #jboss-as7
[11:27:37] *** ChanServ sets mode: +v AndyTaylor
[11:29:53] *** Darran_L has quit IRC
[11:44:48] *** opalka has joined #jboss-as7
[11:44:48] *** opalka has joined #jboss-as7
[11:44:48] *** ChanServ sets mode: +v opalka
[11:52:05] <wolfc> Hmm, per Component instance interceptors is not available.
[11:52:40] *** rmaucher has joined #jboss-as7
[11:53:33] <wolfc> The problem is that org.jboss.invocation.Interceptor doesn't have lifecycle callbacks.
[11:55:00] *** Jaikiran has joined #jboss-as7
[11:55:00] *** ChanServ sets mode: +v Jaikiran
[11:56:08] <wolfc> Ah the componentInterceptor is created too soon.
[11:59:03] <Jaikiran> wolfc: oh looks like you are looking at interceptors too
[11:59:14] <wolfc> yeah, I'm missing features
[11:59:20] <Jaikiran> wolfc: i might be missing something but from what i gather, the component intereceptors run client side
[11:59:21] <wolfc> (11:50:24 AM) wolfc: Hmm, per Component instance interceptors is not available.
[11:59:26] <wolfc> (11:51:52 AM) wolfc: The problem is that org.jboss.invocation.Interceptor doesn't have lifecycle callbacks.
[11:59:44] <wolfc> Keep remote out of scope
[11:59:47] <wolfc> for the moment
[12:00:07] <Jaikiran> ah ok
[12:00:10] <wolfc> (remote) client side should never have a direct association with Component
[12:00:16] <Jaikiran> right
[12:00:30] <Jaikiran> that's what was confusing me
[12:03:38] *** miclorb has quit IRC
[12:14:59] <wolfc> Jaikiran, https://github.com/wolfc/jboss-as/tree/component-interceptor
[12:15:05] *** stalep has joined #jboss-as7
[12:18:24] *** emmanuel has quit IRC
[12:19:37] *** JimMa has quit IRC
[12:19:55] <Jaikiran> wolfc: I guess you needed this change because you were adding some system component interceptor factory a bit later than the componentInterceptor creation?
[12:20:19] <wolfc> Jaikiran, no I need the component instance in the interceptor itself
[12:20:48] <wolfc> all the current interceptors are VM lifecycle bound
[12:20:51] <Jaikiran> wolfc: that required by most of our interceptors now. and we kind of hack it in the createClientInterceptors
[12:20:56] <wolfc> I want Component lifecycle bound
[12:21:24] <wolfc> Do not confuse with ComponentInstance lifecycle bound :-)
[12:21:58] <Jaikiran> i have always been confused by the various different ways the "component" term is being used
[12:22:01] <Jaikiran> :)
[12:22:20] <Jaikiran> sometimes for the component instance and sometimes for the component (previously known as containers)
[12:23:05] <Jaikiran> for example, we use "componentClass" as a reference to the bean impl class
[12:23:38] <wolfc> ^ you are making the mistake again of Component instance vs ComponentInstance instance :-)
[12:23:51] <Jaikiran> ha ha :) let me try and understand that
[12:25:11] <Jaikiran> ok let's take an example
[12:25:22] <wolfc> In my old job, we used a mnemonic for this kind of situations: from now on we call Component instance a 'Mars' and ComponentInstance instance a 'Snickers' :-)
[12:25:34] <Jaikiran> yeah, that would make this easier :)
[12:27:53] <wolfc> https://github.com/wolfc/jboss-as/tree/component-interceptor now with ComponentInterceptorFactory
[12:32:06] *** epbernard has joined #jboss-as7
[12:32:06] *** epbernard is now known as emmanuel
[12:32:07] *** ChanServ sets mode: +v emmanuel
[12:32:15] *** asoldano is now known as asoldano_lunch
[12:32:16] <Jaikiran> WIP? because i don't see a call to those factories on component creation
[12:33:50] *** darranl has joined #jboss-as7
[12:33:50] *** darranl has joined #jboss-as7
[12:33:50] *** ChanServ sets mode: +v darranl
[12:35:01] <wolfc> Yes, I'm not mudding it up with actual EJB stuff :-)
[12:35:21] <wolfc> s/not/now/ :-)
[12:36:18] <Jaikiran> ok :)
[12:36:53] *** Darran_L has joined #jboss-as7
[12:41:20] *** Darran_L has quit IRC
[12:47:27] *** maxandersen has joined #jboss-as7
[12:47:27] *** ChanServ sets mode: +v maxandersen
[13:10:30] <maxandersen> emuckenhuber: do you know if alexey's latest cli fixes made it into master yet?
[13:16:39] <wolfc> MB race failure: https://gist.github.com/a65f33bfa10e9393e52d
[13:24:31] <emuckenhuber> maxandersen: not yet
[13:30:17] *** maxandersen has quit IRC
[13:30:45] *** maxandersen has joined #jboss-as7
[13:30:46] *** ChanServ sets mode: +v maxandersen
[13:48:23] *** Jaikiran has quit IRC
[13:49:12] *** Jaikiran has joined #jboss-as7
[13:49:12] *** ChanServ sets mode: +v Jaikiran
[13:57:51] *** balunasj has joined #jboss-as7
[13:57:51] *** ChanServ sets mode: +v balunasj
[13:59:00] *** tdiesler has quit IRC
[14:00:07] *** balunasj has quit IRC
[14:00:08] *** asoldano_lunch is now known as asoldano
[14:01:03] *** tdiesler has joined #jboss-as7
[14:01:04] *** ChanServ sets mode: +v tdiesler
[14:09:31] *** balunasj_mtg has joined #jboss-as7
[14:11:11] <dmlloyd> good morning
[14:11:41] <opalka> morning, would U cherry pick and apply upstream https://github.com/ropalka/jboss-as/commit/7b0cf26 ?
[14:11:42] <jbossbot> git [jboss-as] 7b0cf26.. Richard Opalka [JBWS-3245] fixing JBossWS AS7 RemoteDeployer bug - always uninstall deployed archives
[14:11:43] <jbossbot> jira [JBWS-3245] AS7 RemoteDeployer have to always undeploy deployed archives [Open (Unresolved) Sub-task, Major, Richard Opalka] https://issues.jboss.org/browse/JBWS-3245
[14:13:04] <dmlloyd> baileyje: looks good!
[14:13:31] <opalka> dmlloyd, thanks in advance
[14:14:19] *** frainone has joined #jboss-as7
[14:14:19] *** ChanServ sets mode: +v frainone
[14:14:55] <tdiesler> dmlloyd, with msc beta6 the osgi framework hangs on shutdown when started in its own process
[14:14:55] <dmlloyd> will do opalka
[14:15:01] <tdiesler> the process never returns
[14:15:03] <dmlloyd> wolfc / Jaikiran - everything OK?
[14:15:22] <rmaucher> so I redid the web annotation processing code with jandex: https://github.com/rmaucher/jboss-as/commit/65375f76e5bc575be7d8999314342777118e90ed
[14:15:23] <jbossbot> git [jboss-as] 65375f7.. Rémy Maucherat Redo web annotation processing using jandex rather than reflection. Passes smoke tests.
[14:15:26] <dmlloyd> tdiesler: can you try it with the latest snapshot?  frainone did identify and fix a number of bugs
[14:15:26] <Jaikiran> dmlloyd: so far, yes. i'll get some @Singleton changes in, in some time
[14:15:39] <Jaikiran> dmlloyd: wolfc has some changes for component interceptors
[14:15:48] <tdiesler> dmlloyd, as a result we cannot run the TCK anymore. ok, will do
[14:15:55] <rmaucher> it looks ok so far, but I did not test the TCK, I expect a few regressions that will be fixed
[14:16:04] <wolfc> https://github.com/wolfc/jboss-as/tree/component-interceptor
[14:16:09] <dmlloyd> rmaucher: ok will check it out
[14:16:14] <wolfc> wicked as ever :-)
[14:16:26] <dmlloyd> baileyje: is yours ready to merge?  or was there something you wanted to chat about first?
[14:16:30] <rmaucher> thanks
[14:16:45] <wolfc> But the pull request might be a bit more urgent, a bug in upstream.
[14:17:02] <rmaucher> doing annotation processing with jandex is NPE friendly, because it doesn't do default values ;)
[14:17:15] <rmaucher> so that's the main risk
[14:18:53] <rmaucher> dmlloyd, thanks
[14:19:51] <dmlloyd> wolfc: why is this necessary?  you could just use your ComConfig subclass to construct whatever interceptor you want
[14:20:54] * opalka 's impressed that AS7 trunk boots for him 24% faster than 2 weeks older branch
[14:21:14] <wolfc> dmlloyd, let me finish up the tx interceptors, then we can see if it is refactorable
[14:21:58] <jbossbot> git [jboss-as] push master 697056e.. Richard Opalka [JBWS-3245] fixing JBossWS AS7 RemoteDeployer bug - always uninstall deployed archives
[14:22:01] <jbossbot> jira [JBWS-3245] AS7 RemoteDeployer have to always undeploy deployed archives [Open (Unresolved) Sub-task, Major, Richard Opalka] https://issues.jboss.org/browse/JBWS-3245
[14:22:01] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/023dc7c...697056e
[14:22:13] <opalka> dmlloyd, thanks ;)
[14:23:35] <tdiesler> dmlloyd, could you pls pull my stuff that fixes all the smoke tests
[14:23:39] <dmlloyd> wow - revision 65375f76e5bc575be7d8 is now ambiguous
[14:23:54] <dmlloyd> tdiesler: what's the branch?
[14:24:08] <dmlloyd> tdiesler: jbosgi?  did you remove the change which rolls the JSF version back?
[14:24:14] <tdiesler> dmlloyd, as always: jbosgi
[14:24:45] <tdiesler> https://github.com/jbosgi/jboss-as/tree/jbosgi
[14:25:28] <tdiesler> dmlloyd, that is still in there. I couldn't build otherwise
[14:25:44] <dmlloyd> tdiesler, okay according to the experts it's a problem in your settings.xml
[14:25:48] <maxandersen> maan … I really wish deployments weren't persisted in standalone.xml…having to handedit standalone.xml to make AS 7 not freeze is quirky….;)
[14:25:52] <dmlloyd> everyone else seems to be able to build
[14:26:43] <tdiesler> dmlloyd, where do they get the javax.faces stuff from if it is not in public jboss?
[14:26:53] <rmaucher> maybe it's because I rebased https://github.com/rmaucher/jboss-as/commit/e26910532b3b8ad419ede27915bf6bcc52d9b3a5
[14:26:54] <jbossbot> git [jboss-as] e269105.. Rémy Maucherat Redo web annotation processing using jandex rather than reflection. Passes smoke tests.
[14:27:18] <tdiesler> dmlloyd, let me see perhaps it was a tmp hickup on central
[14:27:41] <maxandersen> emuckenhuber: so…where are the actual jars used to run the server at ? :) find . -name *.jar gives nothing....
[14:28:26] <dmlloyd> tdiesler: it's in the "public" group, not the "public-jboss" group
[14:28:32] <emuckenhuber> maxandersen: $JBOSS_HOME/modules/*
[14:28:33] <maxandersen> emuckenhuber: ignore me ;) …"*.jar" works so much better. darn root jars ;)
[14:28:36] <Jaikiran> maxandersen: under modules folder,
[14:28:37] <dmlloyd> tdiesler: we are going to look at using the jboss API jar in any case
[14:29:34] <maxandersen> emuckenhuber: okey - and if outsideres were to understand which jars are exposed to a users deployment …how does one figure that out?
[14:29:47] <opalka> dmlloyd, Do U already know about this NPE? - http://fpaste.org/jNMu/
[14:31:09] <jbossbot> git [jboss-as] push master 9110459.. Rémy Maucherat Always set the cross context flag (it shouldn't hurt)
[14:31:09] <jbossbot> git [jboss-as] push master e269105.. Rémy Maucherat Redo web annotation processing using jandex rather than reflection. Passes smoke tests.
[14:31:09] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/697056e...e269105
[14:31:21] <dmlloyd> opalka: yes, it's fixed in the MSC upstream
[14:31:35] <opalka> dmlloyd, thx for info
[14:31:43] <dmlloyd> thanks for the report
[14:31:56] <dmlloyd> okay, anyone else?
[14:32:53] <tdiesler> dmlloyd, https://github.com/jbosgi/jboss-as/commit/81ec4e000e10f49d0d117496dab366e1eec0a434
[14:32:54] <jbossbot> git [jboss-as] 81ec4e0.. Thomas Diesler [JBAS-8932] Restore jsf-api-2.0.4-b09
[14:32:55] <jbossbot> jira [JBAS-8932] weld subsystem build fails on unsatisfied javax.faces dependency [Resolved (Won't Fix) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-8932
[14:33:10] <dmlloyd> thanks tdiesler
[14:33:43] <emuckenhuber> maxandersen: well the deployers setup the module classpath for a deployment - so reference modules not .jars usually
[14:34:02] <rmaucher> ok, thanks, I'll run the TCK in Hudson and fix any regressions
[14:34:39] <maxandersen> emuckenhuber: okey? so how does users know which jars are "active" ? and anyway we can figure it out or at least some "best guess" ?
[14:35:47] <jbossbot> git [jboss-as] push master eec4b19.. Thomas Diesler Sync CDI dependency on Arquillian
[14:35:47] <jbossbot> git [jboss-as] push master 25441d5.. Thomas Diesler Switch to explicit excludes for smoke tests
[14:35:47] <jbossbot> git [jboss-as] push master def20c7.. Thomas Diesler [JBAS-8932] weld subsystem build fails on unsatisfied javax.faces dependency
[14:35:48] <jbossbot> jira [JBAS-8932] weld subsystem build fails on unsatisfied javax.faces dependency [Resolved (Won't Fix) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-8932
[14:35:48] <jbossbot> git [jboss-as] push master 247ad3f.. Thomas Diesler Seperate smoke test executions into profiles
[14:35:48] <jbossbot> git [jboss-as] push master ef42e05.. Thomas Diesler Restore ArchiveProvider functionality in modular smoke tests
[14:35:49] <jbossbot> git [jboss-as] push master dacd22a.. Thomas Diesler Restore OSGi and ConfigAdmin smoke tests...
[14:35:49] <jbossbot> git [jboss-as] push master e4474af.. Thomas Diesler [JBAS-8932] Restore jsf-api-2.0.4-b09
[14:35:49] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e269105...e4474af
[14:36:03] *** smarlow has joined #jboss-as7
[14:36:04] *** ChanServ sets mode: +v smarlow
[14:36:41] *** bobmcw has joined #jboss-as7
[14:36:42] <emuckenhuber> dmlloyd: btw. since on the topic - do we plan to add some java EE path filters to deployments... so in case they contain some spec .jars that it does not blow up?
[14:36:42] *** ChanServ sets mode: +v bobmcw
[14:36:55] <dmlloyd> emuckenhuber: I do, but not until after the Beta1 release
[14:37:00] <dmlloyd> it's on the list
[14:37:05] <dmlloyd> well, someone will :)
[14:37:32] <emuckenhuber> ok, because basically every deployment i tried contained a spec .jar and blew up hehe
[14:37:51] <emuckenhuber> dmlloyd: oh, and is there a plan to make VFS case sensitive - looks like that's not the case?
[14:38:10] <emuckenhuber> since Sacha once complained that hudson does not deploy - i tried it again
[14:38:17] <dmlloyd> VFS is case sensitive unless you have a filesystem deployment on a case-insensitive filesystem
[14:38:25] <tdiesler> dmlloyd, still hangs with the latest msc snapshot
[14:38:30] <dmlloyd> I don't have any opinion about that
[14:38:45] <dmlloyd> tdiesler: okay can you get some data like services snapshot, thread stack traces etc?
[14:38:55] <emuckenhuber> dmlloyd: well the hudson stuff blew up - because they have package names "hudson/model/Queue" and "hudson/model/queue"
[14:39:26] <dmlloyd> emuckenhuber: as long as it's in a JAR it should work afaik
[14:39:46] <tdiesler> dmlloyd, I verified that there are no services in the registry
[14:39:52] <dmlloyd> emuckenhuber: might be worth looking into, could be a bug
[14:39:53] <tdiesler> dmlloyd, http://pastie.org/1655570
[14:40:30] <rmaucher> dmlloyd: there needs to be a flag somewhere (as in VFS 2) to enable case sensitivity, otherwise the web impl will not be secure
[14:40:39] <dmlloyd> tdiesler: did you remember to shut down the container?
[14:40:57] <Jaikiran> dmlloyd: emuckenhuber: -Djboss.vfs.forceCaseSensitive=true
[14:41:04] <Jaikiran> i believe that's false by default
[14:41:12] <alesj> Jaikiran: thta was for VFS2
[14:41:24] <Jaikiran> i see
[14:41:28] <alesj> VFS3 doesn't have that anymore
[14:41:30] <rmaucher> yes VFS 2 only, which actually had a per VFS flag, that was nice
[14:41:32] *** jpederse has joined #jboss-as7
[14:41:41] *** jpederse has quit IRC
[14:41:41] *** jpederse has joined #jboss-as7
[14:41:42] <opalka> dmlloyd, how about this NPE? - http://fpaste.org/pZns/
[14:41:44] <tdiesler> dmlloyd, possibly not. Is that a new API?
[14:41:50] <emuckenhuber> dmlloyd: well i just stopped that the JavaZipFileSystem gets the children with token.toLowerCase();
[14:42:31] <dmlloyd> tdiesler: no, it's pretty old, but now the MSC thread pool is managed by MSC and they're non-daemon threads so if you don't shut down the container, the VM won't terminate (unless you do System.exit())
[14:43:08] <tdiesler> dmlloyd, ok - let me check that
[14:43:12] <dmlloyd> opalka: I take it back, both of those are problems in some EE component (servlet I guess?)
[14:43:30] <opalka> dmlloyd, OK, I'll track them down. NP
[14:44:52] <emuckenhuber> maxandersen: you can figure out the module dependencies dependencies during runtime - also for deployments, but i'm not sure if that would help you? because it's basically the deployers who determine what a deployment should see or not
[14:46:35] <emuckenhuber> dmlloyd: i'm was referring to this line: https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/vfs/spi/JavaZipFileSystem.java#L117
[14:46:51] <dmlloyd> ah
[14:46:55] <dmlloyd> I had forgotten about that business
[14:46:58] <asoldano> opalka, dmlloyd those seems to me exactly the same I asked stuart about
[14:47:16] <asoldano> opalka, dmlloyd he said he's working on them and might have fixed locally
[14:47:19] <dmlloyd> emuckenhuber: yeah that is a bug I think.
[14:47:34] <opalka> asoldano, thanks for info
[14:47:36] <dmlloyd> emuckenhuber: is there a JIRA for the issue?
[14:47:54] <emuckenhuber> dmlloyd: i don't think so
[14:48:09] <asoldano> opalka, I didn't create a jira as he seemed to be fixing quickly...
[14:49:52] <wolfc> How do I inject EJBUtilities into EJBComponent?
[14:50:56] <dmlloyd> wolfc: use a BindingDescription to create the dependency, using the service binding source description
[14:51:03] <dmlloyd> wolfc: I know it seems counter-intuitive :)
[14:51:09] <dmlloyd> that'll set up the dependency
[14:51:35] <dmlloyd> really though we probably need a nice general mechanism on the config
[14:51:47] <jfclere> rmaucher: dmlloyd:  JBVFS-170?
[14:51:48] <jbossbot> jira [JBVFS-170] Support for -Djboss.vfs.forceCaseSensitive=true [Open (Unresolved) Feature Request, Minor, John Bailey] https://issues.jboss.org/browse/JBVFS-170
[14:51:50] <dmlloyd> like a Map<ServiceName, InjectedValue>
[14:52:23] <dmlloyd> jfclere: ah that's it.  It was unscheduled, that's why I couldn't find it...
[14:52:41] <dmlloyd> let me reframe the problem - is there ever a time where we do NOT want case sensitivity?
[14:52:41] *** bstansberry has joined #jboss-as7
[14:52:41] *** ChanServ sets mode: +v bstansberry
[14:52:56] <wolfc> EJBUtilities isn't coming in over JNDI, neither do I want it injected into the ComponentInstance
[14:53:03] <wolfc> .instance
[14:53:27] <tdiesler> dmlloyd, hangs with latest snapshot after srvreg shutdown is complete. http://pastie.org/1655615
[14:53:27] <dmlloyd> wolfc: yeah, BindingDescription can create dependencies on services, without binding to JNDI
[14:53:37] <dmlloyd> wolfc: and without injecting into an instance
[14:54:02] <dmlloyd> tdiesler: look for non-terminated MSC Service Threads
[14:54:29] <wolfc> that's really ugly and only takes care of the dependency
[14:54:36] <dmlloyd> yes
[14:54:40] <dmlloyd> I acknowledge that
[14:55:12] <dmlloyd> that's why I suggested maybe having a Map<ServiceName, InjectedValue> on CompConfig and/or CompDescr
[14:56:18] <rmaucher> case sensitivity is slower (you need the canonical path of a file for the check)
[14:56:35] <tdiesler> dmlloyd, I see 5 of them waiting on some condition http://pastie.org/1655625
[14:56:49] <jfclere> dmlloyd: well the issue is find the OS that don't have it, we always need it.
[14:57:56] <wolfc> not, Map<ServiceName, Injector> ?
[14:57:57] <maxandersen> emuckenhuber: well…how can I as a user see which jars are loaded without having to introspect the classloader at runtime from within my jar/war ? :) In "old" days looking in the lib/ folder gave an idea..now its kinda spread out…so just wondering how to get such info from AS…is it available in the model somewhere?
[14:58:10] <tdiesler> dmlloyd, maybe this one is fishy http://pastie.org/1655633
[14:58:42] <dmlloyd> that's a daemon thread, tdiesler
[14:59:10] <dmlloyd> wolfc: well if it's InjectedValue then that'll eliminate duplicates as everyone can easily use InjectedValue
[14:59:51] <wolfc> This is what I had some time ago: https://github.com/wolfc/jboss-as/blob/naming-comp/ee/src/main/java/org/jboss/as/ee/component/injection/ComponentResourceInjectionConfiguration.java
[15:00:18] <bstansberry> wolfc: did anyone pull your ArrayKey patch?
[15:00:23] <bstansberry> good morning everyone
[15:01:14] <wolfc> bstansberry, doesn't appear to be
[15:01:39] <bstansberry> ok, I have my initial while-caffeinating task
[15:02:35] <tdiesler> dmlloyd, the pool-x-thread-y threads that are WAITING (parking) are not critical either, are they?
[15:02:55] <wolfc> I think ComponentInjector is a badly named it should be ComponentInstanceInjector
[15:03:28] <dmlloyd> if they don't say "daemon" next to the name, tdiesler, then they're preventing the container from terminating.  The MSC snapshot names all of its threads "MSC service thread" though.
[15:04:17] *** AndyTaylor has quit IRC
[15:04:27] <tdiesler> dmlloyd, there are none "MSC ..." threads
[15:05:17] *** pgier has joined #jboss-as7
[15:05:17] *** ChanServ sets mode: +v pgier
[15:05:46] <jbossbot> git [jboss-as] push master 52fbe7d.. Carlo de Wolf Fixed silly equals on ArrayKey
[15:05:46] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e4474af...52fbe7d
[15:07:09] <wolfc> thx
[15:09:09] <dmlloyd> rmaucher: the case-insensitivity for exploded deployments is actually a separate issue from case-insensitivity in JAR deployments - the latter is definitely a bug.  The former should be supported though...
[15:10:00] <rmaucher> ok
[15:11:25] <bstansberry> tdiesler: I bet it's from the ServerControllerImpl; give me a minute to do some cleanup
[15:12:05] <tdiesler> dmlloyd, so its those pool-x-thread-y threads http://pastie.org/1655625
[15:12:35] <tdiesler> bstansberry, it hangs in the standalone osgi framework already, no AS code involved
[15:13:05] <bstansberry> oh, ic
[15:13:20] <bstansberry> well, I think I need to do cleanup anyway ;)
[15:13:31] <emuckenhuber> maxandersen: afaik there is an modules mbean which gives you some information - however a .jar alone does not tell you much about the visibility rules on a classloader
[15:13:49] <dmlloyd> tdiesler: so some framework is creating a thread pool and not cleaning it up.  This is why thread pools should always use a thread factory which assigns a name to the threads
[15:14:01] <dmlloyd> otherwise it's hard to know who created it
[15:14:34] <tdiesler> dmlloyd, ok this is a lead - let me see
[15:15:46] <maxandersen> emuckenhuber: how would I get to that modules mbean ?
[15:17:54] <emuckenhuber> maxandersen: there are some mbeans registered under "jboss.modules"
[15:20:11] <maxandersen> emuckenhuber: ok - so need jmx - not available via the thttp api?
[15:25:07] *** balunasj_mtg has quit IRC
[15:29:02] <baileyje>  dmlloyd It was ready for review and merge if it looked ok to you.
[15:29:28] <dmlloyd> baileyje: ok, it looks good to me
[15:29:35] <dmlloyd> I'll merge it in a minute
[15:29:37] <baileyje> yeah.  IT can be merged.
[15:30:13] <dmlloyd> baileyje: next most important I think is to help out Nihility and smarlow with JPA in any way necessary
[15:31:35] <smarlow> baileyje, Nihility:  we talked last night about the need for some EJB3 interceptors
[15:33:17] <baileyje> smarlow: What are still needed?
[15:33:32] <smarlow> baileyje, Nihility:  I'm not sure if Nihility started anything yet.  I pushed some changes this morning
[15:34:15] <smarlow> baileyje: I pushed a SFSBCallStack
[15:34:19] <baileyje> dmlloyd: We also need to reenable non "lookup" based managed bean injection
[15:34:23] <smarlow> that the interceptors will use
[15:34:53] <dmlloyd> baileyje: did we lose that somehow?
[15:35:06] <baileyje> Yeah.  over a month ago.
[15:35:43] <baileyje> There used to be a processor that would find resource injections that did not have a target set and would determine if they were managed beans
[15:35:49] <baileyje> It was removed at some point.
[15:36:00] <baileyje> I would have needed to be rewritten anyway
[15:36:14] <baileyje> since it was depending on refactored EE bits
[15:36:20] <smarlow> wolfc:  when you have a chance, could you peak at org.jboss.as.jpa.spi.BeanContextHandle to see if that is going to work for referencing session beans?
[15:36:43] <baileyje> basically we need to be able to handle "@Resource private SomeManagedBean bean;"
[15:36:46] <wolfc> smarlow, do you have an URL handy?
[15:36:53] <smarlow> yep, 1 sec :)
[15:37:22] <wolfc> you only want to reference SFSB, not?
[15:37:37] <smarlow> wolfc:  https://github.com/scottmarlow/jboss-as/blob/master/jpa/src/main/java/org/jboss/as/jpa/spi/BeanContextHandle.java
[15:38:12] <wolfc> why a weak reference?
[15:38:54] <smarlow> wolfc:  I was worried about impacting life cycle management of SFSBs, since I heard talk of using the GC for that :)
[15:39:13] <wolfc> smarlow, SFSBs have a well defined lifecycle
[15:39:21] <smarlow> if that is not the case, I would rather avoid polluting the reference list :)
[15:39:45] <wolfc> The JPA interceptor should listen to @PreDestroy and clean up on that.
[15:40:08] <wolfc> Hmm, although the spec doesn't guarantee that @PreDestroy is called
[15:40:13] <smarlow> wolfc:  sure and if the app developer doesn't specify a @remove?
[15:40:39] <smarlow> I didn't want to keep the bean in memory :)
[15:40:40] <wolfc> smarlow, our container will still call @PreDestroy when it is time to die
[15:41:01] <smarlow> okay, so, you don't rely on GC, cool.  I'll remove the reference...
[15:42:18] * smarlow that should save a bunch of cpu cycles from being wasted on the reference queue :)
[15:50:23] *** AndyTaylor has joined #jboss-as7
[15:50:23] *** ChanServ sets mode: +v AndyTaylor
[15:50:59] *** smcgowan has joined #jboss-as7
[15:50:59] *** ChanServ sets mode: +v smcgowan
[15:58:06] <smarlow> wolfc:  Yes, I think we can avoid referencing SLSB at this point.  So, only need SFSBs
[16:00:32] <smarlow> wolfc:  https://github.com/scottmarlow/jboss-as/blob/master/jpa/src/main/java/org/jboss/as/jpa/spi/BeanContextHandle.java removed the Reference and mentions SFSB in the comments.
[16:00:42] *** fnasser has joined #jboss-as7
[16:01:15] <smarlow> wolfc: the trick will be implementing it :)
[16:02:07] *** frainone has quit IRC
[16:02:42] <wolfc> Shouldn't be too hard :-) https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/stateful/StatefulSessionComponentInstance.java
[16:03:11] <wolfc> How do we handle hard dependencies of this nature?
[16:04:50] <smarlow> wolfc, dmlloyd:  Shouldn't JPA just reference the EJB3 classes directly?  Or do we need a component level abstraction?
[16:05:44] <smarlow> probably the same question for the JPA interceptors for SFSB instances and SFSB lifecycle
[16:07:23] <dmlloyd> baileyje: that seems very similar to resolving unqualified @EJB to me.  You could probably use the same mechanism for it
[16:07:45] <baileyje> Yeah.  Possibly..
[16:08:01] <baileyje> That was basically my plan.  Just requires a bit of fun..
[16:08:38] <baileyje> since you may not know the reference is a managed bean without looking at the annotation index
[16:11:40] <wolfc> the annotation index should not be leading
[16:12:03] <smarlow> wolfc:  I'm not sure myself, dmlloyd should probably answer whether JPA can reference EJB3 directly.  I haven't heard of any restriction on hard dependencies.
[16:12:05] <wolfc> other processors might have added a MB (or EJB or whatever)
[16:12:22] <dmlloyd> for now, sure
[16:12:41] <dmlloyd> we don't have a comprehensive solution for inter-DUP dependencies
[16:12:51] <dmlloyd> it does need to be revisited though
[16:12:55] *** bstansberry is now known as bstans_afk
[16:13:32] <smarlow> dmlloyd, wolfc:  lets add the hard coded ejb3 dependencies now then and abstract them out to a common layer later or never.  which ever happens :)
[16:13:36] <baileyje> Can we assume if it is not a standard resource type, it is a component of some type?
[16:13:47] <ccrouch> random question
[16:13:49] <dmlloyd> baileyje: you should be able to look in the component index to see if there's some component with that name, and do instanceof checks maybe, or perhaps use AbstractComponentDescription.getViewClassNames()
[16:13:57] <ccrouch> is there still going to be /farm in jbas7 ?
[16:14:09] <dmlloyd> baileyje: no, we can't because there are some component-specific unqualified types like EJBContext
[16:14:14] <dmlloyd> ccrouch: no
[16:14:21] <ccrouch> dmlloyd: thank you sir
[16:21:02] *** smarlow has quit IRC
[16:22:20] *** emmanuel has quit IRC
[16:22:38] *** epbernard1 has joined #jboss-as7
[16:22:38] *** epbernard1 is now known as emmanuel
[16:22:38] *** ChanServ sets mode: +v emmanuel
[16:22:44] *** emmanuel has quit IRC
[16:22:44] *** emmanuel has joined #jboss-as7
[16:22:44] *** verne.freenode.net sets mode: +v emmanuel
[16:24:43] *** smarlow has joined #jboss-as7
[16:24:43] *** ChanServ sets mode: +v smarlow
[16:27:41] *** opalka has quit IRC
[16:29:25] <wolfc> dmlloyd, smoke-tests are passing on https://github.com/wolfc/jboss-as/commits/ejb3-ee. Let's talk about how I made a mess of things :-)
[16:33:56] <baileyje> smarlow: Are there any JPA related tasks you want me to assist on?
[16:37:51] *** bstans_afk is now known as bstansberry
[16:37:51] <smarlow> baileyje:  sure, I need two EJB3 interceptors.  Nihility might of looked at doing them already but I'm not sure.  One needs to be a SFSB lifecycle (need to know when @remove happens).  The other needs to be a SFSB instance interceptor (some details are in IRC history, I'll grab them and paste :)).
[16:40:20] <wolfc> The XPC needs to be aware of SFSB lifecycle, the tx EM needs to work over every EJB.
[16:46:25] <smarlow> wolfc:  I was talking to rmaucher about not doing the ManagedEntityManagerFactory.nonTxStack dance and instead aggressively closing the PC EM after each EM method call.  That is for the non transactional case only and eliminates the need for one interceptor in EJB3 + WEB land.  I'm fine with doing that and considering a future optimization to bring an interceptor in if we need to.  Do you recall any history that disagrees with me doing that?  Wa
[16:46:25] <smarlow> s there a performance problem solved by doing the ManagedEntityManagerFactory.nonTxStack dance (closing the PC at the bean invocation boundary instead of after each EM invocation?)
[16:47:32] <wolfc> It's required by spec, hold on
[16:48:50] <smarlow> I think the spec says that we have to detach after each method call
[16:49:21] <smarlow> that might be 7.6.1, but I'm checking
[16:49:50] <wolfc> Yes
[16:50:20] <wolfc> So you can not close after each EM call. It would change the semantics completely.
[16:52:17] <smarlow> I must be being stupid about that but if we clear the state, after each EM call, which semantics am I forgetting about?
[16:53:41] <smarlow> we don't allow any calls to EM remove/merge/persist/refresh.
[16:58:35] *** balunasj has joined #jboss-as7
[16:58:35] *** balunasj has joined #jboss-as7
[16:58:35] *** ChanServ sets mode: +v balunasj
[16:58:40] <wolfc> Yes, now I need to dig history then
[17:00:27] <dmlloyd> wow, vfs seems to be in a pretty broken state
[17:00:35] * dmlloyd is a little shocked
[17:01:07] <rmaucher> broken like what ?
[17:07:08] <dmlloyd> well there's target/ checked in for one thing
[17:07:25] <dmlloyd> and .svn dirs checked into git
[17:07:28] <dmlloyd> that's probably my fault
[17:07:56] <dmlloyd> the pom is pretty messed up
[17:08:05] *** mbg has joined #jboss-as7
[17:08:06] *** ChanServ sets mode: +v mbg
[17:08:09] <dmlloyd> deps on common-core for one class which it doesn't even need
[17:09:02] <dmlloyd> getting stack overflow errors on VirtualJarInputStream too
[17:09:06] <dmlloyd> looking into that now
[17:09:15] <dmlloyd> also fixed about 30 spelling errors :)
[17:10:01] <alesj> dmlloyd:  what's so broken about vfs?
[17:19:45] *** asaldhan has joined #jboss-as7
[17:19:45] *** ChanServ sets mode: +v asaldhan
[17:19:55] *** pgier has quit IRC
[17:20:21] *** pgier has joined #jboss-as7
[17:20:21] *** ChanServ sets mode: +v pgier
[17:22:59] *** fnasser has quit IRC
[17:23:25] *** jamezp has joined #jboss-as7
[17:27:55] *** fnasser has joined #jboss-as7
[17:31:05] *** baileyje has quit IRC
[17:32:31] <tdiesler> dmlloyd, do you know what this is? http://pastie.org/1656191
[17:32:47] <tdiesler> dmlloyd, modules seems to require xerces
[17:34:35] <dmlloyd> Nihility can explain in detail
[17:34:53] <dmlloyd> but basically something is specifying that provider impl class
[17:35:10] <dmlloyd> i.e. META-INF/service
[17:35:23] <dmlloyd> that's not the whole stack trace, is it?
[17:35:28] <Nihility> yea that means that the TCCL had a META-INF/service
[17:35:33] <Nihility> for jaxp
[17:35:41] *** frainone has joined #jboss-as7
[17:35:47] *** frainone has joined #jboss-as7
[17:35:47] *** ChanServ sets mode: +v frainone
[17:36:33] <dmlloyd> it looks like the default provider is throwing javax.xml.datatype.DatatypeConfigurationException
[17:36:56] <dmlloyd> in this case though it really shouldn't use __redirected.__RedirectedUtils#wrapped() because that hides the initial cause
[17:37:05] <dmlloyd> it's meant for when you replace an exception with an equivalent error
[17:37:13] <dmlloyd> it should probably replace the stack trace, too...
[17:40:32] *** baileyje has joined #jboss-as7
[17:40:32] *** ChanServ sets mode: +v baileyje
[17:40:52] <Nihility> wrapped copies the cause
[17:41:24] <Nihility> it should instead use it as the cause
[17:42:20] <Nihility> but it wouldnt give you any more information
[17:42:47] <Nihility> other than the stack trace of what threw the original exception
[17:44:07] *** smcgowan has quit IRC
[17:44:17] <tdiesler> Nihility, dmlloyd, this error shows when I bootstrap the framework with modules Beta15. META-INF/services from the surefire classpath should not affect Framework bootstrap I think. Is there more detail on why this needed to change?
[17:45:03] <dmlloyd> yeah, tdiesler, JAXP uses TCCL to find implementation classes and it's impossible to replace the JDK classes, so the whole mechanism exists so that the default impl can be replaced
[17:45:57] <dmlloyd> it is necessary, the real question is, why is the default datatype provider throwing javax.xml.datatype.DatatypeConfigurationException
[17:46:06] <dmlloyd> and what is the content of that masked exception
[17:46:21] <Nihility> the content is: Provider org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl not found:
[17:47:02] <smarlow> Nihility:  baileyje volunteered to help with the JPA tasks.  We discussed needing three interceptors but I think we have it down to two now.  The SFSB instance interceptor (I think it should go after Association and possibly Transaction but it might be possible to be outside of Transaction).  There was the question for wolfc that we wanted to ask, whether EJB3 tx interceptors are per method or per class.
[17:47:05] <wolfc> smarlow, the nonTxMap was introduced in r42263 but I agree that it should not be needed.
[17:47:24] <Nihility> which mean thats xerces is on the TCCL
[17:47:26] *** bstansberry has quit IRC
[17:47:31] <smarlow> wolfc:  cool, so rmaucher will be happy that we are starting without that.  :)
[17:47:32] <Nihility> well part of it
[17:47:50] <rmaucher> nice ;)
[17:47:53] <smarlow> wolfc: and we will have one less moving part, which makes me happy :)
[17:48:03] <wolfc> currently the ee setup doesn't allow for system per instance interceptors
[17:48:09] <dmlloyd> augh.  the VFS tests don't clean up their mounts, so earlier tests leave a corrupted state for later tests.
[17:48:22] <dmlloyd> forking was used to work around it
[17:48:25] <dmlloyd> nasty
[17:48:25] <wolfc> but do we actually need that for JPA?
[17:48:50] <Nihility> a component interceptor might work
[17:50:09] <smarlow> Nihility, wolfc, dmlloyd, baileyje :  could a component interceptor know the underlying StatefulSessionComponentInstance for SFSBs?
[17:50:31] <wolfc> context.getPrivateData(CompontInstance.class);
[17:50:37] <wolfc> But only after association
[17:50:57] <Nihility> actually it ake that back
[17:51:54] <wolfc> That is actually no problem. Just need to make sure it goes in the correct spot on the interceptor chain.
[17:52:10] <Nihility> tdiesler, dmlloyd this means that the default factory was replaced
[17:52:52] *** bstansberry has joined #jboss-as7
[17:52:52] *** ChanServ sets mode: +v bstansberry
[17:53:54] <Nihility> tdiesler: Is there a caused by on that stacktrace, and do you have trimStackTrace=false?
[17:55:27] *** fnasser has quit IRC
[17:56:05] <smarlow> baileyje:  do you want to hack the JPA interceptors together to help get me started?  or should I just do it?  If someone builds me stub interceptors that will be get invoked, I can fill in the JPA blanks.
[17:56:44] <tdiesler> Nihility, there is only the CNFE ClassNotFoundException
[17:56:48] <tdiesler> http://pastie.org/1656283
[17:57:00] *** jcosta has quit IRC
[17:57:58] <baileyje> smarlow: I can do what ever you need.  I am still not sure what the interceptors do, but I can get them to run..  Which components needs them?  All components?  All SLSBs?
[17:58:31] <wolfc> the interceptor itself needs to go into jpa subsystem.
[17:58:47] *** smcgowan has joined #jboss-as7
[17:59:05] <wolfc> in StatefulComponentConfiguration: if(hasJPA()) addComponentSystemInterceptorFactory...
[17:59:16] <tdiesler> Nihility, never mind I'll look at this tomorrow.
[17:59:16] <Nihility> tdiesler: ah ok so what that says is that your app classpath (or endorsed boot classpath) has a META-INF/services/javax.xml.datatype.DatatypeFactory on it, but it does not have the class
[17:59:19] *** smcgowan has quit IRC
[17:59:43] <smarlow> baileyje:  Only SFSBs.
[17:59:59] *** smcgowan has joined #jboss-as7
[18:00:00] *** ChanServ sets mode: +v smcgowan
[18:00:31] <wolfc> smarlow, if we only have the XPC interceptor, what is the other one?
[18:00:35] <smarlow> baileyje:  there is a JPADeploymentMarker marker for the hasJPA part
[18:00:51] <Nihility> tdiesler: a simple test of not using modules and instead just doing DatatypeFactory.newInstance should present the same problem
[18:00:51] <wolfc> no, no
[18:01:05] <wolfc> a deployment may use JPA from another DU
[18:01:26] <wolfc> hasJPA means whether the JPA subsystem is available
[18:02:10] <smarlow> wolfc:  okay, sure.  Thanks for learning me that!  so, they can use the fully scoped reference to another DU?
[18:02:33] <wolfc> smarlow, I hope so :-)
[18:02:43] <tdiesler> Nihility, the service def and the class is in the same jar AFAICS http://pastie.org/1656304
[18:03:35] <wolfc> Nihility, tdiesler, dmlloyd, does modules expose META-INF/services/... even if a package is not exposed?
[18:03:56] <dmlloyd> depends on what you mean by expose wolfc
[18:04:15] <Nihility> tdiesler: you know what this might be the bug in JAXP i saw let me check
[18:04:44] <dmlloyd> wolfc, your services are available to anyone who imports, but they have to explicitly import it because META-INF is filtered out by default (on import, not on export)
[18:04:57] *** rawblem has joined #jboss-as7
[18:04:57] *** ChanServ sets mode: +v rawblem
[18:05:24] <rawblem> bstansberry, is there a page listing all the deploy options / suffixes current workflow? .dodeploy .deploying .deployfailed etc etc?
[18:05:52] <wolfc> if META-INF is filtered out by default, then we shouldn't be able to see anything
[18:06:27] <bstansberry> rawblem: best is max's forum post; going to find the link now
[18:06:38] <Nihility> tdiesler: yes this is a stupid bug in the jaxp factories that happens when a jar is on the app classpath but the TCCL is null
[18:06:56] <Nihility> tdiesler: ill see if i can work around it
[18:07:13] <smarlow> wolfc, baileyje:  the other need is for XPC lifecycle
[18:07:45] <smarlow> wolfc:  gave me a pointer for that before, need to check my notes...
[18:08:06] <bstansberry> http://community.jboss.org/thread/155949?start=30&tstart=0, post dated Nov 20
[18:08:49] *** balunasj is now known as balunasj_away
[18:09:18] <bstansberry> rawblem: ^^^. I see now he requested ".isdeployed" and we implemented ".deployed" -- which we can change if you guys want
[18:09:45] <bstansberry> his post doesn't include ".deploying" and ".undeploying" which I added per our IRC last week
[18:09:53] <rawblem> bstansberry,  just need an accurate list is all ;)
[18:09:58] <bstansberry> we aren't doing .donotdeploy at this time
[18:10:31] <rawblem> bstansberry,  so what's default behaviour if a foo.war is copied in and no suffix-file is there?  no action?
[18:10:35] <bstansberry> tomorrow I'll add a README.txt to the standalone/deployments dir
[18:10:38] <rawblem> k k
[18:10:40] <bstansberry> right. nothing
[18:10:40] <smarlow> baileyje, wolfc:  from a previous email discussion, I have "A lifecycle interceptor should do the trick:@PreDestroy void preDestroy(InvocationContext ctx) { unsubscribe(sessionContext.getSessionId()); } That is the other interceptor needed
[18:10:55] <rawblem> bstansberry,  ok and just give me a pointer to where in your code this is impl
[18:11:00] <Nihility> tdiesler: i have a solution give me 10 and ill have it fixed, if you want a workaround you can add -Djavax.xml.datatype.DataTypeFacory=org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl
[18:11:08] <Nihility> to your surfire config
[18:11:25] <smarlow> baileyje:  I'll fill in the unsubscribe blanks to keep it simple.
[18:11:58] <bstansberry> rawblem: https://github.com/bstansberry/jboss-as/tree/deployment-scanner/deployment-scanner/src/main/java/org/jboss/as/server/deployment/scanner
[18:12:01] <smarlow> it will be the inverse of xpc injection
[18:12:05] <smarlow> more or less
[18:12:17] <wolfc> right now we have no ComponentInstance lifecycle callbacks on system interceptors
[18:12:40] <bstansberry> particularly the FilesystemDeploymentService class -- the rest is probably not relevant
[18:13:06] <dmlloyd> https://github.com/dmlloyd/jboss-vfs/tree/whatever <- I don't have any more time to spend on this, someone else can finish it up if they want to
[18:13:56] <smarlow> wolfc:  we could close the xpc at AS server shutdown time :)
[18:14:02] <dmlloyd> baileyje: your stuff is in master?
[18:14:06] <rawblem> bstansberry,  fantastic, found it.
[18:14:07] <smarlow> after it OOMs :-)
[18:14:10] <baileyje> dmlloyd: Yeah
[18:16:24] *** pferraro has joined #jboss-as7
[18:16:24] *** ChanServ sets mode: +v pferraro
[18:17:22] <jbossbot> git [jboss-as] push master b8ceebe.. John E. Bailey Add initial support for @EJB injection.
[18:17:23] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/52fbe7d...b8ceebe
[18:17:27] <dmlloyd> baileyje: it was rebased
[18:17:35] <dmlloyd> unchanged other than that
[18:17:42] <baileyje> dmlloyd: Thanks
[18:17:50] *** dimitris_ has joined #jboss-as7
[18:17:51] *** dimitris_ has joined #jboss-as7
[18:17:51] *** ChanServ sets mode: +v dimitris_
[18:18:40] <tdiesler> Nihility, I'll rollback to Beta14 for now
[18:18:42] <wolfc> smarlow, we could abuse configuration.preDestroyInterceptLifecycle and insert an interceptor factory there.
[18:18:51] *** tdiesler has quit IRC
[18:19:52] <wolfc> baileyje, dmlloyd, the EJB annotation processor needs to be in ee
[18:20:51] *** alesj has quit IRC
[18:20:54] <wolfc> you can do @EJB from any ee component
[18:20:59] <dmlloyd> http://github.com/dmlloyd/jboss-modules/commit/af1acaf
[18:21:00] <jbossbot> git [jboss-modules] af1acaf.. David M. Lloyd Exception readability improvements
[18:21:07] <dmlloyd> ^^ should help debug problems like this
[18:21:19] <dmlloyd> wolfc: yeah but it only works if EJB is enabled
[18:21:26] *** jhalliday has quit IRC
[18:21:31] <wolfc> dmlloyd, how can Web enabled this then?
[18:21:53] <dmlloyd> wolfc: it works on all deployments but only if EJB is installed
[18:22:09] <dmlloyd> where the processor lives has no effect on the type of deployment it can operate on
[18:22:23] <wolfc> you'll get circular compile dependencies
[18:22:31] <dmlloyd> I don't see why
[18:23:29] *** smarlow has quit IRC
[18:23:31] <wolfc> where does @WebServiceRef processing live?
[18:24:01] <dmlloyd> webservices subsystem
[18:24:05] <dmlloyd> not done yet though
[18:24:12] <wolfc> So EJB 3 depends on WS then
[18:24:18] <dmlloyd> no it doesn't, why would it
[18:24:31] <wolfc> Else I can't have an @WebServiceRef in an EJB component
[18:24:35] <dmlloyd> why not?
[18:24:53] <dmlloyd> if you don't have webservices installed it just ignores it
[18:24:57] <dmlloyd> otherwise it works
[18:25:33] <wolfc> ah yes, silly me.
[18:26:02] <wolfc> I was thinking the wrong loop-hole
[18:27:06] <dmlloyd> Nihility: can you look over my modules commit?
[18:28:20] <Nihility> dmlloyd: i already have that in my commit with the work-around to thomas' problem
[18:28:24] <rmaucher> ok, there are indeed plenty on NPEs I need to fix after the TCK run ;)
[18:28:35] <dmlloyd> Nihility: ok, both parts?
[18:28:43] <wolfc> dmlloyd, in https://github.com/wolfc/jboss-as/blob/d8445913415c9ea063b9361db25f358af9f4f368/ejb3/src/main/java/org/jboss/as/ejb3/EJBUtilities.java I do Service<EJBUtilities> that seems wrong. How should this work?
[18:28:56] <dmlloyd> Nihility: what is the problem btw?  is the default impl making bad CL assumptions?
[18:29:48] <Nihility> yep i fixed that too
[18:29:57] <dmlloyd> wolfc: it's ugly but should work fine
[18:30:03] <Nihility> its that bug i found in the jaxp provider
[18:30:09] <Nihility> i was telling you about long ago
[18:30:11] <Nihility> the factory class
[18:30:31] <Nihility> here ill post the comment i just added
[18:30:31] <Nihility> :)
[18:30:52] <wolfc> It works. Ah I should have an EJBUtilitiesService extends AbstractService<EJBUtilities>
[18:31:12] <Nihility> http://fpaste.org/qqIq/
[18:31:21] <dmlloyd> wolfc: you can do it either way.  I don't think it really makes a big difference
[18:31:38] <wolfc> then I'll leave that
[18:32:20] <wolfc> dmlloyd, instead of the Map<ServiceName, InjectedValue> I've reinstated https://github.com/wolfc/jboss-as/blob/d8445913415c9ea063b9361db25f358af9f4f368/ee/src/main/java/org/jboss/as/ee/component/ComponentInjectionConfiguration.java
[18:32:56] <wolfc> with the generics addDependency doesn't like anything I give it.
[18:33:21] <wolfc> https://github.com/wolfc/jboss-as/commit/d8445913415c9ea063b9361db25f358af9f4f368#L7L103
[18:33:22] <jbossbot> git [jboss-as] d844591.. Carlo de Wolf Initial integration of CMT tx interceptor
[18:34:29] <wolfc> why do we have ServiceBuilder.addDependency(ServiceName, Injector<Object>) ?
[18:34:30] <dmlloyd> baileyje: hey, you should go on to github and add "jbailey at redhat dot com" as an email alias so that the impact graph makes all your segments continuous
[18:34:48] <dmlloyd> bstansberry: you should do the same for "bstansberry at jboss dot com"
[18:35:30] *** smarlow has joined #jboss-as7
[18:35:30] *** ChanServ sets mode: +v smarlow
[18:40:48] *** emuckenhuber has quit IRC
[18:41:45] <Nihility> https://github.com/n1hility/jboss-modules/commit/66cd842547a678cffb0ee6708e43a2b51cfb4cd4#diff-2
[18:41:47] <jbossbot> git [jboss-modules] 66cd842.. Jason T. Greene Workaround JAXP API bug that is triggered when a provider is on the app classpath
[18:42:17] *** darranl has quit IRC
[18:42:37] <Nihility> btw i realized we have a ton of stuff
[18:42:41] <Nihility> thats not using security manager
[18:42:42] <Nihility> in here
[18:42:47] <Nihility> need to fix that at some point
[18:42:55] <dmlloyd> Nihility: you realise that getSystemClassLoader() will usually return null?
[18:43:10] <dmlloyd> oh I see, you do it via TCCL
[18:43:20] <dmlloyd> still though it's basically the same code
[18:43:26] <Nihility> no it doesnt
[18:45:00] <Nihility> it returns the classloader that loaded class path
[18:46:23] <dmlloyd> hmm, interesting
[18:46:26] <rmaucher> various fixes to the annotation code, after running TCK: https://github.com/rmaucher/jboss-as/commit/f284c7b27a039052f4110e1a7ea65009f0ff744d
[18:46:26] <jbossbot> git [jboss-as] f284c7b.. Rémy Maucherat Various fixes in new web annotation code, after running tests.
[18:46:34] <dmlloyd> it *can* return null though
[18:47:17] <Nihility> dmlloyd: yes although if it did, then the jaxp code would not find the provider META-INF/service
[18:47:40] <Nihility> since the jaxp impl uses getSystemCL when TCCL is null
[18:47:46] <Nihility> for its (fallback)
[18:47:58] <dmlloyd> ok well, then *approved*
[18:48:17] <dmlloyd> funny that you made pretty much the exact same change to the exception thing that I did
[18:48:36] <Nihility> yeah i realized it when i was saying using wrapped should be fine
[18:48:45] <Nihility> and looked at the code and realized it wasnt fione
[18:49:24] <Nihility> dmlloyd: i think it might be more correct though to not mess with TCCL and just inherit the runtimes impl
[18:49:40] <dmlloyd> the JDK one you mean?
[18:49:46] <dmlloyd> yeah that might be smart
[18:49:50] *** rawbdor has joined #jboss-as7
[18:50:06] <Nihility> yeah i mean basically rely on whatever TCCL modules gets on static init
[18:50:20] <Nihility> the only reason i didnt do that is that i was worried about breaking things like maven
[18:50:36] <Nihility> which probably have a wierd TCCL
[18:51:07] <Nihility> thought we could revisit after release
[18:51:27] <baileyje> smarlow: So far I have done nothing.  I am still trying to get some background , if it makes sense for you to just add the interceptors, I can't get something else to do.
[18:51:50] *** rawbdor has quit IRC
[18:52:11] *** rawbdor has joined #jboss-as7
[18:53:20] <Nihility> rmaucher: the reason the annotation index does not have defaults is that the class file does not store them, and they would require having the annotations visible (and scanned) by the indexer at the time of indexing, and it's extra space. However there is an interesting benefit to this, which is that you can actually know if the user specified the value or if its the default (no way to know in reflection).
[18:53:49] <rmaucher> yes, I read that in the comments somewhere :)
[18:58:36] *** rawblem has quit IRC
[19:05:28] *** Darran_L has joined #jboss-as7
[19:10:30] <smarlow> baileyje:  either way is fine with me.  Basically, the interceptor needs to track the SFSB invocation call stack.  I added SFSBCallStack on my branch but haven't requested a push of that yet.  The interceptor will call SFSBCallStack.pushCall() for each SFSB invocation (synchronously in the invocation thread).  On the invocation return, the interceptor will call SFSBCallStack.popCall()
[19:11:05] <smarlow> baileyje:  The SFSBCallStack will be used for extended persistence context inheritance
[19:12:09] <smarlow> baileyje:  basically, if SFSB1 has a extended persistence context (XPC) and during a SFSB1 invocation, SFSB2 is injected, SFSB2 can inherit the XPC from SFSB1
[19:12:38] *** jfclere has quit IRC
[19:12:44] <smarlow> baileyje:  so, the SFSBCallStack tracks enough information, to make this possible.
[19:13:20] *** AndyTaylor has quit IRC
[19:15:42] *** rawbdor has quit IRC
[19:16:59] <rmaucher> and I also have the NPE on deployment fix: https://github.com/rmaucher/jboss-as/commit/1d0df181a18dc3667f6cf2207ab9f761a481b401
[19:17:00] <jbossbot> git [jboss-as] 1d0df18.. Rémy Maucherat Fix NPE when using JSP Servlets (no class).
[19:17:46] <smarlow> baileyje:  alternatively, maybe you could help answer questions when I get into trouble? :)
[19:17:48] <rmaucher> adding classes as components is good, but some Servlets are actually JSPs and should be skipped
[19:18:00] <baileyje> smarlow: That sounds like a better plan :)
[19:18:07] *** emuckenhuber has joined #jboss-as7
[19:18:08] *** emuckenhuber has joined #jboss-as7
[19:18:08] *** ChanServ sets mode: +v emuckenhuber
[19:18:45] <Nihility> smarlow: do you think you have the time to get it working though?
[19:19:32] <smarlow> wolfc:  you said earlier:  "StatefulComponentConfiguration: if(hasJPA()) addComponentSystemInterceptorFactory..."  where is StatefulComponentConfiguration?
[19:20:38] <smarlow> Nihility:  how much time do I have left?
[19:20:45] <wolfc> I meant StatefulSessionComponentConfiguration
[19:21:10] <Nihility> smarlow: monday evening im going to try tagging the release
[19:22:41] <Nihility> smarlow: so if your odds go up by giving a chunk to baiieyje or i we should do that
[19:25:15] <smarlow> I think if I continue building the plumbing up, while someone adds a stub JPA SFSB interceptor (in EJB3 StatefulSessionComponentConfiguration I think), that would be good.
[19:26:03] *** ALR has joined #jboss-as7
[19:26:03] *** ChanServ sets mode: +v ALR
[19:26:08] <smarlow> Nihility:  I have the plumbing pieces for the interceptor to invoke, so that could be pulled in.
[19:27:51] <smarlow> Nihility:  or we could leave extended persistence context support out for this release and build around it.  That might not be a bad idea since we don't have the lifecycle support yet
[19:28:23] <smarlow> for this tagged build I mean, not the release :)
[19:29:02] <smarlow> then, I don't need any interceptors and just start tying things together to finish up...
[19:29:05] <Nihility> we should certainly start by getting something merged i think
[19:29:28] <Nihility> if we have to lose XPC for beta1 thats fine
[19:30:10] <wolfc> lifecycle support we can 'fake' by putting your interceptor before the user interceptors.
[19:30:56] <smarlow> Nihility, wolfc:  so, it would be a big help if someone could coordinate, getting that in for me?
[19:32:07] <wolfc> I can lend a hand while I'm waiting for my latest stuff to get flamed :-)
[19:32:42] <smarlow> wolfc:  great, thanks!  :)
[19:38:27] *** AndyTaylor has joined #jboss-as7
[19:38:27] *** ChanServ sets mode: +v AndyTaylor
[19:38:35] *** AndyTaylor has quit IRC
[19:43:31] <kkhan> dmlloyd: Was there a problem with my patches from last night or did you just not get around to applying them
[19:45:41] <wolfc> Ah realization. We don't want hasJPA(), do we? The JPA subsystem should install a processor that installs the needed interceptors into EJB Component (Configuration/Desc), not?
[19:45:54] <Nihility> correct
[19:47:38] <dmlloyd> kkhan: probably just got lost in the shuffle, can you link your branch to me?
[19:47:50] <wolfc> Hmm, that's really tricky to do.
[19:47:53] <kkhan> [23:30:03] <kkhan> dmlloyd: https://github.com/kabir/jboss-as/commits/master-patches contains https://github.com/kabir/jboss-as/commit/de1d4c0608391a5581337217471b9177c3ae566a and https://github.com/kabir/jboss-as/commit/31ec57cc9a71fc2b55c21abe57687bf1ca9003ae
[19:47:54] <jbossbot> git [jboss-as] de1d4c0.. kabir Upgrade to 1.0.0.Alpha3 of modular surefire plugin to avoid issues on maven 3.0.3
[19:47:54] <jbossbot> git [jboss-as] 31ec57c.. kabir [JBAS-8934] Better rejection policy for client
[19:47:55] <jbossbot> jira [JBAS-8934] RejectedExecutionExceptions in management API [Open (Unresolved) Bug, Major, Kabir Khan] https://issues.jboss.org/browse/JBAS-8934
[19:48:16] <kkhan> For 8934 I'm not 100% sure if that is what you had in mind
[19:48:17] <dmlloyd> great
[19:48:22] <dmlloyd> yeah that's fine
[19:48:33] *** Darran_L has quit IRC
[19:48:34] <dmlloyd> well, the core size shouldn't be 0
[19:48:44] <wolfc> So we actually want to use the same for tx and security, not?
[19:48:46] <dmlloyd> that can cause weird starvation issues
[19:48:52] <dmlloyd> change it to one and I'll pull it
[19:49:03] <smarlow> wolfc, Nihility:  do we want a JPA DUP to somehow build off of noticing EJB3 attachments that it finds?  and install an interceptor that way?
[19:49:24] <dmlloyd> actually it's a small change, I'll just hack it in there
[19:49:33] <wolfc> The problem is that interceptor sequence is important
[19:50:14] <kkhan> dmlloyd: I've done it
[19:50:44] <wolfc> But as long as we tweak the phase right, they should pop up in the correct order
[19:50:54] <kkhan> I spoke too soon
[19:50:58] <dmlloyd> kkhan: looks like a big chunk of that was changed in upstream
[19:51:04] <dmlloyd> can you rebase?
[19:51:31] <Nihility> i think as long as its added before user interceptors
[19:51:34] <Nihility> it ok
[19:53:14] *** asoldano is now known as asoldano_away
[19:59:40] *** emmanuel has quit IRC
[20:01:35] <wolfc> Hmm, component system interceptor are in Configuration only, which lives inside one processor.
[20:04:56] <kkhan> dmlloyd: Getting some problems, I'll look after dinner
[20:06:44] <dmlloyd> okay
[20:08:06] *** Jaikiran has quit IRC
[20:08:53] *** asaldhan has quit IRC
[20:09:11] *** asaldhan has joined #jboss-as7
[20:09:17] *** asaldhan has left #jboss-as7
[20:21:01] <smarlow> dmlloyd:  if I squash my branch changes, will that conflict with the squashing that you already did separately for my branch?
[20:22:24] <dmlloyd> smarlow: it should be fine
[20:22:29] *** rawbdor has joined #jboss-as7
[20:22:29] *** ChanServ sets mode: +v rawbdor
[20:23:09] *** AndyTaylor has joined #jboss-as7
[20:23:09] *** ChanServ sets mode: +v AndyTaylor
[20:23:51] <wolfc> it would appear we don't have class level lifecycle callbacks
[20:24:06] <wolfc> on interceptor instances that is
[20:24:54] *** darranl has joined #jboss-as7
[20:24:55] *** darranl has joined #jboss-as7
[20:24:55] *** ChanServ sets mode: +v darranl
[20:25:34] <wolfc> baileyje, where is @PostConstruct and @PreDestroy processed for an @Interceptor?
[20:26:29] *** darranl has quit IRC
[20:26:59] *** AndyTaylor has quit IRC
[20:27:04] <baileyje> wolfc: The @PostConstruct and @Predestroy for an interceptor itself?
[20:27:11] <wolfc> yes
[20:27:30] <baileyje> They might not be.  One second
[20:31:41] <baileyje> dmlloyd: Did we add support for lifecycle methods on an interceptor?
[20:32:10] <dmlloyd> I thought stuart did but maybe we lost it at some point
[20:32:45] <baileyje> yeah.  I thought it was done, but can't remember clearly
[20:33:54] <wolfc> I think we better have it as well for system interceptors. It is needed to make JPA work.
[20:34:31] *** smcgowan is now known as smcgowan_lunch
[20:35:05] <smarlow> wolfc:  I just squashed the mess on my branch
[20:38:58] <wolfc> screeching to a halt anyway. Let me see if I can get a hack up.
[20:39:29] <dmlloyd> originally you'd just register a ComponentLifecycle or whatever it was and that was it
[20:39:44] <dmlloyd> we really need to go back to that and stop using Interceptor for lifecycle methods because it doesn't fit
[20:40:59] <wolfc> It fits up to a certain point. It requires a mind-warp.
[20:41:14] <wolfc> Something that is too alien vs 'normal' interceptors.
[20:41:24] <dmlloyd> it only works if your invocation target is a Method
[20:41:45] <wolfc> Okay, it requires a mind-warp++
[20:41:50] <dmlloyd> should just be a simple interface with postConstruct/preDestrory
[20:41:57] <wolfc> Yup
[20:42:04] <dmlloyd> then we can have an impl that hits Methods
[20:42:11] <dmlloyd> for the user case
[20:42:17] <dmlloyd> *that* would be more consistent
[20:43:48] <wolfc> smarlow, https://github.com/wolfc/jboss-as/commit/6806c56d4bdf53528c59671c3eb6c0d2012364eb
[20:43:49] <jbossbot> git [jboss-as] 6806c56.. Carlo de Wolf Introduce a class level interceptor for JPA processing
[20:43:55] <wolfc> it works, but we're not going to use it :-)
[20:44:22] <wolfc> it should be a system interceptor, not an user interceptor
[20:44:30] * smarlow looking
[20:45:19] *** fnasser has joined #jboss-as7
[20:45:33] <wolfc> so ComponentSystemInterceptorFactories needs an Description equivalent and it needs lifecycle callback for ComponentInstances
[20:46:16] <wolfc> There is a nagging thing in the spec that the instance of an interceptor is tied to the lifecycle it controls. We probably want to let go of that and make it configurable for system interceptors. It needs code & docs.
[20:46:29] * wolfc is now getting some beer.
[20:47:18] <dmlloyd> well it's still consistent though, there's really only two lifecycles that make sense to track: instance, and proxy
[20:47:25] <dmlloyd> and I can't think of any use for tracking proxy lifecycle
[20:48:00] <dmlloyd> interceptor objects (as created by the @Interceptor annotation) are a different story from the registered lifecycle handles
[20:55:02] <dmlloyd> anyway my point is that a component level Interceptor instance can last as long as we want it to - there is no real lifecycle attachment for it
[20:58:49] <baileyje> dmlloyd: What other tasks are needed before Monday?
[20:59:27] <dmlloyd> this JPA stuff needs to be finished up
[20:59:32] <dmlloyd> that's the single most important item
[21:00:01] <dmlloyd> and singletons, which jaikiran is working on
[21:00:13] <dmlloyd> that's all for EJB at least, let me check my other list here
[21:00:21] <dmlloyd> frainone is working on @WSRef...
[21:01:03] <dmlloyd> quick task, could you enhance the injetion thing to support injecting an ORB from a service named jboss.org?
[21:01:04] <dmlloyd> er
[21:01:06] <dmlloyd> jboss.orb :)
[21:01:11] * dmlloyd muscle memory
[21:01:24] <rmaucher> dmlloyd, do you have time to pull https://github.com/rmaucher/jboss-as/commit/f284c7b27a039052f4110e1a7ea65009f0ff744d and https://github.com/rmaucher/jboss-as/commit/1d0df181a18dc3667f6cf2207ab9f761a481b401 ? NPE fixes (lots of) ;)
[21:01:25] <jbossbot> git [jboss-as] f284c7b.. Rémy Maucherat Various fixes in new web annotation code, after running tests.
[21:01:25] <jbossbot> git [jboss-as] 1d0df18.. Rémy Maucherat Fix NPE when using JSP Servlets (no class).
[21:01:29] <dmlloyd> baileyje: and maybe quick check over EE and jsr-250 etc to make sure there aren't any other implicit injection types
[21:01:38] <dmlloyd> rmaucher: sure
[21:01:43] <rmaucher> thanks :)
[21:04:50] <jbossbot> git [jboss-as] push master f284c7b.. Rémy Maucherat Various fixes in new web annotation code, after running tests.
[21:04:51] <jbossbot> git [jboss-as] push master 1d0df18.. Rémy Maucherat Fix NPE when using JSP Servlets (no class).
[21:04:51] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/b8ceebe...1d0df18
[21:08:15] <rmaucher> merci ! :)
[21:08:42] <rmaucher> how long do I need to wait before running the TCK on hudson ? does anyone know ?
[21:10:01] <kkhan> dmlloyd: https://github.com/kabir/jboss-as/commit/31ec57cc9a71fc2b55c21abe57687bf1ca9003ae causes problems
[21:10:02] <jbossbot> git [jboss-as] 31ec57c.. kabir [JBAS-8934] Better rejection policy for client
[21:10:04] <jbossbot> jira [JBAS-8934] RejectedExecutionExceptions in management API [Open (Unresolved) Bug, Major, Kabir Khan] https://issues.jboss.org/browse/JBAS-8934
[21:10:23] <kkhan> Can you just pull https://github.com/kabir/jboss-as/commit/de1d4c0608391a5581337217471b9177c3ae566a  for now?
[21:10:24] <jbossbot> git [jboss-as] de1d4c0.. kabir Upgrade to 1.0.0.Alpha3 of modular surefire plugin to avoid issues on maven 3.0.3
[21:10:51] <dmlloyd> sure
[21:11:24] <kkhan> I'm guessing that the protocol gets confused if it is able to execute more than one thing at a time
[21:11:48] <dmlloyd> hmm I can't seem to merge that commit
[21:11:53] <dmlloyd> what branch is it in?
[21:12:08] <kkhan> Sorry, I used the old ones and I've force upgraded
[21:12:11] <kkhan> force pushed
[21:12:28] <kkhan> https://github.com/kabir/jboss-as/tree/master-patches
[21:12:33] <dmlloyd> ok thanks
[21:12:39] <kkhan> https://github.com/kabir/jboss-as/commit/cef0df973ce20d4fb734b4db5e9e7eaefa5bf1b6
[21:12:40] <jbossbot> git [jboss-as] cef0df9.. kabir Upgrade to 1.0.0.Alpha3 of modular surefire plugin to avoid issues on maven 3.0.3
[21:13:02] <jbossbot> git [jboss-as] push master 8931009.. kabir Upgrade to 1.0.0.Alpha3 of modular surefire plugin to avoid issues on maven 3.0.3
[21:13:02] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/1d0df18...8931009
[21:13:38] <dmlloyd> cherry-picked it
[21:15:58] *** stuartdouglas has joined #jboss-as7
[21:20:21] *** stuartdouglas has quit IRC
[21:21:35] *** smcgowan_lunch is now known as smcgowan
[21:25:41] <smarlow> hmm, did https://github.com/jbossas/jboss-as go back in time?  I don't see jpa anymore?
[21:25:52] <dmlloyd> it was never pushed upstream, smarlow
[21:26:01] <dmlloyd> I staged it in my tree
[21:26:04] <dmlloyd> that's it
[21:26:46] <smarlow> oh, my mistake, I thought it was pulled already
[21:27:11] *** mbg is now known as mbg|away
[21:30:25] *** balunasj_away has quit IRC
[21:32:29] <smarlow> Nihility:  any idea how a javax.persistence.PersistenceContextType (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceContextType.html) will appear in a AnnotationValue?  I wasn't sure in https://github.com/scottmarlow/jboss-as/blob/master/jpa/src/main/java/org/jboss/as/jpa/service/PersistenceContextInjectorService.java how to access that
[21:33:01] * smarlow I just hacked it to assume PersistenceContextType.TRANSACTION
[21:33:33] <smarlow> but need to fix that for EXTENDED
[21:35:16] <Nihility> this.type = PersistenceContextType.TRANSACTION;  /
[21:35:20] <Nihility> how does that compile?
[21:35:38] <smarlow> yes, that is the hack
[21:37:34] <smarlow> this.type is of the same type as the right hand side, probably could of used a better variable name
[21:38:41] <smarlow> the hack is that I'm hard coding the setting to transaction scoped, instead of reading the result of annotation.value("type") because I wasn't sure how to access it.
[21:39:24] <smarlow> for enums, will annotation value return something special?
[21:41:07] <Nihility> OH
[21:41:09] <Nihility> ok
[21:41:25] <Nihility> yes
[21:41:30] <Nihility> see the Type javadoc
[21:41:42] <Nihility> oh its an enum
[21:42:00] <Nihility> in that case if you do asEnum
[21:42:13] <Nihility> you get the unique string for the enum
[21:42:22] <Nihility> which is the same as the identifier
[21:42:29] <Nihility> so "TRANSACTION"
[21:42:36] <smarlow> nice, perfect!  :)
[21:44:00] <Nihility> if you dont like hard coding the string you can also just convert the enum to a string
[21:44:26] <Nihility> if (PersitenceContextType.TRANSACTION.name().equals(value.asEnum))
[21:46:02] *** mbg|away is now known as mbg
[21:47:42] <smarlow> nice, that is much better than my evil hack.
[21:51:05] *** stuartdouglas has joined #jboss-as7
[21:53:08] <smarlow> I need to do some basic transaction stuff but don't have easy access to a service registry to lookup the TransactionSynchronizationRegistryService and other transaction services
[21:54:47] <smarlow> one solution, would be to push the logic into a service, if that is the right way
[21:55:08] <smarlow> then, I could depend on other services.  I have some stuff in services but not everything
[21:55:32] <smarlow> Or is there a global service registry?
[21:55:50] <stuartdouglas> Putting the logic in a service is probably the eat to go
[21:55:52] <dmlloyd> all components act as services smarlow
[21:56:07] <dmlloyd> so you've already got one at hand, it's just a question of setting up the dependency
[21:59:01] <smarlow> hmm, I currently have some of both.  From my injectorService, I'll inject a class that is not service aware.  And from that class, I need to do some JTA transaction stuff
[21:59:45] <smarlow> one version of this class, can be serialized and passed to other tiers (the extended persistence case)
[22:01:37] <smarlow> dmlloyd:  If I setup a global service, can I call that from non-service code somehow?
[22:01:54] <Nihility> so basically your parsing deployer would have to have a dep on the tx service
[22:02:00] *** tdiesler has joined #jboss-as7
[22:02:01] *** ChanServ sets mode: +v tdiesler
[22:02:23] <Nihility> although the serialization bit confuses me
[22:02:36] <Nihility> how do you know which to use
[22:02:38] <Nihility> annotation?
[22:02:46] <kkhan> dmlloyd: Can you pull my https://github.com/kabir/jboss-as/commits/jsf-take2? It has https://github.com/kabir/jboss-as/commit/95f35fcf55d9b4024e04b7361ec688416e7f926c and https://github.com/kabir/jboss-as/commit/380479a29dff16b34a7b3697669c2147c09e5004
[22:02:47] <jbossbot> git [jboss-as] 95f35fc.. kabir Push the naming context for the embedded arquillian method invocation as well
[22:02:47] <jbossbot> git [jboss-as] 380479a.. kabir Add Stan's JSF getting started example as a smoke test
[22:03:06] <Nihility> anyone see stan
[22:03:16] <kkhan> He's on PTO
[22:03:20] <Nihility> ah ok
[22:03:23] <smarlow> well, the injected EntityManager, for the extended case, should be replicated to other tiers as part of SFSB replication
[22:03:51] <Nihility> how do you decide which impl of that class to use
[22:04:13] <smarlow> at injection time, I know, based on the type field that we just talked about above.
[22:04:21] *** irooskov has joined #jboss-as7
[22:05:11] <dmlloyd> warning: CRLF will be replaced by LF in testsuite/smoke/src/test/java/org/jboss/as/test/embedded/jsf/JSFTestCase.java
[22:05:11] <kkhan> dmlloyd: Yuck my commit contains some debug printlns, let me fix it
[22:05:14] <dmlloyd> :/
[22:05:19] <aslak> kkhan, your debug code in AbstractDeployableContainer.deploy, can be configured via arquillian.xml. http://docs.jboss.org/arquillian/reference/latest/en-US/html_single/#containers.configuration deploymentExportPath
[22:05:20] <dmlloyd> okay fix that CRLF too :)
[22:05:41] <kkhan> dmlloyd: How?
[22:05:56] <Nihility> kkhan: are you on windows?
[22:06:03] <kkhan> No, OS X
[22:06:17] <Nihility> where did the CR come from, stans patches?
[22:06:59] <kkhan> I copied it from http://anonsvn.jboss.org/repos/jsfunit/trunk/gettingstarted
[22:07:11] <Nihility> oh
[22:07:16] <Nihility> just run dos2unix on it
[22:07:31] <Nihility> you have mac ports?
[22:07:35] <Nihility> sudo port install dos2unix
[22:07:43] <Nihility> then
[22:07:52] <kkhan> You preempted my next question :-)
[22:07:57] <smarlow> Nihility:  so, I'll inject a XPC, which will has our ExtendedEntityManager instance attached to it, at injection time.  The injected ExtendedEntityManager has a reference to the underlying (from the PersistenceProvider) EntityManager.  For the other case, we attach our TransactionalEntityManager which doesn't have an underlying Persistence Provider EntityManager referenced.
[22:08:22] <Nihility> find . -name \*.java -or -name \*.xml | xargs dos2unix
[22:08:58] <smarlow> The TransactionalEntityManager defers the choosing of the underlying EM until invocation time (and that will need JTA transaction stuff).
[22:09:21] *** maxandersen has quit IRC
[22:09:43] <Nihility> smarlow: right but how do you KNOW which to use
[22:09:52] <Nihility> or how does it know
[22:10:02] <Nihility> is it an annotation
[22:10:04] <Nihility> or an xml file
[22:10:14] <Nihility> OH
[22:10:16] <Nihility> i missed that
[22:10:28] <Nihility> so if its at invocation
[22:10:29] <smarlow> Nihility:  For the transactional Entity manager, when its invoked, it looks for a XPC, than the current TX for an existing EM
[22:10:30] <Nihility> that its per instance
[22:10:37] <Nihility> correct?
[22:10:45] <smarlow> yes, per instance
[22:10:54] <kkhan> aslak: Not sure what you mean?
[22:11:04] <Nihility> ok so the transactional dep is only needed at invocation time right?
[22:11:13] <smarlow> yep, correct :)
[22:11:53] <Nihility> ok then you should somehow make sure the deployment depends on the stuff it will need to do that
[22:12:09] <aslak> kkhan, https://github.com/kabir/jboss-as/commit/380479a29dff16b34a7b3697669c2147c09e5004#L3R95  <-- you could get the same feature by configuring arq to export the deployments
[22:12:10] <jbossbot> git [jboss-as] 380479a.. kabir Add Stan's JSF getting started example as a smoke test
[22:13:06] <kkhan> Aha, I see
[22:13:24] <aslak> kkhan, if that is only to be able to see the deployment that is..
[22:13:32] <kkhan> Yep
[22:13:53] <smarlow> Nihility:  oh, I have a JPADependencyProcessor that stuartdouglas  helped me get started.  We inserted dependencies required for JPA dependencies there.  That sounds like the right place.  I'll grab a url
[22:14:16] <Nihility> right so as long as your jpa deps require the transaction service
[22:14:20] <smarlow> https://github.com/scottmarlow/jboss-as/blob/master/jpa/src/main/java/org/jboss/as/jpa/processor/JPADependencyProcessor.java
[22:14:28] <Nihility> or alternatively you add the transaction service
[22:14:47] <Nihility> thats for modules
[22:15:02] <Nihility> you need a service dependency on the transaction system
[22:15:09] <Nihility> unless we have some other gaurantee
[22:15:28] <Nihility> it sounds like it should be an optional dep though
[22:15:36] <smarlow> I can have the PersistenceUnit service depend on the transaction service, to make sure it gets pulled in
[22:15:44] <Nihility> dmlloyd: do we already have a place for deps on common things like the tx service or no
[22:16:10] <dmlloyd> not exactly
[22:16:16] <dmlloyd> you can do it with resource injections but it's ugly
[22:16:23] <dmlloyd> I'm working on a more general solution
[22:16:32] <dmlloyd> gimme like 45 more mintues
[22:18:18] <kkhan> dmlloyd: https://github.com/kabir/jboss-as/commits/jsf-take2 should be better now
[22:19:15] *** stuartdouglas has quit IRC
[22:20:26] <jbossbot> git [jboss-as] push master 95f35fc.. kabir Push the naming context for the embedded arquillian method invocation as well
[22:20:26] <jbossbot> git [jboss-as] push master b8382ac.. kabir Add Stan's JSF getting started example as a smoke test
[22:20:27] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/8931009...b8382ac
[22:23:39] <Nihility> smarlow: can jpa work without transactions
[22:23:48] <Nihility> smarlow: i mean without the subsystem
[22:27:03] *** kkhan has quit IRC
[22:31:10] *** dimitris_jboss has joined #jboss-as7
[22:31:10] *** ChanServ sets mode: +v dimitris_jboss
[22:34:49] *** dimitris_jboss has quit IRC
[22:34:50] *** dimitris_ has quit IRC
[22:35:00] *** jpederse has quit IRC
[22:37:57] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/be5f77e - baileyje / Nihility / smarlow - there it is
[22:37:58] <jbossbot> git [jboss-as] be5f77e.. David M. Lloyd Add a general mechanism for adding injectable service dependencies to a component
[22:38:48] *** Nihility has quit IRC
[22:39:51] *** pgier has quit IRC
[22:41:05] <dmlloyd> :(
[22:41:48] <wolfc> I would rather have seen a pojo style injection
[22:42:42] <dmlloyd> this way is just as good as any other user of MSC injection
[22:42:46] <dmlloyd> which is to say pretty damned good
[22:42:58] <dmlloyd> the component subclass can just declare final fields for each service type
[22:42:58] <wolfc> hehe
[22:43:14] <dmlloyd> then it pulls the ones it needs from the component config and fills it in
[22:43:26] <wolfc> Yeah, spec style injection makes it hard to maintain a proper state
[22:43:46] <dmlloyd> these are all create deps not start deps though, it should be noted
[22:43:55] <dmlloyd> I think create deps cover all the use cases though
[22:44:42] <wolfc> Somehow I feel that at some point we need to expose the ServiceBuilder to sub-classes
[22:44:56] *** miclorb has joined #jboss-as7
[22:45:15] <dmlloyd> yeah probably
[22:45:34] <wolfc> Hmm, maybe we should have an interceptor extension on MSC itself.
[22:45:35] <dmlloyd> this is all gonna get cleaned up for sure
[22:45:42] <dmlloyd> no, that'd be going too far :)
[22:46:04] <wolfc> We are going far right now :-)
[22:46:43] <dmlloyd> it'd be somewhat more elegant to have the component config subclass add the deps to the builder and store the injections individually, where the component can access them via getters
[22:46:55] *** stalep has quit IRC
[22:49:03] <wolfc> Yes, then it will basically be usable service on top of the ServiceBuilder which you could do manually if you ever wanted to do it. Un-opinionated instead of forcing down a fixed path.
[22:50:46] *** pferraro has quit IRC
[22:51:35] <dmlloyd> it's a little goofy because then you have to do a lot more manual work
[22:52:13] <dmlloyd> this way is the least amount of work for component implementors
[22:52:20] *** Nihility has joined #jboss-as7
[22:52:21] *** Nihility has joined #jboss-as7
[22:52:21] *** ChanServ sets mode: +v Nihility
[22:52:22] <wolfc> right, so you would always choose our convenience paths, unless you hit an outside case
[22:53:42] <dmlloyd> anyway this should let us have all our required and optional deps for components without a lot of drama
[22:53:51] <dmlloyd> Nihility: http://github.com/dmlloyd/jboss-as/commit/be5f77e
[22:53:52] <jbossbot> git [jboss-as] be5f77e.. David M. Lloyd Add a general mechanism for adding injectable service dependencies to a component
[22:54:09] <wolfc> smarlow, for Enum you can do: PersistenceContextType.valueOf(annotationInstance.value().asEnum());
[22:55:34] <Nihility> very cool
[22:56:40] *** smarlow has quit IRC
[22:56:58] <Nihility> dmlloyd: looks awesome
[22:59:06] <wolfc> maybe add a shortcut, getInjectionValue(serviceName) { return getInjection(..).getValue(); }
[22:59:29] *** stalep has joined #jboss-as7
[23:00:21] <rmaucher> dmlloyd, last TCK regression: https://github.com/rmaucher/jboss-as/commit/980b3c780792e1c07e6cd2276b1f0d09ff8771be
[23:00:22] <jbossbot> git [jboss-as] 980b3c7.. Rémy Maucherat Fix annotation field name for @WebFilter name.
[23:00:55] <wolfc> If you push it, I'll rebase the CMT tx interceptor stuff onto that tomorrow.
[23:01:01] <dmlloyd> okat
[23:01:01] <dmlloyd> okay
[23:01:06] <dmlloyd> rmaucher: checking it out now
[23:01:20] <jbossbot> git [jboss-as] push master be5f77e.. David M. Lloyd Add a general mechanism for adding injectable service dependencies to a component
[23:01:20] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/b8382ac...be5f77e
[23:01:25] * wolfc is getting some zzz now
[23:02:22] <jbossbot> git [jboss-as] push master c71f978.. Rémy Maucherat Fix annotation field name for @WebFilter name.
[23:02:22] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/be5f77e...c71f978
[23:04:31] <rmaucher> thanks :)
[23:04:54] *** wolfc has quit IRC
[23:05:22] *** asoldano_away has quit IRC
[23:09:56] *** Darran_L has joined #jboss-as7
[23:16:29] *** Darran_L has quit IRC
[23:20:57] *** kkhan has joined #jboss-as7
[23:20:58] *** ChanServ sets mode: +v kkhan
[23:22:29] *** Darran_L has joined #jboss-as7
[23:25:52] *** frainone has quit IRC
[23:27:06] *** Darran_L has quit IRC
[23:30:27] *** kkhan has quit IRC
[23:43:20] *** stalep has quit IRC
[23:45:29] *** stuartdouglas has joined #jboss-as7
[23:45:30] *** ChanServ sets mode: +v stuartdouglas
[23:50:30] *** tdiesler has quit IRC

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