[00:00:10] *** Darran_L has quit IRC
[00:00:45] *** Darran_L has joined #jboss-as7
[00:01:04] *** irooskov has joined #jboss-as7
[00:02:19] <dmlloyd> smarlow: here's how you do it (this week)
[00:02:44] <dmlloyd> smarlow: am I correct in assuming that there is only one global thing you're trying to inject?
[00:03:10] <dmlloyd> smarlow: or is it an instance-per-deployment thing or instance-per-component(aka EJB, servlet, MB etc)
[00:03:26] <smarlow> I have a global service that I could put the logic into that deals with injection but I have many different objects that i will inject
[00:03:55] <dmlloyd> ok so basically, you need to have an MSC service for each thing you're injecting, which has to implement Service<ManagedReferenceFactory>
[00:04:30] <smarlow> ah, okay. makes sense
[00:05:24] <dmlloyd> once you have that, you then need to determine (a) what JNDI bindings must be made and (b) where you're injecting these things in to
[00:06:18] <dmlloyd> if you only need to bind into JNDI then you can disregard (b)
[00:07:12] <smarlow> I need so I can support some hibernate extensions (at some point)
[00:07:21] <smarlow> oops, I need B, I meants
[00:07:46] <dmlloyd> ok well if injection is normally done (for example) via @Resource then you don't need to worry about it (other code does that for you)
[00:07:55] <dmlloyd> but if you have to implement some injection annotation then you do
[00:08:20] <dmlloyd> to get (a) working, what you need to do is create a BindingDescription for each binding
[00:08:34] <dmlloyd> and attach it to a component
[00:08:56] *** smcgowan has quit IRC
[00:08:59] * dmlloyd makes a note that we should probably have module-wide bindings too...
[00:10:48] <smarlow> I have most of the code together for that (based on ResourceInjectionAnnotationParsingProcessor) but was just missing a few steps.   https://github.com/scottmarlow/jboss-as/raw/master/jpa/src/main/java/org/jboss/as/jpa/processor/JPAAnnotationParseProcessor.java
[00:12:38] <dmlloyd> looks reasonable at a glance
[00:15:25] *** asoldano has quit IRC
[00:16:49] *** frainone is now known as frainone_dinner
[00:20:46] *** pferraro has joined #jboss-as7
[00:20:46] *** ChanServ sets mode: +v pferraro
[00:26:45] *** pgier has quit IRC
[00:27:14] <Nihility> Holy shit
[00:27:32] <Nihility> Thats alot of merges
[00:28:39] <Nihility> stuartdouglas: I stepped away to get food for family did lloyd merge your tree?
[00:30:28] <dmlloyd> yeah I got it
[00:37:59] *** pferraro has quit IRC
[00:55:50] *** Darran_L has quit IRC
[01:00:01] *** pferraro has joined #jboss-as7
[01:00:01] *** ChanServ sets mode: +v pferraro
[01:01:54] *** opalka has quit IRC
[01:02:10] *** alesj has quit IRC
[01:02:16] *** Darran_L has joined #jboss-as7
[01:04:35] *** pferraro has quit IRC
[01:05:22] *** jpearlin has joined #jboss-as7
[01:06:41] *** Darran_L has quit IRC
[01:09:51] *** frainone_dinner is now known as frainone
[01:10:51] *** jwulf has joined #jboss-as7
[01:12:56] *** Darran_L has joined #jboss-as7
[01:17:11] *** Darran_L has quit IRC
[01:21:07] <stuartdouglas> I'm going to be offline for a few hours
[01:21:26] *** stuartdouglas has left #jboss-as7
[01:46:23] <Nihility> Halo
[01:46:39] <jamezp> Nihility: If you're around I've a quick question about the maven plugin.
[01:47:18] <Nihility> Intelligently for awhile what's up
[01:48:09] <jamezp> From what I'm understanding we basically want to take a WAR file (or what ever valid packaging) and deploy it to a server.
[01:48:29] *** rawblem has joined #jboss-as7
[01:48:29] *** ChanServ sets mode: +v rawblem
[01:48:30] <Nihility> exactly
[01:48:34] <jamezp> I'm a bit confused on how I should be doing the deploy.
[01:48:51] <rawblem> just wanted to say i got closest yet to building as7 on my new laptop ;)  didn't fail until smoke tests
[01:48:52] <rawblem> woot
[01:48:56] <jamezp> Should I be pluging in to the CLI and piping out commands or is there a better way?
[01:49:20] <Nihility> yes using the java remote API
[01:49:49] <Nihility> thats what th cli uses
[01:50:17] <Nihility> you have a remote modelcontroller
[01:50:27] <jamezp> Okay, I'll look into from that aspect then :-) I had a feeling, but I felt I was chasing my tail for a moment.
[01:50:56] <Nihility>  and you give he model controller dmr requests
[01:51:39] <jamezp> Okay, so if I just dig through what the CLI is doing, I should be able to figure it out.
[01:51:43] <Nihility> those operation handlers I pointed you to, those implement the server side of reducing the equest and procssngbit
[01:52:13] <Nihility> receiving the request and processing it
[01:52:41] <jamezp> Ah-ha. Okay, that makes a little more sense.
[01:53:17] <Nihility> so the deploy process is two seps
[01:53:58] <Nihility> 1) add the content(deployment) to the repo via a stream
[01:54:55] <Nihility> 2) deploy (or replace) the hash you get from 1
[01:55:20] <jamezp> Perfect. It's starting to make sense in my pea sized brain now :-)
[01:55:49] <Nihility> basically 1 sticks it on the fileystsem in a special hash indexed directory
[01:56:02] <Nihility> and 2 adds it to the XML
[01:56:45] <jamezp> That makes sense. I like it.
[01:56:54] <Nihility> the basic idea is that you can disable and enable a deployment wthout resenting it that's why it's not one operation
[01:58:00] <Nihility> but the maven plugin probably needs to always do both
[01:58:12] <jamezp> Cool! I watched bstansberry's videos on the domain deployment stuff. Looks awesome.
[01:58:34] <jamezp> Right, I'll get something working so we can add any kind of functionality we want ;-)
[01:59:44] <bstansberry> jamezp: if you look at the stuff in the demos module, most of them do some sort of deployment via the java remote API
[02:00:10] <jamezp> Cool. That's good to know. Thanks! I'll be looking for sure.
[02:00:58] <jamezp> I started digging around, but as I'm sure you know it's rather massive. So I went with the lazy approach and just asked. :-D
[02:01:45] <bstansberry> asking is good :)
[02:02:18] <jamezp> :-)
[02:06:29] *** jwulf has quit IRC
[02:09:13] *** bstansberry is now known as bstans_afk
[02:11:36] *** rawblem has quit IRC
[02:24:20] *** fnasser has quit IRC
[02:31:13] *** jamezp has left #jboss-as7
[02:47:00] <jpearlin> Nihility:  I believe that I fixed that issue with the content boundaries for the file upload stuff...
[02:47:10] <jpearlin> I have some clean-up to do, but I should have at least a first cut patch of it for you tonight
[02:57:24] *** bstans_afk has quit IRC
[02:57:28] *** bstansberry has joined #jboss-as7
[02:57:28] *** ChanServ sets mode: +v bstansberry
[03:14:26] *** mbg has joined #jboss-as7
[03:14:26] *** ChanServ sets mode: +v mbg
[03:14:38] *** mbg has quit IRC
[03:30:30] *** aslak has quit IRC
[03:41:47] *** pferraro has joined #jboss-as7
[03:41:47] *** ChanServ sets mode: +v pferraro
[03:47:53] *** jpearlin has quit IRC
[04:05:55] *** stuartdouglas has joined #jboss-as7
[04:05:55] *** stuartdouglas has quit IRC
[04:05:55] *** stuartdouglas has joined #jboss-as7
[04:05:55] *** ChanServ sets mode: +v stuartdouglas
[04:11:05] *** asaldhan has left #jboss-as7
[04:14:18] *** pferraro has left #jboss-as7
[04:17:37] *** smcgowan has joined #jboss-as7
[04:24:36] *** smcgowan has quit IRC
[04:26:19] <smarlow> seems like RESOURCE_ROOTS can be null now, checking for null...
[04:27:11] <dmlloyd> github has gone bye-bye
[04:29:03] *** miclorb_ has quit IRC
[04:29:10] <stuartdouglas> smarlow: use getAttachmentList
[04:29:25] <stuartdouglas> if it is null it will return an empty list
[04:29:41] <smarlow> stuartdouglas:  cool, I'll switch to that...
[04:29:45] <Nihility> just so you guys now
[04:29:50] <Nihility> my jbossas mirror is active
[04:29:55] <Nihility> if you need it
[04:29:56] <Nihility> :)
[04:30:07] <stuartdouglas> I'm about to get on a plane in about 5 minutes
[04:30:17] <stuartdouglas> I found the web service problem to
[04:30:24] <Nihility> stuartdouglas: have a safe trip
[04:30:33] <stuartdouglas> the NPE happens when they try and inject the WebServiceContext
[04:30:42] <stuartdouglas> if we implement that it will go away :-)
[04:31:04] <Nihility> ah why the NPE?
[04:31:24] <stuartdouglas> there is no BindingSourceDescription
[04:31:45] <dmlloyd> that'd do it
[04:31:49] <stuartdouglas> (we also need to make sure that this is a meaningful error message in future)
[04:32:34] <dmlloyd> http://twitter.com/github#
[04:33:06] <Nihility> http://git.engineering.redhat.com/?p=users/jgreene/jboss-as.git;a=summary
[04:34:03] <dmlloyd> probably be back up in a few minutes
[04:34:14] <dmlloyd> when something goes wrong these guys pretty much jump on it
[04:34:23] <dmlloyd> I thing the response time was like 2 minutes
[04:35:40] *** stuartdouglas has quit IRC
[04:41:18] *** miclorb has joined #jboss-as7
[04:47:58] *** stuartdouglas has joined #jboss-as7
[04:47:58] *** ChanServ sets mode: +v stuartdouglas
[04:48:31] <stuartdouglas> computer just crashed
[04:49:51] *** stuartdouglas has quit IRC
[04:53:37] <smarlow> And we're back. Thanks for your patience!
[04:53:56] <dmlloyd> Nihility: what's left on the hit list for Beta1
[04:54:12] <dmlloyd> now that EJBs are getting off the ground
[04:54:29] <Nihility> i was just going to ask you
[04:54:36] <Nihility> hahaha
[04:54:43] <dmlloyd> I think we should make sure we have good coverage of all those annotation types
[04:54:47] <Nihility> so do we have working components
[04:54:52] <dmlloyd> yeah
[04:54:56] <Nihility> like slsb
[04:54:57] <Nihility> sfsb
[04:54:59] <smarlow> how much time is left for jpa?
[04:54:59] <Nihility> singleton
[04:55:05] <Nihility> oh yeah we need jpa
[04:55:16] <dmlloyd> smarlow: not a lot, but we're here to help if you hit any trouble
[04:55:55] <dmlloyd> so JPA, you got the DS thing, @Resource is working
[04:56:25] <dmlloyd> it's kinda weird, suddenly everything is coming together all at once
[04:56:51] <dmlloyd> I can think of a dozen plus code cleanups off the top of my head but it seems to me like we should be focusing on locking down any missing functionality first
[04:57:17] <Nihility> we need to try and deploy some ee web profile app
[04:57:22] <dmlloyd> are there any other web profile things we're missing?  java mail?  any JMS things?
[04:57:24] <Nihility> and find out what breaks
[04:57:32] <dmlloyd> well that might be hairy without descriptor parsing
[04:57:41] <Nihility> yeah a pure annotations app
[04:57:48] <dmlloyd> we could probably start right in on that though, if everything else is square
[04:58:02] <Nihility> right thats what i as thinking
[04:58:06] <Nihility> do we have transactions?
[04:58:18] <dmlloyd> supposedly
[04:58:25] <dmlloyd> it's bound into JNDI
[04:58:31] <dmlloyd> I don't know what the status of the txn interceptor is though
[04:58:42] <dmlloyd> interceptorS actually since there'd be a client and component one
[04:58:51] <dmlloyd> we need @Remote support too
[04:59:19] <Nihility> yeah thats what i mean tx interceptor
[05:01:00] <smarlow> do we have ejb3 interceptors that i can integrate JPA with?
[05:01:07] <dmlloyd> sure
[05:01:10] <dmlloyd> theoretically
[05:01:30] <dmlloyd> :D
[05:02:40] <dmlloyd> smarlow, I'd start by implementing Interceptor and seeing where that leads you.
[05:03:23] <dmlloyd> then think about where you want that interceptor to go (in relationship to other interceptors and thinking from both the client (outbound) perspective as well as the server (inbound) perspective)
[05:06:25] <smarlow> InterceptorDescription?  Interceptor didn't match anything in intellij for some reason
[05:06:36] <dmlloyd> it's in the jboss-interceptors project
[05:08:56] <dmlloyd> we also have EJB security to implement, I believe
[05:09:23] <dmlloyd> and MDBs of course
[05:09:32] <dmlloyd> which shouldn't be too hard actually...
[05:09:35] <Nihility> https://github.com/n1hility/jboss-modules/commit/b3ac9b120b93d44266eaeb5bd43a437a71f746c9
[05:09:36] <jbossbot> git [jboss-modules] b3ac9b1.. Jason T. Greene MODULES-79 - SAXTransformerFactory support
[05:09:37] <jbossbot> jira [MODULES-79] Support SAXTransformerFactory redirection [Open (Unresolved) Feature Request, Major, Jason Greene] https://issues.jboss.org/browse/MODULES-79
[05:10:42] <dmlloyd> looks good
[05:10:52] <dmlloyd> are there any other specializations of TransformerFactory we should support?
[05:11:05] <Nihility> thats the only one i think that exists
[05:11:06] <dmlloyd> it probably would have been faster for me to just look than type that out :)
[05:11:24] <dmlloyd> yeah looks like it
[05:12:13] <smarlow> dmlloyd:  is https://github.com/jbossinterceptors/jbossinterceptors the right place to look for jboss-interceptors?
[05:12:20] <dmlloyd> no
[05:12:22] <dmlloyd> sorrty
[05:12:25] <dmlloyd> jboss-invocation
[05:12:31] <smarlow> I should of just asked :)
[05:12:40] <dmlloyd> https://github.com/jbossas/jboss-invocation
[05:12:47] * dmlloyd has interceptors on the brain
[05:12:57] <smarlow> I'll add it to the cheat sheet
[05:13:56] <Nihility> yeah imo i think we need some kind of small demo/sample app
[05:14:02] <Nihility> either we take something and modify it
[05:14:22] <dmlloyd> yeah a real demo
[05:14:23] <Nihility> well thats probably the only reasonable option
[05:14:38] <Nihility> just to make sure we have all the core pieces working
[05:14:42] <Nihility> and it allows us to say
[05:14:44] <Nihility> hey look
[05:14:47] <Nihility> an ee app deploys
[05:14:50] <Nihility> say hello to beta 1
[05:15:15] <Nihility> there is already a bunch of weld demos
[05:15:15] <dmlloyd> frainone is available for AS7 tasks if needed, and baileyje will be around tomorrow too
[05:15:26] <Nihility> but it would be nice to have one thats non-weld as well
[05:15:31] <dmlloyd> what do you think about security though
[05:15:46] <dmlloyd> it's kind of a big unknown it seems
[05:16:03] <Nihility> honestly i think the security subsystem is not finished yet
[05:16:14] <Nihility> jesper was saying it has issues
[05:16:32] <dmlloyd> ok so I see the possibility for a few tasks:
[05:16:34] <dmlloyd> 1) @Remote
[05:16:38] <Nihility> so its probably not worth doing a lot of work on security interceptors
[05:16:41] <dmlloyd> 2) Txn interceptors
[05:17:05] <dmlloyd> 3) XML descriptor parsing for EJBs
[05:17:09] <dmlloyd> 4) MDBs
[05:17:39] *** miclorb has quit IRC
[05:17:40] <Nihility> so we cant do mdbs without 3
[05:17:47] <Nihility> they are in xml only
[05:18:05] <Nihility> @Remote isnt that interesting without remoting integration
[05:18:12] <dmlloyd> what about @MessageDriven
[05:18:13] <Nihility> so that leaves 2 and 3
[05:18:23] <dmlloyd> @Remote is actually interesting for in-container stuff
[05:18:24] <dmlloyd> pass-by-value
[05:18:39] <dmlloyd> remoting access to @Remote is actually a pretty different process
[05:19:27] <Nihility> so there is also
[05:19:29] <Nihility> @Resource Queue
[05:19:31] <Nihility> and so on
[05:19:46] <Nihility> but that i thought also needed xml
[05:20:00] <dmlloyd> well using @Resource to inject stuff is already done for any resource type
[05:20:13] <dmlloyd> it's getting stuff bound that is still needed for queues and stuff
[05:20:52] *** ALR has joined #jboss-as7
[05:20:52] *** ChanServ sets mode: +v ALR
[05:21:01] <Nihility> hmm
[05:21:13] <Nihility> yeah the issue there
[05:21:26] <Nihility> is that hornetq treats the whole thing
[05:21:42] <Nihility> as more like a table
[05:21:52] <Nihility> than a thing with a lifecycle
[05:22:08] <dmlloyd> that's fine, things bound into JNDI don't have to have a lifecycle per se
[05:22:24] <dmlloyd> the reference thing that stuart wrote is really pretty flexible
[05:26:24] <dmlloyd> I wonder if Jaikiran implemented support for @DependsOn
[05:26:42] <dmlloyd> and @EJB
[05:26:47] <dmlloyd> if not, add those to the list
[05:26:57] <Nihility> yes those are critical
[05:27:06] <dmlloyd> @Lock
[05:27:19] <dmlloyd> and @LocalBean
[05:27:38] <dmlloyd> there's a bunch of 2.x stuff too like @LocalHome and @RemoteHome
[05:28:25] <dmlloyd> async invocation
[05:28:55] <dmlloyd> eager singletons
[05:29:31] *** miclorb has joined #jboss-as7
[05:30:47] <Nihility> \http://netbeans.org/projects/samples/downloads/directory/Samples/JavaEE
[05:30:48] *** jamezp has joined #jboss-as7
[05:31:47] <Nihility> NewsApp :)
[05:31:49] <Nihility> haha
[05:32:19] <dmlloyd> ah, timers
[05:32:40] <Nihility> oh you know
[05:33:03] <Nihility> ALR: hey did you do like a combo demo for your ejb 3.1 book?
[05:33:30] <ALR> Nihility: Combo of what?
[05:33:39] <dmlloyd> XML + annotations
[05:33:40] <Nihility> like an ejb3 demo thing
[05:33:52] <Nihility> that used a bunch of features
[05:34:04] <ALR> Nihility: I tried to isolate the features best I could.
[05:34:10] <ALR> That said, there had to be some overlap.
[05:34:23] <Nihility> so basically we are close to releasing
[05:34:29] <ALR> Like the interceptors example uses a @Stateless...
[05:34:35] <Nihility> official dealine is 15yh
[05:34:45] <Nihility> and we are trying to get the most bang for our buck
[05:34:46] <Nihility> as it were
[05:34:48] <ALR> https://github.com/jbossejb3/oreilly-ejb-6thedition-book-examples
[05:35:41] *** irooskov has quit IRC
[05:36:11] <Nihility> ah cool
[05:36:16] <Nihility> so we have some stuff to try
[05:36:23] <ALR> Yeah, play around :)
[05:36:29] <ALR> And lemme know if you need anything specifically.
[05:36:30] <Nihility> smarlow: how do you feel about JPA support?
[05:36:38] <ALR> Some of those are configured to run on OpenEJB or GFv3
[05:37:57] <Nihility> damn madeline is up
[05:38:02] <Nihility> bbl
[05:39:39] <dmlloyd> ok so 12 things on the EJB todo list
[05:39:52] <dmlloyd> 12 possible things for M2
[05:42:56] <smarlow> Nihility:  there is the ejb3 interceptor/lifecycle integration which hasn't started yet.  I don't think it will be a huge deal, as long as we can do what we need to.  Otherwise, I have a little more annotation injection work.  I need to integrate with JTA and use it for some container management tasks.  One wild card is that I need access to the current EJBContext (so I can build a TLS invocation stack of them) for extended persistence managemen
[05:42:56] <smarlow> t.  fix bugs, write tests
[05:44:20] <smarlow> dmlloyd:  if I get to a stable point tomorrow, should we try to merge the current jpa source in?  I have a lot of rebasing to do probably.  :)
[05:44:31] <dmlloyd> yeah we can look at that
[05:44:32] <smarlow> I rebased twice and stopped
[05:44:38] <dmlloyd> :)
[05:45:00] <dmlloyd> the component stuff should stay stable until after the release unless we discover a major problem
[05:45:10] <dmlloyd> that's where the bulk of integration happens
[05:45:29] <dmlloyd> so conflicts seem unlikely at this point, after you get rebased tomorrow
[05:47:31] <smarlow> ALR:  how many people showed up for Dan's talk?
[05:48:45] * smarlow i wanted to go but needed to get ready for tomorrow
[05:49:55] * smarlow speaking of which, I need to get some sleep, good night
[05:54:34] <dmlloyd> 'night
[05:54:41] <dmlloyd> I'm about to fold it up myself
[05:54:58] *** smarlow has quit IRC
[05:59:23] *** ALR1 has joined #jboss-as7
[06:01:45] *** ALR has quit IRC
[06:03:56] <dmlloyd> https://github.com/dmlloyd/jboss-as/commit/5a16fe1d2
[06:03:57] <jbossbot> git [jboss-as] 5a16fe1.. David M. Lloyd Asynchronous invocation interceptor
[06:04:20] <dmlloyd> with props to ALR's original implementation, from which ideas were gratuitously stolen
[06:05:08] <dmlloyd> and with that, I'm for bed... would be great if someone could touch base with Jaikiran when he comes on in a few hours to see what his list looks like compared to ours
[06:05:14] <dmlloyd> and wolfc when he's up
[06:05:26] * dmlloyd will try to get up earlier tomorrow, but don't expect 4am
[06:05:29] * dmlloyd o/
[06:08:03] <Nihility> Night
[06:08:23] <Nihility> Thanks for brainstorming
[06:08:38] *** bgeorges has joined #jboss-as7
[06:08:38] *** ChanServ sets mode: +v bgeorges
[06:42:15] *** bstansberry has quit IRC
[06:55:45] *** jamezp has quit IRC
[07:18:38] *** baileyje has joined #jboss-as7
[07:18:39] *** ChanServ sets mode: +v baileyje
[07:23:57] *** bgeorges has quit IRC
[07:43:30] *** jwulf has joined #jboss-as7
[07:45:28] *** stuartdouglas has joined #jboss-as7
[07:57:10] *** stuartdouglas has quit IRC
[08:03:11] *** jwulf has quit IRC
[08:03:19] *** jwulf has joined #jboss-as7
[08:10:24] *** Jaikiran has joined #jboss-as7
[08:10:34] *** ChanServ sets mode: +v Jaikiran
[08:11:33] *** jfclere has joined #jboss-as7
[08:11:33] *** ChanServ sets mode: +v jfclere
[08:18:28] *** tdiesler has joined #jboss-as7
[08:18:28] *** ChanServ sets mode: +v tdiesler
[08:36:09] *** rmaucher has joined #jboss-as7
[08:46:50] *** bgeorges has joined #jboss-as7
[08:49:53] *** opalka has joined #jboss-as7
[08:49:53] *** ChanServ sets mode: +v opalka
[09:15:09] *** tdiesler has quit IRC
[09:22:37] *** emmanuel has joined #jboss-as7
[09:22:37] *** ChanServ sets mode: +v emmanuel
[09:26:30] *** tdiesler has joined #jboss-as7
[09:26:30] *** ChanServ sets mode: +v tdiesler
[09:37:54] *** asoldano has joined #jboss-as7
[09:37:54] *** ChanServ sets mode: +v asoldano
[09:42:36] *** emuckenhuber has quit IRC
[09:54:26] *** AndyTaylor has joined #jboss-as7
[09:54:26] *** ChanServ sets mode: +v AndyTaylor
[09:57:29] *** wolfc has joined #jboss-as7
[09:57:29] *** ChanServ sets mode: +v wolfc
[10:00:02] *** kkhan has joined #jboss-as7
[10:00:02] *** ChanServ sets mode: +v kkhan
[10:00:29] *** bgeorges has quit IRC
[10:03:40] *** miclorb has quit IRC
[10:05:03] *** bgeorges has joined #jboss-as7
[10:05:08] *** emuckenhuber has joined #jboss-as7
[10:05:08] *** ChanServ sets mode: +v emuckenhuber
[10:14:59] <tdiesler> kkhan, ping
[10:22:10] *** bgeorges has quit IRC
[10:24:18] *** bgeorges has joined #jboss-as7
[10:25:49] *** kkhan has quit IRC
[10:31:01] <rmaucher> wolfc, so I am looking at the Servlet annotations using jandex now
[10:44:59] *** maxandersen has quit IRC
[10:45:29] *** maxandersen has joined #jboss-as7
[10:45:33] *** maxandersen has quit IRC
[10:45:33] *** maxandersen has joined #jboss-as7
[10:45:33] *** ChanServ sets mode: +v maxandersen
[10:48:18] *** emmanuel has quit IRC
[10:55:27] <wolfc> rmaucher, where is that?
[10:56:21] *** jcosta has joined #jboss-as7
[10:56:21] *** ChanServ sets mode: +v jcosta
[10:57:44] <rmaucher> nowhere committed yet
[10:58:02] <rmaucher> but the Servlet annotations are a bit complex, with lots of nesting
[10:58:18] <rmaucher> so I am not certain jandex is more efficient for that
[10:58:43] <rmaucher> beyond initially finding the annotated class, I mean
[10:59:13] <wolfc> once you have a class hierarchy jandex can still play along
[11:00:39] <wolfc> https://github.com/wolfc/jandex/commit/752673c3f460885ba9fb77eb5d7a8826e094a45c#L0R66
[11:00:40] <rmaucher> I know, but it's not nice coding
[11:00:40] <jbossbot> git [jandex] 752673c.. Carlo de Wolf Added a method test case
[11:01:12] <wolfc> it should fit into jboss-metadata without much of an issue
[11:01:33] <rmaucher> so I am using AnnotationValue.asNestedArray
[11:01:50] <rmaucher> in the end, I don't quite understand how it is going to be any fatsre
[11:01:53] <rmaucher> fatser
[11:01:56] <rmaucher> faster
[11:02:05] *** maxandersen has quit IRC
[11:03:25] <wolfc> https://github.com/jfclere/metadata/blob/master/common/src/main/java/org/jboss/metadata/annotation/creator/AbstractProcessor.java is the bit that is slowing it up
[11:03:42] <wolfc> getInterfaces(), getDeclaredFields(), getDeclaredMethods() are evil
[11:03:52] <wolfc> Well maybe not getInterfaces()
[11:04:16] <wolfc> Jaikiran, did you ever push your final installment of bringing jandex into jboss-metadata?
[11:04:22] *** alesj has joined #jboss-as7
[11:07:42] <rmaucher> ok
[11:08:42] <wolfc> In essence it should boil down to: a processor knows which annotations it wants. So instead of the processor finding the annotation, we could use jandex to find it instead.
[11:10:35] <wolfc> Then pass that result into a Creator which doesn't query the finder and voila. Software falls from the skies.
[11:10:37] *** maxandersen has joined #jboss-as7
[11:10:37] *** ChanServ sets mode: +v maxandersen
[11:10:47] <rmaucher> well, yes, but it's really a bit annoying to code
[11:10:53] <Jaikiran> wolfc: i have some uncompilable WIP changes to jbmeta (which i ditched after deciding about jbmeta). but I can commit a few changes which I had done last week initially
[11:11:16] <Jaikiran> the annoying part is to having to redo it all again :)
[11:11:33] <Jaikiran> i mean having to code up those processors in this new way
[11:11:50] <Jaikiran> that's what was slow and boring
[11:11:55] <rmaucher> jandex is not nice dealing with custom types and nested annotations ... :(
[11:12:17] <rmaucher> I understand it is good for @Singleton
[11:12:51] <Jaikiran> are you trying this within JBMETA or within AS7 code?
[11:13:22] <Jaikiran> i was of the impression thta we had given up on jbmeta
[11:13:48] <rmaucher> I am moving this annotation processing code to WarAnnotationDeploymentProcessor
[11:14:10] <rmaucher> which is now calling the jbmeta annotation processors
[11:15:59] <Jaikiran> looking at the BasicTestCase in jandex project, nested annotation processing looks OK
[11:16:19] <Jaikiran> the one thing that i have disliked so far in jandex is the use of those strings
[11:16:23] <rmaucher> I know the API
[11:16:24] <Jaikiran> to query the annotation attribute values
[11:16:26] <rmaucher> I'm using it
[11:16:35] <rmaucher> it's just annoying to ise ;)
[11:16:38] <rmaucher> use
[11:16:43] <Jaikiran> :)
[11:16:59] <rmaucher> AnnotationInstance.asNestedArray, youhou !
[11:19:35] <rmaucher> for enums, it goes through the enum string value (asEnum returns String)
[11:19:39] <rmaucher> so bleh
[11:20:16] <wolfc> Yeah, that looks wicked. I'm not sure how it affects performance, but it can't be better.
[11:20:41] <wolfc> On the other hand jandex doesn't load classes.
[11:20:48] <wolfc> So it doesn't go through a CL
[11:21:07] <rmaucher> yes ok
[11:21:26] <rmaucher> those are servlet and filters that will get loaded 5s later, though
[11:22:09] <wolfc> I agree
[11:24:16] <rmaucher> ok, so I believe I did @WebServlet ;) only 6 more to go
[11:31:10] <opalka> rmaucher, jfclere Did U see this issue before? - http://fpaste.org/8GH5/
[11:31:58] <rmaucher> yes, it's caused by the new security code
[11:32:11] <rmaucher> but I don't know how to fix it ;)
[11:32:33] <emuckenhuber> afaik shelly filed a jbcts issue for this as well
[11:33:01] <opalka> rmaucher, NP, just wanted to hear if it's known or not ;)
[11:33:07] * opalka 's excluding tests for now ...
[11:33:24] <rmaucher> I don't actually know how to port the security config for AS 7 and the TCK, at the moment
[11:33:37] <opalka> rmaucher, :(
[11:33:55] <rmaucher> feedback has been to avoid using JNDI to pass around components, like security is doing right now
[11:34:40] <opalka> rmaucher, Is there a JBAS JIRA for that?
[11:35:01] <rmaucher> I don't know ;)
[11:35:09] <opalka> rmaucher, OK, thx
[11:38:48] *** asoldano is now known as asoldano_away
[11:41:01] *** miclorb_ has joined #jboss-as7
[11:42:49] *** stuartdouglas has joined #jboss-as7
[11:45:30] *** stuartdouglas has quit IRC
[12:09:01] *** miclorb_ has quit IRC
[12:17:09] *** miclorb_ has joined #jboss-as7
[12:34:11] *** miclorb_ has quit IRC
[12:35:25] *** darranl_afk is now known as darranl
[12:46:24] *** asoldano_away is now known as asoldano
[13:13:48] *** asoldano is now known as asoldano_lunch
[13:28:38] *** jwulf has quit IRC
[13:36:21] *** jbossbot has quit IRC
[13:37:02] *** dmlloyd has quit IRC
[13:47:21] *** dmlloyd has joined #jboss-as7
[13:47:21] *** ChanServ sets mode: +v dmlloyd
[13:47:40] <dmlloyd> hard crash just before I got up
[13:47:53] * dmlloyd mildly irritated
[13:51:43] <dmlloyd> okay so there are basically 14 items we've identified as possible tasks for EJB before the release
[13:51:58] <dmlloyd> of these, JPA is being worked on smarlow and security is ????
[13:52:58] <dmlloyd> otherwise we have: @Remote/PBV, Txn interceptors, XML descriptors, @MessageDriven, @DependsOn, @EJB, @Lock, @LocalBean & other EJB2-ish things, eager singleton, timers, async invocation, no-interface view
[13:53:19] <dmlloyd> as far as resources, we have several people who should be available to pitch in
[13:54:14] <dmlloyd> so my question, for Jaikiran and wolfc, is: which of these tasks should be easily doable, and how can we divide them up?
[13:54:57] <Jaikiran> dmlloyd: i am currently working on @Singleton
[13:55:04] <Jaikiran> wolfc is working on tx interceptors
[13:55:16] <Jaikiran> what's PBV?
[13:55:20] <dmlloyd> pass by value
[13:55:23] <wolfc> security is out of scope not?
[13:55:41] <wolfc> @Remote is non web-profile
[13:55:42] <dmlloyd> wolfc: yeah.  not because we planned for it to be though.
[13:55:49] <wolfc> Ah okay :-)
[13:55:52] <Jaikiran> dmlloyd: @LocalBean is done a few hours back https://github.com/jaikiran/jboss-as/commits/ejb3
[13:56:00] <dmlloyd> excellent, Jaikiran.
[13:56:11] <dmlloyd> FYI I did merge into upstream last night, in case you didn't see.
[13:56:20] <wolfc> We saw, excellent
[13:56:23] <Jaikiran> yeah, saw that this morning :)
[13:56:28] <dmlloyd> so make sure you're rebased on that
[13:56:32] <Jaikiran> yep
[13:56:48] <wolfc> Timers and async is not web-profile
[13:56:55] <Jaikiran> those latest commits have been on top of latest upstream
[13:57:00] <dmlloyd> ok good
[13:57:03] <wolfc> Same for MDB
[13:57:35] <Jaikiran> are we still targeting xml desc for this release?
[13:57:36] <wolfc> We need to have EJBContainer embeddable
[13:58:29] *** bobmcw has quit IRC
[13:59:52] <Jaikiran> so yeah, i'll take up @DependsOn, @Lock since it's part of @Singleton
[14:00:24] <Jaikiran> we just need to beef up the testsuite bits too for all these new stuff
[14:00:54] <dmlloyd> and @Startup
[14:01:20] <dmlloyd> web profile is the priority for this release but the more we can get in there the better
[14:01:29] <Jaikiran> yeah, @startup too
[14:01:54] *** smarlow has joined #jboss-as7
[14:01:54] *** ChanServ sets mode: +v smarlow
[14:03:22] <wolfc> Jaikiran, I'm rewriting bits of the annotation processors
[14:03:52] *** kkhan has joined #jboss-as7
[14:03:52] *** ChanServ sets mode: +v kkhan
[14:03:59] <wolfc> since smarlow is here, we need a test for injection of XPC
[14:04:11] <dmlloyd> smarlow was also looking at adding interceptors for JPA
[14:04:21] <dmlloyd> we don't really have a general thing for adding interceptors
[14:04:30] *** asoldano_lunch is now known as asoldano
[14:04:37] <smarlow> good morning :)
[14:04:49] <dmlloyd> morning smarlow
[14:04:59] <Jaikiran> wolfc: what parts of the annotation processors? anything that i should be aware of for processing other annotations on singleton beans?
[14:05:00] <wolfc> I think we'll just do something wicked in the Configuration
[14:05:41] <wolfc> Jaikiran, just processComponentConfig. It is common across all processors
[14:05:54] <Jaikiran> ok
[14:05:56] <wolfc> I'll get my unit test to pass, then I'll commit
[14:06:00] <Jaikiran> sure
[14:06:13] <smarlow> I don't have interceptors started yet.  I leave for the hospital in a few hours.  I'm thinking I should rebase and get my code merged in.  There aren't any big pieces just little interceptors, JTA integration, some more plumbing...
[14:06:17] <kkhan> Is a BeanManager getting bound somewhere in JNDI in AS 7?
[14:06:36] <wolfc> dmlloyd, smarlow, in Configuration: if(EJBUtilities.hasJPA()) addComponentSystemInterceptorFactory(...);
[14:07:29] <wolfc> Utilities being the gas, water & energy supplier for EJB Components
[14:07:46] <wolfc> So it should have an optional JPA, TransactionManager etc.
[14:08:04] *** jpederse has joined #jboss-as7
[14:08:13] *** jpederse has joined #jboss-as7
[14:08:22] <dmlloyd> ....ah I meant to say "@LocalHome & other EJB2-ish things"
[14:08:59] *** aslak has joined #jboss-as7
[14:08:59] *** aslak has joined #jboss-as7
[14:08:59] *** ChanServ sets mode: +v aslak
[14:10:23] <smarlow> wolfc:  EJBUtilities is something we have?  I do have a JPADeploymentMarker
[14:10:36] *** bgeorges has quit IRC
[14:11:11] <wolfc> smarlow, not yet
[14:11:33] <wolfc> dmlloyd, EJB2-ish stuff is a bitch. I would say leave it out of scope for now.
[14:12:59] * smarlow will be back in 30 minutes...
[14:13:34] *** tdiesler has quit IRC
[14:15:35] *** tdiesler has joined #jboss-as7
[14:15:35] *** ChanServ sets mode: +v tdiesler
[14:18:36] *** jbossbot has joined #jboss-as7
[14:18:36] *** ChanServ sets mode: +v jbossbot
[14:19:06] <dmlloyd> jbossbot was asleep, Jaikiran, but I pushed your change
[14:21:33] <frainone> dmlloyd: good morning
[14:21:45] <wolfc> Jaikiran, https://github.com/wolfc/jboss-as/commit/13450cb805e503fee5dc56799d3603f560ce177c#diff-4
[14:21:47] <jbossbot> git [jboss-as] 13450cb.. Carlo de Wolf Initial work on @TransactionAttribute
[14:22:09] <wolfc> I'm not very proud of https://github.com/wolfc/jboss-as/commit/13450cb805e503fee5dc56799d3603f560ce177c#L1R69 now is the chance for bright ideas
[14:22:09] <jbossbot> git [jboss-as] 13450cb.. Carlo de Wolf Initial work on @TransactionAttribute
[14:22:26] <dmlloyd> kkhan: I hope you don't mind that I assigned JBAS-8937 to you.
[14:22:31] <dmlloyd> morning frainone
[14:22:56] <dmlloyd> JBAS-8934 that is.
[14:22:57] <jbossbot> jira [JBAS-8934] RejectedExecutionExceptions in management API [Open (Unresolved) Bug, Major, Kabir Khan] https://issues.jboss.org/browse/JBAS-8934
[14:22:58] <wolfc> note that that commit might disappear
[14:23:46] <kkhan> dmlloyd: Np, I'll take a look a bit later today
[14:24:04] <wolfc> bah I intermixed refactoring of tests and functionality again.
[14:27:05] <Jaikiran> dmlloyd: thanks!
[14:27:09] <dmlloyd> darranl: just to provide a little more info, Remoting does automatically provide an EXTERNAL SASL mechanism *but* only if you have enabled TLS
[14:27:44] <darranl> dmlloyd, excellent - don't need to implement that one then ;-)
[14:27:58] <dmlloyd> darranl: I think I did have a PLAIN implementation at some point, maybe it's still in there, but it also only works with TLS
[14:28:08] <dmlloyd> which might be overly paranoid :)
[14:28:41] <darranl> at the very least I think we can try and log some scary WARN messages if end users use configurations we think they should avoid ;-)
[14:29:07] <darranl> e.g. Your passwords are at risk of being stolen - please verify your configuration.
[14:30:01] <dmlloyd> also, there's a draft SASL spec for SRP floating out there, but it has some problems
[14:30:14] <dmlloyd> we did support that briefly though
[14:31:07] <darranl> from what I remember of SRP if we get everything in place to support Digest comfortably that one shouldn't be as bad to add retrospectively
[14:32:37] <dmlloyd> and ultimately I want to come up with some keypair-based mechanism...
[14:33:21] <darranl> going as far as proposing an RFC for a new mechanism?
[14:33:34] <dmlloyd> maybe
[14:33:41] <darranl> cool ;-)
[14:34:25] <darranl> Although spending plenty of time reading RFCs this week ;-)
[14:35:25] <dmlloyd> I suppose, theoretically, we could probably support ANONYMOUS as well
[14:36:42] <darranl> I think the additional mechanisms should really come as a second pass later - for the moment I was trying to list the set needed to meet the ERD requirement for integration with existing infrastructure
[14:36:56] <dmlloyd> so would the authentication DBs defined in the management section be generally available to subsystem profiles?
[14:37:15] *** bstansberry has joined #jboss-as7
[14:37:15] *** ChanServ sets mode: +v bstansberry
[14:37:15] <dmlloyd> or are they limited to just the management connection
[14:37:30] <dmlloyd> oh, there's bstansberry, I'll repeat my question for his benefit...
[14:37:34] <dmlloyd> <dmlloyd> so would the authentication DBs defined in the management section be generally available to subsystem profiles?
[14:37:34] <dmlloyd> <dmlloyd> or are they limited to just the management connection
[14:37:39] <darranl> Just the management connection - most likely in domain mode we have no subsystems
[14:37:50] <dmlloyd> okay that makes sense
[14:38:07] <dmlloyd> we'll definitely want something similar though for the subsystems
[14:38:14] <bstansberry> agreed, leaking stuff out of management into subsystems sounds like a can of worms
[14:38:42] <darranl> this latest design also obsoletes JBoss Negotiation as well if it was applied to subsystems
[14:44:27] <Jaikiran> wolfc: missed commiting MethoIntf?
[14:44:48] <bstansberry> emuckenhuber, kkhan: we need to fill in the missing domain and host descriptions
[14:45:07] <wolfc> Jaikiran, no
[14:45:14] <bstansberry> does anyone know where heiko braun hangs out?
[14:45:20] <wolfc> I had some similar trouble
[14:45:24] <Jaikiran> hmm. i don't see it locally in IntelliJ
[14:45:26] <Jaikiran> let me see
[14:45:37] <wolfc> Yeah, Intellij fouls up
[14:45:42] <wolfc> Look at the FS
[14:45:42] <dmlloyd> you have to synch up
[14:45:46] <wolfc> Doesn't work
[14:45:58] <dmlloyd> I assign a hotkey to it, F10
[14:46:06] <emuckenhuber> bstansberry: can you push those minor changes to master: https://github.com/emuckenhuber/jboss-as/compare/jbossas:master...misc
[14:46:11] <darranl> bstansberry, I think he could be offline
[14:46:29] <dmlloyd> if it doesn't work, wolfc, it must be a local problem because that always works for me on both mac and linux
[14:46:57] <bstansberry> emuckenhuber: will do
[14:47:00] <emuckenhuber> bstansberry: and one for your my-domain-op branch: https://github.com/emuckenhuber/jboss-as/commit/9857f6e35348f9044ab520093022eafd9e646399
[14:47:00] <jbossbot> git [jboss-as] 9857f6e.. Emanuel Muckenhuber use serverOp
[14:47:23] <Jaikiran> that's strange, synch and force re-import both don't work
[14:47:31] <Jaikiran> i can see those files locally on FS
[14:49:20] <Jaikiran> restarting the IDE did the trick
[14:49:33] *** opalka has quit IRC
[14:58:05] <smarlow> I'm going to rebase the JPA (https://github.com/scottmarlow/jboss-as) branch for merging.  The last time I rebased, I was able to do a "git rebase -i HEAD~11" but now I have my changes and others intermixed.  Is cherry picking better for sifting through the mess (opening pro git book to check myself)?
[14:59:02] <jbossbot> git [jboss-as] push master be1ffc4.. Emanuel Muckenhuber use correct service name
[14:59:03] <jbossbot> git [jboss-as] push master dd08169.. Emanuel Muckenhuber preserve socket-binding-group name, when creating the server model
[14:59:03] <jbossbot> git [jboss-as] push master 0837840.. Emanuel Muckenhuber call handleResultComplete()
[14:59:03] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/4208d4c...0837840
[14:59:41] * smarlow doesn't look like cherry picking helps
[15:01:08] * smarlow will sync with master again now and try to rebase after
[15:01:33] <dmlloyd> nah rebase should be OK
[15:01:50] <dmlloyd> but not with HEAD~11
[15:02:10] <dmlloyd> the usual formula is: git fetch upstream && git rebase upstream/master
[15:02:35] <dmlloyd> the only time that doesn't really work is if someone committed some of your patches but they were cherry-picked or rebased outside of your tree
[15:02:53] <dmlloyd> that's when you have to go to the three-way rebase/cherry-pick approach
[15:03:38] <smarlow> none of my changes have been pulled in yet, so shouldn't have to do that.
[15:03:53] *** fnasser has joined #jboss-as7
[15:05:18] <baileyje> dmlloyd: Morning
[15:05:32] <dmlloyd> morning baileyje
[15:05:39] <dmlloyd> how was the vacation
[15:05:44] <bstansberry> hi baileyje
[15:06:05] <baileyje> It was good.  Our travel was late and I got in pretty late last night, but the trip was nice
[15:06:21] <baileyje> of course I decided to get sunburnt the last day..
[15:06:57] <dmlloyd> well, you gotta bring back a souvenir to the tundra :)
[15:07:06] <baileyje> for sure
[15:07:36] <baileyje> So how are things?  What can I help out with
[15:07:38] <baileyje> ?
[15:07:55] <dmlloyd> things are good
[15:07:59] <dmlloyd> we have some basic EJB stuff working
[15:09:49] <dmlloyd> the things which are still outstanding (with nobody working on them) are: @MessageDriven, @EJB, @LocalHome+other EJB2, EJB timers
[15:10:24] <dmlloyd> Jaikiran is working on @Singleton/@DependsOn/@Startup/@Lock, wolfc is working on txn interceptors
[15:10:41] <dmlloyd> oh also @Remote
[15:11:00] <dmlloyd> wolfc would point out right about now that most of this stuff isn't needed for web profile
[15:11:08] <dmlloyd> which I would ignore :)
[15:11:26] <baileyje> dmlloyd: Ok.  I can take one whichever makes the most sense at this time
[15:11:30] <wolfc> @EJB is needed :-)
[15:11:57] <bstansberry> show me the spec reference! ;)
[15:11:59] <dmlloyd> baileyje, you could take @EJB I guess, it should be pretty similar to the @Resource thing
[15:12:08] <Jaikiran> isn't all of the Java EE injectable resources needed for this release?
[15:12:27] <dmlloyd> yeah, Jaikiran but just annotation-driven
[15:12:28] <baileyje> dmlloyd: Sure.  I can start looking at @EJB
[15:12:33] <Jaikiran> right
[15:12:50] <dmlloyd> which means @EJB, @Resource (which we have), the JPA stuff (smarlow), anything else?
[15:12:57] <wolfc> Resolving is a bit different than @Resource and it has scoping (but so has @Resource MB)
[15:13:55] <wolfc> @WebServiceRef
[15:14:02] <smarlow> JPA is @PersistenceUnit @PersistenceContext
[15:14:05] <dmlloyd> ah that's a good one
[15:14:23] * smarlow not sure if there was a question for JPA
[15:14:34] <wolfc> And then there are all the types of @Resource
[15:14:46] <dmlloyd> the different types of @Resource are a red herring
[15:14:49] <bstansberry> emuckenhuber, kkhan: can you join #as7-domain ? (others welcome if they want)
[15:14:59] <dmlloyd> they're all treated the same, the only difference is in the equivalent XML
[15:15:37] <dmlloyd> it'll matter once we bring in descriptor overriding
[15:15:40] <kkhan> The weld bean manager for a deployment gets bound under 'BeanManager' using the BinderService. This BinderService gets injected with a NamingStore for the context service name "jboss.naming.context.java.module.test.test". How do I look it up?
[15:16:21] <dmlloyd> java:module/test/BeanManager I guess?
[15:16:25] <kkhan> I tried: new InitialContext().lookup("jboss.naming.context.java.module.test.test.BeanManager") but that's not right
[15:16:30] <dmlloyd> in module test.jar or whatever
[15:16:33] <kkhan> ok, thanks I'll try that
[15:16:42] <dmlloyd> if you're not in the same EE module you won't see it though
[15:17:19] *** pgier has joined #jboss-as7
[15:17:19] *** ChanServ sets mode: +v pgier
[15:17:21] *** pgier has quit IRC
[15:17:38] <dmlloyd> frainone: do you want to take a try at implementing @WebServiceRef?
[15:17:57] <wolfc> BeanManager should be under java:comp/BeanManager
[15:18:00] *** pgier has joined #jboss-as7
[15:18:00] *** ChanServ sets mode: +v pgier
[15:18:28] <frainone> dmlloyd: sure... I'll just need some time to get familiar with the code
[15:19:26] <dmlloyd> frainone: okay, use org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor as a reference point to get started
[15:20:02] <frainone> tx!
[15:20:37] <wolfc> Jaikiran, I pushed another https://github.com/wolfc/jboss-as/commits/ejb3-ee. I won't change the underlying commit.
[15:21:28] <Jaikiran> ok, i'll get it locally
[15:21:48] <Jaikiran> wolfc: btw, i had to fix some checkstyle and surefire issue to get it passing
[15:21:52] <Jaikiran> i'll push my changes too
[15:22:44] <dmlloyd> and hopefully asoldano will be available to answer questions too...
[15:23:14] <dmlloyd> frainone: I guess the class should probably live in the webservices module.
[15:23:30] <dmlloyd> asoldano: just an FYI that we're working on @WebServiceRef.
[15:23:38] <frainone> ok
[15:24:43] <wolfc> I hate checkstyle. It has little added value and Intellij always screws up.
[15:26:05] <smarlow> there must be something bad about my branch as the rebase needs to be rolled back
[15:26:07] <wolfc> It reminds me of the Cobol days, where code had to start at a certain indentation position.
[15:27:19] <dmlloyd> smarlow: if there are conflicts normally you just need to resolve them
[15:27:30] <dmlloyd> it'll give instructions on how to do it
[15:27:42] <smarlow> yeah, I resolved the merge conflicts, this is different
[15:28:08] <dmlloyd> and you added them and did git rebase --continue, and it still failed?
[15:28:16] <darranl> wolfc, also been having the same disagreements with checkstyle and eclipse ;-)
[15:28:50] <dmlloyd> wolfc, if you set up IDEA to remove trailing whitespace on save (for lines you've changed) you shouldn't have a problem
[15:28:54] * dmlloyd doesn't, at least
[15:29:08] <asoldano> dmlloyd, frainone: yes, you can use the webservices module
[15:29:57] <smarlow> dmlloyd:  this is more like, some newer java packages and modules are gone.  Older java modules are back.
[15:30:15] <dmlloyd> smarlow: yeah that happens on a rebase
[15:30:20] <dmlloyd> smarlow: it's because you're travelling back in time
[15:30:36] <dmlloyd> as you resolve conflicts and roll forward things get sorted out
[15:30:48] <smarlow> okay, dokey...
[15:31:16] <dmlloyd> you do need to be careful that your IDE doesn't add files on you
[15:31:30] <dmlloyd> so after you get the rebase conflict message, make sure your IDE is synced up with the filesystem
[15:31:46] <dmlloyd> then resolve conflicts, save all, git add, git rebase --continue, repeat as needed
[15:33:24] <Jaikiran> wolfc: testsuite fixes https://github.com/jaikiran/jboss-as/commits/ejb3
[15:34:57] <wolfc> Jaikiran, the weird part is that the test case is passing in Intellij
[15:35:05] <wolfc> Something wicked is going on
[15:35:12] <Jaikiran> wolfc: might have assertions disabled :)
[15:35:25] <Jaikiran> i was running into "assert" throwing up an error
[15:35:27] <wolfc> I knew I was forgetting something
[15:39:55] *** asoldano is now known as asoldano_away
[15:41:53] *** asaldhan has joined #jboss-as7
[15:41:53] *** ChanServ sets mode: +v asaldhan
[15:42:41] <wolfc> Jaikiran, I've pushed ejb3-ee with your changes in it. Mine got merged away. :-)
[15:46:24] *** smcgowan has joined #jboss-as7
[15:46:24] *** ChanServ sets mode: +v smcgowan
[15:46:25] *** pferraro has joined #jboss-as7
[15:46:25] *** ChanServ sets mode: +v pferraro
[15:47:07] <dmlloyd> wolfc, Jaikiran, be sure to ping me any time you guys have some unit of progress that can be pushed out.
[15:48:00] <smarlow> dmlloyd:  should I wait until I reach the end of the rebasing, to worry about java compiler errors?
[15:48:12] <wolfc> https://github.com/wolfc/jboss-as/commits/ejb3-ee 182c7e13c27 has smoke tests passing
[15:48:33] <dmlloyd> smarlow: yes.  Just fix the conflicts to be as correct as possible without affecting anything else
[15:48:45] <smarlow> okay, thanks
[15:49:46] *** tdiesler has quit IRC
[15:50:30] <wolfc> dmlloyd, I'm looking at populating ComponentConfiguration with tx attr stuff. I see AbstractComponentDescription.prepareComponentConfiguration looping over component class methods and view methods. Either I hook into there or I build up in some sort of cache.
[15:50:50] <wolfc> Hmm, the looping itself might be offensive as well.
[15:51:12] <wolfc> Deployment time, runtime performance or memory?
[15:51:30] <dmlloyd> runtime perf then memory then deployment time
[15:51:36] <dmlloyd> but deployment time still has to be fast ;)
[15:51:56] <dmlloyd> and higher short-term memory use is okay to reduce memory use later on
[15:52:16] <dmlloyd> so it's OK to put a map or three on your EJB component config because that should be short-lived
[15:52:31] <dmlloyd> well, theoretically
[15:52:36] <wolfc> config or description
[15:52:40] <dmlloyd> in practice maybe it won't be, but it's still probably OK
[15:52:49] <wolfc> We need to install a state where description gets thrown
[15:53:06] <wolfc> s/thrown/tossed/
[15:53:35] <wolfc> Right now I keep it forever and the same goes for configuration.
[15:54:30] <dmlloyd> yeah
[15:54:33] <dmlloyd> we can fix that later
[15:55:05] <wolfc> https://github.com/jbossas/jboss-as/blob/master/ee/src/main/java/org/jboss/as/ee/component/AbstractComponentConfiguration.java#L45
[15:55:10] <wolfc> Hmm
[15:55:18] <wolfc> https://github.com/jbossas/jboss-as/blob/master/ee/src/main/java/org/jboss/as/ee/component/AbstractComponentConfiguration.java#L75
[15:55:24] <wolfc> I'll make that deprecated
[15:56:09] <dmlloyd> yeah if that's not actually used we can toss it
[15:56:17] <dmlloyd> but for now we'll play it safe
[15:56:39] <wolfc> In fact it is only by EJB and Weld.
[15:56:41] <dmlloyd> ejb3-ee needs a rebase
[15:56:46] <wolfc> I'm going to toss it
[15:57:22] <smarlow> dmlloyd:  I got near the end "Your branch and 'origin/master' have diverged".  Should I force a push or try to deal with possible build errors first?
[15:57:57] <dmlloyd> smarlow: yeah that just means that you've rebased but the github version hasn't yet.  I'd make sure that any build errors are fixed at this point.
[15:58:06] <dmlloyd> smarlow: then push --force and you should be fine.
[15:58:07] *** pferraro has quit IRC
[15:58:17] <smarlow> dmlloyd:  nice!  thanks :)
[15:58:28] <dmlloyd> no prob!
[15:58:29] *** pferraro has joined #jboss-as7
[15:58:29] *** ChanServ sets mode: +v pferraro
[15:58:53] <wolfc> dmlloyd, do we have a conflict rebasing ejb3-ee onto master?
[16:00:19] * smarlow weird:  symbol PARSE_DATA_SOURCE_DEFINITION not found in connector/src/main/java/org/jboss/as/connector/subsystems/datasources/DataSourcesSubsystemAdd.java
[16:00:46] * smarlow I didn't expect to mess up other modules...
[16:01:22] <dmlloyd> wolfc: no, I just thought maybe you wanted to do the rebase so you don't have to deal with dup commits or whatever
[16:01:26] <dmlloyd> I don't mind doing it
[16:01:49] <wolfc> git rebase detects that. it works like a charm
[16:01:57] <dmlloyd> okay I'll do it then
[16:02:24] * smarlow sounds like a PHASE screwup, shouldn't be tough to find...
[16:02:26] <wolfc> it'll say 'nothing to do' while it actually does a fast forward
[16:03:23] *** davidbos has joined #jboss-as7
[16:04:34] <dmlloyd> smarlow, could be a lost static import too
[16:04:38] *** kkhan has quit IRC
[16:05:08] *** emuckenhuber is now known as emuckenh_afk
[16:07:14] *** kkhan has joined #jboss-as7
[16:07:14] *** ChanServ sets mode: +v kkhan
[16:07:53] <jbossbot> git [jboss-as] push master 789e5b3.. Carlo de Wolf Initial work on @TransactionAttribute
[16:07:53] <jbossbot> git [jboss-as] push master 361a327.. Carlo de Wolf Process @TransactionAttribute
[16:07:54] <jbossbot> git [jboss-as] push master 72df875.. jaikiran Fix checkstyle errors and also setup surefire plugin to ignore TestHelper.java as a testcase
[16:07:54] <jbossbot> git [jboss-as] push master c90acda.. jaikiran Fix testsuite
[16:07:54] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/0837840...c90acda
[16:15:05] *** frainone has quit IRC
[16:15:06] *** AndyTaylor has quit IRC
[16:15:08] <dmlloyd> does anyone know what JBAS-8932 is all about?
[16:15:09] <jbossbot> jira [JBAS-8932] weld subsystem build fails on unsatisfied javax.faces dependency [Open (Unresolved) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-8932
[16:16:56] * smarlow repeating the cycle (git pull --rebase upstream master) once more to fix a build error.  should be quicker this time.  :)
[16:19:30] <smarlow> dmlloyd:  rebase is complete a pushed to https://github.com/scottmarlow/jboss-as/commits/master
[16:20:12] <dmlloyd> cool, I'll check it out.
[16:20:15] <smarlow> dmlloyd:  should I request a git pull, to see if the change looks right?
[16:20:28] <dmlloyd> you just did :)
[16:20:41] <smarlow> hehe :)
[16:25:32] *** AndyTaylor has joined #jboss-as7
[16:25:35] *** AndyTaylor has joined #jboss-as7
[16:25:35] *** ChanServ sets mode: +v AndyTaylor
[16:26:48] <smcgowan> dmlloyd:  re:  JBAS-8932 was seen with AS 6 too, there was a thread on jboss-dev about it, trying to locate it . . . to see the resolution
[16:26:50] <jbossbot> jira [JBAS-8932] weld subsystem build fails on unsatisfied javax.faces dependency [Open (Unresolved) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-8932
[16:27:18] <smcgowan> it's an issue with the mvn settings IIRC
[16:27:20] <dmlloyd> weirdly I was able to download it
[16:27:22] <dmlloyd> ah
[16:27:42] <dmlloyd> can't we use the jboss-spec JSF API?
[16:28:01] <dmlloyd> I guess that's a question for stan
[16:28:16] <baileyje> dmlloyd: Is your EE work in a branch>
[16:28:36] <dmlloyd> I don't have anything right now, baileyje, other than the async interceptor I wrote
[16:28:40] <dmlloyd> everything is in upstream
[16:28:54] <baileyje> ok.
[16:29:04] *** pferraro has quit IRC
[16:29:35] *** pferraro has joined #jboss-as7
[16:29:35] *** ChanServ sets mode: +v pferraro
[16:29:40] <smcgowan> dmlloyd: http://lists.jboss.org/pipermail/jboss-development/2010-December/016754.html
[16:30:07] <smcgowan> dmlloyd:  i do have the JSF APIs in the JBoss Java EE project
[16:30:25] <dmlloyd> yeah I'm just curious if they're compatible
[16:31:20] <smarlow> I'll be offline in a few minutes but will continue building JPA up.  If someone wants to help, it would be nice to have some EJB3 interceptor stubs in the JPA source tree.  Will need an interceptor for SLSB/SFSB (incoming request side and outgoing response side) invocations.  Also need a SFSB lifecycle interceptor.  Something to help with tracking SFSB context via implementation of JPA SPI BeanContextHandle class would be helpful also.  :)
[16:31:59] <dmlloyd> anyone here have a lot of JPA experience, and wants to pick this up?
[16:32:11] <wolfc> I'm still trying to convince Intellij to work
[16:32:18] <dmlloyd> smarlow, you'll be off for a day or two?
[16:32:18] <smcgowan> dmlloyd:  i did test them a while ago: https://issues.jboss.org/browse/JBEE-26?focusedCommentId=12540136&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12540136, so yes, they are compatible
[16:32:20] <jbossbot> jira [JBEE-26] Add jsf-api_2.0_spec [Open (Unresolved) Feature Request, Major, Stan Silvert] https://issues.jboss.org/browse/JBEE-26
[16:32:59] <wolfc> It's stuck in 'Performing code analysis' for some reason
[16:33:31] <dmlloyd> yeah if there's an error in the file it can't figure out it can get stuck that way
[16:33:44] <smarlow> dmlloyd:  I'll have connectivity from there and will keep pushing part time
[16:34:04] <dmlloyd> smarlow: okay.
[16:34:40] <dmlloyd> smarlow: I may squash your branch down into fewer commits, or maybe even just one.
[16:34:45] <dmlloyd> smarlow: I'll let you know.
[16:35:24] <smarlow> excellent, that is what was missing that I had done before with the "git rebase -i HEAD~NN" rebase :)
[16:39:06] * smarlow leaving now...
[16:39:23] *** smarlow has quit IRC
[16:39:30] <wolfc> dmlloyd, https://github.com/wolfc/jboss-as/commit/e4e0e5b9025ebe9090ed3291f3d3bb7581d1fdda
[16:39:31] <jbossbot> git [jboss-as] e4e0e5b.. Carlo de Wolf Removed reference to Description in AbstractComponentConfiguration
[16:42:44] <jbossbot> git [jboss-as] push master e4e0e5b.. Carlo de Wolf Removed reference to Description in AbstractComponentConfiguration
[16:42:44] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c90acda...e4e0e5b
[16:43:04] <wolfc> thanks
[16:46:46] <asaldhan> jfclere: ping
[16:49:10] <dmlloyd> http://github.com/dmlloyd/jboss-as/tree/jpa <- this is scott's JPA work, squashed
[16:49:21] <dmlloyd> I could use a few extra eyeballs on it because I'm not terribly familiar with JPA
[16:59:11] <baileyje> dmlloyd: Have you tested managed bean injection recently?
[16:59:20] <alesj> dmlloyd: hmmm, AS7 eats my exceptions ...
[16:59:28] <dmlloyd> baileyje: yeah just with smoke tests though
[17:00:01] <baileyje> If there is no "lookup" defined for the resource, how is it resolving the ManagedBeans to inject?
[17:00:06] <alesj> dmlloyd: looks like i have issues with one of my services, but no report … no missing dep report, ...
[17:00:07] <baileyje> There used to be a processors for that.
[17:00:33] <dmlloyd> baileyje: if org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor doesn't do it, it's not done
[17:00:52] <baileyje> OK.  So that did get lost.  I will look into that alone with the @EJB piece.
[17:00:57] <dmlloyd> alesj: all start exceptions should be logged - missing deps aren't logged yet though
[17:01:21] <alesj> ah :-(
[17:01:34] <alesj> for me there was a CNFE in some service
[17:01:36] <alesj> but no report
[17:01:50] <alesj> where can I "catch" missing service dep?
[17:03:10] <wolfc> dmlloyd, that JPA code contains test code in the main
[17:04:16] <dmlloyd> alesj: it's visible to listeners
[17:04:34] <dmlloyd> if there was no report then it probably didn't happen during start()/
[17:04:35] <dmlloyd> ?
[17:06:12] <alesj> it was
[17:06:29] <alesj> ok, not really sure ...
[17:06:31] <asaldhan> rmaucher: ping
[17:06:44] <alesj> dmlloyd: which listeners are we talking about here?
[17:07:04] <dmlloyd> alesj: anything implementing a ServiceListener which is attached to the service in question
[17:07:21] <alesj> to the dependee?
[17:08:04] <alesj> dmlloyd: i mean, if I add a listener to dependee, i should be able to see its missing deps?
[17:08:21] <dmlloyd> you can see that it has missing deps
[17:08:42] <dmlloyd> the actual missing dep list is something that will be done by the startup and deployment listeners
[17:08:50] <dmlloyd> because it's computationally intensive
[17:09:17] <alesj> yeah, i wrote that piece for AS5/6 :-)
[17:09:38] <alesj> e.g. remember the crappy msg info we put out :-)
[17:10:34] <wolfc> I say we don't let alesj write up the dependency error reporter :-)
[17:10:45] <alesj> :-)
[17:10:47] <alesj> fine by me
[17:11:20] <alesj> although, i would imagine people got used to that cryptic msgs …
[17:11:21] <alesj> :-)
[17:11:29] *** kkhan has quit IRC
[17:11:33] <wolfc> only after a few bacos :-)
[17:11:34] <dmlloyd> right now we just have a list of services which are active but missing dependencies after the point where all other known services are started or failed
[17:11:44] <dmlloyd> but we don't have the list of actual dependencies which are missing
[17:12:03] <dmlloyd> that's only during boot though
[17:12:09] <dmlloyd> the deployment one doesn't have that
[17:13:25] <alesj> dmlloyd: is there a way to only chnage some module in AS7 build?
[17:13:34] <alesj> like we could do it with build magic :-)
[17:13:54] <alesj> e.g. I wanna only change web module jar(s)
[17:15:03] <dmlloyd> build always rebuilds everything right now
[17:15:28] <dmlloyd> you can do: cd web && mvn install && cd ../build && mvn install
[17:15:33] <dmlloyd> which is reasonably short
[17:20:07] *** kkhan has joined #jboss-as7
[17:20:07] *** ChanServ sets mode: +v kkhan
[17:20:40] *** adietisheim has joined #jboss-as7
[17:20:50] <alesj> dmlloyd: what's the diff Servicetarget::addInjection vs. addDependency(… Injector in)?
[17:21:05] <dmlloyd> addInjection does not add a dependency
[17:21:47] <alesj> dmlloyd: http://pastebin.com/EVSGBi3H from:
[17:21:57] <alesj>             .addDependency(beanManagerBindingServiceName, BeanManager.class, enhancerService.getBeanManager())
[17:22:46] <alesj> ah, stupid me …
[17:23:18] <dmlloyd> you're pretty far behind, you're going to want to rebase on upstream asap
[17:23:48] <alesj> tried that, but lots of merge issues ...
[17:24:24] <alesj> what's the best way to tackle those?
[17:25:28] <bstansberry> pgier: do you know of any reason why a build should be limited to stuff in https://repository.jboss.org/nexus/content/groups/public-jboss/ ?
[17:26:00] <bstansberry> JBAS-8932 is basically because an artifact isn't in groups/public-jboss but only in groups/public
[17:26:03] <jbossbot> jira [JBAS-8932] weld subsystem build fails on unsatisfied javax.faces dependency [Open (Unresolved) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-8932
[17:26:04] <pgier> bstansberry: that repo group includes only the jboss jars
[17:26:18] <bstansberry> right, so basing a build on it is wrong
[17:26:20] <pgier> if you use "public" you are getting JBoss jars and thirdparty jars
[17:27:11] <bstansberry> yeah. EAP needs to be restricted, but community AS should be based on "public"
[17:27:58] <dmlloyd> okay so tdiesler's change is basically invalid then
[17:28:02] <dmlloyd> for now
[17:28:28] <dmlloyd> though when stan gets back we should at least ask about using the jboss jsf 2.0 api JAR
[17:28:48] <pgier> bstansberry: it's kind of up to the project, I'm guessing that jar is in the java.net repo, so if you put documentation in the build that you need to configure that repo, I guess it would be ok
[17:29:01] <pgier> but in general, it's easier to just use the "public" group
[17:30:13] <bstansberry> pgier: thanks. "easier" is the goal here :)
[17:31:59] <pgier> bstansberry: this is in the AS 7 build?  I don't get why the public-jboss group would even show up there
[17:32:22] <bstansberry> I think it was just an invalid bug report
[17:33:43] *** frainone has joined #jboss-as7
[17:33:43] *** ChanServ sets mode: +v frainone
[17:40:48] *** bobmcw has joined #jboss-as7
[17:40:48] *** ChanServ sets mode: +v bobmcw
[17:44:33] <dmlloyd> I'll close it
[17:47:56] *** emuckenh_afk is now known as emuckenhuber
[17:49:58] <jfclere> asaldhan: yes?
[17:50:16] <Nihility> maeste, jpederse where in the spec does it say that JCA must load drivers in the user's TCCL?
[17:50:27] <asaldhan> jfclere: the CCe was fixed by marcus like 20days ago. I thought u checked it correct?
[17:51:14] <jfclere> asaldhan: yes I think it was ok.
[17:51:53] <asaldhan> jfclere: ok. I have another issue.
[17:52:02] <asaldhan> jfclere: that is more between AS5 and AS6.
[17:52:26] <jpederse> Nihility: the TCCL must be set for resource adapters
[17:52:47] <asaldhan> jfclere: if i do  requestDispatcher.forward(coyoteRequest,Response).  it works fine on AS5.1   but on 6,  I get   CCE:  Request cannot be cast to ServletRequestWrapper
[17:53:09] <Nihility> jpederse: yeah i am referring to this though in stefanos email "Basically when we call a getConnection() on a DataSource looked up from jndi we need to have driver in TCCL (as JCA spe requrement) we are using TCCL to make a driver instance and create the underlying connection."
[17:53:23] <asaldhan> jfclere: now if I do  RD.forward( coyoteRequest.getRequest(), response).  it barfs on 5.1 but works on 6.
[17:53:34] <Nihility> jpederse: which implies the TCCL is the caller not the RAR
[17:53:53] <jpederse> Nihility: the TCCL is the RAR
[17:53:59] <alesj> Nihility: I'm looking at JspFactory::getDefaultFactory
[17:54:11] <alesj> Nihility: which uses Class:forName to find the right class instance
[17:54:12] <asaldhan> jfclere: what is the issue.  Catalina CoyoteRequest  impl  ServletRequest.
[17:54:16] <alesj> will that work?
[17:54:21] <jpederse> Nihility: for DS deployments it should be the driver.jar + jdbc-local.rar f.ex.
[17:54:41] <jpederse> Nihility: that part is up to the ds deployer chain to set
[17:55:09] <jpederse> Nihility: so each ds deployment has an isolated driver instance
[17:55:48] <jpederse> Nihility: the jdbc-local.rar just uses the TCCL, since it is the way for RAs to do that
[17:56:49] <Nihility> jpederse: ah ok that matches my understanding, although the stack trace he has implies differently as well
[17:57:54] <jpederse> Nihility: k
[17:58:03] <Nihility> i think thats the issue with this problem
[17:58:26] <jfclere> asaldhan: what exception do you get?
[17:58:29] <Nihility> the jndi binding, if its performed lazily needs to use the RA's classloader to load the drier
[17:58:34] <jpederse> Nihility: yeah, the call happens at run-time not during creation of the object
[17:58:48] <jpederse> Nihility: correct
[17:59:06] <jpederse> Nihility: but that must be true for all deployments
[17:59:23] <asaldhan> jfclere: in the 2nd case.  I think I get something like  "request cannot be created or such after response has been committed"
[18:00:14] *** ALR has joined #jboss-as7
[18:00:14] *** ChanServ sets mode: +v ALR
[18:00:33] <asaldhan> jfclere: I have dig further.  it may be an issue with my tests currently.
[18:01:16] <Nihility> jpederse: just to make sure we are on the same page, i mean that a WAR does not need to see the jdbc driver classes just because it does a lookup on "java:/MyDataSource"
[18:01:38] <jfclere> asaldhan: mail me if you get stuck
[18:02:00] <asaldhan> jfclere: let me dig and see.
[18:02:18] <jpederse> Nihility: nope, we bind the JDBC 4 / 4.1 API into JNDI
[18:02:24] *** davidbos has quit IRC
[18:02:35] <Nihility> jpederse: ok perfect, just wanted to make sure we were really saying the same thing
[18:02:36] <Nihility> :
[18:02:42] <jpederse> :)
[18:05:56] *** jcosta has quit IRC
[18:10:58] <baileyje> wolfc: There?
[18:11:11] <baileyje> Jaikiran: There?
[18:14:24] *** jamezp has joined #jboss-as7
[18:19:37] *** AndyTaylor has quit IRC
[18:28:43] *** maeste is now known as maeste_afk
[18:29:50] *** jhalliday has quit IRC
[18:35:32] *** jfclere has quit IRC
[18:38:55] *** alesj has quit IRC
[18:44:29] *** bobmcw has quit IRC
[18:46:21] <Nihility> baileyje: welcome back
[18:47:23] *** kkhan has quit IRC
[18:48:57] *** darranl has quit IRC
[18:52:18] <wolfc> baileyje, dinner time. I'm here now.
[18:54:00] *** alesj has joined #jboss-as7
[18:54:26] *** asoldano_away is now known as asoldano
[18:55:24] *** stalep has quit IRC
[18:58:58] <dmlloyd> who was looking into that problem with the null ReferenceSourceDescription?
[18:59:22] <Nihility> i remember there being a null WebServiceContext
[19:01:24] <Nihility> and stuart was working on that originally
[19:01:35] <Nihility> not sure if thats what you re talking about
[19:05:53] *** smarlow has joined #jboss-as7
[19:05:53] *** ChanServ sets mode: +v smarlow
[19:08:37] <wolfc> smarlow, why are the mock classes in src/main/java?
[19:09:00] *** emuckenhuber has quit IRC
[19:09:11] <smarlow> wolfc: they aren't supposed to stay there very long
[19:09:33] <wolfc> smarlow, they are part of the test setup
[19:09:35] <smarlow> I have a small ARQ test that references them that needs to be changed
[19:09:43] <dmlloyd> nah there was another problem where some component wasn't setting a binding source for an injection
[19:10:15] <smarlow> we can kill the mock package any time
[19:10:25] <smarlow> don't need it anymore
[19:10:28] <wolfc> you still need to verify your own implementation
[19:10:28] <dmlloyd> Nihility: you need to configure your copyright stuff
[19:10:55] <smarlow> mock should move to test then
[19:11:00] <Nihility> oh is it editing the license headers
[19:11:18] <dmlloyd> no, there simply are none
[19:11:23] <dmlloyd> org.jboss.as.connector.deployers.processors.DirectDataSourceDescription
[19:11:41] <dmlloyd> no @author tags either :)
[19:11:42] <smarlow> wolfc:  I'm not sure where mock should go actually.  Can it go in test?
[19:12:11] <wolfc> I'm not sure whether it can go into test, but that is where it should be. :-)
[19:12:18] <Nihility> oops
[19:12:23] <Nihility> only problem is
[19:12:28] <Nihility> i wrote this file with eclipse!
[19:12:31] <dmlloyd> :)
[19:12:39] <Nihility> not sure how my templates stopped working
[19:13:04] <Nihility> not that i have to worry about that anymore
[19:15:29] *** darranl has joined #jboss-as7
[19:15:32] <Nihility> btw
[19:15:35] *** darranl has quit IRC
[19:15:35] *** darranl has joined #jboss-as7
[19:15:35] *** ChanServ sets mode: +v darranl
[19:15:43] <Nihility> "unnecessary unboxing" is a stupid warning
[19:16:00] <dmlloyd> I like it, I hate autoboxing, it always surprises me
[19:16:06] <dmlloyd> even now
[19:16:09] <dmlloyd> after all this time
[19:16:15] <Nihility> no its complaining that im NOT autoboxing
[19:16:22] <dmlloyd> oh I see :)
[19:16:38] <dmlloyd> yeah it offers both, which is kinda neat for people who have bizarre coding standards to conform to
[19:16:49] <dmlloyd> you can turn them both on and it will never be happy with you :)
[19:17:17] <Nihility> " This inspection reports "unboxing", e.g. explicit unwrapping of wrapped primitive values. Unboxing is unnecessary under Java 5.0, and can be safely removed."
[19:17:29] <Nihility> depends on ones definition of "safe"
[19:17:30] <Nihility> :)
[19:17:42] *** frainone is now known as frainone_away
[19:18:11] <dmlloyd> if you tell it to auto-fix it, it converts it into the equavalent valueOf()/*Value() method
[19:21:01] *** asoldano is now known as asoldano_afk
[19:21:16] <Nihility> strange that it reports unused method on public methods
[19:21:30] <jbossbot> git [jboss-as] push master c77429a.. Emanuel Muckenhuber don't call handleResultComplete() twice
[19:21:30] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e4e0e5b...c77429a
[19:27:23] *** aslak has quit IRC
[19:27:59] *** aslak has joined #jboss-as7
[19:27:59] *** ChanServ sets mode: +v aslak
[19:35:37] *** frainone_away has quit IRC
[19:36:20] <dmlloyd> Nihility: that's configurable too
[19:36:40] <dmlloyd> you can also do unused public methods project-wide if you tell it where the entry points are
[19:36:55] <smarlow> dmlloyd:  nice squashing in https://github.com/dmlloyd/jboss-as/tree/jpa  :-)
[19:37:32] <Nihility> dmlloyd: yeah i figured out how to turn it off, i dont like unused public method warnings since they are usually an API
[19:37:40] <dmlloyd> squashing is possibly my favorite git feature, smarlow :)
[19:37:53] <Nihility> dmlloyd: it looked like the setting applied to both but it doesnt
[19:37:56] <baileyje> Jaikiran: Time for a question?
[19:37:57] <Nihility> (private and public)
[19:38:31] <dmlloyd> Nihility: there may be another separate setting.  I've had these inspection settings for so long that I don't even remember where they are anymore
[19:38:44] *** fnasser has quit IRC
[19:40:45] *** frainone has joined #jboss-as7
[19:40:45] *** ChanServ sets mode: +v frainone
[19:42:02] *** fnasser has joined #jboss-as7
[19:45:10] <wolfc> baileyje, I don't think Jaikiran is around at the moment. Just ask the question.
[19:47:07] <baileyje> Sure.  Basically I am looking to figure out how we should resolve and @EJB injection that does not provide a 'beanName' or a 'lookup'.  Basically we would need to inspect the actual component based on the field or method type to determine which component to inject.
[19:48:16] <Nihility> iirc type based injection is very limitied
[19:48:26] <Nihility> as far as teh spec explains
[19:49:14] *** frainone has quit IRC
[19:50:01] *** rmaucher has left #jboss-as7
[19:52:18] <dmlloyd> remy is showing us all up with his fancy IPv6 address
[19:54:35] <baileyje> Nihility: Yeah.  The spec shows a bunch of examples with either "beanName" or "lookup".
[19:54:50] <baileyje> It also shows one that is "@EJB private ShoppingCart myCart;"
[19:55:12] <Nihility> i think only no interface views support it
[19:56:04] <Nihility> so you basically identify the bean by classname
[19:57:55] *** epbernard has joined #jboss-as7
[19:57:55] *** epbernard is now known as emmanuel
[19:57:55] *** ChanServ sets mode: +v emmanuel
[19:59:15] <baileyje> yeah.  I figured as much.  I am just not sure about the best way to determine which bean.  I could use the annotation index, or possible check the DU for components to see if it matches,
[19:59:55] <dmlloyd> looks like the unqualified @Resource thing is tripping up some... tests
[19:59:59] <wolfc> No, all views can do that
[20:00:15] <wolfc> @EJB ShoppingCart cart; is a scoped reference
[20:00:36] <wolfc> You need to look for the EJB exposing ShoppingCart, first in the module, then in the app.
[20:00:53] <dmlloyd> looking in the module is easy
[20:01:01] <dmlloyd> looking in the module + the app is less so
[20:01:11] <Nihility> oh right duh
[20:01:20] <Nihility> yeah you use the field name
[20:01:22] <dmlloyd> is it an error to define the same EJB class more than once in an app?
[20:01:23] <Nihility> in the context you arein
[20:01:36] <dmlloyd> anyone know?
[20:01:40] <wolfc> No, you can have multiple EJBs with the same class
[20:01:49] <wolfc> and the same views
[20:01:59] <dmlloyd> in one app though?
[20:02:05] <wolfc> In the same module even
[20:02:22] <dmlloyd> hmm then how do you decide which one to use
[20:02:32] <Nihility> beanName
[20:02:36] <Nihility> (or jndi name)
[20:02:39] <dmlloyd> so you have to disambiguate?
[20:02:45] <Nihility> in ejb-jar.xml
[20:02:49] <wolfc> Yup, add additional qualifiers to @EJB
[20:03:03] <dmlloyd> that rules out using simple MSC service aliases
[20:03:32] <dmlloyd> but we have to resolve these at service resolution time one way or another, or so it would seem
[20:04:01] <wolfc> The same goes for rar, PU etc.
[20:04:16] <dmlloyd> which means we'll need some kind of registry service for injectables which knows when there are multiple items which satisfy a given name
[20:04:35] <wolfc> https://github.com/dmlloyd/jboss-as/commit/5ef1ddcd7143c392d3ac20c7565e4b84ef775928#L21R40
[20:04:36] <jbossbot> git [jboss-as] 5ef1ddc.. Scott Marlow Initial implementation of JPA subsystem
[20:04:53] <Nihility> there is only one component name though
[20:05:01] <Nihility> just you might reuse the same backing class
[20:05:14] <dmlloyd> yeah but you still have to be able to find the component by its class
[20:05:22] <dmlloyd> at least that's what it seems like you guys are saying
[20:05:33] <dmlloyd> and not just within the same DU but also the same app
[20:05:34] <wolfc> by its view, not by its class
[20:05:54] <dmlloyd> right, by its viewS really
[20:05:55] <Nihility> yeah the referencing annotation always specifies the view it wants
[20:05:56] <dmlloyd> right?
[20:06:07] <Nihility> so its unambigous
[20:06:12] <dmlloyd> I mean you have local, no-interface etc.
[20:06:24] <dmlloyd> and more than one EJB can expose the same view right?
[20:06:29] <dmlloyd> the same view type
[20:07:01] <wolfc> Nihility, no the annotation can be 'without' proper view type
[20:07:22] *** bobmcw has joined #jboss-as7
[20:07:22] *** ChanServ sets mode: +v bobmcw
[20:07:23] <wolfc> ViewA extends ViewB ViewC extends ViewB @EJB ViewB
[20:07:44] *** bobmcw has quit IRC
[20:08:09] <wolfc> At that point you have ambiguity and the user needs to add either beanInterface, beanName, mappedName or lookup
[20:08:46] <Nihility> right the point is though that the location in jndi is unambigous
[20:08:48] <dmlloyd> okay but can more than one EJB actually expose ViewB directly (i.e. not a subtype of it)?
[20:09:13] <Nihility> or unambiguous
[20:09:14] <Nihility> :)
[20:09:15] <dmlloyd> yeah I'm not worried about the JNDI Nihility, I'm worried about the code that has to look at the annotation declaration and figure out what JNDI name it's really looking for
[20:09:24] <dmlloyd> that's where it can be ambiguous
[20:09:41] <wolfc> ambiguous => DeploymentException
[20:10:03] <dmlloyd> the JNDI stuff is never ambiguous because of the nature of JNDI, which makes that part pretty easy
[20:10:13] <dmlloyd> wolfc: but my question?
[20:10:43] * dmlloyd notes that nothing right now is supporting mappedName
[20:11:01] <dmlloyd> baileyje: ^^ that's something we had to change about the @Resource code, changed to use lookup not mappedName
[20:11:09] <wolfc> dmlloyd, I'm not sure. ViewA extends ViewB ViewC extends ViewB @EJB ViewB. If an EJB would expose ViewB than that would be the one.
[20:11:54] <dmlloyd> sure
[20:12:11] <wolfc> mappedName we need to choose in such a way that we can put a dependency on it
[20:12:21] <wolfc> we can do that with a JNDI name, not?
[20:12:43] <dmlloyd> sure, we could
[20:12:51] <Nihility> yeah mappedName isnt needed anyway
[20:12:51] <dmlloyd> but we should not require mappedName for anything
[20:13:02] <dmlloyd> if we even support it at all, which we shouldn't without a good reason
[20:13:17] <wolfc> It's a last ditch effort to save the day
[20:13:17] <Nihility> if we did support it it would probably behaive the same as lookuup name
[20:13:27] <wolfc> Yeah
[20:13:28] <Nihility> unless we need to stick extra stuff in there
[20:13:31] <dmlloyd> then we wouldn't support it
[20:13:35] <dmlloyd> because it would be redundant
[20:14:02] <wolfc> In AS 6, lookup == mappedName
[20:16:20] <Nihility> interesting note
[20:16:57] <Nihility> the spec says that ambiguous names should be resolved by deployment tools
[20:18:06] <wolfc> The 'deployment tools' is an ancient construct.
[20:18:09] <dmlloyd> okay so baileyje's original question is still unanswered
[20:18:12] <wolfc> JBoss was the first to ditch it :-)
[20:18:33] <dmlloyd> we need to translate the field type into a service to inject
[20:18:37] *** frainone has joined #jboss-as7
[20:18:38] *** ChanServ sets mode: +v frainone
[20:18:48] <baileyje> RIght.  Basically we will need to determine which components expose the views
[20:19:04] <wolfc> The DUs represent a registry which contains all components with their views.
[20:19:07] <dmlloyd> which means we need an application-wide registry to resolve this info
[20:19:16] <dmlloyd> yeah that's fine for per-DU purposes
[20:19:30] <dmlloyd> but it doesn't work so well app-wide unless we add some special logic
[20:19:32] <wolfc> It also needs to be available on a global level.
[20:19:45] <wolfc> Why not?
[20:19:45] <dmlloyd> I don't think we should resolve this way for TLDs
[20:19:50] <wolfc> du.getParent == ear?
[20:20:00] <dmlloyd> because, wolfc, all subdeployments are processing at different rates
[20:20:11] <wolfc> ah
[20:20:26] <wolfc> so we need to have a metadata view complete state :-)
[20:20:26] <dmlloyd> we'd need to sync them all up so there's some definite point where you can say, "all available EJBs are known as of now"
[20:20:48] <dmlloyd> which means that a parent phase will have to be dependent on child phases
[20:20:54] <dmlloyd> which might be tricky
[20:21:15] <wolfc> there is a wicked alternative
[20:21:21] <Nihility> yeah
[20:21:21] <Nihility> "
[20:21:25] <wolfc> make such a registry event driven
[20:21:27] <Nihility> "deployment tools" == jboss.xml
[20:21:27] <Nihility> :)
[20:21:32] <dmlloyd> well it shouldn't be too tricky tbh
[20:22:47] <dmlloyd> yeah just drew it up hang on let me scan it
[20:23:09] <Nihility> hmm im pretty sure do not have to do type based injection outside of an ear
[20:23:23] <wolfc> it's one of our killer features
[20:24:15] *** stuartdouglas has joined #jboss-as7
[20:25:09] <Nihility> in the past though we talked about how global ejb-jars needed to have a static import, until a distant future time when we may be able to do a fancy annotation based discovery mechanism without classloading
[20:26:27] *** emmanuel has quit IRC
[20:26:35] <dmlloyd> http://www.flurg.com/Stuff.png
[20:26:45] <dmlloyd> the circles are DU phases
[20:26:56] *** asoldano_afk is now known as asoldano
[20:27:02] <dmlloyd> the second-to-the-bottom one would be the phase where we know that the EJBs are all detected
[20:27:11] <dmlloyd> EJBs would be detected in the third-to-bottom phase
[20:27:15] <bstansberry> can someone have a quick look at https://github.com/bstansberry/jboss-as/commit/47b2dc4a3b13f77ed2301120edf186cf52ca33f5 ?
[20:27:16] <jbossbot> git [jboss-as] 47b2dc4.. bstansberry at jboss dot com Minor deployment handler cleanups
[20:27:18] <dmlloyd> arrow means "depends on"
[20:27:26] <dmlloyd> columns are DUs, with the EAR in the center
[20:27:54] <dmlloyd> so it's still a DAG with asynchronous execution properties
[20:28:55] <dmlloyd> so basically, while a child DU phase will automatically depend on the equivalent phase of the parent DU, the parent DU phase may also depend on the *previous* phase on the child DU
[20:29:04] <dmlloyd> without introducing a cycle or anything nasty like that
[20:29:20] <dmlloyd> can I get an amen
[20:29:48] <wolfc> I'm still trying to envision the states in there
[20:30:05] <dmlloyd> yeah not sure what the actual states would be
[20:30:14] <dmlloyd> a lot of the DUPs are in the wrong place as it is
[20:30:15] <wolfc> The right jar doesn't reach the same state as the left jar
[20:30:50] <dmlloyd> yeah well the dependencies should be limited to what is required to complete the phase only
[20:31:02] <wolfc> ah yes
[20:31:03] <dmlloyd> so if the left JAR fails at the last stage, the right JAR doesn't really care
[20:31:18] *** adietisheim has quit IRC
[20:31:20] <Nihility> unless it had an @EJB on the left
[20:31:21] <Nihility> :)
[20:31:27] <dmlloyd> right
[20:31:35] <dmlloyd> in which case only the affected components would be DOWN
[20:32:08] <wolfc> so (left and right) resolving is in the state after the description is complete and the ear description is also complete in that state
[20:32:31] <dmlloyd> yeah
[20:32:36] <wolfc> the @EJB would already be resolved long before the final state is reached
[20:32:42] <dmlloyd> for that phase only, the EAR will wait for all of its child deployments
[20:32:53] <Nihility> does a parent even need a dep on a previous child, doesnt the phase dependency take care of that
[20:33:22] <dmlloyd> this is the phase dependency, that I"ve drawn
[20:33:34] <wolfc> We can do with a lot less arrows :-)
[20:33:45] <dmlloyd> all the arrows are the existing deps except for the arrows coming from the second-to-bottom-most phase from the EAR to the two JARs
[20:33:51] <stuartdouglas> At the moment the parent has a dep on all it's children's previous phases
[20:33:58] <dmlloyd> they're actually implict deps due to being child services
[20:34:00] <Nihility> ok so you were just saying that semantically it depends on the childs previous state, its not a direct dep on the process to the child
[20:34:12] <wolfc> EAR: I'll switch to metadata complete if everybody is metadata complete
[20:34:33] <wolfc> And resolving depends on the ear being complete
[20:34:36] <dmlloyd> right
[20:34:49] <dmlloyd> then we just keep the (thread-safe!) registry on the EAR's DU
[20:34:59] <dmlloyd> immutable would be ideal
[20:35:18] <wolfc> I would say we use the Descriptions and make them immutable at that point
[20:35:30] <wolfc> Hmm...
[20:35:48] <dmlloyd> it would be an aggregate of all of the EJBs in the EEModuleDescriptions of the subdeployments
[20:36:10] <dmlloyd> then it would push the aggregated info down into the subdeployments
[20:36:26] <dmlloyd> so that way the difference between a subdeployment and a TLD is minimal
[20:37:31] <dmlloyd> so the processor which does that would have three paths
[20:37:36] <wolfc> There is a finagle detail where techs want to see a full metadata view, but also want to manipulate it some more.
[20:37:41] <dmlloyd> (1) TLD, (2) EAR and (3) EAR/JAR
[20:38:01] <dmlloyd> wolfc: well we're not really talking about a full metadata view, more like a full component view
[20:38:05] <dmlloyd> we don't have to make it general
[20:38:05] <wolfc> This goes mostly for RS & WS
[20:38:38] <wolfc> Right, they want a full component view and then manipulate it
[20:38:39] <dmlloyd> don't know about RS but WS probably would want to do it's business before this happens I would think, because it should be all within one component at this point
[20:39:04] <wolfc> WS generates components
[20:39:12] <wolfc> so does RS
[20:39:27] <dmlloyd> yes but they don't need to view the whole EAR, correct?
[20:39:30] <wolfc> Hmm, yes it could be that it is confined
[20:39:36] <dmlloyd> not to create their stuff
[20:39:50] <wolfc> It's why we have the wicked input/output definitions in AS 6
[20:40:08] <wolfc> We gave up trying to manually wire it together :-)
[20:40:43] <dmlloyd> ok now the question is, what phases do we apply this to
[20:41:00] <dmlloyd> we could even add one, really
[20:43:51] <jbossbot> git [jboss-as] push master 946536b.. Jason T. Greene Add missing comments / lic header
[20:43:51] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c77429a...946536b
[20:44:52] <wolfc> whatever it takes and keeps us sane :-)
[20:44:58] <darranl> Nihility, Your missing lic header is still for last year ;-)
[20:45:05] * wolfc is away for a bit
[20:45:05] <Nihility> bah
[20:45:07] <Nihility> :)
[20:45:22] <Nihility> i have timetraveling code
[20:45:23] <Nihility> :)
[20:45:27] <darranl> lol
[20:46:05] <dmlloyd> I really regret the DEPENDENCIES phase
[20:46:21] <dmlloyd> I think a lot of people needlessly split their logic between PARSE and DEPENDENCIES
[20:46:49] <dmlloyd> and CONFIGURE_MODULE is pretty much empty :)
[20:47:48] <dmlloyd> why is org.jboss.as.ee.component.InterceptorAnnotationParsingProcessor and similar running during POST_MODULE rather than PARSE?
[20:49:04] <dmlloyd> well I'm thinking that maybe EAR INSTALL can depend on subdeployment POST_MODULE
[20:49:57] <stuartdouglas> Because web components need the module available to read annotation
[20:50:52] *** asaldhan has quit IRC
[20:50:53] <stuartdouglas> So I had to move all that back temporarily, until we can fix the web stuff
[20:53:40] <dmlloyd> ok
[20:53:48] <dmlloyd> we gotta make sure to remember to do that
[20:54:01] <dmlloyd> I want to clean up these phases after Beta1, it's one of my top items
[20:55:02] <dmlloyd> baileyje: ok so the way to move forward I guess is to define a registry type which gives you what you need, and make it a field in EEModuleDescription; I'll work out populating it
[20:55:24] <dmlloyd> first I'm gonna look at getting the deps added for INSTALL phase, so that we can be sure that when INSTALL runs it's all filled out
[20:55:44] <dmlloyd> the registry should somehow go from type name(s) to view service name
[20:55:52] <dmlloyd> (right?...right...I think)
[20:56:07] <baileyje> dmlloyd: yeah.  That is how I see it.
[20:56:07] <dmlloyd> DotName or String or whatever works
[20:57:46] <asoldano> stuartdouglas, sorry for bothering, any findings with that NPE exceptions of yesterday?
[20:58:12] <stuartdouglas> Yes, there were two different problems
[20:59:04] <asoldano> ok..
[20:59:10] <stuartdouglas> One was failing because it was trying to do @Reaource WebServiceContext and we have not implemented that yet
[20:59:56] <asoldano> ok..
[21:00:02] *** Jaikiran has quit IRC
[21:00:05] <stuartdouglas> The other was a npe that I have fixed on my laptop
[21:00:35] <stuartdouglas> I will push it to github after breakfast
[21:00:50] <asoldano> thanks
[21:01:05] <asoldano> I'll run the jbossws hudson jobs on tomorrow morning my time
[21:01:10] <stuartdouglas> Hopefully I will have time to fix the WebServiceContext thing to
[21:01:23] <stuartdouglas> You are in Europe right?
[21:01:35] <asoldano> yep
[21:03:12] *** asaldhan has joined #jboss-as7
[21:03:12] <asoldano> ok, thanks, I'm leaving for today
[21:03:23] *** asoldano has quit IRC
[21:03:58] *** asaldhan has quit IRC
[21:03:58] *** asaldhan has joined #jboss-as7
[21:04:13] <stuartdouglas> I'm going to go and get some breakfast
[21:04:22] *** stuartdouglas has quit IRC
[21:05:27] *** irooskov has joined #jboss-as7
[21:22:37] *** mbg has joined #jboss-as7
[21:22:38] *** ChanServ sets mode: +v mbg
[21:26:12] *** opalka has joined #jboss-as7
[21:26:12] *** opalka has joined #jboss-as7
[21:26:12] *** ChanServ sets mode: +v opalka
[21:26:47] *** kkhan has joined #jboss-as7
[21:26:48] *** ChanServ sets mode: +v kkhan
[21:37:16] <dmlloyd> baileyje: http://github.com/dmlloyd/jboss-as/commit/05c94bd
[21:37:17] <jbossbot> git [jboss-as] 05c94bd.. David M. Lloyd Support for aggregated app-wide EE component indexes by view, with proper dependencies
[21:37:24] <dmlloyd> that includes all the dependency crap.
[21:37:38] <dmlloyd> you can cherry-pick that, or mix it in however you want to
[21:37:43] <dmlloyd> it's not complete without your part
[21:37:48] <dmlloyd> (see the TODO items in there)
[21:38:15] <dmlloyd> I bet we're going to need this same thing for @Resource somehow, and the other types as well
[21:41:35] <baileyje> dmlloyd: Ok.  I will pull that in
[21:42:37] <dmlloyd> it was easier to solve than I thought :)
[21:42:50] * dmlloyd needs some more easy tasks
[21:59:09] *** darranl has quit IRC
[21:59:41] *** opalka has quit IRC
[22:02:02] *** opalka has joined #jboss-as7
[22:02:03] *** ChanServ sets mode: +v opalka
[22:06:59] <alesj> dmlloyd: ping?
[22:07:26] <alesj> in my case, i have a bunch of completely diff classes - the web
[22:07:34] <dmlloyd> hi
[22:07:46] <alesj> how do i tell git that my version is the one, and no merge is actually required
[22:08:11] <alesj> ok, there are probably some classes that do need merge
[22:08:11] <dmlloyd> you're rebasing right?
[22:08:14] *** stuartdouglas has joined #jboss-as7
[22:08:29] <alesj> what do you suggest to do … i'm still a git noob
[22:09:25] <dmlloyd> I'd just resolve the ones that need conflicts - and the ones which it says are new in your branch or deleted in upstream, just follow the directions and make your best guess
[22:09:40] <dmlloyd> you can either save them from deletion by re-adding them or drop them by git rm'ing them
[22:10:00] *** kkhan has quit IRC
[22:10:22] <alesj> ok, i'll try my best :-)
[22:11:41] *** alesj has quit IRC
[22:31:37] *** emuckenhuber has joined #jboss-as7
[22:31:37] *** emuckenhuber has joined #jboss-as7
[22:31:37] *** ChanServ sets mode: +v emuckenhuber
[22:48:54] *** stuartdouglas has quit IRC
[22:49:24] *** mbg has quit IRC
[22:52:30] *** miclorb_ has joined #jboss-as7
[22:55:25] *** smcgowan has quit IRC
[22:59:45] <Nihility> smarlow: you around?
[23:00:00] <smarlow> Nihility:  yup, I'm hear
[23:00:35] <Nihility> smarlow: so im planning to give you a hand / continuing your jpa stuff while you are away
[23:01:03] <Nihility> could you give me an overview of where you are, and what needs to be solved yet
[23:01:04] <smarlow> Nihility:  awesome, thanks :)  I don't think its that much left
[23:02:05] <Nihility> cool
[23:02:44] <smarlow> Nihility: The ejb integration is probably the biggest remaining thing (getting interceptors going).  Need to hook into the transaction service
[23:02:57] <opalka> dmlloyd, Nihility Do we ship STaX impl with AS7? If yes, which module artifact is it? I'm getting http://fpaste.org/sseu/ and I don't wanna use JDK default.
[23:03:01] <Nihility> ah ok so is the PU stuff done?
[23:03:35] <Nihility> opalka: we were thinking of using woodstox as the default, but were holding off making the switch until someone found a problem with the jdk impl
[23:03:59] <opalka> Nihility, IOW U've been waiting for this to happen ;)
[23:04:05] <Nihility> opalka: exactly :)
[23:04:07] <smarlow> Nihility:  yep, the PU definitions are parsed and the scoped search seems to be working.  I have most of PersistenceUnit setup, next is hooking PersistenceContext up.
[23:04:21] <Nihility> opalka: take a look at the jaxp-provider module
[23:04:36] <Nihility> opalka: that module imports every JAXP impl we replace
[23:05:26] <opalka> Nihility, What  U mean with jaxp-provider module? I'm getting
[23:05:26] <Nihility> opalka: so if you want to verify woodstox works for you, just create a module for it (if we dont have one already) and then add an import wtih services="import"
[23:05:28] <opalka> [nucleus][/home/opalka/git/jboss-as/build/target/jboss-7.0.0.Alpha2/modules]>find -type d -name jaxp-provider
[23:05:28] <opalka> [nucleus][/home/opalka/git/jboss-as/build/target/jboss-7.0.0.Alpha2/modules]>
[23:05:46] <opalka> Nihility, Yes, this is what I'm going to do ;)
[23:06:23] <opalka> Nihility, Thx for info/update
[23:06:41] <Nihility> ./javax/xml/jaxp-provider
[23:06:51] *** kkhan has joined #jboss-as7
[23:06:51] *** ChanServ sets mode: +v kkhan
[23:07:02] <Nihility> have you done a git pull --rebase upstream master recently?
[23:07:59] <Nihility> smarlow: ah ok so injecting PersistenceContext via the new ee injection layer needs to be done?
[23:08:34] <Nihility> smarlow: and by interceptors i take it you are referering to closing the context at the end of a tx
[23:08:36] <Nihility> ?
[23:09:47] <smarlow> Nihility: yes, the persistencecontext is being handled through JPAAnnotationParseProcessor but not hooked up to actually return a EntityManger yet.
[23:09:51] <smarlow> manager
[23:10:02] <Nihility> ah ok
[23:10:57] <smarlow> Nihility:  yes, for closing the context at the end of a non-tx invocation.  We need to register with the transaction sync for the tx case
[23:11:16] <smarlow> Nihility:  unless its a extended persistence context.
[23:11:40] <Nihility> ah ok
[23:12:07] <smarlow> Nihility: also on the interceptor side, is building a TLS stack of SFSB invocations
[23:12:51] <smarlow> Nihility:  that is to be used for extended persistence context inheritance.
[23:12:52] <Nihility> smarlow: whats that for?
[23:13:05] <Nihility> oh
[23:13:52] <Nihility> ill need to reread that portion of the spec to remember how it is supposed to work
[23:14:05] <smarlow> Nihility: if SFSB1 is invoked and has a XPC1.  If SFSB1 injects another SFSB (SFSB2), SFSB2 inherits SFSB1 extended persistence context
[23:15:01] <Nihility> ok
[23:16:06] <smarlow> Nihility:  I'm fine with connecting the dots on that stuff.  If you could help me get through getting the EJB interceptors going and stuff like that.  That would be great.  If you want to help more, that is great as well.  :)
[23:16:48] <smarlow> that stuff, being the XPC inheritance and other crazed ideas in JPA :)
[23:18:41] <smarlow> Nihility:  EjbAnnotationProcessor is where EJB3 annotations are read and that sets up an interceptor.
[23:22:47] <smarlow> Nihility:  I can hack through the interceptor integration, just haven't figured it out yet.
[23:23:13] <Nihility> smarlow: did you see ComponentInterceptorAnnotationParsingProcessor
[23:23:33] <smarlow> Nihility:  nope, looking now
[23:24:26] *** jwulf has joined #jboss-as7
[23:25:19] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/21aea2a3c
[23:25:20] <jbossbot> git [jboss-as] 21aea2a.. David M. Lloyd Asynchronous invocation interceptors
[23:25:49] <dmlloyd> basically all that's left is to add those to the appropriate spot (after security, before txn) in the client interceptor chain
[23:25:56] <dmlloyd> and to add cancellation support, I suppose
[23:26:38] <Nihility> dmlloyd: do we have a convention for where to place system level interceptors
[23:26:57] *** pferraro has quit IRC
[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
[23:30:04] <jbossbot> git [jboss-as] de1d4c0.. kabir Upgrade to 1.0.0.Alpha3 of modular surefire plugin to avoid issues on maven 3.0.3
[23:30:04] <jbossbot> git [jboss-as] 31ec57c.. kabir [JBAS-8934] Better rejection policy for client
[23:30:05] <jbossbot> jira [JBAS-8934] RejectedExecutionExceptions in management API [Open (Unresolved) Bug, Major, Kabir Khan] https://issues.jboss.org/browse/JBAS-8934
[23:33:37] <dmlloyd> Nihility: it's fairly complex actually
[23:33:47] <dmlloyd> we have client interceptors, component-level interceptors, and instance-level interceptors
[23:34:27] <Nihility> yeah from smarlow's description its an instance interceptor that we need
[23:34:57] <smarlow> yeah, instance sounds right.
[23:35:47] <Nihility> but do we just put these anywhere in the list, or is there a place they should be added to thats separate like a special chain thats aggregated with user interceptors
[23:36:53] <smarlow> Nihility:  hmm, user interceptors.  I guess it depends on whether the user interceptors could do JPA stuff
[23:37:14] <dmlloyd> well additionally
[23:37:30] <dmlloyd> the instance-level interceptors are divided up into default, per-class and per-method interceptors
[23:38:25] <smarlow> we don't care which method is being invoked, just need to know which beans are being invoked.
[23:39:53] <smarlow> that sounds more like per-class (instance)
[23:40:01] <Nihility> i wonder if carlo is doing tx interceptors per method
[23:40:05] <Nihility> or per class
[23:41:01] <Nihility> my thinking is that we want system interceptors to be first in the list
[23:41:26] <Nihility> i vaguely recal something about transactional scope surrounding interceptors
[23:42:57] <dmlloyd> the only way you can really add arbitrary Interceptor impls is via AbstractComponentConfiguration
[23:43:02] <dmlloyd> which is created from a description at install time
[23:43:20] *** maeste_afk has quit IRC
[23:43:22] <dmlloyd> yeah the first component interceptor is security
[23:43:25] <dmlloyd> then transactions
[23:43:30] <dmlloyd> then association
[23:43:39] <dmlloyd> then user interceptors
[23:43:54] <dmlloyd> async would go between security and transaction (security ctxt is propagated, txn isn't)
[23:43:56] *** maeste_afk has joined #jboss-as7
[23:45:12] *** rawblem has joined #jboss-as7
[23:45:12] *** ChanServ sets mode: +v rawblem
[23:45:51] <smarlow> It shouldn't matter whether we run before or after transactions or associations (not really sure what that is though).  I'm not sure about user interceptors, maybe we should run before them (out of principle :)
[23:45:51] *** maeste_afk has quit IRC
[23:46:20] <dmlloyd> association is going from saying "invoke method X on EJB Y" to "invoke method X on instance Z of EJB Y"
[23:46:24] *** maeste_afk has joined #jboss-as7
[23:46:45] <dmlloyd> because when you have a client proxy, you don't really know which EJB you're actually going to hit, especially for SLSB
[23:47:35] <smarlow> I probably want to run after associations then, because I need some way of know which bean context is being invoked
[23:48:33] <smarlow> the bean context would be used to build up a TLS call stack (for XPC inheritance on SFSBs)
[23:49:06] <dmlloyd> smarlow, the org.slf4j.slf4j-module duplicates the already existing org.slf4j module
[23:49:41] *** stuartdouglas has joined #jboss-as7
[23:49:41] *** stuartdouglas has quit IRC
[23:49:41] *** stuartdouglas has joined #jboss-as7
[23:49:41] *** ChanServ sets mode: +v stuartdouglas
[23:49:57] <smarlow> I'll clean that up.  I probably did that when I was first learning about modules :)
[23:50:08] * smarlow still learning ;)
[23:50:41] <stuartdouglas> The web service NPE's should be fixed in my master
[23:50:42] <dmlloyd> also I don't think we need org.apache.ant at runtime
[23:51:03] <dmlloyd> it would be nice if we could avoid cglib too, but that's a discussion for later
[23:51:33] <stuartdouglas> I was not sure how to get the WebServiceContext
[23:51:46] <smarlow> maybe we could wean some of the Hibernate dependencies
[23:52:06] <dmlloyd> stuartdouglas: ready for pull?
[23:52:26] <stuartdouglas> yes
[23:52:38] <smarlow> dmlloyd:  but if hibernate uses cglib, I assume they won't be able to resolve cglib classes if we drop that cglib module definition?
[23:52:38] <stuartdouglas> it's a fairly minor sort of patch
[23:52:54] <stuartdouglas> are any of the web service guys here?
[23:53:15] <dmlloyd> smarlow: right; noting that javassist, asm and cglib are included, we should not need all three
[23:53:34] <dmlloyd> we should consult with the hibernate gurus on that
[23:54:04] <stuartdouglas> I was talking to the hibernate guys the other day about using classfilewriter and jboss-invocation for their bytecode stuff
[23:54:14] <smarlow> dmlloyd:  yeah, its an old question, cglib was faster than others but the cglib project hasn't been active for a long time
[23:54:37] <dmlloyd> stuartdouglas: WebServiceContextObjectFactory?
[23:54:42] <smarlow> stuartdouglas:  that sounds promising
[23:54:59] *** wolfc has quit IRC
[23:55:02] <stuartdouglas> dmlloyd: I am not really sure how to get the WebServiceContext
[23:55:10] <smarlow> I fixed some weird cglib usage bugs long ago in hibernate.
[23:55:16] <dmlloyd> stuartdouglas: I'm more curious why an ObjectFactory
[23:55:25] <stuartdouglas> so I figured I would hook it up to an ObjectFactory and hope that one of the web service guys knows how to implement it:-)
[23:55:26] <dmlloyd> as opposed to ManagedReferenceFactory
[23:56:05] <stuartdouglas> actually, yea, I should have done that
[23:57:11] <stuartdouglas> actually, I'm not sure
[23:57:20] <stuartdouglas> I need to talk to the web service guys
[23:57:33] <dmlloyd> it's just about the only thing allowed to be bound into java: anymore
[23:57:41] *** jwulf has quit IRC
[23:58:42] <stuartdouglas> I will change it then, but now NHO is about to start
[23:58:45] <stuartdouglas> so I have to go
[23:58:48] *** stuartdouglas has quit IRC

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