[00:00:00] <jbossbot> jira [JBAS-8909] TransformerConfigurationException when reading faces-config.xml [Coding In Progress (Unresolved) Bug, Major, Jason Greene] https://issues.jboss.org/browse/JBAS-8909
[00:01:06] <Nihility> bstansberry: can you double check when you have a chance
[00:01:47] <bstansberry> you mean test ^^^ ? sure
[00:01:59] <asoldano> Nihility, bstansberry if you have some minutes before leaving today, please pull kabir's changes for Richard's deployment issue... that would make us life much better with going on with the WS integration tomorrow (europe time) :-)
[00:02:52] <bstansberry> asoldano: yes, i'll definitely do that; it's in the queue
[00:03:08] <asoldano> bstansberry, thanks
[00:04:49] <jpederse> Nihility: IronJacamar 1.0.0.Beta4 is out
[00:05:13] *** asoldano has quit IRC
[00:05:13] *** asoldano has joined #jboss-as7
[00:08:23] *** pgier has quit IRC
[00:11:29] <bstansberry> Nihility: it builds fine. smoke tests pass
[00:12:21] *** emmanuel has quit IRC
[00:15:08] <Nihility> Cool thanks
[00:15:52] <Nihility> dmlloyd: tonight I'm ready to give you a hand
[00:17:14] *** alesj has quit IRC
[00:17:30] <bstansberry> Nihility: I tested that against a rebased branch; want me to push to upstream?
[00:17:42] <dmlloyd> tonight I'm ready to knock off early and drink a more than average amount of beer :(
[00:17:53] <bstansberry> :)
[00:18:09] <dmlloyd> well we could at least regroup and get a task list together
[00:19:52] <stuartdouglas> dmlloyd: That sounds like a plan :-)
[00:20:00] <stuartdouglas> the beer part, not the task list  part...
[00:20:17] <bstansberry> minor task: once you merge EE, go through and re-enable smoke tests that have been disabled since ??? Dec ???
[00:20:55] <bstansberry> not you go through and re-enable, me go through and re-enable
[00:21:22] <dmlloyd> EE is merged
[00:22:13] <bstansberry> lol; seems i've been focused elsewhere
[00:22:30] <jbossbot> git [jboss-as] push master ba5d1cc.. Jason T. Greene Fix xalan, use the new jaxp module, fix JBAS-8909
[00:22:31] <jbossbot> jira [JBAS-8909] TransformerConfigurationException when reading faces-config.xml [Coding In Progress (Unresolved) Bug, Major, Jason Greene] https://issues.jboss.org/browse/JBAS-8909
[00:22:31] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/5d32981...ba5d1cc
[00:25:18] *** jpederse has quit IRC
[00:30:16] *** asoldano has quit IRC
[00:32:16] <stuartdouglas> If I have a managed bean that is also a servlet deployed in an ejb-jar in an ear
[00:32:35] <stuartdouglas> and then a war uses it as a servlet in web.xml
[00:33:03] <stuartdouglas> I am going to have to pick up that it is a managed bean, even though it is in a different deployment unit
[00:34:03] <stuartdouglas> which we may need some kind of whole deployment index
[00:34:13] <dmlloyd> can a servlet also be a managed bean?  I thought that wasn't allowed
[00:34:18] <stuartdouglas> yea
[00:34:40] <stuartdouglas> 15.5.15 in servlet 3.0
[00:34:50] <stuartdouglas> servlets can also be CDI beans
[00:35:01] <stuartdouglas> but not just a normal CDI bean, a CDI bean with resource injection
[00:35:33] <stuartdouglas> so this whole web components this is shaping up to be more complex than originally hoped :-)
[00:36:08] <stuartdouglas> actually maybe it is just a normal CDI bean
[00:36:21] <stuartdouglas> "JSR-299 specifies the requirements for these container-managed bean instances with respect to instantiation, injection and other services."
[00:36:44] <stuartdouglas> so that line could be taken to mean that the CDI injection stuff superceds the resource injection stuff
[00:37:54] <maxandersen> stuartdouglas: aren't beans spanning deployment units "grey area" ?
[00:38:10] <stuartdouglas> maybe
[00:38:19] <stuartdouglas> I kinda hope so so I can ignore them :-)
[00:39:49] <dmlloyd> ah that's not the same thing at all
[00:40:03] <dmlloyd> a servlet is a component sure
[00:40:12] <dmlloyd> but it's not a plain managed bean
[00:40:25] <stuartdouglas> no, but if you put an @ManagedBean on a servlet
[00:40:29] <dmlloyd> any component can be a CDI bean afaik
[00:40:44] <stuartdouglas> you have to be able to use the managed bean as a servlet
[00:40:51] <stuartdouglas> with all the interceptors etc
[00:41:34] <stuartdouglas> components are only CDI beans if there is a beans.xml in their jar
[00:41:43] <dmlloyd> right
[00:42:15] <dmlloyd> but I think any servlet would support injection, lifecycle and interceptors regardless of @ManagedBean
[00:43:36] <stuartdouglas> in which case it would not matter if I just always registered a new component for the servlet
[00:43:42] <dmlloyd> .
[00:43:44] <dmlloyd> right
[00:44:04] <stuartdouglas> if there servlet was a managed bean there would be two pretty much identical components
[00:44:08] <dmlloyd> I'm not sure it should be allowed to put @ManagedBean on a servlet tho
[00:44:23] <stuartdouglas> You will have to take that up with the spec authors
[00:44:26] <dmlloyd> still trying to find that in the spec
[00:44:27] <stuartdouglas> its pretty clear
[00:44:58] <stuartdouglas> are you looking in servlet 3.0 final?
[00:45:04] <dmlloyd> no, EE
[00:45:37] <dmlloyd> @ManagedBean is not mentioned in servlet
[00:45:38] <stuartdouglas> It is the last paragraph in the servlet 3.0 spec before the apendix
[00:46:16] <dmlloyd> hmm I think this is an old spec, on sec
[00:48:04] <dmlloyd> I think my interpretation is still valid, to a degree
[00:48:20] <dmlloyd> I guess if @ManagedBean is on a servlet, we additionally bind it into JNDI and that's it
[00:48:43] <maxandersen> bstansberry: ping about .deployed/.faileddeploy….
[00:48:48] <dmlloyd> the list of components is already uniquely indexed by name so we could probably use that somehow
[00:48:48] <stuartdouglas> but we will already create a normal @ManagedBean definition
[00:49:02] <bstansberry> maxandersen: yep
[00:49:18] <stuartdouglas> that will be bound to jndi
[00:49:38] <dmlloyd> yeah true but then the dependencies for injection will be all fucked up
[00:49:46] *** rawblem has joined #jboss-as7
[00:49:47] *** ChanServ sets mode: +v rawblem
[00:49:51] <maxandersen> bstansberry: I was showing the latest code/forum to rawblem
[00:49:57] <dmlloyd> unless we actually use the managed bean to create the servlet
[00:50:17] <stuartdouglas> I think that would be the correct way to do it
[00:50:18] <maxandersen> bstansberry: he came up with a usecase that might be interesting to consider.
[00:50:51] <rawblem> bstansberry, was just saying, might be good to flag a few more states
[00:50:55] <maxandersen> bstansberry: imagine the tools have copied over foo.war, added the foo.dodeploy marker - now we wait...
[00:51:11] <rawblem> .deploy.starting predominantly
[00:51:22] <rawblem> to show that the server has at least recognized it's trying to deploy something
[00:51:41] <maxandersen> bstansberry: but for how long…;) rawblem was suggesting it would be useful to have something like foo.deploying as indicator that something was actually happening.
[00:52:09] <maxandersen> bstansberry: I know we want to keep it to a *minimal* api but thought this one was worth considering….wdyt ?
[00:52:24] <bstansberry> 1 sec
[00:52:51] <bstansberry> that would be pretty trivial to do
[00:54:15] <bstansberry> I'll toss that in
[00:54:40] <rawblem> so where is the marker file exactly?
[00:54:44] <stuartdouglas> actually I don't think that we should support managed beans across deployment units
[00:54:58] <stuartdouglas> as it will mean the JNDI stuff will be bound to the wrong module context
[00:55:03] <dmlloyd> TLDs you mean?
[00:55:07] <bstansberry> in the deployments/ dir
[00:55:08] <stuartdouglas> we should just create a new component
[00:55:18] <stuartdouglas> sub deployments
[00:55:20] <dmlloyd> binding happens in the scope of the deployment containing the @ManagedBean
[00:55:25] <dmlloyd> only lookups happen inthe caller context
[00:55:44] <dmlloyd> but yeah the point is still valid that lookup deps won't work right as it is right now if you cross DUs
[00:55:50] <stuartdouglas> yea, but according to the servlet spec we need to create the bindings in the war module context
[00:55:52] <maxandersen> bstansberry: of course the server could get stuck in .deploying state too - but at least we can then just wait 5-10 seconds for the .deploying to show up and if it doesnt error early. if the .deploying then isn't gone after 1-2 minutes we can tell the user something is taking way too long ;)
[00:55:53] <dmlloyd> especially if you cross apps
[00:56:18] <dmlloyd> stuartdouglas: right.  if the MB is also a servlet then the lookups happen in the servlet's scope (it's an "overriding spec")
[00:56:34] <dmlloyd> the servlet rules are pretty clear on that, and on handling of comp
[00:57:27] <dmlloyd> at least, when the servlet is constructed
[00:57:46] <dmlloyd> if it's treated like an MB then we could probably use the MB rules
[00:58:52] *** pferraro has quit IRC
[00:59:48] <maxandersen> btw. bstansberry with exploded users can update their html, css and other dynamic files and it won't require a full redeploy right ? just wondering how that will work with AS 7 which seem to inteernally more agressively copy deployments...
[01:00:29] <bstansberry> basically, we won't copy exploded deployments
[01:00:43] <dmlloyd> exploded deployments are served right off the FS
[01:00:51] <dmlloyd> which means you can't use them in a domain, period
[01:01:41] <bstansberry> the tricky part is going to be avoid file locking
[01:02:58] *** smcgowan has joined #jboss-as7
[01:02:58] *** ChanServ sets mode: +v smcgowan
[01:04:00] <maxandersen> dmlloyd: "can't use them in a domain" …so no cool demos with a 3 server backed AS7 and quickly update some scripts/content ;)
[01:04:55] <bstansberry> with the servers running on audience members' phones
[01:04:56] <maxandersen> bstansberry: but sure makes good sense …and yeah - filelocking is tricky… might be necessary to do a foo.war.undeploy to make it let go?
[01:05:04] <maxandersen> bstansberry: yes
[01:07:01] <bstansberry> an undeploy would be a brute way to do it :)
[01:07:26] <maxandersen> bstansberry: sure - but you are the guys talking about explicit and safe apis ;)
[01:08:10] <bstansberry> maxandersen: yeah, I never said "brute" == bad!
[01:09:40] <maxandersen> bstansberry: ah ;)
[01:10:42] <maxandersen> bstansberry: but sure - not locking would be the best and I a goal to acheive - but having an explicit .undeploy form might not be bad since the locking might not be done by you but by a framework the user deployed…..
[01:13:07] <bstansberry> maxandersen: agreed
[01:15:10] <maxandersen> bstansberry: btw. thats actually not explicitly stated in our forum thread…how do I undeploy an archive today ? just remove foo.war ?
[01:15:33] <bstansberry> remove foo.war.deployed
[01:16:12] <bstansberry> that reminds me; there needs to be a README.txt in deployments/
[01:16:17] <maxandersen> ah - so we already got it  ?
[01:16:32] <bstansberry> to undeploy? yeah
[01:16:38] <maxandersen> i.e. bstansberry we already got explit undeploy
[01:16:46] <bstansberry> yes
[01:17:04] <maxandersen> well greatness…so that just needs a matching .undeploying marker and we are done ;)
[01:17:16] *** maxandersen has quit IRC
[01:18:32] *** maxandersen has joined #jboss-as7
[01:18:32] *** ChanServ sets mode: +v maxandersen
[01:18:55] <rawblem> bstansberry,  so... i admit the odds of me checking out the AS-source code directly are pretty slim.  So... in the next day or two, possibly monday, do you think you could fire me an email when you have something workable with a small list of instructions as to how to shove it into an AS-7?
[01:19:29] <rawblem> either point me to an i-build of the AS and a jar to overwrite one of my other ones? some such instructions would be great for me to get started
[01:20:50] <bstansberry> you just want a zip of a build?
[01:21:55] <dmlloyd> because typing two commands is too much...?
[01:21:55] *** jamezp has quit IRC
[01:22:29] <rawblem> bstansberry,  that would work, sure... or if its too much for you to email a whole AS-build, just point me to an AS-build i should download, and a link to a specific jar i should override with your recent changes
[01:22:35] <maxandersen> dmlloyd: typing two commands and wait 2-3 hours is worse than downloding a zip yes ;)
[01:22:57] <dmlloyd> 2-3 hours?  you building on an apple II?
[01:22:59] <maxandersen> that said…. rawblem you should try building AS7 its actually quite easy/fast these days.
[01:23:19] <rawblem> maxandersen,  my computer, as i've said, is near death... i'm lucky i'm not offline this entire week
[01:23:22] <maxandersen> dmlloyd: no but i dont have a large fiber optic to maven central ;)
[01:23:49] <maxandersen> rawblem: ah yes … but yeah; getting a zip of an as7 with this would definitely speed up our attack on this (bstansberry ;)
[01:25:50] <bstansberry> rawblem: I can use this job:
[01:25:52] <bstansberry> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-git-param/
[01:26:02] *** jamezp has joined #jboss-as7
[01:26:09] <bstansberry> which allows us to parameterize hudson so it runs against a branch
[01:27:10] <bstansberry> but I recommend you get the source and build it some night while you sleep
[01:28:35] *** jwulf has joined #jboss-as7
[01:29:08] *** jpearlin has joined #jboss-as7
[01:29:44] <bstansberry> can anyone give me a thumbs up on https://github.com/bstansberry/jboss-as/commit/8dcf4a0dd041d976ac532931052a830838850d28 ?
[01:29:45] <jbossbot> git [jboss-as] 8dcf4a0.. bstansberry at jboss dot com Re-enable smoke tests that work
[01:30:30] <rawblem> bstansberry,  from that link, where do i download the actual output build?
[01:30:46] <bstansberry> I'll have to play with it
[01:31:01] <bstansberry> I shouldn't have said anything; I was kinda thinking out loud
[01:31:09] <rawblem> oh ok heh
[01:31:17] <bstansberry> sorry
[01:35:46] <maxandersen> bstansberry: ill need to get some sleep - thanks for getting the file deploy api started…we'll do what we can to get this implemented ASAP in jbosstools trunk too….i want to do my talk at JBoss World with this stuff - actually I want to use this at eclipsecon if I can but that depends on rawblem's laptop not dying ;)
[01:36:29] <rawblem> maxandersen,  or rruss magically getting his ass in gear
[01:36:39] <bstansberry> maxandersen: have a good night. and use some of your massive budget  for hardware for your folks
[01:37:05] <maxandersen> bstansberry: i dont have a budget - im not a manager per redhats definition ;)
[01:37:57] <bstansberry> maxandersen: yeah, i know, if you were you'd be doing compass forms instead of chatting
[01:38:28] <maxandersen> exactly;)
[01:45:44] *** rmaucher has quit IRC
[01:49:37] <Nihility> I dont think we need to worry about the file locking of the deployed file
[01:49:54] <Nihility> File locking only matters if you have the file open
[01:50:03] <Nihility> And we won't have it open
[01:51:58] <Nihility> So I don't see how an undeploy is necessary, in fact if this problem of locking the deployed file existed, you would have the same thing happen with the undeploy file
[01:52:45] *** maxandersen has quit IRC
[01:55:26] *** rawblem has quit IRC
[02:20:00] *** miclorb_ has quit IRC
[02:26:34] <Nihility> stuartdouglas: my thinking was that an mb and a servlet are two components as far as jndi is concerned, they have two different lifecycled
[02:27:49] <stuartdouglas> but if you have a managed bean as a servlet, the web container can just look up the servlet in the app context to get an instance, and then the web container manages the lifecycle
[02:29:56] <Nihility> well the problem is that mb won't call predestroy
[02:30:35] <Nihility> So servlet should handle all 250ish stuff
[02:31:13] <Nihility> at least the destroy part
[02:31:53] <stuartdouglas> makes sense
[02:32:16] <Nihility> I guess I wonder what MBs offer a servlet
[02:32:34] *** jamezp has left #jboss-as7
[02:32:44] <Nihility> aside from a jndi name
[02:33:06] <Nihility> (from a user perspective)
[02:33:12] <stuartdouglas> interceptors
[02:33:28] <Nihility> ah yes
[02:34:29] <jbossbot> git [jboss-as] push master c797db3.. kabir Don't close the streams created from the file and URL varieties of DeploymentPlanBuilder.add()...
[02:34:29] <jbossbot> git [jboss-as] push master f3215a7.. kabir Test the deployment api
[02:34:29] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/ba5d1cc...f3215a7
[02:35:32] <Nihility> ok that makes sense.
[02:37:07] <Nihility> The caller context thing is strange
[02:38:03] <Nihility> you can have an mb be "reusable" across components
[02:38:23] <stuartdouglas> yea, its really weird
[02:38:54] *** miclorb has joined #jboss-as7
[02:39:57] <Nihility> say it has a resource ref to module/db, now two wars with different DBS can use that bean!
[02:40:28] <stuartdouglas> I don't think anyone really thought this stuff through
[02:41:09] <Nihility> so get this
[02:42:28] <Nihility> If it has no name, and is therefore not in jndi, the servlet container needs to execute lifecycle and injection
[02:43:09] <stuartdouglas> I wonder just how much of this stuff the TCK goes into
[02:43:51] <Nihility> not a ton of testing from what we heard
[02:45:05] <stuartdouglas> If we just made our servlet component type support interceptors
[02:45:21] <stuartdouglas> know one would know if we actually had managed bean servlets or not :-)
[02:45:58] <stuartdouglas> except for that two wars with different resources using it thing that you mentioned before
[02:47:36] *** bstansberry is now known as bstans_afk
[02:51:58] *** miclorb has quit IRC
[03:01:28] *** miclorb_ has joined #jboss-as7
[03:03:39] *** smcgowan has quit IRC
[03:07:24] <Nihility> stuartdouglas: did you and dmlloyd discuss a TODO list for ee component stuff?
[03:07:32] <stuartdouglas> not yet
[03:07:55] <Nihility> man i just heard to most awesome cover of kashmir ever
[03:08:30] <Nihility> well actually its the second time
[03:08:34] <Nihility> pandora keeps picking it
[03:08:45] <Nihility> http://www.youtube.com/watch?v=tPCmERgVAO0
[03:13:53] *** miclorb_ has quit IRC
[03:14:41] *** miclorb has joined #jboss-as7
[03:18:02] *** miclor___ has joined #jboss-as7
[03:19:28] *** miclorb has quit IRC
[03:20:47] *** miclor___ has quit IRC
[03:30:35] *** jpearlin has left #jboss-as7
[03:37:13] *** miclorb_ has joined #jboss-as7
[03:44:55] *** bstans_afk is now known as bstansberry
[03:51:23] <jbossbot> git [jboss-as] push master 9b6e2ee.. bstansberry at jboss dot com Re-enable smoke tests that work
[03:51:23] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/f3215a7...9b6e2ee
[03:56:36] <stuartdouglas> Is there anyone around who can merge https://github.com/stuartwdouglas/jboss-invocation for me and do a release of jboss-invocation?
[03:56:58] <stuartdouglas> I discovered a fairly major bug in the proxies
[04:04:04] <Nihility> sure i can do it
[04:05:19] <stuartdouglas> thans
[04:05:28] <stuartdouglas> thanks even
[04:08:49] <Nihility> +        if(method.getName().equals("getResult")) {
[04:08:49] <Nihility> +            return method;
[04:08:50] <Nihility> +        }
[04:08:50] <Nihility> +        return 20;
[04:09:04] <Nihility> i take it thats unintentional
[04:09:05] <Nihility> ?
[04:09:27] <stuartdouglas> actually I just used that to demonstrate the bug
[04:09:34] <stuartdouglas> I did not mean to commit it
[04:09:50] <Nihility> bridgemethod parent has something similar
[04:10:05] <Nihility> oh nm
[04:10:06] <Nihility> thats a test
[04:11:01] <stuartdouglas> but not a hugely useful one
[04:11:24] <stuartdouglas> I will re-do without it, give me a sec
[04:11:33] <Nihility> i can just edit it out
[04:11:34] <Nihility> dont worry
[04:29:54] *** pgier has joined #jboss-as7
[04:29:55] *** ChanServ sets mode: +v pgier
[04:30:13] *** praba has joined #jboss-as7
[04:30:38] <Nihility> i love git
[04:30:42] <Nihility> command of the day
[04:30:55] <Nihility> git checkout --patch <oldcommit>
[04:31:16] <Nihility> allows you to selectively apply reverse hunks for every change back to that commit
[04:34:03] <jbossbot> git [jboss-invocation] push master ca77ad1.. Stuart Douglas Fix proxy factory bug
[04:34:03] <jbossbot> git [jboss-invocation] push master a1afa3a.. Jason T. Greene Release 1.0.0.Beta3
[04:34:03] <jbossbot> git [jboss-invocation] push master 095d6c0.. Jason T. Greene Next is beta4
[04:34:04] <jbossbot> git [jboss-invocation] push master URL: http://github.com/jbossas/jboss-invocation/compare/7e39024...095d6c0
[04:35:50] <Nihility> stuartdouglas: done
[04:36:03] <stuartdouglas> Thanks
[04:39:26] <praba> Anybody: I'm new to Jboss.. i got standalone running on 8080.. but when i hit localhost:8080/admin-console i get a 404. What is it that i am missing?
[04:40:30] <Nihility> the console for as7 is under development right now its not completed
[04:41:04] <praba> oh. didn't know that. so, where should i start? take a look at JIRA?
[04:43:00] *** pferraro has joined #jboss-as7
[04:43:00] *** ChanServ sets mode: +v pferraro
[04:43:18] *** irooskov has quit IRC
[04:44:07] <bstansberry> Nihility: https://github.com/bstansberry/jboss-as/commit/82ea7cdf646f65a6c06c4a47ed8546e6e0c14eef
[04:44:08] <jbossbot> git [jboss-as] 82ea7cd.. bstansberry at jboss dot com Treat host.xml <server/> as 'server-config', running servers as 'server'
[04:44:59] <Nihility> so is domain.xml still server?
[04:45:15] <bstansberry> ?
[04:45:24] <Nihility> <server>
[04:45:28] <Nihility> erm
[04:45:30] <Nihility> nevermind
[04:45:31] <Nihility> im a moron
[04:45:32] <bstansberry> ah, good question
[04:45:43] <bstansberry> haha, well maybe not ;)
[04:46:04] <Nihility> i cant get the old domain.xml design out of my brain
[04:46:08] <Nihility> its permanent stuck
[04:46:09] <bstansberry> I mentioned changing <server> in host.xml to <server-config>
[04:46:10] <Nihility> looks good
[04:46:33] <bstansberry> doing ^^^ would have the xml match the model
[04:51:05] <jbossbot> git [jboss-as] push master 82ea7cd.. bstansberry at jboss dot com Treat host.xml <server/> as 'server-config', running servers as 'server'
[04:51:05] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/9b6e2ee...82ea7cd
[04:51:39] <Nihility> stuartdouglas: is there anything i can help you with
[04:51:52] <stuartdouglas> I am making progress
[04:52:23] <stuartdouglas> I had servlets etc working as managed beans, but now I am chaning them to proper web components so that @PreDestroy works
[04:53:04] <stuartdouglas> however at the moment we don't have a way of destroying an instance, so I am making component Proxies implement a DestroyableComponent interface
[04:53:13] <stuartdouglas> and adding a special interceptor to call the methods
[04:53:20] *** jamezp has joined #jboss-as7
[04:53:36] <stuartdouglas> so not really :-)
[05:04:43] *** pgier has quit IRC
[05:18:18] *** smarlow has quit IRC
[05:30:47] *** bstansberry is now known as bstans_afk
[05:37:58] <stuartdouglas> crap
[05:38:21] <stuartdouglas> I think we are going to have to re-do the web metadata stuff to work with Jandex info rather than actual types
[05:39:04] <stuartdouglas> because at the moment it is creating that info to late for me to use it to create components
[05:39:27] <stuartdouglas> unless I move all the component creation stuff right back into POST_MODULE
[05:39:43] *** jamezp has quit IRC
[05:50:54] *** pferraro has quit IRC
[06:03:17] <Nihility> stuartdouglas: yeah i expected that
[06:03:31] <stuartdouglas> for now I have just moved all the component stuff back
[06:03:39] <Nihility> stuartdouglas: actually one thing i wonder, is if it needs type info at all
[06:03:58] <stuartdouglas> I don't think it should
[06:04:04] <stuartdouglas> but it has been written that way
[06:05:09] <stuartdouglas> I'm just ducking out for a bit
[06:05:21] <Nihility> a deployer needs a representation of the descriptors
[06:05:29] <Nihility> it needs the annottaion information
[06:05:39] <Nihility> and then it needs the final post process state
[06:05:59] <Nihility> the first and the third should not need jandex or reflection types at all
[06:08:33] <Nihility> ok well im off to bed
[06:08:46] <Nihility> good luck :)
[06:09:06] <Nihility> oh i keep forgetting this is your friday
[07:03:51] *** praba has quit IRC
[07:27:40] <Nihility> ok now im really going to bed
[08:23:29] *** miclorb_ has quit IRC
[08:39:53] *** mbg has joined #jboss-as7
[08:39:53] *** ChanServ sets mode: +v mbg
[08:47:18] *** asoldano has joined #jboss-as7
[08:47:18] *** ChanServ sets mode: +v asoldano
[08:49:51] *** miclorb has joined #jboss-as7
[09:11:07] *** opalka has joined #jboss-as7
[09:11:07] *** opalka has joined #jboss-as7
[09:11:07] *** ChanServ sets mode: +v opalka
[09:21:13] *** pil-afk has joined #jboss-as7
[09:24:30] *** mbg is now known as mbg|away
[09:30:11] *** mbg|away is now known as mbg
[09:32:11] *** emmanuel has joined #jboss-as7
[09:32:11] *** ChanServ sets mode: +v emmanuel
[09:32:42] *** torben has joined #jboss-as7
[09:32:42] *** torben has joined #jboss-as7
[09:32:42] *** ChanServ sets mode: +v torben
[09:41:05] *** jcosta has joined #jboss-as7
[09:45:23] *** maeste has joined #jboss-as7
[09:45:23] *** ChanServ sets mode: +v maeste
[10:02:50] *** emuckenhuber has joined #jboss-as7
[10:02:50] *** emuckenhuber has joined #jboss-as7
[10:02:50] *** ChanServ sets mode: +v emuckenhuber
[10:10:19] *** mbg has quit IRC
[10:13:52] *** miclorb has quit IRC
[10:17:10] *** torben has quit IRC
[10:17:46] *** torben has joined #jboss-as7
[10:17:46] *** torben has joined #jboss-as7
[10:17:46] *** ChanServ sets mode: +v torben
[10:22:58] *** wolfc has joined #jboss-as7
[10:22:58] *** ChanServ sets mode: +v wolfc
[10:41:16] *** alesj has joined #jboss-as7
[10:46:00] *** AndyTaylor has joined #jboss-as7
[10:46:00] *** ChanServ sets mode: +v AndyTaylor
[10:56:20] *** pil-afk is now known as pilhuhn
[10:56:21] *** pilhuhn has quit IRC
[10:56:21] *** pilhuhn has joined #jboss-as7
[10:57:49] *** maxandersen has joined #jboss-as7
[10:57:49] *** ChanServ sets mode: +v maxandersen
[11:14:13] *** rmaucher has joined #jboss-as7
[11:21:35] *** opalka has quit IRC
[11:40:09] *** miclorb_ has joined #jboss-as7
[11:56:00] *** pilhuhn is now known as pil-afk-bbl
[11:57:00] *** miclorb_ has quit IRC
[11:57:13] <wolfc> dmlloyd, https://github.com/wolfc/jboss-as/commit/fe23d6805901226101ffb8e9a6a92e89c8680271
[11:57:14] <jbossbot> git [jboss-as] fe23d68.. Carlo de Wolf Make it compilable (smoketests are failing) (wip)
[11:59:06] *** opalka has joined #jboss-as7
[11:59:07] *** opalka has joined #jboss-as7
[11:59:07] *** ChanServ sets mode: +v opalka
[12:10:50] *** emmanuel has quit IRC
[12:20:36] *** darranl has joined #jboss-as7
[12:20:36] *** darranl has joined #jboss-as7
[12:20:36] *** ChanServ sets mode: +v darranl
[12:31:49] *** maxandersen has quit IRC
[12:33:11] *** asaldhan has quit IRC
[12:38:10] <wolfc> and https://github.com/wolfc/jboss-as/commit/a40c0bb04a75a3bdebfc5ab534bd78f91b774454
[12:38:11] <jbossbot> git [jboss-as] a40c0bb.. Carlo de Wolf Removed module dependency org.jboss.as.domain (smoketests pass)
[12:39:14] *** pil-afk-bbl is now known as pilhuhn
[12:48:19] *** asaldhan has joined #jboss-as7
[12:54:46] *** pilhuhn is now known as pil-afk-bbl
[12:59:06] *** torben has quit IRC
[13:10:09] *** smcgowan has joined #jboss-as7
[13:10:09] *** ChanServ sets mode: +v smcgowan
[13:24:06] *** maxandersen has joined #jboss-as7
[13:24:06] *** ChanServ sets mode: +v maxandersen
[13:28:05] <stuartdouglas> dmlloyd: Nihility When you guys wake up I have a fairly rough web component implementation  in my master
[13:29:53] <stuartdouglas> It has a few issues though, will talk about in the morning when my blood alcohol level is lower
[13:30:09] <stuartdouglas> I mean, when I have had good nights sleep
[13:31:00] *** smarlow has joined #jboss-as7
[13:31:01] *** ChanServ sets mode: +v smarlow
[13:39:50] *** pil-afk-bbl is now known as pilhuhn
[13:56:37] *** epbernard has joined #jboss-as7
[13:56:37] *** epbernard is now known as emmanuel
[13:56:37] *** ChanServ sets mode: +v emmanuel
[13:56:46] *** ccrouch has joined #jboss-as7
[13:56:46] *** ChanServ sets mode: +v ccrouch
[14:02:21] *** mmoyses has joined #jboss-as7
[14:02:21] *** ChanServ sets mode: +v mmoyses
[14:02:42] *** asaldhan has left #jboss-as7
[14:04:29] <alesj> stuartdouglas: :-)
[14:06:11] *** jpederse has joined #jboss-as7
[14:06:50] *** jpederse has joined #jboss-as7
[14:10:40] *** mbg has joined #jboss-as7
[14:10:40] *** ChanServ sets mode: +v mbg
[14:11:25] *** aloubyansky has joined #jboss-as7
[14:19:20] *** mmoyses has quit IRC
[14:20:39] *** mmoyses has joined #jboss-as7
[14:20:39] *** ChanServ sets mode: +v mmoyses
[14:21:34] *** torben has joined #jboss-as7
[14:21:34] *** ChanServ sets mode: +v torben
[14:23:49] <darranl> hi emuckenhuber
[14:25:33] <emuckenhuber> darranl: hi
[14:25:37] <asoldano> dmlloyd, Nihility please ping me when your awake, to me there's a bug in the jboss-modules related to the latest JAXP changes (found that through some failures in jbossws testsuite after the update)
[14:25:48] <darranl> hi emuckenhuber do you have time for a quick question?
[14:27:51] <darranl> emuckenhuber, I will ask anyway - just in case ;-)  - When a host connects to the domain controller is there an operation that the hosts calls to register itself as a host?
[14:30:00] *** mmoyses has quit IRC
[14:30:53] *** mmoyses has joined #jboss-as7
[14:30:53] *** ChanServ sets mode: +v mmoyses
[14:31:53] *** torben has quit IRC
[14:31:54] <smcgowan> emuckenhuber, bstans_afk:  i'm unable to add resource-adapters to a standalone config: http://pastebin.test.redhat.com/42949 is there a known issue with that?
[14:34:03] <emuckenhuber> darranl: it's not really an operation using an OperationHandler, it's part of the remoting protocol to register that at the DC - not sure if that answers your question though ;)
[14:34:43] <darranl> emuckenhuber, but it is something we can pick out as being different to a client (say the CLI) establishing a connection?
[14:37:59] <emuckenhuber> smcgowan: hmm, can you show me the xml? resource-adapters should be a child of the "<subsystem xmlns="urn:jboss:domain:resourceadapters:1.0"/>"
[14:39:14] <smcgowan> emuckenhuber: http://pastebin.test.redhat.com/42946
[14:42:27] <emuckenhuber> smarlow: http://pastebin.test.redhat.com/42957
[14:42:36] <emuckenhuber> smarlow: sorry, meant smcgowan
[14:42:45] <emuckenhuber> stupid tab completion :)
[14:44:15] <emuckenhuber> that should work, or at least call the ra subsystem parsers? at least it was <subsystem />
[14:44:48] <smcgowan> emuckenhuber: i'll check the full config file, but thought i terminated the subsystem
[14:44:49] <emuckenhuber> darranl: in theory, although i'm not sure if that's currently the case
[14:45:46] <darranl> emuckenhuber, ok thanks for the clarification - at some point I think it may come up as a requirement as I think it will be a candidate for something to detect in our ACLs for the authorization check
[14:46:10] <emuckenhuber> smcgowan: well there is <subsystem xmlns="urn:jboss:domain:resourceadapters:1.0" /> which closes the element right away :)
[14:49:19] <smcgowan> emuckenhuber:  ya, that is stupid - i've move forward now: http://pastebin.test.redhat.com/42960
[14:51:39] <emuckenhuber> smcgowan: hmm, yeah that seems to be broken then - maybe maeste can look into that
[14:51:49] <emuckenhuber> not sure if that's expected to work
[14:53:15] <smcgowan> emuckenhuber:  thx for pointing that out, and will continue to discuss with maeste
[14:53:29] <smcgowan> we've been discussing this earlier today
[14:54:55] <smcgowan> emuckenhuber:  this is probably not expected to work either, but filed a JIRA to track the CCE: https://issues.jboss.org/browse/JBCTS-1085
[14:55:46] <emuckenhuber> smcgowan: ok thanks - jean-frederic also had issues with that
[14:56:01] *** pferraro has joined #jboss-as7
[14:56:01] *** ChanServ sets mode: +v pferraro
[14:58:34] *** smcgowan has quit IRC
[15:02:20] *** ccrouch has quit IRC
[15:03:18] *** pgier has joined #jboss-as7
[15:03:19] *** ChanServ sets mode: +v pgier
[15:07:08] *** mbg has quit IRC
[15:25:47] *** alesj has quit IRC
[15:27:05] *** asaldhan has joined #jboss-as7
[15:27:16] <asaldhan> bstans_afk: thx for the ports. :)
[15:27:54] <Nihility> asoldano: Whats the bug?
[15:28:12] <Nihility> Morning everyone
[15:28:18] <asoldano> Nihility, hi Jason
[15:28:41] <asoldano> Nihility, the problem is that Module does as follows afaics: 1) erase the TCCL 2) load the platform default without TCCL setup and store the name fo the platform default 3) set a sys prop with the custom factories 4) restore the TCCL
[15:28:56] <asoldano> Nihility, the problem is that if you load the Module class from 2 different classloaders, the second execution fail
[15:29:22] <asoldano> Nihility, because it will still find the sys prop when trying to load the platform default, but with the bootstrap classloader (which has loaded FactoryFinder) only it's impossible to load the custom jboss factories
[15:30:19] <Nihility> You have a custom jaxp factory finder?
[15:30:27] <asoldano> Nihility, no
[15:30:47] <Nihility> Oh I think I understand what you are saying
[15:31:07] <Nihility> You are saying that your module has a custom provider
[15:31:15] <Nihility> But it's not being discovered
[15:31:55] <asoldano> the second time the Module class is initialized, the sys prop will make it look for your __XX factories
[15:32:28] <asoldano> but those might now be loadable in the classloader that loaded Module and all the linked stuff the second time
[15:32:39] <asoldano> s/now/not
[15:33:14] <Nihility> here is what the behavior is (well supposed to be)
[15:34:03] <Nihility> Everything in AS uses a default provider, that overrides the jdk, UNLESS the TCCL of the caller has a custom provider
[15:34:34] <Nihility> so if a user includes one in their deployment that will take precedence
[15:34:52] <Nihility> If a module needs a custom jaxp provider then it must do one of two things
[15:35:13] <Nihility> 1) set the TCCL before calling newINstance to be it's cl
[15:35:32] <Nihility> 2) use the cl form of new instance, and pass the modules cl
[15:35:44] <asoldano> I'm not saying the behaviour is wrong, let me be more clear
[15:35:51] <asoldano> see here: http://fpaste.org/u8PN/
[15:36:03] <asoldano> at line 12 you set the prop
[15:36:34] <asoldano> immagine you run that static block again, with the prop being already set to your DataTypeFactory
[15:36:55] <asoldano> at line 6 you won't be able to build the new factory instance
[15:37:32] <Nihility> jboss modules should only be on the classspath once
[15:37:42] <asoldano> that can happen if you load a class in a new classloader and that class looks for a DocumentBuilderFactory
[15:38:10] <asoldano> am I wrong?
[15:38:30] <Nihility> That static block should only be executed once
[15:39:07] <Nihility> the only way that could be executed twice is if you had more than one jboss modules occurrence in the system
[15:39:30] <asoldano> well, I do have a testcase (it's actually two tests executed one after the other in the jbossws testsuite) that reproduce this, and my understanding is that happens becase two diferent separated classloaders are used
[15:39:57] <Nihility> those class loaders would have to each have jboss modules in them
[15:40:04] <asoldano> yes
[15:41:01] <asoldano> my guess  is we should check the prop also before retrieving the platform default
[15:41:02] <Nihility> ok that's probably an issue, I could add a safe guard though
[15:41:14] <Nihility> And unset it if it's there
[15:41:17] <asoldano> if the prop is set to our custom factories, just reset it
[15:42:07] <asoldano> then there's probably a potential need for synchronization, but that's a probably a really unlikely issue
[15:42:18] <Nihility> although just so you know two class loaders with modules will likely have other issues, like each try to replae stream handlers and logging
[15:42:27] *** smcgowan has joined #jboss-as7
[15:42:27] *** ChanServ sets mode: +v smcgowan
[15:43:41] <asoldano> Nihility, ok... btw, the trick with new classloader here is just done for a specific set of tools tests (just tests)
[15:44:15] <Nihility> is there a chance you could keep the same module impl between the two class loaders
[15:44:39] <Nihility> or are you trying to load two different modules with the same name?
[15:45:30] <Nihility> also even if it does fix the issue
[15:45:36] <Nihility> It still will not work correctly
[15:45:52] <Nihility> Because only one modules impl can be the factory provider
[15:45:59] *** emmanuel has quit IRC
[15:46:18] <asoldano> the test is basically building an urlclassloader and running the jaxws tools with that... everything from the "original" classloader should simply not be used in there
[15:46:21] <Nihility> And it will not see the other modules module
[15:46:49] <asoldano> I can test if a fix like what we said above solve my test issue
[15:47:27] <Nihility> You could just disable it
[15:47:34] <Nihility> By setting the sys prop to something else
[15:48:02] <Nihility> after modules has loaded
[15:48:31] <asoldano> I can try erasing the prop before loading the class that triggers this all
[15:49:10] <Nihility> I could add a property to modules to tell it not to do this
[15:49:28] <Nihility> that would be a better fix
[15:50:30] <asoldano> I still think it would be better to check/clean the prop before getting the platform default, but I might be missing part of the overall use here
[15:50:45] <Nihility> no my point is that will never work
[15:50:57] <Nihility> You can only have one provider
[15:51:07] <Nihility> Both module implies will fight to be that provider
[15:51:11] <Nihility> One of them will lose
[15:51:31] <Nihility> It's like the highlander
[15:51:33] <Nihility> ....
[15:52:03] <asoldano> ;)
[15:52:57] *** epbernard has joined #jboss-as7
[15:52:57] *** epbernard is now known as emmanuel
[15:52:57] *** ChanServ sets mode: +v emmanuel
[15:53:11] <Nihility> are these ran in sequence?
[15:53:25] <Nihility> or in parallel
[15:53:37] <asoldano> in sequence
[15:54:21] <asoldano> the 2nd classloader is then trashed at the end of the test
[15:54:39] <Nihility> ok because you can have multiple module loaders
[15:54:54] <Nihility> Even in parallel
[15:55:21] <Nihility> and you get two isolated areas
[15:55:43] <asoldano> but they still see the same sysprop, right?
[15:56:00] <maxandersen> bstans_afk: ping….so i just used your build to do deployment from JBDS/JBoss Tools and ant…worked like a charm except for JBAS-8920 (but thats a core as issue not file deploy api)
[15:56:01] <jbossbot> jira [JBAS-8920] Deployment fails with empty classpath manifest [Open (Unresolved) Bug, Major, David Lloyd] https://issues.jboss.org/browse/JBAS-8920
[15:56:35] <Nihility> no because there is still only one jboss modules instancenin the vm
[15:58:49] <asoldano> mmh... so, let me understand, you're saying the problem comes from the 2 loaders I have seeing 2 different jboss modules instead of one as they should?
[15:59:44] <Nihility> right in a nutshell modules is supposed to be one per vm, we can support multiple but we have tonhave a feature to doable all the system stuff it registers to fix the jam
[15:59:46] <Nihility> Jam
[15:59:48] <Nihility> Erm
[15:59:50] <Nihility> jam
[15:59:56] <Nihility> jvm
[16:00:01] <Nihility> Damn autocorrect
[16:00:09] <asoldano> eheh
[16:00:29] <asoldano> anyway, ok, understood, so my test is doing something falling out of the supported usecases
[16:00:40] <asoldano> given the way it defines the new classloader
[16:01:12] <Nihility> alternatively if you run them in serial like that you could clear the state, and maybe we could add a method to do that like a I'm killing modules thing
[16:01:42] <asoldano> yes... let me try erasing the prop in my test first
[16:02:24] <Nihility> right so maybe you could tell me about how you use class loaders like this, are you trying to reset static varsity in jbossws?
[16:02:35] <Nihility> Variables
[16:02:51] <Nihility> I'm switching to a real computer......
[16:04:38] <Nihility> maxandersen: ah thanks for that one
[16:04:52] <maxandersen> Nihility: ?
[16:07:50] *** jpederse has quit IRC
[16:07:50] *** opalka has quit IRC
[16:07:51] *** jfclere1 has quit IRC
[16:07:52] *** bstans_afk is now known as bstansberry
[16:08:25] <bstansberry> maxandersen: cool; and thanks for the JIRA (I think that's what Nihility meant as well)
[16:08:37] *** jhalliday has joined #jboss-as7
[16:08:54] <bstansberry> I'll push the .deploying thing to the branch in a minute; been doing that this morning
[16:09:23] <Nihility> maxandersen: thats a bad assumption on our part
[16:12:00] <asoldano> Nihility, no afair (I'd need to check), it's just that for testing the jbossws tooling, the classloader provided by maven can't be used, so we created a new one starting from the surefire test classpath. But now that you cleared the problem a bit more to me, I can also try modifying that (first I try cleaning that sys prop before running the test)
[16:16:37] <Nihility> the bug
[16:17:20] <asoldano> ;)
[16:18:01] <Nihility> AH
[16:18:03] <Nihility> i see
[16:18:35] <Nihility> so you wanted to bypass the classloader but without forking a vm
[16:19:05] <asoldano> yes
[16:19:35] *** maxandersen1 has joined #jboss-as7
[16:19:35] *** ChanServ sets mode: +v maxandersen1
[16:19:36] <Nihility> so one option is that kkahn has a modular test environment
[16:20:08] <Nihility> another option is you could put modules a parent classloader
[16:20:32] <asoldano> ok, good, that's what I was thinking to try as a 2nd option
[16:20:34] <Nihility> another option is a way to prevent setting system things
[16:20:44] <Nihility> (with the known side effects)
[16:20:57] <Nihility> and last option is a reset call we could implement
[16:21:06] <asoldano> anyway I've cleared the "javax.xml.datatype.DatatypeFactory" before running the test and the test now seems to pass
[16:21:28] <Nihility> note there is 6 factories
[16:21:49] <asoldano> for the sake of my jbossws tools tests, I think I should be fine with this (plus other factories)
[16:22:50] <asoldano> now running the full testsuite to confirm...
[16:26:04] *** maxandersen has quit IRC
[16:26:04] *** darranl has quit IRC
[16:27:43] *** opalka has joined #jboss-as7
[16:27:43] *** opalka has joined #jboss-as7
[16:27:43] *** ChanServ sets mode: +v opalka
[16:27:50] <asoldano> Nihility, ok, solved 12 failures, going ahead with the remaining 15... thanks for the chat for now :-)
[16:27:53] *** jpederse has joined #jboss-as7
[16:28:04] *** jpederse has quit IRC
[16:28:04] *** jpederse has joined #jboss-as7
[16:28:50] <Nihility> np
[16:28:50] <Nihility> :)
[16:39:44] *** mbg has joined #jboss-as7
[16:39:47] *** mbg has quit IRC
[16:39:47] *** mbg has joined #jboss-as7
[16:39:47] *** ChanServ sets mode: +v mbg
[16:43:47] <maeste> bstansberry: ping
[16:43:57] <bstansberry> maeste: pong
[16:44:22] <maeste> bstansberry: Im getting this exception during startup https://gist.github.com/854843
[16:44:30] <maeste> bstansberry: for sure a problem in patch
[16:44:41] <maeste> bstansberry: but exception is not so clear to me
[16:45:06] <maeste> bstansberry: could you help me pointing me on what does it mean, and what seek in my changes?
[16:45:12] <bstansberry> there are two problems:
[16:46:05] <bstansberry> 1) the "add" handler for the DS subsystem is reporting a compensating operation "remove" -- and no handler for that op exists
[16:46:27] <bstansberry> 2) during boot we're executing compensating ops, and we really shouldn't be
[16:46:45] <bstansberry> but, all this is masking the real problem
[16:46:51] <maeste> exactly
[16:47:07] <bstansberry> which is that something is going wrong with the "add" causing it to get reverted
[16:47:20] <maeste> how can I unmask it?
[16:47:49] <maeste> just debugger? or something easier?
[16:48:23] <bstansberry> i can give you a quick workaround for 2) (it will probably be my solution for it)
[16:48:58] <maeste> k
[16:49:35] *** opalka has quit IRC
[16:51:25] <bstansberry> org.jboss.as.server.ServerControllerService.start
[16:51:34] <bstansberry> add at line 132
[16:51:43] <bstansberry> update.get(ModelDescriptionConstants.ROLLBACK_ON_RUNTIME_FAILURE).set(false);
[16:51:51] <bstansberry> maeste: ^^^
[16:52:22] <maeste> bstansberry: doing
[16:56:15] <maeste> bstansberry: line 132? update is not defined at that line
[16:56:41] <bstansberry> oops
[16:56:45] <bstansberry> line 180
[16:57:08] <bstansberry> I have two eclipse windows open, one overlapping the other and I read the wrong one!
[16:57:18] <maeste> lol
[16:57:45] <bstansberry>         for (ModelNode update : updates) {
[16:57:45] <bstansberry>             count.incrementAndGet();
[16:57:46] <bstansberry>             update.get(ModelDescriptionConstants.ROLLBACK_ON_RUNTIME_FAILURE).set(false);
[16:57:46] <bstansberry>             serverController.execute(ExecutionContextBuilder.Factory.create(update).build(), resultHandler);
[16:57:46] <bstansberry>         }
[17:07:53] *** darranl has joined #jboss-as7
[17:07:53] *** darranl has joined #jboss-as7
[17:07:53] *** ChanServ sets mode: +v darranl
[17:08:07] <jhalliday> smcgowan: ping
[17:08:38] <smcgowan> jhalliday: pong
[17:09:12] <jhalliday> smcgowan: where are the JCA API classes hidden in AS7, it does not seem to use jboss-connector-api ?
[17:09:39] <bstansberry> aloubyansky: I need to prefix commands with : to get them to work now -- http://pastebin.com/XgnpwqTk
[17:09:49] <smcgowan> jhalliday: {jboss.modules.dir}/javax/resource/api/main/ironjacamar-spec-api-1.0.0.Beta3.jar
[17:09:53] <aloubyansky> yes
[17:10:07] <aloubyansky> it's to not confuse the tab-completion
[17:10:16] <jhalliday> ahh, sneaky renaming. thanks.
[17:10:26] <aloubyansky> I just wrote http://community.jboss.org/docs/DOC-16581
[17:10:41] <bstansberry> aha, that probably answers my 2nd question, which was how to trigger tab completion :)
[17:10:51] <smcgowan> jhalliday:  i've got the changes integrated for JBAS-8910 with mmusgrov help.  committing now
[17:10:52] <jbossbot> jira [JBAS-8910] Upgrade JBossTS to version 4.14.0.Final [Open (Unresolved) Thirdparty Change, Major, Shelly McGowan] https://issues.jboss.org/browse/JBAS-8910
[17:11:07] <aloubyansky> press the tab :)
[17:11:18] <bstansberry> after typing :
[17:11:52] <jhalliday> smcgowan: cool
[17:11:56] <aloubyansky> if you press the tab before, you'll get the nodes
[17:12:16] <bstansberry> hmm, let me try again
[17:12:25] <smarlow> dmlloyd:  I hacked up a JPAInjectionAnnotationParseProcessor that is similar to ResourceInjectionAnnotationParsingProcessor.  Next I think I need something to read the PersistenceContext/PersistenceUnit annotations for components (like ManagedBeanAnnotationProcessor seems to read the ManagedBean annotation).
[17:13:26] <nickarls> Is there any list and what is working and what not on AS7? So that one knows what to file JIRA:s for and what not? ;-)
[17:14:07] <bstansberry> aloubyansky: having that work after /to would be nice
[17:14:19] <aloubyansky> yes... :)
[17:17:23] *** Nihility_ has joined #jboss-as7
[17:17:24] *** Nihility_ has joined #jboss-as7
[17:17:24] *** ChanServ sets mode: +v Nihility_
[17:18:48] *** mmoyses has quit IRC
[17:18:48] *** Nihility has quit IRC
[17:18:48] *** stalep has quit IRC
[17:18:55] *** Nihility_ is now known as Nihility
[17:18:58] <bstansberry> this also point out a problem in the read-resource-description/read-operation-names handling
[17:19:12] <bstansberry> inherited operations are not reported
[17:21:04] <bstansberry> that's not a CLI problem; it's in how the handlers work
[17:21:39] <aloubyansky> btw, i'm committing a typo fix... the operations are of the node aren't listed in the tab-completion, only the global ones are...
[17:21:49] <dmlloyd> smarlow: yeah I'd say that's next
[17:24:20] *** smcgowan has quit IRC
[17:24:47] *** smcgowan has joined #jboss-as7
[17:25:17] *** stuartdouglas has quit IRC
[17:25:49] *** asoldano_ has joined #jboss-as7
[17:25:54] <smarlow> dmlloyd:  it seems like ManagedBeanAnnotationProcessor is a component level thing.  I'll want to read (JPA) PeristenceContext/Unit annotations from WEB/EJB3 components.  Does that mean we need to build the WEB/EJB3 equivalents of ManagedBeanAnnotationProcessor that also reads the JPA annotations?  Or can I build something standalone that reads the JPA annotations?
[17:26:18] <jbossbot> git [jboss-as] push master 73e4172.. Alexey Loubyansky JBAS-8919
[17:26:19] <jbossbot> jira [JBAS-8919] add read-children-types operation [Open (Unresolved) Task, Major, Alexey Loubyansky] https://issues.jboss.org/browse/JBAS-8919
[17:26:19] <jbossbot> git [jboss-as] push master 4751cd6.. Alexey Loubyansky complete operation tab-completion
[17:26:19] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/82ea7cd...4751cd6
[17:26:44] *** ALR1 has joined #jboss-as7
[17:27:38] *** stalep has joined #jboss-as7
[17:27:43] <smarlow> dmlloyd:  or I could ask, should I have a JPA impl that extends AbstractInjectableDescription?
[17:27:47] *** jcosta_ has joined #jboss-as7
[17:28:05] <smarlow> dmlloyd:  oops, I mean AbstractComponentDescription
[17:28:32] <aloubyansky> bstansberry: could you please pull in one more... i sent the email to the list. thanks!
[17:29:18] <dmlloyd> only if it is a "component" in the EE sense.  The test is:  can it have @Resource injections of its own?  and, can (EE) modules contain instances of it?
[17:29:29] *** jamezp has joined #jboss-as7
[17:29:59] <dmlloyd> smarlow, it looks to me like e.g. @PersistenceUnit is really more of an injection than a component, just from my glance over the EE platform spec.
[17:30:19] <smarlow> dmlloyd:  I am definitely in agreement with you on that.
[17:30:34] *** bstansberry_ has joined #jboss-as7
[17:30:38] *** bstansberry_ has quit IRC
[17:30:38] *** bstansberry_ has joined #jboss-as7
[17:30:38] *** ChanServ sets mode: +v bstansberry_
[17:30:42] <Nihility> woo
[17:30:48] <jbossbot> git [jboss-as] push master 217d05b.. Alexey Loubyansky pass the full address instead of just the prefix to the candidates provider
[17:30:48] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/4751cd6...217d05b
[17:30:54] <dmlloyd> smarlow: so I think the processor for @PersistenceUnit should (a) find the component which it is attached to, and (b) add BindingDescriptions to it similarly to how the Resource processor does.
[17:30:54] <Nihility> as7 in 64 bit mode heap = 14 megs
[17:30:59] <Nihility> 32 bit mode 8 megs
[17:31:10] <dmlloyd> Nihility: don't forget -XX:+UseCompressedOops :-)
[17:31:22] <dmlloyd> I got it running in 9 megs on my system with that
[17:31:24] <maxandersen1> bstansberry: btw. anyone on AS team the shellscript expert?
[17:31:25] <Nihility> java has lots of pointers! lol
[17:31:25] <dmlloyd> (64-bit)
[17:31:44] <dmlloyd> Nihility, no kidding.  It almost doubles the size of objects
[17:31:53] *** asoldano has quit IRC
[17:32:49] *** asaldhan1 has joined #jboss-as7
[17:36:54] *** pferraro has quit IRC
[17:36:54] *** asaldhan has quit IRC
[17:36:54] *** jcosta has quit IRC
[17:36:54] *** jwulf has quit IRC
[17:36:55] *** bstansberry has quit IRC
[17:36:55] *** ALR has quit IRC
[17:36:56] *** bstansberry_ is now known as bstansberry
[17:38:42] *** jwulf has joined #jboss-as7
[17:38:43] <smarlow> dmlloyd:  Makes sense.  I assume you, the processor for @PersistenceUnit should grab the components DU COMPOSITE_ANNOTATION_INDEX and add directly to that.  Sound about right?
[17:39:06] <dmlloyd> one sec, smarlow
[17:41:16] *** jfclere has joined #jboss-as7
[17:44:11] *** jwulf has quit IRC
[17:47:56] *** maxandersen1 has quit IRC
[17:51:25] *** emuckenhuber has quit IRC
[17:53:10] *** maxandersen has joined #jboss-as7
[17:53:10] *** ChanServ sets mode: +v maxandersen
[17:58:12] *** aloubyansky has quit IRC
[18:03:26] <asaldhan1> ALR1: ping ut?
[18:07:21] <dmlloyd> smarlow: I'm just on a call, shouldn't be long though
[18:15:14] *** emmanuel has quit IRC
[18:15:16] <maxandersen> trying to use the CLI…that thing really is upside down when it comes to syntax ;)
[18:22:46] *** jcosta_ has quit IRC
[18:23:29] <dmlloyd> smarlow: okay back
[18:23:52] <dmlloyd> smarlow: the annotation index is already created when your processor is entered
[18:24:09] *** maeste has quit IRC
[18:24:50] *** maeste has joined #jboss-as7
[18:24:50] *** ChanServ sets mode: +v maeste
[18:25:41] <dmlloyd> smarlow: so basically what you do is, find the annotations you're interested in, find the corresponding components (via org.jboss.as.ee.component.Attachments#EE_MODULE_DESCRIPTION), and add the resource injections to them
[18:27:38] *** Nihility has quit IRC
[18:31:28] *** maxandersen has quit IRC
[18:31:56] *** maxandersen has joined #jboss-as7
[18:31:57] *** ChanServ sets mode: +v maxandersen
[18:33:29] *** emuckenhuber has joined #jboss-as7
[18:33:29] *** emuckenhuber has joined #jboss-as7
[18:33:29] *** ChanServ sets mode: +v emuckenhuber
[18:34:34] *** Nihility has joined #jboss-as7
[18:34:34] *** ChanServ sets mode: +v Nihility
[18:35:06] <Nihility> dont you hate it when your irc client has a model dialog which steals focus and that dialog gets lost
[18:35:08] <Nihility> :)
[18:36:49] <ALR1> asaldhan1: Hi.
[18:36:50] *** maeste has quit IRC
[18:37:19] *** maeste has joined #jboss-as7
[18:37:20] *** ChanServ sets mode: +v maeste
[18:37:25] *** ALR1 has quit IRC
[18:37:47] *** ALR has joined #jboss-as7
[18:37:47] *** ChanServ sets mode: +v ALR
[18:37:57] *** maxandersen has quit IRC
[18:45:05] <jbossbot> git [jboss-as] push master 3402ce3.. bstansberry at jboss dot com Reduce console noise in the build
[18:45:05] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/217d05b...3402ce3
[18:50:21] *** jhalliday has quit IRC
[18:52:02] *** AndyTaylor has quit IRC
[19:02:19] *** maeste has quit IRC
[19:02:51] *** maeste has joined #jboss-as7
[19:02:52] *** ChanServ sets mode: +v maeste
[19:04:33] *** emuckenhuber has left #jboss-as7
[19:04:34] <jbossbot> git [jboss-as] push master 7612b5c.. bstansberry at jboss dot com Further reduce console noise in smoke tests
[19:04:35] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/3402ce3...7612b5c
[19:04:44] *** emuckenhuber has joined #jboss-as7
[19:04:44] *** ChanServ sets mode: +v emuckenhuber
[19:04:49] *** bstansberry is now known as bstans_afk
[19:05:48] *** maeste has quit IRC
[19:06:21] *** maeste has joined #jboss-as7
[19:06:21] *** ChanServ sets mode: +v maeste
[19:06:41] *** darranl has quit IRC
[19:18:23] *** maeste is now known as maeste_dinner
[19:21:15] *** emuckenhuber has quit IRC
[19:33:51] *** emuckenhuber has joined #jboss-as7
[19:38:02] *** maeste_dinner has quit IRC
[19:38:02] *** Nihility has quit IRC
[19:38:45] *** emuckenhuber has quit IRC
[19:38:46] *** emuckenhuber has joined #jboss-as7
[19:38:46] *** ChanServ sets mode: +v emuckenhuber
[19:39:10] *** maeste_dinner has joined #jboss-as7
[19:39:10] *** Nihility has joined #jboss-as7
[19:39:10] *** gibson.freenode.net sets mode: +vv maeste_dinner Nihility
[19:44:29] <bstans_afk> smcgowan: can you rebase to upstream and re-push your tx changes?
[19:44:50] *** bstans_afk is now known as bstansberry
[19:45:58] <bstansberry> hmmm -- you have a merge commit (https://github.com/smcgowan/jboss-as/commit/ff4d7c8369767da0503fa7870e59458b00fded14) in your master and when I rebase another commit pops out at the top
[19:46:00] <jbossbot> git [jboss-as] ff4d7c8.. Shelly McGowan Merge branch 'master' of git://github.com/jbossas/jboss-as
[19:47:53] <bstansberry> ah, it's this one: https://github.com/smcgowan/jboss-as/commit/67c826345f91fe0e376742836274b95932844652
[19:47:53] <jbossbot> git [jboss-as] 67c8263.. Shelly McGowan JBEE-74 - update jboss-jaxb-api_2.2_spec to 1.0.1.Final
[19:47:54] <jbossbot> jira [JBEE-74] jboss-jaxb-api_2.2_spec-1.0.0.Final missing Message.properties [Resolved (Done) Bug, Major, Shelly McGowan] https://issues.jboss.org/browse/JBEE-74
[19:49:28] <smarlow> dmlloyd:  thanks for the help, I'm hacking into doing that now... :)
[19:54:12] *** mbg has quit IRC
[20:01:13] *** mbg has joined #jboss-as7
[20:01:13] *** ChanServ sets mode: +v mbg
[20:04:26] *** mbg has quit IRC
[20:04:39] *** mbg has joined #jboss-as7
[20:04:45] *** ChanServ sets mode: +v mbg
[20:15:42] *** mbg has quit IRC
[20:17:31] <emuckenhuber> bstansberry: hmm, do we want to persist the location of an exploded deployment as part of the standalone.xml?
[20:20:41] *** jamezp1 has joined #jboss-as7
[20:23:12] <bstansberry> ugh; good point
[20:23:12] *** jamezp has quit IRC
[20:23:12] *** smcgowan has quit IRC
[20:23:20] <emuckenhuber> or can we just have that as part of the deployment repository ?
[20:23:20] <bstansberry> I hated the idea of storing scanner state in standalone.xml
[20:23:22] <bstansberry> this is different from the scanner state though, since as you say it involves the repo
[20:23:22] <bstansberry> yes, store it in the repo
[20:23:25] <emuckenhuber> ok, that's what i did so far
[20:23:25] <emuckenhuber> and on what do want to base the deployment hash ?
[20:23:25] <bstansberry> I like the general notion dmlloyd has put out there a couple times of having the <deployment> element contain more details on the contet
[20:23:25] <bstansberry> but i don't want to pursue that over the next week :)
[20:23:28] <bstansberry> mount the exploded dir as vfs mount and the calcuate the hash as if it were a zip?
[20:23:31] *** stuartdouglas has joined #jboss-as7
[20:23:31] *** ChanServ sets mode: +v stuartdouglas
[20:23:31] <bstansberry> I don't really mean mount it and keep it around; I just mean use VFS to make it look like a zip and then calculate the hash
[20:24:35] <emuckenhuber> yeah, so a hash based on the deployment contents - do you think that could be an issue if i.e. JBossTools changes some html files in the deployment? as the hash would change?
[20:37:56] *** dmlloyd has quit IRC
[20:50:49] <jbossbot> git [jboss-as] push master 3d7bb37.. Shelly McGowan JBEE-74 - update jboss-jaxb-api_2.2_spec to 1.0.1.Final
[20:50:49] <jbossbot> jira [JBEE-74] jboss-jaxb-api_2.2_spec-1.0.0.Final missing Message.properties [Resolved (Done) Bug, Major, Shelly McGowan] https://issues.jboss.org/browse/JBEE-74
[20:50:49] <jbossbot> git [jboss-as] push master e77d9f0.. Shelly McGowan JBAS-8910 - upgrade JBoss TS to 4.14.0.Final
[20:50:51] <jbossbot> jira [JBAS-8910] Upgrade JBossTS to version 4.14.0.Final [Open (Unresolved) Thirdparty Change, Major, Shelly McGowan] https://issues.jboss.org/browse/JBAS-8910
[20:50:51] <jbossbot> git [jboss-as] push master 2dac70c.. Shelly McGowan JBAS-8910 - upgrade JBoss TS to 4.14.0.Final
[20:50:51] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/7612b5c...2dac70c
[21:11:18] *** rmaucher has quit IRC
[21:11:18] *** stuartdouglas has quit IRC
[21:11:18] *** emuckenhuber has quit IRC
[21:11:18] *** bstansberry has quit IRC
[21:11:18] *** jpederse has quit IRC
[21:11:19] *** pgier has quit IRC
[21:11:19] *** maeste_dinner has quit IRC
[21:11:20] *** Nihility has quit IRC
[21:11:20] *** jamezp1 has quit IRC
[21:11:21] *** ChanServ has quit IRC
[21:11:21] *** jfclere has quit IRC
[21:11:21] *** smarlow has quit IRC
[21:11:22] *** pilhuhn has quit IRC
[21:11:22] *** nickarls has quit IRC
[21:11:23] *** asaldhan1 has quit IRC
[21:11:23] *** asoldano_ has quit IRC
[21:11:24] *** bobmcw has quit IRC
[21:11:24] *** stalep has quit IRC
[21:11:25] *** wolfc has quit IRC
[21:11:25] *** stuartdouglas_ has quit IRC
[21:11:25] *** ALR has quit IRC
[21:12:38] <jbossbot> git [jboss-as] push master 7108ef5.. Stefano Maestri JBAS-8924 porting to IJ beta4
[21:12:39] <jbossbot> jira [JBAS-8924] Port connector subsystems to IronJacamar Beta4 [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-8924
[21:12:40] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/2dac70c...7108ef5
[21:17:39] *** maeste_dinner has joined #jboss-as7
[21:17:39] *** FordPrefect has joined #jboss-as7
[21:17:39] *** torben has joined #jboss-as7
[21:17:39] *** mbg has joined #jboss-as7
[21:17:39] *** jamezp has joined #jboss-as7
[21:17:39] *** stuartdouglas has joined #jboss-as7
[21:17:39] *** gibson.freenode.net sets mode: +vvvv FordPrefect torben mbg stuartdouglas
[21:17:39] *** dmlloyd has joined #jboss-as7
[21:17:39] *** opalka has joined #jboss-as7
[21:17:39] *** pferraro has joined #jboss-as7
[21:17:39] *** smcgowan has joined #jboss-as7
[21:17:39] *** Nihility has joined #jboss-as7
[21:17:39] *** gibson.freenode.net sets mode: +vvvv dmlloyd opalka pferraro Nihility
[21:17:39] *** emuckenhuber has joined #jboss-as7
[21:17:39] *** ALR has joined #jboss-as7
[21:17:39] *** jfclere has joined #jboss-as7
[21:17:39] *** asaldhan1 has joined #jboss-as7
[21:17:39] *** bstansberry has joined #jboss-as7
[21:17:39] *** stalep has joined #jboss-as7
[21:17:39] *** asoldano_ has joined #jboss-as7
[21:17:39] *** jpederse has joined #jboss-as7
[21:17:39] *** pgier has joined #jboss-as7
[21:17:39] *** gibson.freenode.net sets mode: +vvvv emuckenhuber ALR bstansberry pgier
[21:17:39] *** smarlow has joined #jboss-as7
[21:17:39] *** rmaucher has joined #jboss-as7
[21:17:39] *** wolfc has joined #jboss-as7
[21:17:39] *** stuartdouglas_ has joined #jboss-as7
[21:17:39] *** bobmcw has joined #jboss-as7
[21:17:39] *** nickarls has joined #jboss-as7
[21:17:39] *** ChanServ has joined #jboss-as7
[21:17:39] *** gibson.freenode.net sets mode: +vvvo smarlow wolfc bobmcw ChanServ
[21:21:39] *** smcgowan has quit IRC
[21:22:02] *** smcgowan has joined #jboss-as7
[21:22:02] *** ChanServ sets mode: +v smcgowan
[21:23:26] <smarlow> dmlloyd, rmaucher:  Is there a WEB DeploymentUnitProcessor change coming to add WEB components via EEModuleDescription.addComponent()?  That gets attached to the DU via org.jboss.as.ee.component.Attachments.EE_MODULE_DESCRIPTION.
[21:23:41] <dmlloyd> yes, it will
[21:23:56] <stuartdouglas> I have one in my master
[21:24:05] <smarlow> dmlloyd:  okay, just want to make sure I was understanding :)
[21:24:17] <dmlloyd> don't worry too much about the differences between component types for now, unless the spec defines something specific
[21:28:15] <Nihility> that jca issue
[21:28:21] <Nihility> its processing annotations using reflection
[21:28:32] <stuartdouglas> dmlloyd: In my master I have CDI injection and web components implemented
[21:29:00] <stuartdouglas> I had to move all the component creation back into POST_MODULE though, as that is where web annotations get read
[21:29:45] <stuartdouglas> also at the moment it makes all servlets into components, even builtin ones like the FacesServlet, not sure if that is an issue
[21:29:52] <Nihility> yeah htat is probably the same explanation for JBAS-8925
[21:29:54] <jbossbot> jira [JBAS-8925] Failure in the rar demo smoke test [Open (Unresolved) Bug, Blocker, Jason Greene] https://issues.jboss.org/browse/JBAS-8925
[21:31:02] <stuartdouglas> the web module also processes annotations with reflection
[21:32:16] <stuartdouglas> hmm, weld does not really let you do anything if you don't have the correct TCCL set
[21:32:41] <jpederse> Nihility: JCA has a SPI which uses jandex in AS 7
[21:33:23] <Nihility> jpederse: yes it initially does, but then it uses reflection to read values
[21:34:39] <jpederse> Nihility: k, that part
[21:35:14] <jpederse> stuartdouglas: onnector/src/main/java/org/jboss/as/connector/annotations/repository/jandex/AnnotationImpl.java - if you want to look
[21:35:18] <Nihility>  hmm that does happen in install
[21:35:24] <Nihility> phase though
[21:35:36] *** ccrouch has joined #jboss-as7
[21:35:37] *** ChanServ sets mode: +v ccrouch
[21:37:43] <Nihility> jpederse: in the future you can now read that stuff straight off the index, so that might simplify the process, but that doesnt seem to explain this problem
[21:39:13] <jpederse> Nihility: neat-o
[21:39:59] <Nihility> its probably a classloading issue
[21:40:05] <Nihility> that by luck shows up in annotation phase
[21:40:37] *** rawblem has joined #jboss-as7
[21:40:37] *** ChanServ sets mode: +v rawblem
[21:41:00] <rawblem> bstansberry,  so um... how do i start up this server? Or... alternatively, where would I find the docs on it? =]
[21:41:14] <jpederse> sounds likely - every dump I have seen from maeste_dinner looks classloader related, as we pass those around internally
[21:41:22] <rawblem> just ./standalone.sh?
[21:41:25] <rawblem> seems pretty tiny
[21:41:43] <bstansberry> http://community.jboss.org/wiki/JBossAS7UserGuide
[21:41:53] <rawblem> thanks that should get me started =]
[21:41:54] <bstansberry> short answer: ./standalone.sh
[21:42:06] <bstansberry> I put in the .deploying thing
[21:43:04] <Nihility> rawblem: did you end up building it, how long did it take for you
[21:44:26] <rawblem> no i didn't build... i've been having laptop problems and am really in a broken state while i wait for a new laptop ;)
[21:44:57] <rawblem> i just downloaded from the link bstansberry sent me https://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-git-param/10/
[21:45:07] <bstansberry> there's another one out there now
[21:45:08] <Nihility> ah well in that case you can always ssh into a qa box
[21:45:36] <Nihility> you just do git clone, then ./build.sh and your good to go
[21:45:41] *** frainone has joined #jboss-as7
[21:45:42] *** ChanServ sets mode: +v frainone
[21:46:41] <Nihility> but yeah the build for me is about a minute -> two minutes
[21:48:06] *** maxandersen has joined #jboss-as7
[21:48:06] *** ChanServ sets mode: +v maxandersen
[21:48:14] *** maxandersen has quit IRC
[21:48:30] *** maxandersen has joined #jboss-as7
[21:48:30] *** ChanServ sets mode: +v maxandersen
[21:52:03] *** maeste_dinner has quit IRC
[21:54:30] *** maeste has joined #jboss-as7
[21:54:31] *** ChanServ sets mode: +v maeste
[21:54:57] <maeste> Nihility: I'll be online for a while if you need me
[21:55:16] <maeste> Nihility: I saw your discussion had with jpederse before
[21:55:40] <Nihility> ok yeah im not digging into it yet, i just took a brief look to see if the problem was obvious
[21:56:09] <maeste> Nihility: it's quite strange since it seems to don't find a class provided in the deployed rar
[21:56:45] <maeste> Nihility: anyway I'll be here for an hour or two. Just ping me if you need me
[21:57:04] <Nihility> ok
[21:57:07] <Nihility> thanks
[21:57:34] <stuartdouglas> dmlloyd: can you pull  https://github.com/stuartwdouglas/jboss-logmanager
[21:57:55] <stuartdouglas> I just added a quick fix to stop it throwing and then catching NPE's
[21:58:10] <stuartdouglas> as it is really annoying when you have a NPE breakpoint set
[22:01:21] <dmlloyd> heh
[22:01:46] <dmlloyd> hm that's actually not quite the right fix
[22:01:57] <dmlloyd> it's that same stupid issue where the VM uses null to mean system CL...
[22:02:02] * dmlloyd hates that
[22:03:13] *** ccrouch has quit IRC
[22:03:54] <stuartdouglas> I must admit I did not look past getting rid of the NPE
[22:05:30] <maxandersen> dmlloyd: quick quesiton - did you ever get around to do the logging output enhancements we discussed at devoxx ? multicolor and app specific logging ?
[22:05:50] <stuartdouglas> multicolor? cool
[22:09:38] <Nihility> mmmm multicolor
[22:12:19] <dmlloyd> maxandersen: I got around to writing those things on my list :)
[22:14:54] <Nihility> we have to save something for 7.1
[22:14:55] <Nihility> :)
[22:23:30] <maxandersen> dmlloyd: bummer ;)
[22:24:24] <maxandersen> dmlloyd: another devoxx leftover - we talked about adding support for parsing old ds.xml for basic datasource deployment to support all existing tooling and what I think would be the reqirements for about 90% of all web devs...
[22:24:29] <maxandersen> deploy war + datasource.
[22:24:41] <maxandersen> without having to invoke custom apis...
[22:24:58] <nickarls> max: ansi animation!
[22:25:19] <maxandersen> nickarls: the multi color was simply to not have the domain log output be useless
[22:25:35] <Nihility> maxandersen: sounds like a great JBossTools feature
[22:25:39] <Nihility> a migration tool
[22:25:49] <maxandersen> Nihility: huh? which feature ?
[22:26:03] <Nihility> :)
[22:26:16] <Nihility> porting old ds.xml files
[22:26:20] <maxandersen> Nihility: convering ds.xml into what exactly ?
[22:26:36] <maxandersen> Nihility: as far as I can see there is nothing to port it too.
[22:27:27] <maxandersen> Nihility: all is requiring complex use of the detyped model api…not at all "convertible" …which is why I suggested supporting reading basic info from ds.xml ...
[22:28:07] <jpederse> maxandersen: I can provide the mapping for that if you want...
[22:28:10] <dmlloyd> stuartdouglas: would you mind looking at JBAS-8920 if you get a second
[22:28:12] <jbossbot> jira [JBAS-8920] Deployment fails with empty classpath manifest [Open (Unresolved) Bug, Major, David Lloyd] https://issues.jboss.org/browse/JBAS-8920
[22:28:13] <maxandersen> my biggest concern is that AS 7 becomes superfast but you cant deploy any of your existing apps to it easily..
[22:28:20] <smcgowan> maxandersen: does this help:http://pastebin.test.redhat.com/42947
[22:28:31] <jpederse> maxandersen: new schemas - http://docs.jboss.org/ironjacamar/schema/
[22:28:34] <Nihility> maxandersen: domain.xml
[22:28:34] <dmlloyd> maxandersen: don't make a general issue out of specific problems
[22:28:41] <stuartdouglas> dmlloyd: sure
[22:28:46] <Nihility> maxandersen: or the datasource annotation
[22:29:14] <Nihility> maxandersen: i think you are conflating things working exactly as they did before, with not being usable
[22:29:21] <maxandersen> jpederse: smarlow: these are all stuff that needs to be added different places in the .xml file correct ? meaning not something that is easily done without custom tools ?
[22:29:56] <smcgowan> maxandersen:  yes
[22:29:57] <jpederse> maxandersen: of course - each subsystem has its own area
[22:30:03] <maxandersen> Nihility: anything that forces the common usecase to be harder than basic copy/move operations is for me considered serious adoption hinderances.
[22:30:20] <jpederse> maxandersen: so <datasources> takes care of datasource definitions
[22:30:33] <Nihility> maeste: i dont buy it
[22:30:38] <Nihility> oops bad tab complete
[22:30:38] <jpederse> maxandersen: like <resource-adapters> takes care of resource adapters
[22:30:40] <maxandersen> jpederse: yes - thus its not something that is persistable to svn for your project - that xml is part of a comple whole AS config...
[22:30:42] <Nihility> maxandersen: i dont buy it
[22:30:51] <Nihility> its just as easy to add a datasource through any of the admin interfaces
[22:30:57] <Nihility> as it is to know the ds.xml format
[22:30:59] <Nihility> and get it right
[22:31:04] <jpederse> maxandersen: gone is the day of a general -ds.xml :D
[22:31:14] <maxandersen> Nihility: today I can create a war or ear project that is selfcontained - I dont she how I can do that for AS7 as it stands today?
[22:31:31] <Nihility> maxandersen: what do you mean by self contained?
[22:31:33] <dmlloyd> depends on what you mean by "self-contianed"
[22:31:46] <dmlloyd> you still have to configure your servlet layer for example
[22:31:53] <dmlloyd> EJBs, etc.
[22:31:55] <dmlloyd> web connector
[22:32:03] <dmlloyd> security
[22:32:36] <dmlloyd> don't generalize specific issues
[22:32:43] <maxandersen> dmlloyd: my servlet layer ? not following you….majority of these things for basic webapps are/were possible to have in your war project.
[22:32:45] <dmlloyd> if you think we should support DS XML, lay out your case
[22:33:02] <dmlloyd> don't say "you cant do self-contained apps anymore" or "everything is terrible"
[22:33:06] <dmlloyd> that doesn't really help us
[22:33:14] <Nihility> maxandersen: his point is the we never had self contained
[22:33:28] <Nihility> maxandersen: unless you had the entire AS config in a deployment it was never self contained
[22:33:51] <maxandersen> Nihility: self contiined = I can have some standard set of xml/descriptor files in my svn repo that can be deployed/undeployed to my appserver  and things works.
[22:34:29] <maxandersen> jpederse: yes I know -ds.xml was/is broken - not saying to support all eleemnts in there..but at least the connection info/driver setup
[22:34:58] <Nihility> not every descriptor could be deployed
[22:35:04] <jpederse> maxandersen: that is http://docs.jboss.org/ironjacamar/schema/datasources_1_0.xsd now
[22:35:10] <Nihility> well many could be and the whole world would break
[22:35:31] <Nihility> if the goal is to have configs in an svn repo
[22:35:34] <Nihility> you can certainly do that
[22:35:38] <jpederse> maxandersen: all the resource adapter specific stuff is gone from that file now
[22:35:45] *** ccrouch has joined #jboss-as7
[22:35:45] *** ChanServ sets mode: +v ccrouch
[22:35:48] <maxandersen> Nihility: yes - but i'm not talking about *all* descriptors i'm talking about those needed for a typical war/ear app.
[22:35:59] <Nihility> ok what abou the web server thread pool
[22:36:08] <rawblem> tried to build ;) did not work
[22:36:09] <rawblem> [INFO] JBoss Application Server: Arquillian Common ....... FAILURE [56.549s]
[22:36:12] <Nihility> how do you do set that in a deployment
[22:36:12] <stuartdouglas> dmlloyd: https://github.com/stuartwdouglas/jboss-as/tree/JBAS-8920
[22:36:13] <jbossbot> jira [JBAS-8920] Deployment fails with empty classpath manifest [Open (Unresolved) Bug, Major, David Lloyd] https://issues.jboss.org/browse/JBAS-8920
[22:36:16] <dmlloyd> maxandersen: stop generalizing...
[22:37:00] <rawblem> any advice? ;)
[22:37:26] <stuartdouglas> rawblem: can you give a pastie of the full output?
[22:37:36] <rawblem> sure sec
[22:38:08] <maxandersen> Nihility: dmlloyd: i'm not trying to cover *everything* in the deployment - just trying to find what steps are needed to cover the typical scenarioes…and that for my perspective does not include the *full* setup.
[22:38:35] <rawblem> will take another 7 minutes to re-run it i think
[22:39:05] <Nihility> maxandersen: you dont seem to have a scenario though, your scenario is a just a cut and past of how things used to be done, which many of these things are unique to jboss, so they are not necessarily what people really do expect
[22:39:19] <maxandersen> so if you say ds.xml wont be supported then i'm interested in understanding how I for example could git add somethin glike http://pastebin.test.redhat.com/42947 to my project and get it added to an AS 7 server ? before I could deploy the ds.xml together with the ear or next to the war.
[22:39:19] <dmlloyd> rawblem, doubtful, most of the build time is downloading shit
[22:39:27] <dmlloyd> once that's done it's retained
[22:40:19] <maxandersen> Nihility: scenario - I want to use the defaults configured in the running server for 99% of the setup - the things I primarily would like to setup for a webapp is my war content + datasource setup.
[22:40:41] <dmlloyd> maxandersen: the same way you configure your web container or login security - you set up your server first, then you drop your app in it
[22:40:49] <maxandersen> tell me how to do that on AS 7 today ? I don't know how. (besides deploy the war ;)
[22:41:11] <Nihility> note there is also an EE datasource annotation
[22:41:22] <maxandersen> dmlloyd: setup server first has until now been unzip as/eap; bin/run.sh
[22:41:24] <Nihility> and we do have deployable jdbc drivers
[22:41:58] <Nihility> really who knew that bin/run.sh edited 50 xml files for you
[22:42:06] <maxandersen> its from that base config i'm looking and seeing what things I think we as minimum should cover from something like project examples and tools.
[22:42:10] *** ALR has quit IRC
[22:42:38] <Nihility> maxandersen: i honestly dont see what you expect to accomplish, other than whining
[22:42:55] <maxandersen> btw. I missed one part - copy the jdbc driver to as/<confg>/lib (that was/is a hack…hoping someting better exist for as7 ;)
[22:43:18] <dmlloyd> maxandersen: JDBC drivers are deployed just like anything else
[22:43:55] <jpederse> maxandersen: community docs for IronJacamar in regards to DS
[22:43:56] <maxandersen> dmlloyd:  copy hsqldb.jar to standalone/deployments ? or require running server and the profilesrevice styleapi?
[22:44:04] <jpederse> maxandersen: http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/ex_datasources.html
[22:44:05] <Nihility> we could spend 5 years
[22:44:14] <Nihility> working on little details
[22:44:19] <Nihility> color logs
[22:44:23] <Nihility> emulation layers
[22:44:24] <jpederse> maxandersen: http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.html#deployingds_descriptor
[22:44:25] <Nihility> etc etc
[22:44:58] <rawblem> http://pastebin.test.redhat.com/43040
[22:45:11] <maxandersen> Nihility: im not trying to whine - im trying to figure out how our tools can work with AS 7 ASAP and how it should do it …and I need deploy war, datasource (and possibly a driver).
[22:45:24] <dmlloyd> maxandersen: it's a standard deployment type - if it's a JDBC 4 driver you don't need to do anything else, just deploy it like any deployment
[22:45:31] <maxandersen> Nihility: colored logs were dmlloyd's baby ;)
[22:45:35] <dmlloyd> maxandersen: if it's <JDBC 4 you have to package it up
[22:45:47] <dmlloyd> but it's still pretty simple
[22:46:06] <Nihility> although i woudl love colored logs!
[22:46:08] <maxandersen> dmlloyd: ok so copy driver.jar to deployments works ? that is awesome if that works.
[22:46:46] <Nihility> maxandersen: see @DatasourceDefinition
[22:47:06] <dmlloyd> maxandersen: yeah that's it
[22:47:19] <maxandersen> Nihility: what I would love is you guys actually try use tools like eclipse, myeclipse, jboss tools even and see how many loops they actually have to go through to deploy things that works ;)
[22:47:19] <Nihility> is it working right now though?
[22:47:32] <maxandersen> dmlloyd: that sounds great (driver deployment)
[22:47:33] <dmlloyd> maxandersen: there's a problem right now if they define OSGi manifest attributes though like h2.jar does - you have to disable OSGi to work around it until we get it fixed
[22:47:54] <jpederse> dmlloyd: plus the cl issue
[22:48:29] <dmlloyd> jpederse: I think maeste has that fixed, could be wrong though
[22:48:30] <maxandersen> dmlloyd: ok - but jdbc driver deployment is then way better than previous AS's so thats excellent. (once isuses fixed ;)
[22:49:01] <Nihility> what we dont have is a ds.xml like thing
[22:49:02] <jpederse> dmlloyd: nope, see our pull request
[22:49:03] <dmlloyd> maxandersen: lots of things which define META-INF/service will be deployable in the future.  Not quite everything, but a lot of things.
[22:49:08] <maxandersen> Nihility: that just leaves the datasource config stuff which all talks ive seen/heard were "hidden" inside a bigger config...
[22:49:09] <dmlloyd> jpederse: ah
[22:49:14] <jpederse> dmlloyd: although bstansberry worked on that one
[22:49:15] <rawblem> here's the better error output
[22:49:16] <rawblem> http://pastebin.test.redhat.com/43041
[22:49:23] <Nihility> we could certainly do one
[22:49:27] * maxandersen reads jpederse link now
[22:49:36] <jpederse> dmlloyd: any hints to maeste would be great
[22:49:59] <jpederse> dmlloyd: but I think the jandex stuff is first
[22:50:03] *** jamezp has quit IRC
[22:50:04] *** asoldano_ has quit IRC
[22:50:58] *** FordPrefect has quit IRC
[22:51:14] <jpederse> once the smoke test is running most areas should be covered
[22:51:23] *** jamezp has joined #jboss-as7
[22:51:34] <maxandersen> jpederse: so reading http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.html#deployingds_descriptor im not following how that relates to datasources…i thought RAR's were different beasts ?
[22:51:38] *** ccrouch has quit IRC
[22:51:39] <dmlloyd> jpederse: I know maeste was working with stuartdouglas on that recently, so I thought it was sorted out
[22:52:09] <jpederse> maxandersen: DS deployments are specific to datasources now
[22:52:24] <jpederse> maxandersen: RAR deployments are specific to resource adapter deployments now
[22:52:31] <jpederse> dmlloyd: nope :(
[22:52:54] <jpederse> dmlloyd: there is a smoke test - although you will have to uncomment that
[22:53:26] *** wolfc has quit IRC
[22:53:34] <maxandersen> jpederse: ok - that doc talks about RAR deployments..as far as I can read… is a DS deployment then just an xml file now that you can put into deployments or something else/elswehere ?
[22:54:03] <jpederse> maxandersen: 5.2 is about RARs, 5.3 is about datasources
[22:54:14] <maxandersen> Nihility: another concern for me is that anything that depends on access to a running server makes deployment workflows tricky ;)
[22:54:18] <jpederse> maxandersen: datasources definitions goes into the <datasources> subsystem
[22:54:33] <jpederse> maxandersen: RARs into the <resource-adapters> one
[22:54:54] <jpederse> maxandersen: deployments are like everything else - domain.xml / standalone.xml
[22:55:03] <maxandersen> jpederse: so again, its about munging the standalone.xml or using the running servers http detyped model ?
[22:55:08] <jpederse> maxandersen: deployment api, cli, ...
[22:55:17] <jpederse> maxandersen: correct
[22:55:30] <jpederse> maxandersen: one file to rule them all, right ?
[22:55:32] <Nihility> we could also support an xml file im ok with that we already have to do one for annotations
[22:55:34] <maxandersen> jpederse: yes - require running server….different setup/worfklow wether standalone or domain...
[22:55:41] <Nihility> but it would be a limited construct
[22:55:44] <Nihility> and a developer only feature
[22:56:27] <jpederse> maxandersen: running or not, you will have to discuss that with bstansberry
[22:56:31] <maxandersen> jpederse: aka. moving the complexity to the user vs handled by the server ;) a design choice I guess ;)
[22:57:04] <Nihility> i dont see why its a problem to start the server to change stuff?
[22:57:08] <maxandersen> jpederse: i.e. what the doc shows in 5.3 for ironjacamar looks great…but thats not what is in AS 7 afaik.
[22:57:12] <Nihility> just that its a different worlflow
[22:57:21] <maxandersen> Nihility: the server might be remote
[22:57:24] <jpederse> maxandersen: it is the same - AS 7 is just sugar
[22:57:40] <Nihility> maxandersen: you can connect to a remote server as well
[22:57:44] <maxandersen> jpederse: eh? you just said stuff had to go into the xml directl?
[22:57:57] <jpederse> maxandersen: into the correct subsystem, yes
[22:58:04] <jpederse> maxandersen: XSD is the same
[22:58:23] <maxandersen> Nihility: yes but were today we got *one* workflow (copy the configuration in the project to the server indepdnet on it running or not) it will have to depend on wether its local, remote, running or not.
[22:58:50] <maxandersen> jpederse: yes so it is *not* the same from a workflow perspective - it is from the xml syntax persisted sure ;)
[22:59:29] <jpederse> maxandersen: workflow is not the same, correct
[22:59:40] <dmlloyd> maxandersen: you can use the XML on a stopped server, or you can use the API on a running server
[22:59:47] <maxandersen> Nihility: what im saying is that tooling (and users) need to do more to do what I call "basic" work when it comes to  AS 7
[23:00:37] <maxandersen> Nihility: but I completely understand how this makes it simpler for the runtime side ;)
[23:01:03] <Nihility> well you can completely change the configuraiton of a runtime server
[23:01:13] <Nihility> so i wouldnt call it basic
[23:01:28] <Nihility> you could for example
[23:01:34] <Nihility> detect if AS is properly configured
[23:01:35] <Nihility> for tooling
[23:01:37] <maxandersen> Nihility: I don't need to change the configuration of a runtime server - thats outside what I call basic ;)
[23:02:21] <dmlloyd> it's pretty simple
[23:02:28] <dmlloyd> the XML is a snapshot of a complete configuration
[23:02:40] <dmlloyd> you either put stuff in deployments or in the XML
[23:02:59] <dmlloyd> if you operate on a running server you use the API instead of the XML
[23:03:06] <maxandersen> dmlloyd: what i'm seeing right now is that we might need to support 4 workflows from tooling side - nonrunning/standalone, nonrunning/domain, running/standalone, runnin/domain… since the deployment and confgiruation changes slightly enough to be different.
[23:03:08] <dmlloyd> or you write to the XML and reload the server, perhaps
[23:03:19] <Nihility> why do you need to support multiple workflows?
[23:03:40] <dmlloyd> for tools support, I'd say just rewrite the XML
[23:03:46] <Nihility> do you really need to deploy to a server thats not running?
[23:03:47] <dmlloyd> because you can just force a server reload which takes like 200ms
[23:04:01] <dmlloyd> now you only have one workflow
[23:04:04] <dmlloyd> congrats
[23:04:34] <dmlloyd> I'm not really convinced it makes sense to integrate tools with a domain
[23:04:38] <dmlloyd> but that's up to you of course
[23:04:48] <dmlloyd> if you like extra work
[23:04:49] <Nihility> i could see one worfkflow
[23:04:53] <maxandersen> dmlloyd: well the xml is different from standalone to domain…at least different enough to be something that needs testing/qa enough to be considred "different" in my world view ;)
[23:04:54] <Nihility> where you just require the server be up
[23:04:59] <Nihility> you alter the configs via the api
[23:05:02] <Nihility> you deploy stuff
[23:05:37] <maxandersen> dmlloyd: for the user it will feel like one workflow though.
[23:05:41] <rawblem> stuartdouglas, http://pastebin.test.redhat.com/43041  is the build error paste
[23:05:42] <Nihility> if its not up you start or tell the user to start there server
[23:06:58] <bstansberry> rawblem: this was my deployment-scanner branch? or master
[23:07:16] <maxandersen> just to be clear, i'm looking very much forward to get better remote api accesss…that will make things much easier in areas that were clunky before.
[23:07:36] <maxandersen> better remote as in the diff from as6 to as7 ;)
[23:07:45] <Nihility> you could do something like
[23:07:48] <Nihility> before deploying
[23:07:53] <Nihility> validate the server is properly configured
[23:07:55] <Nihility> correct it
[23:07:56] <maxandersen> im still a bit walking in the dark on *what* the api actually looks like.
[23:09:07] <maxandersen> Nihility: be aware that in many cases the tools can't really "see" what a correct configuration is…we actuallly have very little data to go for…which is why I appreciate "self-containment" if you understand that ?
[23:09:21] <Nihility> well i mean ok
[23:09:28] <Nihility> lets say you want a ds.xml
[23:09:30] <rawblem> bstansberry, just did what the wiki told me ;)  git clone git at github dot com:[your user]/jboss-as.git
[23:09:32] <Nihility> that you would normally generate
[23:09:40] <rawblem> bstansberry, no idea how to check out the deployment branch
[23:09:44] <Nihility> you can check is there a datasource, called blah, nope make one
[23:10:35] <rawblem> yeah i haven't seen the api at all
[23:10:35] <Nihility> but like i said i can see supporting something like ds.xml
[23:11:12] <rawblem> i also think it'd be nice if there was an api where i could get a list of all deployments on the server and their states...
[23:11:17] <rawblem> and maybe force one to redeploy
[23:11:30] <Nihility> yep
[23:11:33] <Nihility> youll get that
[23:11:34] <dmlloyd> there is one
[23:11:36] <rawblem> good good
[23:12:15] <rawblem> bstansberry,  how do i check out the deployment branch specifically?
[23:12:15] <Nihility> bstansberry had an interesting idea, to have a quick way to bootstrap the server in management only mode
[23:12:37] <bstansberry> it might be straightforward and is something I want to do
[23:12:49] <bstansberry> if it's not too ugly
[23:12:51] <Nihility> so that would allow you to do "offline" editing
[23:12:53] <rawblem> my unbuildable version seems to be from git clone git at github dot com:[your user]/jboss-as.git
[23:13:00] <rawblem> not sure why the build fails
[23:13:06] <Nihility> rawblem: try doing -Dmaven.test.skip
[23:13:13] <Nihility> probably a win32 bug in the arq test
[23:13:19] <Nihility> assuming you are on windows
[23:13:24] <rawblem> i'm on fedora 12
[23:13:30] <rawblem> (yeah yeah i know its super old)
[23:13:33] <Nihility> ah interesting
[23:14:10] <rawblem> Nihility,  my build output is http://pastebin.test.redhat.com/43041   if you wanted to glance ;)
[23:14:27] <rawblem> running now without tests
[23:14:28] <rawblem> just to check
[23:14:48] <bstansberry> what's your github account?
[23:14:55] <rawblem> robstryker
[23:15:10] <Nihility> [ERROR] /home/rob/code/jboss/as7/jboss-as/arquillian/common/src/main/java/org/jboss/as/arquillian/container/JBossASDeploymentPackager.java:[59,16] inconvertible types
[23:15:10] <Nihility> [ERROR] found   : org.jboss.shrinkwrap.api.Archive<capture#653 of ?>
[23:15:11] <Nihility> [ERROR] required: org.jboss.shrinkwrap.api.spec.WebArchive
[23:15:21] <Nihility> interesting
[23:15:26] <Nihility> which tree did you clone
[23:15:38] <jpederse> looks like an old OpenJDK bug
[23:15:49] <Nihility> yeah that makes sense
[23:15:52] <rawblem> [rob@localhost jboss-as]$ java -version
[23:15:52] <rawblem> java version "1.6.0_14"
[23:15:52] <rawblem> Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
[23:15:52] <rawblem> Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)
[23:16:06] <Nihility> _14 is pretty old
[23:16:25] <maxandersen> Nihility: ok so sure - checking datasource names availabilty we could do...
[23:16:27] <Nihility> there was some strange generics bugs in javac for a few jdk releases
[23:16:30] <rawblem> git clone git at github dot com:[your user]/jboss-as.git
[23:16:54] <Nihility> maxandersen: but yeah ill add the xml datasource thing to the list, and we can try and make it close to ds.xml
[23:17:12] <Nihility> but it would be a developer only feature (an admin might disable it)
[23:17:23] <Nihility> the ds.xml though has some pretty bad stuff
[23:17:33] <Nihility> that we dont want to carry over
[23:17:34] <jpederse> don't I get a vote ?
[23:17:41] *** opalka has quit IRC
[23:17:53] <Nihility> jpederse: of course
[23:18:09] <jpederse> veto
[23:18:16] <Nihility> jpederse: my thinking is just an xml form hte DataSourceDefinition thing
[23:18:20] <maxandersen> Nihility: my main concern is the "selfcontainment" and not being *forced* to rely on running servers for the "basic" stuff.
[23:18:26] <jpederse> Nihility: that in 7.0 ?
[23:18:43] <maxandersen> Nihility: ironjacamar already do it according to the docs you sent ?
[23:18:59] <jpederse> Nihility: because I don't have it on my list - maybe maeste do
[23:19:06] <jpederse> maxandersen: not the annotation
[23:19:20] * maxandersen is confused ;)
[23:19:20] <Nihility> DataSourceDefinition, i think its web profile right?
[23:19:39] <jpederse> smcgowan: ^ ?
[23:19:53] <Nihility> ill have to check
[23:19:59] <jpederse> yeah, me too ;)
[23:20:04] <Nihility> maybes its jca only
[23:20:16] <jpederse> Nihility: web profile doesn't have jca
[23:20:21] <Nihility> right
[23:20:23] <maxandersen> DataSourceDefintion as in @DataSourceDefinition ?
[23:20:35] <Nihility> im saying "maybe im wrong and its not required because its jca specific"
[23:20:45] <jpederse> ah, got ya'
[23:20:56] <Nihility> maxandersen: yes
[23:21:12] <Nihility> maxandersen: ee6 annotation to create data sources in a deployment dynamically
[23:21:48] <jpederse> :p
[23:22:39] <maxandersen> yeah - having annotation support for it would fix the "selfcontainment"  - but I'm not seeing such annotations being used alot since they would be hardcoded compiled values for something very deployment specific (which xml/text formats would be better suited for ?)
[23:22:52] * maxandersen might remember @datasourcedefintion content wrong...
[23:23:03] <jpederse> password in java code ? yuck
[23:23:16] <maxandersen> jpederse: isnt that what the annotion is about?
[23:23:24] <jpederse> password ?
[23:23:30] <jpederse> seriously ?
[23:23:34] <Nihility> hahahaha
[23:23:41] <Nihility> yeah i thought you would get a kick out of that
[23:23:44] <smcgowan> jpederse:  yes DataSourceDefinition in Web profile
[23:23:58] * jpederse adds that to JCA TODO list
[23:24:32] <Nihility> got to run bbl
[23:24:43] *** smcgowan has quit IRC
[23:24:44] <maxandersen> jpederse: so if you dont like that, why weren't you liking the idea of being able to deploy ds.xml's instead of requiring changing the domain/standalone.xml ? (just a question about resources to do the work ? :)
[23:24:56] * maxandersen just trying to understand the "veto" :)
[23:24:57] *** maeste has quit IRC
[23:25:48] <jpederse> maxandersen: no, in AS 7 everything has to go through the deployment api imho
[23:25:54] <jpederse> ~bstansberry++
[23:26:14] <maxandersen> jpederse: *sigh*....
[23:26:36] <maxandersen> jpederse: and isn't that exactly what happens when you use deployments folder ?
[23:26:50] <jpederse> maxandersen: standalone IronJacamar is different
[23:26:55] <maxandersen> it picks up the deployment and hand it to the deployment api…thats the whole beauty ;)
[23:27:06] <rawblem> #
[23:27:06] <rawblem> #
[23:27:06] <rawblem> Running org.jboss.as.controller.BaseModelControllerUnitTestCase
[23:27:06] <rawblem> #
[23:27:06] <rawblem> Mar 5, 2011 5:47:35 AM org.jboss.as.controller.BasicModelController execute
[23:27:06] <rawblem> #
[23:27:08] <rawblem> ERROR: operation ("evil") failed - address: ([])
[23:27:10] <rawblem> #
[23:27:11] <maxandersen> jpederse: im talkinga bout as7's deployment folder.
[23:27:12] <rawblem> java.lang.RuntimeException: this handler is evil
[23:27:14] <rawblem> i'm sorry didnt mean to paste that
[23:27:27] <rawblem> although that does seem like a strange error message in build ;)
[23:27:43] <jpederse> maxandersen: I'm ok with the JDBC driver - not the actiual definition - in deployments/
[23:27:57] <Nihility> maxandersen: the problem is we have admins that want to have control over the admin stuff
[23:28:01] <maxandersen> jpederse: never ever ?
[23:28:21] <Nihility> maxandersen: so theres a lot of work on separating the notion of server configured resources, and stuff a developer provides
[23:28:26] <bstansberry> rawblem: lol. it's a unit test forcing an error that gets logged
[23:28:28] <jpederse> maxandersen: like Nihility said - maybe in developer mode - if it is general across the server setup
[23:28:33] <maxandersen> Nihility: yeah sure I can see how datasources are in a grey zone in that respect ;)
[23:28:56] <Nihility> maxandersen: so like all things like pools and so on are supposed to be in one spot for the admin
[23:29:06] <Nihility> maxandersen: unlike today where they have no idea what their server is doing
[23:29:18] <maxandersen> okey so let me try reset this and maybe ask the question differently.
[23:29:33] <Nihility> maxandersen: but yeah i undersstand your point though that it was handy for developers
[23:29:39] <Nihility> and we already have to support that annotation
[23:29:52] <Nihility> so its already a "hole" in the model per se
[23:30:24] <maxandersen> lets say I saved the datasource defintion part in a ds.xml file in my svn; is there a way for me (as a tooling or user) to do something like "jbosscli deploy ds.xml" …which would go through the admin interface yada yada ?
[23:31:19] <jpederse> but having a "activate ds jdbc:blah: user password  ..." in the cli would be nice too
[23:31:23] <maxandersen> I assume that would be the same JON or other management tools would use …. im just trying to find a canoncial way to store these "configuration settings" without storing the "whole" model ?
[23:31:47] <maxandersen> before for datasources that were ds.xml
[23:32:05] <Nihility> maxandersen: yes, you can execute a command that creates a datasource with a bunch of sepcified values
[23:32:15] <Nihility> maxandersen: without having to understand the full config
[23:32:19] <jpederse> it is "just" a matter of adding higher level commands to the cli / api
[23:32:20] <maxandersen> i'm eyeing that I/we could basically do this for subsets of the standalone xml for as7 ..
[23:32:40] <Nihility> in addition to doing it over the cli
[23:32:48] <Nihility> you can do it with the java api and with the http json api
[23:33:30] <Nihility> and if bstansberry does that management mode capability
[23:33:36] <maxandersen> Nihility: jpederse: yes - but what i'm asking for is if there is a sense in allowing something that would basically use the xml syntax as the "parameters" to the calls or you would want users/tools to do the "dissasembly" into smaller bits and call the lower/higher level operations ?
[23:33:36] <Nihility> you could do this without starting the full server
[23:34:12] <maxandersen> or if not the xml format some other "non-binary" form that could be "stable".
[23:34:18] <maxandersen> am I making sense ? :)
[23:34:49] <jpederse> maxandersen: that is a question for Brian, Emanuel and Alexey - drive into the office on Monday ;)
[23:35:22] <maxandersen> jpederse: well…i'm trying to get emmanuel to do the exploded deployment first ;)
[23:35:51] <Nihility> maxandersen: the cli will have a one-shot create-datasource command line
[23:35:57] <Nihility> that would do the more verbose option
[23:36:07] <Nihility> but its not any more complex than an xml blob
[23:36:12] <bstansberry> +1
[23:37:24] <maxandersen> Nihility: yes but what i'm looking/asking for is some "blob" that can be used both from the tooling directly to the AS and via the CLI …so users wouldn't have to have two "forms" ? (this is not specific to ds - but ds's is the major usecase right now I see ;)
[23:37:35] *** mbg is now known as mbg|away
[23:37:41] <dmlloyd> maxandersen: just always modify the XML
[23:37:45] <dmlloyd> and do a server reload
[23:38:08] <dmlloyd> if one code path is more important than allowing incremental runtime changes
[23:38:21] <dmlloyd> server reload takes like 200ms out of the box
[23:38:29] <dmlloyd> that's reloading everything
[23:39:33] <bstansberry> to clarify what's he's talking about -- it doesn't restart the vm, just stops the root service, resulting in everything unloading, and then starting it again
[23:39:39] <maxandersen> dmlloyd: not talking about toolings challenges now - talking about  how for users it would be great to do "cli add datasource <blob>" and that same <blob> could be used by the tools…not just jboss tools.
[23:40:34] <bstansberry> {
[23:40:35] <bstansberry>     "connection-url" => "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1",
[23:40:35] <bstansberry>     "driver-class" => "org.h2.Driver",
[23:40:35] <bstansberry>     "jndi-name" => "java:/H2DS",
[23:40:36] <bstansberry>     "module" => "org.h2.Driver#1.2",
[23:40:36] <maxandersen> bstansberry: got it.
[23:40:36] <bstansberry>     "pool-name" => "H2DS",
[23:40:37] <bstansberry>     "use-java-context" => true,
[23:40:37] <bstansberry>     "enabled" => true,
[23:40:37] <bstansberry>     "pool-prefill" => true,
[23:40:38] <bstansberry>     "pool-use-strict-min" => false,
[23:40:38] <bstansberry>     "user-name" => "sa",
[23:40:38] <bstansberry>     "password" => "sa",
[23:40:39] <bstansberry>     "share-prepared-statements" => false,
[23:40:39] <bstansberry>     "set-tx-query-timeout" => false,
[23:40:39] <bstansberry>     "background-validation" => false,
[23:40:40] <bstansberry>     "use-fast-fail" => false,
[23:40:40] <bstansberry>     "validate-on-match" => false
[23:40:41] <bstansberry> }
[23:40:45] <dmlloyd> ^^
[23:40:48] <maxandersen> now we are talking ;)
[23:40:53] <dmlloyd> that's what it is
[23:41:21] <maxandersen> great…
[23:43:21] <dmlloyd> though I think driver-class and module should be collapsed down into "driver" => "org.h2.Driver#1.2"
[23:43:32] <dmlloyd> since org.h2.Driver had better not be the module name...
[23:43:33] <maxandersen> whats the #1.2 ?
[23:43:38] <dmlloyd> version, presumably
[23:43:42] <dmlloyd> major/minor
[23:43:46] <dmlloyd> so you can have more than one deployed
[23:44:13] <maxandersen> okey - so yes something like that jsonish blob … would that be a "stable" <blob-syntax> ?
[23:45:09] <jpederse> correct
[23:45:55] <dmlloyd> probably not in these pre-beta days but once we get towards CR I'd call it stable
[23:46:50] <maxandersen> dmlloyd: sure - but as a principle it would be ok then...
[23:49:40] *** jpederse_ has joined #jboss-as7
[23:49:46] <maxandersen> Nihility: btw. not sure if you saw that earlier…but I got AS7 deployment working on existing jbosstools/JBDS versions. without custom code now that there is the "file deploy api"…..nice speed ;)
[23:52:41] *** jpederse has quit IRC
[23:52:58] *** jpederse_ has quit IRC
[23:53:26] <bstansberry> maxandersen: yes, the syntax above will be stable
[23:55:09] <bstansberry> there is also a way to represent the same notions in JSON syntax and that will be stable as well

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