[00:03:16] *** bstans_run is now known as bstansberry
[00:04:54] *** balunasj_mtg has quit IRC
[00:23:55] *** emmanuel has quit IRC
[00:25:10] <dmlloyd> sorry, was helping the boy with his subtraction homework
[00:25:49] <dmlloyd> stuartdouglas: okay, just let me know what you're getting into so we don't overlap.
[00:26:26] <stuartdouglas> so far I have just been looking at lifecycle interceptors, but now I am moving into component interceptors
[00:28:26] <stuartdouglas> at the moment it looks like all interceptor instances are hidden behind the Interceptor interface
[00:28:34] <dmlloyd> yeah that's the goal
[00:28:38] <stuartdouglas> which makes it hard to call lifecycle methods on them
[00:28:48] <dmlloyd> yeah InterceptorFactory is the key there
[00:29:00] <dmlloyd> oh I see
[00:29:10] <dmlloyd> you're talking about lifecycle methods on the interceptor instances
[00:29:14] <stuartdouglas> yea
[00:29:40] <stuartdouglas> The obvious solution would be to add lifecycle methods to the Interceptor interface
[00:29:41] <dmlloyd> well InterceptorFactory might help there too...
[00:30:00] <dmlloyd> InterceptorInstanceFactory I mean
[00:30:18] <dmlloyd> the Interceptor interface corresponds with @AroundInvoke pretty specifically
[00:31:20] <dmlloyd> if we recycle the same InterceptorFactoryContext we use to construct the interceptor instances, we should have a good cache of all the instances
[00:31:47] <dmlloyd> as long as you know their classes, which you should
[00:32:03] <stuartdouglas> I do know their classes
[00:32:04] <dmlloyd> the InterceptorFactoryContext context data map has the instances cached under a key which is the class of the instance
[00:32:31] * dmlloyd doesn't have this figured out, just talking it through helps sometimes
[00:33:13] <stuartdouglas> I can't help thinking that adding lifecycle support to Interceptor would be a lot cleaner
[00:33:49] <dmlloyd> kind of, but there isn't necessarily a 1:1 correspondance between an Interceptor and the interceptor class instance
[00:34:08] <dmlloyd> and certainly not a 1:1 correspondance between the existence of lifecycle method(s) on the instance
[00:34:22] <dmlloyd> and there are a lot of Interceptor instances which have nothing to do with method interceptors
[00:34:24] <stuartdouglas> yea, there may be several lifecycle methods per interceptor
[00:34:35] <dmlloyd> or lifecycle
[00:35:01] <dmlloyd> really the object instances used to implement the interceptors from the user's perspective are independent of the Interceptor implementation
[00:35:47] <dmlloyd> and some interceptor classes might not have @AroundInvoke, either
[00:36:36] <dmlloyd> probably what we need is a thing which creates the instances, a thing which wires em up to Interceptor for the ones which have @AroundInvoke, and a thing which wires em up with org.jboss.as.ee.component.ComponentLifecycle for the ones with lifecycle methods
[00:37:27] <stuartdouglas> that sounds reasonable
[00:40:11] <stuartdouglas> When you were talking about caching in the context were you talking about the stuff that happens in MethodInterceptorFactory?
[00:40:53] <dmlloyd> a similar process, but no
[00:41:14] <dmlloyd> org.jboss.invocation.SimpleInterceptorInstanceFactory
[00:44:06] *** laubai has joined #jboss-as7
[00:44:08] *** rmaucher has quit IRC
[00:44:23] *** laubai has quit IRC
[00:46:17] <stuartdouglas> Ok, for now I might try using the same InterceptorFactoryContext to get hold of the interceptor instances
[00:46:32] <stuartdouglas> and we can look at changing it later if need be
[00:47:39] <dmlloyd> only 7 files left with compile errors!
[00:47:50] <dmlloyd> (in ee.component anyway!)
[00:51:11] *** fnasser has joined #jboss-as7
[00:54:04] *** asoldano_away has quit IRC
[01:00:42] *** smarlow has joined #jboss-as7
[01:00:49] *** ChanServ sets mode: +v smarlow
[01:32:15] *** asaldhan has left #jboss-as7
[01:34:34] *** jpearlin has joined #jboss-as7
[01:35:33] <dmlloyd> anyone know offhand if there are ever circumstances where an EJB view would have a method with a different signature than the corresponding method on the EJB class itself?
[01:38:31] <dmlloyd> stuartdouglas: are you in AbstractComponentDescription?
[01:38:40] <stuartdouglas> yea
[01:38:54] <stuartdouglas> just the interceptor stuff
[01:39:09] <stuartdouglas> just make changes and I will fix any conflicts
[01:39:45] <dmlloyd> okay hopefully we won't collide, I'm just messing with the view stuff
[01:39:59] *** balunasj has joined #jboss-as7
[01:39:59] *** balunasj has joined #jboss-as7
[01:39:59] *** ChanServ sets mode: +v balunasj
[01:40:49] <stuartdouglas> That lifecycle interceptor stuff actually worked out quite nicely, I am just creating an Interceptor per lifecycle method
[01:41:01] <dmlloyd> hm, okay
[01:41:08] <stuartdouglas> and cause it shares the same context it will share the instances as well
[01:41:42] <dmlloyd> works is worth 9/10 of an argument :)
[01:41:57] <dmlloyd> or something like that
[01:56:24] <stuartdouglas> dmlloyd: This is what I have so far, it should (mostly) have lifecycle interceptors working https://github.com/stuartwdouglas/jboss-as/commit/2038c8b444c9b8acefd462c2d1333de4453c6428
[01:56:25] <jbossbot> git [jboss-as] 2038c8b.. Stuart Douglas Stuart Temp
[01:57:37] *** fnasser has quit IRC
[02:00:29] <dmlloyd> looks reasonable
[02:01:22] <dmlloyd> no conflicts, nice
[02:02:02] <stuartdouglas> now onto the rest of the interceptors
[02:02:31] <stuartdouglas> I renamed a method in the reflection index as well, as it was ambiguous
[02:02:51] <dmlloyd> yeah I saw
[02:31:34] <stuartdouglas> I introduced a few compile errors in that commit, most of them should be fixed in my beanch
[02:32:40] <dmlloyd> well you know, like I say, 0+0=0
[02:32:51] <dmlloyd> didn't work before, doesn't work now :)
[02:32:56] <stuartdouglas> hehe
[02:44:53] <dmlloyd> yessss, I get to add a fourteenth parameter to this method
[02:44:59] <dmlloyd> going for the record
[02:45:08] <dmlloyd> I don't know what the record is but I'm going for it
[03:05:13] *** balunasj has quit IRC
[03:07:49] *** balunasj has joined #jboss-as7
[03:07:49] *** balunasj has joined #jboss-as7
[03:07:49] *** ChanServ sets mode: +v balunasj
[03:09:09] <dmlloyd> stuartdouglas: any reason why we hang on to the InterceptorContext after the component instance is created?
[03:09:27] <stuartdouglas> should have been the InterceptorFactoryContext
[03:09:35] <stuartdouglas> that is fixed in my last commit
[03:09:46] <dmlloyd> okay
[03:09:46] <stuartdouglas> I need to to create the post construct interceptors
[03:09:59] <stuartdouglas> although I could create them earlier, and just hold onto them
[03:10:08] <dmlloyd> yeah that's what I was wondering
[03:10:27] <dmlloyd> just create the postconstruct and predestroy, stick em on a list or just in a single chained interceptor each
[03:10:57] <stuartdouglas> ok, although when I said post construct, I actually mean't pre destroy
[03:11:21] <dmlloyd> I think I'm changing the invocation interceptors a little
[03:11:30] <stuartdouglas> I apply the post construct ones at component creation time, and don't need them after that
[03:11:31] <dmlloyd> splitting up the bug ubermap of method->interceptor
[03:11:37] <Nihility> god
[03:11:38] <dmlloyd> into one per view
[03:11:41] <Nihility> i cant stand apache code
[03:12:17] <stuartdouglas> I can't stand apache cxf
[03:12:37] <Nihility> i have to share this:
[03:14:03] <Nihility> http://www.docjar.com/html/api/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java.html
[03:14:09] <Nihility> take a look at line 111
[03:14:23] <dmlloyd> ah, the metamorphasis
[03:14:33] <stuartdouglas> dmlloyd: Are you talking about AbstractComponentDescription or AbstractComponentConfiguration ?
[03:15:03] <dmlloyd> yes, both
[03:15:28] <dmlloyd> as in, that's where I'm monkeying with the interceptor maps
[03:16:04] <stuartdouglas> ok, can you push your changes when you are done? I have been changing the way the interceptor annotations are read
[03:16:06] <Nihility> maybe instead of quoting shitty novels
[03:16:13] <Nihility> they should read up on java programming
[03:16:45] <dmlloyd> stuartdouglas, okay, I haven't touched the annotations though.
[03:16:46] <Nihility> more specifically how to properly use a classloader :)
[03:20:23] <Nihility> so i breifly looked into saxon
[03:20:41] <Nihility> the disadvantage is that its an interpreted model
[03:20:56] <Nihility> so runtime perf is not as good as xsltc
[03:21:39] *** bstansberry_ has joined #jboss-as7
[03:21:39] *** ChanServ sets mode: +v bstansberry_
[03:21:39] *** bstansberry has quit IRC
[03:21:39] *** bstansberry_ is now known as bstansberry
[03:21:55] <dmlloyd> sure, otoh it doesn't need an insane class loader right? :)
[03:22:17] <Nihility> yes that is certainly true
[03:38:08] *** balunasj has quit IRC
[03:44:08] *** miclorb has quit IRC
[03:56:22] <stuartdouglas> dmlloyd: Are you still in AbstractComponentDescription and AbstractComponentConfiguration?
[03:56:29] <dmlloyd> yeah
[03:56:33] <dmlloyd> it's a tough one
[03:56:57] <dmlloyd> I'm mainly in the infamous prepareComponentConfiguration()
[04:03:44] *** miclorb_ has joined #jboss-as7
[04:16:03] *** smarlow has quit IRC
[04:21:51] *** jpearlin has left #jboss-as7
[04:23:56] *** pferraro has joined #jboss-as7
[04:23:56] *** ChanServ sets mode: +v pferraro
[04:24:37] <dmlloyd> hmm, I wonder if EJBs will need to vary their client interceptor based on its type
[04:33:21] <stuartdouglas> you mean based on the client type (local, remote ,webservice)?
[04:33:27] <dmlloyd> yeah
[04:33:36] *** pgier has quit IRC
[04:34:20] <stuartdouglas> It seems likely, but I am not really sure
[04:42:37] *** pferraro has quit IRC
[04:51:11] *** bgeorges has joined #jboss-as7
[04:51:11] *** ChanServ sets mode: +v bgeorges
[05:04:33] *** praba has joined #jboss-as7
[05:07:31] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/5161b08
[05:07:32] <jbossbot> git [jboss-as] 5161b08.. David M. Lloyd temp
[05:07:34] <dmlloyd> getting there
[05:07:45] <dmlloyd> I think I've got views really close...
[05:09:07] <stuartdouglas> awesome
[05:09:40] <dmlloyd> one more with minor fixes - http://github.com/dmlloyd/jboss-as/commit/c441cee
[05:09:41] <jbossbot> git [jboss-as] c441cee.. David M. Lloyd temp
[05:09:48] <dmlloyd> AbstractComponent just abotu compiles, just one problem with interceptors
[05:10:00] <dmlloyd> which you probably already have fixed...
[05:10:13] <dmlloyd> you want me to pull in yours?
[05:10:22] <dmlloyd> or you want to rebase first
[05:10:27] <stuartdouglas> just looking at the conflicts now
[05:10:32] * dmlloyd realized that calling all these commits temp is kidna backfiring
[05:16:12] <stuartdouglas> I have pushed
[05:16:47] <dmlloyd> looks like you're not up to date with c441cee
[05:17:36] <stuartdouglas> gah, more conflicts
[05:17:47] <dmlloyd> heh
[05:19:19] <stuartdouglas> pushed
[05:20:42] *** ALR has quit IRC
[05:22:22] <dmlloyd> are we using InterceptorInstallProcessor anymore
[05:22:23] <dmlloyd> ?
[05:23:30] *** pgier has joined #jboss-as7
[05:23:31] *** ChanServ sets mode: +v pgier
[05:24:37] <stuartdouglas> no
[05:24:41] <stuartdouglas> well, we should not be
[05:24:41] <dmlloyd> awesome.
[05:24:57] <stuartdouglas> we probably need to move the login somewhere else though
[05:25:12] <stuartdouglas> or at least, we need some kind of install logic somewhere :-)
[05:25:28] <dmlloyd> ComponentInstallProcessor is where it all is/will be
[05:31:55] *** praba has quit IRC
[05:33:22] <stuartdouglas> just booked my flights and hotels for new hire orientation :-)
[05:33:40] <dmlloyd> heh, you flying all the way to the US?
[05:33:48] <dmlloyd> or do they have one on your hemisphere
[05:33:51] <stuartdouglas> Just Brisbane
[05:34:00] <dmlloyd> ah, exotic brisbane
[05:35:22] *** praba has joined #jboss-as7
[05:35:39] <dmlloyd> praba, welcome.
[05:35:46] <dmlloyd> I saw your bug report, looks legitimate
[05:35:57] <praba> thanks. didn't expect a welcome though. :)
[05:36:26] <praba> i'm new to IRC and JBoss. so, pls excuse for any mistakes upfront.
[05:36:33] <dmlloyd> the problem is that people keep using that newFactory() method because in the actual rt.jar that is found on linux it looks like newInstance is deprecated in favor of newFactory
[05:36:46] <dmlloyd> but only newInstance() is actually supported, so it fails when running under other JDKs...
[05:37:40] <dmlloyd> anyway it should be an easy fix, as soon as I finish the problem I'm working on.
[05:38:00] <praba> cool.
[05:39:03] *** miclorb_ has quit IRC
[05:46:29] *** pgier has quit IRC
[05:51:09] <stuartdouglas> I have feeling that addJndiDependency is also going to need a AbstractComponentConfiguration parameter
[05:51:50] <dmlloyd> yeah it totally doesn't have enough parameters, I think we could put a lot more on there :)
[05:52:21] <dmlloyd> I've deleted the view binding source thing, moving that logic out of there
[05:52:32] <stuartdouglas> ok cool
[05:52:43] <stuartdouglas> with that gone I will just about have it compiling
[05:52:45] <dmlloyd> yet another blind alley in this silly maze
[05:53:36] <stuartdouglas> mainly by deleting anything that is not compiling :-)
[05:55:06] <stuartdouglas> I have made some changes to Phases / EESubsystemAdd so my new processors get installed in the correct order
[05:55:57] <dmlloyd> okay cool
[05:56:03] <dmlloyd> I havne't even begun thinking about that yet
[05:56:17] <stuartdouglas> It is probably still wrong
[05:56:23] <stuartdouglas> but less wrong than before
[05:57:53] <jbossbot> git [jboss-as] push master 9ea57c2.. kabir Make ModelController.execute() take an ExecutionContext instead of raw ModelNode...
[05:57:53] <jbossbot> git [jboss-as] push master 5e11e86.. kabir Introduce ExecutionAttachments as super interface of ExecutionContext, and make OperationContext implement ExecutionAttachments
[05:57:54] <jbossbot> git [jboss-as] push master b9094e3.. kabir Add the stream version of the deployment upload handler and fix bug in the protocol
[05:57:54] <jbossbot> git [jboss-as] push master bd97504.. bstansberry at jboss dot com Fix NPE introduced in commit 9ea57c24e53c3a5
[05:57:54] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/99eacd2...bd97504
[05:58:14] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/ad9e9de
[05:58:14] <jbossbot> git [jboss-as] ad9e9de.. David M. Lloyd Get views straightened out
[05:58:28] <dmlloyd> that one has a proper name to celebrate the occasion of EE probably being compiliable
[05:59:32] *** bstansberry has quit IRC
[06:01:36] <dmlloyd> now we just need a processor to add the EEModuleDescription sometime early on
[06:01:48] <dmlloyd> and of course fix managed beans, now horribly disfigured
[06:03:58] <stuartdouglas> I can look at managed beans if you like?
[06:04:27] <dmlloyd> sure
[06:05:01] <stuartdouglas> also I pushed a fix for my checkstyle errors, I need to configure idea to drop whitespace on the end of a line
[06:05:12] <dmlloyd> settings -> editor iirc
[06:05:26] <stuartdouglas> yep
[06:05:39] <stuartdouglas> odd, it was actually already set
[06:05:40] <dmlloyd> doesn't merge after my ad9e9de
[06:05:47] <dmlloyd> yeah there's one quirk with it
[06:06:01] <dmlloyd> if your cursor is on that line when you save after some trailing spaces, it won't trim it
[06:06:41] <stuartdouglas> should be good now, i forgot to force push
[06:07:02] <dmlloyd> got it
[06:07:22] <stuartdouglas> I have not had a single lock up or freeze since switching to idea
[06:07:48] <dmlloyd> nice
[06:07:55] <stuartdouglas> eclipse used to do it all the time, especially when editing poms
[06:14:22] <dmlloyd> where do we determine what type of EE deployment we're dealing with?
[06:14:48] <stuartdouglas> in the structure phase
[06:14:59] <stuartdouglas> it actually varies slightly
[06:15:00] <dmlloyd> ah it's spread across multiple processors
[06:15:06] <dmlloyd> rats
[06:15:22] <stuartdouglas> yea, and sometimes the ear processor can mark a sub deployment, cause it knows from application.xml
[06:15:32] *** praba has quit IRC
[06:16:32] *** jpearlin has joined #jboss-as7
[06:17:22] <stuartdouglas> are you looking at where to add the EEModule?
[06:17:27] <dmlloyd> yeah
[06:19:14] <stuartdouglas> do we still need ManagedBeanResourceTargetProcessor ?
[06:19:47] <dmlloyd> no I don't think so
[06:27:13] <stuartdouglas> all compiling
[06:27:22] <dmlloyd> yay
[06:31:03] <stuartdouglas> the smoke tests are all failing with NPE's, as there is no EEModule, but that is expected
[06:31:42] <dmlloyd> heh
[06:31:53] <dmlloyd> I think I'm just going to add a new processor for it
[06:32:09] <dmlloyd> I suspect that later on we'll want to collect a couple other bits of EE module info there, but we'll see
[06:32:37] <dmlloyd> do we have any other place where we're determining app/module name?
[06:33:29] <stuartdouglas> I use that stuff in weld I think, to generate bean deployment archive id's
[06:33:52] <stuartdouglas> JPA will probably use it as well
[06:34:28] <dmlloyd> I'm not really finding any single place where we are determining this today, which is interesting since we should be using that all over the place
[06:36:00] <stuartdouglas> The way I use it in weld is not really critical, I just needed a unique bean id, so I added the names in there
[06:36:45] <dmlloyd> INSTALL_APP_CONTEXT and INSTALL_MODULE_CONTEXT are not binding the right names :|
[06:38:29] <stuartdouglas> yea
[06:38:40] *** pferraro has joined #jboss-as7
[06:38:40] *** ChanServ sets mode: +v pferraro
[06:38:57] <dmlloyd> well might as well fix those too
[06:39:28] <stuartdouglas> the app name can be changed in the deployment descriptor
[06:39:45] <stuartdouglas> or the module name can anyway
[06:40:16] <stuartdouglas> and the deployment descriptors are read in all different places :-(
[06:40:58] <dmlloyd> yay
[06:41:08] <dmlloyd> well I'm not worrying about that right now
[06:41:23] <dmlloyd> it's clear we're going to have to sand the bumps off of the EE early processors
[06:42:09] <stuartdouglas> sand? I was thinking a chainsaw :-)
[06:45:08] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/c4e1b1f
[06:45:09] <jbossbot> git [jboss-as] c4e1b1f.. David M. Lloyd Bluh
[06:45:12] <dmlloyd> howzat
[06:45:47] <stuartdouglas> good
[06:46:29] <dmlloyd> I need to run thru AbstractComponentConfig to make sure I'm populating everything and there's no unused crap
[06:47:56] *** pferraro has quit IRC
[06:49:55] *** jpearlin has quit IRC
[06:51:44] <dmlloyd> looks like the ResourceInjections aren't being attached
[06:51:54] <dmlloyd> where are we creating interceptor instances?
[06:52:10] <dmlloyd> I have to be able to run injections at that point
[06:53:17] <stuartdouglas> hmm, well some of them will be created in AbstractComponent#createInstance(), so we probably need to create them all there
[06:53:47] <stuartdouglas> how do we perform injection into interceptors?
[06:54:02] <dmlloyd> run each ResourceInjection with the interceptor instance as the arg
[06:54:24] <dmlloyd> which means we need an association of List<ResourceInjection> with the interceptor config
[06:54:34] <dmlloyd> wherever that is..
[06:54:57] <dmlloyd> right now I'm creating and populating the lists, then dropping them on the floor
[06:55:07] <stuartdouglas> but we don't get the interceptor instance, as it is hidden behind Interceptor
[06:55:14] <dmlloyd> yay
[06:55:53] <dmlloyd> we need a custom InterceptorInstanceFactory that does all preinjection
[06:56:01] <dmlloyd> because those things can probably have CDI shit on them too
[06:56:12] <stuartdouglas> yea
[06:56:40] <stuartdouglas> there is an InjectingInterceptorInstanceFactory
[06:56:55] <stuartdouglas> it is just not hooked up yet
[06:57:07] <dmlloyd> looks like john was thinking ahead
[07:01:32] <dmlloyd> the lists for the interceptors will have to find their way on to AbCompCOnfig
[07:01:39] <dmlloyd> somehow
[07:01:48] <dmlloyd> so that CompInstallProc can add them on
[07:01:55] <stuartdouglas> yea
[07:02:41] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/d49337c <- there's about half of it
[07:02:42] <jbossbot> git [jboss-as] d49337c.. David M. Lloyd Blugh
[07:02:49] <dmlloyd> at least it covers instance injection for the comp instance
[07:02:57] <stuartdouglas> I'm just looking at another random bug at the moment, JAVA_CONTEXT_SERVICE_NAME has changed from a Context to a NamingStore
[07:03:00] <dmlloyd> hope you have an idea for the otehr half
[07:03:15] <dmlloyd> hm, that sounds familiar
[07:03:40] <dmlloyd> what's counting on it being a context
[07:03:56] <dmlloyd> the idea is that the Context will become read only someday
[07:04:04] <stuartdouglas> a few things JMSService and the jaas service
[07:04:12] <dmlloyd> not sure if we want to bind to a different writable context or use naming store
[07:04:24] <dmlloyd> ah those things shouldn't be fuckign with the java context in the first place
[07:04:29] <dmlloyd> not directly anyway
[07:04:34] <dmlloyd> they should just create a binding service
[07:05:07] <stuartdouglas> In the JMS case it looks like the context is being pased directly into hornetq code
[07:05:14] <dmlloyd> jesus
[07:05:15] <stuartdouglas> jaas is probably similar
[07:05:49] <stuartdouglas> actually jaas looks ok
[07:06:15] <stuartdouglas> ah, it NamingSubsystemAdd that is giving me problems
[07:18:33] <dmlloyd> hm, I forgot what I was doing
[07:18:47] <dmlloyd> which is probably a sign that 15 hours straight is about 7 hours too long
[07:19:08] <dmlloyd> want anything looked at before I crash?
[07:19:20] <stuartdouglas> not really, I think I am ok for the moment
[07:19:24] <dmlloyd> ok cool
[07:19:47] <dmlloyd> you'll probably be in bed when I get up, so if you want me to merge something just rebase it on d49337c and leave me a note in here
[07:19:57] <stuartdouglas> ok
[07:19:58] <dmlloyd> assuming my system doesn't spontaneously reboot again I'll check it out
[07:20:22] <dmlloyd> all right then, I'm out
[07:20:23] <dmlloyd> thanks dude
[07:20:43] <stuartdouglas> night
[07:23:37] *** praba has joined #jboss-as7
[08:06:05] *** praba has quit IRC
[08:23:49] *** opalka has joined #jboss-as7
[08:23:50] *** opalka has joined #jboss-as7
[08:23:50] *** ChanServ sets mode: +v opalka
[08:24:01] *** bgeorges has quit IRC
[08:33:35] *** pilhuhn has joined #jboss-as7
[08:33:36] *** pilhuhn has joined #jboss-as7
[08:33:36] *** ChanServ sets mode: +v pilhuhn
[08:34:38] *** aloubyansky has quit IRC
[09:09:40] *** asoldano has joined #jboss-as7
[09:09:40] *** ChanServ sets mode: +v asoldano
[09:21:55] *** wolfc has joined #jboss-as7
[09:21:55] *** ChanServ sets mode: +v wolfc
[09:24:09] *** aloubyansky has joined #jboss-as7
[09:40:57] *** epbernard has joined #jboss-as7
[09:40:57] *** epbernard is now known as emmanuel
[09:40:57] *** ChanServ sets mode: +v emmanuel
[09:50:32] *** emuckenhuber has quit IRC
[09:51:04] *** emmanuel has left #jboss-as7
[10:03:19] *** opalka has quit IRC
[10:10:26] *** alesj has joined #jboss-as7
[10:12:21] *** bgeorges has joined #jboss-as7
[10:17:04] *** emuckenhuber has joined #jboss-as7
[10:17:04] *** emuckenhuber has joined #jboss-as7
[10:17:04] *** ChanServ sets mode: +v emuckenhuber
[10:20:26] *** bgeorges has quit IRC
[10:20:48] *** bgeorges has joined #jboss-as7
[10:29:36] *** bgeorges has quit IRC
[10:38:51] *** AndyTaylor has joined #jboss-as7
[10:38:51] *** ChanServ sets mode: +v AndyTaylor
[11:05:44] *** kkhan has joined #jboss-as7
[11:05:44] *** ChanServ sets mode: +v kkhan
[11:07:07] *** miclorb_ has joined #jboss-as7
[11:09:12] <stuartdouglas> dmlloyd: When you wake up I will have stuff to pull
[11:09:29] <stuartdouglas> how much stuff remains to be seen
[11:13:54] *** rmaucher has joined #jboss-as7
[11:14:35] *** jcosta has joined #jboss-as7
[11:14:35] *** ChanServ sets mode: +v jcosta
[11:24:36] *** ALR has joined #jboss-as7
[11:24:36] *** ChanServ sets mode: +v ALR
[11:28:05] *** maeste has joined #jboss-as7
[11:28:06] *** ChanServ sets mode: +v maeste
[11:33:00] *** torben has joined #jboss-as7
[11:33:00] *** ChanServ sets mode: +v torben
[11:39:27] *** miclorb_ has quit IRC
[11:40:53] *** miclorb has joined #jboss-as7
[11:47:12] *** praba has joined #jboss-as7
[12:04:45] *** alesj has quit IRC
[12:16:10] *** darranl has joined #jboss-as7
[12:16:11] *** darranl has joined #jboss-as7
[12:16:11] *** ChanServ sets mode: +v darranl
[12:17:02] *** alesj has joined #jboss-as7
[12:19:10] *** miclorb has quit IRC
[12:20:32] *** emmanuel has joined #jboss-as7
[12:20:33] *** ChanServ sets mode: +v emmanuel
[12:24:21] *** praba_ has joined #jboss-as7
[12:24:41] *** praba has quit IRC
[12:24:50] *** praba_ is now known as praba
[12:26:49] *** stalep has joined #jboss-as7
[12:33:48] *** praba has quit IRC
[13:05:02] *** torben is now known as torben|lunch
[13:09:28] *** ALR has quit IRC
[13:09:46] *** mmoyses has joined #jboss-as7
[13:09:46] *** ChanServ sets mode: +v mmoyses
[13:12:26] *** asoldano is now known as asoldano_lunch
[13:15:56] <darranl> hi kkhan / emuckenhuber - is the push from Brian last night to master the domain-op branch?
[13:16:16] <kkhan> darranl: Yes, that came from domain-op
[13:16:38] <darranl> thanks kkhan, will move back to master
[13:37:36] *** stansilvert has joined #jboss-as7
[13:43:08] <alesj> stuartdouglas: ping?
[13:53:20] *** asoldano_lunch is now known as asoldano
[14:00:36] *** torben|lunch is now known as torben
[14:03:22] *** balunasj has joined #jboss-as7
[14:03:22] *** balunasj has joined #jboss-as7
[14:03:22] *** ChanServ sets mode: +v balunasj
[14:06:02] *** AndyTaylor is now known as AndyLunch
[14:06:32] *** Praba has joined #jboss-as7
[14:11:05] *** maeste has quit IRC
[14:11:41] *** maeste has joined #jboss-as7
[14:11:42] *** ChanServ sets mode: +v maeste
[14:11:46] *** jhalliday has joined #jboss-as7
[14:13:36] <jhalliday> asoldano: ping
[14:14:04] <asoldano> jhalliday, pong
[14:14:22] <jhalliday> asoldano: hiya.  how functional is the WS stack in AS7 at present?
[14:14:22] *** maeste has quit IRC
[14:14:56] <asoldano> jhalliday, well, POJO endpoints only, no security and ws-*
[14:15:07] *** maeste has joined #jboss-as7
[14:15:08] *** ChanServ sets mode: +v maeste
[14:15:43] <jhalliday> ok, so what's the target date by which I could reasonably expect something functional enough to run XTS ?
[14:15:46] <asoldano> jhalliday, no jaxrpc (but I don't think you're interested in that ;-))
[14:16:44] <asoldano> jhalliday, what do you need besides ws-addressing in terms of ws-* ?
[14:17:20] <jhalliday> hmm. won't know for sure until adinn return from lunch, but hopefully not much.
[14:18:12] <asoldano> jhalliday, ok. Anyway, I'd say you need to wait for ejb3 to come to AS7, then we'll do the ws-ejb3 integration and in the mean time start with the standalone jaxws cert work
[14:18:32] <asoldano> jhalliday, at that point you should more or less have what you need
[14:18:32] *** maeste has quit IRC
[14:18:40] <jhalliday> why do I need ejb3?
[14:18:52] <asoldano> jhalliday, no ejb3 ws endpoints ?
[14:19:06] *** maeste has joined #jboss-as7
[14:19:06] *** ChanServ sets mode: +v maeste
[14:19:17] <jhalliday> no assumption that there as an ejb container at all I hope
[14:19:34] <asoldano> jhalliday, even better ;-)
[14:20:19] <asoldano> jhalliday, then you might even start running something and seeing what's the current status; the basic jaxws functionalities are alredy in, for pojo endpoints
[14:20:26] *** jpederse has joined #jboss-as7
[14:20:38] <jhalliday> I thought you said no ws-addressing yet?
[14:20:57] <asoldano> jhalliday, not complete
[14:20:59] *** jpederse has quit IRC
[14:20:59] *** jpederse has joined #jboss-as7
[14:21:11] <jhalliday> ok, so when is that due?
[14:21:26] *** maeste has quit IRC
[14:22:05] *** maeste has joined #jboss-as7
[14:22:05] *** ChanServ sets mode: +v maeste
[14:22:36] <asoldano> jhalliday, currently the deadline is for passing jaxws standalone cert by the time AS7 goes GA, everything else is at best effort till that point. But the latest jaxws tck covers a good part of ws-addressing functionalities you use
[14:22:51] <asoldano> jhalliday, I can be more precise in some week, once we finish with the most low level integration
[14:23:52] <jhalliday> that's not going to work - we need TS final by GA too and I can't deliver that unless I can test XTS, so the WS feature complete will have to be long before GA
[14:24:40] <asoldano> jhalliday, how is that possible considering WS is kind of "something additional" for AS7, given it's not part of the web profile?
[14:25:07] <asoldano> jhalliday, anyway...
[14:25:31] <asoldano> jhalliday, I do want to have a jaxws compliant stack long before GA, just can't commit on an exact date right now
[14:26:05] <jhalliday> yeah, don't get me started :-)  I think the argument goes something like this: XTS works on EAP5, so must work on EAP6 or will be a regression for customers. Same story with JTS which is not web profile either.
[14:29:30] *** Jaikiran has joined #jboss-as7
[14:29:31] *** Jaikiran has quit IRC
[14:29:31] *** Jaikiran has joined #jboss-as7
[14:29:31] *** ChanServ sets mode: +v Jaikiran
[14:29:46] <asoldano> jhalliday, well, dependency on EAP6 is something different, there's going to be some time between AS7 final release and EAP 6. I'd suggest we move this to a private email thread with managers on the scheduling then.
[14:30:15] <asoldano> jhalliday, WS too needs to be fully operational for the EAP6 that will cover full profile
[14:34:26] *** bgeorges has joined #jboss-as7
[14:35:59] <jhalliday> asoldano: in general the product folks won't let us do component upgrades after the AS7 Final, so the time after that is not really relevant
[14:36:05] *** emmanuel has quit IRC
[14:36:13] <jhalliday> unless they changed the rules again
[14:45:48] *** balunasj is now known as balunasj_away
[14:54:04] *** smarlow has joined #jboss-as7
[14:54:05] *** ChanServ sets mode: +v smarlow
[14:54:52] *** alesj1 has joined #jboss-as7
[14:56:37] *** alesj has quit IRC
[14:57:55] *** alesj has joined #jboss-as7
[15:01:10] *** alesj1 has quit IRC
[15:02:44] <smarlow> jhalliday:  I didn't workaround JBTM-828 yet.  Does it make sense to make a pass through JBossTS and eliminate some of the TCCL cases for AS7?
[15:02:45] <jbossbot> jira [JBTM-828] Please avoid TCCL in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBTM-828
[15:03:19] <jhalliday> smarlow: I started doing that this morning :-)
[15:03:34] <smarlow> jhalliday:  great,  thank you!  :-)
[15:07:07] *** pgier has joined #jboss-as7
[15:07:08] *** ChanServ sets mode: +v pgier
[15:07:27] *** pgier has quit IRC
[15:08:33] *** jcosta has quit IRC
[15:09:33] *** Praba has quit IRC
[15:13:30] *** jcosta has joined #jboss-as7
[15:13:30] *** ChanServ sets mode: +v jcosta
[15:13:35] *** pgier has joined #jboss-as7
[15:13:35] *** ChanServ sets mode: +v pgier
[15:21:29] *** bstansberry has joined #jboss-as7
[15:21:29] *** ChanServ sets mode: +v bstansberry
[15:28:36] *** Jaikiran has quit IRC
[15:32:29] *** pferraro has joined #jboss-as7
[15:32:29] *** ChanServ sets mode: +v pferraro
[15:33:05] <Nihility> hmm vpn not responding today
[15:35:15] <dmlloyd> works for me
[15:35:21] *** asaldhan has joined #jboss-as7
[15:35:21] *** ChanServ sets mode: +v asaldhan
[15:35:26] <dmlloyd> stuartdouglas: still up?
[15:35:34] <jhalliday> look on the bright side, you  can get some work done instead of reading email.
[15:38:05] <dmlloyd> cool, stuart got a bunch more done.
[15:38:37] <dmlloyd> now the main remaining issue is, stuff which is expecting, for whatever reason, to pull Contexts out of MSC and populate them.
[15:39:21] *** epbernard has joined #jboss-as7
[15:39:21] *** epbernard is now known as emmanuel
[15:39:30] *** ChanServ sets mode: +v emmanuel
[15:39:37] *** emmanuel has left #jboss-as7
[15:42:17] *** pferraro has quit IRC
[15:44:00] *** darranl is now known as darranl_afk
[15:51:10] <asaldhan> dmlloyd: hey not sure why the eap6 doc people want the n/w ports right now.  But we need to fill out http://community.jboss.org/docs/DOC-16507  as we proceed. :)
[15:52:39] <dmlloyd> I'll fill it out as soon as I'm sure what's going on
[15:52:48] *** pferraro has joined #jboss-as7
[15:52:48] *** ChanServ sets mode: +v pferraro
[15:53:30] *** smcgowan has joined #jboss-as7
[15:53:30] *** ChanServ sets mode: +v smcgowan
[15:55:26] <dmlloyd> who is our messaging subsystem expert?
[15:55:50] <jpederse> dmlloyd: Stark ?
[15:56:06] <jpederse> AndyLunch: ^
[15:56:25] *** AndyLunch is now known as AndyTaylor
[15:56:45] <AndyTaylor> dmlloyd: ahem
[15:56:58] <dmlloyd> I'll have questions for you in a second or two
[15:57:01] <dmlloyd> as soon as my compile fails :)
[15:57:03] <AndyTaylor> dmlloyd: no worries
[15:57:17] <AndyTaylor> dmlloyd: :)
[15:57:19] <dmlloyd> holy shit, it didn't fail
[15:57:28] <AndyTaylor> dmlloyd: thats always a bad sign i find
[15:57:31] <dmlloyd> well we'll see the tests blow up for sure
[15:57:54] <dmlloyd> and there it is
[15:57:55] <dmlloyd> okay
[15:59:41] <dmlloyd> jboss.messaging.jms.manager
[16:00:21] <AndyTaylor> dmlloyd: ahhhh, jboss mesaging not HornetQ
[16:00:38] <AndyTaylor> dmlloyd: ok, howards the main man, but i'll try and help
[16:00:53] <dmlloyd> wait, this is really jboss messaging?
[16:01:04] <dmlloyd> org.jboss.as.messaging.jms.JMSService
[16:01:11] <dmlloyd> actually written by emuckenhuber
[16:01:25] <dmlloyd> this, and a bunch of other services like it, are injecting a Context to put its stuff into JNDI
[16:01:32] <dmlloyd> but that's no longer allowed
[16:01:53] <dmlloyd> (in my EE branch)
[16:02:03] <dmlloyd> instead they need to create BinderServices
[16:02:10] <AndyTaylor> dmlloyd: which branch and what classes
[16:02:21] <dmlloyd> http://github.com/dmlloyd/jboss-as/tree/ee
[16:02:28] <dmlloyd> class org.jboss.as.messaging.jms.JMSService
[16:02:48] <kkhan> It uses hornetq but the AS package uses messaging
[16:03:02] <kkhan> AS package uses messaging in its name
[16:03:04] <emuckenhuber> afaik hornetQ is binding this internally, right? i don't think we have much control about that
[16:03:10] <AndyTaylor> kkhan: ahh ok
[16:03:24] <dmlloyd> hmmm
[16:03:34] <dmlloyd> that's going to be a major problem
[16:04:07] <dmlloyd> everything in JNDI has to use BinderService so that dependencies work
[16:04:18] <dmlloyd> and Contexts are eventually going to be read-only
[16:04:37] <dmlloyd> so, I'm open to ideas :)
[16:05:00] <dmlloyd> EE branch completely builds btw, and starts (with a couple errors)
[16:05:18] <kkhan> bstansberry: ping
[16:05:22] <dmlloyd> (including some smoke test errors though)
[16:05:28] <AndyTaylor> dmlloyd: so we cant use jndi directly to bind stuff
[16:05:41] <dmlloyd> right
[16:05:43] <AndyTaylor> dmlloyd: instead we should usethe BinerService
[16:05:52] <dmlloyd> yes
[16:05:58] <AndyTaylor> dmlloyd: ok, well we will need to abstract this stuff out and provide 2 implementations then
[16:06:03] <bstansberry> kkhan: pong
[16:06:12] <AndyTaylor> since we wouls still use jndi direct standalone
[16:06:24] <AndyTaylor> dmlloyd: raise a jira and we'll get it done
[16:06:48] <AndyTaylor> dmlloyd: whats the time frames here
[16:07:01] <kkhan> bstansberry: I'm just wondering about ServerDeploymentManager.addDeploymentContent() vs DeploymentPlanBuilder.add()
[16:07:10] <dmlloyd> AndyTaylor: it needs to be done three weeks ago :)
[16:07:21] <AndyTaylor> dmlloyd: thats old chestnut :)
[16:07:22] <kkhan> I assume even if you use the SDM you would still need a builder and call deploy()
[16:07:50] <dmlloyd> AndyTaylor: well, the beta1 deadline is in 2 weeks and this all has to work perfectly by then
[16:07:51] <kkhan> to actually deploy it
[16:07:56] <AndyTaylor> dmlloyd: well it shouldnt be that difficult to do, however, we are snowed under with eap stuff at the mo
[16:07:57] <dmlloyd> AndyTaylor: and in that time we have to fully implement EJB :)
[16:08:04] <AndyTaylor> dmlloyd: good luck
[16:08:07] <dmlloyd> ha
[16:08:24] <dmlloyd> emuckenhuber: is there any chance you could look at it?
[16:09:08] <AndyTaylor> dmlloyd: can you raise a jira anyway as this needs to be done in HornetQ code
[16:09:16] <dmlloyd> okay
[16:09:18] <bstansberry> kkhan: right; the addDeploymentContent just did an upload
[16:09:43] <bstansberry> that method probably doesn't make sense any more
[16:09:58] <kkhan> Cool, that was what what I was hoping :-)
[16:10:05] <bstansberry> i.e. the builder impl can do whatever is needed behind the scenes
[16:10:40] <kkhan> Cool, that clears things up
[16:10:41] <emuckenhuber> dmlloyd: hmm, i'll see if i find some time to look at it
[16:10:50] <dmlloyd> AndyTaylor: HORNETQ-650
[16:10:51] <jbossbot> jira [HORNETQ-650] Allow access to things which are being bound into JNDI [Open (Unresolved) Enhancement, Major, Clebert Suconic] https://issues.jboss.org/browse/HORNETQ-650
[16:11:06] <AndyTaylor> dmlloyd: ta
[16:13:22] <emuckenhuber> bstansberry: you have a minute?
[16:13:45] <bstansberry> i'm on a call, so 1/2 attention :)
[16:14:07] <emuckenhuber> bstansberry: ok, after the call then ;)
[16:16:36] <smarlow> dmlloyd:  I was just talking to maeste about a JDBC driver class not found (same http://pastebin.com/E7BS7Xrs that we discussed yesterday).  In the current datasource demo, we hack around the error with MANIFEST.MF classpath entries.  Is there a magic solution coming to this CNFE via your EE magic changes?
[16:17:51] <dmlloyd> not directly, smarlow, but it makes it possible - it's going to be up to the JCA deployers to detect that a JDBC driver is used and make sure that it is added as a modular dependency
[16:18:31] <maeste> dmlloyd: that's done
[16:18:49] <maeste> dmlloyd: eventually buggy :) but sould be done
[16:18:51] <dmlloyd> awesome :)
[16:19:36] <maeste> dmlloyd: we have added dependency on the "right" service created during jdbc deployments
[16:19:46] <maeste> dmlloyd: that's all right?
[16:20:03] <dmlloyd> the service dependency is important but there's also a modular dependency that must be added
[16:20:11] <dmlloyd> so that class loading works
[16:20:26] <dmlloyd> (depending on how you did it of course)
[16:21:14] <maeste> dmlloyd: an example of modular dependency I can have a look?
[16:21:26] <maeste> dmlloyd: or docs if you prefer :P
[16:21:42] <dmlloyd> maeste: org.jboss.as.webservices.deployers.WSDependenciesProcessor
[16:21:45] <dmlloyd> maeste: I wish we had docs :)
[16:22:02] <dmlloyd> maeste: asoldano's example here is good because it's really complex :)
[16:22:08] <maeste> dmlloyd: cool, my old love WS
[16:22:18] <dmlloyd> these are all static module deps though
[16:22:26] <dmlloyd> you want deployment deps, so that would be more like....
[16:22:55] <dmlloyd> org.jboss.as.server.deployment.module.ModuleClassPathProcessor
[16:23:16] <dmlloyd> although one thing you could do is just add an entry to org.jboss.as.server.deployment.Attachments#CLASS_PATH_ENTRIES
[16:23:51] <dmlloyd> stuartdouglas: when you're back on... when we add class-path entries are we also adding a MSC dependency?
[16:23:51] <asoldano> dmlloyd, speaking of org.jboss.as.webservices.deployers.WSDependenciesProcessor ... if you or someone else have few minutes, please pull latest Richard's stuff
[16:23:55] <maeste> dmlloyd: I'll have a look to the examples
[16:24:10] <dmlloyd> asoldano: it's in my queue
[16:24:16] <asoldano> dmlloyd, thanks!
[16:24:59] <maeste> dmlloyd: ut what is the minus of adding an entry to org.jboss.as.server.deployment.Attachments#CLASS_PATH_ENTRIES respect examples you have pointed me?
[16:25:32] <maeste> dmlloyd: I'm asking just to have a better understanding
[16:26:02] <dmlloyd> maeste, right now I'm not sure it adds a proper MSC dependency but it will.  That might actually be the best way to do it (== least amount of work)
[16:28:37] <maeste> dmlloyd: oki, could you or stuartdouglas send me an email with the answer if I'll be on the bed when he get online?
[16:29:07] <dmlloyd> sure
[16:29:53] <maeste> dmlloyd: thanks a lot
[16:30:33] *** darranl_afk is now known as darranl
[16:33:02] <maeste> dmlloyd: but anyway this change need also your EE stuffs merged to work right?
[16:33:35] <dmlloyd> not if you add it to the class path (in combination with the code you already have) - the EE branch will change the way injection works though which we'll have to discuss
[16:34:22] *** mmoyses is now known as mmoyses_
[16:34:23] <maeste> dmlloyd: oki, perfect. So I'll do that tomorrow.
[16:34:37] <maeste> smarlow: ^^^ hoping to ask a pull very soon
[16:34:48] <smarlow> cool!  Thanks!  :)
[16:41:51] <bstansberry> emuckenhuber: call's done. how are things?
[16:42:36] <emuckenhuber> bstansberry: hey, so i wanted to talk to about multi host / server operations - did you do some work on that as part of your domain-ops already?
[16:44:25] <bstansberry> just the general idea of pushing the op(s) out to the hosts, hosts ignore pieces that are irrelevant to them (e.g. step 2 of 5 is for another host)
[16:45:32] <bstansberry> so my thinking was is there would be an earlier stage of resolving the wildcards
[16:46:35] <emuckenhuber> so that we execute a i.e. "resolve-address" operation first and then create a multi step operation?
[16:47:03] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/7f854e0 <- Worked around.... for now....
[16:47:04] <jbossbot> git [jboss-as] 7f854e0.. David M. Lloyd Work around Context issue for now
[16:48:12] <dmlloyd> something crazy is going on and I'm not sure it's specific to my branch
[16:48:19] <dmlloyd> on startup, it's trying to remove the naming subsystem
[16:48:26] <dmlloyd> and it's starting up OSGi twice
[16:48:28] <bstansberry> that could work -- something like that would probably be needed if the
[16:48:47] <dmlloyd> http://fpaste.org/Ee8F/
[16:48:51] <bstansberry> wilcard results in multiple servers being called
[16:50:31] <bstansberry> do wildcard ops work in standalone mode?
[16:50:38] <emuckenhuber> bstansberry: yes
[16:50:47] <emuckenhuber> bstansberry: the other way would be to have something like "nested operations"
[16:51:22] <bstansberry> please describe what you mean...
[16:51:32] <smarlow> carlo:  For the EJB3 injectors that I will write for JPA, can the injectors live in the JPA codebase?  This influences how much SPI I need for JPA integration.
[16:54:31] <emuckenhuber> bstansberry: basically without calling "resolve-address" you don't know the "number of operations" it results in - one way is to dispatch only to the known local proxies
[16:54:49] <emuckenhuber> and then let them resolve the next level - so the DC knows the hosts and each host knows the servers
[16:55:43] <emuckenhuber> however we would most likely need to introduce a multiOperationHandler - which takes the complete operation result (completed, failed, etc)
[16:56:43] <bstansberry> what I'm doing kind of works that way
[16:57:17] <bstansberry> the DC dispatches to all the slaves; they execute and their response includes information about what server level ops need to get executed
[16:57:40] <bstansberry> that's a similar kind of resolution
[16:58:30] <emuckenhuber> yes, for me the main difference is that it's different from the resultHandler in terms of aggregation
[16:58:31] *** mmoyses_ is now known as mmoyses
[16:58:59] <bstansberry> assembling everything back into a meaningful response is the painful part
[16:59:35] *** epbernard has joined #jboss-as7
[16:59:35] *** ChanServ sets mode: +v epbernard
[16:59:58] <emuckenhuber> yes, it does not really seem to work out with the ResultHandler - so i thought it makes more sense to introduce something separate
[17:00:31] <bstansberry> FYI, https://github.com/bstansberry/jboss-as/tree/my-domain-op has my work in progress
[17:00:48] <bstansberry> needs to be rebased to pick up kkhan's stuff from yesterday
[17:00:52] <smcgowan> asoldano:  jaxb APIs in as7 are 1.0.0.Final, did you want to have the JBEE-74 fix in and use 1.0.1.Final ?
[17:00:53] <jbossbot> jira [JBEE-74] jboss-jaxb-api_2.2_spec-1.0.0.Final missing Message.properties [Resolved (Done) Bug, Major, Shelly McGowan] https://issues.jboss.org/browse/JBEE-74
[17:01:25] *** epbernard is now known as emmanuel
[17:02:08] <asoldano> smcgowan, I workarounded the problem locally while waiting for JBEE-74, so I forgot. Yes, having the latest version in would be better
[17:02:09] <jbossbot> jira [JBEE-74] jboss-jaxb-api_2.2_spec-1.0.0.Final missing Message.properties [Resolved (Done) Bug, Major, Shelly McGowan] https://issues.jboss.org/browse/JBEE-74
[17:02:21] <bstansberry> can you give me a link to what you've got for standalone? that will help me understand what you've had to do
[17:02:51] <smcgowan> asoldano:  i'm working an commit now so i'll add it to my pull request
[17:03:01] <asoldano> smcgowan, thanks!
[17:03:53] <emuckenhuber> bstansberry: https://github.com/emuckenhuber/jboss-as/commit/57d6027ab9bea804bf525ad86e70fc337be00700
[17:03:53] <jbossbot> git [jboss-as] 57d6027.. Emanuel Muckenhuber basic wildcard handling
[17:04:21] <emuckenhuber> bstansberry: the proxy stuff does not make any sense though
[17:05:52] <emuckenhuber> i messed up my rebase on master - so i also had a "resolve-address" action, but the multi operation then failed because of some protocol stuff
[17:19:03] *** balunasj_away is now known as balunasj
[17:25:44] <dmlloyd> boot operation errors are never being logged
[17:31:24] *** jcosta has quit IRC
[17:34:23] *** asoldano is now known as asoldano_away
[17:44:26] *** ALR has joined #jboss-as7
[17:44:29] *** ALR has quit IRC
[17:44:29] *** ALR has joined #jboss-as7
[17:44:29] *** ChanServ sets mode: +v ALR
[17:45:08] *** emmanuel has quit IRC
[17:45:12] *** epbernard has joined #jboss-as7
[17:45:12] *** epbernard is now known as emmanuel
[17:45:12] *** ChanServ sets mode: +v emmanuel
[17:47:30] *** AndyTaylor has quit IRC
[17:52:31] <jhalliday> smcgowan: ping
[18:05:38] *** jcosta has joined #jboss-as7
[18:06:56] *** emuckenhuber has quit IRC
[18:10:05] <smcgowan> jhalliday: pong
[18:13:40] <jhalliday> smcgowan: I'm busy with TCCL stuff but mmusgrov has volunteered to take JBAS-8910 if you want to offload it.
[18:13:41] <jbossbot> jira [JBAS-8910] Upgrade JBossTS to version 4.14.0.Final [Open (Unresolved) Thirdparty Change, Major, Shelly McGowan] https://issues.jboss.org/browse/JBAS-8910
[18:14:08] *** pilhuhn is now known as pil-afk
[18:17:56] <smcgowan> jhalliday:  i was looking into the replacement for: ObjStoreBean.getObjectStoreBrowserBean();
[18:18:22] <smcgowan> is mmusgrov around to chat with
[18:18:22] <kkhan> bstansberry: I'm trying to understand DeploymentFullReplaceHandler do you have an example of its use?
[18:18:45] <smcgowan> that's all that's left, but you/he may want to do this a diff way
[18:18:59] <jhalliday> smcgowan: see comment on the jira for that or try freenode #jbossts
[18:19:21] <bstansberry> kkhan: it's used when v2 of foo.war replaces v1
[18:19:33] <bstansberry> they both have the same "unique name"
[18:20:07] <kkhan> I'm not really seeing when its new data gets added to the repository, or is that via a preceding 'add'?
[18:20:55] <bstansberry> via a preceding "upload"
[18:21:06] <smcgowan> jhalliday:  ok
[18:21:17] <bstansberry> i.e. one of the ops handled by a subclass of AbstractDeploymentUploadHandler
[18:21:59] <bstansberry> not via an op that calls DeploymentAddHandler, as that would fail due to a non-unique name
[18:23:15] <bstansberry> with the new streams stuff though, if, optionally, the user attached a stream and added an "attachment" param, then the AbstractDeploymentUploadHandler step could be skipped
[18:23:59] <bstansberry> DeploymentFullReplaceHandler could do that part itself
[18:24:47] <kkhan> bstansberry: ok, I think I know why this is weird now
[18:25:12] <kkhan> I collapsed the previous add() methods
[18:25:39] <kkhan> to not check for uniqueness and upload via the distributor
[18:25:50] <kkhan> which is now happening in the add handler
[18:26:12] <kkhan> instead attaching input steams to the add operation
[18:26:22] <kkhan> and was going to do the same to the replace operation
[18:26:40] <kkhan> so the missing upload of data is my fault
[18:27:20] <kkhan> Your 'optionally' part worries me a bit
[18:27:44] <kkhan> since I've kind of ripped out the old upload stuff and am doing it all via streams :-)
[18:27:49] *** asoldano_away is now known as asoldano
[18:28:04] <bstansberry> hmm, don't do that
[18:28:11] <kkhan> But I guess I can make the ops handling streams now either look for the hash or for the attachment
[18:28:27] <kkhan> i.e. add handler and fullreplace
[18:28:43] <kkhan> I guess from CLI it would make sense to do this the old way
[18:29:00] <kkhan> and pass in the stream as part of the operation like used to happen
[18:29:21] <kkhan> as part of an upload step I mean
[18:29:22] <bstansberry> i wouldn't be surprised if we trash the ld ones soon
[18:29:39] <bstansberry> but jpearlin is working on http stuff, and we need to coordinate
[18:29:41] <kkhan> and then have the api use streams
[18:29:41] *** emuckenhuber has joined #jboss-as7
[18:29:41] *** ChanServ sets mode: +v emuckenhuber
[18:30:00] <kkhan> ok, I'll try to make it work as it did as well as the new way
[18:30:43] <bstansberry> i'm mostly trying to avoid coordinating, as i'm going to drop that ball for sure
[18:31:45] <bstansberry> if I see him online, i'll point him to the stream stuff
[18:36:16] <kkhan> bstansberry: Do you know where his stuff lives?
[18:37:03] <bstansberry> Nihility: do you know where jpearlin keeps his git repo?
[18:37:18] <Nihility> yes i do its jdpgrailsdev
[18:37:24] <kkhan> thanks
[18:37:51] <bstansberry> kkhan has added the ability to pass streams in via the ModelControllerClient API
[18:38:24] <bstansberry> which may be a better way to deal with that form POST, instead of writing to a tmp file and passing in the URL
[18:39:39] *** alesj has left #jboss-as7
[18:39:42] <kkhan> Nihility: Here is an example from my local copy of AbstractServerDeploymentManager http://pastebin.com/pFJY0VB1, not committed yet
[18:41:26] *** alesj has joined #jboss-as7
[18:42:53] *** alesj has quit IRC
[18:44:56] *** torben has quit IRC
[18:45:40] *** stalep has quit IRC
[18:47:07] *** emmanuel has quit IRC
[18:57:24] *** alesj has joined #jboss-as7
[19:00:08] <alesj> dmlloyd: ping?
[19:02:58] *** smcgowan has quit IRC
[19:03:14] <dmlloyd> alesj: pong
[19:04:29] *** jhalliday has quit IRC
[19:04:33] *** jcosta has quit IRC
[19:05:27] <alesj> dmlloyd: a River question :-)
[19:06:17] <alesj> i implement "private void writeObject(ObjectOutputStream out)" on a Serializable class
[19:06:26] <alesj> but it looks like it doesn't kick in
[19:07:04] <alesj> which looks weird, as this is a trivial use case, which i'm sure you test
[19:07:07] <alesj> dmlloyd: ^^
[19:07:11] <dmlloyd> it is tested, it does work
[19:07:33] <dmlloyd> can I see an example which shows the problem?
[19:07:43] <alesj> http://pastebin.com/Z5xmVNfQ
[19:07:45] <dmlloyd> JBMAR is one project that I'm sure is tested :)
[19:07:57] <alesj> where as the class is here:
[19:08:18] <dmlloyd> looks like SharedAttributeMap is not serializable
[19:08:37] <alesj> https://github.com/alesj/weld-shared/blob/master/jetty6/src/main/java/org/jboss/weld/shared/jetty6/session/InfinispanSessionManager.java
[19:08:39] <kkhan> bstansberry: Would you mind taking a look at my 'deployment' branch? I've made DeploymentAddHandler and DeploymentFullReplaceHandler stream capable.
[19:08:56] *** darranl has quit IRC
[19:08:59] <alesj> dmlloyd: the SAMap is not serializable
[19:09:10] <alesj> dmlloyd: but see https://github.com/alesj/weld-shared/blob/master/jetty6/src/main/java/org/jboss/weld/shared/jetty6/session/InfinispanSessionManager.java
[19:09:15] * bstansberry looks
[19:09:15] *** balunasj is now known as balunasj_busy
[19:09:16] <dmlloyd> alesj, first, serializing an inner class has undefined behavior
[19:09:30] <alesj> and its InfinispanSession _value = null
[19:09:39] <dmlloyd> yeah but then you're calling defaultWriteObject
[19:09:56] <dmlloyd> you need to have _values be transient if you don't want it serialized
[19:09:59] <alesj> sure, but i null out the map before
[19:10:14] <alesj> SharedAttribMap is _values ref
[19:10:24] <alesj> which gets nulled before serialization
[19:10:48] <dmlloyd> where is Session defined
[19:10:58] <alesj> that's the problem
[19:11:19] <alesj> Session is a non-static class in AbstractSessionManager
[19:11:23] <dmlloyd> the problem is that superclass writeObjects() will be written first
[19:11:28] <alesj> hence i need to have inner class as well
[19:11:31] <dmlloyd> so by the time you clear that field it's too late
[19:11:36] <alesj> ah :-(
[19:11:46] <alesj> any hack I can provide? :-)
[19:11:47] <dmlloyd> it's just like constructor ordering but backwards for writeObject
[19:11:58] <alesj> i see
[19:11:59] <dmlloyd> well don't serialize that class, for one
[19:12:04] <dmlloyd> you can do Externalizable
[19:12:17] <alesj> yeah, but I don't have zero arg ctor in super
[19:12:19] <dmlloyd> or use an Externalizer or instance table
[19:12:23] <dmlloyd> or use writeReplace()
[19:12:38] <dmlloyd> and write out a proxy (though that can be a little fragile in certain cases)
[19:12:58] <alesj> how do I register Externalizaer?
[19:13:17] <dmlloyd> that happens inside of infinispan
[19:13:23] <dmlloyd> galderz would probably know
[19:13:53] <alesj> can I mix-n-match writeReplace and readObject?
[19:15:01] <alesj> 	what about if I just do writeReplace, first null out _value, then return this?
[19:15:04] <alesj> dmlloyd: ^
[19:15:15] <bstansberry> kkhan: almost all the stuff in org.jboss.as.server.client needs to come out of the server module (probably into controller-client), so don't import stuff (e.g. ModelDescriptionConstants) into those classes
[19:15:48] <kkhan> So that was the reason for no constants being used :-)
[19:16:54] <bstansberry> :(
[19:17:03] <dmlloyd> alesj: yeah you can mix and match if you're careful
[19:17:17] <dmlloyd> alesj: writeReplace will loop if you return "this", iirc
[19:18:16] <alesj> dmlloyd: why will it loop?
[19:18:26] <dmlloyd> because the new object will then be serialized
[19:18:32] <dmlloyd> and that object has a writeReplace on it
[19:18:32] <dmlloyd> etc.
[19:18:38] <alesj> ugh, ugly
[19:18:43] <dmlloyd> I don't remember if it knows to break that loop or not
[19:18:53] <dmlloyd> it follows the spec behavior on that
[19:18:57] <dmlloyd> which I don't remember
[19:19:16] <dmlloyd> you could probably try it though :)
[19:19:38] <dmlloyd> writeReplace should be declared protected
[19:19:40] <dmlloyd> usually
[19:21:19] <alesj> ok, i'll try it and let you know :-)
[19:24:45] <bstansberry> kkhan: checkDeploymentNameUnique in DeploymentAddHandler shouldn't be necessary
[19:25:06] <kkhan> bstansberry: ok, I guess it throws an exception when trying to add
[19:25:19] <kkhan> if it already exists in the repo
[19:25:21] <bstansberry> BasicModelController.validateNewAddress() will fail earlier if the address already exists
[19:25:43] <bstansberry> because DeploymentAddHandler is a ModelAddOperationHandler
[19:26:03] <bstansberry> see BasicModelController.getOperationSubModel
[19:26:20] *** darranl has joined #jboss-as7
[19:26:20] *** darranl has joined #jboss-as7
[19:26:20] *** ChanServ sets mode: +v darranl
[19:31:27] <alesj> dmlloyd: http://community.jboss.org/wiki/PluggingInfinispanWithUserDefinedExternalizers
[19:31:42] <alesj> found this, but it looks like either too stale data or too new
[19:32:11] <kkhan> bstansberry: I pushed your suggested changes
[19:32:20] <kkhan> redid the last commit
[19:33:00] <bstansberry> k; i'll look in a few
[19:33:19] <bstansberry> does the FS scanner work with these changes?
[19:33:44] <kkhan> Hmm, I've not tried
[19:34:37] <kkhan> Trying now
[19:35:18] <dmlloyd> alesj: if your inner class' enclosing classes are not serializable, you'll get an error there too
[19:35:39] <dmlloyd> assuming you ignore my warning and keep trying to serialize that :)
[19:36:14] <dmlloyd> usually in cases like this the right thing to do is writeReplace a serializable holder, and on that holder class readResolve and reconstruct or look up the original
[19:37:30] <kkhan> bstansberry: It works
[19:37:35] <bstansberry> :)
[19:38:09] <kkhan> i.e copying the demo sar into deployments and deleting + readding it
[19:38:31] <bstansberry> how about not deleting, just re-adding?
[19:38:38] <bstansberry> that's a full-replace
[19:39:00] <bstansberry> doesn't matter that the content is identical
[19:39:03] <kkhan> Yep :-)
[19:39:05] <kkhan> It works
[19:39:25] <kkhan> I take it the FS scanner uses the deployment builder?
[19:39:43] <bstansberry> no, direct operations
[19:40:07] <bstansberry> the demos use the builder
[19:40:16] <bstansberry> but probably don't do any full replace
[19:40:17] <kkhan> cool, so both hash and streams work
[19:40:30] <kkhan> although we've not tested full replace with streams
[19:40:50] <kkhan> I'll be offline tomorrow afternoon
[19:41:15] <kkhan> but can create a smoke test for full replace while flying
[19:41:37] <bstansberry> nice :)
[19:42:04] <bstansberry> ok, done eating; will look at this now
[19:43:34] <kkhan> I've got to go out for dinner, but will check back later
[19:44:43] <dmlloyd> where are the bootstrap operations running now?
[19:45:10] <kkhan> One thing we need to think a bit about is who closes the streams, I think I saw something in the remoting doc that they have to be closed on the server. dmlloyd?
[19:45:27] <dmlloyd> what streams?
[19:45:32] <dmlloyd> whoever opens em, closes em
[19:46:21] <kkhan> I just thought I saw in remoting that if you pass a stream from the client to the server you have to close it on the server, but I might be remembering wrong
[19:47:00] <bstansberry> dmlloyd: bootstrap ops are in ServerControllerService.start
[19:47:07] <dmlloyd> in remoting when you open a request you get a stream which you write in on the client, which you close when the stream is complete
[19:47:29] <dmlloyd> on the server side you should close when you've read everything you're interested or until you hit -1 or an error
[19:48:25] <dmlloyd> if you're doing RPC and you have a stream included in your message, it will be closed, but that code doesn't really exist yet
[19:49:20] <dmlloyd> bstansberry: can you think of any reason that a "remove" op would be called during boot, other than the "add" op failing?
[19:49:28] <alesj> dmlloyd: ah, enclosing classes are not serializable
[19:49:41] <alesj> dmlloyd: so my best bet is to do that Externalizer
[19:49:44] <dmlloyd> bstansberry: I added a log message in the failure handler for boot operations but nothing is logged
[19:49:45] <bstansberry> dmlloyd: no
[19:50:15] <dmlloyd> actually I suspect that we just have a broken failure path, given the number of "// do something" comments I see
[19:51:02] <bstansberry> we should disable rollback on the boot ops
[19:51:09] <dmlloyd> ah there it is, it's being logged...
[19:51:16] <dmlloyd> 12:48:10,246 ERROR [org.jboss.as.server] Boot update failed: "org.jboss.msc.service.DuplicateServiceException: Service jboss.naming.context.java is already registered"
[19:51:19] <dmlloyd> now that's weird
[19:51:24] <dmlloyd> and also I see OSGi starting up *twice*
[19:51:31] <dmlloyd> something really funky is going on here
[19:52:18] <dmlloyd> actually never mind
[19:52:25] <dmlloyd> OSGi thing is just a dup log message
[20:06:00] <dmlloyd> hot damn, everything starts
[20:07:22] <jpederse> only one comment - kick ass
[20:08:30] *** torben has joined #jboss-as7
[20:08:31] *** ChanServ sets mode: +v torben
[20:09:32] <dmlloyd> if I can just get managedbean deployments to work again we might have something here
[20:10:17] *** AndyTaylor has joined #jboss-as7
[20:10:17] *** ChanServ sets mode: +v AndyTaylor
[20:10:38] *** AndyTaylor has quit IRC
[20:12:09] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/29d869d
[20:12:13] <dmlloyd> yes folks some tests actually pas
[20:12:26] *** torben has quit IRC
[20:12:37] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/29d869d
[20:12:38] <jbossbot> git [jboss-as] 29d869d.. David M. Lloyd Fix some tests
[20:12:47] *** torben has joined #jboss-as7
[20:12:47] *** ChanServ sets mode: +v torben
[20:14:43] <jbossbot> git [jboss-as] push master 418ebcd.. kabir Deploy using streams
[20:14:44] <jbossbot> git [jboss-as] push master 975bc2e.. kabir Remove the throwaway clients
[20:14:44] <jbossbot> git [jboss-as] push master 09d688b.. kabir Rework the deploy add and fullreplace handlers to take a stream
[20:14:44] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/bd97504...09d688b
[20:14:56] <bstansberry> kkhan: ^^^
[20:16:39] *** torben has quit IRC
[20:17:55] <dmlloyd> all the names inthe managed bean examples are unqualified
[20:18:06] *** torben has joined #jboss-as7
[20:18:06] *** ChanServ sets mode: +v torben
[20:19:38] <dmlloyd> also they use mappedName
[20:19:39] <dmlloyd> ...
[20:21:58] *** smcgowan has joined #jboss-as7
[20:21:59] *** ChanServ sets mode: +v smcgowan
[20:23:04] *** torben has quit IRC
[20:27:57] *** asoldano is now known as asoldano_dinner
[20:28:22] *** AndyTaylor has joined #jboss-as7
[20:28:22] *** ChanServ sets mode: +v AndyTaylor
[20:28:29] *** AndyTaylor has quit IRC
[20:31:11] *** pil-afk has quit IRC
[20:36:51] <jpederse> Nihility: fyi, we are pretty much done with the Beta4 release, so that'll go into Nexus tomorrow, then we will have a Beta4 to pull some time next week
[20:37:05] <jpederse> * Beta4 branch
[20:45:46] *** alesj has quit IRC
[20:50:21] <stuartdouglas> morning all
[20:51:20] *** asoldano_dinner is now known as asoldano
[20:58:54] *** mbg has joined #jboss-as7
[20:58:54] *** ChanServ sets mode: +v mbg
[21:02:41] *** mbg has quit IRC
[21:02:48] <dmlloyd> morning stuartdouglas.
[21:02:53] <dmlloyd> made a bit of progress
[21:03:35] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/e47a194 is latest
[21:03:36] <jbossbot> git [jboss-as] e47a194.. David M. Lloyd Add some error checking and use the right API
[21:03:39] <stuartdouglas> cool, looks like a lot of the smoke tests pass
[21:03:51] <dmlloyd> yeah it's getting there
[21:03:57] <dmlloyd> managedbeans is a bit off
[21:04:14] <dmlloyd> there's some assumptions john made about JNDI names that I'm still looking for in the spec
[21:04:24] <stuartdouglas> yea, all I did with them was get them to compile
[21:04:29] <dmlloyd> hate wasting time paging through specs
[21:04:42] <dmlloyd> also the demos were using mappedName rather than lookup
[21:04:51] <dmlloyd> so I guess they were never quite correct
[21:05:50] <dmlloyd> the server boots though which is nice
[21:06:46] <stuartdouglas> that is always a plus :-)
[21:08:17] <stuartdouglas> If you merge my ee branch I have the war demo working
[21:08:26] <dmlloyd> great
[21:09:16] <dmlloyd> needs a rebase stansilvert
[21:09:18] <dmlloyd> stuartdouglas
[21:09:22] <dmlloyd> not stansilvert sorry :)
[21:09:50] <dmlloyd> between "as", "ni", "sm" and now "st" I can't do two keys and tab-complete anymore :-/
[21:13:51] <stuartdouglas> pushed
[21:15:09] <dmlloyd> ok let me see what smoke tests are left
[21:17:59] *** mbg has joined #jboss-as7
[21:17:59] *** ChanServ sets mode: +v mbg
[21:18:50] <stuartdouglas> just managed beans
[21:19:18] <dmlloyd> doesn't compile because of the stupid annotation thing
[21:19:25] <stuartdouglas> yea
[21:19:30] <dmlloyd> looking into endorsed in the maven thing
[21:19:44] <stuartdouglas> but other that, they work :-)
[21:20:16] <jbossbot> git [jboss-as] push master 26d15df.. bstansberry at jboss dot com Don't prematurely close the input stream
[21:20:16] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/09d688b...26d15df
[21:24:28] <dmlloyd> jaikiran has a good writeup :  http://jaitechwriteups.blogspot.com/2011/02/resource-and-new-lookup-attribute-how.html
[21:24:31] <dmlloyd> gonna try it
[21:31:09] <stuartdouglas> so what else are the main things that need to be done?
[21:31:39] <dmlloyd> once smoke tests are all fixed I'm going to merge
[21:31:51] <dmlloyd> then we still need to get interceptor injection straight at some point
[21:32:03] <dmlloyd> servlets and their ilk need to be made into components
[21:32:08] <dmlloyd> components need to support CDI
[21:32:13] <stuartdouglas> I added the InjectingInstanceFactory
[21:32:21] <dmlloyd> oh ok, so that's working now?
[21:32:27] <stuartdouglas> maybe
[21:32:29] <dmlloyd> heh
[21:32:46] <dmlloyd> and we need to get deployment processing cleaned up
[21:33:05] <stuartdouglas> It's kind yuck though because the factory is set up before the resource injections are availible
[21:33:06] <dmlloyd> so that we can recognize web and EJB deployments without descriptors as per spec
[21:33:28] <dmlloyd> and we need to get module and app name usage consistent everywhere
[21:33:33] *** mmoyses has quit IRC
[21:33:38] <dmlloyd> and there's some JNDI EE stuff I'm not too sure about
[21:33:46] <stuartdouglas> the ejb and war stuff should already work
[21:33:58] <dmlloyd> like, if I do lookup="foo" from a managed bean does that become java:comp/env/foo or what?
[21:34:10] <stuartdouglas> no, there is no comp
[21:34:13] <Nihility> stuartdouglas: hey would you mind working through your orientation hehe
[21:34:22] <dmlloyd> there is no comp for MBs, sure, but injection apparently happens using the caller's context
[21:34:27] <dmlloyd> or so I hear
[21:34:28] <stuartdouglas> it should be bound to module somewhere
[21:34:42] <stuartdouglas> but the caller could be any component
[21:34:50] <stuartdouglas> so we can't bind it to every comp
[21:34:58] <dmlloyd> binding goes to module or app, but lookup comes from the caller's context
[21:35:18] <stuartdouglas> Nihility: I wouldn't mind, not sure how everyone else would take it though :-)
[21:35:18] <dmlloyd> also the MB itself is supposed to be bound into app and module, I don't think it is currently
[21:35:54] <dmlloyd> anyway I think that just by starting on e.g. getting servlets component-ed all these little bugs will shake out
[21:36:00] <stuartdouglas> actually that is really retarded, if we bind the injections to module, what happens when the caller is from a different module?
[21:36:16] <dmlloyd> they have to use the app binding
[21:36:31] <dmlloyd> to get at the MB itself
[21:36:34] <stuartdouglas> what do we actually do at orientation anyway? Do I get a red hat?
[21:36:35] <dmlloyd> as to its resources, dunno
[21:37:19] <dmlloyd> we also need way, way better error checking in the deployers for managed beans and stuff
[21:37:48] <Nihility> IIRC lookup points to a fully qualified path only
[21:37:52] <Nihility> so "foo" is invalid
[21:37:59] <Nihility> unless you have something in /foo
[21:38:41] <dmlloyd> okay then the demo is invalid
[21:38:56] <dmlloyd> it probably needs to be java:module/ExampleBean or whatever
[21:39:23] <Nihility> correct
[21:39:47] <dmlloyd> does anyone know if there's a ${foo.bar} string I can put in a maven build which expands to the dependency location on the FS?
[21:39:50] <dmlloyd> pgier ?
[21:40:04] <dmlloyd> ${org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec} doesn't do it
[21:40:17] <stuartdouglas> I think you need to use the maven dependency plugin to copy it first
[21:40:29] <stuartdouglas> that syntax only works in the ant plugin
[21:40:30] <dmlloyd> yeah just trying to avoid that :(
[21:40:39] <pgier> dmlloyd: There isn't a property like that built in
[21:40:47] * stuartdouglas has faced that same problem many a time
[21:40:54] *** darranl has quit IRC
[21:40:55] <dmlloyd> suckage
[21:40:56] <pgier> as stuartdouglas said, you'd have to use a plugin to do it
[21:41:16] <dmlloyd> in that case I'm off to add 75 lines to the pom.xml just to add one method on one class
[21:41:40] <Nihility> there is another solution
[21:41:47] <Nihility> you could stick Resource.class in build
[21:41:58] <Nihility> we wont ever need to update it
[21:41:58] <Nihility> haha
[21:43:05] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/43f72bd
[21:43:06] <jbossbot> git [jboss-as] 43f72bd.. David M. Lloyd Make demos compile dammit
[21:43:26] <Nihility> looks good
[21:43:48] <dmlloyd> you know maven could really use an "endorsed artifacts" thing in compiler plugin
[21:43:53] <dmlloyd> hint hint to pgier ;)
[21:44:48] <Nihility> an <endorsed> flag on deps would rock
[21:45:13] <stuartdouglas> I would be happy just with some way to get the path of a dep
[21:46:05] <Nihility> im surprised pgier hasnt forked maven yet
[21:46:13] <smarlow> ALR: I'm trying to create a ARQ test (http://pastebin.com/4daE1Pim) but I'm getting a NCDFE when trying to reference the MockStatefulSessionBeanContainer that lives in the AS7 JPA module currently for testing.
[21:47:13] <stuartdouglas> are you adding the jpa module as a dep to the deployment?
[21:47:21] <dmlloyd> http://fpaste.org/jYyp/ <- so tell me, what should this do
[21:47:26] <ALR> smarlow: Lookin
[21:47:37] <dmlloyd> it's failing to bind the injected resource to "simple"
[21:47:49] <dmlloyd> if this were something sane like an EJB I'd expect it to go into comp/env
[21:48:03] <dmlloyd> do we just bypass binding here?
[21:48:07] <smarlow> stuartdouglas, ALR:  no, I didn't add jpa as a dep to the deployment.  That sounds important but wasn't sure where.  In the test I bet?
[21:48:09] *** alesj has joined #jboss-as7
[21:48:11] <dmlloyd> why is a @Resource on the field as well as the class?
[21:48:14] <dmlloyd> does that even make sense?
[21:48:49] <Nihility> it does in a very messed up way
[21:49:00] *** stuartdouglas_ has joined #jboss-as7
[21:49:01] <Nihility> the first one (class one) creates a JNDI binding
[21:49:07] <ALR> smarlow: Is that a "." in line 47?
[21:49:12] <Nihility> that could be used by other code
[21:49:19] <dmlloyd> Nihility: yeah but there's the sticker - there's no comp namespace
[21:49:21] <Nihility> the field one uses teh default name
[21:49:22] <dmlloyd> so where is the binding?
[21:49:31] <dmlloyd> what is the default name?
[21:49:31] <ALR> smarlow: Nevermind, that won't matter
[21:49:38] <Nihility> dmlloyd: right it goes in module
[21:49:56] <ALR> smarlow: The dependency needs to be added to the classpath running the test
[21:50:01] <ALR> Usually via Maven
[21:50:03] <dmlloyd> where does it say that, Nihility?  I can't find that anywhere
[21:50:10] <ALR> smarlow: What backing container is being used
[21:50:11] <ALR> ?
[21:50:19] <dmlloyd> managed beans says you "should" put it into module, but it doesn't say it will do so
[21:50:25] <dmlloyd> or what name under module it will have
[21:50:54] <Nihility> somewhere there is a defintion on what the default non specified name is
[21:51:00] <Nihility> but name="simple:
[21:51:02] <Nihility> oops
[21:51:05] <Nihility> name="simple"
[21:51:08] <smarlow> ALR:  I'm trying to hack together a standalone SFSB like container hack some direct references to it in the test
[21:51:10] <Nihility> is for sure java:module
[21:51:12] <dmlloyd> EE.5.4 says java:comp/env
[21:51:21] <dmlloyd> so what is that, java:module/simple ?
[21:51:31] <dmlloyd> or does it qualify it because it's a field
[21:51:36] <stuartdouglas> the manged bean spec does not specify where you have to put it
[21:51:38] <dmlloyd> because I've seen that in EJB
[21:51:41] <Nihility> im referring to the class one
[21:51:43] <Nihility> not the field one
[21:51:43] <stuartdouglas> which is really stupid imho
[21:52:13] <ALR> smarlow: So...what is the backing container?
[21:52:24] <ALR> smarlow: ie. What are you deploying @Deployment into?
[21:52:33] <dmlloyd> okay here's my problem
[21:52:46] <dmlloyd> this demo doesn't work, and I have no fucking clue what the expected behavior is
[21:53:04] <dmlloyd> and nothing I see in the spec sheds any light
[21:53:13] <smarlow> ALR:  Well, I want to generate the deployment and have AS7 process it and then run some custom code against it.
[21:53:38] <ALR> So the backing container is AS7.
[21:53:42] <smarlow> ALR:  yes
[21:53:54] <smarlow> ALR:  if that makes sense and could work
[21:53:56] <stuartdouglas> I don't think it is actually defined
[21:54:05] <stuartdouglas> servlets etc are the same
[21:54:24] <ALR> smarlow: So you're referencing AS internals in this test by way of MockStatefulSessionBeanContainer
[21:54:26] <Nihility> servlets comp is an alias to odule
[21:54:31] <dmlloyd> so could we, hypothetically, completely bypass the intermediate binding?
[21:54:42] <ALR> smarlow: Which links the test class, on the appCL, to MockStatefulSessionBeanContainer
[21:54:43] <stuartdouglas> we can pretty much put the JNDI binding whereever we like, safe in the knowledge that it is non-portable and no one uses it anyway
[21:54:43] <dmlloyd> so that the field is injected right from the lookup
[21:54:43] <Nihility> comp is basically dead
[21:54:45] <ALR> Which is in a child CL.
[21:54:49] <ALR> No?
[21:54:55] <Nihility> the thinking was that we should have had module
[21:54:57] <Nihility> and not comp
[21:55:05] <dmlloyd> well that's fine
[21:55:06] <Nihility> so its only around for backwards compatibility
[21:55:15] <dmlloyd> but I still want to know where this intermediate binding should go
[21:55:21] <dmlloyd> because it's specified for some specs
[21:55:22] <dmlloyd> not others
[21:55:28] <Nihility> the field one
[21:55:31] <Nihility> or the class one
[21:55:34] <smarlow> ALR:  yes, my use of AS internals will be very light.  if this test is possible to run
[21:56:05] <dmlloyd> well in this demo, Nihility, it's pretty clear that the intent was to look up the resource, stuff it in an intermediate binding called "simple" which will automatically be looked up from via the @Resource on the field
[21:56:16] <ALR> smarlow: So your ClassLoading setup looks inconsistent then...
[21:56:16] <dmlloyd> assuming that that is a reasonable expectation
[21:56:25] <dmlloyd> the question is, where do we bind simple
[21:56:31] <dmlloyd> if it is NOT a reasonable expectation
[21:56:32] <stuartdouglas> smarlow: Is your jpa stuff on github?
[21:56:42] <ALR> smarlow: If you wanna use MockStatefulSessionBeanContainer on the appCL, everything else has to be there too.
[21:56:57] <Nihility> dmlloyd: i think the sample was working around a bug
[21:57:08] <dmlloyd> then if I instead do @Resource(lookup="java:module/Whatever") right on the field, can I bypass the "implied" binding that specs like EJB would stick in comp/env
[21:57:13] <ALR> smarlow: Where is this?  A module in AS7?
[21:57:25] <dmlloyd> or do I have to put an intermediate binding "somewhere" to satisfy the spec
[21:57:39] <Nihility> the default points to the same location IIRC
[21:57:44] <Nihility> i need to double check the specs
[21:57:45] <smarlow> stuartdouglas: yes, https://github.com/scottmarlow/jboss-as contains it (working on the ejb3 integration without the ejb3 container)
[21:57:52] <dmlloyd> either way, it means that @Resource has to be doen differently depending on the spec, which pisses me off
[21:58:29] <Nihility> in otherwords im saying that what you linked is an error
[21:58:47] <dmlloyd> ok well I'll try directly injecting the lookup into the field and see what happens
[21:58:58] <Nihility> there is some explicit verbage
[21:58:59] <smarlow> ALR:  yes, its all currently in the AS7 JPA module.  The MockStatefulSessionBeanContainer doesn't have a real home yet but is currently in the AS7 JPA module.
[21:59:01] <dmlloyd> though I think the current logic will generate an implied "name="simple""
[21:59:07] <dmlloyd> so it probably still won't work
[21:59:08] <Nihility> that you cant have conflicting name fields UNLESS
[21:59:12] <Nihility> sharable=true
[21:59:17] <Nihility> and it points to the same resource
[21:59:24] <stuartdouglas> smarlow: It looks like you need to add a depedency process to persistence, too add jpa deps
[21:59:29] <ALR> smarlow: Do you understand why you're getting NCDFE?
[21:59:42] <stuartdouglas> and also to make this work you would need to add a dep on the jpa as module itself
[21:59:55] <smarlow> ALR:  yes, I understand what your saying about why
[22:00:02] <dmlloyd> Nihility: no shareable has nothing to do with that, it's a JCA thing
[22:00:06] <dmlloyd> afaict
[22:00:10] <ALR> stuartdouglas: (And probably whatever else follows that reference)
[22:00:16] <dmlloyd> hey this is new - I restarted the container and my old deployment was still deployed
[22:00:27] <stuartdouglas> https://github.com/scottmarlow/jboss-as/blob/master/weld/src/main/java/org/jboss/as/weld/deployment/processors/WeldDependencyProcessor.java
[22:00:38] <stuartdouglas> smarlow: something like that
[22:00:44] <Nihility> dmlloyd: right im referring to connection factories
[22:00:50] <stuartdouglas> dmlloyd: hasn't it always done that?
[22:01:18] <stuartdouglas> actually not for the demos, as they undeploy themselves
[22:01:36] <stuartdouglas> but if you kill the jvm in the debugger before the demo undeploys that will happen
[22:01:51] <dmlloyd> also the demo didn't undeploy on failure
[22:01:51] <dmlloyd> neat, now I don't know how to undeploy :)
[22:02:03] <stuartdouglas> mvn clean install :-)
[22:02:16] <smarlow> stuartdouglas:  looking now. thanks!
[22:02:17] <dmlloyd> had to stop the container, edit standalone.xml, restart
[22:03:08] <dmlloyd> anyway I was right, it's generating a name="simple" so the binding still fails
[22:03:19] <dmlloyd> for now I'll generate a whatever temp binding name to get past it
[22:03:28] <dmlloyd> but at some point, well, we should really conform to the spec :)
[22:04:14] <dmlloyd> it works
[22:04:26] <dmlloyd> \o/
[22:04:30] <dmlloyd>  |
[22:04:59] <dmlloyd> well, it dies with an NPE after running the test :)
[22:05:04] <dmlloyd> which explains the lack of undeploy :)
[22:06:03] <dmlloyd> damn this demo is kidna fucked up
[22:06:08] <dmlloyd> the way it does lookup can't really work
[22:06:17] <dmlloyd> it's looking in module context but it's looking from a different deployment
[22:06:59] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/f7a3888
[22:07:00] <jbossbot> git [jboss-as] f7a3888.. David M. Lloyd Make the managed bean demo valid
[22:07:03] <stuartdouglas> thats really bad if that actually works
[22:07:08] <Nihility> "A Managed Bean does not have its own component-scoped “java:comp” namespace. For this reason, Managed Beans should define resources in the “java:module” namespace or
[22:07:09] <Nihility> Final Release
[22:07:09] <Nihility> above. JNDI lookup operations from a method defined on a Managed Bean will use the naming context of that method’s caller.'
[22:07:26] <stuartdouglas> I think we should use app rather than module
[22:07:34] <dmlloyd> sure, Nihility but that's really damned non-specific
[22:07:39] <stuartdouglas> and module makes no sense if the caller is from another module
[22:07:44] <dmlloyd> managed beans who? authors? implementors?
[22:07:51] <dmlloyd> where in java:module?
[22:07:58] <dmlloyd> where in java:app?
[22:08:07] <Nihility> module/resource-name
[22:08:20] <Nihility> when it says "or above"
[22:08:21] <dmlloyd> stuartdouglas: managed bean spec says that @ManagedBeans are to always be defined in *both* app *and* module
[22:08:27] <Nihility> it means the user can put it in app
[22:08:29] <stuartdouglas> The spec leaves it up to use
[22:08:36] <Nihility> no it doesnt
[22:08:46] <stuartdouglas> yea, as in the proxy that lets you look up the beans thenselves
[22:08:47] <dmlloyd> if they meant java:module/resourceName they would say so
[22:09:09] <dmlloyd> "java:module" or above means anything
[22:09:13] <dmlloyd> java:global even
[22:09:24] <Nihility> the behavior is the same as
[22:09:27] <dmlloyd> java:global/spec/authors/suck even
[22:09:29] <Nihility> all other components
[22:09:36] <Nihility> the only difference
[22:09:43] <Nihility> is you replace "module" with "comp"
[22:09:55] <dmlloyd> all other components default to java:comp/env/foo where comp is specific to the class, unless you're a servlet
[22:10:34] <stuartdouglas> here is another doozy, 'A Managed Bean may optionally have a name, a String.'  'For each named Managed Bean, Java EE containers must make available the following entries in JNDI, ...'
[22:10:47] <stuartdouglas> which means if you leave of the name it is still a valid managed bean
[22:10:55] <stuartdouglas> but it will not be bound to JNDI
[22:11:01] <stuartdouglas> so there is no way to actually use it
[22:11:15] <Nihility> yeah that makes sense to me
[22:11:24] <Nihility> the whole idea of managed beans in jndi
[22:11:27] <Nihility> is the odd ball to me
[22:11:47] <Nihility> they were just supposed to be "pojos"
[22:11:48] <dmlloyd> that's the only way they can ever be used though
[22:11:58] <dmlloyd> they don't exist unless you look them up or inject them
[22:12:06] <dmlloyd> you can't do either if they aren't in JNDI
[22:12:25] <Nihility> the whole reason this spec exists
[22:12:28] <Nihility> is certain vendors
[22:12:34] <Nihility> did not like CDI having "simple beans"
[22:12:38] <Nihility> as it "competed" with EJB
[22:12:54] <dmlloyd> well I don't really care about that
[22:13:07] <dmlloyd> maybe we can just go off of what the TCK tests
[22:13:12] <Nihility> the use case was supposed to be include a java object
[22:13:15] <Nihility> in a framework
[22:13:17] <Nihility> like JSF or CDI
[22:13:24] <Nihility> without it having to be an EJB
[22:14:24] <Nihility> then to get the ability accepted it got turned into a separate EE thing
[22:14:34] <Nihility> and someone said, oh it should work eith EE injection too....
[22:14:35] <Nihility> and boom
[22:14:36] *** irooskov has joined #jboss-as7
[22:14:39] <dmlloyd> okay but none of that really helps to solve the problem
[22:14:40] <Nihility> a crappy spec
[22:14:46] <Nihility> that no one will ever actually use
[22:15:30] <Nihility> so a "simple bean" in CDI
[22:15:36] <Nihility> is a managed bean WITHOUT jndi
[22:15:45] <dmlloyd> fine
[22:15:48] <dmlloyd> but that's a CDI bean
[22:15:54] <stuartdouglas> I like dmlloyd's idea of just looking at what the TCK tests
[22:16:00] <stuartdouglas> and doing that
[22:16:09] <Nihility> sure
[22:16:20] <Nihility> but i can tell you that name defines stuff in module
[22:16:21] <dmlloyd> smcgowan: where can we look to find out what the TCK does for testing @ManagedBeans?
[22:16:55] <Nihility> thats what the spec actually means
[22:17:25] <dmlloyd> JSR-250 tells another tale
[22:17:31] <dmlloyd> @Resource private DataSource myDB;
[22:17:37] <dmlloyd> In the example above the effective name is com.example.class/myDB and the effective type is javax.sql.DataSource.class.
[22:17:52] <dmlloyd> never mind that com.example.class isn't a valid class or package name
[22:18:06] <dmlloyd> this spec was written by some moron
[22:18:09] *** alesj has quit IRC
[22:18:30] <Nihility> yeah thats why i said that i didnt remember the defaults
[22:18:45] <Nihility> but a @Resource without a name does some kind of class generated composite with field name
[22:18:49] <Nihility> to avoid conflicts
[22:18:51] <smcgowan> dmlloyd:  one sec
[22:21:50] <Nihility> i believe its definining class / field
[22:21:56] <Nihility> looking for it
[22:22:09] <dmlloyd> it just needs to be relative to something
[22:22:31] <dmlloyd> is it legit to use java:module/env or does it have to be java:module?
[22:22:59] <Nihility> its just module
[22:24:22] <smcgowan> dmlloyd:  the TCK provides the assertions being tested and tags each test with the assertion.  what isn't provided is a mapping between the two
[22:24:32] <smcgowan> so i have to find the assertion then see if there is a test for it
[22:24:32] <dmlloyd> ok so EJBs will use java:comp/env but managed beans will use java:module, nice
[22:24:49] <dmlloyd> smcgowan: ah ok, well the assertions would almost be good enough
[22:24:58] <dmlloyd> anything relating to managed beans and their bindings
[22:24:59] <smcgowan> first, let me get the assertion lists on a web server so you can view
[22:25:04] <dmlloyd> okay excellent, thanks
[22:25:05] <Nihility> right basically all new specs use module
[22:25:20] <Nihility> and ejb uses comp/env for back compat
[22:25:28] <dmlloyd> it's too bad because comp isn't so bad, especially now that module exists
[22:25:29] <Nihility> and wars alias them
[22:25:43] <dmlloyd> lets you scope an JNDI resource to your component which isn't a bad idea
[22:25:52] <dmlloyd> yeah the war thing is messed up
[22:25:57] <Nihility> yeah in principal its not a bad idea
[22:26:07] <Nihility> its just that in practice no one needs names per class
[22:26:18] <Nihility> to point to the same global thing
[22:28:52] <stuartdouglas> wasn't the original idea to allow you to change it on a per component level with deployment descriptors
[22:29:13] <Nihility> yes exactly
[22:29:45] <Nihility> so the code would never have to be changed
[22:29:52] <Nihility> but you could relocate each component individually
[22:29:59] <Nihility> to some new thing in your instrastructure
[22:30:22] <Nihility> two ejbs refer to comp:env/CreditCardManager
[22:30:43] <Nihility> and you decide that one of them needs to understand Discover
[22:30:47] <Nihility> and the other doesnt
[22:31:06] <Nihility> but now thats all moved back into code anyway so...
[22:32:28] <dmlloyd> this test uses MSC deps to create a hard dep on the binding and then inject it from the naming store
[22:32:47] <dmlloyd> from another deployment unit
[22:32:54] <dmlloyd> so I have to make another binding in the global NS
[22:33:24] <stuartdouglas> could we change the test to deploy an ear?
[22:33:29] <Nihility> so @Resource(name="java:/global/my/global/binding")?
[22:33:29] <dmlloyd> hm, maybe
[22:33:40] <dmlloyd> can we put .sar in .ear?
[22:33:50] <Nihility> i asked john that
[22:33:54] <Nihility> he said not yet
[22:34:27] <stuartdouglas> I don't think it would be that hard to get working
[22:34:43] <stuartdouglas> would we just want all nestled sars to become ears?
[22:34:54] <dmlloyd> is that the sweet sound of a volunteer?
[22:34:54] <stuartdouglas> sorry, all nestled sars to become sub deployments
[22:34:56] <dmlloyd> hark!
[22:35:03] <smcgowan> dmlloyd:  doesn't look like much was updated for EE 6, but here's the index (inside VPN): http://dev39.qa.atl.jboss.com/~smcgowan/JavaEE6TCK-Assertions/assertions/javaee_6/spec/spec-assertions.html
[22:35:22] <stuartdouglas> in my head it is only about 3 lines...
[22:35:28] <dmlloyd> yeah managed beans is not even mentioned in that ;|
[22:35:37] <dmlloyd> stuartdouglas: ok go nuts :)
[22:35:50] <smcgowan> dmlloyd: here's the index: http://dev39.qa.atl.jboss.com/~smcgowan/JavaEE6TCK-Assertions/assertions/assertion-index.html
[22:37:39] <dmlloyd> hm, it's not in EJB or EE
[22:37:59] <dmlloyd> not in servlet
[22:38:12] <Nihility> http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html
[22:38:14] <stuartdouglas> dmlloyd: If you pull from my master sar sub deployments may work
[22:38:14] <dmlloyd> guess they don't test it
[22:38:19] <dmlloyd> ha
[22:38:20] <Nihility> hehe thats more informative then 250 :)
[22:38:22] <dmlloyd> nice stuartdouglas
[22:38:47] <stuartdouglas> It looks like everything was there, it just needed the ear scanner to look for resource roots ending in .sar
[22:38:47] <Nihility> eld-level : <fully-qualified name of declaring class>/<field-name>
[22:39:25] <dmlloyd> stuartdouglas: rebase needed
[22:39:46] <wolfc> it's deep down in the ejb30 TCK module
[22:39:59] <stuartdouglas> done
[22:40:27] <dmlloyd> wolfc: I thought managed beans were EE6
[22:40:51] <Nihility> yeah the module names arent always accurate
[22:40:51] <wolfc> Yeah, well everybody abuses the ejb30 tests for everything. That's why we always get the stick. :-)
[22:40:51] <Nihility> haha
[22:41:15] <Nihility> so on a managed bean
[22:41:19] <Nihility> @Resource without a name
[22:41:24] <Nihility> has a name default of
[22:41:31] <Nihility> fqcn/fieldName
[22:41:40] <wolfc> dig into ejb30/lite/packaging/war/mbean
[22:41:52] <Nihility> so david your example would define two jndi entires
[22:42:04] <Nihility> one would be java:modue/simple (the one on the class)
[22:42:10] <wolfc> the JNDI name for a MB is java:module/env/<fqcn>/<propertyName>
[22:42:40] <dmlloyd> so it IS env
[22:43:16] <Nihility> NO
[22:43:19] <Nihility> its java:module
[22:43:22] <Nihility> no env
[22:43:28] <Nihility> same with app
[22:43:29] <wolfc> Hehe
[22:43:31] <Nihility> and same with globa
[22:43:33] <wolfc> Now we really need to dig
[22:43:41] <smcgowan> dmlloyd:  CDI TCK looks like ithas some,  i'll make that assertion list available too
[22:43:59] *** aloubyansky has quit IRC
[22:44:34] <dmlloyd> smcgowan: well CDI completely changes the rules for MBs
[22:45:02] <Nihility> see EE 5.1.8
[22:45:23] <wolfc> I don't have a 5.1.8
[22:45:42] <Nihility> final release?
[22:45:42] <wolfc> 5.2.5 defines the names
[22:46:17] <wolfc> FR 11/6/09
[22:47:12] <Nihility> oh sorr typo
[22:47:14] <Nihility> 5.18
[22:48:07] <Nihility> also MB 2.1.
[22:48:09] <Nihility> 2
[22:48:25] <wolfc> That's looking up a MB
[22:48:32] <wolfc> Not injecting from a @Resource
[22:48:36] <dmlloyd> yeah taht's where MBs are bound
[22:48:41] <dmlloyd> that duplciates what's in the MB spec
[22:49:18] <Nihility> just point out clearly there is no module/env for this
[22:49:41] <wolfc> So @Resource(lookup="java:module/cart") SC cart; becomes java:module/env/org.example.MB/cart (Linkref->) java:module/cart
[22:50:25] <dmlloyd> yeah the intermediate binding is the one I'm concerned with
[22:50:29] <dmlloyd> not the binding of the MB itself
[22:50:30] <wolfc> Or in accordance with 5.2.5 it should really be: java:comp/env/org.example.MB/cart
[22:50:47] <dmlloyd> right except that comp doesn't exist, hence the dilemma
[22:50:54] <wolfc> java:comp always exists
[22:51:13] <smcgowan> dmlloyd: http://dev39.qa.atl.jboss.com/~smcgowan/CDI-TCK-Assertions/jsr299-tck-impl-coverage-mb.html
[22:51:28] <dmlloyd> wolfc, there is no java:comp namespace for managed beans
[22:51:37] <dmlloyd> not even a fakey one pointing at java:module
[22:51:41] <wolfc> Name a scenario where it doesn't
[22:52:02] <dmlloyd> MB.2.1.3
[22:52:05] <Nihility> "A Managed Bean does not have its own component-scoped “java:comp” namespace. For this reason, Managed Beans should define resources in the “java:module” namespace"
[22:52:14] <dmlloyd> that's the one
[22:53:01] <wolfc> Hmm, we got a real spec conflict here. "JNDI lookup operations from a method defined on a Managed Bean will use the naming context of that method’s caller."
[22:53:23] <dmlloyd> yeah that affects lookup="" and context.lookup()
[22:53:27] <dmlloyd> not name="" in @Resource
[22:53:33] <dmlloyd> nor implied @Resource names
[22:53:46] <dmlloyd> which is clearly binding and happens with the same rules in MB.2.1.2
[22:53:58] <dmlloyd> and 2.1.3
[22:54:07] <dmlloyd> at least that's the only sane way to read that
[22:55:06] <wolfc> EE.5.2.5. makes no exception for MBs. TCK only tests through war deployments. So I guess that's why it hasn't been caught yet.
[22:55:46] <dmlloyd> yeah I mean that pretty clearly states that things go in java:comp
[22:55:55] *** pferraro has quit IRC
[22:55:58] <dmlloyd> well you know
[22:56:11] <wolfc> MB 2.1.3 leaves out whether the user should make sure it's in java:module or the container
[22:56:39] <dmlloyd> we could just bind things in comp by default and render it inaccessible due to the lookup rules in MB.2.1.3
[22:56:50] <dmlloyd> satisfying all the requirements, yet confirming their ultimate uselessness
[22:57:15] <dmlloyd> they won't be able to prove that the MBs have a comp namespace
[22:57:22] <dmlloyd> thus, the spec is satisfied
[22:57:45] <dmlloyd> I mean the reason that there's no comp in MBs is surely tied to the fact that the caller's context is used to look them up
[22:57:50] <dmlloyd> think about the servlet case though
[22:57:52] <dmlloyd> comp == module
[22:58:08] <dmlloyd> then the bindings are suddenly in module as well and everyone is happy as can be
[22:58:20] <wolfc> Right, it's a freaking mess.
[22:58:22] <Nihility> yeah nothing wrong with having a comp thats inaccessible
[22:58:31] <Nihility> except for the wasted memory
[22:58:31] <Nihility> haha
[22:58:45] <dmlloyd> exactly
[22:58:52] <dmlloyd> and I'm happy because I only have one code path
[22:58:54] <wolfc> In case of war java:comp == java:module so the issue becomes moot.
[22:58:58] <dmlloyd> exactly, wolfc
[22:59:13] <Nihility> you could just alias comp on everything but ejbs
[22:59:20] <wolfc> I was expecting for a jar deployment that it would inject from the EJB java:comp
[22:59:26] <Nihility> then no wasted memory
[22:59:26] <Nihility> :)
[22:59:40] <wolfc> Which would allow for some wicked constructs :-)
[23:00:03] <dmlloyd> wolfc: well lookups come from the caller's context, so if you inject into a managed bean from comp, and the managed bean is injceted into an EJB then you'd be injecting from the EJB
[23:00:24] <dmlloyd> but you'd better have a name="java:module/something/in/here" else the binding will fail at runtime
[23:00:29] <Nihility> ok so basically as to env or no env
[23:00:45] <Nihility> the difference is supposed to be user defined stuff = env
[23:00:54] <Nihility> container provided names = no env
[23:02:01] <wolfc> dmlloyd, it wouldn't necessarily fail, if the EJB actually defined a matching java:comp/env resource
[23:02:53] <wolfc> I think you should just inject from the caller context and we'll be safe.
[23:03:52] <dmlloyd> well I was doing that anyway
[23:03:54] <Nihility> ok i was rereading ee 5.2
[23:03:58] <dmlloyd> it's the binding that is the problem
[23:04:05] <Nihility> and i think resource names are supposed to default to env
[23:04:07] <dmlloyd> btw another option is to completely bypass the binding
[23:04:42] <wolfc> that's in violation of 5.2.1 5
[23:04:52] *** miclorb has joined #jboss-as7
[23:04:59] *** smarlow has quit IRC
[23:05:11] <wolfc> and possibly 4, but that depends on how you define 'environment'
[23:06:20] *** emuckenhuber has quit IRC
[23:06:32] <wolfc> Ah the top paragraph defines it as a JNDI naming context.
[23:06:35] <dmlloyd> well again if there's no comp then they can't prove that it's not being bound
[23:07:35] <wolfc> MB.2.1.3 only states that the MB doesn't have its own java:comp. It doesn't really state what happens if you look into java:comp during injection.
[23:07:35] *** bstansberry has quit IRC
[23:07:48] *** bstansberry has joined #jboss-as7
[23:07:48] *** ChanServ sets mode: +v bstansberry
[23:08:06] <dmlloyd> since lookups happen with the caller context, that means that binding and lookup go to two different contexts simultaneously
[23:08:23] <dmlloyd> and MB creation is always in a caller's context
[23:08:28] <dmlloyd> there's no other way to create them
[23:09:04] <dmlloyd> that works out fine for us because we bypass the naming context for binding anyway
[23:09:35] *** jpederse has quit IRC
[23:12:26] *** epbernard has joined #jboss-as7
[23:12:26] *** epbernard is now known as emmanuel
[23:12:26] *** ChanServ sets mode: +v emmanuel
[23:16:55] *** emmanuel has quit IRC
[23:17:05] *** mbg is now known as mbg|away
[23:19:13] *** emuckenhuber has joined #jboss-as7
[23:19:13] *** emuckenhuber has joined #jboss-as7
[23:19:13] *** ChanServ sets mode: +v emuckenhuber
[23:22:29] *** mbg|away is now known as mbg
[23:23:35] <Nihility> dmlloyd: i just went back through my notes
[23:23:39] <Nihility> and emails
[23:24:13] <Nihility> and the outcome was that env was decided to be a similar convention to comp/env
[23:24:15] <wolfc> I'm trying to find out how @Resource(lookup="x") is supposed to work
[23:24:43] <Nihility> so basically the rule is that component names have a fixed location in module/blah
[23:24:47] <Nihility> BUT
[23:24:53] <Nihility> resource refs default to
[23:25:04] <Nihility> module/env for their binding location
[23:25:15] <Nihility> (or comp/env) depending on the component
[23:25:28] <Nihility> thats also consistent with rereading the spec
[23:25:35] *** balunasj_busy is now known as balunas
[23:25:58] <Nihility> to make matters more confusing
[23:26:06] <Nihility> you can for sure change the name
[23:26:09] <Nihility> to be whatever you want
[23:26:13] <Nihility> and that is not in env
[23:26:20] <Nihility> (for the component itslef)
[23:26:23] <Nihility> so like
[23:26:27] <wolfc> How would you do that?
[23:26:51] <Nihility> @ManagedBean(name="java:global/Pollute/the/global/namespace")
[23:27:22] <wolfc> Are you sure? That's really wicked.
[23:27:28] <Nihility> or with ejbs
[23:27:43] <Nihility> @Stateless(name="java:global/OOPS"
[23:27:59] <wolfc> No, that can't be.
[23:28:06] <dmlloyd> yes, it is
[23:28:08] <wolfc> name is the <bean-name>
[23:28:11] <wolfc> or <ejb-name>
[23:28:13] <dmlloyd> name is what you bind to
[23:28:17] <dmlloyd> lookup is where you get it
[23:28:22] <dmlloyd> from
[23:29:43] <Nihility> yeah it takes the last part of the name
[23:29:46] <Nihility> to mean bean-name
[23:29:51] <wolfc> You can't do a full JNDI name into those annotations.
[23:30:21] <wolfc> http://download.oracle.com/javaee/6/api/javax/annotation/ManagedBean.html#value%28%29
[23:31:40] <dmlloyd> oh I thought you guys wer talking about @Resource
[23:31:48] <dmlloyd> yeah @ManagedBean is a bean name not a JNDI name
[23:31:59] <dmlloyd> that's MB.2.1.2
[23:32:18] <dmlloyd> bean name apparently defaulting to the simple name of the class
[23:32:22] <dmlloyd> which is kinda stupid
[23:33:56] <wolfc> It was never meant to be smart :-) It was to have short names first and hope for uniqueness.
[23:35:17] <Nihility> yeah i have the old emails about this, just trying to find where it was dropped
[23:35:23] <Nihility> and where the spec prevents it
[23:35:26] <wolfc> I'm still interested in @Resource(lookup="x") because I can't find a test that does a lookup of that resource in java:module/env or java:comp/env space. In essence it wouldn't make much sense to have an additional LinkRef anyway.
[23:36:26] <wolfc> In other words, nobody tests for a MB looking up java:comp/env/...
[23:36:41] <wolfc> Except when it comes to injection.
[23:37:06] <wolfc> Which can easily be done by just lookup("x")
[23:38:22] *** asoldano has quit IRC
[23:38:37] *** balunas is now known as balunasj_away
[23:44:21] <wolfc> http://download.oracle.com/javaee/6/api/javax/annotation/Resource.html#name%28%29 is contradicting. It leaves out the fqcn bit.
[23:44:37] <wolfc> I'm going to bed. I'll never phantom the workings of MBs.
[23:46:02] <stuartdouglas> does anyone who uses idea know how to make it generate getters for final fields?
[23:46:16] <stuartdouglas> generate getters and setters does not seem to work
[23:47:21] *** wolfc has quit IRC
[23:51:55] <dmlloyd> just do generate getters, stuartdouglas
[23:52:11] <dmlloyd> alt-insert to get the generate menu
[23:52:52] <stuartdouglas> ah, oops, I have been trying to use generate getters and setters
[23:53:23] <stuartdouglas> I did not notice that there was a generate getters only option, in eclipse there is just the one
[23:53:59] <dmlloyd> and setters too, if you already have a getter

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