[00:00:05] *** smarlow has quit IRC
[00:00:20] *** jpearlin has joined #jboss-as7
[00:05:02] *** pferraro has joined #jboss-as7
[00:05:02] *** ChanServ sets mode: +v pferraro
[00:06:53] <stuartdouglas> Nihility: smcgowan_dinner I have resteasy fixed in my master
[00:07:08] <stuartdouglas> I have also made the isolated modules by default change that we talked about
[00:07:34] <stuartdouglas> after those changes the JAX-RS TCK passes 100%
[00:09:21] <jamezp> dmlloyd: I think this is the issue with the start-up http://fpaste.org/oKh0/. Might want to double check, but it looks like if attribute.name.uri is null, -1 is returned.
[00:10:18] <jamezp> dmlloyd: That snippet is from org.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl and attribute is a javax.xml.namespace.QName
[00:11:15] <dmlloyd> ah interesting
[00:11:19] <dmlloyd> Nihility: ^^^
[00:11:32] <dmlloyd> that may be the issue with old openJDKs
[00:11:46] <dmlloyd> the runtime one, not the compile-time one
[00:11:46] <jamezp> What I'm not sure about is what creates the QName. If it's a JBoss library or a JVM library. Either way, the name.uri is null.
[00:12:05] <dmlloyd> we use stax quite a lot
[00:12:06] <jamezp> That's my feeling since it seems to work on 1.6.0_20.
[00:12:27] <stuartdouglas> Nihility: There are a few dodgy looking services="export" in my changes, by I can't see any way around them
[00:12:29] <stuartdouglas> cause of JBAS-9129
[00:12:31] <jbossbot> jira [JBAS-9129] If a JAX-RS is bundled it can break JAX-RS for other deployments [Open (Unresolved) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9129
[00:12:59] <jamezp> dmlloyd: I saw that and I didn't see any reason it was a fault of stax.
[00:13:01] <ccrouch1> do you folks have a hudson job somewhere building as7 binaries from the latest in master branch?
[00:13:07] <stuartdouglas> basically if you have access to the JAX-RS api you also must have access to resteasy's services
[00:13:27] <dmlloyd> jamezp: well org.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl is a stax implementation class
[00:14:53] <jamezp> dmlloyd: I guess I assumed be cause I saw the name it wasn't.
[00:15:18] <dmlloyd> stuartdouglas, jax-rs should be filtered
[00:15:20] <dmlloyd> imo
[00:15:24] <dmlloyd> from deployments I Mean
[00:16:16] <dmlloyd> stuartdouglas, we can and probably should customize our JAXRS API JAR to not use the TCCL
[00:16:25] <jamezp> Wait, I lied. That snippet is from com.sun.org.apache.exces.internal.util.XMLAttributesImpl
[00:16:27] <dmlloyd> like how alessio customized jax-rs
[00:16:31] <dmlloyd> er jax-ws
[00:17:11] <dmlloyd> jamezp: ah okay, then I'm not sure.
[00:17:34] <jamezp> dmlloyd: Sorry had the mouse over the wrong tab :-)
[00:17:43] <dmlloyd> jamezp: you'd have to look at a stack trace I guess, to see what is using it and why it's screwing up.
[00:18:15] <stuartdouglas> dmlloyd: ok, that is the route I will go down to try and solve the issue
[00:18:47] <dmlloyd> stuartdouglas: this seems like a good argument to use the spec jax-rs JAR instead of the one we are using which comes from... somewhere else
[00:19:13] <jamezp> dmlloyd: Will do. I'll fire up VisualVM and see what I can find.
[00:20:57] <stuartdouglas> no, we are using the spec API's, not the resteasy ones
[00:44:51] *** rmaucher has quit IRC
[00:56:06] *** mbg|away is now known as mbg
[00:58:58] *** pferraro has quit IRC
[00:59:06] *** frainone has joined #jboss-as7
[00:59:07] *** ChanServ sets mode: +v frainone
[01:00:50] <Nihility> Yes we are going to be doing lots of framework patching
[01:00:58] <Nihility> Wrt TCCL
[01:02:37] <stuartdouglas> that can probably wait for a later beta though, as I have worked around it for now
[01:05:34] <Nihility> jamezp: Try adding woodstox to the jaxp provider module
[01:06:36] <Nihility> jpearlin: Btw I applied fixes to base64 you may want to look at
[01:06:54] <jamezp> Nihility: I'll check that out. Thanks.
[01:08:04] <Nihility> dmlloyd: If it's stax we may have found our reason to switch to woodstox
[01:08:23] <jpearlin> ok...I'll take a look...is this the result of Heiko's issues?
[01:10:14] <stuartdouglas> Nihility: dmlloyd would one of you be able to merge my master?
[01:10:23] <Nihility> jpearlin: Heiko was still using the old base64 version, his problem was just that old flush impl. I did the patches to your version when I was testing it out more thoroughly
[01:11:52] <Nihility> jpearlin: two problems were not handling stream underflow like you already mentioned and also decoding always wrote out 3 byte multiples no matter what
[01:12:19] <jpearlin> yeah...the first problem was largely due to the fact that I had no idea how we were actually going to use it at the time of writing it
[01:12:36] <jpearlin> it was only after I dug into Heiko's issue (not knowing it was the old impl) that I realized we had that issue
[01:12:57] <jpearlin> so, it looks like it is really only one change (and the fallout from that change) to read 3 or less bytes
[01:13:10] <jpearlin> depending on what is requested
[01:13:46] <Nihility> so like if the file being encoded wasn't a multiple of 3 it would get extra bytes tack on
[01:14:17] <jpearlin> im not so sure about that, because it did have the padding
[01:14:49] <Nihility> stuartdouglas: I can look at that in about 20 mins
[01:14:55] <stuartdouglas> ok
[01:15:16] <jpearlin> although, its certainly possible there was a bug in there...the original intent was to read 3 at a time, and if less than 3, assume the end and pad
[01:15:48] <Nihility> jpearlin: Only streams where affected. Because they alwaysnused the length of the output buffer, the decoding bit never passed back the actual output,
[01:15:49] <jpearlin> Nihility:  the real issue would be if the data coming in was streaming in and we were not guaranteed to get a full block
[01:15:52] <jpearlin> yeah
[01:16:18] <jpearlin> right...and I guess I wasn't thinking about streams when I wrote it...only full buffers of data waiting to be encoded...sorry about that
[01:18:05] <Nihility> It was no big deal to fix it, although it probably needs a bit more abuse before switching to it just to make sure everything is ok
[01:18:25] <jpearlin> yeah...when I finish the tests for the upload stuff, I can write some more integration like tests
[01:18:28] <jpearlin> to feed it random streams
[01:19:01] <Nihility> I just dead it classes.jar :)
[01:19:15] <Nihility> And compared the output with perl's module
[01:19:51] <Nihility> Feed
[01:19:56] <Nihility> not dead
[01:20:48] <Nihility> Bbiab guys
[01:20:53] <jpearlin> sure...but I would think we would want something a little more robust for a test
[01:21:07] <jpearlin> streams with multiple pauses of data, etc
[01:22:09] *** pferraro has joined #jboss-as7
[01:22:09] *** ChanServ sets mode: +v pferraro
[01:24:12] *** pferraro has left #jboss-as7
[01:28:05] <dmlloyd> Nihility: yeah we knew that it was at least possible for the JDK to screw up.
[01:30:29] *** jpearlin has left #jboss-as7
[01:35:35] *** smcgowan_dinner has quit IRC
[01:37:33] *** jpearlin has joined #jboss-as7
[01:50:46] *** smcgowan has joined #jboss-as7
[01:50:47] *** ChanServ sets mode: +v smcgowan
[01:59:38] <Nihility> stuartdouglas: wow war annotaiton parsing is really early now
[02:00:18] <stuartdouglas> is that a problem? I needed it to go before jax-rs so I moved it next to the other war parsing
[02:00:38] <Nihility> no just commenting
[02:01:56] <stuartdouglas> it's kind of a pity that we can't just let processors express a dep on other processors and then sort out the order programatically
[02:07:11] *** bstans_afk has quit IRC
[02:12:22] <Nihility> thats how 5 and 6 did it
[02:12:34] <Nihility> i actually like this way better
[02:12:41] <Nihility> i can easily see all processors
[02:12:45] <Nihility> and their order
[02:13:00] <Nihility> (and its fast)
[02:13:17] <jpearlin> Nihility:  what is more important at this point:  testing and finding the edges on the base64 stuff or the integration tests for the upload stuff?
[02:14:01] <jbossbot> git [jboss-as] push master 70fb14a.. Stuart Douglas Isolate sub deployments by default
[02:14:02] <jbossbot> git [jboss-as] push master e1f7ec7.. Stuart Douglas Update weld to reflect the new class loading visibility rules
[02:14:02] <jbossbot> git [jboss-as] push master 6f6832d.. Stuart Douglas Fix classloading problem with JAX-RS...
[02:14:02] <jbossbot> git [jboss-as] push master 77a3af8.. Stuart Douglas Make JAX-RS integration more spec compliant
[02:14:02] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/bf4b43c...77a3af8
[02:14:26] *** jamezp has left #jboss-as7
[02:14:29] <Nihility> jpearlin: probably the latter
[02:14:42] <stuartdouglas> cool, now we should pass the jax-rs TCK
[02:14:52] <Nihility> awesome thanks
[02:14:52] <jpearlin> ok...I'll keep plugging away on that for now...I think I have something if I can figure out why the http server is throwing oom
[02:15:51] *** aslak has quit IRC
[02:28:09] *** rawbdor has quit IRC
[02:36:30] *** jwulf has joined #jboss-as7
[02:45:21] <Nihility> stuartdouglas: im having some issues after that isolation path
[02:45:23] <Nihility> patch
[02:46:52] <stuartdouglas> what sort of issues?
[02:47:18] <Nihility> so this deployment has a problem where it refers to an exception class in an ejb jar from a war
[02:47:27] <Nihility> i went to workaround it by adding:
[02:47:35] <Nihility> Class-Path: OrderManagerEJB.jar
[02:47:42] <Nihility> this doesnt seem to work though
[02:47:47] <Nihility> i havent debugged why
[02:47:49] <stuartdouglas> odd, it should
[02:48:03] <Nihility> perhaps its because its an ejb
[02:48:09] <Nihility> and ejbs dont export everything?
[02:48:38] <stuartdouglas> there is actually an integration test for this
[02:48:43] <stuartdouglas> between two EJB jars
[02:48:51] <Nihility> oh really hmm interesting
[02:48:59] <stuartdouglas> I will do up a test with a war
[02:49:06] <Nihility> this is an an ear though
[02:49:15] <stuartdouglas> two ejb jars in an ear
[02:49:23] <Nihility> ah
[02:49:32] <stuartdouglas> I will add a test for war referencing ejb jar in ear
[02:49:56] <stuartdouglas> the entry is in META-INF/MANIFEST.MF? not W-I/classes/M-I ?
[02:50:08] <Nihility> correct
[02:50:41] <Nihility> oh btw interesting discussion on the EE eg about that problem
[02:51:22] <Nihility> basically a number of folks thought that W-I/class/M-I should be treated as a nested jar
[02:51:29] <stuartdouglas> to be honest I am not sure if we should default to isolated, we could provide it as an option
[02:51:47] <stuartdouglas> so we should still process it ?
[02:51:59] <Nihility> well there was no verdict
[02:52:05] <Nihility> but we have to process some things there
[02:52:11] <Nihility> like JPA descriptors
[02:52:17] <Nihility> and BV descriptors
[02:52:47] <Nihility> we must proces WAR/META-INF though
[02:53:23] <Nihility> i think we should try isolated by default and see how much the users hate it
[02:53:23] <stuartdouglas> we do at the moment
[02:53:24] <Nihility> haha
[02:53:42] <Nihility> it should be an option though i think
[02:54:00] <Nihility> ok if you want to dig into that
[02:54:07] <Nihility> i will just flip it back to on for now
[02:54:14] <Nihility> (in my tree)
[02:54:29] *** jamezp has joined #jboss-as7
[02:56:52] <Nihility> dmlloyd: you agree to making some kind of ee option for that
[02:57:59] <Nihility> im not sure what to call the option though
[02:58:23] <stuartdouglas> Nihility: I am seeing the issue in a test I just made up, I will debug it
[02:58:39] <Nihility> cool
[03:00:49] <dmlloyd> I dunno, seems like it should be consistent with other containers
[03:01:21] <dmlloyd> there's an argument to be made that we should at least make it possible for things to behave similarly to previous versions though
[03:02:38] <Nihility> cool i fixed the exploded issue
[03:03:03] <Nihility> and now we have jndi not working for these ejbs
[03:03:45] *** smarlow has joined #jboss-as7
[03:03:45] *** ChanServ sets mode: +v smarlow
[03:05:41] *** jwulf has quit IRC
[03:05:48] <Nihility> smarlow: you wouldnt happen to know where the source is to andy's order app benchmark would you?
[03:06:24] <smarlow> Nihility:  No idea, let me take a look at it and see if it rings a bell
[03:07:37] <Nihility> dmlloyd: hmmm
[03:08:51] <stuartdouglas> hmm, in the debugger I am not seeing the war deployment even hit the class path processor
[03:08:53] <stuartdouglas> very weird
[03:09:21] <Nihility> dmlloyd: check out this code
[03:10:23] <Nihility> http://fpaste.org/0XOB/
[03:13:57] <dmlloyd> is that supposed to work, somehow?
[03:14:12] <dmlloyd> I mean is the initial context supposed to be relative to java:comp/env by default?
[03:14:24] <dmlloyd> it'd be easy to do for sure, but that's a little surprising
[03:14:33] <Nihility> i think those are global paths im looking
[03:14:45] <Nihility> i thought you would find it interesting
[03:14:49] <Nihility> note that /local thing
[03:14:56] <Nihility> that was a past jboss ejb convention
[03:17:19] *** jpearlin has quit IRC
[03:17:44] <Nihility> yeah those are global paths
[03:17:54] <Nihility> it raises a good question though
[03:18:13] <Nihility> how are deps supposed to work
[03:18:22] <Nihility> when someone uses direct jndi
[03:18:42] <dmlloyd> we already worked that out a while ago
[03:18:42] <smarlow> Nihility:  https://svn.jboss.org/repos/qa/ejb3demo/trunk/ + https://svn.jboss.org/repos/qa/ejb3demo/trunk/src/services/ejb/
[03:19:14] <dmlloyd> basically what happens is the lookup will block until either the binding is created, or all outstanding services have finished and the dep is still missing, in which case a NameNotFoundException would be thrown
[03:19:17] <smarlow> Nihility:  that looks like it, I found it referenced in a jira.  Don't know for sure
[03:19:19] <dmlloyd> now I don't think that's actually working...
[03:20:10] <stuartdouglas> Nihility: I think your class path issues may have been caused by the war not being unpacked
[03:20:31] <stuartdouglas> it was preventing the manifest from being read
[03:20:40] <Nihility> stuartdouglas: nah i fixed that
[03:20:52] <stuartdouglas> and it still does not work even after you fixed it?
[03:20:58] <Nihility> yeah here is what it says
[03:21:19] <Nihility>  Class Path entry OrderManagerEJB.jar in "/content/OrderManagerApp.ear/OrderManagerWeb.war"  does not point to a valid jar for a Class-Path reference.
[03:21:36] <stuartdouglas> can you push you war unpack fix so I can debug some more?
[03:21:41] <Nihility> dmlloyd: ah clever
[03:21:46] <Nihility> sure
[03:21:53] <Nihility> can you review it stuartdouglas ?
[03:21:59] <stuartdouglas> sure
[03:25:43] <Nihility> https://github.com/n1hility/jboss-as/commit/70548de48d8334d8a6e74a3383f160427521d80a
[03:25:44] <jbossbot> git [jboss-as] 70548de.. Jason T. Greene Unpack nested wars too
[03:26:27] <Nihility> oops
[03:26:28] <Nihility> wrong one
[03:26:29] <Nihility> one sec
[03:27:08] <Nihility> oh no thats right
[03:27:18] <Nihility> wrong window :)
[03:27:23] *** mbg is now known as mbg|away
[03:28:02] <stuartdouglas> looks good
[03:28:19] <jbossbot> git [jboss-as] push master 70548de.. Jason T. Greene Unpack nested wars too
[03:28:20] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/77a3af8...70548de
[03:30:29] <Nihility> smarlow: btw hibernate wins the ridiculous info logging award
[03:30:31] <Nihility> :)
[03:30:56] <smarlow> Nihility:  we should turn that down  :)
[03:31:00] <Nihility> deploying a simple app results in 100+ lines of info logs
[03:31:21] <dmlloyd> jpav is the guy to talk to about that
[03:31:30] <dmlloyd> he's been porting hibernate to the new logging standard
[03:31:33] <dmlloyd> i18n and all
[03:31:50] <jamezp> Nihility: I must not be smart enough to figure this out. Any pointers to how to change the jaxp provider to use woodstox?
[03:33:27] <Nihility> http://fpaste.org/B0sF/
[03:33:36] <Nihility> isnt that crazy
[03:34:32] <smarlow> yup, that could easily be debug (I should make a contribution for that :)
[03:34:36] <Nihility> jamezp: well first see if we have a woodstox module, and if we dont add one
[03:34:55] *** jma has joined #jboss-as7
[03:35:09] <Nihility> jamezp: then all you do is edit the module.xml for the javax.jaxp.provider module (might want to double check the name)
[03:35:20] <Nihility> jamezp: and then you import the woodstox module
[03:35:32] <jamezp> Ah, got it. I just tried changing the module.xml under the jaxp-proivder dir.
[03:35:52] <Nihility> oh thats probably right
[03:35:57] <Nihility> im bad at remembering names
[03:36:04] <Nihility> anyway its an import line in there
[03:36:22] <Nihility> right now it just imports xalan
[03:36:47] <jamezp> Right, so I just need to define the module then.
[03:38:13] <Nihility> yeah its all in build/src/lib.xml or something
[03:38:21] <Nihility> but you have to have a pom entry for the dep
[03:39:06] <jamezp> Okay. Looks like it's time to play and see what I can break :-)
[03:43:43] *** pgier has quit IRC
[03:49:48] <Nihility> hmmm the JNDIView mbean thing is not so useful with our EE namespaces
[03:50:09] <dmlloyd> yeah
[03:50:32] <Nihility> we could easily make global work
[03:50:41] <Nihility> if we had correct global stuff
[03:50:47] <dmlloyd> maybe
[03:51:21] <Nihility> perhaps another fun task for jamezp, make app show up in java:global as its supposed to
[03:51:30] <Nihility> s/app/apps
[03:51:39] <dmlloyd> I don't think that's a blanket rule
[03:51:46] <dmlloyd> I think that certain things are just bound to both places
[03:51:50] <dmlloyd> I could be wrong about that though
[03:52:00] <dmlloyd> just glanced over it the other day when this came up
[03:53:24] <Nihility> it does say that every application has an entry in global
[03:53:40] <Nihility> and every top level jar has a module entry at the same level
[03:54:15] <Nihility> and that contents of that are the same as java:app
[03:55:01] <Nihility> also all ejbs are bound under that
[03:55:28] <Nihility> and the top level module thing implies all mbs are as well
[04:00:19] <stuartdouglas> Nihility: I have some integration test fixes in my master
[04:00:27] <stuartdouglas> but I can't reproduce your class path issues
[04:01:05] <stuartdouglas> I added an integration test that does the same thing and it passes
[04:01:18] <stuartdouglas> and when I added the Class-Path entry to the app it deploys
[04:02:57] <jamezp> Nihility: Sounds good to me. I'll do whatever :-)
[04:06:13] <Nihility> are you doing a sibling Class-Path: foo-ejb.jar in a war file?
[04:06:24] <stuartdouglas> yea
[04:06:40] <Nihility> and also does it do anything that would cause the failure?
[04:06:50] <stuartdouglas> have a look at WarCanAccessEjbJarTestCase in my master
[04:07:11] <stuartdouglas> it attempts to load the class using the war's class loader to access the ejb-jar
[04:07:25] <stuartdouglas> but when I added the class path entry to OrderManager it deployed fine
[04:07:54] <stuartdouglas> well, the web part did anyway
[04:08:37] <stuartdouglas> the ejb jar does not deploy cause of missing services
[04:08:41] <Nihility> hmm
[04:09:27] <Nihility> let me send you my deployment and you can see if you get the error
[04:10:05] <stuartdouglas> ok, I also changed some Phase stuff in my master, but it should have nothing to do with class-path
[04:10:37] <Nihility> just sent it
[04:13:09] <stuartdouglas> odd, it deploys fine
[04:13:22] <stuartdouglas> can you merge my master and see how that goes?
[04:13:34] <Nihility> odd
[04:13:37] <Nihility> yeah ill do that
[04:13:51] <stuartdouglas> (only the war deploys fine, the ejb jar is still broken, but there are no CL error)
[04:25:57] <smcgowan> stuartdouglas:  boy, you're good: http://hudson.qa.jboss.com/hudson/view/TCK6-AS7-WEB/job/tck6-as7-jaxrs/9/
[04:28:16] <stuartdouglas> :-)
[04:30:33] <stuartdouglas> does the jax-rs stuff pass in AS6 ?
[04:36:41] <stuartdouglas> Nihility: how did you go with my master?
[04:37:04] <Nihility> let me try real quick
[04:37:27] <smcgowan> stuartdouglas:  yes, the jaxrs stuff is passing in AS 6
[04:37:34] <smcgowan> you surprised?
[04:38:06] <stuartdouglas> to be honest yes, I don't understand why I was getting that error in AS7 but it is not happening on AS6
[04:38:33] <stuartdouglas> also the way it integrates in AS6 violates the spec, but the TCK must not test that part
[04:39:04] *** lgao has joined #jboss-as7
[04:39:31] <smcgowan> it's basically the standalone JAXRS TCK added in to the EE 6 one - so that is possible
[04:39:50] <smcgowan> probable
[04:41:14] *** mbg|away is now known as mbg
[04:43:06] *** jamezp has quit IRC
[04:43:46] *** smarlow has quit IRC
[04:49:31] <Nihility> stuartdouglas: it does appear to work
[04:49:46] <Nihility> stuartdouglas: what did ypu fix?
[04:50:14] <stuartdouglas> nothing :-) Just the deployment order that happens after the class-path stuff
[04:51:31] <stuartdouglas> are you sure you were not trying with an out of date branch?
[04:55:27] <Nihility> yeah positive
[04:55:34] <Nihility> i had just merged your branch
[04:56:03] <stuartdouglas> I really have no idea then
[04:57:40] *** irooskov has quit IRC
[05:06:51] *** smcgowan has quit IRC
[05:10:39] <Nihility> dmlloyd: looks like stateful session beans arent bound into jndi
[05:27:26] <Nihility> ah its because it thinks there is no view
[05:27:28] <Nihility> lets see why
[05:28:13] <Nihility> well it can wait for the morning
[05:28:22] <stuartdouglas> that will happen if there is only remote interfaces
[05:28:29] *** jwulf has joined #jboss-as7
[05:28:43] <Nihility> stuartdouglas: in this case there is no remote interface
[05:28:49] <Nihility> stuartdouglas: just an interface
[05:29:13] <stuartdouglas> can you send me the source for the app?
[05:29:25] <Nihility> i dont have it
[05:29:35] <Nihility> ive been using JD :)
[05:30:01] <Nihility> http://java.decompiler.free.fr/?q=jdgui
[05:35:16] <stuartdouglas> nice, it's lot easier to use than jclasslib :-)
[05:35:42] <Nihility> oh here it
[05:35:44] <Nihility> i see the bug
[05:35:56] <Nihility>  DotName[] interfaces = sessionBeanClass.interfaces();
[05:35:56] <Nihility>         // TODO: Needs better implementation. For now, we are just checking for a single interface on the
[05:35:57] <Nihility>         // bean implementation class. The EJB spec mandates skipping some specific interfaces like java.io.Serializable
[05:35:57] <Nihility>         // and such. All such rules need to be applied here.
[05:35:57] <Nihility>         if (interfaces == null || interfaces.length != 1) {
[05:35:58] <Nihility>             return null;
[05:35:58] <Nihility>         }
[05:36:15] <Nihility> it implements serializable
[05:36:32] <Nihility> which is funny
[05:36:37] <Nihility> that its in the comment
[05:37:03] <Nihility> ok im off to bed
[05:37:42] <stuartdouglas> night
[05:37:51] <Nihility> you want to fix that one :)
[05:37:56] <stuartdouglas> sure
[05:38:00] <stuartdouglas> which file?
[05:38:13] <Nihility> LocalEjbViewAnnotationProcessor
[05:39:05] <Nihility> thanks man!
[05:39:08] <Nihility> im off to bed
[05:46:54] *** jwulf has quit IRC
[05:47:09] *** fnasser has quit IRC
[05:47:34] *** jwulf has joined #jboss-as7
[06:24:05] *** jwulf has quit IRC
[06:25:10] *** jwulf has joined #jboss-as7
[06:31:14] *** mbg is now known as mbg|away
[06:39:53] *** mbg|away is now known as mbg
[06:42:27] *** mbg has quit IRC
[06:44:17] *** jwulf has quit IRC
[06:45:00] *** jwulf has joined #jboss-as7
[07:01:41] *** frainone has quit IRC
[07:04:21] *** jwulf has quit IRC
[07:05:00] *** jwulf has joined #jboss-as7
[07:12:54] *** stuartdouglas has quit IRC
[07:14:43] *** stuartdouglas has joined #jboss-as7
[07:14:43] *** ChanServ sets mode: +v stuartdouglas
[07:22:01] *** stuartdouglas has quit IRC
[07:24:35] *** jwulf has quit IRC
[07:25:20] *** jwulf has joined #jboss-as7
[07:26:29] *** stuartdouglas has joined #jboss-as7
[07:26:29] *** ChanServ sets mode: +v stuartdouglas
[07:44:51] *** jwulf has quit IRC
[07:45:51] *** jwulf has joined #jboss-as7
[07:48:31] *** miclorb_ has quit IRC
[08:05:01] *** jwulf has quit IRC
[08:06:52] *** stalep has quit IRC
[08:21:17] *** jwulf has joined #jboss-as7
[08:25:11] *** jwulf has quit IRC
[08:25:45] *** jwulf has joined #jboss-as7
[08:28:05] *** Jaikiran has joined #jboss-as7
[08:28:05] *** ChanServ sets mode: +v Jaikiran
[08:45:31] *** jwulf has quit IRC
[08:46:08] *** jwulf has joined #jboss-as7
[08:51:22] *** opalka has joined #jboss-as7
[08:51:22] *** opalka has joined #jboss-as7
[08:51:22] *** ChanServ sets mode: +v opalka
[08:51:29] <opalka> morning
[08:51:57] *** irooskov has joined #jboss-as7
[09:03:15] *** dimitris_jboss has joined #jboss-as7
[09:03:15] *** dimitris_ has joined #jboss-as7
[09:03:15] *** dimitris_jboss has quit IRC
[09:03:15] *** dimitris_jboss has joined #jboss-as7
[09:03:15] *** dimitris_ has quit IRC
[09:03:15] *** dimitris_ has joined #jboss-as7
[09:03:15] *** ChanServ sets mode: +vv dimitris_jboss dimitris_
[09:05:40] *** asoldano has joined #jboss-as7
[09:05:41] *** ChanServ sets mode: +v asoldano
[09:05:41] *** jwulf has quit IRC
[09:06:35] *** jwulf has joined #jboss-as7
[09:06:50] *** irooskov has quit IRC
[09:18:27] *** Sacha has joined #jboss-as7
[09:21:48] *** adietisheim has joined #jboss-as7
[09:25:56] *** jwulf has quit IRC
[09:26:47] *** jwulf has joined #jboss-as7
[09:29:34] *** jwulf has quit IRC
[09:32:24] *** torben has joined #jboss-as7
[09:32:24] *** torben has joined #jboss-as7
[09:32:24] *** ChanServ sets mode: +v torben
[09:35:32] *** pil-dinner has joined #jboss-as7
[09:37:08] *** hbraun has joined #jboss-as7
[09:43:20] *** aslak has joined #jboss-as7
[09:43:20] *** aslak has joined #jboss-as7
[09:43:20] *** ChanServ sets mode: +v aslak
[09:52:34] *** pil-dinner is now known as pilhuhn
[09:52:35] *** pilhuhn has joined #jboss-as7
[09:57:59] *** wolfc has joined #jboss-as7
[09:57:59] *** ChanServ sets mode: +v wolfc
[10:01:41] *** aslak has quit IRC
[10:02:20] *** aslak has joined #jboss-as7
[10:02:21] *** ChanServ sets mode: +v aslak
[10:03:56] *** tdiesler has joined #jboss-as7
[10:04:03] *** tdiesler has quit IRC
[10:04:04] *** tdiesler has joined #jboss-as7
[10:04:04] *** ChanServ sets mode: +v tdiesler
[10:08:05] <opalka> wolfc, ping
[10:08:18] <opalka> wolfc, I confirm that your ejb3-ws branch fixes many EJB3 tests regressions
[10:08:34] <opalka> wolfc, Do U plan to merge it upstream?
[10:08:48] * opalka needs to read yesterday's IRC logs (maybe the answer is there) ...
[10:08:52] <wolfc> opalka, I can't merge.
[10:08:56] *** dimitris_jboss has quit IRC
[10:08:56] *** dimitris_ has quit IRC
[10:09:14] <wolfc> opalka, the bit where of the special view is still dirty
[10:09:36] <opalka> wolfc, I don't understand what U mean ^^^ ?
[10:09:48] <wolfc> me neither, I'm not awake yet
[10:10:19] <opalka> wolfc, ok, ttyl ;)
[10:10:50] <wolfc> opalka, this is dirty: https://github.com/wolfc/jboss-as/commit/613b109b1907eddf23d3ad2878bd5483f615f821
[10:10:51] <jbossbot> git [jboss-as] 613b109.. Carlo de Wolf Create interceptor chain for component methods as well
[10:11:43] <wolfc> opalka, somewhere the equivalent of Component.getComponentEntry(MethodIntf) should happen
[10:11:53] *** sannegrinovero has joined #jboss-as7
[10:11:53] *** ChanServ sets mode: +v sannegrinovero
[10:12:24] <opalka> wolfc, OK, further recommendations? I can have a look in the meantime (when U'll wake up from this bad dream) ?
[10:12:35] <opalka> s/when/until/
[10:12:57] <wolfc> opalka, from a WS p.o.v. the important bit is to get the ComponentEntry beforehand, not during the invocation
[10:13:14] <wolfc> opalka, and the right Method
[10:13:32] * opalka 's listening ...
[10:14:33] <opalka> wolfc, Did U discuss your commits with DML on yesterday? If yes I'll have a look to the logs.
[10:15:00] <wolfc> opalka, yes
[10:15:35] <opalka> wolfc, ok
[10:15:46] * opalka really needs to read yesterday's IRC log
[10:15:58] <opalka> wolfc, ok, have a nice sleep
[10:16:21] <wolfc> opalka, I'm not supposed to sleep now. I need to wake up :-)
[10:16:27] <wolfc> opalka, https://github.com/wolfc/jboss-as/commit/d1760cfaabcd64ac202bacad951540e9158e4d9b
[10:16:28] <jbossbot> git [jboss-as] d1760cf.. Carlo de Wolf Exposing component methods hack to make WS test pass
[10:16:37] <wolfc> That's a work-around to get the right method.
[10:17:29] <opalka> wolfc, OK, so this have to be eliminated somewhere in WS integration, right?
[10:18:56] <wolfc> opalka, yes, but it is a fundamental change. InvocationHandlerEJB3 should not be lazy.
[10:19:18] <opalka> wolfc, understood
[10:20:11] <wolfc> opalka, that way you would have ComponentEntry upfront
[10:20:48] <opalka> wolfc, OK, regarding your ejb3-ws integration changes
[10:20:50] <wolfc> opalka, hmm, I think the next step is for WS to build up some sort of view configuration
[10:20:57] <opalka> wolfc, I can forget about them and start fixing it against upstream, right?
[10:21:37] <opalka> wolfc, Or I can build on top of your ejb3-ws integration branch and then we'll sync somehow?
[10:22:15] <wolfc> opalka, ejb3-ws provides working EJB3 endpoints
[10:22:31] <opalka> wolfc, yes
[10:22:59] <wolfc> opalka, so you can either build on top of ejb3-ws or have two branches
[10:23:30] <opalka> wolfc, I think I'll continue on top of your branch ;)
[10:23:33] <wolfc> opalka, ejb3-ws branch itself is swaying in the wind though. So it'll fly left and right during rebases.
[10:23:51] <opalka> wolfc, understood ...
[10:24:18] *** AndyTaylor has joined #jboss-as7
[10:24:18] *** ChanServ sets mode: +v AndyTaylor
[10:25:58] * opalka found wolfc & dmlloyd conversation starting from [17:46:52] on yesterday's IRC log
[10:27:19] *** tdiesler1 has joined #jboss-as7
[10:27:37] *** tdiesler has quit IRC
[10:33:29] * opalka 's compiling the discussion ...
[10:37:39] <hbraun> does anyone know how to pass the recursive flag through the CLI
[10:37:41] <hbraun> ?
[10:50:36] *** alesj has joined #jboss-as7
[11:15:51] *** jcosta has joined #jboss-as7
[11:15:51] *** ChanServ sets mode: +v jcosta
[11:24:53] *** asoldano is now known as asoldano_away
[11:25:46] *** maeste has joined #jboss-as7
[11:25:46] *** ChanServ sets mode: +v maeste
[11:33:13] *** stalep has joined #jboss-as7
[11:39:20] *** jma has quit IRC
[11:39:41] *** JimMa has joined #jboss-as7
[11:45:01] *** maeste has quit IRC
[11:48:16] *** darranl has joined #jboss-as7
[11:48:16] *** darranl has joined #jboss-as7
[11:48:16] *** ChanServ sets mode: +v darranl
[11:56:17] *** rmaucher has joined #jboss-as7
[12:03:41] *** maeste has joined #jboss-as7
[12:03:41] *** ChanServ sets mode: +v maeste
[12:12:53] <wolfc> FYI, I'm chasing http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-testSuite-sun16/14/testReport/junit/org.jboss.as.testsuite.integration.webejb/ServletInjectionTestCase/testEcho/
[12:14:00] *** miclorb_ has joined #jboss-as7
[12:14:21] *** JimMa has quit IRC
[12:23:28] *** miclorb_ has quit IRC
[12:24:28] *** pmuir has joined #jboss-as7
[12:24:28] *** ChanServ sets mode: +v pmuir
[12:27:01] *** Jaikiran has quit IRC
[12:29:40] *** asoldano_away is now known as asoldano
[12:33:23] *** torben is now known as torben|lunch
[12:34:54] *** AndyTaylor has quit IRC
[12:35:15] *** AndyTaylor has joined #jboss-as7
[12:35:15] *** ChanServ sets mode: +v AndyTaylor
[12:37:44] *** jpederse has joined #jboss-as7
[12:37:44] *** ChanServ sets mode: +v jpederse
[12:37:53] *** jpederse has quit IRC
[12:37:53] *** jpederse has joined #jboss-as7
[12:37:53] *** sendak.freenode.net sets mode: +v jpederse
[12:40:15] *** lgao1 has joined #jboss-as7
[12:41:10] *** lgao has quit IRC
[13:00:33] *** balunasj has joined #jboss-as7
[13:00:34] *** balunasj has joined #jboss-as7
[13:00:34] *** ChanServ sets mode: +v balunasj
[13:02:03] *** Jaikiran has joined #jboss-as7
[13:02:04] *** ChanServ sets mode: +v Jaikiran
[13:19:27] *** JimMa has joined #jboss-as7
[13:20:10] *** smarlow has joined #jboss-as7
[13:20:10] *** ChanServ sets mode: +v smarlow
[13:21:08] *** asoldano is now known as asoldano_lunch
[13:21:38] *** bobmcw has joined #jboss-as7
[13:21:38] *** ChanServ sets mode: +v bobmcw
[13:21:58] *** lgao1 has quit IRC
[13:24:13] *** mmoyses has joined #jboss-as7
[13:24:14] *** ChanServ sets mode: +v mmoyses
[13:37:02] *** stelios has joined #jboss-as7
[13:37:35] *** torben|lunch is now known as torben
[13:40:31] <smarlow> dmlloyd, baileyje:  for adding lifecyle interceptors, it looks like I need to pass in something that I don't have.  For example, if I call componentDescription.addPostConstructMethod(InterceptorMethodDescription), I need a org.jboss.jandex.MethodInfo for my SFSBLifeCycleInterceptor, so I can create a InterceptorMethodDescription
[13:41:02] <smarlow> maybe I'm looking at the wrong path ;)
[13:43:21] *** mbg has joined #jboss-as7
[13:43:21] *** ChanServ sets mode: +v mbg
[13:46:02] *** AndyTaylor has quit IRC
[13:51:49] *** pferraro has joined #jboss-as7
[13:51:49] *** ChanServ sets mode: +v pferraro
[13:57:12] *** pferraro has quit IRC
[13:57:23] *** pferraro has joined #jboss-as7
[13:57:23] *** ChanServ sets mode: +v pferraro
[14:00:10] *** mbg has quit IRC
[14:01:34] *** smcgowan has joined #jboss-as7
[14:01:35] *** ChanServ sets mode: +v smcgowan
[14:07:50] *** fnasser has joined #jboss-as7
[14:08:39] *** jfd has joined #jboss-as7
[14:08:39] *** ChanServ sets mode: +v jfd
[14:08:41] *** maeste has quit IRC
[14:13:52] *** maeste has joined #jboss-as7
[14:14:04] *** ChanServ sets mode: +v maeste
[14:22:31] <hbraun> baileyje: ping
[14:22:46] <hbraun> baileyje: tnx for JBAS-9110
[14:22:47] <jbossbot> jira [JBAS-9110] Read child resource operation [Resolved (Done) Feature Request, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9110
[14:22:54] *** lgao has joined #jboss-as7
[14:23:14] <hbraun> baileyje: do you know how to query the status (started/stopped) of a server?
[14:24:59] *** lgao has left #jboss-as7
[14:29:27] *** AndyTaylor has joined #jboss-as7
[14:29:28] *** ChanServ sets mode: +v AndyTaylor
[14:31:52] *** balunasj is now known as balunasj_mtg
[14:37:55] <opalka> wolfc, ping
[14:38:04] <wolfc> opalka, pong
[14:38:28] <opalka> wolfc, I'm parsing/compiling your conversation with DML on yesterday & I don't understand this
[14:38:38] <opalka> [17:52:18] <dmlloyd> why not have logic more like: if (WS || bind-no-interface) { create no-interface; if (bind-no-interface) { bind it too; }}
[14:38:38] <opalka> [17:53:02] <wolfc> no-interface (MethodIntf.LOCAL) and WS (SERVICE_ENDPOINT) can have their own security & tx attrs
[14:38:38] <opalka> [17:54:03] <wolfc> so ultimately different interceptor chains
[14:38:57] <opalka> wolfc, I thought security is the same for WS & no iface
[14:39:03] <opalka> wolfc, in the past we used to do this:
[14:39:57] <opalka> wolfc, http://fpaste.org/vaRC/
[14:40:07] <opalka> wolfc, see getUserPrincipal() & isUserInRole()
[14:40:39] <opalka> wolfc, or isn't it the security staff U're talking about in that log?
[14:40:46] <wolfc> opalka, yes, apart from the usage of CurrentEJBContext that is correct
[14:41:29] <opalka> wolfc, what was wrong with CurrentEjbContext in AS6 ?
[14:41:42] <wolfc> opalka, it needs to be CurrentSecurityContext or something
[14:42:03] <opalka> wolfc, aha, ok
[14:42:21] <opalka> wolfc, but if we forget about CurrentEJBContext vs. CurrentSecurityContext issue
[14:42:44] <opalka> wolfc, the security interceptors shouldn't be the problem anymore, or am I wrong?
[14:42:45] <wolfc> opalka, container-transaction and method-permission can be applies to views
[14:43:13] <opalka> wolfc, also to no-interface view?
[14:43:31] <wolfc> opalka, so the no-interface can have @RolesAllowed("everybody") while WS endpoint has @RolesAllowed("admin")
[14:44:06] * opalka 's grepping source code ...
[14:44:57] *** pgier has joined #jboss-as7
[14:44:58] *** ChanServ sets mode: +v pgier
[14:46:48] <opalka> wolfc, OK, I found one example - http://fpaste.org/iM3S/
[14:47:00] <opalka> wolfc, could we collaborate on it so I understand what issue U see with it ?
[14:47:46] <wolfc> opalka, that's a @RolesAllowed("friend") on the bean, which then becomes the default for all views
[14:48:56] <Nihility> wolfc: can you take a look at stuartdouglas' last patch on his master, this was to fill in the missing logic (which is one of the things that breaks andy's deployments) around interface detection
[14:49:09] <wolfc> opalka, <method-permission><role-name>admin</role-name><method><method-name>echo</method-name><method-intf>SERVICE_ENDPOINT</method-intf></method></method-permission>
[14:49:26] <wolfc> opalka, although I typed it by heart, so disclaiming parse errors :-)
[14:49:44] <wolfc> Nihility, fetching...
[14:49:52] <baileyje> hbraun: pong
[14:50:01] <hbraun> balunasj_mtg: hi
[14:50:09] <hbraun> baileyje: hi
[14:50:39] <hbraun> baileyje: I was wondering about the status of a server instance
[14:50:48] <hbraun> baileyje: how to read it from the current model
[14:51:02] <baileyje> From the management interface?
[14:51:04] <hbraun> baileyje: thought you might know that
[14:51:13] <hbraun> yes
[14:51:24] <balunasj_mtg> hbraun: Hi
[14:51:29] <hbraun> there is a server element below host, but it's empty
[14:51:41] <hbraun> balunasj_mtg: sorry, i meant baileyje
[14:51:46] * balunasj_mtg I've got about 9 minutes before my meeting started
[14:51:53] <balunasj_mtg> hbraun: oh ok - np
[14:52:00] *** mbg has joined #jboss-as7
[14:52:01] *** ChanServ sets mode: +v mbg
[14:52:10] <hbraun> baileyje: maybe you did see my mail
[14:52:28] <baileyje> hbraun: I am not sure right off hand.  It seems like a good thing to have though.
[14:52:47] <hbraun> baileyje: ok, np then i wait for brian
[14:52:59] <baileyje> yeah.  He may know better
[14:54:22] <opalka> wolfc, I think I already see what U're talking about
[14:54:28] <wolfc> Nihility, there needs to be a @Remote processor in front so the check can be made through the description.
[14:54:54] <baileyje> Jaikiran: Are you still working on the ejb-jar.xml parsing/processing?
[14:55:02] <wolfc> Nihility, more importantly I want to see it tested and then we can just merge it
[14:55:16] <wolfc> As long as we move forward, merge
[14:56:16] *** tdiesler1 has quit IRC
[14:56:51] <Jaikiran> baileyje: part of it is already upstream
[14:57:01] <wolfc> Nihility, I'm also missing checks from 4.9.7
[14:57:03] <Jaikiran> and some is currently WIP locally
[14:57:21] <Jaikiran> baileyje: is that blocking some of your work?
[14:57:32] <baileyje> Ok.  THere is a JIRA for it that is unassigned.  Should I assign it to you?
[14:57:40] <Jaikiran> it's already assigned i guess
[14:57:43] <Jaikiran> which one is it?
[14:58:55] <Jaikiran> JBAS-9019 is the one i'm aware of
[14:58:56] <jbossbot> jira [JBAS-9019] Support for ejb-jar.xml [Open (Unresolved) Sub-task, Major, jaikiran pai] https://issues.jboss.org/browse/JBAS-9019
[14:59:14] <baileyje> nevermind.  It looks like it is assigned to you now
[15:00:04] <baileyje> It was unassigned before.  Pretend I didn't say anything :)
[15:01:12] *** jfd is now known as jfd_away
[15:02:06] <Jaikiran> :)
[15:02:09] <dmlloyd> smarlow: you're looking in the right spot - you may need to come up with some new API though, for adding arbitrary lifecycle interceptors...
[15:02:54] <dmlloyd> like a List<LifecycleWhateverItIs> attached to description which is copied into the configuration
[15:03:04] <dmlloyd> then you can just add your stuff to the list when your processor runs
[15:03:26] <smarlow> dmlloyd:  okay, I expected that I missed something :)  That sounds like a good solution.
[15:03:28] *** bstansberry has joined #jboss-as7
[15:03:29] *** ChanServ sets mode: +v bstansberry
[15:03:34] *** hbraun has quit IRC
[15:04:57] *** Jaikiran is now known as Jaikiran|AFk
[15:06:59] *** mbg has quit IRC
[15:09:41] *** mbg has joined #jboss-as7
[15:09:41] *** ChanServ sets mode: +v mbg
[15:10:14] *** mbg has quit IRC
[15:10:14] *** mbg has joined #jboss-as7
[15:10:14] *** verne.freenode.net sets mode: +v mbg
[15:13:11] <smarlow> dmlloyd, baileyje:  Perhaps List<LifecycleWhateverItIs> could be List<ComponentLifecycle>
[15:13:46] <dmlloyd> yeah that's the one
[15:14:07] <baileyje> smarlow: Yeah.  THose are made to just be added as needed.
[15:14:34] <smarlow> cool, that helps :)
[15:19:33] *** ghoward has joined #jboss-as7
[15:19:56] <ghoward> dmlloyd: ping
[15:20:08] <dmlloyd> what's up ghoward
[15:21:00] <ghoward> dmlloyd: hi David, i'm doing hornetq integration with AS7, I am not sure where to put the hornetq-ra.rar in AS7
[15:21:14] <ghoward> dmlloyd: do you have any advice?
[15:21:52] <dmlloyd> personally I was hoping that we could integrate hornetq without a RAR.  The subsystem could possibly detect & hook into JCA directly.
[15:21:59] <dmlloyd> Nihility: what do you think?
[15:21:59] *** JimMa has quit IRC
[15:22:01] <wolfc> urgh
[15:22:07] <dmlloyd> urgh yourself :)
[15:22:08] <wolfc> I need hornetq-ra.rar for the JMS MDB
[15:22:11] <wolfc> :-)
[15:22:19] <dmlloyd> do you really need an actual rar file though?
[15:22:28] <dmlloyd> you should just depend on a ResourceAdapter
[15:22:42] <wolfc> that comes from a deployment of a rar
[15:22:53] <dmlloyd> or from anywhere else
[15:22:59] <dmlloyd> any Service<ResourceAdapter>
[15:23:11] <ghoward> dmlloyd, wolfc, yes the rar wraps the  stuff
[15:23:41] <wolfc> the related issue is JBAS-9122
[15:23:42] <jbossbot> jira [JBAS-9122] Integrate hornetq-ra.rar into AS 7 [Open (Unresolved) Task, Major, Yong Hao Gao] https://issues.jboss.org/browse/JBAS-9122
[15:24:01] <Nihility> yeah i really want to avoid using deployments for our internals
[15:24:06] <wolfc> +1
[15:24:36] <dmlloyd> yeah we need to find some better way (other than deployment name) to identify what RA to use for MDBs
[15:24:37] <Nihility> we had that with jca jdbc support and it kept causing problems
[15:24:50] <dmlloyd> isn't JCA supposed to use activation properties to figure that out?
[15:25:09] <wolfc> no, but we do have that new ResourceAdapterRegistry
[15:25:33] <wolfc> still it can lead to ambiguity
[15:26:27] <ghoward> the rar is loaded by JCA
[15:26:37] <wolfc> so at the end of the day we use @ResourceAdapter
[15:26:50] <ghoward> unless JCA has another way to load a resource adapter...
[15:27:05] <dmlloyd> there is always a way :)
[15:27:13] <ghoward> :)
[15:27:24] <ghoward> yes as we have a wish
[15:27:47] <wolfc> how about we put the rar in the module repo and fire off a deployment from there?
[15:28:05] <dmlloyd> that's not any better than what we did with jdbc
[15:28:13] <dmlloyd> worse even because we'd have to write a deployer which deploys from a module
[15:28:14] <wolfc> I missed the jdbc problems :-)
[15:28:26] <wolfc> That sounds cool to me
[15:28:55] <Nihility> with jdbc we basically had a service that would kick off a deployment
[15:29:06] <ghoward> yes jdbc is the same thing from jca view,
[15:29:12] <Nihility> anytime a resource was registered
[15:29:21] <Nihility> in the config
[15:29:37] <Nihility> then the deployment would start poking in JCA services/internals
[15:29:54] <Nihility> which would then cycle back to the rar
[15:30:11] <Nihility> the issues were:
[15:30:22] <Nihility> 1. it was slower (tons of extra processing scheduling)
[15:30:33] <ghoward> Nihility: what if a user wants to deploy a 3rd party JMS resource adapter?
[15:30:37] <Nihility> 2. it shared the same deployment CL for all jdbc drivers
[15:31:55] <ghoward> Nihility: forget it, they can use a normal rar deployment.
[15:31:57] <wolfc> Hmm, wicked, all of those should not really be issues
[15:31:58] <Nihility> ghoward: thats find although ideally hornetq has the best possible integration
[15:32:14] *** slaboure has joined #jboss-as7
[15:32:18] <ghoward> Nihility: right. :)
[15:32:57] <Nihility> wolfc: we had this nice fancy jdbc driver deployment layer
[15:33:11] <ghoward> Nihility: where can I have a look in the code how JDBC is activated and loaded?
[15:33:11] <Nihility> wolfc: that had driver instances for multipler versions of the same driver all nicely isolated
[15:33:38] <Nihility> wolfc: and then the jdbc rar would bypass all of that (since its not using service deps per jdbc driver)
[15:33:53] <Nihility> wolfc: and try to load the classes directly and it would use TCCL
[15:34:30] <wolfc> should we not mandate a custom xml that specifies the correct version?
[15:34:30] <Nihility> wolfc: so to fix it it would have to call back into the service registry
[15:34:40] *** Sacha has quit IRC
[15:34:54] <Nihility> wolfc: we have that you specify what version you want in the ds config
[15:35:27] <wolfc> hmm, yeah, let's stop talking jdbc
[15:35:39] <Nihility> ok so in a nutshell
[15:35:50] <Nihility> mdb + any rar should work
[15:36:13] <wolfc> it already does :-)
[15:36:17] <Nihility> but in the case of hornetq where we have a fancy subsystem it will likely be cleaner to do it from there
[15:36:27] <wolfc> but I have a module dependency work-around for CL requirements
[15:38:12] <wolfc> ah I see what you mean, just fire up the ResourceAdapter from messaging subsys
[15:39:19] *** asoldano_lunch is now known as asoldano
[15:41:18] *** ALR has joined #jboss-as7
[15:41:19] *** ChanServ sets mode: +v ALR
[15:44:43] *** ghoward has left #jboss-as7
[15:46:01] *** JimMa has joined #jboss-as7
[15:46:21] *** asaldhan has joined #jboss-as7
[15:46:21] *** ChanServ sets mode: +v asaldhan
[15:47:44] *** bstansberry has quit IRC
[15:48:54] *** jamezp has joined #jboss-as7
[15:48:54] *** ghoward has joined #jboss-as7
[15:58:50] *** JimMa has quit IRC
[15:59:20] <baileyje> man I love the CLI
[15:59:32] <baileyje> The tab complete especially.
[16:01:19] *** bstansberry has joined #jboss-as7
[16:01:20] *** ChanServ sets mode: +v bstansberry
[16:03:03] *** balunasj_mtg has quit IRC
[16:05:44] <smarlow> Nihility:  HHH-6048 is for reducing the Hibernate noise during deployment.
[16:05:44] <jbossbot> jira [HHH-6048] Reduce configuration logging from INFO to DEBUG level [Open (Unresolved) Task, Trivial, Unassigned] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6048
[16:06:25] <wolfc> opalka, is ReflectionServiceFactoryBean.createInterface leading in creating the Methods for AS 7? so wsInvocation.getJavaMethod() comes from there?
[16:07:09] <baileyje> bstansberry: There?
[16:07:29] <bstansberry> yep
[16:07:37] <baileyje> Can you review: https://github.com/baileyje/jboss-as/commit/3ccef1261b5eeeefa61bd9e2c48778f10aca88fc
[16:07:38] <jbossbot> git [jboss-as] 3ccef12.. John E. Bailey [JBAS-9127] - Make sure the datasource related services correctly start and stop together.  Also enable the H2 driver in domain mode
[16:07:49] <jbossbot> jira [JBAS-9127] H2 Datasource fails in domain mode [Open (Unresolved) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9127
[16:08:12] <opalka> wolfc, I don't know if it comes from it
[16:08:24] <opalka> wolfc, I'd need to debug it
[16:08:45] <baileyje> bstansberry: The failure case when the DS happened in standalone as well.  I was trying to be too tricky with the services.
[16:09:16] <bstansberry> baileyje: yeah, I knew it would. I guess I never committed the domain.xml change?
[16:09:29] <bstansberry> ah, I kept asking for patch review and never got it!
[16:09:32] <baileyje> bstansberry: Not that I see in upstream..
[16:09:41] <baileyje> bstansberry: Sorry..  I will review now :)
[16:09:52] <bstansberry> haha, yeah, I nominate you
[16:10:01] <bstansberry> let me find the links
[16:10:32] *** torben has quit IRC
[16:10:50] *** ghoward has left #jboss-as7
[16:10:53] <bstansberry> https://github.com/bstansberry/jboss-as/commits/JBAS-9126
[16:10:54] <jbossbot> jira [JBAS-9126] The read-resource operation description does not include the "include-runtime" parameter [Open (Unresolved) Bug, Minor, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9126
[16:10:59] <bstansberry> and...
[16:11:31] <bstansberry> https://github.com/bstansberry/jboss-as/commit/c373c35eb09e4b0d8b8a9a68b097337131c9a17d
[16:11:32] <jbossbot> git [jboss-as] c373c35.. bstansberry at jboss dot com [JBAS-9063] Configure rollback on the deployment plan...
[16:11:33] <jbossbot> jira [JBAS-9063] Failing rar deployment is not cleaned up [Open (Unresolved) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9063
[16:13:31] <baileyje> bstansberry: JBAS-9126 looks good.  Just two commits in that correct?
[16:13:32] <jbossbot> jira [JBAS-9126] The read-resource operation description does not include the "include-runtime" parameter [Open (Unresolved) Bug, Minor, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9126
[16:14:04] <bstansberry> baileyje: yes, then the 9063 one I posted later
[16:14:13] <baileyje> Just getting to that.
[16:14:18] <bstansberry> your 9127 stuff looks good; I'll push it
[16:14:37] <bstansberry> our JIRA count will decrease :-)
[16:15:46] <baileyje> THe other looks good as well.  You want me to test it?
[16:15:59] <baileyje> Not that I have a failing deployment handy.
[16:16:08] <bstansberry> no, that's ok
[16:16:24] <bstansberry> you can if you want, but I have
[16:16:24] <baileyje> bstansberry: It looks good though.
[16:17:20] <baileyje> I trust you.
[16:19:18] *** opalka has quit IRC
[16:23:29] *** torben has joined #jboss-as7
[16:23:30] *** ChanServ sets mode: +v torben
[16:25:42] <asoldano> Nihility, dmlloyd: good morning; would it be possible to have a release of jboss-modules by the end of the week, so that we have one week before next beta for checking our stuff, releasing jbossws-cxf, preparing the pull request and have it applied upstream?
[16:26:51] * dmlloyd looks at the modules road map
[16:27:33] <asoldano> dmlloyd, even a timestamped snapshot or such would be fine to me in the mean time
[16:29:00] <baileyje> maeste: There?
[16:29:10] <maeste> baileyje: yup
[16:29:20] <baileyje> Will you have time to work on JBAS-9061 before beta2?
[16:29:21] <jbossbot> jira [JBAS-9061] DataSouce schema uses incorrect name for JDBC driver [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/JBAS-9061
[16:33:06] <maeste> baileyje: https://issues.jboss.org/browse/JBJCA-532
[16:33:07] <jbossbot> jira [JBJCA-532] Rename <module> to <driver> [Resolved (Done) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBJCA-532
[16:33:37] <maeste> baileyje: I'm going to link the two issues and IJbeta5 port issue
[16:33:42] <baileyje> ok.  So that will come in with JBAS-9079
[16:33:43] <jbossbot> jira [JBAS-9079] Port connector subsystems to IronJacamar Beta5 [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9079
[16:33:53] <maeste> baileyje: exactly
[16:33:58] <baileyje> maeste: Great.  Thanks
[16:34:14] *** mmoyses is now known as mmoyses_
[16:34:27] <maeste> baileyje: I have almost done also for JBAS-9079, but we need a release of IJ
[16:34:35] <jbossbot> jira [JBAS-9079] Port connector subsystems to IronJacamar Beta5 [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9079
[16:34:43] <maeste> baileyje: it should be Tue 29 March
[16:34:56] <baileyje> maeste: Sounds good.  I assigned you the AS issue.
[16:35:21] <maeste> baileyje: oki, as said linking the 3 issues together
[16:35:28] <baileyje> maeste: perfect.
[16:39:43] *** jclingan has joined #jboss-as7
[16:40:05] *** pmuir has quit IRC
[16:40:29] *** asaldhan has quit IRC
[16:46:01] <jbossbot> git [jboss-as] push master 91640c7.. Carlo de Wolf Fix @EJB injection
[16:46:02] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/70548de...91640c7
[16:46:10] <baileyje> wolfc, dmlloyd:  Do we have anyone moving forward with the ejb3 async?
[16:46:29] <dmlloyd> Jaikiran might be
[16:48:00] *** jclingan has quit IRC
[16:49:01] <jbossbot> git [jboss-as] push master c3fa941.. Stefano Maestri changes to fix dependency
[16:49:01] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/91640c7...c3fa941
[16:50:39] *** stelios has quit IRC
[16:52:08] <dmlloyd> smcgowan: how critical is JBAS-9121?
[16:52:09] <jbossbot> jira [JBAS-9121] CLONE - Cannot build JBoss AS 7 using OpenJDK [Open (Unresolved) Bug, Major, Shelly McGowan] https://issues.jboss.org/browse/JBAS-9121
[16:52:47] <smcgowan> dmlloyd:  not critical - just uncovered those as i created the jobs
[16:53:01] <dmlloyd> okay, do you mind if I push it out to beta3?
[16:53:05] <smcgowan> i think the compilation issue should be addressed
[16:53:23] <dmlloyd> we seem to have a lot of issues with 1.6.0_17 :(
[16:53:34] <smcgowan> no, actually,it should probably note have a release target, that was carried over from cloning
[16:54:00] <smcgowan> note s/b not
[16:54:05] <dmlloyd> ok I'll move it to "open to community" and put some notes in
[16:54:44] <jamezp> dmlloyd: Yes we do. I'm still digging into it, but I have a feeling it's due to XML parsing.
[16:55:26] <dmlloyd> the runtime problem you mean
[16:55:40] <jamezp> Yes.
[16:55:43] <dmlloyd> smcgowan is running into the build problem with the missing Rhino in a hudson instance
[16:55:54] <dmlloyd> the one I told you to avoid by using the sun JDK :)
[16:56:15] <smcgowan> dmlloyd:  i can check that -
[16:56:22] *** asaldhan has joined #jboss-as7
[16:56:26] <smcgowan> something like that, right?
[16:56:33] <jamezp> That's the one :-)
[16:56:45] *** asaldhan has quit IRC
[16:56:45] *** asaldhan has joined #jboss-as7
[16:57:22] <wolfc> baileyje, nobody is moving on async yet. If you want, you can pick it up. dmlloyd did some preliminary work.
[16:58:19] <baileyje> wolfc: I will unless you think it makes more sense to have someone with more ejb3 background on it
[16:59:26] <wolfc> baileyje, the tricky bit will start with remote async. The other bit is that I don't like the API at all.
[16:59:43] <dmlloyd> :D
[16:59:46] <wolfc> baileyje, I have an alternative here: http://github.com/wolfc/jboss-beach-async
[17:00:18] <dmlloyd> well we have to implement the spec
[17:00:24] <wolfc> yup
[17:00:37] <wolfc> although it is not part of web-profile, so it is a lower prio
[17:00:40] <dmlloyd> the impl I have puts the burden of concurrency on the client
[17:00:54] <dmlloyd> which is pretty much what we want afaict
[17:00:57] <wolfc> which concurrency?
[17:01:05] <dmlloyd> background execution of the invocation
[17:01:23] <dmlloyd> works nicely for remote because no thread pool is really strictly necessary
[17:01:30] <dmlloyd> for R3 anyway
[17:01:34] <dmlloyd> since remoting already has a thread pool
[17:01:46] <wolfc> client side?
[17:01:54] <dmlloyd> both sides
[17:02:00] <dmlloyd> R3 uses NIO
[17:03:56] <wolfc> baileyje, another tricky bit is security. That is propagated.
[17:04:25] <wolfc> https://github.com/dmlloyd/jboss-as/commit/53c78cfbbe69afbefaac6cccec1a68fbab001c99#L3R59
[17:04:26] <jbossbot> git [jboss-as] 53c78cf.. David M. Lloyd [JBAS-8978] Asynchronous invocation support
[17:04:27] <jbossbot> jira [JBAS-8978] Complete async EJB invocation [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8978
[17:04:41] <wolfc> we had trouble when we pushed the same invocation into the future
[17:04:47] * dmlloyd should probably rebase that.
[17:05:15] <wolfc> other interceptors might close down context or kill resources
[17:05:21] <dmlloyd> yeah the async interceptor should be coordinated with security/txn on the client side so that the txn/security context is attached.
[17:05:45] <wolfc> txn must not be propagated
[17:05:47] <dmlloyd> granted lots of that stuff doesn't apply with void async methods
[17:05:48] <dmlloyd> yeah
[17:06:33] <wolfc> https://github.com/dmlloyd/jboss-as/commit/53c78cfbbe69afbefaac6cccec1a68fbab001c99#L4R70 is the API's ugliness rearing its head
[17:06:33] <jbossbot> git [jboss-as] 53c78cf.. David M. Lloyd [JBAS-8978] Asynchronous invocation support
[17:06:34] <jbossbot> jira [JBAS-8978] Complete async EJB invocation [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8978
[17:07:38] <jbossbot> git [jboss-as] push master b981bdf.. John E. Bailey [JBAS-9127] - Make sure the datasource related services correctly start and stop together.  Also enable the H2 driver in domain mode
[17:07:39] <jbossbot> jira [JBAS-9127] H2 Datasource fails in domain mode [Open (Unresolved) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9127
[17:07:40] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/c3fa941...b981bdf
[17:07:43] <bstansberry> baileyje: ^^^
[17:07:53] <baileyje> bstansberry: Thanks
[17:08:04] <bstansberry> thank you :)
[17:13:20] *** alesj has quit IRC
[17:16:30] <baileyje> dmlloyd: Do you want to rebase your async branch?
[17:16:36] <dmlloyd> sure
[17:19:43] <jbossbot> git [jboss-as] push master bff83eb.. bstansberry at jboss dot com [JBAS-9063] Configure rollback on the deployment plan...
[17:19:45] <jbossbot> jira [JBAS-9063] Failing rar deployment is not cleaned up [Open (Unresolved) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9063
[17:19:45] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/b981bdf...bff83eb
[17:20:10] * smarlow nice, SFSBLifeCycleInterceptor is getting  invoked.  Next, I need to find my notes about what wolfc said about getting the SFSB context...
[17:23:19] <dmlloyd> baileyje: done
[17:23:44] <baileyje> dmlloyd: Ok.. I will start cranking on it this afternoon
[17:27:21] <smarlow> dmlloyd, wolfc:  I don't suppose the StatefulComponentDescription knows what the SFSB context or sessionId will be?
[17:28:17] <smarlow> The life cycle interceptor is only getting passed in the Target object
[17:28:18] <wolfc> smarlow, no. The SFSBLifeCycleInterceptor should get that in the @PostConstruct
[17:28:37] <wolfc> Yeah, you actually need a system interceptor, not an user one
[17:34:58] *** mmoyses_ is now known as mmoyses
[17:35:07] *** maeste has quit IRC
[17:37:07] <jbossbot> git [jboss-as] push master 4f72004.. bstansberry at jboss dot com Fix broken web resource description; add test
[17:37:07] <jbossbot> git [jboss-as] push master 3efa7fd.. bstansberry at jboss dot com [JBAS-9126] Add include-runtime parameter to read-resource descriptions
[17:37:11] <jbossbot> jira [JBAS-9126] The read-resource operation description does not include the "include-runtime" parameter [Open (Unresolved) Bug, Minor, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9126
[17:37:11] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/bff83eb...3efa7fd
[17:37:29] *** jclingan has joined #jboss-as7
[17:39:12] <smarlow> wolfc, dmlloyd, baileyje:  system interceptors at the AbstractComponent level?  or elsewhere?
[17:41:55] <dmlloyd> well, the problem is that lifecycle methods are not really (currently) interceptors at all
[17:44:15] <dmlloyd> maybe they should be after all...
[17:45:17] <smarlow> there is a TODO in ComponentLifecycle to use Interceptors
[17:48:07] <dmlloyd> everyone has a divergent opinion about how lifecycle methods should be
[17:48:41] <dmlloyd> I suspect that ComponentLifecycle should accept a ComponentInstance, not the Object it refers to
[17:48:53] *** stansilvert has joined #jboss-as7
[17:49:29] *** hbraun has joined #jboss-as7
[17:51:32] <smarlow> dmlloyd:  as long as ComponentLifecycleMethod can get the target object that it refers to (for the current ComponentLifecycleMethod to work as currently)
[17:51:38] <dmlloyd> actually that'd be a pretty simple change since there's only one impl
[17:51:45] <dmlloyd> yeah ComponentInstance.getInstance() iirc
[17:51:53] <dmlloyd> yeah that's the one
[17:52:18] <dmlloyd> might have to double-check baileyje's fix to make sure it doesn't overload that target parameter with the interceptor instance
[17:52:32] <smarlow> baileyje:  thoughts ^?
[17:53:19] <baileyje> Which interceptor?
[17:53:37] <dmlloyd> lifecycle methods on interceptor objects
[17:53:42] <dmlloyd> iirc you fixed that earlier this week
[17:54:55] <baileyje> yeah. Looks like the target is interceptor being created
[17:55:11] <baileyje> For the post constructs on the interceptors
[17:55:42] *** alesj has joined #jboss-as7
[17:55:52] <jbossbot> git [jboss-as] push master dff629f.. Paul Ferraro JBAS-9133 SocketBinding multicast-address validation fails, since model stores result of InetAddress.toString()...
[17:55:53] <jbossbot> jira [JBAS-9133] SocketBinding multicast-address validation fails, since model stores result of InetAddress.toString() [Open (Unresolved) Bug, Critical, Paul Ferraro] https://issues.jboss.org/browse/JBAS-9133
[17:55:53] <jbossbot> git [jboss-as] push master 987bb5a.. Paul Ferraro JBAS-9136 Thread subsystem writer outputting queueless-thread-pool name attribute as blocking
[17:55:54] <jbossbot> jira [JBAS-9136] Thread subsystem writer outputting queueless-thread-pool name attribute as blocking [Open (Unresolved) Bug, Critical, Paul Ferraro] https://issues.jboss.org/browse/JBAS-9136
[17:55:55] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/3efa7fd...987bb5a
[17:56:57] *** hbraun has quit IRC
[18:02:25] *** ccrouch1 has quit IRC
[18:02:39] <Nihility> http://community.jboss.org/message/595247#595247
[18:02:41] *** ccrouch has joined #jboss-as7
[18:02:41] *** ChanServ sets mode: +v ccrouch
[18:03:38] *** jcosta has quit IRC
[18:08:07] *** pilhuhn is now known as pil-dinner
[18:14:00] *** slaboure has quit IRC
[18:17:52] *** darranl has quit IRC
[18:25:06] <smarlow> baileyje:  are you fine with changing ComponentLifecycle to accept a ComponentInstance?
[18:25:31] <smarlow> I'll take a look at doing that if so.
[18:29:34] *** jpederse has quit IRC
[18:29:37] <dmlloyd> the create lifecycles will have to be fixed.  I think the destroy lifecycles already handle it correctly though.
[18:38:09] *** jclingan has quit IRC
[18:39:55] <smarlow> it looks like the same AbstractComponent.performLifecycle is handling both postConstruct and preDestroy.  that seems to invoke the respective componentLifecycles after invoking the passed interceptor chain.
[18:48:32] *** Jaikiran|AFk has quit IRC
[18:50:48] <smarlow> dmlloyd, baileyje:  I noticed that AbstractComponent.performInterceptorPreDestroyLifecycle(ComponentInstance) doesn't seem to get the target object by calling ComponentInstance.getInstance(), instead it does "Object interceptorInstance = interceptorFactoryContext.getContextData().get(interceptorClass)" .  So, my change to pass the ComponentInstance to the ComponentLifeCycle, sounds wrong
[18:51:13] <smarlow> unless that is getting the same object?
[18:54:46] <dmlloyd> there's two objects in question
[18:54:59] <dmlloyd> one is the object associated with the component instance, accessible via ComponentInstance.getInstance()
[18:55:06] <dmlloyd> one is the actual interceptor object being invoked upon
[18:55:19] <dmlloyd> now in some cases they are one and the same
[18:55:31] <dmlloyd> i.e. @PostConstruct/@PreDestroy on the bean class
[18:55:40] <dmlloyd> sometimes they are not, i.e. interceptor object
[18:55:52] <dmlloyd> and sometimes, there is no target instance at all, i.e. your case
[18:56:32] <dmlloyd> if you change the ComponentLifecycle class to accept ComponentInstance, it won't affect the preDestroy ones
[18:56:34] <smarlow> yep, for performPostConstructLifecycle, we haven't created the ComponentInstance yet
[18:56:42] <dmlloyd> because those grab the target instance by class
[18:56:51] <dmlloyd> post-construct however does not do so
[18:57:12] <dmlloyd> if we do not have a component instance by the time post-construct is called then there's a problem
[18:57:18] <dmlloyd> else we should rename it to "pre-construct" :)
[18:58:18] <smarlow> we have the Object instance that ComponentInstance.getInstance() would of returned but haven't called constructComponentInstance() yet
[18:58:35] <dmlloyd> hmm
[18:58:45] <dmlloyd> okay well it should be safe enough to switch that around
[18:59:55] *** aloubyansky has joined #jboss-as7
[19:02:08] <aloubyansky> bstansberry: those upload deployment operations only add the content to the repo but don't deploy, right? which operation should i use to actually deploy or how should this happen?
[19:04:09] <bstansberry> you can also use a byte[] or an input stream with the "add" operation for /deployment=whatever
[19:04:24] <bstansberry> you'd then follow with the "deploy" operation
[19:05:11] * bstansberry wants to eliminate the need for 2 steps, which should be simple
[19:05:15] *** sannegrinovero has quit IRC
[19:05:36] <aloubyansky> so after upload operation the deployment should appear under the type 'deployments'?
[19:06:12] <aloubyansky> i'm not seeing that...
[19:06:17] *** stelios has joined #jboss-as7
[19:06:36] <aloubyansky> the outcome of the upload is success
[19:07:27] <bstansberry> no all the upload does it add it to the repo and return the hash
[19:07:35] <bstansberry> the "add" operation is a better approach
[19:07:52] <bstansberry> that actually adds it to the model
[19:08:39] *** torben has quit IRC
[19:08:53] <aloubyansky> the add operation w/o address?
[19:09:45] <bstansberry> no, assuming the unique name for the deployment is foo.war, it would be /deployment=foo.war:add
[19:10:00] <bstansberry> or
[19:11:00] *** jfd_away is now known as jfd
[19:11:36] <bstansberry>   /deployment=foo.war_v1:add(runtime-name=foo.war) if you wanted it to have a unique name different from how the deployers see it
[19:12:29] <bstansberry> that handler for that add operation can deal with an input stream the same way the upload operation does; same parameter name
[19:12:58] <smarlow> dmlloyd:  we need to affect the preDestroy + postConstruct ones
[19:13:29] <aloubyansky> in this case, does deployment=foo.war_v1 exist in the model before the operation request is sent?
[19:13:32] <smarlow> I think we do anyway, since I need ComponentInstance for both cases
[19:13:40] <bstansberry> aloubyansky: no
[19:13:48] <bstansberry> that's an oddity with "add"
[19:14:07] <aloubyansky> ok, that was confusing. thanks.
[19:16:19] <bstansberry> aloubyansky: we considered having the "add" and "remove" ops on the parent resource
[19:16:23] <smarlow> dmlloyd:  I might not care about the performInterceptorPreDestroyLifecycle case although that is also wired to call lifecyle callbacks too
[19:16:39] <bstansberry> but then they'd have to be name "add-deployment" "add-subsystem" etc
[19:16:59] <bstansberry> which is also confusing, so we chose poison A instead of poison B :)
[19:18:30] <aloubyansky> these are actually examples of node type operations...
[19:20:13] <bstansberry> ?
[19:20:52] <aloubyansky> it looks to me like deployment:add(...), subsystem:add(...)
[19:21:20] <bstansberry> yeah
[19:22:10] <bstansberry> but if the name became a parameter, we would have to require it to be the same param name everywhere
[19:22:54] <bstansberry> which is doable
[19:23:26] <aloubyansky> we would? there couldn't be type-specific operations?
[19:24:28] <bstansberry> I suppose there could; it's just significantly more work
[19:24:38] <bstansberry> the operation handler registry works off of addresses
[19:24:50] <smarlow> dmlloyd:  I'll try and hack somethign together that we can discuss if needed.
[19:25:04] <Nihility> a brief note
[19:25:09] <Nihility> everyone working on as7
[19:25:19] <Nihility> you seriously should consider switching to IDEA over eclipse
[19:25:33] <Nihility> its a productivity boost and we could use one :)
[19:27:36] <Nihility> stuartdouglas: you up yet
[19:28:04] <aloubyansky> i don't get the problem... 'deployment' is one address and 'subsystem' is another one...
[19:28:47] <Nihility> if its the parent resource though then the address would be the same
[19:29:43] <jamezp> Nihility: Will the free version off IDEA suffice?
[19:29:57] <Nihility> jamezp: yeah thats what i am using
[19:30:15] <Nihility> jamezp: the only thing that sucks is learning new hotkeys
[19:30:24] <jamezp> Sweet. I'll check it out. I was about the throw my laptop the other day because of eclipse :-)
[19:30:35] <Nihility> ROFL
[19:30:46] <Nihility> its particularly bad with projects the size of AS
[19:30:56] <jamezp> Meh, I use NetBeans usually, so I don't have eclipse bindings down anyway.
[19:31:04] <bstansberry> Nihililty:  AIUI the idea is deployment:add(name=foo.war, ...) instead of deployment=foo.war:add(...)
[19:31:25] <Nihility> oh well its way better than netbeans
[19:31:43] <jamezp> Yeah. I'm convinced only tools developers like eclipse.
[19:31:56] <bstansberry> the handler for a deployment add operation is stored in a registry organized based on key/value pair addresses
[19:31:57] <Nihility> i actaully really like eclipses L&F
[19:32:14] <Nihility> thats the main reason i used it for so long
[19:32:17] <Nihility> and it used to be fast
[19:32:22] <Nihility> until everyone used maven
[19:32:26] <jamezp> I use NetBeans mainly for the JSF support.
[19:32:45] <Nihility> then someone had the great idea of shoving maven inside your ide
[19:32:47] <jamezp> Yeah, m2eclipse is awful!
[19:33:03] <stansilvert> The maven support in NetBeans is terrific.
[19:33:07] <asoldano> dmlloyd, Nihility: I've sent a pull request for initial changes for JBAS-9138, the rest is blocked by the jboss-modules update
[19:33:08] <jbossbot> jira [JBAS-9138] Upgrade to JBossWS-CXF 4.0.0.Alpha3 [Open (Unresolved) Component  Upgrade, Major, Alessio Soldano] https://issues.jboss.org/browse/JBAS-9138
[19:33:23] <stansilvert> I'm playing around with the new git support.  Not sure if I like it yet.
[19:33:25] <Nihility> asoldano: great will take a look
[19:33:52] <alesj> Nihility: finally came to your IDE senses? :-)
[19:33:59] <Nihility> stansilvert: ah see i havent used netbeans in years, it did have one thing going for it though, it let me do dark color themes :)
[19:34:02] <jamezp> stansilvert: Agreed about the NB maven support. I haven't found any git support in any IDE I like so far.
[19:34:21] <Nihility> alesj: only took 10 years
[19:34:22] <Nihility> hahahaha
[19:34:51] <Nihility> im still kind of a noob though with it
[19:34:57] <alesj> :-)
[19:35:08] <Nihility> it is pretty nice how it doesnt freak out when code does not compile
[19:35:12] <alesj> nah, you'll catch up fast
[19:35:14] <stansilvert> I've been using NetBeans since it was the first open source IDE.  It got slow too, but then it got better.  I'm just afraid Oracle will stop putting $$$ into it.
[19:35:17] <Nihility> much easier to refactor
[19:35:19] * jamezp is downloading IDEA now.
[19:36:04] <Nihility> i still cant get over how fast it opens
[19:36:30] <Nihility> im used to like opening eclipse and getting coffee
[19:37:09] <alesj> v10 is super fast
[19:37:14] <alesj> new indexing, etc
[19:37:31] <jamezp> Holy crap, that is fast!
[19:37:31] <Nihility> stansilvert: how does  nb handle the AS7 tree?
[19:38:16] <stansilvert> Nihility: Just open the main project.  Then you can look at the modules tree and open any subprojects.  Very nice.
[19:38:57] <stansilvert> Anything with a pom.xml opens right up and NetBeans understands it.
[19:39:46] <jamezp> The code completion for POM's in NetBeans is pretty good too.
[19:40:14] <aloubyansky> bstansberry: afaics, add is looking for either a hash or a stream index, not the bytes?
[19:40:22] <stansilvert> Yea, everything just works the way you expect it to.
[19:40:33] * bstansberry looks
[19:41:15] <bstansberry> aloubyansky: sorry :( I dreamed the bytes part
[19:41:43] <aloubyansky> np, just to clarify
[19:42:12] <bstansberry> it could handle bytes, stream, url, easily enough just has to be coded
[19:42:15] <Nihility> hey aloubyansky i think the first shortcut commands should be around server lifecycle and deployment
[19:42:29] <Nihility> aloubyansky: i assume thats what you are working on?
[19:42:38] <Nihility> (due to the discussion)
[19:42:47] <aloubyansky> yes, i started looking at the deployment
[19:42:53] <Nihility> cool
[19:54:40] <bstansberry> jamezp: if you're ever in the mood to improve some of the handling of deployment operations, let me know
[19:55:02] * bstansberry realizes jamezp has dealt with deployment handling some :)
[19:55:48] <jamezp> bstansberry: I'm always looking for something, time constraints are my only issue now :-)
[19:56:17] <jamezp> As long as it doesn't have to be done right away, I'm good.
[19:56:50] <bstansberry> sure
[19:57:15] <bstansberry> I'll file a JIRA and send you the link
[19:57:25] <jamezp> Perfect, sounds good.
[19:58:08] <bstansberry> it would be for Beta3, but just watch it until Beta2, unless you can do it by tue or so
[19:58:34] <jamezp> Will do. I'll take a look and see what the weekend looks like :-D
[19:59:04] <bstansberry> :)
[19:59:19] *** hbraun has joined #jboss-as7
[19:59:51] <aloubyansky> what's the date for beta3?
[20:00:05] <bstansberry> approx April 15
[20:00:42] <smarlow> dmlloyd:  A few test failures, most of the changes are here:  ComponentLifeCycle  http://fpaste.org/wrPS/  AbstractComponent:  http://fpaste.org/gIVO/
[20:01:35] <dmlloyd> smarlow: I'd just have the first invoke() method on ComponentLifecycle.
[20:03:47] <smarlow> dmlloyd:  I started down that path but wasn't sure since we are using both cases currently
[20:04:02] <smarlow> dmlloyd:  like the performInterceptorPreDestroyLifecycle case that we talked about
[20:04:26] <baileyje> dmlloyd, smarlow:  I am back from lunch..
[20:04:30] <baileyje> Where are things at
[20:04:46] *** jamezp is now known as jamezp_afk
[20:05:32] <dmlloyd> smarlow, yeah if pre-destroy is relying on the target being the interceptor object then it needs to be fixed.  If not it can just use .getInstance() from ComponentInstance.
[20:06:00] <baileyje> smarlow: You should be able to get the component instance from the InterceptorFactoryContext and propagate it to the interceptor lifecycle context data
[20:07:22] <smarlow> performInterceptorPreDestroyLifecycle gets passed in the ComponentInstance but that is probably not right for the case where they want to call a lifecycle callback on some other class
[20:07:52] <smarlow> or whatever interceptorFactoryContext.getContextData().get(interceptorClass); returns
[20:10:01] <dmlloyd> the target for pre-destroy objects should be coming from the InterceptorFactoryContext, not the target param
[20:10:13] <dmlloyd> pre-destroy methods, that is
[20:13:31] *** alesj has quit IRC
[20:14:01] * smarlow trying again...
[20:15:10] *** jwulf has joined #jboss-as7
[20:20:54] *** aloubyansky has quit IRC
[20:22:07] * smarlow looking a little better, made it through the AS7 build :)
[20:26:48] *** adietisheim has quit IRC
[20:28:23] *** jpederse has joined #jboss-as7
[20:33:25] <jbossbot> git [jboss-as] push master 8d20050.. bstansberry at jboss dot com [JBAS-9137] Correct global operation error handling
[20:33:26] <jbossbot> jira [JBAS-9137] Improper error reporting from the global operation handlers [Open (Unresolved) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-9137
[20:33:26] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/987bb5a...8d20050
[20:35:37] <Nihility> wolfc: so you are against merging stuart's patch then :)
[20:35:50] *** adietisheim has joined #jboss-as7
[20:35:57] *** irooskov has joined #jboss-as7
[20:35:59] <wolfc> Nihility, no regression is merge in my book
[20:36:11] <Nihility> ah ok
[20:37:11] <wolfc> Nihility, but if it's unguarded by a (good) test than *it* can regress unnoticed
[20:37:35] <baileyje> dmlloyd: Do actually have anything creating a client for  a component?  createClient
[20:37:43] <baileyje> doesn't seem to have any usage..
[20:38:02] <wolfc> baileyje, not yet, but we need something for WS, MDB and RS
[20:39:27] <wolfc> baileyje, there is a bug in createClient where it tries to create interceptors. that is wrong.
[20:40:39] <baileyje> wolfc: Where should they be created?
[20:42:13] <wolfc> baileyje, there are created in createInstance https://github.com/jbossas/jboss-as/blob/master/ee/src/main/java/org/jboss/as/ee/component/AbstractComponent.java#L146
[20:42:28] *** pil-dinner is now known as pilhuhn
[20:43:11] <baileyje> right..
[20:44:57] <wolfc> as for the client / ComponentEntry bit, https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/messagedriven/MessageDrivenComponent.java#L102 and https://github.com/wolfc/jboss-as/blob/ejb3-ws/webservices/server-integration/src/main/java/org/jboss/as/webservices/invocation/InvocationHandlerEJB3.java#L133 need something
[20:45:19] <wolfc> been puzzling all day without real success
[20:46:08] <wolfc> something in the lines of an invocation chain: ProxyHandler -> ComponentEntry -> ComponentInterceptor
[20:46:56] <wolfc> but at the end of the day it's more sugar then real functionality. There isn't really anything failing a.t.m.
[20:48:18] *** AndyTaylor has quit IRC
[20:49:37] *** hbraun has quit IRC
[20:50:52] <baileyje> wolfc: Yeah.  I am looking into the EJB3 async support.  dmlloyd mentioned the interceptor needed to be on the client.
[20:51:06] <dmlloyd> one sec pleaswe.
[20:51:16] <baileyje> dmlloyd: np
[20:52:13] <dmlloyd> okay I'm back.
[20:52:51] <dmlloyd> ComponentEntry is the right interface to use to invoke on a component from the "outside world"
[20:53:16] <dmlloyd> the proxy handler should be calling into the client interceptor chain, which should use ComponentEntry
[20:53:30] <dmlloyd> as for createClient, I need to have a look at it again
[20:53:56] <smarlow> dmlloyd, baileyje:  https://github.com/scottmarlow/jboss-as/commit/b6e722b102060eba03669717ca0c58218eac9044 has the changes that we discussed.  Let me know what further should change...
[20:53:57] <jbossbot> git [jboss-as] b6e722b.. Scott Marlow pass ComponentInstance into ComponentLifecycle.  skeletons for SFSB lifecycle
[20:54:37] <wolfc> we need spots of doc on ComponentEntry and ComponentView. Their relation (if any) is obscured.
[20:56:13] *** stelios has quit IRC
[20:56:19] <dmlloyd> hmm, I don't know why I did this.
[20:56:37] <dmlloyd> it would be right for MBs, just out of coincidence really, but that's about it...
[20:59:58] *** maxandersen has joined #jboss-as7
[20:59:58] *** ChanServ sets mode: +v maxandersen
[21:01:02] <dmlloyd> the problem is that it assumes we have per-method, component-level interceptors
[21:01:03] <dmlloyd> which is not the case
[21:01:38] <dmlloyd> though perhaps it should be
[21:01:58] <dmlloyd> or perhaps not... hm
[21:02:03] <wolfc> the correct statement is: component interceptors are bound to view methods and tied to the instance lifeycle
[21:02:24] <dmlloyd> component interceptors are not tied to the instance lifecycle
[21:02:25] <wolfc> which is a very tricky statement to interpret correctly :-)
[21:02:32] <dmlloyd> (currently)
[21:03:11] <wolfc> we actually have two stacks
[21:03:29] *** jamezp_afk is now known as jamezp
[21:03:42] <dmlloyd> three
[21:03:47] <dmlloyd> including client interceptors
[21:04:02] <wolfc> I'm a sad panda :-)
[21:04:21] * dmlloyd has to have his drawing in front of his face to remember it all
[21:04:30] * dmlloyd is definitely going to document this piss out of this asap
[21:06:27] <wolfc> https://github.com/jbossas/jboss-as/blob/master/ee/src/main/java/org/jboss/as/ee/component/AbstractComponent.java#L144
[21:06:43] <wolfc> that's the last stack
[21:07:59] <wolfc> one problem in there for EJBs is that a view class does not fully identify a view
[21:08:15] <wolfc> for example both WS and no-interface can use the bean class
[21:11:45] <dmlloyd> yeah the per-instance+per-method interceptor set
[21:12:11] <dmlloyd> whereas the correct entry point is really the component interceptor chain
[21:12:18] <dmlloyd> with the target method being set by the caller
[21:12:28] <dmlloyd> (along with the context data, if there's something special about it)
[21:13:12] <dmlloyd> from the component interceptor onwards, is there any difference between WS and no-interface invocation?
[21:13:28] <dmlloyd> assume that upon entry, the caller will have set up the target, method, context etc.
[21:14:04] <wolfc> it depends on how we want to do security & tx
[21:14:40] <wolfc> if we ultimately want direct method calls to (for example) 'mandatory' then the chains can differ
[21:14:47] <dmlloyd> presumably the server-side tx/security interceptors are at the component level, though that leaves the question of per-method stuff aside for the moment
[21:16:00] <dmlloyd> I guess I should put the question another way.  Do we need distinct per-(bean-)method, component-level (pre-association) chains for the purposes of per-method security and txn config?
[21:17:05] <wolfc> if the tx attr is mandatory and there is no tx then a component-level must throw TxRequired
[21:17:28] <dmlloyd> tx attr is per-method?
[21:17:47] *** miclorb has joined #jboss-as7
[21:18:01] <wolfc> per-method/per-method-intf/per-view-class
[21:18:04] <wolfc> 13.3.7
[21:18:09] *** jclingan has joined #jboss-as7
[21:18:23] <dmlloyd> okay so we know that at least has to change because we do not have per-method component-level interceptors today
[21:19:22] <wolfc> it's a tripled key
[21:19:37] <wolfc> per method/method-intf/view-class, not just per-method
[21:19:48] <dmlloyd> ah I see
[21:20:01] <dmlloyd> well it's as good as per-method for our purposes
[21:20:06] <dmlloyd> argh, one sec phone
[21:21:13] <dmlloyd> anyway
[21:21:14] <wolfc> I think we're making it too difficult for ourselves. The whole per-method business is an optimization.
[21:21:24] <dmlloyd> because we use Methods as our key
[21:21:45] <wolfc> Can't we hide that optimization somehow?
[21:21:46] <dmlloyd> I'm still trying to understand under what circumstances we could have two views of the same class
[21:21:59] <dmlloyd> yes, possibly, but not until I understand the whole problem :)
[21:22:23] <dmlloyd> mainly when there's an XML descriptor?
[21:23:33] <wolfc> when there is no xml descriptor then problem can only occur at class level, @Local(A.class, B.class) A says TxMandatory, B says TxRequired
[21:23:49] <wolfc> Even in that case Method is not good enough a key
[21:24:16] <wolfc> If the method comes from a shared super class
[21:24:57] <wolfc> With XML descriptor we can add method-intf to the mix
[21:26:08] * wolfc is away in a couple of min
[21:27:30] <wolfc> so maybe we should only process interceptors on component methods and let the interceptors themselves deal with the problem
[21:28:16] <dmlloyd> even if the method comes from a shared superclass we have distinct instances per view type, so that's really not a problem
[21:28:39] <dmlloyd> the real problem with the current approach is that it doesn't deal with two views of the same type
[21:28:54] <wolfc> you mean two views of the same class?
[21:29:08] <dmlloyd> yeah
[21:29:41] <wolfc> crock, I'm gone for a while
[21:29:58] <dmlloyd> okay well I"ll keep thinking about this.
[21:31:47] *** bstansberry_ has joined #jboss-as7
[21:31:47] *** bstansberry has quit IRC
[21:31:47] *** bstansberry_ has quit IRC
[21:31:48] *** bstansberry_ has joined #jboss-as7
[21:31:48] *** ChanServ sets mode: +v bstansberry_
[21:31:48] *** bstansberry_ is now known as bstansberry
[21:33:57] *** balunasj has joined #jboss-as7
[21:34:02] *** balunasj has quit IRC
[21:34:02] *** balunasj has joined #jboss-as7
[21:34:02] *** ChanServ sets mode: +v balunasj
[21:36:37] *** alesj has joined #jboss-as7
[21:37:27] <smarlow> Does AbstractComponentDescription have a way to add an invocation interceptor?  The closest seems to be addAroundInvokeMethod
[21:38:02] <smarlow> I want my callback/interceptor to be invoked, every time that a SFSB is called
[21:38:31] <smarlow> wolfc, dmlloyd, baileyje:  Anything for that ^ already built?
[21:39:06] <dmlloyd> you want to add an InterceptorFactory
[21:41:08] *** jamezp has left #jboss-as7
[21:41:54] <baileyje>  hmm.  Should @Resource and @EJB injections be processed on super classes....
[21:44:05] *** balunasj has quit IRC
[21:46:13] *** jwulf has quit IRC
[21:47:17] <smarlow> dmlloyd:  should we have a addInterceptorFactory method on AbstractComponentDescription or something more specific for adding an InvocationInterceptor
[21:52:46] <dmlloyd> baileyje: yes... I think
[21:53:01] <baileyje> I think so too.  I am guessing we aren't doing that now.
[21:53:16] <baileyje> since we just ask the index about the component itself.
[21:53:53] <dmlloyd> smarlow, I think we probably need a better general mechanism.  for now though, and addInterceptorFactory method on the description class should be okay.
[21:54:32] <stuartdouglas> morning
[21:58:09] *** jamezp has joined #jboss-as7
[21:59:18] <Nihility> stuartdouglas: hey your patch has a conflict on phase with a change carlo made
[22:00:48] <stuartdouglas> do you want me to rebase?
[22:00:50] *** mmoyses has quit IRC
[22:02:25] <Nihility> stuartdouglas: sure if you dont mind
[22:06:29] *** alesj has quit IRC
[22:06:41] *** pilhuhn has quit IRC
[22:06:53] *** alesj has joined #jboss-as7
[22:08:01] <baileyje> dmlloyd: My initial plan for the async stuff is to at least capture which methods are async and get them on the configuration for the component.
[22:08:11] <baileyje> Since I am not clear how all the client stuff is working yet
[22:08:30] <dmlloyd> yeah, I'm not too clear on it either.  I have a bunch of disjoint ideas.
[22:08:42] <dmlloyd> drawing some pictures now.
[22:08:58] <baileyje> but no matter what we need the annotations processed.
[22:09:06] <dmlloyd> yeah.
[22:09:14] <baileyje> So I figure I will get that out of the way
[22:09:22] <baileyje> after my dog goes to the vet..
[22:09:26] <dmlloyd> I think all the notes I put in that JIRA are still relevant.
[22:11:18] <baileyje> dmlloyd: Yeah..  As far as #3 goes, is that clear at this point?
[22:11:25] <baileyje> "Add appropriate async interceptor to client interceptors corresponding to async methods"
[22:11:58] <dmlloyd> it's relevant but we don't really have client interceptor chains
[22:12:31] <dmlloyd> the important thing is that ComponentEntry has an isAsync method for the client method
[22:12:33] <baileyje> RIght..
[22:12:37] <dmlloyd> if we have that, we can make everything else work
[22:12:56] <dmlloyd> the async interceptor is only used for in-VM invocation
[22:13:10] <baileyje> dmlloyd: Yeah.  I have most of the initial stuff there.  Just working on getting the annotation processing done
[22:13:46] <baileyje> ok.  back in a biut
[22:13:47] <baileyje> bit
[22:14:02] *** opalka has joined #jboss-as7
[22:14:02] *** opalka has joined #jboss-as7
[22:14:02] *** ChanServ sets mode: +v opalka
[22:14:25] *** pgier has quit IRC
[22:16:29] *** miclorb has quit IRC
[22:17:50] <stuartdouglas> Nihility: I have rebased
[22:19:05] <Nihility> thanks
[22:19:39] <jbossbot> git [jboss-as] push master 2a76cf2.. Stuart Douglas Add another class loading tests and fix DUP order so integration tests pass
[22:19:40] <jbossbot> git [jboss-as] push master a95e704.. Stuart Douglas Update ejb local view annotation processor
[22:19:40] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/8d20050...a95e704
[22:20:57] *** miclorb_ has joined #jboss-as7
[22:22:52] *** jpederse has quit IRC
[22:23:32] *** ALR has quit IRC
[22:30:58] *** maxandersen1 has joined #jboss-as7
[22:30:58] *** maxandersen has quit IRC
[22:34:37] *** jfd has quit IRC
[22:40:10] *** asoldano has quit IRC
[23:02:01] *** pferraro has quit IRC
[23:02:56] *** miclorb_ has quit IRC
[23:04:40] *** opalka has quit IRC
[23:09:20] *** wolfc has quit IRC
[23:19:01] *** maxandersen1 has quit IRC
[23:20:56] *** miclorb_ has joined #jboss-as7
[23:20:56] *** fnasser has quit IRC
[23:21:50] *** fnasser has joined #jboss-as7
[23:32:33] *** jpearlin has joined #jboss-as7
[23:48:20] *** mbg has quit IRC
[23:53:39] *** jwulf has joined #jboss-as7

   March 24, 2011  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >