[00:03:55] <dmlloyd> baileyje: interceptor filters scheduled to go away?
[00:04:09] <baileyje> Maybe.
[00:04:21] <baileyje> It is really just used as part of the configuration.
[00:04:27] <baileyje> That is parsed from the annotations.
[00:04:34] <baileyje> It is not used at runtime.
[00:04:38] <baileyje> Just to build the runtime chains
[00:04:39] <dmlloyd> ok
[00:04:56] <baileyje> jury is still out if there is a better way
[00:05:45] <dmlloyd> looks like there's a little bit of abstraction friction with Component and AbstractComponent
[00:05:50] <dmlloyd> instanceof checks in the service
[00:07:26] <baileyje> Yeah.  That is on my list as well
[00:11:19] <stuartdouglas> dmlloyd: Can you pull https://github.com/stuartwdouglas/jboss-as
[00:11:29] <stuartdouglas> just a 1 liner
[00:11:57] <jbossbot> git [jboss-as] push master 835c430.. Stuart Douglas Add vfs module dependency to managed beans subsystem
[00:11:58] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/f5ea548...835c430
[00:11:58] *** emuckenhuber has joined #jboss-as7
[00:11:59] *** ChanServ sets mode: +v emuckenhuber
[00:12:09] <dmlloyd> done
[00:12:16] <stuartdouglas> thx
[00:14:13] * stuartdouglas is getting a cold in the middle of summer
[00:16:05] <alesj> i guess MC module' tests are broken or what's the reason for exclusion?
[00:16:18] <alesj> e.g. mc/src/test/java —> is now _java
[00:21:26] <dmlloyd> don't recall but that was a while ago
[00:21:39] <dmlloyd> fixes welcome! :)
[00:22:12] <dmlloyd> I don't know the right command to find that rename in history
[00:22:22] <alesj> sure, np, just checking for the reason
[00:22:29] *** Nihility has quit IRC
[00:22:44] <alesj> it should be easy to fix, as it's not much there to begin with :-)
[00:23:11] <dmlloyd> it might have been something with arquillian
[00:23:18] <dmlloyd> maybe related to an osgi commit?
[00:24:31] <alesj> dunno, but np, i'll check
[00:25:19] *** alesj has quit IRC
[00:26:32] *** pferraro has quit IRC
[00:28:56] *** opalka has quit IRC
[00:37:25] <stuartdouglas> Is there a way to get a services dependencies in msc?
[00:37:53] <dmlloyd> not really, at the moment
[00:38:09] <dmlloyd> what would you use that info for?
[00:38:19] <dmlloyd> it's something that I may address
[00:38:30] <stuartdouglas> When you have failure due to missing dependencies
[00:38:31] <dmlloyd> but so far there haven't been any compelling use cases
[00:38:46] <stuartdouglas> it is kinda nice to know what the dependencies are :-)
[00:39:02] <dmlloyd> true, however missing dependencies can be transitive
[00:39:09] <dmlloyd> mostly we've been tracking them actively...
[00:39:13] <stuartdouglas> rather than hunting through a list of service names in jconsole
[00:39:44] <dmlloyd> in our next version we'll have some service status tracking changes
[00:40:07] <dmlloyd> so hopefully we'll be able to generate a list of dependencies which are missing, and services which are waiting
[00:40:15] <stuartdouglas> even just being able to get a list of missing deps for a service through JMX would be useful
[00:40:47] <dmlloyd> it's a little tricky because a single missing service can have multiple waiting dependents, and a service might have multiple missing dependencies
[00:40:57] <dmlloyd> so we don't want an explosion of duplicate info
[00:41:21] <stuartdouglas> Better than no info :-)
[00:42:57] <dmlloyd> sure, I agree with the need for it, but I think it'll be covered in the next release without actually having to expose service dependencies
[00:43:44] <dmlloyd> the main thing I'm worried about is busybody services doing expensive (and probably non-thread-safe) traversals of the service graph when there are better solutions for the problem
[00:51:43] <bstansberry> dmlloyd: suddenly all the xml output has quotes escaped
[00:51:45] <bstansberry>     <socket-binding-group name=\"standard-sockets\" default-interface=\"default\">
[00:51:54] <bstansberry> weird
[00:52:19] <dmlloyd> hmmm
[00:52:41] <bstansberry> looking at the staxmapper history, nothing jumps out
[00:52:56] <dmlloyd> could it be due to pulling in woodstox
[00:53:24] <dmlloyd> do you have a whole output?
[00:53:32] <dmlloyd> maybe some attribute is opening and not closing
[00:53:42] <dmlloyd> thus everything gets stuck in there
[00:53:59] <dmlloyd> so <some tag="foo <next-tag name=\"blah
[00:54:04] <dmlloyd> not sure if that makes sense wrt XML
[00:54:11] <dmlloyd> I'd think they'd use &quot
[00:54:13] <dmlloyd> ;
[00:54:15] <bstansberry> it's one the initial processing instruction
[00:54:21] <bstansberry> s/one/on
[00:55:31] <bstansberry> http://pastebin.com/nFEQi5zd
[00:55:49] <dmlloyd> oh
[00:55:55] <dmlloyd> false alarm :)
[00:56:03] <bstansberry> oh, doh
[00:56:06] <dmlloyd> it's because the content of string values in a DMR object are quoted
[00:56:06] <bstansberry> it's dmr
[00:56:09] <dmlloyd> yeah :)
[00:56:22] <dmlloyd> that's neat though!
[00:56:27] <bstansberry> it's probably been that way all along and I never noticed
[00:56:28] *** wmprice has quit IRC
[00:56:33] <bstansberry> oh, i know what it was
[00:56:54] <bstansberry> emanuel wrapped the output in the proper response structure
[00:57:10] <bstansberry> sorry for the noise
[00:57:11] <dmlloyd> ah, so you're getting an outer element instead of the one you thought you were getting
[00:57:14] <dmlloyd> makes sense
[00:57:52] <bstansberry> k; dinner time
[00:58:10] *** bstansberry is now known as bstans_afk
[01:00:04] *** fnasser has quit IRC
[01:01:47] *** miclorb_ has quit IRC
[01:08:44] *** miclorb has joined #jboss-as7
[01:25:42] *** jpearlin has joined #jboss-as7
[01:28:46] *** slaboure has quit IRC
[01:37:30] <stuartdouglas> dmlloyd: Do you have a minute to talk about ModuleClassPathProcessor?
[02:03:31] <dmlloyd> sure
[02:03:47] <dmlloyd> sorry, just finished dinner
[02:05:12] <stuartdouglas> At the moment ModuleClassPathProcessor is causing ear deployments to fail, as it it setting up dependencies on the services for the class path entries that are never created
[02:05:30] <stuartdouglas> This line: deps.add(ServiceName.JBOSS.append("deployment").append(deploymentName).append(phaseContext.getPhase().name()));
[02:05:53] <stuartdouglas> So I was just wondering what is the plan with regard to how we are going to treat class-path entries
[02:06:06] <dmlloyd> ok let me look at the code for a sec to refresh my memory
[02:06:23] <stuartdouglas> looking at the spec just then I realised that we are going to have to run the annotation indexer over them
[02:06:47] *** pferraro has joined #jboss-as7
[02:06:47] *** ChanServ sets mode: +v pferraro
[02:07:18] <dmlloyd> right now it's all designed for top-level deployments
[02:08:16] <dmlloyd> i.e. if I deploy a.jar and b.jar and b.jar has Class-Path: a.jar, what happens is that a.jar's resource roots get mounted, and then b.jar will "inject" that resource root
[02:08:34] <dmlloyd> so b.jar's modularize phase depends on both b.jar's and a.jar's resource roots
[02:08:43] <dmlloyd> inside of an ear is a different story
[02:09:06] <stuartdouglas> In an ear won't you end up with two copies of the same class through different class loaders?
[02:09:11] <dmlloyd> because, presumably, we don't want to actually use a class-path (as in, copy the class files) in the target deployment
[02:09:17] <dmlloyd> yeah you would
[02:09:26] <dmlloyd> so the question is, how do we *want* it to behave inside of an EAR
[02:09:38] <stuartdouglas> I think they should be seperate modules
[02:09:39] <dmlloyd> this is also a question for Jason, too bad he's not around
[02:09:40] *** Nihility has joined #jboss-as7
[02:09:40] *** Nihility has joined #jboss-as7
[02:09:40] *** ChanServ sets mode: +v Nihility
[02:09:43] <dmlloyd> oh
[02:09:45] <dmlloyd> speak of the devil
[02:09:57] <stuartdouglas> same goes for stuff in /lib
[02:10:04] <dmlloyd> stuartdouglas, yeah EAR EJB JARs are definitely separate modules
[02:10:10] <stuartdouglas> (which we also need to index)
[02:10:14] *** bgeorges has joined #jboss-as7
[02:10:41] <stuartdouglas> class-path entries are not nessesarily ejb jars though
[02:10:45] <stuartdouglas> they can just be normal jars
[02:10:45] <dmlloyd> right
[02:11:46] <baileyje> stuartdouglas: I think jar files in an ear as well as classpath entries are a single module
[02:11:58] <baileyje> To follow the EE classloading model.
[02:12:03] <dmlloyd> yeah the top-level classpath entries
[02:12:09] <baileyje> correct
[02:12:15] <dmlloyd> class-path entries on EJB jars is kind of different
[02:12:25] <baileyje> But if a war ahas a class-path entry it would be a module dep to the ear
[02:12:44] <baileyje> but a nested jar with class-path entires, is not as clear
[02:13:14] <baileyje> Since that jar does not have its own CL
[02:13:26] <stuartdouglas> so all the class-path entries get merged into a big ball of mud
[02:13:29] <stuartdouglas> ?
[02:14:04] <dmlloyd> if they're on the EAR yeah
[02:14:26] <stuartdouglas> is that allowed? At the very least it seems kinda crap
[02:14:30] <dmlloyd> yeah it's spec
[02:14:33] <dmlloyd> crap, yes
[02:14:51] <baileyje> The spec says all libs in an ear form a single classloader
[02:15:03] <baileyje> with the exception of WAR files which create a child CL
[02:15:08] <dmlloyd> it purports to give some flexibility there but it also then takes it all away in other places
[02:15:18] <dmlloyd> yeah also EJB jars are on their own too aren't they?
[02:15:35] <dmlloyd> or am I wrong about that
[02:15:37] <stuartdouglas> I thought it just defined visibility requirements, not the actual CL arrangement?
[02:15:43] <baileyje> dmlloyd: I do not believe so.  But a better question for Nihility
[02:15:53] <baileyje> stuartdouglas: That is true..
[02:16:17] <baileyje> We could make them all modules and then create an aggregate module with import/export rules to make the CL for the ear
[02:16:22] <dmlloyd> stuartdouglas: yeah but the way they word it makes it tricky to do it any other way
[02:16:37] <dmlloyd> for example we need a TCCL representing the deployment, so what is the deployment
[02:16:41] <baileyje> but I am not sure how much it buy us, and it would be a mess to get impled.
[02:16:56] <dmlloyd> yeah I mean maybe there's some way to do it
[02:17:45] <baileyje> I gotta run.  I will be on later.  Would love to continue the discussion then
[02:17:49] *** bgeorges has left #jboss-as7
[02:17:53] <dmlloyd> okay
[02:17:55] *** bgeorges has joined #jboss-as7
[02:21:24] <dmlloyd> EE.8.2.5 covers TCCL
[02:21:39] <jpearlin> Nihility:  Were you ever able to use in the dmr/json changes?  Is there anything else you need me to do on the dmr -> json side of things?
[02:23:21] *** bstans_afk has quit IRC
[02:24:39] *** asaldhan has left #jboss-as7
[02:26:29] <dmlloyd> yeah maybe the spec can allow for multiple modules
[02:26:33] <dmlloyd> I'll have to read some more
[02:26:44] *** bstansberry has joined #jboss-as7
[02:26:44] *** ChanServ sets mode: +v bstansberry
[02:27:56] <dmlloyd> the primary purpose for breaking these things into modules would be to isolate them from one another somehow though
[02:28:13] <dmlloyd> if they're all going to refer to each other with no restriction, all we've done is made deployment a bit slower for no good reason
[02:28:29] <stuartdouglas> After re-reading the spec I don't know if we can
[02:28:40] <dmlloyd> EE.8.3 or another part?
[02:28:50] <stuartdouglas> Web modules need access to: The contents of all jar files included in any resource adapter archives (rar files) included in the same ear file
[02:28:56] <dmlloyd> :D
[02:29:06] <dmlloyd> that's one of my favorites
[02:29:09] <stuartdouglas> does not even have to be in /lib
[02:29:19] <dmlloyd> for RARs, yeah
[02:29:24] <stuartdouglas> could be anywhere
[02:29:38] <stuartdouglas> but it just says all jars, not just rars
[02:29:39] <dmlloyd> yeah we have a recursive mount scanner just for RARs
[02:29:54] <stuartdouglas> oh, wait
[02:29:54] <dmlloyd> read it again, it specifically says "in any resource adapter archives"
[02:29:57] <stuartdouglas> I just read that wrong
[02:30:07] <dmlloyd> there's a lot of prepositions in that sentence
[02:32:40] <stuartdouglas> How much slower will having seperate modules make things?
[02:32:50] <dmlloyd> yeah looks like wars, ejb jars and app client jars in an EAR each get their own module
[02:33:00] *** frainone has quit IRC
[02:33:11] <dmlloyd> hard to say really, it's never been benchmarked in a deployment setting
[02:33:13] <stuartdouglas> It seems really odd to me that one jar referencing another in a Class-Path entry makes it availible to everyone
[02:33:33] <dmlloyd> yeah, that's ugly
[02:33:38] <dmlloyd> I'm not sure that it's true though
[02:33:51] <stuartdouglas> It would be if we used a big ball of mud
[02:34:01] <dmlloyd> in particular I think (non-EJB, non-WAR, non-appclient) JARs inside of the EAR do not have their class-path read
[02:34:39] <stuartdouglas> yea, but even if one ejb-jar making its call-path entries availble to everyone is not ideal
[02:35:00] <dmlloyd> yeah but that won't happen because (if I read this right) EJB JARs should be isolated modules
[02:35:31] <dmlloyd> man 90% of the fucked up rules in here relate to RARs
[02:36:09] <dmlloyd> so EJB JARs would be true subdeployments
[02:36:21] <dmlloyd> if they have a class-path dep on something, it would not be transitive
[02:36:31] <dmlloyd> it would be a copy of all the classes in that JAR
[02:36:44] <stuartdouglas> so each class path entry needs its own module then
[02:36:51] <stuartdouglas> oh, a copy?
[02:37:04] <dmlloyd> yeah, at least that's how I'm interpreting the spec currently
[02:37:08] <dmlloyd> note that I'm not married to the idea
[02:37:24] <dmlloyd> in particular I'm not super keen on multiple copies of the same class floating around
[02:37:27] <stuartdouglas> surely Module per class-path entry would be cheaper than duplicating class definitions
[02:37:46] <dmlloyd> it depends on whether, and how many, of the classes are actually used
[02:37:49] <stuartdouglas> where do get that it needs a copy from?
[02:38:23] <stuartdouglas> also opens up the possibility of nasty ClassCastExceptions
[02:38:27] <dmlloyd> yeah.
[02:38:46] <dmlloyd> from a few things: first, for TLDs we use class-path in its traditional sense: pull in copies
[02:38:53] <dmlloyd> we use Dependency to make them module deps
[02:39:04] <dmlloyd> (not set in stone of course)
[02:39:56] <dmlloyd> it's in line with the way "traditional" EE app servers work
[02:40:10] <dmlloyd> so in that regard we know it's "safe" from a TCK perspective
[02:40:26] <dmlloyd> I wish I had a stronger argument than that
[02:40:36] <dmlloyd> the only other thing I can think of is statics
[02:41:09] <dmlloyd> if I boot up two deployments with a common EJB client JAR dep then maybe something weird could go on if some statics rely on TCCL or something
[02:41:23] <dmlloyd> so it's clear to me that copying the classes needs to at least be available as an option
[02:41:34] <dmlloyd> whether we have the right approach though, I'm not sure
[02:42:01] <dmlloyd> I mean in an SE environment, Class-Path means "gimme a copy"
[02:42:14] <dmlloyd> extension-list adds another angle to the problem
[02:42:18] <stuartdouglas> In that case I think it is probably ok then
[02:42:20] <dmlloyd> now we have externally shared classes
[02:42:45] <stuartdouglas> but we still need to index the class-path jars
[02:43:08] <dmlloyd> yes
[02:43:12] <dmlloyd> each one is its own resource root
[02:43:19] <dmlloyd> each resource root gets its own index
[02:43:34] <dmlloyd> (and its own codeSource, if you care about such things)
[02:44:02] <stuartdouglas> Can I move the processor further back in the deployment chain?
[02:44:25] <dmlloyd> which processor?
[02:44:37] <dmlloyd> the class path one?
[02:44:40] <stuartdouglas> ModuleClassPathProcessor
[02:44:53] <dmlloyd> is the problem that indexing happens before it?
[02:45:05] <stuartdouglas> yes
[02:45:10] <stuartdouglas> also this is commented out:
[02:45:12] <stuartdouglas>                 // TODO: Need to add a resource root with a "future" virtual file root from an injected dependency
[02:45:12] <stuartdouglas>                 // resourceRoots.add(new ResourceRoot(classPath, null, null, false));
[02:45:34] <stuartdouglas> and it adds a dep on the non-existant service
[02:45:51] <dmlloyd> yeah, that's problematic
[02:46:07] <dmlloyd> we need to depend on the sibling deployment so that its resource root is there when we want it
[02:46:15] <dmlloyd> but we have no way of getting the resource root
[02:46:35] <stuartdouglas> or even if it is a deployment or just a random jar file
[02:47:20] <dmlloyd> well random jar files won't be, uh "dependable" I guess you say?
[02:47:25] <dmlloyd> from the top level at least
[02:47:31] <dmlloyd> inside of EARs everything changes though
[02:47:48] <dmlloyd> we really need to nail down the exact CL semantics we want
[02:48:13] <stuartdouglas> Module per jar probably gives the most flexibility
[02:48:23] <dmlloyd> to do what, though
[02:49:11] <stuartdouglas> well, you could then add some kind of non-standard descriptor, so the user can exactly control class loading scemantics
[02:49:24] <dmlloyd> yeah, we were going to do that for sure
[02:49:37] <dmlloyd> but I don't want it to be sloppy like AS6
[02:49:44] <dmlloyd> everything should have a clear meaning
[02:50:45] <dmlloyd> I'm reading thru EE.8.2 again to see what it says about plain JARs in the EAR
[02:52:04] <stuartdouglas> plain jars, as in jars that are only referenced by class-path entry?
[02:52:39] <dmlloyd> yeah
[02:53:49] <stuartdouglas> hmm: All referenced .jar files or directories must appear in the logical class path of the referencing JAR files at runtime.
[02:53:59] <stuartdouglas> What is a logical class path?
[02:54:11] <dmlloyd> an oxymoron?
[02:54:16] * dmlloyd badum-pssshh
[02:54:21] <stuartdouglas> :-)
[02:54:34] <dmlloyd> I think it just means the classes have to be visible
[02:54:43] <dmlloyd> so it doesn't necessarily rule out module-per-JAR
[02:58:52] <jpearlin> isn't the logical class path the class path once the class loader has resolved everything?
[02:59:05] <jpearlin> i.e. all the sub paths resolved together into one big class path?
[02:59:13] <dmlloyd> yeah but it doesn't have quite the same meaning when you're talking about a module system
[02:59:49] <jpearlin> so the spec is assuming it is just what is visible in the module, then
[02:59:58] <jpearlin> or visible to the module
[03:00:00] <dmlloyd> seems so
[03:00:06] <jpearlin> via whatever the module loader can load for it
[03:03:31] <dmlloyd> okay here's something clear
[03:03:37] <dmlloyd> EE>8.4.1
[03:03:47] <dmlloyd> section 3.f
[03:03:54] <dmlloyd> There must be only one version of each class in an application.
[03:04:14] <stuartdouglas> good
[03:04:24] <dmlloyd> otoh:                               With the exception of application clients, a
[03:04:24] <dmlloyd> Java EE application should not assume that each component is loaded in a
[03:04:24] <dmlloyd> separate class loader and has a separate namespace. All components in a
[03:04:24] <dmlloyd> single application may be loaded in a single class loader and share a single
[03:04:24] <dmlloyd> namespace.
[03:04:40] <dmlloyd> but we *can* do it that way, or so it appears
[03:05:41] <dmlloyd> that seems to contradict 8.3 though where it talks about EJB JARs
[03:06:20] * stuartdouglas thinks the class loading requirement were written after a few beers on a friday afternoon
[03:09:19] <stuartdouglas> The only real area where it seems to say you must not have access to other classes is with war deployments
[03:09:33] <dmlloyd> I guess it says "one version", not "one copy" or "one instance"
[03:09:47] <dmlloyd> everything in this section seems to imply that the container may provide copies
[03:09:50] <Nihility> ejb jars share the class loader
[03:09:53] <Nihility> of the ear
[03:09:57] <dmlloyd> especially the way they talk about class paths
[03:10:09] <Nihility> class-paths are just merged into whatever has them
[03:10:17] <Nihility> so big ball of mud
[03:10:33] <dmlloyd> is there a place in the spec that spells that out, Nihility?
[03:10:48] <dmlloyd> what I'm reading in EE makes it sound like we could do it either way
[03:11:52] <Nihility> it talks about what is visible
[03:11:57] <Nihility> from a particular component
[03:12:18] <dmlloyd> yeah EE.8.5 talks about namespaces and class loaders in a bit more detail
[03:13:06] *** jpearlin has quit IRC
[03:14:29] *** jpearlin has joined #jboss-as7
[03:20:35] <dmlloyd> argh.  I totally missed EE.8.5.3
[03:20:44] <dmlloyd> extension-type libraries have to be deployable as well
[03:23:20] *** pferraro has quit IRC
[03:23:55] <Nihility> well
[03:24:02] <Nihility> its more like referencable
[03:25:51] <jpearlin> Nihility:  sorry to bother you...were you able to use the json/dmr stuff?
[03:26:45] <Nihility> oh hi
[03:28:32] <jpearlin> I still haven't had a chance to see what the problem was with those crlf's
[03:28:40] <jpearlin> and why git wouldn't remove them
[03:28:57] <jpearlin> i'm sure its something I was doing wrong ;)
[03:31:33] <Nihility> i fixed that
[03:32:20] <Nihility> so i did try a few things
[03:32:24] <Nihility> and it seemed to work
[03:32:39] <Nihility> let me get the link to my branch
[03:32:48] <jpearlin> ok...should I just rebase from yours/
[03:32:50] <jpearlin> ?
[03:33:16] <Nihility> the only problem is that it includes david's cokecc patch
[03:33:21] <Nihility> which needs to be re-rebased
[03:33:47] <jpearlin> I assume this patch is newer than the one I have in my repo?
[03:33:47] <Nihility> https://github.com/n1hility/jboss-dmr/commit/585006379072ff35008f54758d108b70b9635660
[03:33:49] <jbossbot> git [jboss-dmr] 5850063.. Jonathan Pearlin Added DMR -> JSON support....
[03:34:04] <Nihility> have you done any changes after that point?
[03:34:27] <jpearlin> not since we last talked
[03:34:32] <jpearlin> I was out of town for a few days
[03:34:33] <Nihility> oh ok
[03:34:46] <Nihility> then i would just use that as your start point
[03:35:00] <jpearlin> re-fork from yours
[03:35:02] <jpearlin> and go from there
[03:35:53] <Nihility> yeah an easy way to do that
[03:35:58] <Nihility> is to fetch my repo
[03:36:03] <Nihility> so add a remote for me
[03:36:10] <Nihility> then do git fetch n1hility
[03:36:16] <Nihility> then in your json branch
[03:36:32] <Nihility> do git reset --hard n1hility/json
[03:36:41] <jpearlin> yeah...to wipe out any local changes
[03:36:45] <jpearlin> and revert to your branch
[03:36:46] <jpearlin> right?
[03:36:48] <Nihility> yeah
[03:36:57] <Nihility> although it still needs to be synced with davids
[03:37:05] <jpearlin> im slowly getting it ;)
[03:37:07] <dmlloyd> upstream you mean
[03:37:10] <dmlloyd> jbossas/jboss-dmr
[03:37:19] <Nihility> is upstream the most current?
[03:37:48] <dmlloyd> yes
[03:37:58] <dmlloyd> mine tends to be out of date these days
[03:38:55] <jpearlin> ok...i'll get my local copy back in sync tomorrow and go from there
[03:39:08] <jpearlin> I assume that I should start looking at the json -> dmr parsing logic at this point
[03:41:36] <Nihility> yes that would be awesome
[03:41:49] <jpearlin> ok...i'll give it a shot
[03:41:58] <jpearlin> hopefully I'll have something for you this weekend
[03:42:56] <jpearlin> thanks for your help
[03:49:31] *** miclorb has quit IRC
[03:51:36] *** miclorb has joined #jboss-as7
[03:56:02] *** jpearlin has left #jboss-as7
[04:07:07] *** bgeorges has quit IRC
[04:09:11] *** dmlloyd sets mode: -q wmprice!*@*
[04:20:58] <baileyje> dmlloyd: Do you see somewhere in the spec that describes EJB jars having their own CL?
[04:21:14] <baileyje> oh.  Now I see Nihility's responses.
[04:21:16] <dmlloyd> ee.8.3.2
[04:21:19] <dmlloyd> doesn't quite spell it out
[04:21:39] <dmlloyd> doesn't rule it out either
[04:22:03] <Nihility> i pictured that we would make every ejb a module
[04:22:20] <Nihility> ejb deployment that is
[04:22:38] <baileyje> Yeah.  I am pretty sure it has always been a single CL for all jars (including EJB) in an EAR.   But I imagine we can have EJB jars as modules and still allow the same visibility
[04:23:23] <dmlloyd> that would let EJBs import just what they need via class-path
[04:23:43] <baileyje> dmlloyd: You can't expect clients to do that though
[04:23:53] <dmlloyd> users you mean?
[04:24:02] <dmlloyd> yeah they may make assumptions
[04:24:05] <baileyje> every app that a customer writes is going to be expecting that behavior.
[04:24:14] <Nihility> the big problem is the lib directory
[04:24:18] <baileyje> Since all the app servers treat them that way.
[04:24:23] <Nihility> which has to be shared
[04:24:29] <dmlloyd> that's not really a problem
[04:24:31] <baileyje> and they run into articles like:  http://www.theserverside.com/news/1364680/Understanding-J2EE-Application-Server-ClassLoading-Architectures
[04:24:32] <dmlloyd> I mean that's the easy part
[04:25:19] <Nihility> well i just mean that we can require people to use class-path
[04:25:30] <Nihility> or explicit imports
[04:25:33] <Nihility> in an ear
[04:25:39] <Nihility> cant
[04:25:53] <baileyje> I would assume we can't require it.
[04:26:00] <Nihility> right
[04:26:21] <baileyje> We could still use modules and automatically setup the visibility, and allow custom extensions to add restrictions
[04:26:21] <dmlloyd> we can require it for anything in the second list under EE.8.3.2
[04:26:31] <dmlloyd> other EJB jars
[04:26:34] <dmlloyd> client JARs
[04:26:37] <dmlloyd> their depds
[04:26:45] <dmlloyd> non-EJB APIs
[04:26:46] <dmlloyd> etc.
[04:27:42] <stuartdouglas> If we have module per jar as I see it it should be possible to emulate the one big CL approach just by making the modules dependent on each other
[04:28:33] <stuartdouglas> but that would make it much easier to allow the user to add custom non-spec class loading config, e.g. to have two versions of the same library
[04:28:53] <stuartdouglas> but if we just use one big class loader, that sort of thing would be much harder
[04:30:07] <Nihility> ideally we would promote using modules vs ear/lib etc
[04:30:57] <Nihility> so making it esay to consume etc
[04:31:18] <Nihility> but yeah the worst of all of these is class-path
[04:31:30] <Nihility> its the opposite of class sharing
[04:31:30] <Nihility> :)
[04:31:52] <dmlloyd> well, that's our current definition of it, anyway
[04:32:07] <dmlloyd> I actually haven't found anything in the spec that says we must define it that way
[04:32:41] <Nihility> its mostly in the jar spec
[04:32:55] <stuartdouglas> Doesn't EE.8.4.1 3.f explicitly state that you can't duplicate them?
[04:33:14] <dmlloyd> nah it just says you can't have two different versions
[04:33:31] <dmlloyd> doesn't say you can't have two copies of the same version
[04:34:47] *** mbg has joined #jboss-as7
[04:34:47] *** ChanServ sets mode: +v mbg
[04:35:41] *** mbg has quit IRC
[04:37:12] <stuartdouglas> 'The value of this attribute specifies the relative URLs of the extensions or libraries that this application or extension needs. URLs are separated by one or more spaces. The application or extension class loader uses the value of this attribute to construct its internal search path.'
[04:37:31] <stuartdouglas> Which sorta implies that the CL that loads the jar also has to load the class-path jar
[04:37:35] <dmlloyd> nice and general
[04:37:39] <stuartdouglas> but does not actually explicitly state it
[04:37:42] <dmlloyd> well, it doesn't quite say it
[04:37:42] <dmlloyd> yeah
[04:40:22] <stuartdouglas> What about using shared CP entries by default, but having the option of duplicating them via non-standard config?
[04:42:55] <Nihility> imo we should try to avoid making EVERY jar a module
[04:43:16] <Nihility> which would totally happen if we treated class-path as a module ref
[04:43:38] <dmlloyd> stuartdouglas, that's the approach we were taking so far, more or less
[04:43:38] <Nihility> we certainly could do it that way though
[04:44:16] <Nihility> imo we do "duplicate" classes
[04:44:35] <Nihility> since class-path is just another resource path on the jar containing the reference
[04:44:52] <Nihility> if we shared them you would have to convert that to a module dep
[04:45:05] *** ALR has quit IRC
[04:46:10] <dmlloyd> yeah
[04:47:03] <dmlloyd> I'm thinking in particular of EJB JARs though
[04:47:15] <dmlloyd> on the one hand the spec doesn't require that they be visible without a class path
[04:47:17] <dmlloyd> ref
[04:49:04] <Nihility> it does
[04:49:15] <dmlloyd> not!
[04:49:15] <Nihility> if the ejb refs a component it calls
[04:49:21] <dmlloyd> yeah
[04:49:30] <Nihility> not necessarily with class-path
[04:49:36] <dmlloyd> sure
[04:49:41] <dmlloyd> just with *some* reference of some sort
[04:49:59] <dmlloyd> the question is, is that desirable
[04:50:01] <Nihility> yeah the intention is the "ejb-ref" attribute
[04:50:22] <Nihility> which i totally think is the most intuitive way to do it
[04:50:25] <Nihility> but its not trivial
[04:53:01] *** bgeorges has joined #jboss-as7
[04:53:02] *** ChanServ sets mode: +v bgeorges
[04:55:59] *** pferraro has joined #jboss-as7
[04:56:00] *** ChanServ sets mode: +v pferraro
[04:58:28] *** smarlow has quit IRC
[05:03:38] *** ccrouch1 has joined #jboss-as7
[05:03:39] *** ChanServ sets mode: +v ccrouch1
[05:06:36] <baileyje> Man. Shoveling blew away all my desire to be awake.
[05:06:52] *** ccrouch has quit IRC
[05:14:10] <baileyje> You two in madison getting any snow?
[05:15:37] <dmlloyd> yeah plenty
[05:15:51] <dmlloyd> 3" tonight, 1-2" tomorrow, 5-8" tomorrow night
[05:16:04] <baileyje> I think we are getting lucky.  We have gotten about 3 today
[05:16:35] <baileyje> Don't think we are going to be getting anything major moving forward..
[05:17:13] <stuartdouglas> It is 102°F here
[05:17:23] <stuartdouglas> I think I just got burnt walking to the mail box
[05:20:27] <Nihility> i have two snow blowers
[05:20:30] <Nihility> so i am prepared
[05:20:31] <Nihility> :)
[05:20:35] <dmlloyd> one for each hand
[05:20:54] <baileyje> you must work out.
[05:20:58] <Nihility> a two stage which does the huge stuff
[05:21:46] <Nihility> and a single stage for the smaller stuff (faster to operate)
[05:21:55] <Nihility> also it cleans closer to the driveway
[05:22:34] <Nihility> we had a big snow early winter
[05:22:41] <Nihility> that i spent the whole day shoveling
[05:23:05] <Nihility> so i get the big one :)
[05:23:56] <Nihility> if this one fails me
[05:24:01] <Nihility> i guess i have to buy a bobcat
[05:24:02] <Nihility> lol
[05:24:36] <baileyje> No kidding.  Or a hummer with a plow on the fron
[05:24:37] <baileyje> t
[05:25:00] <Nihility> i had a neighboor at my old house offer to ram the wall of plowed in snow
[05:25:05] <Nihility> with his truck
[05:25:13] <Nihility> which had no plow on it
[05:25:54] <stuartdouglas> snow is soft right? Whats the worst that could happen :-)
[05:26:14] <Nihility> haha well see its snow plowed snow
[05:26:22] <Nihility> so heavily packed
[05:26:28] <Nihility> partial ice
[05:26:28] <baileyje> It is soft until the plow creates a packed wall of it
[05:26:35] <Nihility> not the brightest idea in the world
[05:26:42] <Nihility> i couldnt take him up on it
[05:26:44] <Nihility> :)
[05:26:48] <stuartdouglas> It's hard to be sarcastic on the internet :-)
[05:26:54] <Nihility> oh
[05:26:55] <Nihility> haha
[05:27:05] <Nihility> well you are in australia
[05:27:24] <stuartdouglas> I have seen snow before
[05:27:27] <Nihility> so i thought maybe you just were unfamiliar with this shitty weather we get
[05:27:28] <Nihility> :)
[05:27:29] <stuartdouglas> twice
[05:28:37] <Nihility> on the bright side the winter kills any posionous things lying about
[05:28:54] <Nihility> so we have that!
[05:31:25] <stuartdouglas> http://www.manbir-online.com/htm2/snake.22.htm
[05:31:40] <stuartdouglas> We only have 5 of the top 10 most deadly snakes
[06:00:30] *** ccrouch has joined #jboss-as7
[06:00:31] *** ChanServ sets mode: +v ccrouch
[06:03:41] *** ccrouch1 has quit IRC
[06:07:38] *** mbg has joined #jboss-as7
[06:07:38] *** mbg has joined #jboss-as7
[06:07:38] *** ChanServ sets mode: +v mbg
[06:40:48] *** mbg has quit IRC
[06:41:17] <Nihility> ok so back to extensions
[06:41:31] <Nihility> i don't think it is valid to deploy an ejb-jar as an extension
[06:42:42] <Nihility> 8.5.2.4 has nice limitations
[06:42:59] <Nihility> on the use of annotations on "shared" resources
[06:43:06] <Nihility> so i would interpret that to apply to extensions
[06:44:04] <stuartdouglas> What are you referring to by 8.5.2.4's limitations?
[06:44:21] <stuartdouglas> As I read it ejb's in class-path entries still have to be deployed
[06:44:45] <stuartdouglas> (as long as metadata-complete is false)
[06:45:08] <Nihility> ". Note that the presence of component-declaring annotations in shared artifacts, such as li- braries in the library directory and libraries referenced by more than one mod- ule through Class-Path references, can have unintended and undesirable consequences and is not recommended. "
[06:45:34] <stuartdouglas> but we still have to support it :-(
[06:46:07] <Nihility> not working sounds like an undesirable consequence to me
[06:46:08] <Nihility> :)
[06:46:25] <stuartdouglas> :-)
[06:47:06] <Nihility> i think we should do it within reason
[06:48:26] <Nihility> index annotations at the module level
[06:48:37] <Nihility> where you can have multiple direct class-path refs
[06:48:52] <Nihility> (thats just additional data in the module)
[06:49:11] <Nihility> if there is an import then it can just use the index of the import IF its intended
[06:49:42] <Nihility> so like someone deploying struts.jar as a module
[06:49:50] <stuartdouglas> yea, but if two modules reference the same class-path jar
[06:49:54] <stuartdouglas> will break everything
[06:49:55] <Nihility> and then they add a proprieatary module ref
[06:50:12] <Nihility> to their ejb
[06:50:21] <Nihility> that wont work, and shouldnt work (noramlly(
[06:50:38] <Nihility> we could however support some kind of annotation import feature with modules
[06:50:45] <Nihility> so that you can explicitly say to do it
[06:50:57] *** pferraro has quit IRC
[06:51:02] <Nihility> yes if two modules reference the same classpath jar
[06:51:23] <Nihility> then they are not able to communicate with those classes
[06:51:29] <Nihility> (without serialization)
[06:51:46] <Nihility> this is more of a problem if you have an ear
[06:52:04] <Nihility> and use class-path to point to the same shared lib from 2 different ejb jars
[06:52:17] <Nihility> and they use local dispatch
[06:52:38] *** bstansberry has quit IRC
[06:53:31] <Nihility> we could solve this problem
[06:53:42] <Nihility> by having a module represent the ear shared resources
[06:53:43] *** pferraro has joined #jboss-as7
[06:53:43] *** ChanServ sets mode: +v pferraro
[06:53:56] <Nihility> so ear/lib + anything refd by classpath
[06:54:01] <Nihility> (that is in the ear)
[06:54:08] <stuartdouglas> but then class-path entries leak between modules
[06:54:27] <Nihility> and then all ejb jars would be their own module
[06:54:28] <stuartdouglas> so if one module has a class-path ref, all modules have it
[06:54:32] <Nihility> that imports the shared ear stuff
[06:55:45] <stuartdouglas> with that model if you have a.jar and b.jar and a.jar has a class-path ref to c.jar then b.jar will also end up with access to c.jar
[06:56:14] <stuartdouglas> kinda negates the purpose of class-path, you might as well just dump everything in /lib
[06:58:01] *** miclorb has quit IRC
[06:59:05] <Nihility> sure thats an allowed side effect
[06:59:26] <Nihility> the only other option is to remap everything pointed to by class-path
[06:59:29] <Nihility> to a module
[06:59:52] <Nihility> which imo will be expensive
[07:00:18] <Nihility> but then again i think class-path is stupid so...
[07:00:19] <Nihility> :)
[07:00:53] <Nihility> i suspect though most common usage pattern
[07:00:55] <Nihility> is the /lib
[07:01:20] <stuartdouglas> class-path could be really useful for different versions of the same lib
[07:01:28] <stuartdouglas> but the spec explicitly disallows the use case
[07:03:37] <Nihility> yeah its not portable certainly
[07:03:42] <Nihility> we could support its use that way
[07:03:45] <stuartdouglas> dmlloyd: If you get a minute could you merge https://github.com/stuartwdouglas/jboss-invocation
[07:03:49] <Nihility> although using modules directly is a better approach
[07:04:45] <stuartdouglas> What makes you think that using module per jar will be expensive?
[07:05:19] <Nihility> everytime you create a module its yet another classloader
[07:05:33] *** stuartwdouglas has quit IRC
[07:05:38] <Nihility> and another entry in a large forest
[07:05:56] <Nihility> it would be REALLY bad if we did it for every individual jar in /lib
[07:06:14] <Nihility> ear/lib war/lib etc
[07:06:30] <stuartdouglas> so there is no point
[07:06:40] <stuartdouglas> hmm, some of my messages went missing
[07:06:49] <Nihility> however classpath may nnot be as bad as i was thinking
[07:06:56] <Nihility> since i think it is not used as much
[07:07:06] <Nihility> as putting stuff in /lib
[07:07:07] *** pferraro has left #jboss-as7
[07:07:14] <Nihility> we can then create one module for stuff in /lib
[07:07:25] <Nihility> and individual ones for each class-path jar
[07:07:42] <Nihility> and then modules for each deployable construct
[07:07:45] <Nihility> ejbs etc
[07:07:48] <stuartdouglas> only every second or third message I type seems to get through
[07:07:54] <stuartdouglas> IRC is being weird
[07:08:29] <Nihility> strange
[07:08:33] <stuartdouglas> I think that is probably the best way to do it
[07:09:04] <Nihility> the big problem is class-path refs that leave the ear
[07:09:18] <Nihility> thats a bitch to implement that way
[07:10:03] <Nihility> doing that as just a resource include sounds the best approach
[07:11:51] <Nihility> (technically the spec says it doesnt even have to work)
[07:12:02] <stuartdouglas> I was just trying to find that bit
[07:13:33] <Nihility> 8.2.1
[07:16:22] <Nihility> what gets confusing though
[07:16:39] <Nihility> is lib artifact using a classpath ref
[07:17:53] <stuartdouglas> With regard to class-path: The Java EE deployment tools must process all such referenced files and directories when processing a Java EE module.
[07:18:08] <stuartdouglas> Stuff in the lib dir is not really a Java EE Module
[07:18:48] <Nihility> "ts. These libraries may reference other libraries, either bun- dled with the application or installed separately, using any of the techniques described herein."
[07:18:59] <stuartdouglas> damn
[07:19:06] <Nihility> haha
[07:19:11] <Nihility> but yeah picture this problem
[07:19:19] <Nihility> ejb A has a classpath ref to C
[07:19:39] <Nihility> lib1.jar also has a class-path ref to C
[07:21:00] <stuartdouglas> is that actually a problem?
[07:21:15] <stuartdouglas> It would expose C to all other entries in /lib
[07:21:28] <Nihility> right but C is also a module
[07:21:38] <Nihility> because ejb a referred to it
[07:22:08] <Nihility> so the classes are distinct
[07:22:18] <Nihility> i guess you could somehow detect
[07:22:25] <Nihility> that scenario
[07:22:31] <Nihility> and ignore it on the ejb side
[07:22:36] <Nihility> which would solve the problem
[07:22:43] <stuartdouglas> the ejb spec does not actually say that you need two different copies of the class though
[07:23:00] <Nihility> yeah im just saying if we went with the approach
[07:23:06] <Nihility> of module per class-path jar
[07:23:12] <Nihility> and module for all of lib
[07:23:28] <stuartdouglas> ah, I see what you mean
[07:23:51] <Nihility> we would basically have to flag every indirect reference in the ear
[07:23:54] <Nihility> as being part of lib
[07:23:57] <Nihility> and not make them modules
[07:24:18] <Nihility> so its doable
[07:24:27] <Nihility> otherwise the approach of making everything modules works
[07:24:28] <Nihility> :)
[07:24:40] *** bgeorges has quit IRC
[07:25:09] <stuartdouglas> We could only process the entries that are referenced by ejb-jars as modules
[07:25:10] * Nihility has big fears of people with 100 jars in their wars
[07:25:37] <stuartdouglas> then when resolving class-path for /lib if it is already a module just add a dependency
[07:25:43] <stuartdouglas> otherwise add a resource root
[07:26:15] <Nihility> oh yeah you are right
[07:26:19] <Nihility> we can do the reverse
[07:26:53] <Nihility> that would be faster
[07:27:46] <Nihility> ok im off to bed
[07:27:57] <stuartdouglas> night
[07:28:10] <Nihility> we should probably chat about this again tommorow
[07:28:26] <Nihility> and wiki up the solution
[07:28:29] <stuartdouglas> ok
[07:29:30] <Nihility> i also need to think about weld and this model
[07:29:35] <Nihility> i ahvent thorught it through completely
[07:30:57] <stuartdouglas> I don't think it will present any real problems for weld
[07:32:28] <stuartdouglas> The 'check if its a module before adding it to the shared lib' approach should also make it easy to support explicit module definitions by the end user
[07:32:50] *** rmaucher has joined #jboss-as7
[07:49:25] *** opalka has joined #jboss-as7
[08:09:55] *** miclorb_ has joined #jboss-as7
[08:10:14] *** jfclere has joined #jboss-as7
[08:10:14] *** ChanServ sets mode: +v jfclere
[08:43:17] *** miclorb_ has quit IRC
[08:43:34] *** aloubyansky has quit IRC
[08:48:18] *** aslak has joined #jboss-as7
[08:48:18] *** aslak has joined #jboss-as7
[08:48:18] *** ChanServ sets mode: +v aslak
[08:49:08] *** miclorb has joined #jboss-as7
[08:51:32] *** Jaikiran has joined #jboss-as7
[08:51:33] *** ChanServ sets mode: +v Jaikiran
[09:22:58] *** miclorb__ has joined #jboss-as7
[09:25:46] *** miclorb has quit IRC
[09:29:48] *** ccrouch1 has joined #jboss-as7
[09:29:49] *** ChanServ sets mode: +v ccrouch1
[09:33:08] *** ccrouch has quit IRC
[09:34:24] *** maeste has joined #jboss-as7
[09:34:24] *** ChanServ sets mode: +v maeste
[09:42:16] *** alesj has joined #jboss-as7
[09:48:28] *** AndyTaylor has quit IRC
[09:53:10] *** maeste has quit IRC
[09:54:51] *** emuckenhuber has quit IRC
[09:56:43] *** emmanuel has joined #jboss-as7
[09:56:43] *** ChanServ sets mode: +v emmanuel
[10:06:39] *** maeste has joined #jboss-as7
[10:06:40] *** ChanServ sets mode: +v maeste
[10:10:02] *** aslak has quit IRC
[10:10:31] *** aslak has joined #jboss-as7
[10:10:31] *** ChanServ sets mode: +v aslak
[10:15:39] *** Jaikiran is now known as Jaikiran|lunch
[10:21:29] *** emuckenhuber has joined #jboss-as7
[10:21:30] *** emuckenhuber has joined #jboss-as7
[10:21:30] *** ChanServ sets mode: +v emuckenhuber
[10:24:51] *** aslak has quit IRC
[10:25:09] *** aslak has joined #jboss-as7
[10:25:09] *** ChanServ sets mode: +v aslak
[10:26:36] *** asoldano has joined #jboss-as7
[10:26:36] *** ChanServ sets mode: +v asoldano
[10:27:22] *** aslak has quit IRC
[10:27:38] *** aslak has joined #jboss-as7
[10:27:38] *** aslak has joined #jboss-as7
[10:27:38] *** ChanServ sets mode: +v aslak
[10:29:17] *** slaboure has joined #jboss-as7
[10:32:40] *** aslak has quit IRC
[10:33:08] *** aslak has joined #jboss-as7
[10:33:16] *** ChanServ sets mode: +v aslak
[10:36:15] *** aslak has quit IRC
[10:36:31] *** aslak has joined #jboss-as7
[10:36:31] *** aslak has joined #jboss-as7
[10:36:31] *** ChanServ sets mode: +v aslak
[10:37:19] *** kkhan has joined #jboss-as7
[10:37:20] *** ChanServ sets mode: +v kkhan
[10:40:09] *** wolfc has joined #jboss-as7
[10:40:09] *** ChanServ sets mode: +v wolfc
[10:45:04] *** aslak has quit IRC
[10:54:04] *** bgeorges has joined #jboss-as7
[11:01:24] *** aslak has joined #jboss-as7
[11:01:24] *** ChanServ sets mode: +v aslak
[11:04:15] *** aslak has quit IRC
[11:04:31] *** aslak has joined #jboss-as7
[11:04:31] *** ChanServ sets mode: +v aslak
[11:06:43] *** AndyTaylor has joined #jboss-as7
[11:06:44] *** ChanServ sets mode: +v AndyTaylor
[11:14:38] *** jcosta has joined #jboss-as7
[11:14:38] *** ChanServ sets mode: +v jcosta
[11:26:41] *** darranl has joined #jboss-as7
[11:26:42] *** darranl has joined #jboss-as7
[11:26:42] *** ChanServ sets mode: +v darranl
[11:28:06] *** miclorb__ has quit IRC
[11:28:41] *** torben has joined #jboss-as7
[11:35:46] *** Jaikiran|lunch is now known as Jaikiran
[11:45:08] *** opalka has quit IRC
[11:47:41] *** opalka has joined #jboss-as7
[11:48:22] *** miclorb has joined #jboss-as7
[11:50:05] *** miclorb has quit IRC
[11:50:31] *** miclorb has joined #jboss-as7
[11:54:49] <dmlloyd> good morning
[11:55:21] <wolfc> we could really use a zoom function on github graph
[11:56:09] <wolfc> and I fear that the family tree dictates a lot of the layout
[11:56:10] <alesj> dmlloyd: you up really early? or you moved to EU? :-)
[11:56:11] <dmlloyd> yeah it gets somewhat less useful as we get more committers and as branches diverge more
[11:56:30] <dmlloyd> alesj: up early, to help out wolfc & Jaikiran.
[11:56:44] <alesj> 5am?
[11:56:56] <dmlloyd> about 4:30 yeah
[11:57:02] <alesj> nice :-)
[11:57:09] <dmlloyd> slowly adjusting :)
[11:57:10] <rmaucher> nice :)
[11:57:21] <alesj> that's for that dinner the other day, making me look into xml myself
[11:57:22] <alesj> :-)
[11:57:53] <wolfc> Jaikiran, as for terminology, container/servitor => component, effigy => component configuration
[11:58:46] <Jaikiran> ok
[11:58:55] *** miclorb has quit IRC
[11:59:05] <wolfc> don't worry too much about those details. First and foremost I want to see the flaws in the conceptual design.
[12:03:49] *** emmanuel has quit IRC
[12:10:52] *** asoldano has quit IRC
[12:12:02] *** AndyTaylor has quit IRC
[12:12:03] *** AndyTaylor1 has joined #jboss-as7
[12:14:32] <dmlloyd> I have to say, I really don't get https://github.com/wolfc/jboss-as/commit/02d377fc60f148cc6d
[12:14:32] <jbossbot> git [jboss-as] 02d377f.. Carlo de Wolf Dup2 hack for javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,39] Message: Premature end of file.
[12:14:47] <wolfc> I was just about to point it out :-)
[12:14:53] <dmlloyd> the only thing that could possibly do is, prevent the input stream from reading big chunks
[12:15:03] <wolfc> https://github.com/jaikiran/jboss-as/commit/aa8ffaf6ae9e53f4905922755eb56f0c37541f89
[12:15:03] <jbossbot> git [jboss-as] aa8ffaf.. jaikiran Change the version of xml to 1.1 to prevent the javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,39] Message: Premature end of file.
[12:15:04] *** kkhan is now known as kabir_afk
[12:15:04] <dmlloyd> which might point to a bug in ZIS, or a bad zip
[12:15:38] <wolfc> Jaikiran, dmlloyd, take a look at line #15
[12:15:46] <dmlloyd> ah
[12:15:47] <dmlloyd> cute.
[12:15:55] <wolfc> it might be that
[12:15:59] <dmlloyd> yeah it could be.
[12:16:25] <Jaikiran> hmm strange, i never noticed that
[12:16:30] <wolfc> there is a second piece that need more thought
[12:16:33] <dmlloyd> I think that points to a stax bug.  We're already going to bundle our own JAXP, just haven't gotten there yet
[12:16:35] * wolfc is digging
[12:17:34] <wolfc> I'm purposely being an ass here: https://github.com/wolfc/jboss-as/blob/ejb3-domain/build/src/main/resources/modules/org/jboss/as/ejb3/main/module.xml#L30
[12:18:07] <dmlloyd> ha.
[12:18:24] <dmlloyd> what I"d do there is, remove all the random deps, then set org.jboss.modules to TRACE
[12:18:27] <wolfc> I'm not sure how we can improve this piece. We need better error reporting to make it something usable.
[12:18:29] <dmlloyd> find out what's blowing up
[12:18:43] <wolfc> It's class loading on EJB3Extension.
[12:18:52] <dmlloyd> yeah the problem is that missing deps are tough to track because the class loader eats the exception at various points
[12:18:56] <wolfc> Some dependent class is missing.
[12:19:06] <dmlloyd> using org.jboss.modules in TRACE will show you the exact failure
[12:19:29] <wolfc> It also ties into the discussion on generating this sort of stuff.
[12:19:40] <dmlloyd> it's bootstrap phase, so you'll want to edit logging.properties
[12:20:01] <wolfc> One argument to add to this, we need to be able to verify whether this is correct or not.
[12:20:09] <wolfc> If we can't verify it anyway...
[12:20:37] <wolfc> + what I don't want is baby sitting transient dependencies
[12:21:23] <dmlloyd> there's no way to verify it right now
[12:21:29] <dmlloyd> tattletale goes some of the way but not all the way
[12:21:45] <dmlloyd> we can revisit the problem later though
[12:21:55] <wolfc> so the pom is our best source currently
[12:22:04] <dmlloyd> the pom is a good starting point
[12:22:45] <wolfc> does it actually do transient dependencies?
[12:23:08] *** epbernard has joined #jboss-as7
[12:23:08] *** epbernard is now known as emmanuel
[12:23:08] *** ChanServ sets mode: +v emmanuel
[12:23:11] <dmlloyd> tattletale?  yeah, sort of
[12:23:22] <dmlloyd> I assume you mean transitive
[12:23:22] <wolfc> no, I mean module.xml
[12:23:33] <wolfc> ah yes, bad translation errors
[12:24:04] <dmlloyd> no, module.xml specifies immediate dependencies only.  you can explicitly re-export an import though, thus making an implied transitive dep whenever someone imports your module
[12:24:15] <dmlloyd> which, I guess, is what you were actually asking :)
[12:24:31] <wolfc> yes, I only want to specify my high level dependencies
[12:24:53] <dmlloyd> ah well that isn't a great idea on a module level
[12:25:04] <dmlloyd> because it makes it much harder to restrict what is seen from imports
[12:25:38] <dmlloyd> the only time it's OK is if you've got some API JAR which is an extension of another API JAR and is in fact completely useless without it
[12:26:08] <wolfc> anything that I use from some util library is useless unless it has its dependencies on the cp
[12:26:18] <dmlloyd> there is no CP
[12:26:26] <dmlloyd> if you pull in some util library, it can have dependencies you don't see
[12:26:33] <dmlloyd> it doesn't have to be on your import list
[12:26:34] <wolfc> ultimo module.xml leads to a cp, not?
[12:26:37] <dmlloyd> nope
[12:26:53] <dmlloyd> every module is its own class loader which can only see its immediate dependencies
[12:27:02] <dmlloyd> they are truly modules
[12:27:09] <dmlloyd> not like maven where it's one flat classpath
[12:27:24] <wolfc> ah yes, cl, cp, potato. :-)
[12:27:49] <wolfc> this is unmanagable
[12:28:21] <dmlloyd> well, to be clear, when we talk about class path, that tends to refer to a collection of resource roots taken together into a single class loader
[12:28:46] <wolfc> to me there is a 1-1 correlation between cp and cl
[12:28:49] <dmlloyd> and, thus far modules has been quite a bit easier to manage than, say, maven deps
[12:29:28] <dmlloyd> your defined modules should only import what they need
[12:29:33] <wolfc> well at the end of the day I take the easy way out. put everything in module.xml.
[12:29:35] <dmlloyd> no more
[12:29:50] <dmlloyd> don't do that unless you want your patch rejected :)
[12:29:55] <dmlloyd> it's more work in the end!
[12:30:19] <wolfc> no, it's already unmanageable to begin with.
[12:30:26] <dmlloyd> it's been fine for everyone else
[12:31:08] <dmlloyd> and we've already dealt with far more complex scenarios than you're likely to run into
[12:31:26] <wolfc> well as long as you have no way to verify that that module.xml is wrong, we'll get along fine :-P
[12:31:52] <dmlloyd> when you've got references to modules which don't appear in your pom or subsystem, that's all the verification I need
[12:32:12] <dmlloyd> ultimately we'll have tattletale, or something like it, to help
[12:32:14] <wolfc> ROFL, I got 3 deps in the pom
[12:33:45] <dmlloyd> it's not hard, just add an entry for each API you use
[12:34:05] <wolfc> I had this, https://github.com/wolfc/jboss-as/blob/aebcfbb6ef2a36b24c8165a279971a0b59c9c4a4/build/src/main/resources/modules/org/jboss/as/ejb3/main/module.xml
[12:34:17] <rmaucher> is it possible to pull this ? https://github.com/rmaucher/jboss-as/commit/7569ac5b493e0f9b149fe71375ff8854f039e0cd
[12:34:18] <jbossbot> git [jboss-as] 7569ac5.. Rémy Maucherat Add various Servlet container elements....
[12:34:31] <dmlloyd> rmaucher: looking
[12:35:49] <rmaucher> there's still a need to wait for a while to get anything pulled :( see the WS pull request as well
[12:36:05] <dmlloyd> yeah I've been working with allesio
[12:36:11] <rmaucher> thanks
[12:36:49] *** mmoyses has joined #jboss-as7
[12:36:49] *** ChanServ sets mode: +v mmoyses
[12:38:00] <dmlloyd> wolfc: then that's your starting point.  If you hit NCDFE, don't start randomly adding stuff, use the logging to see what the problem is
[12:38:20] <wolfc> if only I where to hit NCDFE
[12:38:23] <jbossbot> git [jboss-as] push master aa711bb.. Rémy Maucherat Add various Servlet container elements....
[12:38:23] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/835c430...aa711bb
[12:38:30] <wolfc> That would have been easy to solve.
[12:38:34] <dmlloyd> let me ask you
[12:38:43] <dmlloyd> have you turned up modules trace logging yet
[12:38:53] <wolfc> nope, will do that now
[12:39:01] <dmlloyd> then you will see, it's fairly straightforward
[12:41:49] <rmaucher> thanks :)
[12:42:18] <wolfc> Jaikiran, I've replaced Dup2 with version="1.1" on ejb3-domain
[12:42:41] <Jaikiran> wolfc: does it also contain the latest from jboss-as/master?
[12:42:56] <dmlloyd> did we try it without the version 1.1 but with the EOL at the end of the file?
[12:42:57] <wolfc> Jaikiran, yes complete rebase
[12:43:05] <wolfc> yeah, did not work out
[12:43:10] <dmlloyd> ah interesting.
[12:43:14] <Jaikiran> wolfc: ok, let me pull it in
[12:43:19] <dmlloyd> maybe 1.0 actually requires an EOL or something
[12:43:29] <wolfc> the stacktrace also showed the error on line 1
[12:43:56] <wolfc> that doesn't make sense if I put a Dup2 input stream in between
[12:44:13] <wolfc> I think the in.read(buf, pos, len) is broken somewhere
[12:44:32] <dmlloyd> it may just be that the error reporting is wrong
[12:45:03] <dmlloyd> or that the whole buffer is parsed before events are returned
[12:45:15] <wolfc> version="1.0" with newline also give an error
[12:45:19] <dmlloyd> read() itself is unlikely to be the problem simply because it would have come up before now
[12:45:23] <wolfc> it doesn't make sense
[12:46:09] <wolfc> leave it to me to find silly bugs :-)
[12:46:21] <Jaikiran> from what i quickly looked at yesterday (and also one of the reasons why i switched to 1.1) was because the Sun xmlstreamparser had some switchTo11Parser() call at some point where this was failing
[12:46:42] <Jaikiran> btw, does this pass with other JDKs?
[12:47:07] <dmlloyd> yeah it's not valid 1.0 XML
[12:47:14] <wolfc> I'm running IcedTea6 1.9.4
[12:48:05] <dmlloyd> ah, nm
[12:48:07] <dmlloyd> IDEA just being a butt
[12:48:54] <dmlloyd> probably a JAXP bug, not gonna worry about it for now
[12:49:11] <dmlloyd> once we get our own JAXP packaged up we can revisit
[12:50:46] *** asoldano has joined #jboss-as7
[12:53:21] <wolfc> dmlloyd, on a slightly different topic, this is what happens if I deploy the failing stuff twice: http://pastebin.com/TicxVaQe
[12:53:40] <wolfc> I would not expect the error @ 41
[12:54:04] <wolfc> as it looks like ejb3-mbean.sar was never undeployed properly
[12:54:24] <dmlloyd> yeah looks like it
[12:54:50] <dmlloyd> and, I see why
[12:55:06] <dmlloyd> the attachment isn't being added until everything finishes OK, so undeploy() doesn't see it
[12:59:10] <dmlloyd> tell me if http://github.com/dmlloyd/jboss-as/commit/8b9f0b9 fixes it
[12:59:10] <jbossbot> git [jboss-as] 8b9f0b9.. David M. Lloyd Fix bug where module is not properly removed
[12:59:19] <dmlloyd> you should be able to rebase on it
[12:59:28] <dmlloyd> if it works I'll push it upstream so you'll be clean
[13:02:41] *** AndyTaylor1 has quit IRC
[13:02:56] *** AndyTaylor has joined #jboss-as7
[13:02:56] *** ChanServ sets mode: +v AndyTaylor
[13:03:16] <Jaikiran> wolfc: dmlloyd: Fyi - i've updated to the latest that John has implemented and am going to start with the SLSBComponent implementation (which is based off AbstractComponent)
[13:03:30] <dmlloyd> okay, Jaikiran.
[13:04:13] <dmlloyd> I've talked to baileyje about ComponentFactory - he plans to change it to accept the ComponentConfiguration that created it so you should be able to come up with some kind of SLSBComponentConfiguration which extends it
[13:04:17] <wolfc> Jaikiran, keep in mind that the Pool is also a 'MB' which we inject via metadata
[13:05:09] <Jaikiran> wolfc: what advantage does pool being a MB serve?
[13:05:41] <wolfc> At some point users will want to be able to plug their own Pool impls
[13:05:55] <wolfc> If those impls are already managed, then they get full injection free of charge
[13:07:15] <dmlloyd> that's the point of making everything components
[13:07:25] <dmlloyd> well, one of them
[13:10:46] <wolfc> dmlloyd, I did not get anything useful from modules trace, https://gist.github.com/8e6a99bc604591a793ce
[13:12:07] <dmlloyd> TRACE
[13:12:10] <dmlloyd> not DEBUG
[13:12:46] *** frainone has joined #jboss-as7
[13:12:46] *** ChanServ sets mode: +v frainone
[13:15:09] <wolfc> dmlloyd, ah yes, the FileHandler has a threshold
[13:15:38] <dmlloyd> I would be interested in seeing the output as well
[13:15:51] <dmlloyd> trying to come up with ways to improve the diagnostics
[13:16:09] *** kabir_afk is now known as kkhan
[13:17:27] <wolfc> I think we'll need to write our own ServiceLoader. The real exception gets swallow its LazyIterator.
[13:17:41] <wolfc> swallowed in its
[13:17:56] <dmlloyd> yeah, that is annoying.
[13:19:08] <wolfc> so its a java.lang.ClassNotFoundException: org.jboss.as.server.Extension from [Module "org.jboss.as.ejb3:main" from local module loader @7d2452e8 (roots: /home/carlo/work/jboss-as/build/target/jboss-7.0.0.Alpha2/modules)]
[13:19:32] <dmlloyd> so you need a dep on org.jboss.as.server
[13:20:39] <wolfc> yup, that makes sense
[13:23:41] *** asoldano has quit IRC
[13:23:41] *** asoldano has joined #jboss-as7
[13:26:54] <dmlloyd> I lied, I did a fixup on that patch: http://github.com/dmlloyd/jboss-as/commit/4dae6b8
[13:26:55] <jbossbot> git [jboss-as] 4dae6b8.. David M. Lloyd Fix bug where module is not properly removed
[13:27:01] <dmlloyd> so if it works you'll have to rebase again ;)
[13:31:30] <wolfc> one for the docs: http://community.jboss.org/thread/162032
[13:41:58] <wolfc> dmlloyd, cleaned up the module.xml in https://github.com/wolfc/jboss-as
[13:42:19] <dmlloyd> okay, did my patch fix the redeploy thing?
[13:42:28] <wolfc> need to check, hold on
[13:45:46] *** smarlow has joined #jboss-as7
[13:45:46] *** ChanServ sets mode: +v smarlow
[13:47:19] <wolfc> dmlloyd, yup, that fixes that issue. I'm now only left with a broken management connection.
[13:47:42] <dmlloyd> okay
[13:47:55] <jbossbot> git [jboss-as] push master 4dae6b8.. David M. Lloyd Fix bug where module is not properly removed
[13:47:55] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/aa711bb...4dae6b8
[13:55:22] *** ccrouch has joined #jboss-as7
[13:55:22] *** ChanServ sets mode: +v ccrouch
[13:55:24] <asoldano> dmlloyd, good morning :-) Just since you said it's a race... my stuff for the initial ws integration has been rebased ;-)
[13:55:35] <dmlloyd> haha okay
[13:55:40] <dmlloyd> I've been looking at it, honest :)
[13:55:55] <asoldano> dmlloyd, thanks
[13:58:14] *** ccrouch1 has quit IRC
[14:04:47] *** pferraro has joined #jboss-as7
[14:04:47] *** ChanServ sets mode: +v pferraro
[14:06:32] <darranl> Anyone have an guidance as to how we should be handling property types using ModelNodes in the detyped model?
[14:06:58] <dmlloyd> nothing really good
[14:07:11] <dmlloyd> we've been treating property types as a sort of giant attribute
[14:09:22] <darranl> dmlloyd, sorry in this case really mean a list of named properties like this - http://pastebin.com/ZazHXGiq
[14:09:58] *** AndyTaylor has quit IRC
[14:10:06] <dmlloyd> normally the syntax we use prefers attributes <propert name="foo" value="bar"/>
[14:10:18] <dmlloyd> using content only for big stuff
[14:10:58] <darranl> ok, this is just the porting to detyped - should I also update the xsd or leave that for a subsequent task?
[14:11:07] <dmlloyd> leave it for later
[14:11:38] <darranl> for representing in the ModelNodes do we just dynamically add based on the name set or should these be represented some other way?
[14:12:14] <dmlloyd> I'd just go with { "name" => "value" }
[14:12:42] <Jaikiran> dmlloyd: quick question - is this AS7 checkstyle different from what we used to use earlier for jboss projects?
[14:12:50] <dmlloyd> yes
[14:12:55] <dmlloyd> probably
[14:13:01] <dmlloyd> I don't know what was used earlier
[14:13:05] <Jaikiran> i see the braces being on the same line as the if statements, for example
[14:13:18] <dmlloyd> the style is, four-space indent, braces on the same line
[14:13:18] <Jaikiran> earlier i used to have a checkstyle which would push them to a new line
[14:13:22] <Jaikiran> hmm ok
[14:13:23] <dmlloyd> basically the Sun recommendations
[14:13:31] <Jaikiran> just ran into the checkstyle build error
[14:13:34] <darranl> would this become a problem for the self describing nature of the domain model or will it later be able to list which names are recognised?
[14:13:34] <dmlloyd> except wrapping at 120-130 chars instead of 76 or whatever
[14:13:44] <dmlloyd> the onlything checkstyle doesn't like is trailing whitespace
[14:13:52] <Jaikiran> yeah, that thing too
[14:13:54] <dmlloyd> we enforce that to keep diffs minimal after we had some problems
[14:14:02] <Jaikiran> and for some reason i can't find that setting in IDEA
[14:14:13] <dmlloyd> darranl: properties like this are by definition somewhat free-form
[14:14:17] <dmlloyd> Jaikiran: it's under Editor
[14:14:21] * Jaikiran checks
[14:15:26] <Jaikiran> ah found it! (yet another place to configure formatting :))
[14:15:35] <darranl> thanks dmlloyd - will add it as you suggest and we can see what it looks like later.  I get the feeling if we know what properties can be set they should possibly be defined in the xsd so we can also describe them in the model otherwise clients will have issues knowing what they can actually set
[14:15:44] <opalka> dmlloyd, kkhan: I gotta question. Is it possible to deploy remotely to AS7? In AS6 we used to have MainDeployer called via JMX to do  the job.
[14:16:03] <dmlloyd> opalka: yes, though it might be a little unstable right now
[14:16:18] <dmlloyd> remote deployment is actually the default now
[14:16:22] <dmlloyd> FS deployment is a special case
[14:16:23] <opalka> dmlloyd, detyped2 gonna change the way it works in AS7 ATM?
[14:16:28] <dmlloyd> yes
[14:16:30] <dmlloyd> a little
[14:16:58] <opalka> dmlloyd, when detyped2 is going to be merged to AS7 mainstream?
[14:17:07] <kkhan> Brian started it in his handlers branch
[14:17:08] <dmlloyd> as soon as it's done
[14:17:16] <opalka> dmlloyd, ;)
[14:17:21] <dmlloyd> bstansberry is the boss of that branch
[14:17:28] <kkhan> https://github.com/bstansberry/jboss-as/tree/handlers
[14:17:31] <dmlloyd> he's working hard on it, with probably 3-4 others too
[14:18:01] <opalka> dmlloyd, IOW if I wanna start playing with remote deployments I should fork his branch?
[14:18:03] <kkhan> We need to get domain starting using detyped and I don't think that will happen this week
[14:18:26] <opalka> kkhan, thanks for info. This is I wanted to hear (not this week).
[14:18:50] <kkhan> We're working on it, but it is a big job :-)
[14:18:53] <opalka> kkhan, I will clone Brian's detyped2 branch then
[14:18:55] <dmlloyd> once that's merged, I'll be making some changes to deployment as well to account for multiple content roots per deployment
[14:19:33] <kkhan> opalka: Yeah, https://github.com/bstansberry/jboss-as/tree/detyped2 is the "main" branch for this
[14:19:47] <kkhan> https://github.com/bstansberry/jboss-as/tree/handlers is where he started implementing the deployment api
[14:20:09] <kkhan> I think handlers will end up in detyped2 when more complete
[14:23:45] <opalka> kkhan, What is the status of maven-surefire plugin in your git account? Is it usable?
[14:23:55] <opalka> kkhan, I'm asking because now we're using maven surefire for AS6 testing
[14:24:17] <kkhan> opalka: Yes, it is already used in testsuite/smoke (at least it was a while ago)
[14:24:19] <opalka> kkhan, I'm wondering whether we should use modules based version of it for AS7? What's your opinion on that?
[14:24:49] <kkhan> THat is basically what my surefire plugin does, it sets up the modular env
[14:24:52] <opalka> kkhan, opinion/experience
[14:25:09] <kkhan> Yes, AS 7 should be tested in modular env
[14:25:28] <opalka> kkhan, thought so ;)
[14:25:44] <kkhan> the plan for the forked surefire plugin is to integrate with arquillian as well so that arq is not needed on app classpath either
[14:26:14] <kkhan> However, I have not finished that - I've put that aside until all the demos are working again with all our new stuff
[14:26:25] <dmlloyd> hit this transient failure: http://fpaste.org/8BjL/
[14:26:36] <kkhan> Then the plan is to have the demos be part of our smoke tests
[14:27:04] <jbossbot> git [jboss-as] push master 36cb64f.. asoldano [JBAS-8838] Providing initial WS subsystem...
[14:27:05] <jbossbot> jira [JBAS-8838] Provide initial WS subsystem functionalities [Open, Major, Alessio Soldano] https://issues.jboss.org/browse/JBAS-8838
[14:27:06] <jbossbot> git [jboss-as] push master db2fe22.. asoldano [JBAS-8838] Updating jbossws-cxf-client/server modules to be more specific on apache cxf module's import; making javax.xml.bind.api module depend on com.sun.xml.bind impl
[14:27:06] <jbossbot> git [jboss-as] push master c8bdc7c.. asoldano [JBAS-8838] Avoid exposing jaxb impl; keep that for ws deployments classloader only for now (will need to be revisited)
[14:27:06] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/4dae6b8...c8bdc7c
[14:27:32] <kkhan> opalka: http://community.jboss.org/wiki/JBossModulesSurefirePlugin
[14:27:51] <dmlloyd> asoldano: I rebased it again.  You'll want to do a "git fetch upstream; git reset --hard upstream/master" before proceeding
[14:27:59] *** jpederse has joined #jboss-as7
[14:28:03] *** jpederse has joined #jboss-as7
[14:29:41] *** smcgowan has joined #jboss-as7
[14:29:41] *** ChanServ sets mode: +v smcgowan
[14:31:01] *** bstansberry has joined #jboss-as7
[14:31:02] *** ChanServ sets mode: +v bstansberry
[14:31:35] <smarlow> wolfc, dmlloyd:  for JPA, I would like to jump into @PersistenceContext + @PersistenceUnit annotation scanning.  I saw some examples of this being done that I can follow.  Do we have something in place for handling the injection part?
[14:31:43] <opalka> dmlloyd, kkhan For JBossWS to integrate faster with AS7 is very important to have working remote deployment. Thus my question is
[14:32:02] <opalka> dmlloyd, kkhan if we should just focus on JBossWS bits or we should help with some other AS7 staff before focusing on JBossWS?
[14:32:26] <opalka> dmlloyd, kkhan to speed things up?
[14:32:42] <kkhan> Hmm, bstansberry ^^^ ??
[14:32:49] <wolfc> smarlow, those bits are already in jboss-metadata
[14:35:33] <wolfc> smarlow, except for the injection part
[14:35:56] <asoldano> dmlloyd, thanks. Thanks also for the tip on going on... I actually planned to trash the fork and start over after the pull, but I'll try this tip ;-)
[14:37:47] <smarlow> wolfc:  so for ejb use of @PersistenceContext, there will be metadata attached to the DU for me to use?
[14:39:44] <wolfc> smarlow, ejb3 will give its entire EnvironmentRefsGroup to an injection component
[14:40:40] *** kkhan is now known as kabir_lunch
[14:42:56] <wolfc> smarlow, basically you should expect to have some component that gets a Persistence*Ref scoped to a (JavaEE) component
[14:43:29] <wolfc> smarlow, then you should resolve that ref and do stuff with it. Similar to the resource provider in AS 6.
[14:45:31] <wolfc> smarlow, best to focus currently on getting the PU deployed. Do we have a DS deployer?
[14:48:53] <smarlow> wolfc:  I was just trying to fill in enough holes to do the full trip with web.
[14:49:58] <wolfc> smarlow, that'll be some way off
[14:51:06] <wolfc> smarlow, as long as I don't see a PU come up, you've got work to do :-)
[14:53:15] <smarlow> wolfc:  I'm currently attaching the PU definition for web deployments.  I need to set some additional fields though before actually bring a persistence provider in (need to pass in a classloader and a classload clone).
[14:54:16] <smarlow> wolfc:  classload==classloader clone.  Cloned classloader is for the persistence provider to use temporarily...
[14:55:45] <wolfc> smarlow, you should be processing every persistence.xml, not just the ones in web
[14:57:03] <wolfc> smarlow, did you write up a demo yet?
[14:57:24] *** fnasser has joined #jboss-as7
[14:58:53] <smarlow> wolfc:  currently, I have a web application that contains a persistence.xml that I'm deploying.
[14:59:09] <smarlow> wolfc:  Its not a demo though, just a test
[14:59:22] <wolfc> in jboss-as codebase?
[14:59:35] <smarlow> wolfc:  yes, although not merged in yet
[14:59:49] <dmlloyd> baileyje: ping me when you're in
[14:59:51] <smarlow> wolfc: the test isn't in jboss-as
[14:59:55] <wolfc> smarlow, I think it's better to do the jar case first.
[15:00:06] <wolfc> that leaves almost everything out of scope :-)
[15:01:04] <wolfc> smarlow, you have got a parsing DUP. So now you need a DUP that actually installs the PU service.
[15:01:25] <wolfc> Then we should see msc starting the lot and see Hibernate come up.
[15:02:50] *** AndyTaylor has joined #jboss-as7
[15:02:51] *** ChanServ sets mode: +v AndyTaylor
[15:03:19] <dmlloyd> I'd like to see metadata rolled into master instead of living on its own
[15:03:24] <dmlloyd> into AS7 I mean
[15:03:54] <wolfc> dmlloyd, I don't.
[15:04:12] <dmlloyd> why? it's not useful outside of AS
[15:04:14] <wolfc> Still I can see it being usable outside the scope of AS.
[15:04:16] <dmlloyd> and it's a pain to keep in sync
[15:05:16] <wolfc> What needs to be kept in sync? You get a single commit which updates it to the next version.
[15:05:46] <dmlloyd> yeah but you need a release of metadata
[15:06:01] <dmlloyd> it's silly
[15:06:08] <wolfc> The same goes for everything we've dependencies upon.
[15:06:11] <dmlloyd> what reason is there for keeping it apart
[15:06:18] <dmlloyd> I can't think of a single one
[15:06:33] <wolfc> I'm thinking of doing an annotation processor tool at some point.
[15:06:48] <dmlloyd> it just makes us have to bend over backwards to meet a contract which isn't even specified
[15:06:52] <wolfc> But that's just an example.
[15:06:59] <dmlloyd> rather than bending that project to fit the needs we know we have
[15:07:08] <wolfc> No it doesn't. jboss-metadata needs to be tightly scoped.
[15:07:12] <wolfc> And we don't go over that scope.
[15:07:18] <dmlloyd> for waht reason?
[15:07:21] <dmlloyd> that's not a first principle
[15:07:26] <dmlloyd> you must have some use case
[15:07:45] <wolfc> I just put forward a use case.
[15:07:51] <dmlloyd> an invented, fake one
[15:08:13] <wolfc> Every invention has to start somewhere.
[15:08:16] <dmlloyd> not one that (a) has any bearing on our deadline or the ERD or (b) has any evidence of actually being true
[15:08:24] <dmlloyd> why would you need metadata for an annotation processor
[15:08:26] <rmaucher> dmlloyd: yes, we should lose commit access to our own project, and give you the keys, I get the idea :)
[15:08:27] <dmlloyd> it makes no sense
[15:08:42] <dmlloyd> so it's about control?
[15:08:58] <rmaucher> and logic too :)
[15:09:03] <dmlloyd> what logic
[15:09:05] <wolfc> Not to me. To me its about re-use.
[15:09:09] <dmlloyd> what re-use
[15:09:20] <rmaucher> it's a 100% separate component, thus it is kept separate
[15:09:34] <dmlloyd> it is separate because it is separate, so it must remain separate to be separate?
[15:09:39] <dmlloyd> that's not really logic
[15:09:41] <rmaucher> and it's also about control, so I don't have to beg for days before being able to commit ...
[15:09:47] <rmaucher> right
[15:10:08] <wolfc> what is the logic of getting it into AS 7 codebase?
[15:10:22] <dmlloyd> so that we can make changes to it more quickly and incrementally
[15:10:23] <wolfc> which is already turning into a big pile of mud.
[15:10:37] <dmlloyd> so we can split it into ee base, web, ejb, jca etc pieces
[15:10:40] <rmaucher> wolfc: he gets to make you beg for pulls :)
[15:10:56] <wolfc> it already has those splits
[15:11:19] <rmaucher> yes, it is split per component, like the previous metadata (better actually)
[15:12:00] <wolfc> I fully agree that the ejb3 model was over the top
[15:12:16] <wolfc> But stuffing everything in one codebase for arguments sake is just as bad.
[15:12:35] <dmlloyd> it's not for arguments sake
[15:12:40] *** emmanuel has quit IRC
[15:12:50] <wolfc> If we ever want to achieve a similar setup to yum, then we need to be able to juggle different components.
[15:13:04] <dmlloyd> of course, but not when there's no need
[15:13:25] <dmlloyd> if project A and project B are released in lock step then that's a fair indication that they should be one, that the abstraction is in the wrong place
[15:13:42] <rmaucher> with that reasoning, the servlet container could be pulled in too
[15:13:46] <dmlloyd> yes
[15:13:49] <wolfc> That's because AS setup is wrong :-)
[15:14:08] <wolfc> AS should be an integration platform, not an integration codebase.
[15:14:10] <dmlloyd> you think it's better to manage 90 independent versions?  even though they all increment at the same time?
[15:14:12] <rmaucher> because if the web container ever starts using metadata (rather than converting to its own internal stuff) it would have a circular dependency
[15:14:41] <dmlloyd> circular deps are another dead giveaway that the component is divided up wrong
[15:14:44] <wolfc> we did ejb3 releases outside of the AS releases
[15:14:57] <wolfc> and install them using our own package manager
[15:15:21] <rmaucher> dmlloyd: you should rewrite it :)
[15:15:27] <dmlloyd> and how many man-years did it cost, and how many did it safe?
[15:16:31] <rmaucher> depends, it's probably only about two David-weeks actually ;)
[15:17:17] <rmaucher> anyway, so I would like to be able to possibly use metadata as-is in the container if possible, so if you pull that in, I won't be able to do that
[15:17:38] <dmlloyd> in which container? servlet?
[15:17:41] <wolfc> the same goes for everything that gets pulled in
[15:17:59] <dmlloyd> not things which have an independent lifecycle, wolfc
[15:18:16] <rmaucher> yes, in the servlet container
[15:18:17] <wolfc> exactly, and I'm not the one defining that lifecycle.
[15:18:51] <dmlloyd> things like infinispan or weld or whatever, which have a lifecycle and real consumers outside of our environment, should have an independent lifecycle (but the integration code for them should not)
[15:19:20] <wolfc> my consumers define that lifecycle :-)
[15:19:23] <dmlloyd> we've tried many times over the years to produce an independent project for the EE sub-specs without success
[15:19:30] <dmlloyd> with lots of effort though
[15:19:57] <dmlloyd> that's why it was decided that AS should be the platform for standalone spec stuff too
[15:20:03] *** opalka is now known as opalka_away
[15:20:44] <wolfc> I tried that and it's not that simple.
[15:21:04] <dmlloyd> simpler than the alternative
[15:21:17] <wolfc> The alternative is the Fedora model.
[15:21:26] <dmlloyd> no, that's orthogonal
[15:21:54] <dmlloyd> even with a completely incremental update system, you still have the problem that core components are released and tested in lock-step
[15:21:55] <wolfc> We should have a simple kernel and a distribution mechanism
[15:22:03] <dmlloyd> that sounds great, on paper
[15:22:11] <wolfc> Sure components need to be integrated, that's a fact of life.
[15:22:23] <dmlloyd> integration is 90% of the work and 90% of the code
[15:22:29] <dmlloyd> there's almost nothing of value outside of it
[15:22:36] <dmlloyd> integration is the definition of the specs
[15:22:54] <dmlloyd> if it were something like OSGi bundle distribution it'd be a different story
[15:23:24] <rmaucher> why is my use case of metadata inside the servlet container simply casually ignored ?
[15:23:38] <dmlloyd> it's not, I think that moving metadata to the servlet container is a good idea
[15:23:51] <dmlloyd> except, of course that the common EE code becomes a problem then
[15:24:00] <dmlloyd> because all the other EE bits are in AS
[15:24:57] <rmaucher> so we can't do that, the nice thing about metadata is that it cleanly (hopefully) deals with the ton of common EE metadata
[15:26:30] <wolfc> the part of having EE bits in AS is wrong
[15:26:40] <rmaucher> so I see no way other than bring all the "external" containers into AS then (EJB, WS, etc etc)
[15:26:46] <wolfc> you should separate core functionality from integration code
[15:26:59] <dmlloyd> those principles are useless in the face of reality
[15:27:08] <wolfc> https://github.com/jbossejb3/jboss-ejb3-tx2/blob/master/impl/src/main/java/org/jboss/ejb3/tx2/impl/CMTTxInterceptor.java
[15:27:18] <wolfc> that code has seen two TCKs already
[15:27:31] <wolfc> to me it is much more valuable then anything you write up
[15:28:02] <wolfc> we can merge it in, I don't mind.
[15:28:20] <wolfc> That way we'll never get any more fixes out of it for EAP <6 and AS <7
[15:28:22] *** pil-afk is now known as pilhuhn
[15:28:42] <dmlloyd> you're still doing less work
[15:28:53] <dmlloyd> if you replicate a fix across three branches
[15:29:07] <dmlloyd> it's less work than putting in the fix and coordinating the release of 50 dependent projects
[15:29:34] <wolfc> We don't have a chain of 50 anywhere.
[15:31:03] <wolfc> Like I said yesterday, we'll never agree on where source needs to live.
[15:31:59] *** aloubyansky has joined #jboss-as7
[15:32:17] <wolfc> But I'm always in for a bit of fun (just like switching to maven), so I'll go along with any ride. :-)
[15:32:33] *** epbernard has joined #jboss-as7
[15:32:33] *** epbernard is now known as emmanuel
[15:32:33] *** ChanServ sets mode: +v emmanuel
[15:36:00] <smarlow> wolfc: I'm currently starting the JPA subsystem and independently parsing the persistence.xml (I though we were going to handle JPA aspects independently).  How does the PU service fit in?
[15:36:34] <wolfc> smarlow, after your parsing DUP you need a component installer DUP
[15:36:42] <wolfc> that would fire up the PU service
[15:36:45] <rmaucher> wolfc: ok, so David merges metadata in AS then ? ;)
[15:37:02] <wolfc> rmaucher, I would say no.
[15:37:05] <bstansberry> kkhan, opalka: I wasn't around earlier
[15:37:18] <rmaucher> you just said you were ok with the ride
[15:38:13] <wolfc> I'll go along with any ride, doesn't mean I agree to the entertainment value. :-)
[15:38:35] <rmaucher> lol
[15:39:04] <bstansberry> kkhan, opalka: is the question help on remote deployment vs other aspects of WS integration?
[15:39:47] <bstansberry> if so, what would be most immediately helped is a detyped version of the WS integration (NewExtension etc)
[15:41:56] <asoldano> bstansberry, let me explain
[15:42:10] <asoldano> bstansberry, Richard was basically asking about the remote deploymeny
[15:42:21] <asoldano> bstansberry, becase we'd like to restore the run of our testsuite
[15:42:25] <darranl> bstansberry, I was going to offer to pick up that one next if the current was typed
[15:42:58] <asoldano> bstansberry, if that's blocked by other things there, let me know / understand, perhaps we can help
[15:43:23] <asoldano> bstansberry, we didn't do anything for detyped in ws module yet
[15:43:35] <asoldano> bstansberry, the initial ws integration was pulled few hours ago
[15:44:09] <bstansberry> remote deployment works in master
[15:44:43] <bstansberry> in the detyped2 branch, I'll get a clunky version going today
[15:45:26] <baileyje> dmlloyd here
[15:45:42] <dmlloyd> baileyje: hey.  I was going to be working on EE but got sidetracked :)
[15:46:06] <dmlloyd> keep me posted on where you're at though, I'm particularly interested in getting component config into the factory param list
[15:46:55] <baileyje> dmlloyd: Well I spent a good part of last night totally refactoring it :(
[15:47:08] <baileyje> The n I decided I may scrap the refactor.
[15:47:52] <baileyje> There is just so much stuff being created for the component.  Lots of stuff being passes around.
[15:48:04] <baileyje> but I am not sure it can be avoided.
[15:48:09] <maeste> bstansberry: do you prefer a pull request for each jca's subsystem, or one single request for all the three?
[15:48:10] <dmlloyd> well let's start small
[15:48:40] <bstansberry> darranl: I just looked at the WS stuff in master; it looks pretty simple to convert; probably simpler for you to do it than to explain
[15:48:45] <maeste> bstansberry: I'm ready for connector's subsystem, working on other two
[15:48:58] <jfclere> wolfc: dmlloyd: rmaucher: What about having https://github.com/jbossmetadata so we have a common repos?
[15:49:24] <bstansberry> maeste: one at a time is fine
[15:49:27] <smarlow> wolfc:  I see that services have start/stop life cycle and a getValue().  Are you suggesting that JPA not be a sub-system (as is currently done https://github.com/scottmarlow/jboss-as/commit/1a83185620917b5df814dc1a80e38a80dfe69213)
[15:49:28] <jbossbot> git [jboss-as] 1a83185.. Scott Marlow keep changes linear...
[15:49:47] <maeste> bstansberry: oki, let me rebase my branch against your so
[15:49:59] <maeste> bstansberry: and I'm ready for the first one
[15:50:04] <baileyje> dmlloyd: I was considering utilizing attachments to hold onto some of the info.
[15:50:06] <wolfc> smarlow, to me that commits looks good
[15:50:18] <rmaucher> jfclere: no problem, it's the same thing for me ;)
[15:50:36] <maeste> bstansberry: am I right saying pull request should be against your detyped2 branch?
[15:50:46] <bstansberry> maeste: yes
[15:50:59] <baileyje> dmlloyd: As to not have parameter explosion and allow additional processors to get in the game before the component is installed.
[15:51:04] <darranl> bstansberry, "probably simpler for you to do it than to explain" that is what I was thinking, not much longer on OSGi and I can start that one
[15:51:36] <baileyje> dmlloyd: but I agree, starting small is a good idea.
[15:52:04] <dmlloyd> baileyje: I think that componentconfiguration is really good unit.
[15:52:13] <dmlloyd> if we put that in an attachment list we'd be gtg
[15:52:31] <baileyje> Yeah.  We already have the component configuration
[15:52:45] <darranl> bstansberry, do we need you to rebase detyped2 against master to get the original WS integration pulled in correctly?
[15:53:10] <baileyje> dmlloyd: Ok.  Well I will look into that route.
[15:53:26] <baileyje> just need to blow away my current working copy
[15:53:32] <bstansberry> darranl: good point. i'll do that now
[15:53:41] <maeste> bstansberry: oki there you go https://github.com/maeste/jboss-as/tree/jcaDetyped
[15:53:53] <bstansberry> maeste: thanks
[15:53:53] <maeste> bstansberry: or do you need a pull request in ML?
[15:54:02] *** ALR has joined #jboss-as7
[15:54:02] *** ChanServ sets mode: +v ALR
[15:54:09] <darranl> bstansberry, then later or tomorrow we probably need to look at the pull request from mmoyses as it will need some re-work of the security conversion
[15:54:20] <bstansberry> no, IRC is fine
[15:55:08] <bstansberry> darranl: ok
[15:55:23] <asoldano> bstansberry, darranl: thanks
[15:59:43] *** opalka_away has quit IRC
[16:02:26] *** smarlow has quit IRC
[16:13:10] *** pmuir has joined #jboss-as7
[16:13:16] *** pmuir has joined #jboss-as7
[16:13:16] *** ChanServ sets mode: +v pmuir
[16:17:34] *** asaldhan has joined #jboss-as7
[16:17:34] *** ChanServ sets mode: +v asaldhan
[16:25:38] <Nihility> Just to add my thoughts on this metadata separation issue, ultimately the direction for our product is that we have one platform that can be slimmed to a standalone service. True standalone frameworks should be only done when there Is a good technical or community reason, and there is the resourcing to do it. For example, infinispan has a very active community with lots of contributors that are using it as a pure standalone framework. A servlet
[16:25:38] <Nihility> contenta
[16:25:44] <darranl> bstansberry, got time for a question?
[16:26:14] <bstansberry> sure
[16:26:34] <bstansberry> while I watch eclipse download WS dependencies
[16:26:50] <darranl> bstansberry, just writing the add operation for OSGi, looking at the existing add operation they pass their typed configuration to a number of services
[16:27:18] <Nihility> An isolated servlet container could make sense, it has some historical precedent, but it does require thought. EJB standalone though I think is much harder to justify because for all intents and purposes EJB IS an application server
[16:27:31] <darranl> bstansberry, should those services also be updated to use the detyped model or can a component convert from detyped to their own typed model for their use?
[16:28:10] <bstansberry> conversion is allowed
[16:28:27] <bstansberry> there are going to be a lot of subsystems that use their own internal API
[16:28:40] <bstansberry> HornetQ, Infinispan etc
[16:28:41] <Nihility> our long term strategy with "metadata" should reflect those decisions
[16:28:45] <darranl> bstansberry, ok  I think that makes it easier for me so I will go for conversion now and then they can switch internally to detyped if they wish
[16:29:16] <Nihility> for now we seem to be making good progress
[16:29:43] <rmaucher> Nihility, well, ok, only very specific projects exist as real standalone, but this does not imply all code goes into one repo
[16:29:44] <Nihility> as we solidify EE I think it will become obvious how to bundle it
[16:30:00] <bstansberry> I think I good rule of thumb is if something lives entirely in the integration module, creating typed objects to represent the detyped stuff has a bad smell
[16:30:21] <wolfc> Nihility, how would you explain for example a standalone package like dbus-libs for Fedora?
[16:30:27] <bstansberry> but we should never force the detyped stuff outside of the integration module
[16:30:55] <dmlloyd> wolfc: you can't carry the metaphor that way
[16:30:57] <dmlloyd> it doesn't work
[16:30:58] <wolfc> Just like EJB it has no right to live alone :-)
[16:31:37] <dmlloyd> who knows how they version their source components
[16:31:55] <dmlloyd> if it's like other C projects, they probably build the libs in the same project as the dbus application program
[16:31:59] <darranl> bstansberry, (I know this shouldn't decide the final solution) one problem I have is that for this conversion we are pre-fixing everything 'New' so we don't break the ability to rebase to pass these changes back to master - if each of these services is changed today each of them will need to be cloned as well so a conversion from detyped to typed for now also allows that to be deferred
[16:32:05] <dmlloyd> in any case it's not justification
[16:32:21] <Nihility> I think a better analogy is the Linux kernel
[16:32:23] <dmlloyd> it's just an appeal to some outside authority based on the assumption that it's "right" without reasons
[16:32:35] <Nihility> Should yum update the VM implementation
[16:33:02] <wolfc> Okay, a bit closer to home then: http://sourceforge.net/projects/jboss/files/EJB%203.0/JBoss%20EJB%203.0%201.0.19/jboss-ejb3-plugin-1.0.19-installer.jar/stats/timeline
[16:33:32] <bstansberry> darranl: I'm fine with doing what's needed to make this easy to merge
[16:34:09] <darranl> bstansberry, ok thanks will go with the conversion and then maybe consider it as a candidate for a second pass post merge to refine
[16:34:51] <wolfc> You'll never hear me say that EJB has a life without AS.
[16:35:11] <wolfc> But we can have stuff independently release of AS.
[16:35:30] <dmlloyd> for what purpose?
[16:35:55] <wolfc> because community fixes stuff
[16:36:18] *** smarlow has joined #jboss-as7
[16:36:18] *** ChanServ sets mode: +v smarlow
[16:37:18] <dmlloyd> so?
[16:37:36] <dmlloyd> how are they going to use that fix without an AS
[16:38:32] <Nihility> its certainly a way to deliver new features and patches
[16:39:21] <Nihility> we can also do them for AS as a whole as well
[16:39:49] <Nihility> which is the model EAP will use
[16:39:56] <Nihility> does use rather
[16:40:26] <Nihility> the beneift would be allowing things to have a faster release cycle
[16:40:37] <Nihility> however then you have the combination complexity
[16:40:59] <dmlloyd> things can have an independent release cycle, when it makes sense
[16:41:15] <wolfc> sense is subjective
[16:41:15] <dmlloyd> i.e. it's an independent thing with a use outside the AS which isn't bound to it release-wise
[16:41:23] <dmlloyd> no, I have very specific rules
[16:41:30] <dmlloyd> criteria
[16:43:53] *** pgier has joined #jboss-as7
[16:43:53] *** ChanServ sets mode: +v pgier
[16:43:59] <Nihility> rmaucher: right whether or not a famework is "standalone" doesn't dictate whether it should be in the AS repo, it just doesn't preclude it
[16:45:05] <Nihility> what repos it lives in is really a question of what can we get that is easy to maintian and fits the release cycles for all the components we have
[16:49:30] <dmlloyd> baileyje: how's it going, still running into trouble?
[16:49:42] <baileyje> dmlloyd: Nahh.  It is going.
[16:49:51] <baileyje> Just need some time to round it out..
[16:53:25] *** AndyTaylor has quit IRC
[16:56:25] *** mbg has joined #jboss-as7
[16:56:25] *** mbg has joined #jboss-as7
[16:56:25] *** ChanServ sets mode: +v mbg
[16:58:45] <bstansberry> darranl: I just rebased detyped2 to upstream/master and pushed it
[16:58:59] <darranl> bstansberry, excellent, will be onto that one shortly
[17:02:10] *** balunasj has joined #jboss-as7
[17:02:10] *** ChanServ sets mode: +v balunasj
[17:03:43] *** smcgowan has quit IRC
[17:03:44] *** balunasj is now known as balunasj_mtg
[17:05:16] *** kkhan has joined #jboss-as7
[17:05:16] *** ChanServ sets mode: +v kkhan
[17:05:17] *** kabir_lunch has quit IRC
[17:10:10] *** mmoyses has quit IRC
[17:15:32] *** mmoyses has joined #jboss-as7
[17:15:32] *** ChanServ sets mode: +v mmoyses
[17:24:33] *** ccrouch1 has joined #jboss-as7
[17:24:33] <bstansberry> maeste: I've been looking at the connector stuff
[17:24:33] *** ChanServ sets mode: +v ccrouch1
[17:25:00] <bstansberry> the way the registration of the XML marshallers works changed some late last week
[17:25:04] <bstansberry> https://github.com/bstansberry/jboss-as/commit/5a616698c34ffc749ca49581eb8af35a9212e72b
[17:25:05] <jbossbot> git [jboss-as] 5a61669.. bstansberry at jboss dot com Register NewConnectorSubsystemParser's XMLElementWriter aspect in initialize()
[17:25:20] <bstansberry> ^^^ shows how it should be done
[17:26:04] <bstansberry> we need to chat a bit about:
[17:26:06] <bstansberry>             final ModelNode address = parentNode.clone();
[17:26:07] <bstansberry>             address.add(ARCHIVE_VALIDATION);
[17:26:28] *** ccrouch has quit IRC
[17:26:44] <bstansberry> any element in an address needs to be a key/value pair
[17:27:11] <maeste> looking at your commit...
[17:27:19] <bstansberry> if something can't be addressed that way, it can be an attribute
[17:30:45] <maeste> oki I've seen you commit, so have you already fixed the connector parser? Are you pointing me to that for other subsystem, right?
[17:32:20] <bstansberry> i'm pointing for the other subsystem, plus you should pick up that change for your workspace
[17:32:32] <maeste> yep sure
[17:32:45] <bstansberry> the addressing issue is more significant
[17:33:51] <maeste> yep, so I have to use a key/value pair using add(propertyName, propertyValue)?
[17:34:08] <bstansberry> well, there are three choices
[17:34:35] <bstansberry> you can make ARCHIVE_VALIDATION a resource, which means it itself has attributes and operations
[17:35:01] <bstansberry> to do that, yes, you have to make it a key/value pair
[17:35:17] <bstansberry> option two is to make it an attribute with a complex structure
[17:36:01] <bstansberry> and then people can read/write the attribute as a unit
[17:36:27] <bstansberry> the 3rd is to add individual attributes for the pieces
[17:37:13] <bstansberry> e.g. archive-validation-enabled, archive-validation-fail-on-error, archive-validation-warn-on-error
[17:37:44] <bstansberry> then people can read/write the 3 things individually
[17:38:48] <bstansberry> BTW, there is no need to have a direct correspondence between the XML structure and the way things are stored/addressed in the detyped model
[17:39:12] <maeste> bstansberry: oki, extending to all cases the third approach I can have no submodels to register and just one add/remove for connector
[17:39:26] <maeste> all cases = in connector I mean
[17:39:30] <bstansberry> right
[17:39:57] *** AndyTaylor has joined #jboss-as7
[17:39:57] *** ChanServ sets mode: +v AndyTaylor
[17:40:29] <bstansberry> the API is ModelNodeRegistration.registerReadWriteAttribute
[17:41:41] <bstansberry> or registerReadOnlyAttribute if you don't want the user to be able to modify the attribute and instead plan to set the value via the connector resource's ADD operation
[17:42:27] <maeste> oki it is what I was planning
[17:44:50] <maeste> last question to be sure I've understood: but if I use ARCHIVE_VALIDATION as a resource the only things I have to change is to use a key/value pair? Registration is fine as is?
[17:45:33] <bstansberry> the registration was fine, eys
[17:45:35] <bstansberry> yes
[17:46:19] <bstansberry> well, let me look more carefully at the descriptions, I was focusing on ^^^
[17:46:43] *** alesj has quit IRC
[17:46:51] <bstansberry> if you use ARCHIVE_VALIDATION as a resource, the 3 pieces will be read-only
[17:47:34] <bstansberry> actually, making it a resource makes no sense, unless you wanted it to have operations of it's own
[17:48:09] <maeste> oki
[17:48:10] <bstansberry> a resource with only ADD + REMOVE is equivalent to a complex attribute with a read-attribute, write-attribute
[17:49:46] <maeste> oki it makes sense to me
[17:51:55] <maeste> oki I have to bring daughther to the doctor now. I'll be online tonight thought and I'll go on with tasks open
[17:55:02] *** bgeorges has quit IRC
[17:55:08] <dmlloyd> maeste, jpederse, jdbc driver deployment!
[17:55:32] <dmlloyd> baileyje: progress?  and/or any chance you can split the work into smaller bits so I can follow along?
[17:55:56] <baileyje> dmlloyd: Just about done.  Running the final test
[17:56:01] <dmlloyd> Jaikiran: also let me know if you have any questions (you're probably gone now though)
[17:56:12] *** mbg is now known as mbg|away
[17:57:22] <dmlloyd> Nihility: http://github.com/dmlloyd/jboss-modules/commit/6216ce2
[17:57:23] <jbossbot> git [jboss-modules] 6216ce2.. David M. Lloyd Log class definition problems at WARN
[17:57:28] <dmlloyd> look good?
[17:57:56] *** maeste is now known as maeste_afk
[18:04:14] <baileyje> dmlloyd: Ok.  Here is what I have so far:  https://github.com/baileyje/jboss-as/commit/be697588aff9a4ddd86623816eca02d59a5bca80
[18:04:16] <jbossbot> git [jboss-as] be69758.. John E. Bailey Break the component install process into multiple processors.  Also utilize the component config for attaching required configs
[18:04:42] <dmlloyd> ah, I liked having the factory on the config
[18:04:50] <dmlloyd> but, it's ok
[18:05:01] <baileyje> We can add it back.  It is still there.  Just attached.
[18:05:14] <dmlloyd> ah I see
[18:05:36] <baileyje> Seems more flexible that way..  maybe :)
[18:05:50] <baileyje> Anyway, as you can see, I need to comment all this stsuff
[18:06:07] <baileyje> but I figured we could both work from here
[18:06:14] <dmlloyd> sure
[18:06:40] <baileyje> Was the attachment usage what you were thinking?
[18:06:53] <baileyje> For the install pieces?
[18:07:03] <dmlloyd> I was just thinking, we keep an attachment list of component configs
[18:07:20] <dmlloyd> if factory was part of that then at install the factory would be called to create each component
[18:07:28] <dmlloyd> EJB coudl subclass the compoent config with their additional stuff
[18:07:38] <dmlloyd> their factory would just cast the config to the subtype then
[18:07:46] <baileyje> ahhh...
[18:07:48] <baileyje> well....
[18:08:27] <baileyje> That could have been there before.  The only problem was the factory was working against already resolved configuration and not the actual configuration
[18:08:31] *** smcgowan has joined #jboss-as7
[18:08:32] *** ChanServ sets mode: +v smcgowan
[18:08:51] <baileyje> Since the actual configuration needs to become real things once the classloader is available
[18:09:31] <baileyje> but 90% of the time it will be done the same way, so I didn't want to leave that to the actual factories to do.
[18:10:21] *** slaboure has quit IRC
[18:12:32] *** jcosta has quit IRC
[18:13:21] <dmlloyd> is that what all this ConstructedComponent business is about?
[18:13:28] <dmlloyd> why do we need the intermediate step
[18:13:35] <dmlloyd> why not just go right from config to component?
[18:13:51] <baileyje> dmlloyd: That was what I started refactoring last night
[18:14:33] <baileyje> I don't like it....  but somehow we need to allow the component creator to set the right dependencies with regard to naming contexts etc..
[18:15:43] <dmlloyd> wouldn't that all be in the config?
[18:15:58] <baileyje> Only if it is put in there.
[18:16:11] <baileyje> It wouldn't be in the config from a parsing point of view
[18:16:14] *** balunasj_mtg has quit IRC
[18:16:31] <baileyje> but there is nothing stopping it from going in the config
[18:17:03] <baileyje> my issue is the config is starting to play two roles.
[18:17:35] <baileyje> capturing the initial config from the parsing phase and holding onto the results of processing that config
[18:17:47] <dmlloyd> yeah, but that's kind of the intent
[18:18:00] <dmlloyd> the overall configuration comes from multiple sources
[18:18:21] <dmlloyd> doesn't mean we *must* have different classes for each stage, unless it really makes sense
[18:19:02] <baileyje> dmlloyd: Right.  I was under the assumption that multiple sources would be setting the initial config.  And "hopefully" a single set of processors can turn that config into an actual component.
[18:19:11] <dmlloyd> right
[18:19:51] <darranl> hi bstansberry I have the OSGi subsystem converted here https://github.com/darranl/jboss-as/commits/detyped%2Fosgi-subsystem
[18:20:23] <baileyje> dmlloyd:  but for certain things like Injection you need to have subsystem specific information in the actual injection.
[18:20:35] <bstansberry> darranl: good timing; i was just about to unstash something
[18:20:44] <dmlloyd> baileyje: can you give an example?
[18:21:35] <darranl> bstansberry, just to clarify I have taken these conversions as far as enabling the XML and verifying it is read, going through the motions in add and then verifying the model that comes out from your client that dumps your model and the xmlconfig demo
[18:21:56] <baileyje> With injection the rules for where an actual injected value varies between EJB and MB.  Since MB does not have a component context, it needs to bind injection targets in module and not comp
[18:22:10] <baileyje> The same goes for where the actual component itself is bound.
[18:22:27] <bstansberry> darranl: so you ran both the "descriptions" and "xmlconfig" demos?
[18:22:48] <darranl> bstansberry, yes using both of those to check the final results are as I would expect
[18:22:51] <dmlloyd> baileyje, so can we not have an InjectionConfig element within ComponentConfiguration which outlines what gets bound and where?
[18:23:01] <bstansberry> great; thanks
[18:23:19] <dmlloyd> baileyje: if those are the main variances then a base component factory could take care of all of that stuff
[18:23:32] <darranl> onto WS ;-)
[18:23:46] <baileyje> dmlloyd: Yeah.  We have the injection config already. It would just need to get primed with some additional info.
[18:23:51] <baileyje> Which is fine..
[18:24:16] <wolfc> Everybody has an environment refs group which defines what needs to be bound.
[18:25:32] *** jpederse_ has joined #jboss-as7
[18:25:37] *** jpederse has quit IRC
[18:25:57] *** pilhuhn is now known as pil-afk
[18:28:01] <baileyje> dmlloyd: What were you looking to work on?
[18:28:21] <dmlloyd> I am just trying to imagine how the EJB integration will work
[18:28:35] <dmlloyd> and remote invocation, as well
[18:29:03] <dmlloyd> thinking through how an invocation client (local or remote) might acquire a component, get a proxy etc.
[18:29:09] <dmlloyd> noting that get a proxy != get an instance
[18:29:18] <dmlloyd> and there's the class loader mess
[18:29:51] <baileyje> dmlloyd: Ok.  Well I would like to start by eliminating the ResourceResolver.  If that goes smoothly we should be able to beef up the component config to remove the intermediate constructed component.
[18:30:13] <dmlloyd> ok.  Also not sure you caught my note yesterday, but Component shouldn't be generic.
[18:30:27] <dmlloyd> the type parameter will be misleading at best once we have multiple class loaders in play
[18:30:41] <dmlloyd> in particular the proxy need not be of the same type as the instance
[18:30:41] <baileyje> ok
[18:30:56] *** jpederse_ has quit IRC
[18:31:00] <dmlloyd> so it should all just use Object for simplicity
[18:31:13] <bstansberry> darranl: pushed
[18:31:19] <darranl> thanks bstansberry
[18:32:55] *** jfclere has quit IRC
[18:32:57] <baileyje> dmlloyd: ok.  I will take care of that as well
[18:33:02] <dmlloyd> baileyje, do we have a naming standard for component services?  like app.module.comp or something?
[18:34:02] <dmlloyd> on a related note, createProxy() should accept a ClassLoader
[18:34:13] <dmlloyd> maybe more than that, but tentatively we'll leave it at that :)
[18:34:19] <baileyje> Right now no.  It is being left up to the component subsystem, but I would love to just standardize .
[18:35:06] <dmlloyd> yeah.  We have a pseudo-standard for applications with the deployment unit thing but it's not really an app in the EE sense
[18:35:40] <dmlloyd> we should have application, module, and comp services, like jboss.ee.application.foo, jboss.ee.module.foo.bar, jboss.ee.comp.foo.bar.baz maybe
[18:35:58] <dmlloyd> well, a component service for sure
[18:36:01] <dmlloyd> I'm so-so on the others
[18:36:14] <dmlloyd> for a moment I had a picture in my head but now I think, there may not be a use for them
[18:36:49] <dmlloyd> in particular, we'll need to keep a single (atomic) registry of app names so that we can meet the EE rules for unique-ifying app names
[18:36:57] <wolfc> an app also has an env
[18:37:05] <wolfc> which thus needs dependencies
[18:37:25] <dmlloyd> yeah, so far though we've conceptually associated that idea with the DU
[18:37:30] <dmlloyd> though I don't think there's any code there yet
[18:37:37] <baileyje> wolfc: by env do you mean naming context for java:app/env?
[18:37:50] <wolfc> I mean an env ref group
[18:38:10] <dmlloyd> is that spec language?  I'm not following
[18:38:27] <baileyje> That comes from the application.xml correct
[18:38:29] <baileyje> ?
[18:39:06] <wolfc> https://github.com/wolfc/metadata/blob/ejb3-wip/ear/src/main/resources/schema/application_6.xsd#L215
[18:40:22] <wolfc> dmlloyd, https://github.com/wolfc/metadata/blob/ejb3-wip/common/src/main/resources/schema/javaee_6.xsd#L116
[18:40:40] <baileyje> wolfc: We have that info being parsed and available.  We also have the naming context being added as well as the env subcontext.  Now we need to fill it up.
[18:41:02] <wolfc> yes, but to be able to judge readiness you would need a dependency chain
[18:41:04] *** AndyTaylor has quit IRC
[18:42:07] <dmlloyd> ah ok
[18:42:32] <baileyje> anyway..
[18:42:36] <dmlloyd> any app level dependencies would be on the binding spot though, not on the target component like we discussed
[18:42:53] <dmlloyd> actually I take that back
[18:43:17] <dmlloyd> we use the component to get the proxy
[18:43:29] <dmlloyd> but proxies need to be available before the component is "up"
[18:43:34] <dmlloyd> thus the component service has to be two stages
[18:43:54] <dmlloyd> call them "initial" and "up"
[18:43:54] <wolfc> are the two stages modeled as two services?
[18:43:57] <dmlloyd> yes
[18:44:16] <dmlloyd> so "initial" happens, *then* the component is bound into JNDI and all injection and stuff happens, then "up" happens
[18:44:24] <dmlloyd> the proxy is available after "initial"
[18:44:30] <dmlloyd> but it will block until "up"
[18:44:36] <dmlloyd> (or until an error happens)
[18:45:22] <dmlloyd> I think right now what we're doing is binding into JNDI with a blocking binding, and then doing "up" where the binding would be unblocked
[18:45:56] <wolfc> no, that's not good
[18:46:03] <wolfc> you can have a circular dependency
[18:46:14] <dmlloyd> yes, you can
[18:46:24] <dmlloyd> but circular deps won't really work anyway right?
[18:46:28] <wolfc> take two singletons with a circular dep
[18:46:45] <dmlloyd> by dep you mean like JNDI dep?
[18:46:46] <wolfc> they both need to come to "up"
[18:47:10] <wolfc> I mean they inject one-another
[18:47:11] *** Jaikiran has quit IRC
[18:47:18] <dmlloyd> sure that's fine
[18:47:24] <wolfc> Which goes over JNDI for EE
[18:47:37] <dmlloyd> the proxies will be available before the component finishes initializing
[18:47:48] <wolfc> But if the proxies block you would hang
[18:48:06] <dmlloyd> they have to block, unless you're saying the component is really available before it initializes
[18:48:37] <dmlloyd> it's a failure scenario either way
[18:48:38] <wolfc> Both can inject one-another without invoking upon one-another.
[18:48:47] <dmlloyd> sure
[18:48:49] <dmlloyd> that'll work
[18:48:55] <dmlloyd> the proxy doesn't block unless you use it
[18:49:16] <dmlloyd> at least that's what we discussed in antwerp isn't it?
[18:49:20] <wolfc> yes
[18:49:32] <dmlloyd> so you're OK with that?
[18:49:45] *** asoldano is now known as asoldano_dinner
[18:49:51] <wolfc> yes, I think I misunderstood 'but it will block until "up"'
[18:50:16] <dmlloyd> yeah the binding won't block, it's the actual proxy which will hold invocations
[18:50:25] <wolfc> good
[18:50:31] <dmlloyd> we would want to have some kind of deadlock detector though
[18:50:51] <dmlloyd> but we can add that later
[18:51:57] <dmlloyd> this means that after the first stage, the component needs all the information necessary to construct a proxy
[18:52:05] <dmlloyd> before the first stage rather
[18:52:14] *** pmuir has quit IRC
[18:52:16] <dmlloyd> which shouldn't be a problem I don't think
[18:54:06] <dmlloyd> baileyje, we may actually need a couple createProxy methods, one for local & one for "remote" (in-VM)
[18:54:39] <dmlloyd> in particular we need to differentiate between client and target interceptor chains
[18:54:53] <baileyje> dmlloyd: Ok.  Feel free to add them if you need them.  Otherwise I will add them when I get done with some config cleanup.
[18:54:55] <dmlloyd> I could probably take care of that though
[18:55:09] <dmlloyd> okay.  Are you in *Component right now?
[18:57:45] <baileyje> dmlloyd: Nope.  Just the config classes
[18:57:51] <baileyje> I will stay out of component
[19:00:36] <dmlloyd> cool.
[19:00:53] *** emuckenhuber has quit IRC
[19:01:07] <dmlloyd> wolfc, in the EJB case, if we're accessing, say, a SFSB for the first time, we're supposed to create the instance when we first get the proxy right?
[19:06:06] <wolfc> dmlloyd, each time a lookup occurs
[19:06:49] <dmlloyd> right, so a new proxy on every lookup too?  or do we reuse proxies which refer to the same instance from the same class loader?
[19:07:24] <wolfc> You would need a new proxy, because !a1.equals(a2)
[19:07:42] <dmlloyd> okay, well that's actually easier
[19:08:28] <wolfc> as for class loading, the proxy needs to reside in the class loader of the business interface
[19:08:39] <wolfc> which is more or less implied by the JNDI spec
[19:09:02] <dmlloyd> right
[19:10:06] <dmlloyd> baileyje: http://github.com/dmlloyd/jboss-as/commit/487a5e8
[19:10:07] <jbossbot> git [jboss-as] 487a5e8.. David M. Lloyd Make Component non-generic
[19:10:14] <dmlloyd> became somewhat more far-reaching than I expected
[19:10:27] <dmlloyd> let me know if you see anything dumb in there
[19:10:30] <baileyje> dmlloyd: crap.  I already did that.
[19:10:32] <dmlloyd> haha
[19:10:41] <baileyje> But that is ok since I lied to you and said I wasn't touching it
[19:10:42] <dmlloyd> okay, I can toss this no prob
[19:10:44] <baileyje> I already forgot.
[19:10:48] <baileyje> I will toss mine.
[19:10:51] <dmlloyd> okay.
[19:11:24] *** smcgowan has quit IRC
[19:11:48] <baileyje> dmlloyd: Looks correct to me
[19:13:35] <dmlloyd> ok I'll start with pushing this then
[19:13:43] <jbossbot> git [jboss-as] push master be69758.. John E. Bailey Break the component install process into multiple processors.  Also utilize the component config for attaching required configs
[19:13:43] <jbossbot> git [jboss-as] push master 487a5e8.. David M. Lloyd Make Component non-generic
[19:13:43] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c8bdc7c...487a5e8
[19:13:46] <dmlloyd> I get less sure of things from here
[19:14:01] <dmlloyd> hmm I thought I had pushed that other one sooner
[19:14:03] <dmlloyd> oh well!
[19:14:58] *** jpederse has joined #jboss-as7
[19:15:07] *** jpederse has joined #jboss-as7
[19:17:57] *** smcgowan has joined #jboss-as7
[19:17:57] *** ChanServ sets mode: +v smcgowan
[19:18:50] *** bstansberry has quit IRC
[19:24:09] *** smcgowan has quit IRC
[19:25:11] <dmlloyd> we need a way to decide which instance we're getting back
[19:25:27] <dmlloyd> i.e. a generic way to resolve the session
[19:25:50] *** smcgowan has joined #jboss-as7
[19:25:50] *** ChanServ sets mode: +v smcgowan
[19:29:03] <dmlloyd> wolfc: if I get two proxies for a SFSB does that mean I get two instances, even if I'm calling from the same caller?
[19:29:09] <dmlloyd> I mean looking them up
[19:29:16] <dmlloyd> or are they two proxies to the same instance
[19:29:17] <wolfc> yes, two lookups = two instances
[19:29:35] <dmlloyd> okay, so that makes it simpler then
[19:29:41] <wolfc> be aware of a fine detail: injection does 1 lookup and multiple injects
[19:29:57] <dmlloyd> right, so for injection the proxy is shared
[19:30:12] <dmlloyd> that's consistent with what we were talking about the other day about interceptors
[19:30:16] <wolfc> yes
[19:40:10] *** emmanuel has quit IRC
[19:40:22] <dmlloyd> one more question, wolfc.  When we have e.g. a SLSB which is pooled, are we keeping the interceptors/injections/etc around or do they have to be recreated every time the instance is unpooled?
[19:40:52] <wolfc> everything is part of the EJB instance
[19:41:09] <dmlloyd> ok so they share lifecycle with it?
[19:41:14] <wolfc> yes
[19:41:22] <dmlloyd> ok excellent, this is coming together.
[19:41:43] *** darranl has quit IRC
[19:41:53] <wolfc> the same goes for a MB instance
[19:42:24] <dmlloyd> yeah.  though MB has that unbounded lifecycle issue :)
[19:42:42] <wolfc> we need a destroy mechanism for it anyway
[19:42:57] <dmlloyd> yeah.  or we need to keep the instances around forever!
[19:43:32] <wolfc> well StatelessSessionComponent needs to be undeployable
[19:43:46] <dmlloyd> yeah that makes sense
[19:48:59] *** bstansberry has joined #jboss-as7
[19:48:59] *** ChanServ sets mode: +v bstansberry
[19:49:00] <dmlloyd> baileyje, to represent an instance plus interceptors I think an Interceptor or (InvocationContext) is probably appropriate.
[19:49:12] <dmlloyd> so really we'd be pooling that rather than just the instance itself
[19:52:25] *** jeand has joined #jboss-as7
[19:52:41] <wolfc> InvocationContext is too invocation-y
[19:52:51] <baileyje> dmlloyd: I think I missed some context on that,
[19:52:57] <wolfc> EJB has an easy way out. We got EJBContext :-)
[19:53:12] <dmlloyd> baileyje: well the lifecycle of the instance equals the lifecycle of the interceptors and injections, right?
[19:53:23] <baileyje> Correct
[19:53:29] <dmlloyd> baileyje: the injections are taken care of when the instance is created
[19:53:40] <dmlloyd> baileyje: but, the interceptor chains are not.
[19:54:04] <dmlloyd> so when an instance is returned (to be possible repooled) we're losing that.
[19:54:30] <dmlloyd> so we should be pooling an Interceptor, which includes the instance *and* all the interceptors.
[19:54:41] <baileyje> dmlloyd: They could be.  They are being created when they are first needed by an intercerceptor.
[19:54:53] <dmlloyd> Interceptor wears its InvocationDispatcher hat in this case.
[19:54:55] <baileyje> dmlloyd: That is mainly what ComponentInstanceInterceptor does
[19:55:17] <dmlloyd> sure but who is holding on to those interceptors?
[19:55:37] <baileyje> That basically asks for an instance  holds onto it along with a the chains
[19:55:52] <dmlloyd> okay so that's happening outside of the Component though
[19:55:58] <baileyje> dmlloyd: Yeah
[19:56:02] <baileyje> In that interceptor.
[19:56:07] <baileyje> But it could happen in the component.
[19:56:15] <dmlloyd> but since the interceptors have to live and die with the instance, it needs to move to the component.
[19:56:25] <dmlloyd> okay, so I think that's where I'm going to go with this.
[19:56:37] <dmlloyd> there's another angle to this
[19:56:44] <baileyje> I guess it is the dying part you are worried about
[19:57:06] <dmlloyd> when I do remote invocations, I'm not getting a proxy from the component; instead I'm going right into the guts, directly into the Interceptor.
[19:57:13] <dmlloyd> the proxy exists on the client end.
[19:57:20] *** alesj has joined #jboss-as7
[19:57:28] <dmlloyd> so this way I can use the same API to get my Interceptor plug for remote invocation.
[19:57:51] <baileyje> dmlloyd: Yeah..
[19:57:52] <dmlloyd> then createProxy() is just a handy convenience for local & in-VM remote invocations.
[19:58:20] <dmlloyd> I think we might want a way to snag a (serializable) client interceptor chain though, for remote clients.
[19:58:29] <dmlloyd> but I think it all fits in what you've layed out.
[19:58:33] <dmlloyd> laid out
[20:00:54] <dmlloyd> wolfc: okay I lied, one more dumb question.  I think I know the answer already though, but I want to be sure.  When an EJB is passivated, all its injected stuff and interceptors are passivated too right?
[20:01:15] <dmlloyd> so ideally re-activation amounts to just deserializing it in the right context
[20:01:21] <wolfc> yes
[20:01:23] <dmlloyd> and everything just springs to life
[20:01:45] <wolfc> everything injectable must be aware of serialization requirements
[20:02:07] <wolfc> while basically nothing implements Serializable :-)
[20:02:15] <dmlloyd> yeah.
[20:07:56] *** slaboure has joined #jboss-as7
[20:10:57] *** ccrouch has joined #jboss-as7
[20:10:58] *** ChanServ sets mode: +v ccrouch
[20:11:14] *** mbg|away is now known as mbg
[20:13:33] *** ccrouch1 has quit IRC
[20:14:14] *** torben has quit IRC
[20:16:24] *** aslak has quit IRC
[20:16:29] *** aslak has joined #jboss-as7
[20:16:29] *** ChanServ sets mode: +v aslak
[20:22:51] <dmlloyd> baileyje: http://github.com/dmlloyd/jboss-as/commit/5e88ab6 <- what do you think about this concept?
[20:22:51] <jbossbot> git [jboss-as] 5e88ab6.. David M. Lloyd DEMO ONLY - DO NOT PUSH.  New ComponentInstance API
[20:23:01] <dmlloyd> I think it covers everything
[20:24:22] <baileyje> dmlloyd: It looks like it covers it
[20:24:57] <dmlloyd> ok I'm going to do some minimal work to integrate it and get it in there
[20:25:07] <dmlloyd> would have been done sooner if it weren't for these meddling kids
[20:25:32] *** stuartdouglas has quit IRC
[20:25:32] *** stuartdouglas has joined #jboss-as7
[20:26:20] <dmlloyd> crap, I think I broke the build
[20:26:23] <dmlloyd> how did that even happen
[20:26:30] <dmlloyd> ah! forgot to clean
[20:26:37] <dmlloyd> I'm bad at this
[20:28:59] <wolfc> divide and conquer. Luckily we have git and a fast build now. :-)
[20:29:28] <alesj> baileyje, dmlloyd: I see sar also has _java in test dir
[20:29:40] <alesj> i guess we should just port the test to Arq at one point
[20:29:49] <alesj> i mean, sar and mc tests
[20:34:49] <jbossbot> git [jboss-as] push master 9cd07a2.. David M. Lloyd Fix broken managed beans
[20:34:49] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/487a5e8...9cd07a2
[20:40:41] <dmlloyd> you could say, I "managed" to break it
[20:42:58] *** pferraro has quit IRC
[20:43:18] *** asoldano_dinner is now known as asoldano
[20:45:52] <alesj> dmlloyd: ah, no wonder you broke it, managed has _java as well
[20:45:54] <alesj> ;-)
[20:45:58] <dmlloyd> ha
[20:46:14] <alesj> looks like the way to do testing in as7 is to have _java :-)
[20:57:32] *** slaboure has quit IRC
[20:58:09] *** bstansberry is now known as bstans_afk
[20:58:49] *** smcgowan has quit IRC
[20:59:08] *** alesj has left #jboss-as7
[20:59:11] *** alesj has quit IRC
[21:05:04] *** pferraro has joined #jboss-as7
[21:05:05] *** ChanServ sets mode: +v pferraro
[21:08:40] <mbg> baileyje: ping
[21:08:53] <baileyje> mbg:  pong
[21:10:00] <dmlloyd> looks like we need a mapping of methods for remote invocations (including in-VM).  I'm thinking a Map<MethodIdentifier, Method> would suffice... now where to put it...
[21:10:28] <nickarls> BTW are the smoke tests supposed to pass currently?
[21:10:52] <mbg> baileyje: when you have time - I made a few changes to jbossinterceptors - please take a look at https://github.com/mbogoevici/jbossinterceptors/commits/rebased/ - and let me know if that makes things better or worse
[21:12:53] *** asoldano is now known as asoldano_away
[21:14:39] <dmlloyd> wolfc: when you wake up, hopefully you'll read scrollback :)  Do local views need to use the system interceptors like TXN and security, since they're used from within the same context?
[21:20:54] *** smcgowan has joined #jboss-as7
[21:20:55] *** ChanServ sets mode: +v smcgowan
[21:31:51] <smcgowan> mpg, not sure is you saw my earlier but the CDI API version in AS 7 currently is 1.0-SP1.  need 1.0-SP4 with weld 1.1.0.Final.  i'm preparing a patch to update all EE apis - FYI
[21:32:35] *** mmoyses has quit IRC
[21:32:43] <dmlloyd> on that topic, smcgowan, I did some changes to javax.invocation - just javadoc rewriting and reformatting, but thought you should know
[21:32:47] <dmlloyd> er
[21:32:48] <smcgowan> mbg ^^
[21:32:51] <dmlloyd> javax.interceptors
[21:32:57] * dmlloyd has invocation on the brain
[21:33:14] <smcgowan> interceptors,  sure, thanks for the update
[21:33:25] * mbg thinks dmlloyd is planning a Java Invocation JSR'
[21:33:26] <dmlloyd> anyway I'm thinknig of some far-off-day when we actually have aggregated javadocs :)
[21:34:05] *** bstans_afk is now known as bstansberry
[21:34:21] <smcgowan> dmlloyd:  for the most part the version of the APIs went from beta to Final so it should be OK but CDI and EJB3 need the Final versions
[21:34:33] <smcgowan> i think i have the "aggregated JavaDoc" JIRA on my list
[21:34:38] <mbg> smcgowan: anything I can do to help? stuartdouglas owns CDI/Weld integration in AS7
[21:34:51] <bstansberry> kkhan: fyi, the FS deployment scanner is now working in detyped2, and the persistence of the config file following changes is turned on
[21:35:01] <kkhan> Cool
[21:35:02] <dmlloyd> "aggravated JavaDoc" more like
[21:35:06] <smcgowan> mbg:  no, just wanted you to know as i there is an API change between SP1 and SP4
[21:35:50] <smcgowan> i'm filing a JBAS JIRA to track
[21:36:02] *** asoldano_away is now known as asoldano_otp
[21:36:30] <mbg> smcgowan: thanks
[21:37:12] <smcgowan> bstansberry:  is there a good time that we can discuss deployment and the TCK - i've started a discussion with emanuel but he mentioned we might want to speak with you
[21:37:36] <bstansberry> any time
[21:37:42] <smcgowan> this discussion should include the cdi and beanvalidation tck as the're runners need to change too
[21:38:03] <smcgowan> bstansberry:  in short, what is the JSR-88 equivalent
[21:38:34] <mbg> Nihility dmlloyd: is there a status page for AS7 - I'd like to know what is supported and not ATM
[21:38:59] <smcgowan> when I refer to a "deployment plan", it is content that I want to add to my "EE" deployment but not repackage the archive
[21:39:04] <Nihility> no status page
[21:39:13] <bstansberry> do you need JSR-88 or just a deployment API?
[21:39:33] <mbg> Nihility: thx
[21:39:37] <Nihility> i have been thinking about doing one
[21:39:57] <smcgowan> bstansberry:  i want to be able to use the recommended programmatic deployment for AS 7 but need similar functionality to what JSR-88 impl had provided
[21:40:17] <smcgowan> such as DeploymentStatus
[21:41:06] <smcgowan> bstansberry:  i started this doc: https://docspace.corp.redhat.com/docs/DOC-56154
[21:41:34] * bstansberry reads
[21:44:23] <smcgowan> bstansberry:  with adjustments to the the runners for CDI and bean validation tck, i'd like to use the same mechanism - if possible
[21:45:27] <bstansberry> smcgowan: please clarify 'passing in runtime deployment descriptors via the "deployment plan".'
[21:45:50] <bstansberry> you want to be able to modify the content of existing deployment by passing in changed deployment descriptors?
[21:46:28] <smcgowan> bstansberry:  we read the runtime descriptor information from the ones provided with the tck and transform them to jboss-specific descritpros, we need to pass that with the deployment
[21:47:05] <smcgowan> JSR-88 refers to that as the "deployment plan"
[21:47:08] *** maeste_afk has quit IRC
[21:47:27] <smcgowan> See #4 in the referenced document
[21:50:35] <smcgowan> i'm not sure if my definition - or context  -of "deployment plan" is in sync with yours - which i realized after speaking with emuckenhuber a bit last night
[21:51:06] <bstansberry> smcgowan: I'll have to think about this a bit. We have no notion of deployment descriptors being passed in external to their archive
[21:51:19] <bstansberry> yes, for sure "deployment plan" is an overloaded term here :)
[21:52:01] <smcgowan> bstansberry:  for the sake of "overloading" you with too much info, i'm giong to send you an email about a brief discussion on deployement with other TCKs between me,pete, ales, hardy
[21:52:15] <bstansberry> :)
[21:54:01] <smcgowan> bstansberry: and for the configuration - it's intended to be standalone,but would like to add the configuration resources dynamically during set up
[21:54:45] <baileyje>  dmlloyd https://github.com/baileyje/jboss-as/commit/640e0071df2be3016d13569463b43f269ab295e7
[21:54:47] <jbossbot> git [jboss-as] 640e007.. John E. Bailey Remove the use of attachments and intermediate constructed objects when building components
[21:56:20] *** mbg has quit IRC
[21:56:24] <dmlloyd> looks good.
[21:57:09] <dmlloyd> no conflicts with my stuff either!
[21:57:10] <dmlloyd> nice
[21:57:17] <baileyje> sweet.
[21:57:23] <dmlloyd> must be doing something right
[21:57:23] <Nihility> awesome
[21:57:25] <Nihility> :)
[21:58:37] <dmlloyd> hey stuartdouglas, do your proxies cache permanent Method objects for the invocation handler?
[21:58:44] <stuartdouglas> yes
[21:59:02] <stuartdouglas> They are loaded in the classes static contructor
[21:59:03] <dmlloyd> okay, neat, so I could use an identity map then to quickly locate equivalent methods
[21:59:18] <dmlloyd> is there any way to access that set of objects?
[21:59:22] <dmlloyd> Method objects I mean
[21:59:32] *** kkhan has quit IRC
[21:59:38] <stuartdouglas> not without using reflection
[21:59:45] <dmlloyd> hm, maybe I could just populate the map lazily
[22:00:00] *** kkhan has joined #jboss-as7
[22:00:00] *** ChanServ sets mode: +v kkhan
[22:00:13] <stuartdouglas> At the moment the proxies have no class loading requirements except for InvocationHandler
[22:00:30] <stuartdouglas> which is great in terms of no class loading issues
[22:00:34] <dmlloyd> yeah
[22:01:01] <stuartdouglas> but it means there is proxy interface that you can cast all the proxies to
[22:01:35] <dmlloyd> it also means that that interface has to be on every class loader with a proxy, though.
[22:01:43] <stuartdouglas> yes
[22:01:45] <smcgowan> bstansberry:  found this: http://community.jboss.org/wiki/JSR88Client
[22:01:50] <dmlloyd> which is not to big a deal really.
[22:02:07] <stuartdouglas> sorry, currently there is no proxy interface that you can cast to
[22:02:21] <stuartdouglas> I could easily create a sub class that had one though
[22:02:32] <dmlloyd> ah, well we don't need that at the moment.
[22:03:23] *** maeste_afk has joined #jboss-as7
[22:03:54] <dmlloyd> maybe what I'll do is create a proxy factory subclass which accepts a component and creates the target map, and maybe does some of the interceptor work right up front
[22:04:10] <dmlloyd> just need to think about it a little bit more
[22:06:33] <baileyje> dmlloyd: Sounds good
[22:06:52] <baileyje> I have to run and pick up some stuff from the eye doctor.  I will be back in 30
[22:07:14] <dmlloyd> okay
[22:16:05] *** frainone has quit IRC
[22:16:57] *** kkhan has quit IRC
[22:25:33] *** tdiesler has joined #jboss-as7
[22:25:33] *** ChanServ sets mode: +v tdiesler
[22:28:22] <wolfc> dmlloyd, yes local (/all) views need to go through system interceptors.
[22:29:26] *** emuckenhuber has joined #jboss-as7
[22:29:26] *** emuckenhuber has joined #jboss-as7
[22:29:26] *** ChanServ sets mode: +v emuckenhuber
[22:30:31] *** wolfc has quit IRC
[22:36:01] <baileyje> dmlloyd: Back.  How is it going?
[22:36:51] *** jpederse has quit IRC
[22:37:56] <dmlloyd> baileyje: OK.  I think I'm going to push a midway-commit here.  There's still some holes to fill for system interceptor stuff for EJB but MBs should work...
[22:38:48] <baileyje> dmlloyd: sounds good.
[22:39:08] <baileyje> Nihility: Just a heads up.  I will be on PTO on Friday and monday
[22:39:42] <baileyje> dmlloyd: Also.  I fixed the MB demo, so you can use it to test the local proxies at least
[22:39:56] <Nihility> baileyje: cool, when you get back we will have rewritten all your work
[22:39:57] <dmlloyd> ok cool
[22:40:04] <dmlloyd> then I'll know if I screwed it up
[22:40:15] *** epbernard has joined #jboss-as7
[22:40:15] *** epbernard is now known as emmanuel
[22:40:15] *** ChanServ sets mode: +v emmanuel
[22:40:19] <Nihility> baileyje: kidding have a good time
[22:40:39] <baileyje> Nihility: I am used to it :)
[22:41:18] <baileyje> Yeah.  Heading to Mexico for a long weekend.  My wife's companies treat.  :)
[22:41:43] <Nihility> dont forget to bring your notebook
[22:42:05] <baileyje> Notebook, ipad, kindle, iphone.  Should be set
[22:42:07] <Nihility> that way you can login on the beach
[22:42:12] <Nihility> and be like
[22:42:24] <Nihility> "hey hows the snow? im looking at the ocean"
[22:42:46] <Nihility> and we can all cry
[22:44:12] <baileyje> for sure
[22:44:25] <baileyje> Do a video chat
[22:45:01] <Nihility> haha
[22:45:12] <Nihility> im assuming you are going to be at the coast
[22:45:16] *** jpederse has joined #jboss-as7
[22:45:17] <dmlloyd> yeah I'll stand out in the blizzard and you can stand on the beach
[22:49:08] *** jfclere has joined #jboss-as7
[22:50:35] *** jpederse has quit IRC
[22:51:22] *** emmanuel has quit IRC
[22:52:45] *** jpederse has joined #jboss-as7
[22:59:59] *** miclorb has joined #jboss-as7
[23:00:31] <baileyje> dmlloyd: Ok.  What is next?
[23:01:01] <dmlloyd> ok so once I figure out why I'm getting a compile error on the CLI and not in the IDE...
[23:01:21] <dmlloyd> I'll be exploring the remote interface and system interceptor business
[23:01:48] <dmlloyd> I think we should look at moving to a multiple-chain approach for method interceptions
[23:02:02] <dmlloyd> because when an invocation comes in it could be for any method
[23:02:16] <dmlloyd> so the first interceptor has to determine which method is being called, then call the chain for the method
[23:02:30] <dmlloyd> which includes default/class/method interceptors like we talked about
[23:07:43] <dmlloyd> anyway the idea would be that each component instance has two Interceptor instances on it, one for default and one for class
[23:08:15] <dmlloyd> then there'd be like a table of Method->Interceptor where the Interceptor calls (if necessary) the default then class interceptors, then the method interceptors (if any)
[23:08:23] <dmlloyd> not too different from what's already there tbh
[23:08:30] <dmlloyd> just no need for the filter construct
[23:08:33] *** asoldano_otp has quit IRC
[23:08:37] <dmlloyd> I guess is what I'm getting at :)
[23:09:07] *** jeand has quit IRC
[23:09:21] <dmlloyd> ah, figured out the compile problem
[23:09:25] <dmlloyd> mvn clean... again
[23:09:36] <dmlloyd> guess I'm not adjusted to the wake-at-4:30am lifestyle yet
[23:10:31] <baileyje> wow.  Not sure I know how to even breath at that time
[23:12:49] <dmlloyd> we're going to need to think about that two-phase start for components too
[23:12:55] <dmlloyd> (compiling...)
[23:13:05] <dmlloyd> and the component service namespace stuff
[23:13:54] *** maeste_afk has quit IRC
[23:14:58] <baileyje> What are you thinking?
[23:15:50] <dmlloyd> jboss.ee.comp.<app>.<module>.<comp> ?
[23:16:15] <dmlloyd> wow, I really broke something!
[23:16:21] <baileyje> Yeah.  That certainly can be cleaned up.
[23:17:59] *** smcgowan has quit IRC
[23:18:45] *** jpederse has quit IRC
[23:19:17] <baileyje> what did you break?
[23:24:15] *** bstansberry is now known as bstans_snow
[23:24:21] <dmlloyd> think just something with instances
[23:25:03] <dmlloyd> because I changed getInstance but a lot of things still used it as an Object... havoc ensued
[23:25:23] <dmlloyd> though now I seem to be having some JNDI problem
[23:25:29] <dmlloyd> which is weird, I didn't really touch that stuff
[23:27:05] <baileyje> DId you somehow disable the namespace selector interceptor?
[23:27:36] <dmlloyd> ah that could be
[23:32:22] *** jfclere has quit IRC
[23:32:37] *** aloubyansky has quit IRC
[23:43:05] <baileyje>  dmlloyd:  Let me know if you need me to help you dig through my mess :)
[23:43:19] <dmlloyd> I think I must have deleted some method call
[23:43:24] <dmlloyd> I thought I understood this all the way
[23:43:28] <dmlloyd> I'm looking thru the diff now
[23:49:27] <dmlloyd> http://github.com/dmlloyd/jboss-as/commit/3ae5ec06acc01c
[23:49:28] <jbossbot> git [jboss-as] 3ae5ec0.. David M. Lloyd DEMO ONLY - DO NOT PUSH.  New ComponentInstance API
[23:49:32] <dmlloyd> do you see anything I'm missing here
[23:49:37] <dmlloyd> deployment gets this excpetion:
[23:49:58] <dmlloyd> http://fpaste.org/yVNY/
[23:50:55] <baileyje> my guess is the injections are not getting applied
[23:51:16] <dmlloyd> hmm, maybe I shorted out that code path without noticing
[23:51:18] <baileyje> I see you calling them..
[23:52:45] <baileyje> dmlloyd: Hmm..  Seems like that change couldn't have caused it.
[23:52:49] <baileyje> Let me check something
[23:54:47] <baileyje> dmlloyd: I wonder if my demo change actually has a race condition.
[23:55:01] <baileyje> That you are seeing on linux
[23:55:40] <baileyje> hmmmm
[23:56:14] <dmlloyd> that'd be wacky.
[23:56:17] <dmlloyd> does this code work for you?
[23:56:25] <stuartdouglas> Just a random thought, but is the TCCL set up correctly?
[23:56:25] <baileyje> Yours or mine?
[23:56:36] <dmlloyd> all of it together, baileyje
[23:56:43] <dmlloyd> let me confine it to one CPU and see what happens
[23:56:48] <baileyje> dmlloyd: haven't tired it yet
[23:57:25] <dmlloyd> JBoss AS 7.0.0.Alpha2 "Halloween" started in 4073ms, lol
[23:57:32] <dmlloyd> guess one CPU makes it go slower
[23:57:34] *** pferraro has quit IRC
[23:57:44] <stuartdouglas> actually, the TCCL being wrong would not cause that error
[23:58:36] <baileyje> stuartdouglas: I could.  Depends on what is causing the name not found to be thrown
[23:59:03] *** ccrouch1 has joined #jboss-as7
[23:59:04] *** ChanServ sets mode: +v ccrouch1

   February 1, 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 | >