[00:12:58] *** AndyTaylor has quit IRC
[00:16:49] *** asaldhan has left #jboss-as7
[00:19:03] <jpearlin> Nihility:per your e-mail, you believe that Heiko's issue is with the DMR code itself?
[00:21:56] <baileyje> dmlloyd: There?
[00:37:08] <dmlloyd> baileyje: what
[00:37:11] <dmlloyd> 's up
[00:37:30] <baileyje> I was thinking we may need a clear place where interceptors are destroyed.
[00:43:09] <dmlloyd> they should be destroyed at the same time as the component instance
[00:43:49] *** alesj has quit IRC
[00:44:07] <dmlloyd> note that org.jboss.invocation.Interceptor instances are not the same as, and should not be conflated with, @Interceptor object classes
[00:44:14] <baileyje> dmlloyd: They may be.  The key is, do we have a way to know.  In order to call the pre-destroy methods on the interceptors.
[00:44:24] <baileyje> dmlloyd: Correct.
[00:45:09] <dmlloyd> yeah the component instance should know the pre-destroy methods to call
[00:45:28] <stuartdouglas> I have an interesting MSC dump: http://fpaste.org/rFcc/
[00:45:37] *** pferraro has quit IRC
[00:45:48] <stuartdouglas> module.service."deployment.managedbean-example.ear.managedbean-mbean.sar".main claims to have missing dependencies
[00:45:56] <stuartdouglas> however they all seem to be up
[00:46:53] <Nihility> jpearlin: It mght be the old flush bug
[00:47:10] <Nihility> jpearlin: As soon as I get my daughter to bed I'll check it out
[00:47:48] *** balunasj has joined #jboss-as7
[00:47:48] *** ChanServ sets mode: +v balunasj
[00:48:02] <Nihility> dmlloyd: I always correct bug descriptions
[00:48:22] <Nihility> Server hang -> does not complete
[00:49:49] *** aslak has quit IRC
[00:51:27] *** smcgowan_afk is now known as smcgowan
[00:52:08] <jpearlin> Nihility:  ok...let me know if you need me to check anything out
[00:53:28] <baileyje> dmlloyd: So you think we should add the predestroy methods for the interceptors to the component?
[00:54:03] <Nihility> jpearlin: the client side is a GWT app with a special ported version of dmr
[00:54:14] <Nihility> so ist dmr-javascript essentially
[00:55:37] <jpearlin> it sounded like the thinking was that the issue was on the server side, unless I misunderstood
[00:55:52] <dmlloyd> baileyje: yes (well for the class and default level ones anyway)
[00:56:48] <baileyje> dmlloyd: Yeah.  I just need a good way for the pre-destroy to get ahold of an instance of the interceptor.
[00:57:15] <dmlloyd> yeah I guess that's the real trick - seems like it would make sense to get that info up front
[00:57:25] <dmlloyd> so that you just have a list of things to call which are already wired up
[00:57:37] <dmlloyd> instead of having to keep those instances around seperately
[00:58:12] <baileyje> Yeah.  I agree.  But the interceptor instances come to life as needed by the Interceptor factories
[00:58:20] <baileyje> So the instances aren't pre-known.
[00:59:15] <dmlloyd> if the class/default-level interceptor factories are separately listed you could spin through that list again, using the same interceptor factory context
[01:02:22] <dmlloyd> brb
[01:02:43] *** emuckenhuber has quit IRC
[01:05:40] *** smarlow has quit IRC
[01:06:56] *** fnasser has quit IRC
[01:07:59] *** smarlow has joined #jboss-as7
[01:07:59] *** ChanServ sets mode: +v smarlow
[01:10:52] *** Sacha has quit IRC
[01:15:03] *** emuckenhuber has joined #jboss-as7
[01:15:03] *** emuckenhuber has joined #jboss-as7
[01:15:04] *** ChanServ sets mode: +v emuckenhuber
[01:24:23] *** bgeorges has joined #jboss-as7
[01:30:01] *** bgeorges has quit IRC
[01:32:48] *** jamezp has left #jboss-as7
[01:36:39] <stuartdouglas> dmlloyd: frainone: Are either of you there? I have a MSC question
[01:37:17] <dmlloyd> go for it
[01:37:54] <stuartdouglas> I just had a MSC blip where it was showing missing deps, even though all the deps were installed
[01:38:10] *** balunasj has quit IRC
[01:38:11] <stuartdouglas> And I think it may be due to ServiceContainerImpl.getOrCreateRegistration()
[01:38:20] <stuartdouglas> is it does not appear to be called under lock
[01:38:34] <stuartdouglas> so it is possible to get two ServiceRegistrations for the same service
[01:38:54] <stuartdouglas> unless there is something I am missing?
[01:39:02] <dmlloyd> ah yeah that's a bug
[01:39:08] <dmlloyd> it doesn't actually need to be called under a lock anymore
[01:39:17] <dmlloyd> but it _should_ be doing putIfAbsent for sure
[01:40:57] <stuartdouglas> you want me to fix it?
[01:43:11] <dmlloyd> sure
[01:43:25] <dmlloyd> it should still do a get first, that's lockless
[01:43:46] <Nihility> right on
[01:43:56] <Nihility> get followed by putIfAbsent
[01:44:15] <Nihility> they could make a getPutIfAbsent combo op
[01:44:20] <Nihility> its so common
[01:44:22] <Nihility> :)
[01:48:06] <stuartdouglas> https://github.com/stuartwdouglas/jboss-msc
[01:48:34] <stuartdouglas> should fix it
[01:48:42] <stuartdouglas> hopefully this was what caused the MSC blip
[01:48:53] <stuartdouglas> and there is not another concurrency bug :-)
[01:49:53] <jpearlin> Nihility:  is there a next step with the file upload stuff, or are we done for now until the http console comes a little further along?
[01:53:31] <stuartdouglas> dmlloyd: I also have quite a bit of stuff in my jboss-as master that is ready to merge
[01:53:51] *** rmaucher has quit IRC
[01:53:55] <stuartdouglas> Including moving all the component stuff back to PARSE
[01:55:08] <stuartdouglas> however it seems like the phases are getting somewhat out of control, as it is not really documented anywhere which processors have to run before other processors
[01:57:45] *** pgier has quit IRC
[02:08:11] <smarlow> stuartdouglas:  are you seeing that "out of control" issue within phases or between phases?  Or maybe both?
[02:17:31] <stuartdouglas> smarlow: I was just referring to how may processors there are in each phase
[02:17:50] <stuartdouglas> and it is hard to know which ones are in a given spot because it is important they are there
[02:18:14] <stuartdouglas> and which ones are just there because they need to go somewhere (i.e. which processors depend on other processors in the phase)
[02:19:47] <smarlow> stuartdouglas:  yeah, kind of hard to visualize it (I wonder if we could generate a textual description at runtime that is somewhat readable)
[02:21:04] <stuartdouglas> or we could use msc to track dependencies between processors :-)
[02:25:09] *** jamezp has joined #jboss-as7
[02:26:38] <smarlow> stuartdouglas:  maybe it might help if we describe the dependencies between processors in Phase.java?  At the start of each Phase, X needs to run before Y.  Y needs to run before Z type stuff
[02:27:14] <stuartdouglas> considering how may of them there are I think it would get out of date very quickly
[02:28:00] <smarlow> It might get ugly to read as well but, it would be nice to have a place to state such dependencies
[02:31:49] <smarlow> stuartdouglas:  even some simple rules, like, your processor can be moved to any slot in Phase, except before/after any other processors that you have comments that you must be before/after respectfully
[02:32:39] <stuartdouglas> yea, although some kind of annotation based system would probably be better
[02:32:49] <stuartdouglas> cause then you could validate it at build time
[02:32:53] <stuartdouglas> possibly
[02:33:28] <smarlow> stuartdouglas:  +1 for the annotation based system, whether you could validate with it or not.  It would be a nice way to express the dependency
[02:38:53] <dmlloyd> that's why I started documenting the states
[02:46:54] <Nihility> jpearlin: i think we are done for now with that.
[02:47:44] <jpearlin> ok..sounds good
[02:48:02] <jpearlin> let me know if you need anything else with it or if any issues crop up
[02:48:05] <jpearlin> like that dmr one
[02:48:14] <Nihility> jpearlin: the only other item that we could do at this point would be to support inlining an upload with a request for non browser clients
[02:48:38] <jpearlin> is that something you expect to support in the future?
[02:50:43] <Nihility> jpearlin: yeah i think its probably a good idea for programatic clients, they probably expect a simple interface
[02:51:23] <jpearlin> so would you expect http or something else
[02:51:44] <Nihility> jpearlin: although its not that hard to do just simulate a form post from a client
[02:51:52] <jpearlin> right...that was my thought
[02:51:57] <jpearlin> it doesnt seem too different from a post
[02:52:07] <jpearlin> other than needing to have an http client library
[02:52:11] <jpearlin> in your tool of choice
[02:52:26] <Nihility> i think what it takes is just writing a JSON client using some language
[02:52:33] <Nihility> and seeing how it feels
[02:52:42] <Nihility> if it seems clunky then we may want to look into that
[02:52:46] <jpearlin> I don't know that you would even need to be that complicated
[02:53:13] <jpearlin> I guess you would need JSON parsing for the response
[02:53:22] <Nihility> like ruby, perl or python
[02:53:36] <jpearlin> yeah...that's what I was thinking...a sample perl or python app
[02:53:45] <jpearlin> showing how to do it cli style instead of through the console
[02:53:52] <jpearlin> for those who want to automate deployments, etc
[02:54:08] <Nihility> well we have a cli interface thats just started
[02:54:27] <Nihility> thats in java and uses the native api
[02:54:32] <Nihility> although it does not yet have deployment
[02:54:35] <jpearlin> well...I guess the question is:  do you want people to use the CLI or are you open to letting them write their own tools
[02:54:37] <Nihility> or fancy shortcut commands
[02:54:55] <Nihility> we definitely want poeople to write their own tools
[02:54:56] *** pferraro has joined #jboss-as7
[02:54:56] *** ChanServ sets mode: +v pferraro
[02:55:00] <Nihility> or be able to i mean
[02:55:08] <jpearlin> yeah...that was really my question
[02:55:23] <Nihility> thats why we supported JSON primarily
[02:55:26] <jpearlin> so, is an http interface good enough for that, or should we expose something else
[02:55:27] <Nihility> just because its popular
[02:55:34] <Nihility> lots of frameworks already for it
[02:56:01] <jpearlin> because, to be honest, I think almost anyone writing a script in perl or python to upload a file would be happy to use http
[02:56:53] <jpearlin> it really sounds like we just need to document how to do it (i.e. the url to call, the post params, etc)
[02:57:13] <Nihility> yeah its really a question of what the scripting languages support well
[02:57:34] <jpearlin> can you think of one that doesn't have some support for http and JSON?
[02:58:10] <jpearlin> or would allow you to write some simple json library, if needed
[02:58:21] <Nihility> well both approaches would be http
[02:58:43] <Nihility> im just wondering wether its better to support a generic attachment mechanism
[02:58:51] <jpearlin> right...but I guess I don't see what getting rid of the post buys us
[02:59:17] <jpearlin> are you thinking some sort of streaming mechanism?
[02:59:22] <Nihility> it would still be a post the only difference is you would not be posting iusing form encoding
[02:59:30] <jpearlin> ah...got ya
[02:59:57] <Nihility> you would be posting a json request + one to many attachemnts
[03:00:29] <Nihility> but yeah it might not be that much better
[03:00:29] <jpearlin> well...if that was the case, you could just put the attachment in the json request itself
[03:00:32] <jpearlin> yeah
[03:00:34] <jpearlin> agreed
[03:01:02] <jpearlin> ok...well let me know if you want me to look into it
[03:01:02] <Nihility> right now we have one operation that makes sense to send a stream
[03:01:11] <Nihility> so the form stuff is fine
[03:01:15] <jpearlin> ok
[03:01:32] <jpearlin> I'm also going to keep an eye on Heiko's issue, in case it comes back  around to me ;)
[03:02:53] <jpearlin> Nihility:  I forgot to ask...should there be a test somewhere for the upload stuff (maybe in the test suite)?
[03:03:02] <jpearlin> i.e. should I create one
[03:03:35] <Nihility> jpearlin: yeah we should probably have a test
[03:04:08] <Nihility> if you are volunteering go for it :)
[03:04:20] <jpearlin> sure
[03:05:15] <jpearlin> I assume it should go in the testsuite module?
[03:05:33] <jpearlin> as an integration test?
[03:05:46] <Nihility> jpearlin: yes, check out some of the other tests that start the server
[03:06:03] <jpearlin> yup...ok.  I'll work on that this week and hopefully get that to you this weekend
[03:06:40] <jpearlin> thanks a bunch...have a good night!
[03:06:40] *** jamezp has quit IRC
[03:06:47] <Nihility> you too!
[03:07:09] *** jpearlin has left #jboss-as7
[03:07:13] *** smcgowan has quit IRC
[03:07:56] *** jamezp has joined #jboss-as7
[03:24:53] <stuartdouglas> dmlloyd: Would you be adverse to adding a method to the MSC MBean to make it easier to trace failed / missing dependency problem?
[03:24:57] <stuartdouglas> something like: https://github.com/stuartwdouglas/jboss-msc/commit/5372393e30b6a2e5f11552a621ddaf2a96b468bb
[03:24:58] <jbossbot> git [jboss-msc] 5372393.. Stuart Douglas Add method to MBean to more easily trace failed/missing dependencies
[03:25:56] <dmlloyd> within the next couple days I'll actually be adding a mechanism to track which actual dependencies are missing
[03:26:24] <stuartdouglas> that would be better :-)
[03:27:06] *** JimMa has joined #jboss-as7
[03:27:39] <stuartdouglas> the ServiceContainerImpl.getOrCreateRegistration() fix is in my master if you want to merge it
[03:29:10] *** jwulf has quit IRC
[03:42:28] *** pferraro has quit IRC
[04:10:20] *** jamezp has quit IRC
[04:19:03] *** miclorb_ has quit IRC
[04:19:10] *** miclorb_ has joined #jboss-as7
[04:22:51] *** jwulf has joined #jboss-as7
[04:23:19] *** smarlow has quit IRC
[05:01:07] *** bobmcw has joined #jboss-as7
[05:01:07] *** ChanServ sets mode: +v bobmcw
[05:01:36] *** bobmcw has quit IRC
[05:02:02] *** bobmcw has joined #jboss-as7
[05:02:03] *** ChanServ sets mode: +v bobmcw
[05:20:46] *** frainone has quit IRC
[05:39:57] *** irooskov has quit IRC
[05:44:52] *** jwulf has quit IRC
[05:57:05] <jbossbot> git [jboss-as] push master 6147492.. Emanuel Muckenhuber fix deployment handler validation
[05:57:06] <jbossbot> git [jboss-as] push master ca6a6f1.. Emanuel Muckenhuber result aggreggation for deployment-upload and simple concurrent-plan fix
[05:57:06] <jbossbot> git [jboss-as] push master af10dec.. Emanuel Muckenhuber change operation routing for deployment-content actions
[05:57:06] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/809d89c...af10dec
[06:01:16] *** bstansberry is now known as bstans_zzz
[06:22:22] *** jwulf has joined #jboss-as7
[07:58:03] *** bgeorges has joined #jboss-as7
[07:58:03] *** ChanServ sets mode: +v bgeorges
[08:08:10] *** emuckenhuber has quit IRC
[08:09:07] *** bgeorges_ has joined #jboss-as7
[08:09:08] *** ChanServ sets mode: +v bgeorges_
[08:10:45] *** bgeorges has quit IRC
[08:17:20] *** opalka has joined #jboss-as7
[08:17:20] *** opalka has joined #jboss-as7
[08:17:20] *** ChanServ sets mode: +v opalka
[08:17:32] <opalka> morning
[08:24:30] *** Nihility has quit IRC
[08:37:09] *** aslak has joined #jboss-as7
[08:37:09] *** ChanServ sets mode: +v aslak
[08:39:05] *** tdiesler has joined #jboss-as7
[08:39:07] *** tdiesler has joined #jboss-as7
[08:39:07] *** ChanServ sets mode: +v tdiesler
[08:48:54] *** hbraun has joined #jboss-as7
[08:52:24] *** pil-afk is now known as pilhuhn
[08:52:25] *** emuckenhuber has joined #jboss-as7
[08:52:25] *** emuckenhuber has joined #jboss-as7
[08:52:25] *** ChanServ sets mode: +v emuckenhuber
[08:56:31] *** AndyTaylor has joined #jboss-as7
[08:56:32] *** ChanServ sets mode: +v AndyTaylor
[08:56:36] *** AndyTaylor has left #jboss-as7
[08:57:11] *** dimitris_ has joined #jboss-as7
[08:57:11] *** ChanServ sets mode: +v dimitris_
[09:10:05] *** miclorb_ has quit IRC
[09:12:33] *** dimitris_jboss has joined #jboss-as7
[09:12:33] *** dimitris_jboss has joined #jboss-as7
[09:12:33] *** ChanServ sets mode: +v dimitris_jboss
[09:13:00] *** dimitris_ has quit IRC
[09:14:14] *** adietisheim has joined #jboss-as7
[09:17:13] *** rmaucher has joined #jboss-as7
[09:28:17] *** alesj has joined #jboss-as7
[09:31:20] *** Nihility has joined #jboss-as7
[09:31:21] *** Nihility has joined #jboss-as7
[09:31:21] *** ChanServ sets mode: +v Nihility
[09:31:28] *** Jaikiran has joined #jboss-as7
[09:31:28] *** ChanServ sets mode: +v Jaikiran
[09:49:02] *** wolfc has joined #jboss-as7
[09:49:07] *** wolfc has quit IRC
[09:49:07] *** wolfc has joined #jboss-as7
[09:49:07] *** ChanServ sets mode: +v wolfc
[09:49:44] *** Sacha has joined #jboss-as7
[09:52:08] *** ALR has joined #jboss-as7
[09:52:08] *** ChanServ sets mode: +v ALR
[10:14:08] *** ALR has quit IRC
[10:20:53] *** maeste has joined #jboss-as7
[10:20:54] *** ChanServ sets mode: +v maeste
[10:22:28] *** jhalliday has joined #jboss-as7
[10:29:02] *** bgeorges_ has quit IRC
[10:31:41] *** miclorb_ has joined #jboss-as7
[10:33:00] *** jcosta has joined #jboss-as7
[10:33:01] *** ChanServ sets mode: +v jcosta
[10:36:03] *** AndyTaylor has joined #jboss-as7
[10:36:03] *** ChanServ sets mode: +v AndyTaylor
[10:40:13] <opalka> Jaikiran, wolfc how is EJB3 work going?
[10:53:16] *** jcosta has quit IRC
[10:53:37] *** jcosta has joined #jboss-as7
[10:53:37] *** ChanServ sets mode: +v jcosta
[10:55:12] *** aslak has quit IRC
[10:55:37] *** aslak has joined #jboss-as7
[10:55:38] *** ChanServ sets mode: +v aslak
[10:56:18] *** aslak has quit IRC
[10:58:29] <wolfc> opalka, good morning. I say it's going fine :-)
[10:58:47] <wolfc> opalka, do you have an integration test in AS 7 for that Endpoint stuff?
[10:59:33] <wolfc> rephrase: an integration test that does WS over an EJB3
[11:00:05] <opalka> wolfc, No
[11:00:25] <opalka> wolfc, There's also not EJB3 WS integration pulled upstream - I asked for pull on yesterday, but it didn't happen :(
[11:00:45] <wolfc> opalka, where is your branch?
[11:01:01] <opalka> github.com/ropalka/jboss-as/
[11:01:04] <opalka> ejb3-integration
[11:01:58] <opalka> wolfc, but wait a sec. I'll sync it with upstream ...
[11:03:01] <opalka> wolfc, ok, synced
[11:04:20] *** torben has joined #jboss-as7
[11:04:20] *** torben has joined #jboss-as7
[11:04:20] *** ChanServ sets mode: +v torben
[11:06:15] * wolfc is looking
[11:13:36] *** darranl has joined #jboss-as7
[11:13:36] *** darranl has joined #jboss-as7
[11:13:36] *** ChanServ sets mode: +v darranl
[11:22:14] <wolfc> opalka, crock my MDB branch broke on rebasing. I need to fix that first.
[11:22:44] <opalka> wolfc, should be easily fixable
[11:23:10] <wolfc> hehe, it's another hang issue
[11:27:47] *** adietisheim has quit IRC
[11:30:14] *** adietisheim has joined #jboss-as7
[11:41:04] *** davidbos has joined #jboss-as7
[11:41:51] *** aslak has joined #jboss-as7
[11:41:51] *** ChanServ sets mode: +v aslak
[11:47:24] *** davidbos has quit IRC
[12:04:12] *** JimMa has quit IRC
[12:22:26] <wolfc> okay that was fun. a MDB got mixed up in the smoke-tests.
[12:24:53] <stuartdouglas> there is a hang issue that I saw this morning that is a MSC bug, where even though all your services are up MSC things that one is missing
[12:25:11] <stuartdouglas> it should be fixed next msc release
[12:39:40] <hbraun> emuckenhuber: ping
[12:41:51] <wolfc> stuartdouglas, I wasn't sure whether that was what I saw. I did have a MDB in there with a dependency on a rar which was non-existent. So my hang was my problem. :-)
[12:42:13] <wolfc> opalka, I got your branch. What needs to be done in that one?
[12:42:28] <opalka> wolfc, Just fix proper integration EJB3 point
[12:42:39] <opalka> wolfc, Now I'm using some ugly hacks in InvocationHandler*EJB3
[12:42:53] <opalka> wolfc, to lookup appropriate view
[12:43:11] <opalka> wolfc, but this code works only for EJB3s with either remote or local view
[12:45:21] <wolfc> opalka, do you put a dependency on the StatelessSessionComponent?
[12:46:02] <opalka> wolfc, no
[12:46:26] <opalka> wolfc, and it's not necessary
[12:46:32] *** miclorb_ has quit IRC
[12:46:39] <wolfc> opalka, why not?
[12:46:52] <opalka> wolfc, because we're looking up EJB3 during the invocation process
[12:47:08] <opalka> wolfc, We're generating JBossWeb MD from EJB3 MD
[12:47:19] <opalka> wolfc, then these MD are started by JBossWEB
[12:47:31] <opalka> wolfc, and we're accessing EJB3 on first invocation on our endpoint servlet
[12:47:40] <wolfc> opalka, the EJB might not be started
[12:47:52] <opalka> wolfc, why?
[12:48:05] <wolfc> opalka, because nobody put up a dependency on it
[12:48:50] <opalka> wolfc, aha, I understand
[12:49:08] <opalka> wolfc, OK, this should be fixable
[12:49:45] <opalka> wolfc, Does EJB Session & Singleton beans implement Endpoint interface in your fork?
[12:50:32] <wolfc> opalka, no, not yet
[12:51:04] <opalka> wolfc, I'm little bit confused
[12:51:16] <opalka> wolfc, Why I need to add dependency on Session component?
[12:52:08] <opalka> wolfc, I'm calling ServiceController<SessionComponent> MSC.getService(ServiceName)
[12:52:18] <opalka> wolfc, this should start the SessionComponent for me, right?
[12:54:58] <opalka> wolfc, I'm going to spend some time on JAX-RPC these days (till I'll wait for Enpoint interface to be implemented on EJB3 beans)
[12:55:31] <wolfc> opalka, no you would get an IllegalStateException on getValue()
[12:56:00] <opalka> wolfc, why?
[12:56:17] <wolfc> opalka, because that's how MSC works :-)
[12:58:19] * opalka need to study MSC more
[12:59:13] <wolfc> opalka, do we have a failing WS test somewhere?
[12:59:39] <opalka> wolfc, what U mean? EJB3 WS integration test that is failing?
[13:00:25] <opalka> wolfc, https://svn.jboss.org/repos/jbossws/stack/native/trunk
[13:00:35] <opalka> ant deploy-jboss700 -Djboss700.home=$JBOSS_HOME
[13:01:10] <opalka> mvn -Ptestsuite,hudson,jboss700 integration-test -Dtest=**/jaxws/jbws1283/**/*TestCase -Djboss700.home=$JBOSS_HOME
[13:01:15] <wolfc> opalka, I'm not going into that codebase
[13:02:04] <opalka> wolfc, OK, so U want EJB3 WS integration test in AS7 code base then
[13:03:07] <wolfc> opalka, yes, something simple like: https://github.com/jbossas/jboss-as/tree/master/testsuite/integration/src/test/java/org/jboss/as/testsuite/integration/webejb
[13:03:58] <opalka> wolfc, will do
[13:04:09] <opalka> wolfc, hopefully my patch will be applied upstream today including the demo
[13:04:19] <opalka> wolfc, so U can start playing with it
[13:05:42] *** frainone has joined #jboss-as7
[13:05:43] *** ChanServ sets mode: +v frainone
[13:06:57] * opalka 's preparing simple demo ...
[13:09:20] *** frainone has quit IRC
[13:15:42] *** mmoyses has joined #jboss-as7
[13:15:42] *** ChanServ sets mode: +v mmoyses
[13:34:31] *** jpederse has joined #jboss-as7
[13:34:40] *** jpederse has quit IRC
[13:34:40] *** jpederse has joined #jboss-as7
[13:40:19] *** pilhuhn is now known as pil-afk-bbl
[13:40:58] *** fnasser has joined #jboss-as7
[13:41:17] <darranl> hi emuckenhuber - do you have a sec?
[13:44:22] <opalka> wolfc, OK, EJB3 WS integration demo is in place
[13:44:24] <opalka> wolfc, either here U go to play with https://github.com/ropalka/jboss-as/tree/ejb3-integration or wait for my pull request to be applied upstream ;)
[13:45:23] <wolfc> I'm pulling your branch. (Hmm, do not try to translate that in Dutch ;-) )
[13:46:50] *** AndyTaylor has quit IRC
[13:54:32] *** smarlow has joined #jboss-as7
[13:54:32] *** ChanServ sets mode: +v smarlow
[13:55:58] *** frainone has joined #jboss-as7
[13:55:58] *** ChanServ sets mode: +v frainone
[13:56:29] *** asoldano has joined #jboss-as7
[13:56:29] *** ChanServ sets mode: +v asoldano
[13:58:54] *** mbg has joined #jboss-as7
[13:58:54] *** ChanServ sets mode: +v mbg
[14:03:08] *** balunasj has joined #jboss-as7
[14:03:08] *** balunasj has joined #jboss-as7
[14:03:08] *** ChanServ sets mode: +v balunasj
[14:03:14] *** pferraro has joined #jboss-as7
[14:03:14] *** ChanServ sets mode: +v pferraro
[14:12:40] <dmlloyd> good morning
[14:12:49] <darranl> good morning
[14:17:28] <opalka> morning
[14:20:49] <wolfc> opalka, there is nothing failing in that branch, so we're done ;-)
[14:21:12] <opalka> wolfc, ROFL
[14:21:51] <opalka> wolfc, Yes, but there're TODOs to be fixed ;)
[14:22:11] <opalka> wolfc, it's working because there're some fugly hacks in place to make it work (for now)
[14:23:05] <opalka> wolfc, OK, honestly, I need proper EJB3 invocation integration points we discussed before
[14:23:21] <opalka> wolfc, See my InvocationHandler*EJB3 how ugly is it using EJB3 views
[14:25:06] <wolfc> opalka, right, so we need to write tests that break the TODO assumptions
[14:25:24] <wolfc> I'm going for a Singleton, that'll break a lot :-)
[14:25:54] <opalka> wolfc, ok
[14:26:42] <opalka> wolfc, I will provide failing tests in AS7 for you
[14:26:47] <wolfc> opalka, is there a way to skip that wsdl stuff?
[14:27:02] <wolfc> I'm writing one up in testsuite/integration
[14:27:42] <opalka> wolfc, Alessio have some fixes he wants/needs to apply upstream
[14:27:52] <opalka> wolfc, that will simplify our tests from user point of view
[14:28:01] *** mbg has quit IRC
[14:28:05] <opalka> wolfc, i.e. just referencing org.jboss.ws.jaxws-client module artifact
[14:28:20] <opalka> wolfc, and to use pure JAXWS client for playing with webservices
[14:28:36] <opalka> wolfc, but this is not yet there, so for simpler tests we need to wait little bit
[14:28:56] <wolfc> opalka, oh okay. I'll follow your example for now then.
[14:29:07] <wolfc> dmlloyd, do we have a Hudson run on integration-tests?
[14:29:12] <opalka> wolfc, To reproduce first TODO
[14:29:42] <opalka> wolfc, just remove the @Remote annotation from Endpoint interface in wsejb demo
[14:29:57] <dmlloyd> not that I know of wolfc
[14:30:00] <wolfc> opalka, there isn't one :-)
[14:30:14] <wolfc> opalka, you abuse getComponentClass().getInterfaces()[0]
[14:30:23] <dmlloyd> heh
[14:30:30] <wolfc> dmlloyd, right now they are failing :-(
[14:30:53] <dmlloyd> yeah they've been failing for quite some time
[14:32:05] <opalka> wolfc, U're right, this won't reproduce it. OK, remove implements from EndpointImpl then ;)
[14:32:11] <emuckenhuber> darranl: hi, sorry i was out for a while... now i have some time
[14:32:18] *** AndyTaylor has joined #jboss-as7
[14:32:18] *** ChanServ sets mode: +v AndyTaylor
[14:33:00] <darranl> hi emuckenhuber - hopefully a quick question, just wanted to check on naming conventions for add operations
[14:33:34] <wolfc> dmlloyd, I have https://github.com/wolfc/jboss-as/commit/1321585bab27a2b8b3ed05d0bcefa7a5b1e488ea which tests Stuarts fixes to Weld integration
[14:33:35] <jbossbot> git [jboss-as] 1321585.. Carlo de Wolf Test SFSB concurrent access and instance instantiation from Weld
[14:33:46] <darranl> emuckenhuber, based on the following doc http://community.jboss.org/docs/DOC-16576
[14:33:55] <opalka> dmlloyd, I sent pull request to AS7 pull request ML, please review and pull so Carlo can start playing with it against upstream
[14:34:06] <wolfc> dmlloyd, I also have https://github.com/wolfc/jboss-as/commits/JBAS-8969 which has some controversy :-)
[14:34:07] <jbossbot> jira [JBAS-8969] Implement annotation scanner for @MessageDriven. [Open (Unresolved) Sub-task, Major, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-8969
[14:34:22] <darranl> i have a top level <management> element and I am adding an AddHandler to add one or more named security-realm definitions
[14:34:58] <darranl> emuckenhuber, in this case they are all added at the same location so do I use the existing operation name 'add' or do I need a specific name such as 'add-security-realm' ?
[14:36:07] <emuckenhuber> darranl: hmm, well basically you create a submodel for security-realm and then have a simple "add" operation
[14:36:07] *** bobmcw has quit IRC
[14:36:46] <darranl> emuckenhuber, that is what I am currently doing, I just wanted to check that 'add' was a suitable name as it can be called multiple times for different realm definitions
[14:39:37] <emuckenhuber> darranl: yes, usually that should be fine
[14:39:48] <darranl> thanks emuckenhuber
[14:44:37] <asoldano> dmlloyd, good morning; do you have few minutes for some directions on module dependencies ?
[14:44:52] <dmlloyd> sure
[14:45:11] <asoldano> dmlloyd, thanks; so, I'm back at thinking about the spring issue of jbossws-cxf
[14:45:23] *** pgier has joined #jboss-as7
[14:45:23] *** ChanServ sets mode: +v pgier
[14:45:42] <asoldano> dmlloyd, basically, I have the testsuite running properly if I add a spring module and set proper dependencies on it in other modules
[14:45:49] <asoldano> dmlloyd, however of course we can't ship it
[14:46:01] *** balunasj is now known as balunasj_busy
[14:46:15] <asoldano> dmlloyd, in AS6 days, we used to have runtime detection of spring being available enabling use of it if found
[14:46:49] <asoldano> dmlloyd, now, I've tried using the "optional = true" flag in the module dependencies, but that does not seem to do what I though (as I mentioned few weeks ago)
[14:47:20] <asoldano> dmlloyd, because the module that depends on spring module would still fail in being loaded if the spring module is not there
[14:48:27] *** pferraro has quit IRC
[14:48:30] <asoldano> dmlloyd, ideally, user might even provide spring in their deployments instead of having a module available, but the problem is still there
[14:48:49] <dmlloyd> if the tests require spring they're not really accurate then, especially if the thing doesn't work if spring isn't there?
[14:48:54] <asoldano> dmlloyd, iow, how can I make the classes in apache cxf and jbossws module see spring?
[14:49:16] <asoldano> let me explain:
[14:49:37] <asoldano> cxf can work with or without spring; unfortunately some features (ws-sec, for instance) requires spring
[14:50:14] <asoldano> basic features (jaxws stuff) works both with and without instead
[14:50:57] <asoldano> so I need to have the integration work in both cases; by default we don't ship spring and still have what's required for tck etc.
[14:51:02] *** pil-afk-bbl is now known as pilhuhn
[14:51:17] <asoldano> but if the user provide spring somewhere, we support also the advanced stuff (ws-*)
[14:51:58] *** sannegrinovero has joined #jboss-as7
[14:51:58] *** sannegrinovero has quit IRC
[14:51:58] *** sannegrinovero has joined #jboss-as7
[14:51:58] *** ChanServ sets mode: +v sannegrinovero
[14:52:31] *** jfd has joined #jboss-as7
[14:52:31] *** jfd has quit IRC
[14:52:31] *** jfd has joined #jboss-as7
[14:52:31] *** ChanServ sets mode: +v jfd
[14:53:11] <jbossbot> git [jboss-as] push master 32b24fc.. Richard Opalka initial EJB3 integration (WIP)
[14:53:12] <jbossbot> git [jboss-as] push master 981b7a8.. Richard Opalka implemented ugly EJB3 invocation - just to make it work and identify other problems
[14:53:12] <jbossbot> git [jboss-as] push master dfdefc3.. Richard Opalka fixing AS7 WS demo regression - web archive can contain both EJBs & POJOs
[14:53:12] <jbossbot> git [jboss-as] push master b2ed868.. Richard Opalka adding simple EJB3 WS integration demo
[14:53:12] <jbossbot> git [jboss-as] push master badcd5f.. Carlo de Wolf Improved error reporting on component installation failure
[14:53:12] <jbossbot> git [jboss-as] push master f9eb089.. Carlo de Wolf JBAS-9107: Always deploy, no checking anything
[14:53:14] <jbossbot> jira [JBAS-9107] A rar deployment must always activate or error out [Open (Unresolved) Bug, Critical, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9107
[14:53:14] <jbossbot> git [jboss-as] push master 5d67eae.. Carlo de Wolf Iron Jacamar depends on security API
[14:53:15] <jbossbot> git [jboss-as] push master aaed4a2.. Carlo de Wolf Define a message inflow implementation
[14:53:15] <jbossbot> git [jboss-as] push master f173df3.. Carlo de Wolf JBAS-8969: Processing @MessageDriven
[14:53:15] <jbossbot> jira [JBAS-8969] Implement annotation scanner for @MessageDriven. [Open (Unresolved) Sub-task, Major, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-8969
[14:53:15] <jbossbot> git [jboss-as] push master ac94237.. Carlo de Wolf JBAS-8970: implement MDB
[14:53:16] <jbossbot> jira [JBAS-8970] Implement MDB Component type [Open (Unresolved) Sub-task, Major, Carlo de Wolf] https://issues.jboss.org/browse/JBAS-8970
[14:53:16] <jbossbot> git [jboss-as] push master f5557ab.. Carlo de Wolf JBAS-8970: Implement MDB demo
[14:53:16] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/af10dec...f5557ab
[14:53:33] <opalka> thanks!
[14:57:45] <wolfc> woohoo
[14:59:08] <asoldano> dmlloyd, back one month, we had a chat on this topic, but I postponed following up on that because it was blocked by other changes still to do: http://fpaste.org/batk/
[15:00:49] <asoldano> dmlloyd, basically, I'm trying to understand what you meant at point 2) in the end
[15:01:03] <dmlloyd> well consider your cxf module
[15:01:14] <dmlloyd> there's just one class loader for that
[15:01:24] <dmlloyd> now imagine two user deployments which bundle spring
[15:01:32] <dmlloyd> now you've got two copies of spring, possibly different versions
[15:01:36] <asoldano> right
[15:01:39] <dmlloyd> you need an "instance" of your CXF module for each one
[15:01:49] <dmlloyd> in other words a plain module can't do the job
[15:02:11] <asoldano> should I create a new module programmatically?
[15:02:29] <dmlloyd> no
[15:02:54] <dmlloyd> you see the downside here is that with two instances of the module now they're incompatible with each other
[15:03:37] *** bstans_zzz is now known as bstansberry
[15:03:52] <dmlloyd> also, nothing in the AS can link toit
[15:04:08] <dmlloyd> the rule is generally that deployments can link to AS modules but not vice-versa
[15:04:23] <dmlloyd> going the other way requires reflection or redirection through common API modules
[15:04:40] <dmlloyd> i.e. deployment implements some interface inside of AS, so calls can be directed that way
[15:05:19] *** pferraro has joined #jboss-as7
[15:05:20] *** ChanServ sets mode: +v pferraro
[15:07:13] <asoldano> dmlloyd, is there an example or somthing similar to this somewhere?
[15:07:16] <dmlloyd> so basically this is a pretty serious step to take
[15:07:28] <dmlloyd> no, there is nothing, you would be the first and only person to do this
[15:07:34] <dmlloyd> which by itself is a bit of a red flag
[15:07:40] <maeste> wolfc: could you please send me the rar getting to JBAS-9063
[15:07:42] <jbossbot> jira [JBAS-9063] Failing rar deployment is not cleaned up [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9063
[15:07:53] <asoldano> dmlloyd, yes..
[15:08:06] <Jaikiran> wolfc: does the mdb demo work for you?
[15:08:10] <Jaikiran> i get a NPE
[15:08:15] <wolfc> Jaikiran, bummer, where?
[15:08:39] <wolfc> maeste, it's a rar with only a @Connector
[15:08:45] <asoldano> dmlloyd, we might even start by doing the same we did with AS6, ie. assume user create/install a spring module on his server, if that simplifies things
[15:08:47] <Jaikiran> wolfc: http://pastebin.com/WDXYyHhA
[15:08:51] <Jaikiran> resource adapter name
[15:09:16] *** smcgowan has joined #jboss-as7
[15:09:16] *** ChanServ sets mode: +v smcgowan
[15:09:21] <dmlloyd> asoldano: or we could remove the spring dependency somehow?
[15:10:06] <Jaikiran> he he and that NPE shows up JBAS-9077 hang
[15:10:08] <jbossbot> jira [JBAS-9077] Deployment failure leads to a server hang [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9077
[15:10:10] <asoldano> that might mean rewriting half of cxf ;-)
[15:10:26] <wolfc> Jaikiran, hmm, a likely cause is that ext-api isn't found
[15:10:49] <Jaikiran> let me check
[15:12:00] <Jaikiran> i do see it listed in the module.xml and the modules folder
[15:12:31] <Jaikiran> hmm looks like a rebase + merge issue
[15:12:51] <Jaikiran> the ResourceAnnotationprocessor is missing from Ejb3subsystemAdd in my local workspace
[15:12:56] <Jaikiran> let me rebase again
[15:13:36] <wolfc> Jaikiran, I have it there
[15:14:56] <Jaikiran> yep, just realized that the rebase + conflict resolution went wrong in my local branch
[15:15:24] *** torben has quit IRC
[15:18:42] <smarlow> dmlloyd:  could you pull https://github.com/scottmarlow/jboss-as/commit/ba2a4a709d864698636cc8b4b90d2913e1c5f15a, it contains the start of the JPA integration testing (currently broken but may as well share it)
[15:18:43] <jbossbot> git [jboss-as] ba2a4a7.. Scott Marlow JBAS-9081 support for injecting PU into Hibernate session factory, needs to be tested (will probably need more changes but we need a test case to see),forked org.jboss.ejb3.test.epcpropagation.unit.EPCPropagationTestCase
[15:18:44] <jbossbot> jira [JBAS-9081] Inject Persistence Unit into Hibernate session factory [Coding In Progress (Unresolved) Sub-task, Minor, Scott Marlow] https://issues.jboss.org/browse/JBAS-9081
[15:19:38] <Jaikiran> yes, works fine now
[15:21:00] <asoldano> dmlloyd, I'm going back at reasoning on possible choices here, and might sum up the situation in a mailing list message
[15:21:08] <dmlloyd> okay
[15:21:19] <asoldano> dmlloyd, in any case, what's optional=true actually meant to be for?
[15:21:30] <asoldano> in module dependencies, I mean
[15:21:33] <dmlloyd> the most technically sensible answers are (a) just bundle spring or (b) rewrite half of CXF :)
[15:21:57] <dmlloyd> optional=true makes a module load succeed even if the named dependency can't be loaded
[15:22:06] <dmlloyd> otherwise you get a module not found exception
[15:22:24] <asoldano> ok, so why do I get an exception?
[15:22:56] <dmlloyd> what exception?
[15:23:26] <asoldano> let me capture one for you
[15:23:39] *** pilhuhn has quit IRC
[15:23:55] *** pilhuhn has joined #jboss-as7
[15:23:56] *** pilhuhn has joined #jboss-as7
[15:23:56] *** ChanServ sets mode: +v pilhuhn
[15:24:13] *** Jaikiran is now known as Jaikiran|AFK
[15:24:30] <Nihility> hbraun: hi there, so the problem was we had a new base64 impl that was contributed, which we had flush on close, but we never released a version with it. Last night I went to do that, but I noticed some issues with the new impl and was fixing them,
[15:24:47] <bstansberry> emuckenhuber, darranl: shall we talk about model controllers?
[15:24:57] <hbraun> Nihility: did you see my pull request?
[15:25:14] <hbraun> Nihility: https://github.com/dmlloyd/jboss-dmr/pull/1
[15:25:15] <emuckenhuber> bstansberry: i'm here
[15:25:19] <Nihility> hbraun: yes, that was the alternative to just resurect the old impl
[15:25:25] <darranl> bstansberry, sure just grabbing a drink and will be with your - here or in #as7-domain?
[15:25:26] <Nihility> hbraun: and patch the flush issue
[15:25:50] <hbraun> Nihility: I updated to a more recent version and added the flush() call
[15:25:51] <bstansberry> darranl: here unless there's another long running conversation going when you get back
[15:25:58] <hbraun> Nihility: it works, but may not be ideal
[15:26:08] <hbraun> Nihility: what do you suggest?
[15:26:44] <hbraun> Nihility: why did the impl change in the first place? Are you saying it was like this before?
[15:29:36] <Nihility> hbraun: a contributor contributed a less wacky version of this, that version is stable, but it does all kinds of unnecessary and strange things, which likely led to encoding problems
[15:30:14] <hbraun> oh, so you are saying 2.3.7 is wacky?
[15:30:18] <hbraun> i see
[15:30:29] <Nihility> hbraun: i havent looked at the lastest version
[15:30:46] <hbraun> Nihility: well, how do we proceed?
[15:31:09] <hbraun> Nihility: basically just the flush() call was missing
[15:31:14] <Nihility> hbraun: but the contributors version is new code, and it did have some issues that i was fixing. so i was probably going to just patch dmr like you did
[15:31:23] <Nihility> and get the new version tested more
[15:31:27] <hbraun> Nihility: therefore the padding characters have not been written in some cases
[15:31:50] <Nihility> yeah there is a special flush call
[15:32:01] <Nihility> you have to end the base64 session
[15:32:09] <hbraun> Nihility: according to the docs (header of that class) some issues related to illegal characters have been fixed
[15:32:10] <darranl> bstansberry, emuckenhuber - am back
[15:32:19] <asoldano> dmlloyd, http://fpaste.org/K2nf/ : I set <module name="org.springframework.spring" optional="true"/> in some of my modules and don't have that org.springframework.spring module available
[15:32:52] <Nihility> it was a known issue but since the plan was to go with an impl that flushed on close we didnt bother fixing the old impl
[15:33:05] <dmlloyd> looks like a bug at first glance, asoldano
[15:33:10] <Nihility> but then we never released the new impl
[15:33:17] <Nihility> (oversight)
[15:33:38] *** jamezp has joined #jboss-as7
[15:33:44] <hbraun> Nihility: oh, the current one does flush on close
[15:34:09] <hbraun> Nihility: but the HttpD didn't close the Base64OutputStream, but the wrapped one
[15:34:26] <bstansberry> darranl, emuckenhuber: let's chat in #as7-domain as other stuff is going on in here
[15:34:31] <asoldano> dmlloyd, with that optional dep flag working, we could start by restoring the AS6 functionalities and then work on one of the 2 options above... ;-)
[15:34:47] <hbraun> Nihility: see https://github.com/dmlloyd/jboss-dmr/pull/1/files#diff-2
[15:35:14] <hbraun> Nihility: I am not closing it either, merely flushing at the end of writeBase64()
[15:35:15] <Nihility> hbraun: the old version closes the inner stream
[15:35:24] <Nihility> hbraun: the new version doesnt
[15:35:52] <hbraun> Nihility: no, that's still the responsibility of the  callee
[15:35:58] <Nihility> hbraun: old base64 version you call the special flushBase64 function or whatever it is called
[15:36:01] <hbraun> in out case the HttpD
[15:36:10] <hbraun> Nihility: but IMO that's correct
[15:36:20] <Nihility> hbraun: new version you call cloase() which doesnt close the inner stream
[15:36:28] <dmlloyd> but I'll leave that one to my betters
[15:37:05] <maeste> wolfc: have you a minute for JBAS-9063 I can't reproduce the situation
[15:37:07] <jbossbot> jira [JBAS-9063] Failing rar deployment is not cleaned up [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-9063
[15:37:25] <maeste> wolfc: I have the first error (with an incorrect rar) but not the second
[15:37:54] <asoldano> dmlloyd, my understanding at AS6 time was that we do not include spring because users might want different versions to be used... so we could not force a given version
[15:38:18] <Nihility> because spring is slipshod
[15:38:50] <Nihility> the integration code is fragile
[15:39:03] <Nihility> and we have to do lots of work for WFK
[15:39:07] <hbraun> Nihility: isn't that part of Base64.OutputStream#close()  ?
[15:39:10] <Nihility> ask marius :)
[15:39:56] <wolfc> maeste, hmm, it could be a side effect of something, or it could be non-reproducible in master
[15:40:56] <Nihility> hbraun: the version of Bas64 that is in DMR closes the nested stream on close, the contributors version does not not. So if you call close you close the http session which is bad.
[15:41:05] <Nihility> DMR 3 that is
[15:41:15] <Nihility> the contributers version is in upstream
[15:42:04] <maeste> wolfc: oki, let me know if you still get it
[15:42:26] <asoldano> Nihility, dmlloyd: to be honest, on AS7 we might even confine a given version of spring to cxf/jbossws-cxf use only (iow not visible in user classpath), then it's just a matter of using the spring version that comes with cxf version we integrate...
[15:42:41] <hbraun> Nihility: what do you suggest? Should I revert but retain the flush() call?
[15:42:47] <maeste> wolfc: Im going to work on other stuffs atm, if I can't reproduce it it's hard for me to understand/fix it
[15:42:51] <wolfc> maeste, ah I see the issue
[15:42:59] <maeste> wolfc: cool
[15:43:05] <maeste> wolfc: what is it?
[15:43:05] <wolfc> maeste, it's something in the demo itself
[15:43:18] <wolfc> maeste, deployment 'hangs' when the rar fails to deploy
[15:43:21] <Nihility> hbraun: everything you are doing is fine :)
[15:43:29] <wolfc> maeste, then the second run gives that error
[15:43:30] <hbraun> Nihility: got it
[15:43:33] <Nihility> hbraun: i was just explaining why we had the screw up
[15:43:49] <maeste> wolfc: oki, correctly from deployers point of view
[15:43:49] <hbraun> Nihility: ok, i'll take case of it
[15:43:49] <hbraun> +
[15:43:50] <Nihility> hbraun: and that ultimate we had a contribution i would like to move to, but only when its ready
[15:44:15] <hbraun> Nihility: IMO the current patch is fine
[15:44:21] <maeste> wolfc: I'll comment and reassign it to kabir
[15:44:23] <Nihility> hbraun: in the meantime i think i will just merge your patch on a branch off of beta3 and cut a release
[15:44:58] <wolfc> bstansberry, are you there?
[15:45:06] <hbraun> Nihility: yeah, all I need is working base64 impl. that will be shipped with beta2
[15:45:18] <bstansberry> wolfc: yes
[15:45:33] <wolfc> bstansberry, is ServerDeploymentManager.execute(DeploymentPlan) atomic?
[15:45:39] <hbraun> Nihility: most simple way: accept the ull, then comment the close() call on the inner stream
[15:46:05] <Nihility> hbraun: your patch does the right thing htough
[15:46:07] *** mbg has joined #jboss-as7
[15:46:07] *** ChanServ sets mode: +v mbg
[15:46:08] <bstansberry> wolfc: yes, it creates a composite operations with an instruction to roll it all back if any part fails
[15:46:18] <Nihility> hbraun: it calls flushBase64 not cloe
[15:46:23] <wolfc> maeste, it's his ^ fault then :-)
[15:46:26] <Nihility> hbraun: which is exactly right
[15:46:29] *** mbg has quit IRC
[15:46:29] *** mbg has joined #jboss-as7
[15:46:29] *** verne.freenode.net sets mode: +v mbg
[15:46:35] <hbraun> Nihility: yes, it#s the HttpD that close the correct stream
[15:46:39] <Nihility> hbraun: the contributors version you could call close
[15:46:54] <wolfc> bstansberry, JBAS-9063
[15:46:55] <jbossbot> jira [JBAS-9063] Failing rar deployment is not cleaned up [Open (Unresolved) Bug, Major, Kabir Khan] https://issues.jboss.org/browse/JBAS-9063
[15:47:00] <maeste> wolfc: oki, reassigned
[15:47:00] <Nihility> hbraun: which is the version in upstream
[15:48:30] <bstansberry> wolfc: i just reassigned to me as kabir is on PTO
[15:48:39] <wolfc> bstansberry, thanks
[15:49:10] <asoldano> dmlloyd, anyway, regarding the potential bug in modules dependency, should I provide you or someone else a testcase for that?
[15:49:28] <dmlloyd> nah just open a jira in the MODULES project saying optional deps don't work
[15:52:50] <Nihility> hbraun: oh btw could do a non-snapshot release of the console (like a milestone) we have a no snapshot policy for as since it leads to irreproducible failures / builds. The console isnt that big of a deal since its just client side JS but it could still be an issue if the snapshot expires for example
[15:52:52] <asoldano> dmlloyd, MODULES-80 created
[15:52:53] <jbossbot> jira [MODULES-80] Optional dependencies not working [Open (Unresolved) Bug, Critical, David Lloyd] https://issues.jboss.org/browse/MODULES-80
[15:53:10] <hbraun> Nihility: sure
[15:53:50] <hbraun> Nihility: if we resolve the base64 issue I can do an updated release, which I would prefer
[15:53:59] <hbraun> Nihility: don't mean to blackmail you
[15:54:09] <hbraun> Nihility: lol
[15:54:12] <Nihility> hbraun: hahaha im doing that right now
[15:54:28] *** AndyTaylor has quit IRC
[15:54:53] <hbraun> Nihility: ok, I'll do the update release this afternoon. It works solely on the dmr-encoded protocol
[15:55:06] <hbraun> Nihility: which is a great time saver. Good work
[15:55:18] *** AndyTaylor has joined #jboss-as7
[15:55:18] *** ChanServ sets mode: +v AndyTaylor
[15:55:39] <hbraun> Nihility: while you are at it, please create the JIRA component as well
[15:55:50] <hbraun> Nihility: so we can start filing issues like this
[15:56:02] <dmlloyd> didn't somebody already do JBAS-9061?
[15:56:03] <jbossbot> jira [JBAS-9061] DataSouce schema uses incorrect name for JDBC driver [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/JBAS-9061
[15:56:58] *** bobmcw has joined #jboss-as7
[15:56:58] *** ChanServ sets mode: +v bobmcw
[15:57:15] *** jwulf has quit IRC
[15:57:50] <Nihility> hbraun: thanks sorry this bug hit at bad timing
[15:58:04] <hbraun> np
[15:58:18] <dmlloyd> that fucking base64 thing
[15:58:23] <dmlloyd> ...
[15:59:48] <Nihility> hbraun: i should have included the problem in my email to save you all the debugging
[16:00:25] <hbraun> well, I needed to look at the nuts and bolts sometime anyway
[16:01:20] <asoldano> dmlloyd, thanks for the fix, trying with a jboss-module snapshot
[16:01:31] *** balunasj_busy is now known as balunasj_mtg
[16:04:58] *** nickarls has quit IRC
[16:05:17] <Nihility> hbraun: yeah ill do that to, im actually trying to get a new jira project
[16:06:37] *** torben has joined #jboss-as7
[16:06:38] *** torben has joined #jboss-as7
[16:06:38] *** ChanServ sets mode: +v torben
[16:11:49] *** mbg has quit IRC
[16:12:06] <jbossbot> git [jboss-dmr] push 1.0.0.Beta4 2d13d61.. Jason T. Greene Fix flushing, Prepare for 1.0.0.Beta4
[16:12:06] <jbossbot> git [jboss-dmr] push 1.0.0.Beta4 URL: http://github.com/jbossas/jboss-dmr/compare/0000000...2d13d61
[16:22:45] <Jaikiran|AFK> dmlloyd: got a minute?
[16:22:49] *** Jaikiran|AFK is now known as Jaikiran
[16:23:00] <dmlloyd> sure
[16:23:32] <Jaikiran> spent some time on debugging this today https://issues.jboss.org/browse/JBAS-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589605#comment-12589605
[16:23:33] <jbossbot> jira [JBAS-9077] Deployment failure leads to a server hang [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9077
[16:24:11] <Jaikiran> i'm not too sure why that count if block is present. that currently prevents the callback from being invoked on failed deployment
[16:24:15] <Jaikiran> resulting in that hang
[16:25:09] <dmlloyd> I wouldn't waste too much time chasing this down.  I think there are multiple problems with how that code has been refactored over time
[16:25:33] <dmlloyd> the new code for 9010 works somewhat differently
[16:25:54] <Jaikiran> i see. so i'll wait for 9010 to be completed then
[16:26:18] *** asaldhan has joined #jboss-as7
[16:26:18] *** ChanServ sets mode: +v asaldhan
[16:27:19] *** opalka has quit IRC
[16:34:46] <asoldano> dmlloyd, the fix for MODULES-80 is working as I expected, thanks. I assume we're not moving to snapshot deps in AS7 main pom.xml, right? In that case it might help having a new modules version available upstream some days before next release
[16:34:47] <jbossbot> jira [MODULES-80] Optional dependencies not working [Resolved (Done) Bug, Critical, David Lloyd] https://issues.jboss.org/browse/MODULES-80
[16:35:03] <dmlloyd> yeah I will
[16:35:18] <dmlloyd> thomas wants his class filtering anyway
[16:35:57] <asoldano> dmlloyd, good, thanks
[16:39:32] *** asoldano is now known as asoldano_away
[16:39:41] *** jamezp has quit IRC
[16:40:34] *** jamezp has joined #jboss-as7
[16:41:00] *** mmoyses is now known as mmoyses_
[16:41:24] <jbossbot> git [jboss-as] push master 1f2f493.. Jason T. Greene Update to DMR Beta4
[16:41:24] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/f5557ab...1f2f493
[16:41:37] <Nihility> hbraun: ^
[16:42:14] <hbraun> Nihility: great, that means the patch is available upstream?
[16:42:20] *** AndyTaylor has quit IRC
[16:42:31] <hbraun> Nihility: then I'll do another non-snapshot console relese
[16:44:07] <Nihility> hbraun: yes
[16:44:15] <hbraun> Nihility: thanks
[16:55:33] *** JimMa has joined #jboss-as7
[16:57:14] <wolfc> opalka, problem. You're not allowed to do class.getMethod in AS 7. org.jboss.wsf.common.invocation.AbstractInvocationHandler.getImplMethod
[17:05:40] *** frainone has quit IRC
[17:05:58] *** bobmcw has quit IRC
[17:12:58] <wolfc> the problem is even larger. Those methods are cached in ProxyFactory.
[17:14:19] *** pmuir has joined #jboss-as7
[17:14:20] *** ChanServ sets mode: +v pmuir
[17:17:29] *** balunasj_mtg is now known as balunasj_away
[17:20:36] *** ALR has joined #jboss-as7
[17:20:36] *** ChanServ sets mode: +v ALR
[17:28:51] *** tdiesler has quit IRC
[17:31:00] *** ALR has quit IRC
[17:31:49] *** Jaikiran has quit IRC
[17:33:48] *** maeste has quit IRC
[17:46:58] <dmlloyd> baileyje, and stuartdouglas when you come on - what do you think of the idea of copying down any Dependency: from EARs into their subdeployments automatically
[17:47:58] <baileyje> dmlloyd: I may help things.
[17:48:19] <dmlloyd> I think it's the expected behavior
[17:51:15] *** pilhuhn is now known as pil-dinner
[17:55:07] <baileyje> dmlloyd: What is setting the dependencies on the ear in the first place?
[17:55:28] *** frainone has joined #jboss-as7
[17:55:28] *** ChanServ sets mode: +v frainone
[17:56:07] <dmlloyd> baileyje: user - manifest "dependency" property
[17:56:14] <dmlloyd> that's what I'm referring to
[17:56:18] <dmlloyd> not all deps, just manifest ones
[17:56:21] <baileyje> dmlloyd: Yeah.  That makes sense for sure
[17:56:36] <baileyje> I missed the manifest formatting the first time
[17:57:09] <dmlloyd> right now they can set "export" on there but it's not exactly the same thing
[17:57:23] <dmlloyd> might be surprising when there's a class-path ref to the top-level dep and suddenly a bunch of other stuff comes over
[17:58:12] <baileyje> right.  I agree fully now that that would be expected behavior.
[17:58:32] <baileyje> back in a bit.  Need to grab lunch
[18:00:05] * dmlloyd too
[18:00:16] *** alesj has quit IRC
[18:01:30] *** jcosta has quit IRC
[18:02:00] <dmlloyd> everyone please take a minute to vote up http://jira.atlassian.com/browse/JRA-24135
[18:02:13] <dmlloyd> it's important to our AS bug tracking process
[18:05:31] *** smarlow has left #jboss-as7
[18:05:43] *** smarlow has joined #jboss-as7
[18:05:44] *** ChanServ sets mode: +v smarlow
[18:06:34] * smarlow voted so I can ask for more merges today :-)
[18:06:53] *** asoldano_away is now known as asoldano
[18:10:51] *** mmoyses_ is now known as mmoyses
[18:16:02] <smcgowan> bstansberry:  what is the intent of the data/system-content directory in standalone config?  i see there are currently two .rars there?
[18:16:24] <smcgowan> is that where additional resource adapters should be placed?
[18:24:16] <bstansberry> smcgowan: no, end user rars are normal deployments
[18:24:35] <bstansberry> that was the location for internal stuff that subsystems had to deploy themselves
[18:25:05] <smcgowan> bstansberry:  ok, so not for deployments intended for the system shared by user deployments?
[18:25:39] <smcgowan> i'm still thinking that the jdbc drivers would be configured for the entire server for example
[18:26:01] <bstansberry> the distinction is really who deploys it, not who uses it
[18:26:49] <bstansberry> system-content is an internal area for stuff that for whatever reason we had to put through a deployment chain to get installed
[18:26:50] <smcgowan> now that i have my database configured, i see some user apps failing to find the DB classes
[18:27:02] <Nihility> hbraun: hey you now are the new owner of the web console category
[18:27:23] *** mbg has joined #jboss-as7
[18:27:24] *** ChanServ sets mode: +v mbg
[18:27:27] <bstansberry> smcgowan: but the datasource is available?
[18:27:28] <smcgowan> so have been thinking about other modules having a dependency on the DB, for example
[18:28:49] *** torben has quit IRC
[18:29:10] <smcgowan> well, i'm running into a lot of NameNotFoundExceptions when looking up from application, related to: JBAS-9103, I believe
[18:29:12] <jbossbot> jira [JBAS-9103] Move Component related processors back to PARSE phase [Open (Unresolved) Sub-task, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9103
[18:29:28] *** torben has joined #jboss-as7
[18:29:28] *** ChanServ sets mode: +v torben
[18:30:13] <smcgowan> but in other cases, i see this: http://pastebin.com/pHrUt3ML
[18:31:30] <hbraun> Nihility: just saw it. I am feeling so much better now
[18:31:33] <hbraun> thanks ;)
[18:32:04] <bstansberry> smcgowan: so that's a javax.servlet.Filter adding a datasource?
[18:32:46] <Nihility> hbraun: did it email you?
[18:32:48] *** jhalliday has quit IRC
[18:32:59] <Nihility> our jira project is an absolute mess
[18:33:02] <Nihility> we need a new one
[18:33:05] <hbraun> Nihility: nope
[18:33:38] <smcgowan> bstansberry:  that's a JSTL test using sql:setDataSource
[18:34:24] <smcgowan> i'm filing the JIRA in JBCTS but just got me thinking about the availability of the DB jars
[18:34:34] * bstansberry knows nothing about sql:setDataSource :)
[18:34:35] <bstansberry> but
[18:34:46] <bstansberry> it seems odd that it feels the need to load the class
[18:34:49] <smcgowan> AS 6 we added them to server/lib - yes, i know AS 7 is different
[18:36:39] <bstansberry> if the test assumes the driver class is available to the filter, there either needs to be spec that says that or we've missed implementing something
[18:37:49] <bstansberry> or... that's an invalid assumption in the tck
[18:38:20] <smcgowan> bstansberry:  https://svn.devel.redhat.com/repos/jboss-tck/tck6/trunk/src/com/sun/ts/tests/jstl/common/wrappers/TckDataSourceWrapper.java
[18:40:43] *** rawbdor has joined #jboss-as7
[18:42:27] <smcgowan> bstansberry:  i'll check the spec
[18:42:29] *** emuckenhuber has quit IRC
[18:42:56] <bstansberry> smcgowan: looking at that, it's creating its own datasource
[18:43:18] <bstansberry> so where is the driver jar?
[18:43:23] <smcgowan> bstansberry:   JSTL Spec, Chapter 10
[18:43:37] <smcgowan> driver jar is in a module I added:  org.apache.derby
[18:44:19] <smcgowan> https://svn.devel.redhat.com/repos/jboss-tck/tck6/trunk/jee6tck-as7-mods/derby/derby-config.xml
[18:45:48] <smcgowan> modules/org/apache/derby/main module.xml: https://svn.devel.redhat.com/repos/jboss-tck/tck6/trunk/jee6tck-as7-mods/derby/module.xml
[18:46:18] *** pmuir has quit IRC
[18:46:19] <smcgowan> i can follow up on this specific test with rmaucher but just working out the details of the Database configuration
[18:47:02] <smcgowan> e.g., https://issues.jboss.org/browse/JBCTS-1089
[18:47:23] *** pmuir has joined #jboss-as7
[18:47:24] *** pmuir has joined #jboss-as7
[18:47:24] *** ChanServ sets mode: +v pmuir
[18:48:05] <bstansberry> smcgowan: what causes that module to be loaded into the runtime?
[18:48:14] <rmaucher> I guess you'd need a DB available for this test
[18:49:13] <smcgowan> bstansberry: not sure how to answer that, can you tell me more
[18:49:49] <bstansberry> the existence of a module in the module library doesn't trigger loading into the runtime
[18:49:53] <smcgowan> rmaucher:  working on getting the derby config in TCK set up
[18:50:19] <smcgowan> bstansberry:  that may be a problem, then
[18:52:36] *** alesj has joined #jboss-as7
[18:52:39] <smcgowan> i guess I'll wait for https://issues.jboss.org/browse/JBAS-9062
[18:52:40] <jbossbot> jira [JBAS-9062] Add some documentation of DS configuration to the AS 7 User Guide [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9062
[18:53:05] <bstansberry> see the datasource subsystem, <drivers> element
[18:53:39] <bstansberry> that loads the module for the h2 driver and creates a service from which the driver can be obtained
[18:53:54] <smcgowan> <drivers>
[18:53:55] <smcgowan>                 <driver module="com.h2database.h2"/>
[18:53:55] <smcgowan>                 <driver module="org.apache.derby"/>
[18:53:55] <smcgowan>             </drivers>
[18:54:01] <bstansberry> yep
[18:54:18] <bstansberry> but, that isn't likely to help here
[18:54:31] <bstansberry> this spec stuff about DriverManager is unclear
[18:56:43] <bstansberry> I don't see anything in it that implies a driver class is supposed to magically be available from the TCCL
[18:56:55] *** torben has quit IRC
[18:56:58] <bstansberry> i.e. in JSTL Spec Chapter 10
[18:57:00] <dmlloyd> yeah I think the test is in error here
[18:57:34] <bstansberry> I think making the driver class available should be done via EE spec defined ways
[18:57:49] <bstansberry> not an assumption that it's just there by magic
[18:57:51] <dmlloyd> if the driver is deployed and they actually want to create it themselves they need a class-path dep on the deployed driver JAR
[18:57:57] <bstansberry> yep
[18:58:13] <dmlloyd> kinda funny that the test bypasses EE
[18:58:20] <dmlloyd> I wonder if this is some JSTL "feature"
[18:58:39] *** asoldano is now known as asoldano_dinner
[18:59:18] <rmaucher> it's the SQL tags of JSTL, that's old
[18:59:32] <bstansberry> "The data source may be specified either via the dataSource attribute (as a DataSource object, JNDI relative path, or JDBC parameters string), or via the four JDBC parameters attributes. These four attributes are provided as a simpler alternative to the JDBC parameters string syntax defined in Section 10.1.1 that would have to be used with the dataSource attribute.
[18:59:32] <bstansberry> As mentioned in Section 10.1.1, using JDBC’s DriverManager class to access a database is intended for prototyping purposes only because it does not provide connection management features one can expect from a properly designed DataSource object."
[19:00:29] <bstansberry> but there's no discussion of where the driver class comes from, which to me implies no extra requirements beyond normal EE rules
[19:00:37] <dmlloyd> yeah I agree
[19:01:48] *** JimMa has quit IRC
[19:03:49] *** darranl has quit IRC
[19:04:04] <smcgowan> i'll check the tck guide if there is any additional set up for these tests
[19:04:33] *** emuckenhuber has joined #jboss-as7
[19:04:33] *** ChanServ sets mode: +v emuckenhuber
[19:04:54] *** smarlow has quit IRC
[19:05:18] <smcgowan> and once i get this running and proved by tests, i'll update JBAS-9062 - i had hoped to have it by now but my tests are proving my config is right yet
[19:05:24] <jbossbot> jira [JBAS-9062] Add some documentation of DS configuration to the AS 7 User Guide [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9062
[19:05:40] <smcgowan> my config is *not* right yet
[19:06:06] *** balunasj_away has quit IRC
[19:07:26] *** bobmcw has joined #jboss-as7
[19:07:26] *** ChanServ sets mode: +v bobmcw
[19:07:34] *** hbraun has quit IRC
[19:10:55] *** AndyTaylor has joined #jboss-as7
[19:10:56] *** ChanServ sets mode: +v AndyTaylor
[19:12:33] *** bobmcw has quit IRC
[19:19:56] *** bstansberry is now known as bstans_food
[19:21:07] *** smarlow has joined #jboss-as7
[19:21:08] *** ChanServ sets mode: +v smarlow
[19:23:22] *** AndyTaylor has quit IRC
[19:26:19] *** ALR has joined #jboss-as7
[19:26:19] *** ChanServ sets mode: +v ALR
[19:40:16] <ALR> Anyone know where to find David Bosschaert?
[19:40:21] <ALR> Or is this off-time for him?
[19:40:32] <alesj> ALR: i would say off
[19:40:37] <alesj> let me check
[19:40:39] <ALR> alesj: Where's he at?
[19:40:50] <ALR> (Located physically)
[19:41:05] <alesj> he's from Dublin
[19:41:09] <ALR> Ah OK
[19:41:11] <alesj> but at EclipseCon atm
[19:41:27] <alesj> he's online
[19:41:31] <alesj> ALR: ^
[19:41:35] <ALR> So I'll catch him tomorrow.  Ahh...Santa Clara then.  So he'll be spotty for a bit.
[19:41:39] <ALR> alesj: Oh nice, where?
[19:41:46] <alesj> my skype :-)
[19:41:52] <alesj> i told him you're looking for mih
[19:41:53] <alesj> him
[19:42:18] <ALR> alesj: Ah cool, thanks.  We've been having some back/forth on an issue and I just wanna be sure we're in some agreement.
[19:42:49] <alesj> ALR: he's busy, two talks today
[19:43:36] <ALR> alesj: Cool, no prob.
[19:43:48] <ALR> Wish him luck.
[19:44:54] *** mbg has quit IRC
[19:46:32] *** smcgowan has quit IRC
[19:46:34] *** pmuir has quit IRC
[19:59:02] *** sannegrinovero has quit IRC
[20:00:56] <baileyje> dmlloyd: https://github.com/baileyje/jboss-as/commit/dc84c98303b02a9fb4091f897ee863f9bda31839
[20:00:58] <jbossbot> git [jboss-as] dc84c98.. John E. Bailey [JBAS-9067] Make sure class level interceptors have working lifecycles
[20:01:00] <jbossbot> jira [JBAS-9067] Lifecycle methods on interceptor objects not functioning [Open (Unresolved) Bug, Critical, John Bailey] https://issues.jboss.org/browse/JBAS-9067
[20:01:10] <baileyje> dmlloyd: Can you review and see if that makes sense?
[20:03:24] <rawbdor> ALR,  i'm in san fran :D
[20:03:42] <rawbdor> i'll be seeing max tomorrow and meeting with makara on friday
[20:04:02] <ALR> rawbdor: ATL here
[20:04:09] <ALR> Back to Boston tonight.
[20:04:13] <rawbdor> we're quite a migrant bunch
[20:04:14] <rawbdor> heh
[20:04:19] <ALR> Sitting w/ Project:Odd ATM
[20:04:27] *** bstans_food is now known as bstansberry
[20:04:29] <rawbdor> ... what's Project:Odd?
[20:05:15] <ALR> Bob McWhirter and team
[20:05:20] <rawbdor> hmm
[20:06:06] *** nickarls has joined #jboss-as7
[20:08:37] *** alesj has left #jboss-as7
[20:08:42] <dmlloyd> baileyje: why is post-construct a list, while pre-destroy is a map?
[20:09:57] <baileyje> dmlloyd: mainly because the map is needed for the pre-destroy, but not for the post construct :)
[20:10:15] *** mbg has joined #jboss-as7
[20:10:15] *** ChanServ sets mode: +v mbg
[20:10:17] <baileyje> let me review quick.  I flopped back and forth a few times
[20:11:40] <baileyje> where do you see post contruct as a list?
[20:12:05] *** mbg has quit IRC
[20:12:05] *** mbg has joined #jboss-as7
[20:12:05] *** gibson.freenode.net sets mode: +v mbg
[20:12:38] <dmlloyd> looking at AbstractComponentConfiguration
[20:12:55] <dmlloyd> addPostConstructLifecycles() and in fact addPreDestroyLifecycles()
[20:13:07] <dmlloyd> +    private final Map<Class<?>, List<LifecycleInterceptorFactory>> interceptorPreDestroys = new HashMap<Class<?>, List<LifecycleInterceptorFactory>>();
[20:13:11] <dmlloyd> looks unused actually
[20:14:08] <baileyje> dmlloyd: The interceptorPreDestroys is for the pre-destroy method for the interceptors, where as the other two are for the component itself.
[20:14:28] <dmlloyd> ah, I see
[20:14:35] <baileyje> see -> performInterceptorPreDestroyLifecycle
[20:14:47] <dmlloyd> ok what about public void addPostConstructInterceptorLifecycles(Collection<LifecycleInterceptorFactory> lifecycles) {
[20:14:54] <dmlloyd> that one is definitely a list
[20:15:17] <baileyje> That is for the component.
[20:15:34] <dmlloyd> ah then maybe "interceptor" should not be in the name
[20:15:41] <baileyje> The component case is easy.  Since you know the component instance is always the target
[20:15:41] <dmlloyd> it's a bit misleading
[20:16:18] <baileyje> Yeah.  I think there is some confusion in the spec.  Since they refer to the lifecycle methods as interceptors as well
[20:16:27] <baileyje> I am all for making it clearer in our code thoguh
[20:23:52] *** ALR has quit IRC
[20:25:13] *** mbg has quit IRC
[20:32:02] *** smarlow has quit IRC
[20:32:30] <baileyje> dmlloyd: Beyond the name issues, do you see anything else you don't think is correct?
[20:32:52] <baileyje> or do you have any ideas for getting the lifecycles on the interceptors working?
[20:33:19] <dmlloyd> what's the idea with keeping the interceptor factory context attached to the components
[20:33:48] <baileyje> You mean the ComponentInstance?
[20:34:03] <dmlloyd> yeah
[20:34:16] *** Sacha has quit IRC
[20:34:22] <dmlloyd> is that so you can possibly construct interceptors which only have a @PreDestroy at a later time or something?
[20:34:28] *** smarlow has joined #jboss-as7
[20:34:29] *** ChanServ sets mode: +v smarlow
[20:34:32] <baileyje> mainly to get at it when the component instance is destroyed.
[20:34:56] <baileyje> Since the only place that has the actual instanace of interceptors is the factory context
[20:35:45] <baileyje> also you may notice it was already in the construct for AbstractComponentInstance
[20:35:50] <baileyje> all I did was use it :)\
[20:42:07] *** opalka has joined #jboss-as7
[20:42:07] *** opalka has joined #jboss-as7
[20:42:07] *** ChanServ sets mode: +v opalka
[20:43:02] *** mbg has joined #jboss-as7
[20:43:02] *** ChanServ sets mode: +v mbg
[20:44:06] *** mbg has quit IRC
[20:44:06] *** mbg has joined #jboss-as7
[20:44:06] *** jordan.freenode.net sets mode: +v mbg
[20:48:42] <dmlloyd> baileyje: okay I think this is probably fine.  it's all pretty complex and ugly but this patch is not the reason.  maybe once we're all face to face we can come up with a cleaner solution
[20:48:49] <dmlloyd> for component construction I mean.
[20:48:55] <Nihility> stuartdouglas: i think your reply is wrong
[20:49:30] <stuartdouglas> In what way?
[20:49:41] <baileyje> dmlloyd: Yeah,  I agree.  There a lot of parts that are scattered about.  Generally close where they are fist needed, but it is difficult to know how all the pieces are interacting.
[20:49:44] <Nihility> stuartdouglas: IIRC we decided that ejbs should be partially isolated right?
[20:50:00] <stuartdouglas> not from other ejb modules
[20:50:12] <stuartdouglas> just from ear/lib
[20:51:46] *** smcgowan has joined #jboss-as7
[20:51:46] *** ChanServ sets mode: +v smcgowan
[20:52:03] <Nihility> or rather that all ejbs are a separate modules
[20:52:54] <stuartdouglas> they are separate modules
[20:53:11] <Nihility> so how can one ejb see the other's classes then
[20:55:11] <stuartdouglas> because the SubDeploymentProcessor sets up dependencies between them
[20:55:18] <dmlloyd> yeah EE.8.3.2 says that EJB jars need not see each other
[20:55:58] <stuartdouglas> war files do not need to be able to see EJB jars either
[20:56:17] <stuartdouglas> but it is the behaviour that most people have come to expect
[20:57:19] *** dimitris_ has joined #jboss-as7
[20:57:19] *** dimitris_jboss has quit IRC
[20:57:19] *** dimitris_ has quit IRC
[20:57:20] *** dimitris_ has joined #jboss-as7
[20:57:20] *** ChanServ sets mode: +v dimitris_
[20:58:28] <Nihility> ah ok so thats it he has no dependency there
[20:58:33] <Nihility> hes using JPA classes
[20:58:39] <Nihility> as an EJB jar
[20:58:43] <Nihility> so thats the issue
[21:00:40] <dmlloyd> yeah that seems fishy
[21:00:46] <dmlloyd> EJB JAR with no EJBs in it :)
[21:01:36] <stuartdouglas> so do we not want ears/wars to see each other by default?
[21:01:48] <stuartdouglas> soory ejb jars/wars ?
[21:02:15] <dmlloyd> I'd say, no
[21:02:21] <dmlloyd> but that's my opinion
[21:02:30] * dmlloyd usually in the minority on this kind of thing :)
[21:02:34] <dmlloyd> less visibility is better
[21:02:46] <baileyje> What does the spec say?
[21:02:53] <dmlloyd> spec says we can do it either way
[21:02:59] <stuartdouglas> The spec lets us do what we want
[21:03:09] <dmlloyd> "Portable applications must not depend on having or not having access to these classes or resources."
[21:03:11] <stuartdouglas> but I think a lot of people have come to expect it
[21:03:14] <baileyje> Then lets do less visibility until someone yells.
[21:03:14] <baileyje> T
[21:03:15] <baileyje> he
[21:03:15] <baileyje> y
[21:03:32] <baileyje> THey can always add manifest entries, correct?
[21:03:36] <stuartdouglas> yes
[21:03:37] <dmlloyd> yes
[21:03:53] <baileyje> I think users are used to that.
[21:04:11] <baileyje> They have been doing it for years in most cases.
[21:04:16] <stuartdouglas> ok, I will change it
[21:05:53] <stuartdouglas> I'm heading to the gym, I will be back in a bit over an hour
[21:07:04] <baileyje> dmlloyd: Here is that commit with the names cleaned up a bit:  https://github.com/baileyje/jboss-as/commit/60022568400c201667632a146b9022280a23454a
[21:07:05] <jbossbot> git [jboss-as] 6002256.. John E. Bailey [JBAS-9067] Make sure class level interceptors have working lifecycles
[21:07:06] <jbossbot> jira [JBAS-9067] Lifecycle methods on interceptor objects not functioning [Open (Unresolved) Bug, Critical, John Bailey] https://issues.jboss.org/browse/JBAS-9067
[21:07:47] <baileyje> bstansberry: Are you looking for someone to work on JBAS-9082
[21:07:48] <jbossbot> jira [JBAS-9082] Incorrect handling of runtime failures in composite operations if rollback is not enabled [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9082
[21:08:36] <baileyje> wolfc:  ping
[21:11:42] <jbossbot> git [jboss-as] push master 6002256.. John E. Bailey [JBAS-9067] Make sure class level interceptors have working lifecycles
[21:11:43] <jbossbot> jira [JBAS-9067] Lifecycle methods on interceptor objects not functioning [Open (Unresolved) Bug, Critical, John Bailey] https://issues.jboss.org/browse/JBAS-9067
[21:11:43] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/1f2f493...6002256
[21:12:12] <baileyje> dmlloyd: THanks.
[21:12:54] <dmlloyd> after that issue is closed we'll have 44 left for beta2
[21:19:17] <bstansberry> baileyje: sure, that would be nice
[21:19:17] *** adietisheim has quit IRC
[21:19:33] <baileyje> bstansberry: Ok. I may ping you in a little bit to get more info.
[21:19:38] <baileyje> I will dig into a bit first.
[21:23:56] *** asoldano_dinner is now known as asoldano
[21:24:42] <baileyje> dmlloyd:  https://github.com/baileyje/jboss-as/commit/fa1d30ee15554ea8440d89aea3186c74112893ca
[21:24:42] <jbossbot> git [jboss-as] fa1d30e.. John E. Bailey [JBAS-9085] - Provide better exception message for driver connection issues
[21:24:43] <jbossbot> jira [JBAS-9085] Add URL and Driver class name to "javax.resource.ResourceException: Wrong driver class for this connection URL" message in LocalManagedConnectionFactory [Open (Unresolved) Feature Request, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9085
[21:25:37] <jbossbot> git [jboss-as] push master fa1d30e.. John E. Bailey [JBAS-9085] - Provide better exception message for driver connection issues
[21:25:39] <jbossbot> jira [JBAS-9085] Add URL and Driver class name to "javax.resource.ResourceException: Wrong driver class for this connection URL" message in LocalManagedConnectionFactory [Open (Unresolved) Feature Request, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9085
[21:25:39] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/6002256...fa1d30e
[21:28:12] *** jpederse has quit IRC
[21:31:53] <jamezp> Anyone know where I might find the source to org.jboss.jca.common.*?
[21:33:47] <dmlloyd> presumably there'd be source JARs in maven
[21:34:05] <dmlloyd> IDEA will auto-fetch them, not sure if ecollapse will
[21:34:27] <jamezp> I don't even know which JAR :-) Looks like maybe IronJacamar.
[21:34:34] <dmlloyd> yeah I think that's where that is
[21:34:43] <jamezp> Cool, thanks.
[21:36:03] <baileyje> bstansberry: So for JBAS-9082 it looks like it is currently checking...        if (!rollbackOnRuntimeFailure || !modelComplete.get()) {
[21:36:10] <jbossbot> jira [JBAS-9082] Incorrect handling of runtime failures in composite operations if rollback is not enabled [Open (Unresolved) Bug, Major, John Bailey] https://issues.jboss.org/browse/JBAS-9082
[21:36:13] <bstansberry> yep
[21:36:40] <bstansberry> the !modelComplete.get() part is correct
[21:36:59] *** opalka has quit IRC
[21:37:06] <baileyje> Ok.  Just making sure.  The rollbackOnRuntimeFailure is the bad part.
[21:37:11] <bstansberry> right
[21:37:43] <baileyje> How do we account for the rollbackOnRuntimeFailure?
[21:37:58] <bstansberry> ?
[21:37:58] <baileyje> In the rollback phase below?
[21:38:03] <bstansberry> right
[21:39:51] <baileyje> If rollbackOnRuntimeFailure is false, we just skip the execution of rollback, correct?
[21:40:03] <bstansberry> right, we just have to report the results
[21:40:17] *** frainone has quit IRC
[21:40:28] <baileyje> bstansberry: Ok. Makes sense.
[21:44:14] *** dimitris_ has quit IRC
[21:47:55] *** pil-dinner has quit IRC
[21:47:57] <smcgowan> bstansberry:  another example of a dependency on derby.  during deployment of persistence unit, hibernate checks the DB metadata for version information
[21:47:59] <smcgowan> http://pastebin.com/NjZ7s9PK
[21:48:20] <smcgowan> if i add derby module as a dependency it is resolved - obviously
[21:48:28] <smcgowan> dependency on org.hibernate
[21:49:14] <smcgowan> its just a WARN, the correct dialect is selected
[21:50:39] <baileyje> bstansberry: You have any good ways to test this?
[21:51:23] <bstansberry> baileyje: ServerCompositeOperationHandlerUnitTestCase
[21:51:34] <baileyje> bstansberry: Thanks
[21:51:49] <bstansberry> there's a bunch of infrastructure around creating handlers that do various stuff
[21:52:59] <bstansberry> smcgowan: not sure what to say about that one. seems like hibernate could have a better way
[21:53:50] <smcgowan> bstansberry:  smarlow has some ideas i think
[21:54:00] <bstansberry> cool
[21:54:24] *** mbg has quit IRC
[21:54:25] <bstansberry> the driver is available as a service, but of course core hibernate isn't going to look up a service :-)
[21:55:13] <smarlow> smcgowan, bstansberry:  is the the Derby class not found error?
[21:55:34] <bstansberry> smarlow: http://pastebin.com/NjZ7s9PK
[21:55:38] <smcgowan> i was just mentioning it in the case of Hibernate
[21:56:09] <smarlow> smcgowan:  does this also recreate with the DS demo?
[21:56:21] <smarlow> I know the problem from yesterday did
[21:56:47] *** mmoyses has quit IRC
[21:56:56] <smcgowan> the tests scenarios I've tried all access the DB differently too
[21:57:43] <smcgowan> smarlow:  the CNFE?
[21:58:25] <smarlow> smcgowan:  yes
[21:58:48] <smcgowan> i can try it
[21:59:18] <smarlow> smcgowan:  It might be a simpler test case to create a jira with
[21:59:28] *** irooskov has joined #jboss-as7
[21:59:59] <smarlow> smcgowan:  is there a jira already for the tck failure?
[22:00:17] <smcgowan> yes
[22:00:25] *** Sacha has joined #jboss-as7
[22:00:29] <smarlow> what is the number?
[22:00:50] <smcgowan> https://issues.jboss.org/browse/JBCTS-1092
[22:02:00] <smarlow> If the DS demo recreates the issue, it is probably easiest to create a jira against that.  Otherwise, get JBCTS-1092 assigned
[22:02:28] <dmlloyd> ah interesting.
[22:02:45] <dmlloyd> so the hibernate dialects require access to the driver classes associated with the dialect?
[22:06:44] <baileyje> bstansberry: Does this make sense?  http://pastebin.com/4srTKNu9
[22:07:27] <smarlow> dmlloyd:  I think in this case (might need more of the exception call stack), Hibernate is using databasemetadata from the jdbc connection
[22:07:56] <smarlow> smcgowan:  was there an exception call stack (I don't see it in http://pastebin.com/NjZ7s9PK), maybe I'm going blind :)
[22:08:00] <smcgowan> smarlow:  the DS demo won't create the issue as there is no persisetenc unit deployed
[22:09:04] <smarlow> smcgowan:  DS demo shouldn't use a PU
[22:09:24] <smcgowan> smarlow:  i think your confusing two different issues
[22:09:43] <wolfc> baileyje: pong
[22:10:07] <bstansberry> baileyje: sorry, was away
[22:10:15] <baileyje> wolfc: Is there more that needs to be done with ejb-jar.xml parsing?  There is an opern JIRA.
[22:10:24] <baileyje> wolfc: sorry if I already asked you this
[22:10:44] <wolfc> Jaikiran should be working on it.
[22:11:03] <smcgowan> smarlow:  or I am
[22:11:33] <baileyje> ok. Just asking as it was unasigned, and it looked like at least some of it was in pace.
[22:11:35] <baileyje> place
[22:11:39] <bstansberry> baileyje: the question is whether we treat this as "outcome"=>"success" or "outcome"=>"failed"
[22:11:49] <baileyje> for the whole op?
[22:11:55] <bstansberry> dmlloyd was asking about this yesterday; not sure why
[22:11:56] <baileyje> That is where I wasn't sure either..
[22:12:08] <bstansberry> the operation updated the model
[22:12:14] <wolfc> baileyje, that's the jira #?
[22:12:15] <bstansberry> and some steps changed the runtime
[22:12:26] <dmlloyd> I do'nt remember why
[22:12:30] <dmlloyd> but it was important
[22:12:42] <bstansberry> did you like my answer?
[22:12:56] <bstansberry> I said "outcome"=>"success"
[22:13:09] <baileyje> wolfc: JBAS-9019
[22:13:11] <jbossbot> jira [JBAS-9019] Support for ejb-jar.xml [Open (Unresolved) Sub-task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9019
[22:13:22] <smcgowan> smarlow:  but with the jpa demo, and H2, the connection metadata is retrieved: http://pastebin.com/Sa90V4mN
[22:13:34] <smarlow> smcgowan: I'm going to drive home, but my recommendation is to assign some of the jiras or get them recreated with smaller test cases (and then get jiras assigned)
[22:14:18] <smarlow> smcgowan:  my comment above was about http://pastebin.com/NjZ7s9PK.  I see the exception but no stack trace.
[22:16:02] *** jfd has quit IRC
[22:16:40] <dmlloyd> bstansberry, yeah I think that's the answer I was looking for
[22:17:37] <smarlow> smcgowan:  what happens when you run the DS demo with derby?
[22:17:52] <baileyje> bstansberry: ok. So the composite should have outcome of success?
[22:18:08] * bstansberry is happy he wrote wikis!
[22:18:11] <bstansberry> "The high level format of a basic composite operation response is largely the same as that of a simple operation response, although there is an important semantic difference. For a composite operation, the meaning of the outcome flag is controlled by the value of the operation request's rollback-on-runtime-failure field. If that field was false (default is true), the outcome flag will be success if any of the composite operation's steps
[22:18:11] <bstansberry> successful."
[22:18:24] <smcgowan> i'm setting that up now - i'll let you know later after your drive
[22:18:46] <baileyje> easy enough
[22:23:50] *** smarlow has quit IRC
[22:27:15] <Nihility> let me know if you guys fall asleep reading my email
[22:27:17] <Nihility> :)
[22:32:54] <wolfc> Nihility, maybe add Feature Versions and Timeboxed Versions?
[22:33:31] <wolfc> In essence you don't want a timebox to hold on anything but Blockers. So I think it should be as empty as possible.
[22:34:10] <wolfc> And then pick from featurebox, commit, resolve into timebox
[22:36:32] *** rmaucher has quit IRC
[22:36:45] *** frainone has joined #jboss-as7
[22:36:45] *** ChanServ sets mode: +v frainone
[22:44:22] <dmlloyd> well we're feature-boxing for the foreseeable future
[22:45:33] * stuartdouglas back
[22:45:42] <wolfc> According to the triangle there should not be a release date then. :-P
[22:46:05] <dmlloyd> we're also time boxing :)
[22:54:00] <wolfc> dmlloyd, another thing, WS wants to invoke 'directly' on the bean, while EE keeps interceptors tied to a view class. As noted earlier they can not use the no-interface view or a faked one.
[22:54:45] <wolfc> we may have to tie the interceptors to method-intf instead
[22:55:20] <wolfc> but all that is out of scope for EE and MB.
[22:58:15] *** miclorb_ has joined #jboss-as7
[23:01:22] <stuartdouglas> dmlloyd: did you merge my msc fix?
[23:01:52] <dmlloyd> I might have
[23:02:12] <stuartdouglas> does not look like it :-)
[23:03:26] <dmlloyd> yes :)
[23:03:34] <dmlloyd> (just now!)
[23:05:23] <stuartdouglas> smcgowan: I checked out CTS from svn, it took all day yesterday, I will look into the JAX-RS issue today
[23:06:01] <smcgowan> stuartdouglas:  ok the workspace is up-to-date, if you have questions let me know
[23:06:50] <smcgowan> the derby module is created but the datasource entry is not automatically added to the standalone configuration
[23:07:48] <smcgowan> i've included the settings in the checkout under: trunk/jee6tck-as7-mods/derby/derby-config.xml
[23:08:02] <smcgowan> i'm certain it is now configured correctly
[23:08:49] <smcgowan> yay - and thanks to all that helped with that (and listened to my whining along the way)  baileyje: that's means you
[23:15:36] <baileyje> bstansberry: One issue I see, is the multi-step controller will not let an individual step control the rollback flag
[23:16:22] <bstansberry> right
[23:16:46] <bstansberry> trying to remember the details why not
[23:17:20] <baileyje> So a nested composite will never fail from a runtime op.  Regardless of the rollback flag is.
[23:17:47] <bstansberry> hmm, that sounds wrong
[23:18:01] <bstansberry> the idea is the outer op controls
[23:18:12] <baileyje> yeah.  That makes sense to me.
[23:19:06] <bstansberry> so is that not working?
[23:19:23] <baileyje> The composite tells each step ti no rollback on its own.
[23:19:39] <bstansberry> ti no == to ? ')
[23:19:41] <bstansberry> ;)
[23:19:45] <bstansberry> lol
[23:19:49] <bstansberry> typing madness
[23:20:39] <baileyje> but if the step is a composite, and you tell it not to rollback, and it gets a runtime failure, it will always return success based on the change we are addressing.  So the outer composite will not longer know there would even be a need for rollback
[23:21:11] <bstansberry> ok, now I get the problem!
[23:21:22] <baileyje> Sorry it took me so long to describe it..
[23:22:31] * bstansberry is thinking
[23:22:48] <baileyje> bstansberry: I have to run for 20 mins.
[23:22:57] <bstansberry> ok
[23:27:22] <bstansberry> dmlloyd: was it you who suggested "outcome"=>"partial" at one point?
[23:28:12] <bstansberry> that would require some significant surgery though
[23:29:27] * dmlloyd doesn't remember suggesting that
[23:29:29] <dmlloyd> fwiw
[23:29:35] <dmlloyd> doesn't mean i didn't though
[23:30:13] *** jwulf has joined #jboss-as7
[23:31:22] *** jwulf has quit IRC
[23:31:35] *** jwulf has joined #jboss-as7
[23:34:22] * bstansberry is sad to be unable to blame his random thoughts on dmlloyd
[23:35:14] <bstansberry> baileyje: only thing I can think of is to play instanceof tricks with the ResultHandler
[23:36:46] <bstansberry> i.e. the controller for the the inner composite sees the ResultHandler is StepResultHandler and sets some state on it to notify the outer composite
[23:38:15] *** asoldano has quit IRC
[23:38:20] <bstansberry> emuckenhuber is looking at improving this general area, he may be able to de-hackify that
[23:40:33] *** Sacha has quit IRC
[23:48:42] <stuartdouglas> dmlloyd: I have a fair bit of stuff in my master that is ready to merge
[23:49:46] <dmlloyd> lay it on me
[23:50:07] <dmlloyd> actually, you're telling me to go look at it aren't you :)
[23:50:15] <stuartdouglas> hehe
[23:52:01] <stuartdouglas> as the web module stuff no longer needs the CL I moved all the deployers back to PARSE
[23:52:22] <dmlloyd> awesome.
[23:52:40] <dmlloyd> just testing now.
[23:52:55] <dmlloyd> it's to the point where I merge first, then start test build, *then* review the patch while that runs.
[23:53:19] <stuartdouglas> Are we aiming for deployment descriptor support for the next beta?
[23:53:33] *** jpearlin has joined #jboss-as7
[23:53:42] <dmlloyd> ideally, yeah
[23:54:10] <dmlloyd> JBAS-9016
[23:54:11] <jbossbot> jira [JBAS-9016] Support for deployment descriptor parsing (remaining) [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/JBAS-9016
[23:57:57] <jbossbot> git [jboss-as] push master 061b4ae.. Stuart Douglas Remove unused attachments
[23:57:57] <jbossbot> git [jboss-as] push master 3de3e34.. Stuart Douglas Add support for initalize in order deployments
[23:57:57] <jbossbot> git [jboss-as] push master e3b5323.. Stuart Douglas Add initial JAX-RS component integration
[23:57:57] <jbossbot> git [jboss-as] push master dfe2d7d.. Stuart Douglas JBAS-9066 Rename "jboss-structure.xml" to "jboss-deployment-structure.xml" and fix integration tests
[23:58:01] <jbossbot> jira [JBAS-9066] Rename "jboss-structure.xml" to "jboss-deployment-structure.xml" [Open (Unresolved) Task, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9066
[23:58:01] <jbossbot> git [jboss-as] push master ea3b4a3.. Stuart Douglas Update classfilewriter
[23:58:02] <jbossbot> git [jboss-as] push master cc68b22.. Stuart Douglas JBAS-9103 Move component configuration deployers back to the PARSE phase
[23:58:02] <jbossbot> jira [JBAS-9103] Move Component related processors back to PARSE phase [Open (Unresolved) Sub-task, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9103
[23:58:02] <jbossbot> git [jboss-as] push master 251d77d.. Stuart Douglas JBAS-9115 Copy manifest dependencies in an ear into all sub deployments
[23:58:03] <jbossbot> jira [JBAS-9115] Copy manifest dependencies in an ear into all sub deployments [Open (Unresolved) Feature Request, Major, Stuart Douglas] https://issues.jboss.org/browse/JBAS-9115
[23:58:03] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/fa1d30e...251d77d

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