[00:15:57] *** jamezp has quit IRC
[00:32:46] *** jamezp has joined #jboss-as7
[00:36:32] *** aslak has quit IRC
[00:43:59] <Nihility> baileyje: Not yet, but will be soon
[00:44:22] <Nihility> jpearlin: Thanks!
[00:54:44] <bstansberry> hmm; nasty
[00:55:09] <bstansberry> client passes a deployment add into the master DC with an input stream attached
[00:55:41] <bstansberry> the master will consume it, but when it pushes the op to the slaves the stream is consumed
[00:56:02] <bstansberry> the operation for the slaves needs to have the hash instead of the stream
[00:58:00] <bstansberry> trick is how to change the operation without sticking nasty operation-specific details in the domain controller
[01:00:18] <stuartdouglas> Has anyone seen this before? http://pastebin.com/mmSQxi2b
[01:00:59] <bstansberry> sounds like jamezp did
[01:01:13] <bstansberry> and i saw it with some domain deployment stuff i'm doing
[01:01:45] <bstansberry> in my case it was due to the "content" file in the repo being empty
[01:01:58] <bstansberry> due to the problem ^^^
[01:02:18] <bstansberry> but in standalone, if the file is empty, it must be for some other reason
[01:02:34] <stuartdouglas> I am hitting it occasionally running the weld tck
[01:03:48] *** jamezp has quit IRC
[01:04:27] *** jamezp has joined #jboss-as7
[01:05:05] <jamezp> bstansberry: That looks like what I'm seeing too.
[01:05:53] <stuartdouglas> It seems to be happening to me when the deployment fails
[01:06:55] <jamezp> For me it only happens on an undeploy if I use DeploymentPlanBuilder.undeploy(file).remove(name_of_app).
[01:08:14] <stuartdouglas> found it
[01:08:59] <stuartdouglas> line 282 of ModelControllerOperationHandlerImpl
[01:09:09] <stuartdouglas> it writes PARAM_OPERATION to the stream
[01:09:43] <stuartdouglas> I think the solution is just to remove that line, but I am not really that familiar with that bit of the code
[01:10:00] <stuartdouglas> bstansberry: does this seem to be the correct solution?
[01:10:33] <bstansberry> hang on; let me switch workspaces
[01:12:17] <stuartdouglas> actually that is probably not the solution
[01:12:56] <stuartdouglas> I think there should be an expectHeader(input, ModelControllerClientProtocol.PARAM_OPERATION); in AbstractModelControllerClient
[01:14:13] <bstansberry> removing the line is the correct solution
[01:14:20] <bstansberry> i'll push that in a sec
[01:14:36] <jamezp> Sweet, thanks guys.
[01:21:12] <jbossbot> git [jboss-as] push master eeaef78.. bstansberry at jboss dot com Remove extraneous PARAM_OPERATION
[01:21:12] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/6a5f352...eeaef78
[01:21:34] <bstansberry> stuartdouglas, jamezp: thanks. sorry about that :(
[01:21:56] <jamezp> Hey no problem. Thanks for the quick fix.
[01:28:38] <jamezp> Perfect. Fixed that error, now to figure out why it won't perform the undeploy :-)
[01:29:03] <stuartdouglas> jamezp: In arquillian tests?
[01:29:08] <stuartdouglas> If so, I just beat you to it :-)
[01:29:35] <jamezp> Ah, not in a maven plugin I'm working on.
[01:30:00] <stuartdouglas> ok, different problem :-)
[01:30:19] <jamezp> Yes indeed. Probably me just using it wrong.
[01:45:17] <jamezp> My problem was all me :-) I was using the incorrect name in the undeploy() method.
[01:48:35] <jbossbot> git [jboss-as] push master aa95d09.. bstansberry at jboss dot com Remove left over 'New' file from detyped branch
[01:48:36] <jbossbot> git [jboss-as] push master 40ae31b.. bstansberry at jboss dot com Fix xml marshalling of <domain-controller><remote/>
[01:48:36] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/eeaef78...40ae31b
[01:56:01] *** smcgowan has joined #jboss-as7
[01:56:01] *** ChanServ sets mode: +v smcgowan
[02:04:13] *** jamezp is now known as jamezp_afk
[02:07:09] <jpearlin> bstansberry:  the patch I sent Nihility earlier for the deployment upload via http has the fix to remove the name and runtimeName from the upload handler
[02:07:15] <jpearlin> is that still okay?
[02:07:32] <bstansberry> yes, that should be ok
[02:08:08] <bstansberry> i.e. I haven't looked at the patch, but it's ok to remove those
[02:08:09] <jpearlin> great..thanks.  I know that a lot of changes have gone in since we talked about it, so I wanted to make sure nothing changed with regards to removing those parameters
[02:08:23] <jpearlin> noted ;)
[02:20:48] *** jamezp_afk has left #jboss-as7
[02:32:25] <Nihility> Hey guys I'll be looking at this stuff in 15, kids and timezone changes don't work well together
[02:33:18] <bstansberry> AFAICT adults don't enjoy them much either
[02:47:52] *** jpearlin has quit IRC
[02:56:06] <Nihility> haha good point
[02:56:23] <Nihility> dmlloyd: did you merge mmoyers patch?
[03:05:20] *** smcgowan has quit IRC
[03:09:43] <Nihility> baileyje: ping
[03:09:52] <baileyje> yo
[03:10:07] <Nihility> is your patch ready for merging you think
[03:10:23] <baileyje> Yeah.  I think it is ready as I can get it.
[03:10:40] <baileyje> Well in the time we have that is
[03:12:59] <Nihility> ok :)
[03:13:21] <baileyje> haven't had time to properly test the XA DSs
[03:13:36] <Nihility> im not too worried about that
[03:13:44] <baileyje> yeah.  I wasn't either :)
[03:14:12] <Nihility> hey what did you think of that idea to support add module jdbc drivers to the jdbc service
[03:14:22] <Nihility> s/add/adding
[03:14:24] <baileyje> I like the idea.
[03:14:39] <baileyje> Not sure what dmlloyd will think with his deployer bit.
[03:14:41] <Nihility> so that way it uses the same code path
[03:15:03] <Nihility> its just an alternative source to the driver
[03:15:59] <Nihility> ok cool
[03:16:16] <Nihility> ill put that on the "things to do when we are blocking on other thigns list"
[03:16:43] <baileyje> Nihility: SO what is next?  I need to see where scott is with the JPA stuff
[03:16:53] <Nihility> we need to make sure JPA works
[03:16:57] <baileyje> once the DS stuff is there, I will check back into that
[03:17:09] <Nihility> and then there is all the other stuff on DOC-16608
[03:18:28] <Nihility> stuartdouglas: ping
[03:18:34] <stuartdouglas> Nihility: pong
[03:18:39] <Nihility> excellent
[03:18:47] <Nihility> stuartdouglas: how does weld look
[03:18:55] <Nihility> stuartdouglas: can we scratch that one off of DOC-16608
[03:18:56] <Nihility> ?
[03:19:18] <stuartdouglas> It does not have EJB or JPA integration yet
[03:19:30] <stuartdouglas> but other than that is looks pretty good
[03:19:39] <stuartdouglas> I have started on basic EJB integration today
[03:20:13] <stuartdouglas> The TCK currently fails 150 out of 800ish tests
[03:20:25] <stuartdouglas> pretty much all EJB related
[03:20:29] <Nihility> ah ok how likely do you think it is that we can get it included
[03:20:50] <baileyje> Nihility: EJB injection is basically there.  wolfc mentioned there was a fine print kind of thing missing
[03:21:11] <Nihility> yeah i think it was bean names using module ids
[03:21:19] <Nihility> foo.jar#MySessionBean
[03:21:29] <stuartdouglas> Nihility: not really sure, It will not be 100% no matter what
[03:21:48] <Nihility> stuartdouglas: ok dont care about the 100%
[03:21:54] <stuartdouglas> when JPA gets merged I should be able to get weld's JPA integration up and running fairly quickly
[03:22:22] <stuartdouglas> when is the beta going to be released?
[03:22:23] <Nihility> using weld with ejbs in some form though would be a nice target if its possible
[03:22:49] <baileyje> Nihility: Do you happen to have the section number on the EJB injection piece?  I can take care of that
[03:23:08] <Nihility> baileyje: search for ejb-link
[03:23:25] <Nihility> stuartdouglas: (see title of IRC chat)
[03:23:33] <stuartdouglas> ah :-)
[03:23:51] <Nihility> next question i have is JAX-RPC
[03:24:04] <Nihility> was there anything else we need to do in the long run
[03:24:36] <stuartdouglas> I was working on JAX-RS
[03:24:36] <jbossbot> git [jboss-as] push master 6c64725.. John E. Bailey Install datasources durring bootstrap without the use of a RAR
[03:24:37] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/40ae31b...6c64725
[03:25:12] <stuartdouglas> and I think there is some ejb integration that is required
[03:25:28] <stuartdouglas> and a lot of testing :-)
[03:26:00] *** JimMa has joined #jboss-as7
[03:26:16] <Nihility> stuartdouglas: ah ok, basically im trying to go through the list of what we have and what we dont, and what priorities we MUST take care of before the scheduled release on the 15th (which im trying to do on the 14th evening since I am leaving for a family wedding on the 15th)
[03:27:37] <stuartdouglas> ok, should I be focussing on the weld EJB integration or is there something else you want me to look at?
[03:27:51] <Nihility> that sounds right yeah
[03:27:59] <Nihility> or sounds like the most important
[03:28:08] <baileyje> Nihility: for the EJB links, is it allowed to reference other apps?
[03:28:13] <Nihility> unless you think its unobtainable and then we would prioritize something else
[03:29:15] <Nihility> baileyje: IIRC its a fully global ref
[03:29:29] <Nihility> baileyje: but i dont know without checking more into it
[03:29:37] <stuartdouglas> I think I should be able to get it done
[03:30:12] <Nihility> baileyje: its not a ultra-high priority thing though, as i doubt anyone really uses it anyway
[03:30:18] <stuartdouglas> The RAX-RS stuff is just the ability to use EJB's as JAX-RS resources, and I think we can probably get away with letting that slip until the next release
[03:30:28] <Nihility> agreed
[03:30:42] <Nihility> basically what the goal of this release was supposed to be
[03:30:45] <baileyje> I will leave it be if there is something more important.  Like JPA
[03:31:34] <Nihility> was an initial EE web profile impl that is usable enough that people can play around, send feedback, be motivated to contribute
[03:31:51] <Nihility> so we are really going for breadth at this point
[03:32:03] <Nihility> and i think we are mostly there
[03:32:07] <Nihility> certain critical things are:
[03:32:17] <Nihility> servlet 3, ejb3, and weld
[03:32:30] <Nihility> thats what i suspect people will do to play with this stuff
[03:32:36] <stuartdouglas> I have some stuff ready to merge in my master
[03:33:03] <Nihility> stuartdouglas: oh i forgot to ask you, is there like some kind of weld demo app, like dvd store or something
[03:33:26] <stuartdouglas> There are a few, the best one is probably pastecode, which needs the EJB integration to work
[03:33:40] <stuartdouglas> otherwise we have permalink and numbergess, both of which work
[03:34:09] <stuartdouglas> and there are some seam demo apps as well, such as princess-rescue and booking
[03:34:20] <stuartdouglas> princess-rescue works, but I am not sure about booking
[03:36:18] <stuartdouglas> actually I am not sure if booking works as all at the moment, and I have a feeling it needs ejb's as well
[03:40:31] <stuartdouglas> Is it just me or is there a problem with filesystem based deployments at the moment?
[03:43:13] <Nihility> cool
[03:43:31] <Nihility> stuartdouglas: you need to drop a .dodeploy file now
[03:43:36] <stuartdouglas> ah
[03:43:48] <Nihility> deployment.war.dodeploy
[03:43:49] <Nihility> etc
[03:44:23] <Nihility> reason is fixing the bug where you get a partial copy
[03:44:28] <Nihility> in between deploy scans
[03:44:43] <Nihility> we can in the future improve it to understand zips
[03:44:52] <Nihility> and detect a completed and valid copy
[03:44:59] <Nihility> but that wont work with exploded deploy
[03:45:18] <stuartdouglas> or even if the server is starting up then you could assume that the deployment is compied
[03:45:23] <stuartdouglas> cpied even
[03:45:31] * stuartdouglas gives up
[03:45:42] <Nihility> ah good point
[03:45:47] <Nihility> one thing thats missing though
[03:45:52] <Nihility> is that we were supposed to log a message
[03:45:53] <Nihility> saying
[03:46:14] <Nihility> "Noticed foo.ear, once file is ready for deployment, drop a foo.ear.dodeploy file to activate"
[03:47:59] <stuartdouglas> just tried out pastecode, it failed trying to inject the TimerService
[03:48:10] <Nihility> ah yeah
[03:48:13] <Nihility> we dont have timer yet
[03:48:37] <Nihility> how many of the demos does it break without it?
[03:48:51] <Nihility> if its a lot maybe we could implement enough of it that it works
[03:48:52] <stuartdouglas> I think just the one
[03:49:21] <stuartdouglas> most of the other examples are really simple though, just showing off one thing
[03:49:28] <Nihility> hmm
[03:49:30] <Nihility> maybe we should do it
[03:49:41] <stuartdouglas> I'll try the booking example
[03:49:57] <stuartdouglas> as it is the other non-trivial example
[03:50:24] <Nihility> baileyje: hey if you get blocking on jpa, instead of ejb-link, could you look into how hard you think it would be to implement a "lite" version of ejb timers
[03:51:00] <stuartdouglas> Nihility: adding the timers may not actually be enough to get the example to run :-(
[03:51:10] <stuartdouglas> There is probably other ejb related stuff that is broken as well
[03:51:14] <Nihility> ah
[03:51:19] <Nihility> maybe thats a bad idea then
[03:53:49] *** jamezp has joined #jboss-as7
[03:58:33] <Nihility> jamezp: hi
[03:59:10] <jamezp> Hello
[03:59:31] <Nihility> jamezp: i think the issue you uncovered was fixed
[04:00:19] <jamezp> It was indeed. Rebased and it worked perfectly.
[04:00:45] <stuartdouglas> the booking example does not work either, but I think it is because it is broken, not due to AS7 problems
[04:02:46] *** miclorb_ has quit IRC
[04:09:46] *** miclorb has joined #jboss-as7
[04:17:04] <Nihility> stuartdouglas: any of them work? :)
[04:17:29] <stuartdouglas> booking and pastecode failed
[04:17:39] <stuartdouglas> but some of the other ones work
[04:17:44] <Nihility> ah ok
[04:18:00] <Nihility> what does pastecode use timers for?
[04:18:05] <Nihility> deleting entries?
[04:18:47] <stuartdouglas> not really sure, I have not really looked at the code, I think it has some kind of flooding protection that bans you if you post to much
[04:18:59] <stuartdouglas> it may be used to lift the ban after a set time or something like that
[04:19:16] <stuartdouglas> but I think it also needs JPA integration, and probably a few other things as well
[04:19:42] <stuartdouglas> I think the seam booking example is just broken at the moment, so I did not spend much time trying to get it to run
[04:20:12] <stuartdouglas> should we be setting up a java:module context for ears?
[04:20:14] *** bgeorges has joined #jboss-as7
[04:20:14] *** ChanServ sets mode: +v bgeorges
[04:20:33] <stuartdouglas> at the moment it is causing service name conflicts if you have foo.jar inside foo.ear
[04:21:35] <Nihility> eww
[04:21:58] <stuartdouglas> yea, and the weld TCK uses that pattern a lot
[04:22:29] <Nihility> yeah java:module doestn make sense on an ear
[04:22:38] <stuartdouglas> that is what I though
[04:22:45] <Nihility> but im wondering if our service names are wrong
[04:23:07] <stuartdouglas> it will also cause problems if we have foo.war and foo.jar
[04:23:17] <stuartdouglas> but I think the spec does not require that to work anyway
[04:23:19] <Nihility> let me double check what module name defaults are supposed to be
[04:23:27] <stuartdouglas> as you are not allowed to have two modules with the same name
[04:25:10] <stuartdouglas> also I just noticed that having an ejb-jar in your deployment will cause it to fail, it is fixed in my trunk
[04:32:37] <Nihility> ROFL
[04:32:41] <Nihility> the spec contradicts itself
[04:32:43] <Nihility> oops
[04:33:05] <stuartdouglas> which sections?
[04:33:08] <Nihility> take a look at the xample on the bottom of pag 174 and top of 175
[04:33:28] <stuartdouglas> which spec?
[04:33:34] <Nihility> then read the last sentence on the paragraph right before EE.8.1.3
[04:33:40] <Nihility> (ee)
[04:35:32] <stuartdouglas> hmm
[04:36:23] <stuartdouglas> I think that we should probably follow the way it is layed out in the example
[04:36:39] <stuartdouglas> rather than removing the directory names
[04:37:13] <Nihility> it says also thought that we can generate a unique name in the event of a conflict
[04:37:51] <stuartdouglas> Isn't that just for the application name?
[04:38:17] <Nihility> it has to be done for modules too
[04:38:21] <Nihility> because you can access them in app
[04:38:31] <Nihility> java:app/module-name/blah
[04:38:54] <Nihility> that last sentence bugs me
[04:38:56] <stuartdouglas> yea, but where does it say that we can generate our own
[04:39:01] <Nihility> do you agree its a conflict
[04:39:03] <stuartdouglas> if there is a conflic
[04:39:23] <stuartdouglas> yea, there is definitely a conflict
[04:39:52] <Nihility> The name of a module
[04:39:52] <Nihility> must be unique within an application. If and only if the name is not unique (e.g.,
[04:39:52] <Nihility> because two names are identical after removing different filename extensions) the
[04:39:52] <Nihility> deployment tool may choose new unique names for any of the conflicting
[04:39:53] <Nihility> modules; module names that do not conflict must not be changed.
[04:40:29] <jamezp> If I'm following along correctly it's on page 174 of the EE implementation spec.
[04:40:32] <stuartdouglas> got it
[04:41:15] <Nihility> the only other option is we error
[04:41:32] <stuartdouglas> I think people expect it to work
[04:41:37] <Nihility> right
[04:43:47] <Nihility> imo the directory name should be included
[04:43:58] <Nihility> else the following can conflict
[04:44:03] <stuartdouglas> agreed
[04:44:04] <Nihility> ejbs/foo.jar
[04:44:09] <Nihility> web/foo.war
[04:45:11] <Nihility> btw modules also show up in java:global
[04:46:15] <Nihility> so we have an item on our TODO to bind java:app and standalone java:modules to java:global
[04:48:58] <stuartdouglas> where do the modules show up in java:global?
[04:49:11] <stuartdouglas> and why do we need to bind java:app to java:global?
[04:49:18] <Nihility> java:global/app or standalone-module-name/module-name/component-name
[04:49:57] <Nihility> spec requires it for universal/portable addressing of @Remote components
[04:50:19] <Nihility> (@Local can be allowed if a vender chooses to)
[04:50:44] <Nihility> standalone modules dont have a redundant module-name
[04:50:45] <stuartdouglas> ah, this is the EJB spec
[04:51:23] <Nihility> yeah technically we just have to bind managed beans in java:app
[04:51:32] <Nihility> not java:global
[04:51:56] <Nihility> but i think for simplicity sake it makes sense to auto-bind app and module ns' no matter whats in them
[04:52:24] <stuartdouglas> Does that have security implications?
[04:53:05] <stuartdouglas> imho there is a big difference between defining EJB's views in java:global and binding the whole java:module ns to java:global
[05:06:13] <Nihility> well sort of
[05:06:59] <Nihility> jndi, well ee as a whole isnt really secured against hostile applications wanting to screw with other applications
[05:11:45] <Nihility> also like take the managed bean example
[05:11:59] <Nihility> the worst thing that can happen is i use someone elses managed bean's class
[05:12:03] <Nihility> which can be done wihtout jndi
[05:12:13] <Nihility> (just add a class-path: and use new Class)
[05:32:22] <stuartdouglas> Incidently I found that it was not ear's module context that was causing problems, but the other conflicting case where you have foo.jar and foo.war in the same ear
[05:38:02] <Nihility> ah
[05:38:36] <stuartdouglas> I'm going to implement something that changes the module name if it detects a conflict for now
[05:38:56] <stuartdouglas> so we would have foo-war and foo-jar instead of two foo modules
[05:39:12] <Nihility> yeah good idea
[05:41:19] *** irooskov has quit IRC
[06:02:43] <bstansberry> stuartdouglas: FYI http://svn.jboss.org/repos/jbossas/trunk/server/src/main/java/org/jboss/deployment/ModuleNameDeployer.java
[06:03:09] <bstansberry> is the AS 6 logic for the dealing with app and module names
[06:03:41] <Nihility> ah
[06:03:42] <Nihility> cool
[06:06:48] * stuartdouglas looks
[06:09:34] <stuartdouglas> so it looks like you can get different module names for the same deployment depending on the order that they pass through the processor?
[06:10:54] <jbossbot> git [jboss-as] push master e129449.. Jonathan Pearlin Added support to HTTP server to handle deployment upload request....
[06:10:55] <jbossbot> git [jboss-as] push master 1ea1a4f.. Jason T. Greene Use a fixed path not a query param...
[06:10:55] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/6c64725...1ea1a4f
[06:16:15] <Nihility> stuartdouglas: yours is next
[06:18:31] <jbossbot> git [jboss-as] push master f8e6b85.. Stuart Douglas Add javaee.api to all external modules
[06:18:31] <jbossbot> git [jboss-as] push master 6e44753.. Stuart Douglas Add validation services to weld
[06:18:31] <jbossbot> git [jboss-as] push master da588ac.. Stuart Douglas Fix undeploy not working if deployment fails
[06:18:31] <jbossbot> git [jboss-as] push master a8ae424.. Stuart Douglas Initial weld ejb integration
[06:18:32] <jbossbot> git [jboss-as] push master c874026.. Stuart Douglas add toString()
[06:18:32] <jbossbot> git [jboss-as] push master d3fd279.. Stuart Douglas Fix ejb-jar.xml parsing
[06:18:32] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/1ea1a4f...d3fd279
[06:19:33] <Nihility> ok guys im going to get some rest
[06:19:38] <Nihility> and try to get an early start
[06:19:48] <stuartdouglas> ok, when is jpa going to be merged?
[06:19:58] <Nihility> baileyje: you around?
[06:20:44] <stuartdouglas> cause it would be good if I could implement jpa integration for weld for this release
[06:21:01] <stuartdouglas> As I am kinda doubting that I will get the ejb integration done
[06:21:58] <Nihility> baileyje: was helping smarlow on it, i think it should merge early tomorrow, which i know doesnt help you much damn!
[06:22:19] <stuartdouglas> I could probably do up a patch against his branch
[06:22:46] <stuartdouglas> and then either you can cherry pick it, or I can fix it up when I wake up
[06:23:02] <stuartdouglas> does anyone know how functional it is?
[06:23:37] <Nihility> https://github.com/scottmarlow/jboss-as/commits/master
[06:24:15] <Nihility> it looks like baileyje's stuff isnt up there
[06:24:22] <Nihility> local copy i guess
[06:25:36] <Nihility> baileyje was helping fix PU injection basically to have it use proper definitnios and so on
[06:26:00] <Nihility> the other stuff supposedly works
[06:26:48] <stuartdouglas> hmm, PU injection is kinda what I need for weld...
[06:27:15] <Nihility> yeah so probablly not helpful
[06:27:58] <Nihility> http://community.jboss.org/wiki/Beta1MUSTHAVEList
[06:28:46] <Nihility> looks like almost everything on there has someone assigned
[06:29:50] <Nihility> ok ill sync with you tomorrow
[06:41:20] *** jamezp has quit IRC
[07:01:13] <bgeorges> Nihility: How are things J ?
[07:01:43] <stuartdouglas> I think he went to bed
[07:02:19] <bgeorges> stuartdouglas: sounds like it
[07:02:58] <bgeorges> stuartdouglas: Did you have answer about JPA?
[07:03:40] <stuartdouglas> I will see what I can do with smarlow's branch
[07:03:48] <stuartdouglas> and get up early tomorrow :-)
[07:04:18] <bgeorges> stuartdouglas: thank you. How do you find working on Oz Time Zone ?
[07:05:01] <stuartdouglas> It's actually not to bad, because I tend to get up and start working fairly early
[07:05:30] <bgeorges> stuartdouglas: which is good with US Tz
[07:07:07] <stuartdouglas> yes, and I can usually get people in europe before they go to bed as well if I need to
[07:08:18] <bgeorges> stuartdouglas: am glad it works out well for you
[07:08:37] *** Jaikiran has joined #jboss-as7
[07:08:37] *** ChanServ sets mode: +v Jaikiran
[07:25:22] *** jwulf has joined #jboss-as7
[07:50:35] *** asoldano has joined #jboss-as7
[07:50:35] *** ChanServ sets mode: +v asoldano
[08:17:46] *** dimitris_ has joined #jboss-as7
[08:17:46] *** dimitris_ has joined #jboss-as7
[08:17:46] *** ChanServ sets mode: +v dimitris_
[08:26:46] *** miclorb has quit IRC
[08:27:17] *** opalka has joined #jboss-as7
[08:27:17] *** ChanServ sets mode: +v opalka
[08:33:16] *** jfclere has joined #jboss-as7
[08:33:16] *** ChanServ sets mode: +v jfclere
[08:34:48] <opalka> morning
[08:36:28] *** wolfc has joined #jboss-as7
[08:36:28] *** ChanServ sets mode: +v wolfc
[08:50:50] *** emuckenhuber has quit IRC
[09:09:41] *** aslak has joined #jboss-as7
[09:09:42] *** aslak has joined #jboss-as7
[09:09:42] *** ChanServ sets mode: +v aslak
[09:13:13] *** adietisheim has joined #jboss-as7
[09:19:03] *** japjap has joined #jboss-as7
[09:25:59] <Jaikiran> opalka: do you guys have a jbossws channel? japjap is looking for one to ask a question related to cxf
[09:26:25] <opalka> Jaikiran, not yet, but I plan to create one
[09:26:40] <opalka> Jaikiran, on which channel can I catch with him?
[09:26:57] <Jaikiran> opalka: he's right here :) japjap ^
[09:27:21] <opalka> japjap, what CXF problem U have?
[09:27:25] <opalka> japjap, Is it AS7 related?
[09:29:54] *** bstansberry is now known as bstans_zzz
[09:34:00] *** pilhuhn has joined #jboss-as7
[09:34:00] *** pilhuhn has joined #jboss-as7
[09:34:00] *** ChanServ sets mode: +v pilhuhn
[09:37:34] *** aslak has quit IRC
[09:37:57] *** aslak has joined #jboss-as7
[09:37:58] *** ChanServ sets mode: +v aslak
[09:44:28] *** maeste has joined #jboss-as7
[09:44:29] *** ChanServ sets mode: +v maeste
[09:45:00] *** slaboure has joined #jboss-as7
[09:47:09] *** emuckenhuber has joined #jboss-as7
[09:47:09] *** ChanServ sets mode: +v emuckenhuber
[09:50:29] <opalka> Jaikiran, What's the currents state of EJB3 in AS7? What's supported and what's still TODO?
[09:51:01] <opalka> Jaikiran, I'm wondering about this week priorities ;)
[09:51:03] <Jaikiran> opalka: the TODO bits are EJB tx (which is in progress in a separate branch) and @Lock/@DependsOn for Singleon
[09:51:19] <Jaikiran> opalka: we currently have support for SLSB, SFSB in upstream
[09:51:26] <Jaikiran> the basic deployments ofcourse
[09:51:48] <Jaikiran> once Tx bits get integrated later today, that should add more EJB support
[09:51:53] <opalka> Jaikiran, basic deployments == EJB3 beans that are only annotation driven, no DD support, right?
[09:52:08] <Jaikiran> opalka: right. DD support isn't planned for Beta!
[09:52:11] <Jaikiran> Beta1
[09:52:15] <Jaikiran> so that's currently out of scope
[09:52:23] <opalka> Jaikiran, OK, another question regarding switchboard
[09:52:27] <Jaikiran> sure
[09:52:51] <opalka> Jaikiran, U said few months ago this will target both AS6 and AS7? Is it still true? IOW can I reuse SB resource providers in AS7?
[09:53:17] <Jaikiran> opalka: AS7 has native support for what switchboard was meant to do. so no AS7 doesn't plan to have switchboard
[09:53:31] <opalka> Jaikiran, thought so
[09:53:54] <Jaikiran> opalka: the @EJB and @Resource injection is already avaialble in upstream
[09:53:59] <Jaikiran> baileyje added it
[09:54:20] <opalka> Jaikiran, good to know ;)
[09:54:21] <Jaikiran> i saw your JIRA about that @Resource value not being set, it probably is because DD isn't yet supported
[09:56:44] <stuartdouglas> opalka: @Resource injection should work for the WebServiceContext now
[09:58:34] <opalka> stuartdouglas, Yes, I saw your changes and they're looking pretty well
[09:59:02] <opalka> Jaikiran, I changed my "this week priorities" and I'll start playing with EJB3s
[09:59:27] <opalka> Jaikiran, I have few questions on you ;)
[09:59:41] <Jaikiran> opalka: sure
[10:00:55] <opalka> Jaikiran, did JBossWS EJB integration changed somehow ?
[10:01:03] <opalka> Jaikiran, from EJB3 PoV?
[10:01:24] <Jaikiran> opalka: from what i see in AS7, it's currently non-existent
[10:01:45] <opalka> Jaikiran, OK, I'll be more explicit ;)
[10:02:04] <opalka> Jaikiran, we used to have org.jboss.webservices.integration.deployers.WSEJBAdapterDeployer in AS6
[10:02:19] * Jaikiran checks its role
[10:03:02] <opalka> Jaikiran, which used to use
[10:03:04] <opalka> import org.jboss.wsf.spi.deployment.integration.WebServiceDeclaration;
[10:03:04] <opalka> import org.jboss.wsf.spi.deployment.integration.WebServiceDeployment;
[10:03:28] <opalka> Jaikiran, these are EJB/WS integration hooks
[10:03:56] <opalka> Jaikiran, and we used to use them to detect if SLSB is WS related or not
[10:04:27] <Jaikiran> opalka: would detecting the presence of @WebService be the only criteria?
[10:04:31] <Jaikiran> or is there more to it?
[10:04:36] *** alesj has joined #jboss-as7
[10:04:59] <opalka> Jaikiran, Not 100% sure
[10:05:14] <opalka> Jaikiran, But I think it was mainly about @WebService detection
[10:05:39] <opalka> Jaikiran, AFAIK if there was @WebService annotation your EJB beans implemented these integration hooks
[10:05:55] <opalka> Jaikiran, I'm wondering whether we shouldn't use Jandex for it in AS7
[10:06:58] <Jaikiran> opalka: yeah, that should be based on jandex in AS7
[10:06:58] <Jaikiran> @see LocalEjbViewAnnotationProcessor for an example
[10:07:08] <opalka> Jaikiran, OK
[10:07:11] <opalka> Jaikiran, another question
[10:07:14] <Jaikiran> sure
[10:07:21] <opalka> Jaikiran, in the aforementioned integration class
[10:07:26] <opalka> Jaikiran, there was WebServiceDeclarationAdapter inner class
[10:07:35] <opalka> Jaikiran, accessing EJB impl details
[10:07:56] <Jaikiran> right
[10:08:05] <opalka> Jaikiran, was this improved/changed somehow? I mean the data we're accessing there.
[10:08:17] <Jaikiran> it's completely changed
[10:08:20] <Jaikiran> no more JBMETA
[10:08:26] <opalka> Jaikiran, Thought so ;)
[10:08:41] <Jaikiran> looking at WebServiceDeclaration, all the info required by that spi, should be available via the AbstractComponentDescription
[10:08:59] <Jaikiran> which can be picked up by an WS DUP (deployment unit processor)
[10:09:15] <Jaikiran> like the LocalEjbViewAnnotationProcessor does
[10:12:12] <opalka> Jaikiran, OK, I think this is all for now. I need to start playing with it first to raise next questions ;)
[10:12:22] <Jaikiran> opalka: sure :)
[10:12:30] <opalka> Jaikiran, thx for short chat!
[10:12:39] <Jaikiran> you're welcome!
[10:26:36] *** bgeorges has quit IRC
[10:48:47] *** kkhan has joined #jboss-as7
[10:48:47] *** ChanServ sets mode: +v kkhan
[10:57:29] *** jcosta has joined #jboss-as7
[10:57:29] *** ChanServ sets mode: +v jcosta
[10:57:39] *** jwulf has quit IRC
[11:04:32] *** jhalliday has joined #jboss-as7
[11:12:38] *** pmuir has joined #jboss-as7
[11:12:38] *** ChanServ sets mode: +v pmuir
[11:13:02] *** torben has joined #jboss-as7
[11:13:02] *** torben has joined #jboss-as7
[11:13:02] *** ChanServ sets mode: +v torben
[11:33:27] *** aslak has quit IRC
[11:33:58] *** aslak has joined #jboss-as7
[11:33:58] *** ChanServ sets mode: +v aslak
[11:38:55] *** maeste has quit IRC
[11:39:45] *** maeste has joined #jboss-as7
[11:39:46] *** ChanServ sets mode: +v maeste
[11:43:24] *** [1]japjap has joined #jboss-as7
[11:44:49] *** maeste has quit IRC
[11:45:40] *** emmanuel has joined #jboss-as7
[11:45:40] *** ChanServ sets mode: +v emmanuel
[11:46:31] *** japjap has quit IRC
[11:46:31] *** [1]japjap is now known as japjap
[11:49:33] *** JimMa has quit IRC
[11:52:16] *** darranl has joined #jboss-as7
[11:52:17] *** darranl has joined #jboss-as7
[11:52:17] *** ChanServ sets mode: +v darranl
[11:58:39] *** maeste has joined #jboss-as7
[11:58:39] *** ChanServ sets mode: +v maeste
[12:05:23] *** rmaucher has joined #jboss-as7
[12:05:36] *** japjap has quit IRC
[12:12:25] *** jwulf has joined #jboss-as7
[12:29:17] *** emmanuel has quit IRC
[12:36:19] <opalka> Jaikiran, what are the plans about EJB21 in AS7? I bet next effort will be on EJB3 DD driven approach, but when can we expected EJB21 to be integrated in AS7? It's our JAX-RPC prerequisity :(
[12:37:27] <Jaikiran> opalka: EJB2 style beans are still valid for EJB3 deployments and dmlloyd had plans for @LocalHome kind of support for Beta1. but i don't think that'll happen for Beta1
[12:37:49] <Jaikiran> looking at the MUST HAVE doc, it isn't listed so i don't think we'll have that support in Beta`
[12:37:51] <opalka> Jaikiran, OK, so DML is the right person to ask ;)
[12:37:52] <Jaikiran> Beta1
[12:38:09] <Jaikiran> yeah he and jgreene, as far as scheduling it goes :)
[13:03:10] *** stalep has quit IRC
[13:11:22] *** epbernard has joined #jboss-as7
[13:11:22] *** epbernard is now known as emmanuel
[13:11:23] *** ChanServ sets mode: +v emmanuel
[13:26:57] *** asoldano is now known as asoldano_lunch
[13:30:48] *** frainone has joined #jboss-as7
[13:30:48] *** ChanServ sets mode: +v frainone
[13:33:51] *** smarlow has joined #jboss-as7
[13:33:52] *** ChanServ sets mode: +v smarlow
[14:02:50] <Nihility> Jaikiran, opalka correct, ejb2 is the least of my worries ;)
[14:03:04] <opalka> Nihility, ;)
[14:06:21] <frainone> opalka: I'm implementing @WebServiceRef... I need to know if I should be using ServiceRefHandler to retrieve the endpoints that should be injected
[14:06:52] <opalka> frainone, Hi Flavia. Yes, I noticed you're working on @WebServiceRef ;)
[14:07:12] <frainone> :)
[14:07:23] <opalka> frainone, You mean the ServiceRefHandler from JBoss MD project, right?
[14:08:04] <frainone> opalka: hm... I thought it belonged to the web services spi, but in fact, it belongs to JBoss MD :(
[14:09:16] <frainone> opalka: but there is a ServiceRefHandler inside of jbossws/spi, I guess I just imported the wrong class
[14:09:19] <opalka> frainone, Yes, this one of our broken abstractions that has ugly dependencies on MD API :(
[14:09:51] <opalka> frainone, The proper way of creating WebServiceRef resources U can find on AS6/webservices submodule
[14:09:58] <frainone> opalka: just checked. Yes, I'm using the one from ws/spi
[14:10:02] <opalka> frainone, org.jboss.webservices.integration.injection.ServiceRefResourceProvider
[14:10:53] <opalka> frainone, Ahh, sorry for confusion.
[14:11:01] <opalka> frainone, Yes, there's one in our SPI.
[14:11:20] <opalka> frainone, The above link to ServiceRefResourceProvider should be all the piece of information needed.
[14:11:51] <opalka> frainone, However AFAIK for some legacy staff EJB's still using JBossMD ServiceRefHandler which is broken by architecture design.
[14:12:11] <frainone> opalka: tx for the info! So I'm on the right track! Now I need to know how to inject the Referenceable
[14:12:34] <Jaikiran> baileyje: wolfc: the @EJB injection processor in AS7 might need some more enhancement
[14:12:53] <Jaikiran> i don't see it handling beanName = jarName.jar#beanName style values
[14:13:34] *** mmoyses has joined #jboss-as7
[14:13:34] *** ChanServ sets mode: +v mmoyses
[14:13:51] <wolfc> known issue
[14:13:52] <frainone> opalka: one last question. Do you know how do I get from the Referenceable to the endpoint interface implementation that needs to be injected?
[14:14:01] <Jaikiran> oh ok
[14:14:42] <opalka> frainone, wait a minute (searching the sources ...)
[14:15:38] *** torben has quit IRC
[14:21:52] <frainone> apparently the docspace number DOC-16608 is wrong. Can somebody point what is the right doc number?
[14:23:34] *** asaldhan has joined #jboss-as7
[14:23:34] *** ChanServ sets mode: +v asaldhan
[14:25:07] *** asoldano_lunch is now known as asoldano
[14:25:32] *** ccrouch has joined #jboss-as7
[14:25:32] *** ChanServ sets mode: +v ccrouch
[14:29:54] <opalka> frainone, JNDI NamingManager should be responsible for doing it
[14:32:59] <frainone> opalka: apparently, that is not how stuff works in AS7. Thanks for your response, I'll check with dmlloyd if I'm missing any pieces on the AS7 side of the story
[14:33:03] <opalka> frainone, CXFServiceReferenceableJAXWS.getReference() method should setup all the necessary info for JNDI NamingManager so he's able to construct WS proxy from it
[14:33:44] <opalka> frainone, UR welcome
[14:33:58] <frainone> :)
[14:34:05] <frainone> dmlloyd: please, ping me once you get online
[14:35:11] <baileyje> Jaikiran: Yeah.  That still isn't handled.
[14:35:32] <Jaikiran> baileyje: ok
[14:35:48] <baileyje> Jaikiran: feel free to work on it if you have time :)
[14:36:10] <wolfc> I've got per instance/method system interceptors here: https://github.com/wolfc/jboss-as/commit/8b846eac136bdb82a4168bbffda7a3956c645891
[14:36:11] <jbossbot> git [jboss-as] 8b846ea.. Carlo de Wolf Added PerViewMethodInterceptorFactory for per method system interceptors
[14:36:17] <Jaikiran> baileyje: i needed something similar for @DependsOn for singleton, so yeah when i get to that part, i'll get to this too
[14:36:31] <baileyje> Jaikiran: Awesome. Sounds good
[14:36:40] <wolfc> and some usage: https://github.com/wolfc/jboss-as/commit/abc7d278fd0fe256806278e7e6078bbf33aaa2a3 (never to be pulled)
[14:36:41] <jbossbot> git [jboss-as] abc7d27.. Carlo de Wolf Dummy instance interceptor
[14:36:53] <baileyje> smarlow: There?
[14:38:44] *** torben has joined #jboss-as7
[14:38:44] *** ChanServ sets mode: +v torben
[14:46:24] <dmlloyd> frainone: ping
[14:46:30] <frainone> dmlloyd: pong
[14:47:01] <frainone> dmlloyd: web services spi gives me a Referenceable, which gives me a Reference. I don't know how can I use that to do the injection
[14:47:23] <frainone> dmlloyd: I think I got all the other parts figured out,this is the only piece I seem to be missing
[14:48:21] <dmlloyd> you mean like a javax.naming.Reference?
[14:48:25] <frainone> exactly
[14:48:58] <dmlloyd> in order to actually bind into JNDI, we use org.jboss.as.naming.ManagedReferenceFactory
[14:49:08] <frainone> yeah, I saw it
[14:49:15] <dmlloyd> which lets us define a cleanup process as well as a lookup
[14:49:22] <frainone> but I don't know how to inject that using the Injector<ManagedReferenceFactory>
[14:49:25] <dmlloyd> so CXF only gives a Reference, hm that's odd
[14:49:35] <frainone> yeah, I need the stub, as far as I can see
[14:49:54] <dmlloyd> well you don't need to worry about the injection
[14:50:02] <baileyje> frainone: What is the class for the Referenceable?
[14:50:23] <dmlloyd> if you just add the binding to the bindings list for the component, that's all we need
[14:50:26] <frainone> baileyje: this is the referenceable I get: CXFServiceReferenceableJAXWS
[14:50:52] <frainone> dmlloyd: but what do I put in the BindingSourceDescription?
[14:51:19] <dmlloyd> well, that's the question isn't it :)
[14:51:23] <frainone> yeah :)
[14:52:25] <dmlloyd> opalka: isn't there any piece which is lower-level than CXFServiceReferenceableJAXWS.getReference()?  As you might have surmised we don't use NamingManager for the "java:" namespace, it's all service-driven
[14:52:26] <frainone> dmlloyd: I implemented BindingSourceDescription and, in the implementation, I'm creating a ValueManagedObject to inject it into the ServiceBuilder
[14:53:07] *** bstans_zzz is now known as bstansberry
[14:53:24] <frainone> dmlloyd: I just need the stub, or I should choose a different path that I don't know
[14:53:32] <baileyje> frainone: Take a look at AbstractServiceObjectFactoryJAXWS
[14:53:56] <baileyje> its getObjectInstance is what they expect to happen every time a jndi lookup id one
[14:54:28] <baileyje> You will need something similar to happen everytime the ManagedReferenceFactory is called.
[14:54:31] <dmlloyd> frainone: I know nothing of CXF.  baileyje's idea sounds good to me
[14:55:07] *** jwulf has quit IRC
[14:55:11] <frainone> baileyje: great! I'll git it a try!
[14:55:53] *** smarlow has quit IRC
[14:56:15] <baileyje> You will likely be able to be much more efficient.  The Reference/ObjectFactory version will require everything to be created new.  With a MRF you could have a lot of it pre done and simply do the "instantiateService" and "configure" portion when a new reference is needed.
[14:56:21] <Nihility> baileyje: hey did you run into stuartdouglas by chance?
[14:56:29] <baileyje> I did not
[14:57:02] <opalka> frainone, dmlloyd, baileyje Yes, AbstractServiceObjectFactoryJAXWS.getObjectInstance() is the info you're looking for Flavia
[14:58:10] <baileyje> Nihility: I got much closer to PU injection last night.
[14:58:37] <baileyje> It is now running into hibernate classloading issues
[14:58:43] <dmlloyd> opalka / Jaikiran I expect we'll want ejb2 by beta2
[14:58:52] <Nihility> baileyje: yeah he was trying to do weld JPA integration, but we couldnt find a branch with even partial PU
[14:58:54] <Jaikiran> dmlloyd: that sounds doable
[14:58:54] <dmlloyd> (not counting CMP)
[14:58:57] <Jaikiran> yeah
[14:59:26] <Nihility> beta2 is next week, assuming we do the weekly build thing thats being asked for us
[14:59:42] <baileyje> Nihility: Yeah.  I haven't pushed my fixes.  I rebased scott's master agains upstream master and then did some fixing.
[14:59:54] *** pmuir has quit IRC
[14:59:58] <Jaikiran> dmlloyd: wolfc: do we have a decision on where testcases should go and how?
[15:00:07] <jhalliday> dmlloyd: congratulations on a logging tools release that did not blow up as soon as I touched it.
[15:00:11] <Nihility> also on the bad news front stuartdouglas thought he might not get weld ejb3 int completed
[15:00:14] <wolfc> I would say not in the demo :-)
[15:00:15] <Jaikiran> i mean i need to add some tests for @Lock and smoke-tests probably aren't the right place for that
[15:00:31] <Jaikiran> yeah, demo isn't the right place for this testing stuff
[15:00:56] <dmlloyd> jhalliday: :)
[15:01:11] *** smcgowan has joined #jboss-as7
[15:01:19] *** ChanServ sets mode: +v smcgowan
[15:01:47] <dmlloyd> Jaikiran: I don't have an answer for that yet.  We have a testsuite module where we'll probably put more comprehensive tests eventually
[15:02:04] <Jaikiran> dmlloyd: talking of schedule, i'm completing this @Lock thing. I have @DependsOn my plate for @Singleton. but if anyone wants to take it before i get there, i don't mind
[15:02:25] <Jaikiran> ack, about the testsuite
[15:03:19] <dmlloyd> baileyje: do you want to take @DependsOn?  It looks rather similar to @EJB in how it looks things up
[15:03:21] <wolfc> Jaikiran, where did you hide LockInterceptor? I need it for SFSB.
[15:03:39] *** smarlow has joined #jboss-as7
[15:03:39] *** ChanServ sets mode: +v smarlow
[15:03:39] <Jaikiran> wolfc: haven't pushed it. it's at the same level as the CMTTxInterceptor in AS7
[15:04:20] <wolfc> Jaikiran, I'm curious where you put the lock field. To maintain the previous model you would need an instance interceptor.
[15:04:47] <Nihility> baileyje is working with smarlow on JPA now
[15:05:04] <smarlow> baileyje:  Hi John, I just got back on and am here now.  :)
[15:05:30] <baileyje> smarlow: Ok.  So I made some progress with the latest upstream master
[15:05:33] <Jaikiran> wolfc: yeah, that part isn't yet tested/working and would actually require your commits
[15:05:43] <baileyje> ran into some hibernate classloading issues.
[15:05:47] <dmlloyd> baileyje: btw, you are my hero for fixing jdbc-*.rar
[15:05:59] *** stansilvert has joined #jboss-as7
[15:06:10] <dmlloyd> wb stansilvert
[15:06:16] <Jaikiran> wolfc: btw, it should be per component interceptor right?
[15:06:17] <stansilvert> thanks
[15:06:27] <baileyje> smarlow: http://pastebin.com/tjAqYTRF
[15:06:32] <Jaikiran> which as far as i see, is currently supported
[15:06:44] <wolfc> Jaikiran, no per ComponentInstance instance.
[15:06:59] <wolfc> For a Singleton it doesn't matter, for SFSB it does.
[15:07:12] <Jaikiran> ah yes, i ignored the bean instances part
[15:07:33] <Jaikiran> wolfc: are you planning that support for @Stateful in Beta1?
[15:07:42] *** jpederse has joined #jboss-as7
[15:07:50] <wolfc> We already have it :-)
[15:07:50] *** jpederse has quit IRC
[15:07:50] *** jpederse has joined #jboss-as7
[15:07:59] <wolfc> It currently doesn't do concurrency
[15:08:02] <Nihility> maeste: btw just so you know we (baileyje actually), have moved the jdbc*.rar code into AS as part of the connector subsystem, so that it no longer requires a deployment. This eliminates all of the annoying issues we have been running into
[15:08:16] <smarlow> baileyje:  give me a minute to look at that...
[15:08:25] <jpederse> Nihility: please, move that code to a datasource/ directory instead
[15:08:40] <Nihility> jpederse: oh there you are
[15:08:45] <Nihility> jpederse: tab complete wasnt showing your name
[15:08:47] <wolfc> Jaikiran, it's just a matter of when Nihility tags to see what's in there :-)
[15:08:55] <Jaikiran> :)
[15:09:01] <jpederse> Nihility: it is a fork - and we have already added a new feature to the JDBC rar implementation
[15:09:04] <dmlloyd> stansilvert: question for you about https://issues.jboss.org/browse/JBCTS-1086
[15:09:18] <dmlloyd> stansilvert: oops, make that https://issues.jboss.org/browse/JBCTS-1088
[15:09:25] <Nihility> jpederse: ok, yeah the rar impl just doesnt work for AS7
[15:09:48] <dmlloyd> stansilvert: I'm wondering if maybe our default filters are hiding the TLD files somehow
[15:09:58] <dmlloyd> stansilvert: where are they normally found?
[15:09:59] <jpederse> Nihility: so you want to go with another approach for Beta1+ ?
[15:10:23] <Nihility> jpederse: i just wanted datasources to work :)
[15:10:41] <Nihility> jpederse: the problem is that all JDBC drivers had to be on the rars classpath
[15:10:43] <maeste> Nihility: so is it working now? Deploying a ds and running correctly the ds demo?
[15:10:47] <Nihility> jpederse: which just cant work
[15:11:07] <stansilvert> dmlloyd: That's coming from this https://issues.jboss.org/browse/JBAS-8916
[15:11:08] <jbossbot> jira [JBAS-8916] Need shared TLD's for JSTL and JSF [Open (Unresolved) Task, Critical, Remy Maucherat] https://issues.jboss.org/browse/JBAS-8916
[15:11:12] <Nihility> maeste: yes you can now run the ds demo
[15:11:23] <maeste> Nihility: I've tested just 5 mins, but I cna't make it works
[15:11:41] <Nihility> you have to deploy the h2 jdbc jar
[15:11:44] <dmlloyd> stansilvert: ah okay
[15:11:50] <Nihility> so its picked up by the jdbc subsystem
[15:11:53] <stansilvert> I'll link it.
[15:11:59] <maeste> Nihility: yup, on deployements...let me retry
[15:12:07] <jpederse> Nihility: no, correct - hence the usage of the classloader must be setup with the JDBC driver - and invocations must happen in that context
[15:12:14] <stansilvert> I guess we're not having a call today?
[15:12:48] <dmlloyd> stansilvert: it's DST for us but not europe, so we call an hour later until they catch up
[15:13:05] <Nihility> jpederse, maeste right yeah so the current jdbc rar code uses the TCCL to do that (why it was breaking)
[15:13:32] <stansilvert> Ah, of course.  I'm all messed up.
[15:13:38] <smarlow> baileyje:  I wonder if its a TCCL issue
[15:13:51] <baileyje> smarlow: it looks like it is.
[15:13:54] <Nihility> jpederse, maeste the other thing is that the jdbc service has the Driver instance ready to go in a service, so all the CF has to do is just have dep on that service
[15:14:12] <Nihility> it doesnt even need to do CL unless XA is being used and a DS has to be loaded
[15:14:41] <maeste> Nihility: just cp ../modules/com/h2database/h2/main/h2-1.2.144.jar ../standalone/deployments/ is not triggering the driver deployment. What am I missing?
[15:15:31] <baileyje> you also need to touch the "deployments/h2-1.2.144.jar.dodeploy"
[15:15:35] <baileyje> to trigger the deployment
[15:15:45] <jpederse> Nihility: classes internal to a .rar uses the TCCL to do classloading
[15:16:00] <maeste> baileyje: yup I've read the ML..totally forgotten
[15:16:16] <Nihility> yeah we need to add a log message
[15:16:22] <Nihility> to tell you to do that
[15:16:32] <baileyje> maeste: I originally enabled that feature and still forgot the other day
[15:16:49] <maeste> lol
[15:17:06] <Nihility> jpederse: right yeah there is the conundrum, the jdbc rar, which is reused for all jdbc drivers uses TCCL, so thats why it needs to see all possible jdbc drivers
[15:17:07] *** JimMa has joined #jboss-as7
[15:17:30] <dmlloyd> stansilvert: what are your thoughts on using jboss-jsf-api_2.0_spec for JSF API?
[15:18:04] <Nihility> jpederse: this doesnt have to be a fork btw, we could move it into some kind of shared ironjacamar module, as like a jar used by both the rar and the as7 integration
[15:18:14] <jpederse> Nihility: that is for all .rar deployments - the JDBC rar just happens to implement the JBoss requirements
[15:19:02] <baileyje> Nihility, jpederse:  That would be my suggestion.  A shared module for theJDB bits.
[15:20:23] <Nihility> jpederse: right, but it falls short of the requirements, thats my point. you could potentially make the rar approach work, but it would have to have a separate code path to talk to the AS7 services, and then there really isnt much benefit to it being a rar
[15:20:36] <bstansberry> kkhan, emuckenhuber: ping
[15:20:44] <kkhan> Hi
[15:20:45] *** JimMa has quit IRC
[15:20:46] <emuckenhuber> hi
[15:20:50] <bstansberry> hello
[15:20:55] <bstansberry> what's up?
[15:21:04] <emuckenhuber> bstansberry: i just replied to your email
[15:21:25] <kkhan> I'm trying to track down the problem for host=blah,server=s2
[15:21:47] <kkhan> There is some problem propagating the result back from the server to the slave DC
[15:21:53] <kkhan> or rather the result gets set
[15:22:03] <Nihility> jpederse maeste if you guys rather we could make it an entirely separate project or subsystem too, im really open to any approach
[15:22:14] <kkhan> but handleResultComplete is not getting set on the slave DC, although it is happening on the server
[15:22:22] <kkhan> So I'm trying to figure out that
[15:22:28] <bstansberry> cool
[15:22:55] <bstansberry> emuckenhuber: a guess at your problem is the management socket is bound to 0.0.0.0
[15:22:59] <Nihility> stansilvert: how do you think we look for JSF when it comes to tagging this evening
[15:23:13] <Nihility> stansilvert: any objections/blockers you have
[15:23:14] <jpederse> Nihility: if it doesn't pass through the JCA deployer chain and doesn't use JCA infrastructure it should be in a datasource/ top level project
[15:23:18] <smarlow> baileyje:  I don't know how the Javassistet ProxyFactory is working internally but looking at ProxyFactory code, it seems to have some getClassLoader() code that could do a "loader = Thread.currentThread().getContextClassLoader()"
[15:23:40] <bstansberry> RemoteDomainConnectionService has some emabarrassing 2 AM logic to try and figure out a valid address to send to the master
[15:23:58] <Nihility> jpederse: it uses the JCA infrastructure, its a CF impl still. It's just been modified to pull Driver instances from MSC instead of using TCCL to load them
[15:24:13] <bstansberry> maybe that's the problem? it's telling it to use your VPN interface or something
[15:24:24] *** pmuir has joined #jboss-as7
[15:24:24] *** ChanServ sets mode: +v pmuir
[15:24:54] <baileyje> jpederse, maeste:  The key requirements are... 1.  Not have a RAR that needs to be deployed separate. 2.  No TCCL usage to load,  3. No reloading the jdbc driver, 4.  All binding should be using a BinderService and a ManagedReferenceFactory
[15:25:05] <stansilvert> Nihility: status is here: http://community.jboss.org/wiki/JSFonAS7
[15:25:09] <baileyje> I don't really care where the code is located.
[15:25:20] <emuckenhuber> bstansberry: hmm, let me check
[15:25:30] <jpederse> baileyje: TCCL is how .rar's load classes
[15:25:36] <jpederse> Nihility: ok, lets do
[15:25:36] <stansilvert> I don't like this one: https://issues.jboss.org/browse/JBAS-8908
[15:25:38] <jbossbot> jira [JBAS-8908] AS6 ZipException now seen in AS7 [Open (Unresolved) Bug, Blocker, John Bailey] https://issues.jboss.org/browse/JBAS-8908
[15:25:48] <jpederse> Nihility: #1 move impl to datasource/
[15:25:56] <jpederse> Nihility: #2 create a JDBC jar artifact
[15:26:05] <jpederse> Nihility: #3 create a classloading spi
[15:26:26] <jpederse> Nihility: #4 use the jar artifact + JBoss Modules SPI impl in AS 7
[15:26:44] <stansilvert> Nihility: I have it marked as a blocker for now.
[15:27:20] <smarlow> baileyje:  should we sync up somewhere so I can get far enough to also hit this?
[15:27:31] <baileyje> smarlow: Sure..
[15:27:38] <stansilvert> Nihility: It's just hard to tell what % of apps would be affected by this.
[15:27:53] <baileyje> smarlow: Why don't you rebase against upstream.
[15:28:05] <baileyje> Then I will get in sync with you, and push my change for you to intergrate.
[15:28:05] <dmlloyd> stansilvert: JBAS-8024 is marked as fixed but I don't see what the resolution was?
[15:28:06] <jbossbot> jira [JBAS-8024] Weld deployments fail with "Error in zip file" message [Resolved (Done) Bug, Critical, John Bailey] https://issues.jboss.org/browse/JBAS-8024
[15:28:15] <smarlow> baileyje: I did about an hour ago but can again
[15:28:20] <baileyje> smarlow:  that should keep us from having a lot of conflict.
[15:28:30] <smarlow> I'll sync again
[15:28:50] <baileyje> smarlow: That should be fine.  I just need to make sure I am not ahead of you
[15:29:26] *** aloubyansky has joined #jboss-as7
[15:29:26] *** ChanServ sets mode: +v aloubyansky
[15:29:52] <smarlow> baileyje:  cool, I'm still up to date :)
[15:30:21] <Nihility> baileyje does JBAS-8204 ring any bells, the comments appear like you were the one that fixed it
[15:30:22] <emuckenhuber> bstansberry: ok, that did the trick, thanks
[15:30:23] <jbossbot> jira [JBAS-8204] Deployment via a deployment plan [Open (Unresolved) Task, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-8204
[15:30:45] <Nihility> jpederse: agreed
[15:30:48] <stansilvert> dmlloyd: Perhaps baileyje remembers how to fix it.  I believe he took care of it in AS6, which is why I assigned to him.
[15:31:10] <jpederse> Nihility: k, I'll put it as a TODO for our Beta5 release
[15:32:57] *** jfd has joined #jboss-as7
[15:32:57] *** ChanServ sets mode: +v jfd
[15:34:36] <baileyje> Nihility, stansilvert : Yeah.  I think that was just a hack to translate the URL into a non-file URL
[15:34:52] <baileyje> VFS doesn't use file URLs, but there may be a related issue
[15:37:45] <smarlow> baileyje:  I might have to hack around javassists expectaction for TCCL
[15:38:11] <smarlow> baileyje: although, I thought I got further than this before.
[15:38:19] *** hbraun has joined #jboss-as7
[15:38:37] <hbraun> Nihility: ping
[15:38:41] <baileyje> smarlow: You man need a way to discover the need for the required modules and add them to the deployment
[15:41:43] <smarlow> baileyje:  hmm, so PersistenceUnitDeploymentProcessor would do the adding, I assume?
[15:42:16] <baileyje> smarlow: Yeah.  If you discovered they were using the hibernate impl
[15:42:26] <baileyje> you could add the needed modules to the deployment
[15:43:58] <smarlow> baileyje:  makes sense.
[15:44:05] <Nihility> hbraun: halo
[15:44:13] <hbraun> Nihility: ;9
[15:44:15] <hbraun> hi
[15:44:18] <hbraun> how are you?
[15:44:21] <Nihility> good!
[15:44:35] <jbossbot> git [jboss-as] push master aeab5fc.. Alexey Loubyansky JBAS-8949
[15:44:36] <jbossbot> jira [JBAS-8949] when tab-completing the only possible node type return its children as candidates [Open (Unresolved) Feature Request, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-8949
[15:44:36] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/d3fd279...aeab5fc
[15:44:40] <hbraun> i am looking into integrating M1 into the AS codebase
[15:44:50] <hbraun> wondering how to deploy the console
[15:44:59] <hbraun> is the httpd integrated already?
[15:45:06] <hbraun> for both standalone and domain usage?
[15:46:22] <smarlow> baileyje:  although, adding the required modules to the deployment might not help the TCCL to see them
[15:46:54] <baileyje> it would in this case.  THe key is to look at the exception stack
[15:47:00] <Nihility> hbraun: we need to add come up with some kind of javascript resource bundle, and then add a resource serving ability into the http-api using a different context /console maybe?
[15:47:13] <hbraun> Nihility: plus, I would need a JIRA component for the console
[15:47:27] <hbraun> Nihility: right
[15:47:33] <hbraun> Nihility: that#s was what I was thinking
[15:47:41] <hbraun> Nihility: I can look into it
[15:47:48] *** slaboure has quit IRC
[15:47:52] <hbraun> Nihility: but is it already part of the dist?
[15:47:59] <Nihility> hbraun: not sure if its included in the domain mode yet, at the time i implemented it domain was not yet running on the detyped api, lets ask bstansberry
[15:48:12] <Nihility> bstansberry: hey has anything happened to launch the domain-http-api stuff from the DC
[15:48:33] <hbraun> bstansberry, Nihility: and standalone as well, right?
[15:48:37] <bstansberry> hbraun, Nihility: I just started the domain and see errors related to http that i didn't see yesterday
[15:48:57] <emuckenhuber> bstansberry: i fixed that in my domain-op branch
[15:49:07] <Nihility> bstansberry: i merged a contributor patch yesterday, perhaps something broke
[15:49:23] <Nihility> hbraun: standalone is definitely working
[15:49:31] <emuckenhuber> bstansberry: https://github.com/emuckenhuber/jboss-as/commit/0b9589a75ba31ad2ec35d13f92d065a78cc4dc69
[15:49:31] <jbossbot> git [jboss-as] 0b9589a.. Emanuel Muckenhuber don't depend on the server-env, since it's not available on the HC
[15:49:32] <bstansberry> exactly. see http://pastebin.com/W5AL4zg5
[15:49:46] <bstansberry> ah, cool
[15:49:58] <smarlow> baileyje:  from the exceptoin stack, I don't see that.  We are going through some code that sets the TCCL to contain the transaction manager but that is it.
[15:50:00] <Nihility> hbraun: the resource service stuff i hadnt added, its about an hour of work maybe so I can do that ASAP if you need soon, alhtough are you wanting this in beta1?
[15:50:19] <hbraun> Nihility: I might do it myself
[15:50:42] <hbraun> Nihility: you are probably busy with other items, right?
[15:50:44] <smarlow> baileyje:  actually, it should be JTA + whatever else is in the com.arjuna.ats.jbossatx.jta.TransactionManagerService.class.getClassLoader()
[15:51:01] <hbraun> Nihility: we just need to agree on a resource directory that's as the web root
[15:51:08] *** jfd has quit IRC
[15:51:16] <Nihility> emuckenhuber: duh, you know i looked over that last night, and didnt even think to check that it would be injecting the wrong env
[15:51:46] <hbraun> Nihility: which maven module contains the httpd again?
[15:51:50] <hbraun> Nihility: controller?
[15:51:56] <Nihility> hbraun: domain-http-api
[15:51:59] <emuckenhuber> Nihility: hehe - no problem, it was easy to fix :)
[15:52:34] <bstansberry> I cherry-picked it onto master; seeing if there are any issues
[15:52:40] <smarlow> baileyje:  but I don't see anything telling otherwise in the exception stack.  What am I missing?
[15:52:41] <hbraun> Nihility: ok, my IDE was out of sync
[15:52:42] *** tdiesler has joined #jboss-as7
[15:52:43] *** ChanServ sets mode: +v tdiesler
[15:52:49] <hbraun> Nihility: got it
[15:52:56] <baileyje> smarlow: One second.  Just getting my fix pushed for you..
[15:53:17] <Nihility> hbraun: so i was thinking of just serving the stuff straight from a jar via the classloader, basically we would put that console jar as a dep on domain-http-api and just map /console/* to getResource()
[15:53:37] <smarlow> baileyje:  cool, thanks!
[15:53:47] <hbraun> Nihility: ok
[15:53:56] <hbraun> Nihility: we worry about auth some other time
[15:54:11] <hbraun> Nihility: but what you suggets sounds fine to me
[15:54:36] <hbraun> Nihility: I'll give it a shot and keep you posted
[15:54:36] <Nihility> hbraun: right yeah we need a real solution to auth at some point
[15:54:40] <Nihility> ok great
[15:55:48] <baileyje> smarlow: The key is ... "Caused by: java.lang.ClassNotFoundException: org.hibernate.proxy.HibernateProxy from [Module "deployment.jpa-example.jar:main" from Service Module Loader]"
[15:55:56] <Nihility> hbraun: so the embedded server has a way to register HttpHandler objects per context, so we probably just need a ConsoleHandler, or ResourceHandler something like that registered at /context
[15:56:22] <hbraun> Nihility: thats' something you build?
[15:56:36] <baileyje> smarlow: The CL exception include the module CL that was in use when the CL happened.  So it is trying the deployment CL.  So if the deployment CL has the correct deps, it should work
[15:56:54] <frainone> dmlloyd, baileyje: I'm getting a NPE at this line of AbstractServiceObjectFactoryJAXWS: return Thread.currentThread().getContextClassLoader().loadClass(className)
[15:57:00] <frainone> here is the full stack trace: http://www.fpaste.org/nrcn/
[15:57:05] <frainone> is there a workaround for this?
[15:57:21] <Nihility> hbraun: yeah if you look at the domain-http-api, you will see that it is currently acting as the server impl as well as a handler for domain-api
[15:57:38] <hbraun> Nihility:  ok great
[15:57:41] <smarlow> baileyje:  ah cool, I'll make a mental note to look for that key detail next time.  :)
[15:58:38] <baileyje> smarlow: https://github.com/baileyje/jboss-as/commit/098fa60f407491214d7398068a654cb953055e7c
[15:58:38] <jbossbot> git [jboss-as] 098fa60.. John E. Bailey Make sure the PU/PC injeciton services have the correct deps
[15:58:46] <Nihility> hbraun: if you look at the create method: server.createContext(DOMAIN_API_CONTEXT, me);, is where the handler gets registered
[15:58:54] <jbossbot> git [jboss-as] push master 132aaaa.. Emanuel Muckenhuber don't depend on the server-env, since it's not available on the HC
[15:58:54] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/aeab5fc...132aaaa
[15:58:59] <hbraun> Nihility: still, I need a JIRA component for the console
[15:59:04] <hbraun> Nihility: can you do that?
[15:59:07] <Nihility> yes
[15:59:18] <hbraun> Nihility: tnx
[15:59:26] <hbraun> Nihility: just chose a name
[15:59:39] *** balunasj has joined #jboss-as7
[15:59:39] *** balunasj has joined #jboss-as7
[15:59:39] *** ChanServ sets mode: +v balunasj
[16:00:02] <hbraun> Nihility: i refer to it as "Management Web Interface" most of the time
[16:01:12] <asaldhan> dmlloyd: AS7 jars are sealed. right?
[16:02:45] <bstansberry> hbraun, Nihility:  on master the httpd api works on the DC
[16:03:38] <Nihility> sweet
[16:03:52] <Nihility> bstansberry: emuckenhuber thanks for adding that guys
[16:04:14] <smarlow> baileyje:  nice patch/fix!  :)  I can easily apply the patch but what is the git way to apply it?
[16:04:35] <baileyje> smarlow: You can do a fetch from my repo
[16:04:45] <baileyje> then you can cherry-pick the change
[16:05:18] <baileyje> so.  "git fetch baileyje"
[16:05:26] <Nihility> dmlloyd: hey did you merge that security patch last week
[16:05:29] <baileyje> then "git cherry-pick 098fa60f407491214d73"
[16:06:03] *** ALR has joined #jboss-as7
[16:06:03] *** ChanServ sets mode: +v ALR
[16:06:30] <bstansberry> aloubyansky: your last JBAS-8949 patch is pushed -- are there any other critical CLI things you need for the beta?
[16:06:32] <jbossbot> jira [JBAS-8949] when tab-completing the only possible node type return its children as candidates [Resolved (Done) Feature Request, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-8949
[16:08:01] <aloubyansky> bstansberry: i'll see if I can hack tab-completion for 'cd'
[16:08:31] <Nihility> stansilvert: did the stack trace on 7 look like the one on 6
[16:08:32] <bstansberry> ok
[16:10:03] <stansilvert> Nihility: as I remember, it was almost exactly the same.  I should have included it in the new jira though.  I'll run it again and post it.
[16:10:18] <Nihility> stansilvert: thanks
[16:14:00] *** opalka has quit IRC
[16:15:21] <dmlloyd> Nihility: yeah I think I did merge that
[16:15:23] <smarlow> baileyje:  I tried "git pull  https://github.com/baileyje/jboss-as "  for the fetch but I'm not sure about the cherrypick?
[16:15:47] <kkhan> bstansberry: Fixed
[16:15:56] <smarlow>  baileyje git cherry-pick 098fa60f407491214d73 doesn't seem to be enough
[16:16:06] <bstansberry> kkhan: :-)
[16:16:16] <kkhan> After many hours it turned out to be one line of code in the wrong place
[16:16:41] <kkhan> Basically the problem was in ModelControllerOperationHandler
[16:16:45] <bstansberry> lack of debuggability on this is a killer
[16:16:53] <kkhan> Yes
[16:17:07] <kkhan> The problem was the asynch operation on the slave controller
[16:17:13] <kkhan> asynch op handler
[16:18:01] <kkhan> It has a synch block on the outputstream where it also waits for the compensating operation from the result
[16:18:28] <kkhan> So when sending its result handler on to use for calling into the servers
[16:18:33] <kkhan> the results come back
[16:18:49] <kkhan> but the result handler also synchs on the output stream
[16:19:00] <kkhan> I'll clean up and commit
[16:19:17] <bstansberry> cool
[16:19:48] <bstansberry> kkhan, emuckenhuber: once I pull in ^^^ I'd like to merge in domain-op again. any objections?
[16:20:37] <emuckenhuber> sounds good to me
[16:20:44] <kkhan> Fine by me too
[16:21:25] <bstansberry> emuckenhuber: what's up with demos?
[16:21:53] <kkhan> Once this release is out of the way I'd like to ping Andrew Haley to see if he has any idea about the invalid memory access errors we see when trying to debug
[16:22:05] <bstansberry> +1000
[16:23:07] <frainone> dmlloyd: do you have any idea of how could I fix this? http://www.fpaste.org/nrcn/
[16:23:23] <frainone> this is the line that is throwing the NPE: return Thread.currentThread().getContextClassLoader().loadClass(className);
[16:23:45] <baileyje> smarlow: You need to add my repo as a remote.   Avoid using pull.
[16:24:27] <dmlloyd> frainone: ah.  we've run into this kind of thing frequently where frameworks use TCCL to find their own stuff
[16:24:30] <baileyje> smarlow: "git remote add baileyje https://baileyje at github dot com/baileyje/jboss-as.git"
[16:24:35] <dmlloyd> asoldano: any idea about ^^^^?
[16:25:08] * dmlloyd looks at the source to that method
[16:25:22] <dmlloyd> oh, opalka wrote that
[16:25:26] <kkhan> bstansberry: Here's the needle in the haystack https://github.com/kabir/jboss-as/commit/04a8f6124ba295cec137aa4aed0638db8cada1d1
[16:25:27] <jbossbot> git [jboss-as] 04a8f61.. kabir Avoid deadlock when the result handler in the asynch ModelControllerOperationHandler is forwarded on to another controller asynchronously
[16:25:57] <alesj> dmlloyd: is there a way to get all Modules?
[16:26:13] <dmlloyd> frainone: what about setting TCCL to the deployment CL for the duration of the call to getResourceValue?
[16:26:20] <dmlloyd> alesj: all loaded modules you mean?
[16:26:28] <alesj> yes
[16:26:50] <smarlow> baileyje:  If you don't object, I'll just apply your patch by hand and commit it.
[16:26:55] <dmlloyd> alesj: just through the MBean
[16:26:55] <asoldano> dmlloyd, don't know, need to ask Richard
[16:27:09] <baileyje> smarlow: Fine by me.  Small anyway
[16:27:25] <frainone> dmlloyd: I'll give it a try
[16:27:40] <alesj> dmlloyd: which MBean is that?
[16:27:53] <alesj> dmlloyd: and afaik, one cannot get Module's dependencies?
[16:28:39] <dmlloyd> alesj: that is correct
[16:29:13] <dmlloyd> alesj: jboss.modules:type=ModuleLoader,name=*
[16:29:48] <alesj> and I get back what?
[16:30:03] <dmlloyd> there's tons of operations and attributes for looking at module information
[16:30:07] <dmlloyd> try it out with jconsole
[16:30:14] <alesj> ok
[16:30:21] <dmlloyd> well mostly operations really
[16:31:21] <asoldano> frainone: when going throught the DUP you most probably don't have a TCCL set. That class in jboss-common should most likely be changed to accept a classloader to be used for loading service impl classes
[16:31:46] <dmlloyd> jbossws-common you mean
[16:31:48] <stansilvert> Nihility: posted AS7 stack trace.  It is indeed the same as in AS6.
[16:31:51] <dmlloyd> yeah I agree it should be changed
[16:31:54] <dmlloyd> but setting TCCL for now is fine
[16:31:58] <dmlloyd> (in this case)
[16:32:55] *** aslak has quit IRC
[16:33:12] <asoldano> dmlloyd, yep, right jbossws-common ;-)
[16:33:22] <frainone> dmlloyd, asoldano: ok, tx!
[16:38:02] *** aslak has joined #jboss-as7
[16:38:02] *** ChanServ sets mode: +v aslak
[16:45:34] *** tdiesler has quit IRC
[16:46:07] <smarlow> baileyje:  were you running the "mvn package -Dexample=jpa" to get that exception?
[16:46:41] <emuckenhuber> bstansberry: hmm, a lot of the demos seem to be working anyway - i was looking into the domain.servers one, but i guess we don't have restart operations yet?
[16:47:07] *** jamezp has joined #jboss-as7
[16:47:20] <bstansberry> there are restart op, at the root of the host resource
[16:47:28] <bstansberry> start-server(name=serverx)
[16:47:31] <bstansberry> stop-server
[16:47:34] <bstansberry> restart-server
[16:49:27] <smarlow> baileyje:  I get the same problem as I got previously when running the demo (IllegalStateException is thrown from InjectedValue.getValue))
[16:49:37] <emuckenhuber> bstansberry: ah, ok that's why i did not see them - thanks
[16:51:11] <baileyje> smarlow: You need to do a couple things.  One edit the standalone.xml file and enable the datasource
[16:51:24] <smarlow> k
[16:51:25] <baileyje> smarlow: Then you need to cp the h2...jar into the deployment directory
[16:52:20] *** jfd has joined #jboss-as7
[16:52:20] *** ChanServ sets mode: +v jfd
[16:54:15] <dmlloyd> if anyone needs a task, ping me
[16:54:35] *** pilhuhn is now known as pil-afk
[16:54:40] <jamezp> dmlloyd: I've got time if you need anything.
[16:55:18] <dmlloyd> jamezp: can I PM you?
[16:55:26] <jamezp> Sure thing.
[16:57:17] <baileyje> dmlloyd: I can grab something from ya
[16:58:54] *** mmoyses is now known as mmoyses_
[16:59:01] <dmlloyd> baileyje: I'm going to assign @DependsOn to jamezp.  Just in case I'm away or something and he has a question :)
[16:59:13] <baileyje> dmlloyd: Sounds good,
[16:59:57] *** balunasj has quit IRC
[17:03:41] <wolfc> Is somebody working on EJBContext binder?
[17:03:55] <alesj> dmlloyd: a ejb interceptors q 4 u … or for wolfc
[17:04:15] <wolfc> We need something similar to TransactionJndiBindingProcessor for EJBContext
[17:04:27] <alesj> dmlloyd, wolfc: I need to add Weld interceptors to EJBs at runtime
[17:04:30] <baileyje> wolfc: I can work on it..
[17:04:33] *** tdiesler has joined #jboss-as7
[17:04:34] *** ChanServ sets mode: +v tdiesler
[17:04:36] <wolfc> baileyje, cool thx
[17:04:51] <alesj> e.g. after the DUPs have already done its work
[17:04:54] <wolfc> alesj, the weld interceptor is a spec one, or a jboss-invocation one?
[17:05:08] <alesj> i think it's spec
[17:05:12] <alesj> wolfc: ^
[17:05:16] <wolfc> does it have lifecycle callbacks?
[17:05:29] <alesj> hmmm, dunno
[17:05:31] <dmlloyd> baileyje: yeah if you can help wolfc with whatever he needs that'd be good
[17:06:28] *** smarlow has quit IRC
[17:07:19] <Jaikiran> dmlloyd: Nihility: baileyje: just a FYI, i just ran into a server hang
[17:07:28] <Nihility> doh
[17:07:30] <Nihility> whats the hang
[17:07:32] <Jaikiran> which was a result of @EJB (lookup="non-existent-jndi-name)
[17:07:32] *** smarlow has joined #jboss-as7
[17:07:33] *** ChanServ sets mode: +v smarlow
[17:07:44] <Jaikiran> it "waits" in the AbstractComponent
[17:07:47] <smarlow> baileyje:  I copied the h2 drive in the deployment folder and changed the H2DS datasource to be enabled.  However, I'm missing a dependency.  According to the msc mbean:  Service "jboss.data-source.java:/H2DS" (class org.jboss.as.connector.subsystems.datasources.LocalDataSourceService) mode ACTIVE state DOWN (parent: jboss.as.server-controller) (dependencies: jboss.naming, jboss.jdbc-driver."org.h2.Dr
[17:07:52] <smarlow> iver".1.2, jboss.txn.ArjunaTransactionManager) (has missing dependency)
[17:07:56] <smarlow> baileyje:  it looks like its jboss.jdbc-driver."org.h2.Driver".1.2
[17:07:56] <wolfc> that is by design
[17:08:01] <Nihility> Jaikiran: sounds like https://issues.jboss.org/browse/JBAS-8947
[17:08:03] <jbossbot> jira [JBAS-8947] Missing service dependencies doesn't result in deployment failure [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8947
[17:08:09] <dmlloyd> Jaikiran: is it really blocking in the component? it should have a dependency
[17:08:09] <alesj> wolfc: where is the code that knows what to inject for @EJB?
[17:08:14] <baileyje> smarlow: Did you create the deployment marker file?
[17:08:22] <Jaikiran> let me get that thread dump
[17:08:24] <dmlloyd> Jaikiran: as in, it should never even try to start the component without the dependency
[17:08:43] <smarlow> no, I didn't.  I'll try that
[17:08:47] <Nihility> i think we need that log message for FS deployment
[17:08:50] <Nihility> im going to do that
[17:08:52] <baileyje> you have to touch a file called  "h2-1.2.144.jar.dodeploy" in the deployment dir
[17:08:53] <Nihility> bstansberry: any objects?
[17:08:57] <wolfc> alesj, EjbAnnotationProcessor
[17:08:57] <Nihility> objections?
[17:09:11] <bstansberry> Nihility: no objections
[17:09:18] <wolfc> alesj, ah no, silly me, hold on
[17:09:24] <Nihility> its confusing way to many people
[17:09:56] <wolfc> alesj, EjbResourceInjectionAnnotationProcessor
[17:10:43] <Jaikiran> dmlloyd: baileyje: Nihility: http://pastebin.com/6Dh9Kpqv
[17:10:55] <baileyje> Nihility: The alternative is to punt and just assume a deployable archive in the directory that does not have a ".dodeploy", ".deployed", ".faileddeploy", or a ".donotdeploy" should be deployed
[17:10:55] <kkhan> bstansberry: New issue, running a :read-resource(recursive=1) with no address does not return slave hosts just the master domain + host
[17:11:22] <bstansberry> ah, yeah :(
[17:11:29] <wolfc> Jaikiran, it's by design. It is waiting for dependencies to be satisfied
[17:11:32] <bstansberry> that's going to require custom logic in the handler
[17:11:46] <Jaikiran> wolfc: hmm, i thought it should fail at some point?
[17:11:59] <bstansberry> because the local "host" part of the model is no longer proxied
[17:12:07] <Jaikiran> like it does eventually in JBAS-8947
[17:12:09] <jbossbot> jira [JBAS-8947] Missing service dependencies doesn't result in deployment failure [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-8947
[17:12:16] <alesj> wolfc: ok, this is for config processing
[17:12:26] <bstansberry> the handler needs to pretend it is proxied
[17:12:28] <alesj> wolfc: I have @EJB and I wanna get the right bean
[17:12:33] <alesj> what do I do? :-)
[17:13:24] <alesj> wolfc: that's the code I'm looking for
[17:13:30] <frainone> dmlloyd: I need some help here. Look at what I'm getting when the code attempts to retrieve the Endpoint proxy: Caused by: java.lang.ClassNotFoundException: org.jboss.as.demos.ws.archive.Endpoint from [Module "org.jboss.as.webservices:main" from local module loader @95c083 (roots: /home/fla/Development/projects/jboss-as/build/target/jboss-7.0.0.Alpha2/modules)]
[17:13:50] <dmlloyd> Jaikiran: I think there must be a missing dep - it shouldn't have to wait if all of its deps are satisfied
[17:14:21] <smarlow> baileyje:  same error as before, I'll look for more missing dependencies in jconsole
[17:14:44] <dmlloyd> frainone: okay so it must expect both the deployment *and* CXF to be on the TCCL.... sound familiar asoldano? :)
[17:15:13] <Jaikiran> dmlloyd: it does setup the dep via the LookupBindingSourceDescription in the bindingdescription
[17:15:19] <Jaikiran> let me see what might be wrong then
[17:15:37] <dmlloyd> Jaikiran: the lookups should all not happen until the component is instantiated which should not happen until START
[17:15:38] <Jaikiran> dmlloyd: oh wait, i read your message wrong
[17:15:43] <wolfc> alesj, after that it goes out of scope for me. :-) Somewhere through LazyBindingSourceDescription, baileyje probably knows the details.
[17:15:55] <Jaikiran> ofcourse it's a missing dep because of incorrect lookup jndi value by the bean developer
[17:16:27] <dmlloyd> Jaikiran: yeah, so in that case the component should never go to START so there should be no waiting threads - just services missing dependencies (which is what we want - we will add an error message for that later)
[17:16:36] <smarlow> baileyje:  still have "Service "jboss.data-source.java:/H2DS" (class org.jboss.as.connector.subsystems.datasources.LocalDataSourceService) mode ACTIVE state DOWN (parent: jboss.as.server-controller) (dependencies: jboss.naming, jboss.jdbc-driver."org.h2.Driver".1.2, jboss.txn.ArjunaTransactionManager) (has missing dependency)"
[17:16:38] <asoldano> dmlloyd, frainone I might need to look better at this, but on server side there you should make use of the classloader from the org.jboss.as.webservices.server.integration:main module
[17:16:44] <dmlloyd> Jaikiran: it's on my Beta2 list
[17:16:57] <asoldano> dmlloyd, plus the deployment, yes
[17:17:05] <asoldano> frainone, ^
[17:17:19] <Jaikiran> dmlloyd: ok, so i'll keep that aside for later then
[17:17:57] <alesj> baileyje: so, wolfc says you know how to get the right EJB bean fwith just @EJB instance
[17:18:31] <dmlloyd> Jaikiran: unfortunately it doesn't answer the question of why the thread gets to a waiting state in the first place
[17:18:42] <dmlloyd> Jaikiran: might be a problem in the test though
[17:18:57] <Jaikiran> i'll take a look and see if i can figure it out soon
[17:19:19] <alesj> wolfc: back to you for that interceptor binding at runtime
[17:19:56] <alesj> wolfc, dmlloyd: I see ComponentInstallProcessor adding the descriptors
[17:20:23] <alesj> in my case it looks like I would need to push my stuff in before that gets started
[17:20:28] <smarlow> baileyje:  the deployments folder contains:  h2-1.2.144.jar  h2-1.2.144.jar.isdeployed  README.txt
[17:20:57] <smarlow> I'll try to stop and start again
[17:21:28] <alesj> meaning i need to somehow create EE_component descriptors depend on Weld service
[17:21:40] <wolfc> alesj, if you put your processor in the right phase
[17:22:08] <alesj> wolfc: my interceptors only get read when Weld scans the beans
[17:22:14] <frainone> asoldano: would that module CL be able to retrieve the application's end point interface?
[17:22:18] <alesj> which is done in WeldService
[17:22:21] <smarlow> baileyje:  on the AS console, I see:  Services missing dependencies:
[17:22:27] <alesj> out side dup
[17:22:28] <smarlow> baileyje:  service jboss.data-source.java:/H2DS
[17:22:39] <smarlow> baileyje: service jboss.naming.context.java.java:/H2DS
[17:22:41] <asoldano> frainone, no, that's just in the deployment
[17:23:12] <asoldano> frainone, on the jbossws side for similar problem we create a new delegate classloader having the deployment one as a parent and the one we need as a delegate
[17:23:17] <wolfc> alesj, you're not making much sense :-)
[17:24:07] <alesj> wolfc: or you don't know enough about how your EJBs work now :-)
[17:24:43] <alesj> wolfc: I have a WeldService, which is started when all deps are in place
[17:24:47] <baileyje> smarlow: have you confirmed the DS is getting installed?
[17:24:56] <frainone> asoldano: ok, I'll try it
[17:24:59] <alesj> this then scans the beans, only to find out this is an interceptor bean
[17:25:03] <baileyje> smarlow: Make sure it is enabled and the driver is installed.  It should clean boot if so
[17:25:08] <alesj> on a EJB
[17:25:29] <alesj> which means it needs to get added to EJB interceptor chain
[17:25:49] <wolfc> alesj, you are in swimlane #2 and you want to modify swimlane #1. AS 6 has already told us this is impossible. :-)
[17:26:12] <alesj> wolfc: how come we have thins working then in AS6 :-)
[17:26:26] <wolfc> shear luck :-)
[17:26:30] <alesj> hehe
[17:26:37] <smarlow> baileyje:  I didn't copy in a jdbc-local.rar as I was doing previously.  Do I need to?
[17:26:46] <baileyje>  You don't need to
[17:26:54] *** frainone is now known as frainone_lunch
[17:26:56] <baileyje> the h2 jar
[17:27:07] <baileyje> a ".dodeploy" file
[17:27:18] <baileyje> and the standalone.xml update to enable the DS
[17:27:50] <wolfc> alesj, you need to ask dmlloyd if you can modify a DU from a Service
[17:28:44] <dmlloyd> if you want to modify a deployment or an EE component, alesj, you have to use a deployment processor
[17:29:19] <baileyje> wolfc: Where does the EJB context come from?
[17:29:41] <baileyje> in other words is it available already, just not bound, or is a new one created?
[17:29:55] <alesj> dmlloyd: can I modify interceptor chain from a service?
[17:30:01] <baileyje> I would assume a new one is create per instance
[17:30:41] <alesj> dmlloyd: as i'm past DUP stage, I only know I need to add a new interceptor at service time
[17:31:05] <dmlloyd> you can't
[17:31:41] <alesj> dmlloyd: e.g. my WeldService know it needs to add interceptor for its EJB bean only after it scanned the beans
[17:31:42] *** dimitris_ has quit IRC
[17:32:08] <dmlloyd> then it needs to be done during deployment processing
[17:32:11] <alesj> e.g. @FooBar is tied to FooBarInterceptor
[17:32:37] <alesj> which I wanna squeeze into existing EJB interceptor chain
[17:33:01] <Nihility> alesj: did you talk to stuart?
[17:33:29] <alesj> Nihility: yeah, it was him who did the initial weld as a service approach
[17:33:40] <smarlow> baileyje:  the DS is definitely not working, looking at the services state, H2DS depends on jboss.jdbc-driver."org.h2.Driver".1.2 but there is no service with that name.
[17:33:43] <dmlloyd> he can use a service, that's jsut fine
[17:33:45] *** AndyTaylor has quit IRC
[17:33:56] <dmlloyd> but the service has to be integrated into the deployment processor service chain
[17:34:00] <Nihility> alesj: ok yeah cause he started ejb integration last night, i merged one of his patches, just making sure you saw them
[17:34:05] <baileyje> smarlow: Can you see the jar being deployed?
[17:34:10] *** pmuir_ has joined #jboss-as7
[17:34:10] *** pmuir_ has joined #jboss-as7
[17:34:10] *** ChanServ sets mode: +v pmuir_
[17:34:11] <baileyje> OHHHHHHHHH
[17:34:15] <baileyje> you have to disable OSGI
[17:34:24] *** hbraun has left #jboss-as7
[17:34:30] <Nihility> can someone modify the build to strip osgi from that h2 binary
[17:34:31] <Nihility> ?
[17:34:31] <baileyje> I forgot it still won't let the H2 jar deploy cleanly.
[17:34:39] <smarlow> oh, still, I was being to optimistic about that :)
[17:34:46] <alesj> Nihility: yeah, he did some work, but left the EJbXServices to me … now I see why :-)
[17:34:56] <Nihility> alesj: rofl
[17:35:22] <Nihility> alesj: he promised to be back early his tz, so feel free to pass it back to him when it gets too late for you
[17:35:48] <alesj> Nihility: there are two things to do
[17:35:54] <alesj> 1) register interceptor at service level
[17:36:14] <alesj> 2) be able to lookup EJB with just @EJB instance
[17:36:18] *** pmuir has quit IRC
[17:36:29] <baileyje> smarlow: sorry I forgot to mention that.  I just do it by default without even thinking about it
[17:36:52] <smarlow> baileyje:  cool, I'm caught up with you now.  :)
[17:37:13] <baileyje> So I would try and see if adding the dep on hibernate proxy helps
[17:38:02] <alesj> Nihility: looks like 1) is gonna need quite a re-write ...
[17:38:42] *** pmuir_ is now known as pmuir
[17:38:51] <smarlow> Will do, I'll just assume we are working with Hibernate initially.  I'm not sure if we can dynamically know the dependencies so might need a system config file with per PersistenceProvider settings (I thought we might need that at some point but not for this)
[17:39:04] <smarlow> baileyje:  ^
[17:39:17] <baileyje> smarlow: Yeah.  I would start by getting the hibernate PP working
[17:39:43] <smarlow> baileyje:  I'm taking a little walk and will work on this in a bit...
[17:39:51] <jbossbot> git [jboss-as] push master 9d6c18d.. kabir Get :add-system-property(name=test,value=test) working properly
[17:39:51] <jbossbot> git [jboss-as] push master 022d91d.. bstansberry at jboss dot com Integrate the TransactionalModelController operation handler with the non-transactional...
[17:39:51] <jbossbot> git [jboss-as] push master be653e5.. bstansberry at jboss dot com Only handle slave DC registrations on the master DC
[17:39:51] <jbossbot> git [jboss-as] push master 10b76b2.. bstansberry at jboss dot com Make sure transaction commit handlers reset the initializingHandler
[17:39:51] <jbossbot> git [jboss-as] push master 8caa1b2.. bstansberry at jboss dot com Prevent concurrent master-slave requests to the same slave...
[17:39:52] <jbossbot> git [jboss-as] push master f413548.. bstansberry at jboss dot com Handle uploaded content only on the master
[17:39:52] <jbossbot> git [jboss-as] push master cf0daf6.. bstansberry at jboss dot com Use 2 way communication between master DC and slave
[17:39:52] <jbossbot> git [jboss-as] push master 9e7bc3e.. kabir Avoid deadlock when the result handler in the asynch ModelControllerOperationHandler is forwarded on to another controller asynchronously
[17:39:52] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/132aaaa...9e7bc3e
[17:39:56] <baileyje> I would assume if someone is going to use an alternate, they will need to make sure there app classpath is correct.
[17:41:01] <rmaucher> dmlloyd, two commits: https://github.com/rmaucher/jboss-as/commit/a03509ed55e115603f82018af8fede6b4f2e3c1c https://github.com/rmaucher/jboss-as/commit/492b23a2f1c218eef5e9c37ac3c917dc68521504
[17:41:01] <jbossbot> git [jboss-as] a03509e.. Rémy Maucherat Merge annotation processing util functions, as the code will be removed from metadata.
[17:41:02] <jbossbot> git [jboss-as] 492b23a.. Rémy Maucherat Web 7 Beta5.
[17:41:35] <dmlloyd> rmaucher: I like your commits.  They're always very straightforward :)
[17:41:56] <baileyje> wolfc: did you see my question about EJBContext?
[17:42:00] <rmaucher> the first one is a cleanup (so that a package can be dropped), the second one is a web build used which adds memory oriented defaults which can be enabled
[17:42:47] <rmaucher> dmlloyd, ok, nice if it can make it into the release
[17:42:57] <alesj> baileyje: where do you do @EJB —> actual bean lookup?
[17:43:13] <dmlloyd> rmaucher: testing it now
[17:43:38] <baileyje> alesj: It is done as part of the ee component injections.
[17:44:01] <alesj> which class?
[17:44:04] <alesj> baileyje: ^
[17:44:09] *** smarlow has quit IRC
[17:44:22] <baileyje> alesj: It is initially setup by ..   EjbResourceInjectionAnnotationProcessor
[17:44:43] <baileyje> Which is responsible for finding @EJB injections
[17:44:56] <alesj> ok, yeah, saw that one
[17:45:06] <alesj> that one creates descriptors
[17:45:12] <alesj> which get used / extecuedt where?
[17:45:22] <baileyje> binding them in the local context, and setting up InjectionTargetDescription which will actually inject into a bean when created
[17:45:38] <darranl> hi dmlloyd - has the MSC 1.0.0.Beta7 tag not been pushed to jboss-as yet? https://github.com/jbossas/jboss-as/commit/9c863b11d5b68aa5ed537d8f16af1ae4d2bb9068
[17:45:39] <jbossbot> git [jboss-as] 9c863b1.. David M. Lloyd Upgrade to MSC 1.0.0.Beta7
[17:45:47] <wolfc> baileyje, I don't see your EJBContext question
[17:46:38] <rmaucher> and I'm getting a smoke test failure BTW: BasicOperationsUnitTestCase
[17:46:53] <baileyje> alesj: ComponentInstallProcessor line 256 creates the injections
[17:46:58] <dmlloyd> darranl: I'll check it out
[17:47:05] <darranl> thanks dmlloyd
[17:47:34] <baileyje> wolfc: The question was where the EJBContext comes from.  What impl should be used and is it already being created for the component?
[17:47:41] <dmlloyd> darranl: yeah I forgot to push out the tag, sorry about that
[17:47:45] <dmlloyd> fixed now
[17:48:03] <wolfc> baileyje, I have org.jboss.ejb3.context.CurrentEJBContext which can be used.
[17:48:13] <baileyje> wolfc: I would assume the binding is simply an ObjectFactory like thing that will get the correct one for each instance
[17:48:20] <darranl> thanks dmlloyd, will fetch it now
[17:49:41] <wolfc> baileyje: I also have https://github.com/jbossejb3/jboss-ejb3/blob/master/context/naming/src/main/java/org/jboss/ejb3/context/naming/EJBContextObjectFactory.java
[17:50:34] <baileyje> wolfc: What will will need is a ManagedReferenceFactory for lookups and injection to work,
[17:50:36] <wolfc> https://github.com/wolfc/jboss-as/commit/b0ea1ddbb0611c4dca1a3cccde5bcea4f4ca5e09#L3R37 sets up an interceptor that floats it
[17:50:36] <jbossbot> git [jboss-as] b0ea1dd.. Carlo de Wolf Added SessionInvocationContextInterceptor
[17:50:57] *** tdiesler has quit IRC
[17:52:34] <alesj> baileyje:  so it looks like I would need ManagedReferenceFactory in order to do the @EJB lookup?
[17:53:16] <baileyje> alesj: The ManagedReferenceFactory is used on the binding side.  Are you looking to bind or lookup?
[17:53:24] <baileyje> or are you looking to support @EJB injection?
[17:53:49] <alesj> baileyje: I have @EJB instance, and I need to get the right bean
[17:53:58] <alesj> so lookup
[17:54:44] <baileyje> if it is really lookup, you would need to translate the @EJB into the correct jndi name and just look it up.
[17:55:16] <dmlloyd> it'll crap out if there's a dep missing - the question is how far do we go for weld -> MSC dep mapping
[17:55:39] <baileyje> alesj: The current @EJB processor assumes you are doing a local binding as well
[17:55:42] <baileyje> per the EJB spec
[17:55:49] <baileyje> well EE spec really
[17:55:50] <Nihility> shouldnt we just reuse the binding stuff
[17:56:01] <dmlloyd> we should imo
[17:56:04] <Nihility> and either stuff it into the weld controlled bean, or add a hook to pass weld the instance
[17:56:19] <dmlloyd> well we want to add the dep either way
[17:56:32] <Nihility> weld needs to construct the instance
[17:56:50] <Nihility> but we could maybe do the @EJB injection stuff
[17:57:01] <baileyje> I think I am missing some context.  I agree a dep is needed either way
[17:57:04] *** asoldano is now known as asoldano_away
[17:57:07] <wolfc> alesj, is now only going for the @EJB, BeanInstantiator will come later
[17:57:20] <wolfc> That shouldn't be a big issue
[17:57:56] <alesj> i would guess so :-)
[17:58:04] <wolfc> You guys have to make a decision if WeldServices is allowed to scan and modify DUs
[17:58:37] <wolfc> Or whether it should really be processors
[17:58:53] <Nihility> AFAIK the only thing that modifies DU stuff is web services
[17:59:17] <wolfc> and RS and Weld
[17:59:25] <Nihility> weld allows extensions to create weld annotations but not ejb annotations that would be a value add if we did it
[17:59:28] <aloubyansky> bstansberry: here is cn/cd tab-completion https://github.com/aloubyansky/jboss-as/commit/6e765f99710fc1a3bf66bd61708ec64ef04034f7
[17:59:28] <jbossbot> git [jboss-as] 6e765f9.. Alexey Loubyansky tab-completion for cd/cn
[17:59:51] <wolfc> Weld needs to inject interceptors in the EJB chain
[17:59:57] <alesj> yup
[18:00:09] <bstansberry> aloubyansky: great!
[18:00:20] <alesj> i thought with new Invocation stuff, we could easily add that to the existing chain
[18:00:22] <aloubyansky> bstansberry: it'll need refactoring but after...
[18:00:30] <Nihility> ah ok well in that case it should be able to just add interceptors
[18:00:32] *** pmuir has quit IRC
[18:00:39] <bstansberry> everything needs refactoring after!
[18:00:39] <wolfc> You can from a Processor, but not from a Service
[18:00:58] <dmlloyd> you can use the output from a service in a processor though
[18:01:27] <Nihility> well logically it has to happen at deploy time right?
[18:01:30] *** aloubyansky has quit IRC
[18:01:33] <Jaikiran> dmlloyd: i have some @Lock processing here https://github.com/jaikiran/jboss-as/commits/ejb3
[18:01:40] <Jaikiran> what remains is testing that functionality
[18:01:46] <dmlloyd> yes, Nihility but deployment phases can depend on services and services can depend on deploy phases
[18:02:04] <dmlloyd> in fact services *do* depend on phases whether you want them to or not because they're children
[18:02:09] <Jaikiran> the current smoke tests and demos pass btw
[18:02:16] <Nihility> Jaikiran: awesome
[18:02:27] <alesj> i guess we could re-write WeldService to a DUP
[18:02:49] <alesj> but probably there is a reason stuartdouglas started goind donw the service path
[18:03:06] <alesj> and it's only in service that we know that we need to add a new interceptor to existing chain
[18:03:13] <dmlloyd> it's all about what you need and when
[18:03:17] <Nihility> ah ok
[18:03:19] *** jcosta has quit IRC
[18:03:20] <dmlloyd> it might still make sense for it to be a service
[18:03:35] <Nihility> yeah stuartdouglas had a plan for all of it, shame its not written down haha
[18:03:40] <alesj> :-)
[18:04:32] <Nihility> i know he wanted weld to have control over almost everything if its a weld deployment
[18:04:45] <Nihility> thats probably why its a service
[18:04:52] <wolfc> Jaikiran, better do a release and get rid of that snapshot
[18:04:59] <Jaikiran> wolfc: oops forgot that
[18:05:03] * Jaikiran does a release now
[18:05:53] <Nihility> did anyone look into the failures that smarlow noticed
[18:06:03] <rmaucher> dmlloyd, ok so now I have https://github.com/rmaucher/jboss-as/commit/f5a70402f847b727deb90051f142de549d2d119b https://github.com/rmaucher/jboss-as/commit/f336f663268bfb9461b2f89d2392721600b8054f https://github.com/rmaucher/jboss-as/commit/d4a0f2514216f2ab8e597fd6d91eb4822366188c
[18:06:04] <jbossbot> git [jboss-as] f5a7040.. Rémy Maucherat Merge annotation processing util functions, as the code will be removed from metadata.
[18:06:04] <jbossbot> git [jboss-as] f336f66.. Rémy Maucherat Web 7 Beta5.
[18:06:05] <jbossbot> git [jboss-as] d4a0f25.. Rémy Maucherat Enable back the modeler for this release, it is used to gather web connector statistics.
[18:06:14] <alesj> Nihility: we don't really need to control everything if its a Weld deployment
[18:06:22] <alesj> but should be able to add interceptor to existing chain
[18:06:37] <dmlloyd> rmaucher: I'm still testing your first patch! :)
[18:06:38] <rmaucher> so I'm enabling back that JMX Tomcat stuff, it is used by some class to expose statistics
[18:06:47] <alesj> we could use the same hack we did for AS6 :-)
[18:06:52] <wolfc> It's this wicked class: https://github.com/jbossas/jboss-as/blob/master/weld/src/main/java/org/jboss/as/weld/services/bootstrap/WeldEjbServices.java
[18:07:06] <rmaucher> dmlloyd, well the smoke tests had a problem, so I'm adding a flag to the config
[18:07:10] <dmlloyd> I got a test failure
[18:07:12] <Nihility> alesj: yeah the big problem is that the interceptor chain is expected to reach a "frozen" state at some point for concurrency performance
[18:07:15] <dmlloyd> oh ok, so you know about that
[18:07:27] <dmlloyd> let me try your new patches as well
[18:07:36] <Nihility> although maybe its volatile already
[18:07:37] <alesj> wolfc: yup, that's the one
[18:07:39] <rmaucher> yes, the smoke tests actually use the JMX beans from Tomcat (which I just removed)
[18:08:13] <alesj> Nihility: i would expoect that freeze to come once all services from current batch are done
[18:08:35] <dmlloyd> heh
[18:08:40] <rmaucher> the offending class will be fixed to use a proper Java API rather than JMX in the next release
[18:08:56] <dmlloyd> okay testing new patch
[18:09:05] <Nihility> i wonder what it was using them for
[18:09:21] <rmaucher> it's statistics stuff anyway, not critical things
[18:09:30] <dmlloyd> add that to the beta2 list...
[18:09:43] *** mmoyses_ is now known as mmoyses
[18:09:45] <Nihility> after beta1 jira reorg is happening
[18:09:47] <rmaucher> like, expose the bytes written by a http connector
[18:09:49] <Nihility> i want to capture all of this stuff
[18:09:57] <dmlloyd> yeah I've got a big list of stuff to enter
[18:10:27] <stuartdouglas> morning all
[18:10:29] <dmlloyd> hopefully we'll be able to have a "fix it or kill it" policy for JIRAs
[18:10:33] <dmlloyd> morning stuartdouglas
[18:10:39] <dmlloyd> up early!
[18:10:48] <wolfc> alesj, I think WeldDeploymentProcessor needs to pass DU into WeldEjbServices constructor, but I don't see how you can depend on a phase
[18:10:49] <dmlloyd> someone get the man some coffee quick!
[18:11:24] *** jfd has quit IRC
[18:12:12] <wolfc> Hmm, it installs way too late. So EJBs are already unmodifiable.
[18:12:20] <alesj> stuartdouglas: just in time for a quick morning EjbServices discussion :-)
[18:12:28] <stuartdouglas> yay
[18:12:35] <jbossbot> git [jboss-as] push master f5a7040.. Rémy Maucherat Merge annotation processing util functions, as the code will be removed from metadata.
[18:12:35] <jbossbot> git [jboss-as] push master f336f66.. Rémy Maucherat Web 7 Beta5.
[18:12:35] <jbossbot> git [jboss-as] push master d4a0f25.. Rémy Maucherat Enable back the modeler for this release, it is used to gather web connector statistics.
[18:12:36] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/9e7bc3e...d4a0f25
[18:13:08] <dmlloyd> nice to see that system-properties works :)
[18:13:16] <alesj> stuartdouglas: since we have it all services based, while ee descriptors are done in DUPs, we cannot properly modify the interceptor chain ...
[18:13:43] <rmaucher> dmlloyd, yah ! workarounds, workarounds ...
[18:14:18] <stuartdouglas> moving weld to be a DUP rather than a service won't be great for performance
[18:14:54] <alesj> yeah :-(
[18:15:00] <dmlloyd> stuartdouglas: I think it can still be a service as long as e.g. INSTALL for the DUP depends on it, in order to perform the changes to the interceptors
[18:15:36] <dmlloyd> or, perhaps, the component CREATE phase can depend on it
[18:15:49] <alesj> dmlloyd: can we just get the iceptor chain to modify it?
[18:15:52] <stuartdouglas> can we register a special weld interceptor, that is responsible for running all the weld related interceptors
[18:15:59] <dmlloyd> alesj: no! it's immutable
[18:16:11] <dmlloyd> alesj: well it comes in two flavors
[18:16:16] <dmlloyd> not-thread-safe, and immutable :)
[18:16:20] <rmaucher> dmlloyd, thanks :) now testing mode for me
[18:16:22] <alesj> stuartdouglas: that's how we did it in AS6
[18:17:19] <alesj> stuartdouglas: i'll go down that path then
[18:17:27] <alesj> as I think we should be still fine
[18:17:30] <alesj> ok?
[18:18:09] <stuartdouglas> I think that is the way to go
[18:18:21] <alesj> stuartdouglas: the other thing I was looking at was EjbInjectionServices
[18:18:25] *** fnasser has joined #jboss-as7
[18:18:25] *** ChanServ sets mode: +v fnasser
[18:18:51] <alesj> but I don't really see how to get bean from just @EJB
[18:19:08] <alesj> stuartdouglas: looking at ComponentInstallP
[18:19:21] <alesj> it looks like I need the right ManagedRefFactory
[18:19:32] <stuartdouglas> yea
[18:20:33] <alesj> so one should iterate over ResrouceInjections and find the right one?
[18:20:57] <stuartdouglas> no, not ResourceInjections
[18:21:15] <alesj> i need the instabnce that has MRefFactory
[18:21:22] <alesj> and that's ResrouceInjection
[18:21:31] <dmlloyd> no
[18:21:45] <dmlloyd> JNDI bindings are all of type Service<ManagedReferenceFactory>
[18:21:54] <dmlloyd> that's where you get your instance from generally
[18:22:09] <alesj> so I just need to find the right Service?
[18:22:11] <dmlloyd> if you're injecting components
[18:22:20] <stuartdouglas> yes, you just need the right service
[18:22:22] <dmlloyd> all the deps are via Service
[18:22:50] <alesj> ok, i need to see how the ServiceName gets constructed for EJB bean then
[18:22:54] <Nihility> stuartdouglas: glad you could make it early today
[18:22:55] <wolfc> as a side note, Weld doesn't want a client proxy
[18:23:23] <Nihility> dmlloyd: btw stuartdouglas and i researched module name conflicts and so on
[18:23:27] <stuartdouglas> no, you need to be able to get different client proxies for the same bean instance
[18:23:47] <alesj> a?
[18:23:48] <wolfc> It wants a SessionObjectReference
[18:23:53] <Nihility> dmlloyd: all application contexts need to be registered in global, and standalone modules at the same level
[18:24:11] *** pmuir has joined #jboss-as7
[18:24:11] *** ChanServ sets mode: +v pmuir
[18:24:14] <dmlloyd> Nihility: but not comp?
[18:24:16] <stuartdouglas> when is JPA going to be merged?
[18:24:18] <Nihility> dmlloyd: all modules need to be visible under application context
[18:24:21] <alesj> wolfc: that's a EJBServices, not EjbInjectionServices
[18:24:35] <alesj> stuartdouglas: which diff client proxies?
[18:24:37] <Nihility> dmlloyd: except for standalone modules which do not have redundant names
[18:24:43] <dmlloyd> Nihility: ok I don't think we're doing that right now
[18:24:47] <Nihility> dmlloyd: and finally conflicting names need to generate a new name
[18:24:49] <wolfc> ah yes, my bad
[18:25:00] <Nihility> dmlloyd: right comp is never visible to anyone else
[18:25:36] <dmlloyd> Nihility: well that should be easy enough to implement, I gues
[18:25:40] <alesj> stuartdouglas: why wouldn't looking up service work for EjbInjectionSertvice?
[18:25:40] <Nihility> dmlloyd: so in a nutshell apps can do java:global/application/module/FooBean
[18:26:01] <dmlloyd> we should probably just use references for that, what do you think
[18:26:06] <Nihility> dmlloyd: yeah should be trial we can just have module contexts have a dep on application or global
[18:26:15] <stuartdouglas> alesj: it will
[18:26:18] <Nihility> and then inject the reference
[18:26:34] <alesj> stuartdouglas: what was the client proxy issue then?
[18:26:40] <Nihility> that way they get cleaned up and so on
[18:26:44] <dmlloyd> yeah
[18:26:56] <dmlloyd> guess we need a ReferenceBindingService then
[18:26:57] <Nihility> dmlloyd: also another bizare thing is that the spec contradicts itself regarding dir names
[18:27:01] <stuartdouglas> alesj: That is an EjbServices issue
[18:27:05] <Nihility> dmlloyd: but stuartdouglas and i think it shoudl respect them
[18:27:11] <dmlloyd> Nihility: you mean in terms of "foo.ear" vs "foo"?
[18:27:23] <Nihility> dmlloyd: e.g. foo.ear/ejbs/foo.jar and foo.ear/ui/foo.war
[18:27:24] <stuartdouglas> back to @Ejb if lookup= is specified, then you need to use ContextNames.serviceNameOfContext
[18:27:27] <alesj> stuartdouglas: you mean for resolveEjb()?
[18:27:29] <dmlloyd> I had noticed some apparent contradiction
[18:27:34] <stuartdouglas> yea
[18:27:54] *** jfd has joined #jboss-as7
[18:27:55] *** ChanServ sets mode: +v jfd
[18:27:57] <Nihility> dmlloyd: in that case the module name "should" be "ejbs/foo" and "ui/foo"
[18:27:59] <stuartdouglas> if there is no lookup= you need to use the bean name and the bean interface to construct the portable JNDI neame
[18:28:06] <stuartdouglas> and then do the same thing
[18:28:26] * stuartdouglas wonders if the coffee machine will wake up my wide
[18:28:40] <stuartdouglas> s/wide/wife/
[18:28:44] <wolfc> Jaikiran, I've pushed a new ejb3-ee branch.
[18:29:11] <Jaikiran> wolfc: ok. i just released alpha2 and am just doing a mvn clean install of AS7 branch with it
[18:29:29] <wolfc> Jaikiran, the original ejb3-ee is no longer
[18:29:44] * Jaikiran checks
[18:29:44] <alesj> stuartdouglas: what's the issue with resolveEjb()?
[18:30:09] <stuartdouglas> no issue, you were just asking how the service names are constructed
[18:30:32] <alesj> ok, same mechanism as from EjbInjectionServices?
[18:31:17] <alesj> stuartdouglas: ^
[18:31:40] <stuartdouglas> no, you can't use the same method
[18:32:29] <stuartdouglas> In EjbInjectionServices you can basically do the equivalent of looking up the bean in JNDI
[18:32:52] <stuartdouglas> in EjbServices you need to be able to get multiple client views for the same bean instance
[18:33:07] <alesj> ok, but for EjbServices::resolveEjb?
[18:34:21] *** frainone_lunch has quit IRC
[18:34:29] <Jaikiran> wolfc: the only major new commit is this, i guess? https://github.com/wolfc/jboss-as/commit/65de351cb2f79ed55a0c0f2963c065bfdd519b04
[18:34:30] <jbossbot> git [jboss-as] 65de351.. Carlo de Wolf Added PerViewMethodInterceptorFactory for per method system interceptors
[18:34:41] <alesj> stuartdouglas: how do I get that … multiple views?
[18:34:48] *** maeste has quit IRC
[18:34:48] *** pmuir has quit IRC
[18:34:50] <wolfc> Jaikiran, I cleaned up the first commit
[18:35:08] <stuartdouglas> not sure yet, will let you know when I have had some coffee
[18:35:21] <alesj> stuartdouglas: :-)
[18:35:27] <Jaikiran> dmlloyd: fyi - i have pushed a commit to move away from SNAPSHOT to a new EJB3 release https://github.com/jaikiran/jboss-as/commits/ejb3
[18:35:46] <dmlloyd> okay
[18:35:55] <dmlloyd> should I pull this whole branch?
[18:36:00] <jbossbot> git [jboss-as] push master 2c2a365.. bstansberry at jboss dot com Disable broken classloading tests
[18:36:00] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/d4a0f25...2c2a365
[18:36:02] <wolfc> That's the old commit
[18:36:14] *** jfclere has quit IRC
[18:36:18] <baileyje> wolfc: Are there plans to make the CurrentEJBContext available to the AS codebase?
[18:36:24] * Jaikiran is rebasing
[18:37:22] <wolfc> baileyje, it is available
[18:37:37] <baileyje> ok.  Must just not have some maven dep
[18:38:25] <wolfc> dmlloyd, this is the cleaned up branch https://github.com/wolfc/jboss-as/commits/ejb3-ee
[18:38:48] <wolfc> baileyje, there is a commit in that branch that'll bring it in
[18:38:55] *** alesj has left #jboss-as7
[18:39:01] <baileyje> wolfc: Ok.  Sounds good.
[18:39:34] <wolfc> there is also https://github.com/wolfc/jboss-as/commit/65de351cb2f79ed55a0c0f2963c065bfdd519b04 to scrutinize over
[18:39:34] <jbossbot> git [jboss-as] 65de351.. Carlo de Wolf Added PerViewMethodInterceptorFactory for per method system interceptors
[18:39:46] <Jaikiran> wolfc: i'll just recreate my local branch with this then. i was fixing some rebasing issues
[18:39:52] <dmlloyd> wolfc: can you rebase it?
[18:39:59] <wolfc> sure
[18:41:20] <stuartdouglas> how many hours until we release?
[18:41:38] <stuartdouglas> and when is jpa getting merged, as I have the weld integration for JPA pretty much ready to go
[18:41:59] <dmlloyd> release == ASAP but probably not for 5-6 hours or so from the looks of things
[18:43:14] <stuartdouglas> wolfc: At the moment is there any way to get multiple client views of the same SFSB?
[18:43:15] <wolfc> I finally figured out how to call the different interceptor types. An interceptor is tied to an object's (VM, Component, Instance) lifecycle and bound to an invocation (path) (e.g. Method)
[18:43:31] <wolfc> stuartdouglas, that should work
[18:44:17] <wolfc> So we have method bound system interceptors tied to an Instance
[18:44:38] <wolfc> dmlloyd, rebase is done: https://github.com/wolfc/jboss-as/commits/ejb3-ee
[18:44:51] <dmlloyd> thanks wolfc
[18:46:06] <stuartdouglas> wolfc: how do I do it though?
[18:46:40] <wolfc> https://github.com/wolfc/jboss-as/commit/abc7d278fd0fe256806278e7e6078bbf33aaa2a3
[18:46:41] <jbossbot> git [jboss-as] abc7d27.. Carlo de Wolf Dummy instance interceptor
[18:47:00] <dmlloyd> wolfc: so we moved interceptor construction again eh? :)
[18:47:10] <wolfc> dmlloyd, no, this is the next level
[18:47:39] <wolfc> previously I moved system interceptors bound to a Component
[18:47:58] <wolfc> these are the method bound system interceptors tied to an Instance
[18:48:19] <wolfc> I was thinking of drawing up a matrix of all interceptor configs
[18:48:54] <wolfc> the spec only does * bound interceptors tied to an Instance
[18:52:24] <wolfc> For system interceptors we now have: Component bound interceptors tied to VM or Component and method bound interceptors tied to an Instance.
[18:52:47] *** smarlow has joined #jboss-as7
[18:52:47] *** ChanServ sets mode: +v smarlow
[18:57:52] *** smarlow has quit IRC
[18:58:03] <jbossbot> git [jboss-as] push master 42b1a4e.. Carlo de Wolf Instantiate the component interceptor after component instantiation
[18:58:03] <jbossbot> git [jboss-as] push master b0b439a.. Carlo de Wolf Add a ComponentInterceptorFactory for per Component interceptors
[18:58:03] <jbossbot> git [jboss-as] push master 56ba6f9.. Carlo de Wolf Allow sub-classes of Description to process component and view methods
[18:58:03] <jbossbot> git [jboss-as] push master 0c62abc.. Carlo de Wolf Initial integration of CMT tx interceptor
[18:58:03] <jbossbot> git [jboss-as] push master b72ea95.. Carlo de Wolf Moved EJBUtilities class to the proper architectural level
[18:58:04] <jbossbot> git [jboss-as] push master 3071aad.. Carlo de Wolf Reinstated the default interceptor from descriptor demo as 2 class interceptors
[18:58:04] <jbossbot> git [jboss-as] push master 6c78e99.. Carlo de Wolf Refactored Singleton for TX
[18:58:04] <jbossbot> git [jboss-as] push master 8e8d625.. Carlo de Wolf Added SessionInvocationContextInterceptor
[18:58:04] <jbossbot> git [jboss-as] push master 0cd2e52.. Carlo de Wolf Never block forever
[18:58:05] <jbossbot> git [jboss-as] push master f2a095e.. Carlo de Wolf Added PerViewMethodInterceptorFactory for per method system interceptors
[18:58:06] <jbossbot> git [jboss-as] push master ddfc027.. jaikiran Initial implementation for @ConcurrencyManagement and @Lock support for @Singleton EJBs
[18:58:06] <jbossbot> git [jboss-as] push master 946cdc9.. jaikiran @AccessTimeout processing and more @Singleton implementation
[18:58:06] <jbossbot> git [jboss-as] push master e75ebb9.. jaikiran Upgrade to 2.0.0-alpha-2 of EJB3
[18:58:07] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/2c2a365...e75ebb9
[18:58:08] *** frainone has joined #jboss-as7
[18:58:08] *** ChanServ sets mode: +v frainone
[18:58:14] <wolfc> nice, thanks
[18:58:15] <dmlloyd> wolfc: next!
[18:58:56] <wolfc> Jaikiran, I think we have a bug. unlock SFSB should only happen on commit.
[19:01:18] <jbossbot> git [jboss-as] push master 454c7cf.. Alexey Loubyansky tab-completion for cd/cn
[19:01:19] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e75ebb9...454c7cf
[19:01:35] <Jaikiran> wolfc: on tx commit you mean?
[19:01:41] <wolfc> yes
[19:02:11] *** torben has quit IRC
[19:03:52] *** smarlow has joined #jboss-as7
[19:03:53] *** ChanServ sets mode: +v smarlow
[19:04:44] <Jaikiran> wolfc: for now SFSB lock interceptors aren't enabled
[19:04:51] <Jaikiran> it's just on Singleton
[19:07:28] *** darranl has quit IRC
[19:09:19] *** emmanuel has quit IRC
[19:27:33] <Jaikiran> Nihility: stuartdouglas: ever seen this? http://pastebin.com/CuuyU0KU
[19:28:30] <stuartdouglas> no, but I can debug it now if you want
[19:28:34] <Jaikiran> the method is annotated as follows http://pastebin.com/rLL8Akxj
[19:29:50] <Jaikiran> stuartdouglas: i might be able to get past that for now by a workaround. let me file a JIRA later
[19:29:54] <Jaikiran> if i get past this
[19:30:09] <smarlow> baileyje:  hi, took longer than expected to get back online.  My first attempt to add Hibernate module dependencies didn't seem to help.  Maybe I need to enable an MSC debug logging setting to see which jar is really missing here.
[19:30:11] <stuartdouglas> that should be enough for me to debug
[19:34:18] <stuartdouglas> Jaikiran: I can see the problem
[19:34:27] <Jaikiran> stuartdouglas: cool! easy to fix?
[19:34:58] <Nihility> dmlloyd: can you do a modules release
[19:35:08] <stuartdouglas> kinda, it looks like TimeUnit.SECONDS.getClass().isEnum() is false, as the enum values are actually nestled inner classes
[19:36:16] <baileyje> smarlow: Which jar Is that class that is missing in?
[19:36:18] <Jaikiran> i see. my workaround of not setting that "unit" value failed, btw. which is obvious now that you explain the problem
[19:37:30] <smarlow> baileyje: modules/org/javassist/main/javassist-3.12.1.GA.jar
[19:38:06] <baileyje> smarlow: I lost the stack trace, can pastbin it?
[19:40:33] <smarlow> baileyje: sure, will do.  By the way, I only added a dependency on org.hibernate.hibernate which includes all of the other hibernate related modules via http://pastie.org/1671227
[19:40:50] <smarlow> baileyje:  I wonder if I need an export or something in that module.xml ^
[19:40:59] * smarlow getting the exception stack...
[19:41:31] <baileyje> smarlow: They are not transitive by default..
[19:42:26] <smarlow> baileyje:  exception stack is here http://pastie.org/1671229
[19:42:38] <smarlow> baileyje:  how to make them transitive?  export?
[19:43:14] <baileyje> smarlow: Yeah.  BUt it will likely be better for the processor to just add the deps needed to the deployment.
[19:43:20] <baileyje> Transitive deps can get scary
[19:43:38] <baileyje> although if you end up adding all the deps to the deployment, that would be gross as well
[19:44:10] <smarlow> baileyje:  okay, in the grand scheme of things, what does it mean that I added the dependency to javassist in the hibernate module def?
[19:44:44] <baileyje> smarlow: That if it needs it, then it isn't a big deal
[19:46:40] <smarlow> baileyje:  as in an optional dependency that can be retrieved if needed?  but doesn't become a transitive dependency?
[19:47:10] <baileyje> nope.  The only way to become transitive is to export.
[19:47:38] <stuartdouglas> Jaikiran: releasing a new classfilewriter now
[19:47:47] <Jaikiran> stuartdouglas: thanks!
[19:48:41] <dmlloyd> Nihility: yeah I was going to do one today
[19:51:55] *** echelog-2 has joined #jboss-as7
[19:58:01] *** adietisheim has quit IRC
[19:58:01] *** rawbdor has joined #jboss-as7
[20:00:23] <stuartdouglas> Jaikiran: Did the new version fix the problem?
[20:00:56] <Jaikiran> stuartdouglas: build in progress :)
[20:01:00] <Jaikiran> just a few more min
[20:01:39] <Jaikiran> stuartdouglas: that fixed it! thanks :)
[20:02:02] <smarlow> baileyje:  cool, just as a quick hack, I exported the javassist dependency on hibernate and that helped.  I'll remove the export and make it a dependency on the deployment as well.
[20:04:26] <baileyje> smarlow: Great.
[20:04:48] *** stansilvert has quit IRC
[20:07:07] <smarlow> baileyje:  looks like I need to add another dependency for JTA for hibernate as well.
[20:07:49] <baileyje> wolfc, dmlloyd: are we creating java:comp namespaces?
[20:07:58] <dmlloyd> yes, we should be
[20:08:08] <dmlloyd> depending on NamingMode
[20:08:18] <wolfc> I hope so
[20:08:44] <baileyje> ok.  I will have to track down why I am missing a dep on the EJB components comp service
[20:08:56] <wolfc> I was under the impression that NamingMode was always set to CREATE, so we create java:comp always (also in war deployments)
[20:10:11] <wolfc> ah no, the default is ComponentNamingMode.NONE
[20:10:47] <baileyje> Should we make CREATE the default and disable it for MBs?
[20:10:52] <wolfc> baileyje, set it to CREATE in EJBComponentConfiguration for the moment
[20:11:07] <baileyje> Sounds good.
[20:11:14] <wolfc> It needs more work for war deployments
[20:12:03] <jbossbot> git [jboss-as] push master e1f9c21.. Jason T. Greene Notify the user that they need a .dodeploy file when a deployment is noticed
[20:12:04] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/454c7cf...e1f9c21
[20:13:32] <Nihility> hopefully that avoids some confusion
[20:15:35] <Nihility> smarlow: how is jpa coming?
[20:16:07] <smarlow> Nihility:  need to get through a few class not found errors in hibernate but am moving forward.
[20:21:22] <Nihility> smarlow: no pressure ROFL
[20:21:24] <Nihility> :)
[20:21:46] <Nihility> baileyje: what are you working on atm?
[20:21:52] <smarlow> :)
[20:21:58] <baileyje> Nihility: binding EJBContext
[20:23:23] <baileyje> stuartdouglas: There is an issue with BeanValidationFactoryDeployer
[20:23:40] <stuartdouglas> yes?
[20:24:37] <baileyje> Still trying to track it.  It seems to be attempting to bind the ValidatorFactory multiple times for a component
[20:24:39] <jbossbot> git [jboss-as] push master fce0c18.. Jason T. Greene Log when a deployment is being stopped
[20:24:40] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/e1f9c21...fce0c18
[20:25:32] <stuartdouglas> that seems odd
[20:25:44] <stuartdouglas> there cause the logic is the same as for UserTransaction etc
[20:25:45] <baileyje> yeah.,  Still tracking int..
[20:26:06] <baileyje> Have you actually had a component with a java:comp get created?
[20:26:27] <wolfc> did anybody test ComponentNamingMode.CREATE?
[20:27:03] <smarlow> baileyje:  In JPADependencyProcessor, is there a way to inject a dependency on the TransactionManagerService?  Or do we have to have a module definited for TransactionManagerService?
[20:27:11] <stuartdouglas> I didn't, I wrote that code before we had any components that had ComponentNamingMode.CREATE
[20:27:25] <baileyje> stuartdouglas: Just a bug.  You the module name was being passed in instead of the component name.
[20:28:41] <stuartdouglas> oops, it also looks like a similar bug in TransactionJndiBindingProcessor
[20:29:28] <baileyje> yeah. I fixed them both
[20:29:48] <baileyje> I will test it out and make sure it is funcitoning.
[20:31:24] * wolfc is afk for a bit
[20:33:52] <Jaikiran> dmlloyd: my final set of commits for today https://github.com/jaikiran/jboss-as/commits/ejb3. added a read lock testcase and upgraded classfilewriter to bring in stuartdouglas' fix for annotation value processing
[20:34:00] <Jaikiran> it's been rebased on latest upstream
[20:34:17] <dmlloyd> okay.
[20:34:21] <dmlloyd> testing now
[20:34:24] <Jaikiran> ok
[20:34:47] <Jaikiran> i was planning a test for write lock semantics on singleton, but it's too late now and am too sleepy.
[20:34:59] <Jaikiran> will add some test tomorrow
[20:36:29] *** smcgowan has quit IRC
[20:38:34] <Jaikiran> going by a demo we have, the write semantics look OK
[20:39:30] <dmlloyd> okay
[20:40:17] <smarlow> baileyje:  never mind, its something else.  Need to specify hibernate.transaction.manager_lookup_class...
[20:40:21] <jamezp> dmlloyd: Thinking about the DependsOn processing… …SInce they are always @Singleton's does it make sense to create a list sorted by which Singletons need to be created first?
[20:40:27] *** smcgowan has joined #jboss-as7
[20:40:27] *** ChanServ sets mode: +v smcgowan
[20:40:37] <dmlloyd> jamezp: no, let MSC sort the dependencies
[20:41:06] <Jaikiran> dmlloyd: just a fyi - it's not just a dependency thing for @DependsOn
[20:41:08] <dmlloyd> jamezp: you just need to find out what each one depends on, and make sure those dependencies are added to the appropriate ServiceBuilder
[20:41:12] <dmlloyd> Jaikiran: oh?
[20:41:32] <jamezp> dmlloyd: Got it thanks.
[20:41:34] <Jaikiran> dmlloyd: the spec says that for the @DependsOn controls the call to @PostConstruct on the dependent singleton beans
[20:41:58] <Jaikiran> so even if you bring up those beans in the right order, we need to make sure that when the instance is being created, we take into account the @DependsOn beans
[20:42:25] <dmlloyd> ah you're talking about lazy singleton
[20:42:27] <dmlloyd> right?
[20:42:28] <Jaikiran> right
[20:42:35] <Jaikiran> a singleton without @Startup
[20:42:41] <Jaikiran> @DependsOn applies to those too
[20:42:53] <dmlloyd> the dependency will make sure they're available - I think that the creation would be a different concern though, separate code
[20:43:01] <Jaikiran> right
[20:43:01] <dmlloyd> we'd need to share the source dep list though
[20:43:08] <Jaikiran> exactly
[20:43:24] <dmlloyd> well we'll get the MSC dep sorted out first, worry about the rest later
[20:43:29] <dmlloyd> I'll make a note though
[20:43:34] <Jaikiran> sure
[20:44:09] <Jaikiran> dmlloyd: so, i'll be off for now. see you guys tomorrow
[20:44:11] <Jaikiran> good night!
[20:44:14] <dmlloyd> okay, thanks Jaikiran
[20:44:21] *** Jaikiran has quit IRC
[20:44:41] <jbossbot> git [jboss-as] push master 28efc59.. jaikiran Added testcase for Read lock type singleton bean and some fixes for @AccessTimeout annotation processing. Also upgraded classfilewriter to bring in a fix for annotation scanning bug
[20:44:41] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/fce0c18...28efc59
[20:53:21] <baileyje> wolfc: WHen you are back ping me
[20:54:33] <jbossbot> git [jboss-as] push master bce4397.. bstansberry at jboss dot com Move standalone server deployment convenience API out of server module
[20:54:33] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/28efc59...bce4397
[20:55:31] *** opalka has joined #jboss-as7
[20:55:31] *** opalka has joined #jboss-as7
[20:55:31] *** ChanServ sets mode: +v opalka
[21:03:21] <kkhan> bstansberry: https://github.com/kabir/jboss-as/commit/8666f80cd5b2b7d2477321c9d4aae96bd3868ee0
[21:03:22] <jbossbot> git [jboss-as] 8666f80.. kabir Make read-resource for no address pull in slave results
[21:03:41] <dmlloyd> Nihility: http://github.com/dmlloyd/jboss-modules/commit/aaf4017
[21:03:41] <jbossbot> git [jboss-modules] aaf4017.. David M. Lloyd [MODULES-69] Support for filtering of classes and resources (part 1 - initial filtering support for loader types)
[21:03:42] <jbossbot> jira [MODULES-69] Allow for OSGi style Class Filtering [Open (Unresolved) Feature Request, Major, David Lloyd] https://issues.jboss.org/browse/MODULES-69
[21:03:43] *** kkhan is now known as kabir_back_soon
[21:04:59] <smcgowan> dmlloyd:  https://github.com/smcgowan/jboss-as/commit/c5a18ccc6ff758ce3cddcd315ce46de8c450ba2a
[21:05:00] <jbossbot> git [jboss-as] c5a18cc.. Shelly McGowan JBCTS-1083 - resolve javax.servlet.jsp.jstl linkage errors
[21:05:19] <smcgowan> dmlloyd:  i think i messed up my repo after that though
[21:05:29] <dmlloyd> haha no worries
[21:05:36] <dmlloyd> I can cherry-pick this commit
[21:06:05] <smcgowan> dmlloyd:  i'm still only seeing the jaxrs linkage errors locally, so let's wait for a hudson run to confirm
[21:06:11] *** frainone has left #jboss-as7
[21:06:17] <smcgowan> and the javax.persistence APIs I see have also been integrated
[21:06:56] <jbossbot> git [jboss-as] push master 7188d97.. Shelly McGowan JBCTS-1083 - resolve javax.servlet.jsp.jstl linkage errors
[21:06:57] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/bce4397...7188d97
[21:07:20] <dmlloyd> smcgowan: okay cool, as always let me know if you need something looked at
[21:07:21] <smcgowan> dmlloyd:  how can i be sure i'm sync'd correctly with master?
[21:07:36] <dmlloyd> depends
[21:07:41] <dmlloyd> do you have local stuff you want to save or not?
[21:07:59] <wolfc> baileyje: pong
[21:08:25] <stuartdouglas> git fetch origin && git reset --hard origin/master will do it, but will wipe out any local changes
[21:08:42] <baileyje> wolfc: Ok.  I have the EJBContext binding.
[21:08:43] <bstansberry> kkhan: sorry, been looking at your patch; should have acknowledged your message!
[21:08:52] <wolfc> cool
[21:08:59] <baileyje> I don't however see it ever being set on the CustomSessionInvocationContext
[21:09:19] <dmlloyd> smcgowan: if you use stuart's method make sure you do a "git status" to make sure there's no garbage left around
[21:09:20] <wolfc> Yeah, that bit needs work.
[21:09:29] <baileyje> It also seems to be chicken and egg issue if you inject it.
[21:09:32] <wolfc> Also the AS 7 classes don't implement the SPI.
[21:09:39] <wolfc> Why?
[21:09:42] <stuartdouglas> or git clean -f
[21:10:06] <baileyje> Since the injection will require the current EJBContext to be pushed, but the EJB context objects look like they need an instance
[21:10:41] <wolfc> The invocation EJBContext is pushed.
[21:10:41] <smcgowan> stuartdouglas:  i'll try that,
[21:10:50] <baileyje> wolfc: Injection happens as part of component creation.
[21:10:56] <Nihility> dmlloyd: looks good
[21:11:01] <dmlloyd> awesome.
[21:11:12] <baileyje> wolfc: Does the EJB context not need the instance?
[21:11:15] <smcgowan> i used --hard earlier and looked like i got some older changes
[21:11:20] <wolfc> Injection needs to happen within an interceptor chain anyway.
[21:11:54] *** alesj has joined #jboss-as7
[21:12:11] <baileyje> IN the case of a stateless it is being injected during DummyComponentInterceptor
[21:12:23] *** emuckenhuber has quit IRC
[21:12:51] <smcgowan> dmlloyd:  and I'll let you know if there is something to look at:  TCK back up and running
[21:13:47] <smcgowan> and because of stuartdouglas changes: we see blue here: http://hudson.qa.jboss.com/hudson/view/TCK6-AS7-WEB/job/tck6-as7-jta_web-profile/6/testReport/unknownTestSuite.0/
[21:14:11] <wolfc> baileyje, that's not going to fly
[21:14:31] <wolfc> instance instantiation and injection need to happen within an interceptor chain
[21:14:43] <baileyje> They are
[21:14:53] <baileyje> You need to be more clear what you mean when you say that
[21:15:03] <wolfc> No, they're not. They appear to be because you call from within an interceptor chain.
[21:15:05] <baileyje> They currently are happening in the chain
[21:15:18] <baileyje> That is what I mean by being more clear
[21:15:32] <baileyje> what do you mean when you say in the chain.
[21:15:42] <baileyje> Since they are being run within an interceptor in the chain
[21:15:56] <wolfc> Suppose I inject a SLSB into another SLSB.
[21:16:08] <baileyje> yeah
[21:16:16] <wolfc> The second SLSB needs to be instantiated without a TX. This is taken care of by an interceptor.
[21:17:37] <wolfc> A better example might be an eager Singleton.
[21:17:57] <wolfc> It is instantiated at @Startup. Which isn't tied at all to a client interceptor chain coming in.
[21:18:48] *** opalka has quit IRC
[21:19:14] <wolfc> Anyway, don't worry about this bit for the moment. The EJBContext bit will work out once the proper instance EJBContext is associated with the invocation EJBContext.
[21:21:08] *** frainone has joined #jboss-as7
[21:21:08] <bstansberry> kkhan: i'll push that in a sec. but for a later release we should look into a param to disable crossing proxies
[21:21:18] *** ChanServ sets mode: +v frainone
[21:21:37] <bstansberry> which would have to be smart and drop the "local" host as well
[21:21:47] <smcgowan> baileyje:  the database drivers needs are deployed as a "user" deployment
[21:21:49] <smcgowan> ??
[21:21:54] <jbossbot> git [jboss-as] push master 242f887.. kabir Make read-resource for no address pull in slave results
[21:21:54] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/7188d97...242f887
[21:22:04] <baileyje> smcgowan: Yes.
[21:22:29] <smcgowan> baileyje:  i currently have them defined as a module - that's should be changed i guess
[21:22:56] <baileyje> Well, it still says module in the config, but needs to be changed to driver
[21:24:20] * wolfc bbl
[21:25:16] *** pretec has joined #jboss-as7
[21:25:21] *** pretec has left #jboss-as7
[21:25:33] <jbossbot> git [jboss-as] push master 1625bd4.. Jason T. Greene Log stopped message with stop time...
[21:25:34] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/242f887...1625bd4
[21:26:42] <Nihility> ok
[21:26:59] <smcgowan> baileyje:  this derby entry look about right: http://pastebin.test.redhat.com/43886
[21:27:37] <Nihility> dmlloyd: what do you think about a facility to have a static module be seen as a Driver deployment
[21:27:46] <baileyje> smcgowan: Can you post that on a public pastbin?  I am not on the VPN right now
[21:27:57] <Nihility> dmlloyd: one explicitly configured
[21:29:06] <dmlloyd> Nihility: I'm okay with the concept of static modules providing Drivers...
[21:29:40] <baileyje> Nihility: I was thinking something along the lines of having another element in the datasources subsystem for driver modules
[21:30:25] <baileyje> And make sure the datasource element is fixed so in no longer call the driver class "module"
[21:30:30] <dmlloyd> Nihility: the question is, do we have two ways to register a driver, or do we have one way but then have a way to fake out a deployment with a module, or do we have one way to do deployments but allow content to come from modules somehow, or do we provide a deployment that's just a Dependency meta-inf item plus a services/ file for the driver
[21:30:41] <dmlloyd> all those solutions kinda suck in different ways
[21:31:19] <smcgowan> baileyje:  sure: http://pastebin.com/BXxGqMv9
[21:31:43] *** jfd has quit IRC
[21:32:07] <baileyje> smcgowan: Looks correct as it is today
[21:32:24] <smcgowan> thanks for the confirmation, i'll give it a go
[21:32:35] *** kabir_back_soon is now known as kkhan
[21:33:29] <Nihility> dmlloyd: one problem we are going to run into, is using vendor types on a user deployed driver, the only workable solution at the moment is class-path. a module import will cause problems since that will be different classes
[21:33:44] <smcgowan> baileyje:  and the jndi-name"jdbc/DB1" needs to resolve to java:comp/env/jdbc/DB1 - so is that correct or do I have to add the java:comp
[21:33:58] <Nihility> dmlloyd: unless of course we had the ability to register the module with the Driver deployer
[21:34:06] <Nihility> dmlloyd: and it just pretends like its a deployment
[21:34:11] *** emuckenhuber has joined #jboss-as7
[21:34:11] *** emuckenhuber has joined #jboss-as7
[21:34:11] *** ChanServ sets mode: +v emuckenhuber
[21:34:22] <baileyje> smcgowan: The java:comp should only come into play when something is looking for it..
[21:34:33] <dmlloyd> Nihility: well under no circumstances should we copy the classes no matter what
[21:34:42] <baileyje> smcgowan: From a component.  What is looking it up?
[21:34:46] <dmlloyd> Nihility: I think we should really discourage that whenever possible
[21:35:18] <smcgowan> baileyje:  i know that, but want to be sure I don't have to fully define it in the config
[21:35:20] <Nihility> dmlloyd: yeah i think you can either deploy something as a static module OR a deployment not both
[21:35:32] <Nihility> else it can never work
[21:35:39] <baileyje> smcgowan: You would not fully define it in this config.
[21:35:49] <smcgowan> ok, good, that's what I thought just checking
[21:36:20] <smarlow> do we have anything setup to bind the transaction manager to jndi java:/TransactionManager?
[21:37:19] <Nihility> smarlow: IIRC we have a TM bound into comp
[21:38:27] <baileyje> smarlow: Yes.  The TransactionJndiBindingProcessor.java
[21:38:46] <Nihility> stuartdouglas: alesj hey did you guys figure out the interceptor problem?
[21:39:14] <alesj> Nihility: yeah, stuartdouglas already did it AS6 style :-)
[21:39:26] <Nihility> oh
[21:39:31] <Nihility> so do we have weld with ejb?
[21:39:35] <stuartdouglas> not already done yet, but sort of nearly done almost
[21:39:40] <stuartdouglas> not yet
[21:39:44] <stuartdouglas> working on it
[21:39:46] <Nihility> sweet
[21:39:54] <alesj> dmlloyd, Nihility: how can my app make use of existing modules?
[21:40:01] <stuartdouglas> we probably won't be able to properly support SFSB's with multiple views
[21:40:11] <alesj> e.g. I want my app to use jboss-common-core
[21:40:38] <alesj> and jboss-msc and jboss-modules
[21:40:40] <dmlloyd> alesj: well first, be aware that common-core is being removed from AS7 permanently as soon as humanly possible
[21:40:42] <dmlloyd> :)
[21:40:44] <Nihility> alesj: you can add a module-import in the manifest, or you can use the jboss-structure.xml that stuartdouglas added
[21:41:04] <Nihility> alesj: and yes we realize that name choice is bad
[21:41:05] <Nihility> :)
[21:41:08] *** dimitris_ has joined #jboss-as7
[21:41:08] *** ChanServ sets mode: +v dimitris_
[21:41:24] <alesj> Nihility: one would say stuartdouglas never used AS5/6 … :-)
[21:41:59] <alesj> stuartdouglas, Nihility: where do I see schema for jboss-structure.xml?
[21:42:04] <stuartdouglas> I used them, I just never used jboss-structure.xml
[21:42:13] <stuartdouglas> it is similar to jboss modules files
[21:42:14] <alesj> dmlloyd: not jboss-common-core … that's legendary … :-)
[21:42:42] <dmlloyd> yeah well there's a lot of really nasty stuff in there
[21:42:43] <Nihility> the most depended on dep ever
[21:42:44] <alesj> stuartdouglas: where do I put it for war, WEB-INF?
[21:43:00] <stuartdouglas> the schema is in the server module
[21:43:04] <dmlloyd> I want to find out what's still good and move it to a better home, or perhaps a new home, which is more purpose-oriented
[21:43:08] <dmlloyd> no more ball-o-mud
[21:43:10] <stuartdouglas> there are tests under integration that give examples
[21:43:26] <alesj> stuartdouglas, Nihility: I think we should change the name
[21:43:42] <dmlloyd> file a JIRA :)
[21:43:45] <alesj> otherwise folks might have issues deploying the same app to AS6 vs. AS7
[21:43:46] <Nihility> alesj: agreed, we just didnt get around to it
[21:44:05] <alesj> dmlloyd: i'll just lurk for that JIRA to appear :-)
[21:44:08] <Nihility> alesj: i think we were going to call it something like jboss-deployment.xml
[21:44:18] <alesj> Nihility: nah, not gonna work either
[21:44:25] <alesj> also taken :-)
[21:44:27] <Nihility> but thats takjen to
[21:44:33] <alesj> yup
[21:44:34] <Nihility> and then we had a bunch of bad name ideas
[21:44:44] <stuartdouglas> I thought we agreed on jboss-the-file-that-controls-classloading-and-a-few-other-things.xml
[21:44:49] <Nihility> the most entertaining was brian's jboss-anatomy.xml
[21:44:55] <alesj> :-)
[21:45:07] <alesj> jboss-modules.xml?
[21:45:08] <stuartdouglas> and that was why we never changed it
[21:45:16] *** jfd has joined #jboss-as7
[21:45:16] *** jfd has joined #jboss-as7
[21:45:16] *** ChanServ sets mode: +v jfd
[21:45:18] <stuartdouglas> because we could not come up with a better name
[21:45:33] <dmlloyd> alesj: taken, more or less
[21:45:49] <alesj> by modules.xml?
[21:45:51] <Nihility> jboss-classloading2
[21:45:52] <Nihility> haha
[21:45:54] <dmlloyd> yeah it's too similar
[21:45:54] <alesj> hehe
[21:46:23] <bstansberry> Nihility, dmlloyd, emuckenhuber, kkhan: i need to step out for 45 mins or so
[21:46:31] <Nihility> same here actually
[21:46:34] <Nihility> need to take cats to boarding
[21:46:42] <dmlloyd> jboss-deployment-structure.xml!
[21:46:43] <kkhan> bstansberry: I'm looking at adding some model descriptions
[21:46:52] <bstansberry> great
[21:47:06] <Nihility> jboss-assembly.xml?
[21:47:22] <dmlloyd> the thing describes the deployment structure
[21:47:30] <dmlloyd> anyway why did we get sucked back into this :)
[21:47:33] <dmlloyd> alesj: file a JIRA!
[21:48:21] <jbossbot> git [jboss-as] push master b5e9d0b.. Emanuel Muckenhuber use server-config:auto-start...
[21:48:21] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/1625bd4...b5e9d0b
[21:48:36] <alesj> hehe … sorry … :-)
[21:50:54] <baileyje> hmmm..  Just rebase and now i am getting failures..   hmmm
[21:51:43] <alesj> stuartdouglas: is there some example of jboss-structure.xml in AS7?
[21:51:48] <alesj> cant find one ...
[21:51:54] <stuartdouglas> in tests/integration
[21:52:10] <smcgowan> baileyje:  FYI: http://pastebin.com/KASsuFN9
[21:52:12] <stuartdouglas> it's not an actual file, just a string that is added to an ARQ archive
[21:52:50] <alesj> which test class?
[21:53:08] <alesj> searching ...
[21:53:41] <alesj> stuartdouglas: is there one that adds module dep?
[21:54:10] <stuartdouglas> org.jboss.as.tests.deployment.classloading.ear.EarJbossStructureAdditionalModuleTestCase
[21:54:11] <dmlloyd> there's server/src/main/resources/schema/jboss-structure-1_0.xsd if you want the schema
[21:54:29] <stuartdouglas> or org.jboss.as.tests.deployment.classloading.ear.EarJbossStructureDepedenciesTestCase
[21:54:51] <stuartdouglas> these both add the deps to sub deployments, you will need it in the top level <deployment> bit
[21:59:48] <baileyje> dmlloyd: https://github.com/baileyje/jboss-as/commit/76216abd773c6bcead9529fe475412d00485c14f
[21:59:49] <jbossbot> git [jboss-as] 76216ab.. John E. Bailey Add binding description for EJBContext to EJB components.
[22:01:37] *** irooskov has joined #jboss-as7
[22:03:30] <smcgowan> so not much luck, but i'll keep testing and verifying other part of my config are OK: http://pastebin.com/iie5s1it
[22:04:41] <frainone> dmlloyd: to keep you posted, my @WebServiceRef test uses wsdlLocation, and I'm getting a NPE because the Bus (org.apache.cxf.Bus) doesn't have an extension of type WSDLManager.class, the extension that should be used to parse the wsdl file.
[22:05:26] <frainone> some context info: this Bus is provided by org.jboss.ws.core.jaxws.spi.ProviderImpl, and apparently there is nothing I can do from outside ws. I'll try a new test that doesn't use wsdlLocation...
[22:06:05] <smcgowan> the later is using @DataSourceDefinition
[22:07:46] <dmlloyd> baileyje: what branch is that
[22:08:29] <baileyje> master
[22:09:01] *** mmoyses has quit IRC
[22:10:16] <frainone> the actual location of the ProviderImpl class I mentioned is org.jboss.wsf.stack.cxf.client
[22:10:25] *** stansilvert has joined #jboss-as7
[22:13:19] <jbossbot> git [jboss-as] push master 29da87c.. John E. Bailey Add binding description for EJBContext to EJB components.
[22:13:19] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/b5e9d0b...29da87c
[22:14:52] <smarlow> baileyje:  looks like TransactionJndiBindingProcessor only binds UserTransaction + TransactionSynchronizationRegistry to jndi (for WARS or if the EE component naming mode is set to CREATE.
[22:16:02] <stuartdouglas> yea comp/UserTransaction does not really make sense anywhere else
[22:19:24] <smarlow> stuartdouglas:  I'm to supply hibernate with the transaction manager.  It doesn't look like "java:/TransactionManager" is set, which is what I was really looking for
[22:19:52] <dmlloyd> smcgowan: are we packaging derby, or expecting it from the JDK?
[22:19:56] <stuartdouglas> should probably bind that as well then :-)
[22:20:49] <smcgowan> dmlloyd:  am explicity adding the derby.jar and derbyclient.jar to AS 7 as a user deployment
[22:21:03] <smcgowan> not expecting it from the JDK
[22:21:40] <dmlloyd> smcgowan: okay so if your second example is using @DataSoruceDefinition, then your deployment containing it needs to have one or both of those JARs in their class-path
[22:21:48] <dmlloyd> or as a Dependency in the manifest, either way
[22:21:59] <dmlloyd> class-path is the preferred way though I think
[22:22:05] <dmlloyd> (in this case)
[22:22:23] <smcgowan> dmlloyd:  that's ugly, i think, we are not going to have these jars accessible as a system deployment?
[22:22:51] <dmlloyd> well there's really no way to auto-detect what DBs you want to access in most cases
[22:23:00] <dmlloyd> at least not with @DataSoruceDef
[22:23:15] <dmlloyd> there could be multiple versions of a DB driver for example
[22:23:18] <smcgowan> but the DB is a system configuration isn't it?
[22:23:25] <stuartdouglas> smarlow: Are you ok with setting up the binding?
[22:23:25] <dmlloyd> not if you use @DataSourceDef
[22:23:47] <dmlloyd> if with @DSD it bypasses the container's datasource mechanism generally
[22:24:30] <dmlloyd> if it's a regular data source injection then the dep can be added automatically based on the datasource config in standalone.xml
[22:24:59] <alesj> stuartdouglas: Caused by: java.lang.NullPointerException
[22:24:59] <alesj> 	at org.jboss.as.server.deployment.module.DeploymentStructureDescriptorParser.deploy(DeploymentStructureDescriptorParser.java:294)
[22:25:03] <smarlow> stuartdouglas:  sure, although I'm not yet understanding the meaning in TransactionJndiBindingProcessor, of checking for componentnaming mode = create?
[22:25:09] <smcgowan> dmlloyd:  i have derby configured in standalone.xml
[22:25:19] <smcgowan> so thought it should be available to the deployment
[22:25:44] <smarlow> stuartdouglas:  I can read the comment (Create a new namespace for this component) but not sure who sets it
[22:26:08] <stuartdouglas> alesj: line 290 should be getAttachmentList rather than getAttachment
[22:26:36] <stuartdouglas> CREATE means that this component has it's own java:comp namespace (i.e. it is an ejb)
[22:27:02] <stuartdouglas> war's also have their own comp namesapce, aliased to java:module
[22:27:14] <stuartdouglas> so if it is a war it binds it into the java:module ns
[22:27:34] <stuartdouglas> and then it looks for ejb's and binds it into their comp namesapce as well
[22:27:34] <dmlloyd> smcgowan: it should be... how are you injecting it
[22:27:54] <smcgowan> dmlloyd:  i should be able to have multiple configurations, and then the app will define the one I want to use
[22:27:57] <stuartdouglas> you can't install java:TransactionManager in that processor
[22:27:58] <smarlow> stuartdouglas:  I know for my JPA demo, component naming mode is none
[22:27:59] <smcgowan> DB configurations, that is
[22:28:06] <stuartdouglas> cause that runs once per deployment
[22:28:17] <stuartdouglas> and you just need to install java:TransactionManager once
[22:28:38] <stuartdouglas> is your JPA demo a war?
[22:28:51] <smarlow> stuartdouglas:  no, just a EJB jar
[22:29:26] <stuartdouglas> I think I saw something a few hours ago about this
[22:30:07] <smcgowan> dmlloyd:  on a stateful bean: http://pastebin.com/v2uw0JDe
[22:30:32] <stuartdouglas> smarlow: I think it was not being set properly, so ejb's were not set to create
[22:30:46] <smarlow> stuartdouglas:  any idea where would be a good place to inject java:TransactionManager?  Guess, it needs to be someplace that depends on the naming service
[22:30:49] <stuartdouglas> not sure if that has made it into upstream yet
[22:31:00] *** jfd has quit IRC
[22:31:10] <smcgowan>  @EJB
[22:31:10] <smcgowan>     private DataSourceIF dataSourceBean;
[22:31:15] <stuartdouglas> TransactionSubsystemAdd is probably where you want to set it up
[22:31:43] <smarlow> stuartdouglas:  oh, if its coming, I could avoid the error by using a non-transactional datasource
[22:31:44] *** miclorb has joined #jboss-as7
[22:32:06] <stuartdouglas> either way, we still need java:TransactionManager at some point
[22:32:19] <smarlow> hmm, I'll try and fix it, if it comes from somewhere else, we won't need my change
[22:32:31] *** slaboure has joined #jboss-as7
[22:32:59] <bstansberry> back
[22:33:16] <alesj> stuartdouglas: is that fixed already?
[22:35:26] <stuartdouglas> alesj: no
[22:35:45] <alesj> how do those tests pass then?
[22:35:55] <stuartdouglas> the tests are an ear
[22:36:03] <stuartdouglas> which has sub deployments
[22:37:17] <alesj> i have .war
[22:40:23] <stuartdouglas> alesj: should be fixed in my master
[22:40:40] <smcgowan> dmlloyd: i'm going to simplify this test a bit -  heading home from office be back on-line after a quick dinner
[22:41:42] <dmlloyd> smcgowan: okay I'm going to look into this a little
[22:45:13] <jbossbot> git [jboss-as] push master b7d622d.. bstansberry at jboss dot com Remove unused experimental code
[22:45:13] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/29da87c...b7d622d
[22:47:22] <dmlloyd> smcgowan: okay ping me when you're back and we'll discuss
[22:48:33] <smcgowan> dmlloyd:  sure thing
[22:48:39] *** smcgowan has quit IRC
[22:49:05] <wolfc> I'm picking up the EJBContext commit
[22:51:35] *** dimitris_jboss has joined #jboss-as7
[22:51:35] *** ChanServ sets mode: +v dimitris_jboss
[22:52:24] <kkhan> bstansberry: https://github.com/kabir/jboss-as/commit/e8f5b2c6a336551998f4216b59ee0be2d61503f0
[22:52:25] <jbossbot> git [jboss-as] e8f5b2c.. kabir JMX, Sar and naming subsystem providers
[22:53:10] <stuartdouglas> does anyone know if SFSB interceptors have to implement Serializable for passivation to work properly? Or are they just automagically Serializable?
[22:54:07] <bstansberry> kkhan: thanks
[22:54:35] <stuartdouglas> wolfc: ^
[22:54:36] <kkhan> Going to do a few more, but I don't think the big horrible ones will happen tonight
[22:55:10] <wolfc> stuartdouglas, user classes magically become serializable
[22:55:16] <bstansberry> for bigger ones, please put the actual modeNode.get(....).set(...) stuff in a separate class with a static method. then call it from the DescriptionProvider
[22:55:30] <dmlloyd> we'll do that serialization stuff via JBMAR
[22:55:38] <dmlloyd> not every class is automatically serializable
[22:55:41] *** fnasser has quit IRC
[22:55:49] <stuartdouglas> that is what I thought, looks like there may be a bug in weld
[22:55:58] <bstansberry> so we don't pay the classloading hit to load all that stuff during bootstrap -- only if people access the description
[22:55:59] <wolfc> I think for the system interceptors we'll mandate them to be serializable
[22:56:13] <dmlloyd> sure we could, we don't have to though
[22:56:26] <wolfc> Weld should not keep weird references in their interceptors
[22:56:52] <stuartdouglas> The issue is validation, weld wants interceptors of SFSB's to implement Serializable
[22:57:10] <kkhan> bstansberry: Got an example?
[22:58:21] <wolfc> why would it want that?
[22:58:40] <bstansberry> kkhan: org.jboss.as.controller.descriptions.common.CommonProviders
[22:59:22] <bstansberry> also ServerDescriptionProviders in the server module
[23:00:06] <stuartdouglas> It wants all SFSB's to be passivation capable, which means the interceptors must be passivation capable, and it checks that through implements Serializable
[23:00:15] <kkhan> Right, so this means that the class is smaller to load when registering the provider in the registry?
[23:00:23] <bstansberry> yep
[23:00:46] <bstansberry> no one asks for descriptions during boot
[23:00:49] <stuartdouglas> but really there are probably other issues here
[23:03:25] *** asoldano_away has quit IRC
[23:04:55] *** dimitris_jboss has quit IRC
[23:07:32] *** smarlow has quit IRC
[23:09:54] <jamezp> dmlloyd: Maybe I'm handling this wrong, but I modeled the @DependsOn after the @Singleton components.
[23:10:33] <dmlloyd> well afaik @DependsOn applies to singletons only so that makes some sense
[23:10:44] <jamezp> I'm getting errors when testing that the component has already been defined.
[23:11:02] <jamezp> Yes, that's why I was using that approach.
[23:11:53] <jamezp> I'm sure I'm just missing something… …so I'm just kind of thinking allowed.
[23:12:17] <dmlloyd> oaky you don't actually want to redefine the component
[23:12:22] <dmlloyd> you want to modify an existing one
[23:12:33] <jamezp> Oh, got it I think.
[23:12:51] <dmlloyd> have a look at org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor for example
[23:13:02] <jamezp> Perfect thanks.
[23:13:06] <dmlloyd> (granted that applies to methods and fields too; this annotation only applies to classes)
[23:13:13] <dmlloyd> that's the one that handles @Resource
[23:13:19] <dmlloyd> so the parsing logic would be similar
[23:13:26] <dmlloyd> but what it does with the info would be different
[23:13:38] <jamezp> Perfect. Thanks. Seems that should make sense then :-)
[23:14:10] <bstansberry> kkhan, emuckenhuber: is there any reason to have module org.jboss.as.aggregate any more?
[23:14:24] <jamezp> Right. That's why my initial thought was to have a sorted collection of SingletonComponents since that's basically what the DependsOn does.
[23:14:24] <emuckenhuber> bstansberry: no, not that i'm aware of
[23:14:31] <kkhan> Same here
[23:14:34] <jamezp> Makes sure the components are created in order.
[23:15:44] <dmlloyd> jamezp: you don't need to do that.  Components are created by the component create service - so all you have to do is make sure that the service has the right dependency.
[23:16:02] <dmlloyd> jamezp: it's actually "created" by the start service, actually.
[23:16:18] <dmlloyd> jamezp: so for each @DependsOn, you add one dependency to the service builder for the component.
[23:16:40] <jamezp> dmlloyd: Right, I need to change the way I'm thinking of it. It's a component itself and should be treated as such :-)
[23:17:01] <jamezp> Right… …it's clicking now. Sorry about that.
[23:17:09] <dmlloyd> jamezp: the singleton that the annotation is attached to is a component, and the singleton being referenced is a component.
[23:17:26] <dmlloyd> jamezp: the service dependency map is accessible via org.jboss.as.ee.component.AbstractComponentDescription#getDependencies().
[23:17:46] <dmlloyd> you'll have to hunt around for how to get the service name for a component though, I don't remember how that works.
[23:18:10] *** dimitris_ has quit IRC
[23:18:11] <jamezp> That's fine, I'll dig around. I think I'm getting it now.
[23:18:36] <dmlloyd> it's related to that thing I was talking about earlier with how we delay some resolution until the INSTALL phase.
[23:18:39] <dmlloyd> with EARs and such.
[23:19:59] <jamezp> Right, that's what I wasn't wrapping my head around. I kept thinking "this needs to happen first", but no classes have been instantiated  yet so I need to quit thinking they have.
[23:23:29] <kkhan> bstansberry: A few more simple ones https://github.com/kabir/jboss-as/commit/31f78b278c37b8feaa69503049e2cfd80971cc0a
[23:23:31] <jbossbot> git [jboss-as] 31f78b2.. kabir Managed beans, Ee and EJB 3subsystem providers
[23:23:46] <bstansberry> thanks
[23:36:22] *** smarlow has joined #jboss-as7
[23:36:22] *** ChanServ sets mode: +v smarlow
[23:42:34] <jbossbot> git [jboss-as] push master bed2e5d.. kabir JMX, Sar and naming subsystem providers
[23:42:35] <jbossbot> git [jboss-as] push master 31f78b2.. kabir Managed beans, Ee and EJB 3subsystem providers
[23:42:35] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/b7d622d...31f78b2
[23:45:01] *** jpearlin has joined #jboss-as7
[23:46:01] <frainone> dmlloyd: I had to add org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec dependency to jboss-as-demos/pom.xml... however, I still get a CNFE when testsuite is run. The CNFE comes from Module "org.jboss.as.demos:main"
[23:46:50] <frainone> dmlloyd: how can I fix the module? I found the testsuite demos-arquillian-module-ref.xml file, which I believe is from where org.jboss.as.demos:main module is being generated
[23:47:10] <stuartdouglas> frainone: you need to add it to the test configuration in testsuite/smoke/src/test/resources/modules/
[23:47:14] <frainone> I just don't know what to add to the file in order to get access to javax.xml.ws.Service
[23:47:27] <stuartdouglas> I think it is demos-arquillian-module-def.xml
[23:48:06] <frainone> stuartdougas: yeah, it is. I just don't know what should I add to that file
[23:49:16] <stuartdouglas> in the last bit of the file, inside  <module name="org.jboss.as.demos">
[23:49:37] <stuartdouglas> you will need to add the module identifier for the module that contains your class
[23:49:50] <frainone> exactly, except that I have no idea of which module would that be :(
[23:49:58] <stuartdouglas> what class is it?
[23:50:17] <frainone> javax.xml.ws.Service
[23:50:33] <frainone> from org.jboss.spec.javax.xl:jboss-jaxws-api_2.2_spec dep
[23:50:57] <frainone> I mean, from org.jboss.spec.javax.xml.ws:jboss-jaxws-api_2.2_spec dep
[23:51:40] <stuartdouglas> javax.xml.ws.api
[23:51:49] <frainone> thanks a million!
[23:52:04] <stuartdouglas> the mapping between module names and maven artifacts is in build/build.xml
[23:52:33] <bstansberry> wolfc, everyone, are you seeing frequent failures in the ejb3 smoke tests? http://pastebin.com/YGXG6nmM
[23:53:01] <frainone> stuartdouglas: I'll keep that in mind :)
[23:53:37] <frainone> dmlloyd: still no luck. My last resource is to compare this execution with AS6 and try to figure out why there is no NPE there
[23:54:02] <wolfc> bstansberry, no I haven't seen that one yet
[23:54:11] <frainone> dmlloyd: I'll first stop for half an hour or so for dinner, should be back asap
[23:54:14] *** frainone is now known as frainone_dinner
[23:54:38] <dmlloyd> okay frainone_dinner, thanks
[23:57:23] <jbossbot> git [jboss-as] push master 7a91d93.. bstansberry at jboss dot com Fix the H2DB declaration in domain.xml
[23:57:23] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/31f78b2...7a91d93

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