[00:01:25] *** babo has quit IRC [00:03:32] *** bfitzpat has quit IRC [00:42:59] *** lanceball has quit IRC [01:36:27] *** kcbabo has joined #switchyard [02:36:07] *** rcernich_away has quit IRC [02:49:32] *** kcbabo has quit IRC [03:02:48] *** errantepiphany has joined #switchyard [03:06:18] *** aslak has quit IRC [03:20:24] *** ldimaggi has joined #switchyard [03:46:45] *** errantepiphany has left #switchyard [05:55:22] *** ldimaggi has quit IRC [07:32:42] *** magesh has joined #switchyard [07:36:56] *** wyer has joined #switchyard [08:52:43] *** rbalent has joined #switchyard [08:52:44] *** rbalent has joined #switchyard [08:53:06] *** javahorn has joined #switchyard [10:21:49] *** aslak has joined #switchyard [10:21:49] *** aslak has quit IRC [10:21:49] *** aslak has joined #switchyard [12:09:15] *** wyer has quit IRC [12:37:30] *** kcbabo has joined #switchyard [13:10:09] <magesh> kcbabo: Hi Keith [13:10:19] <kcbabo> magesh: hey magesh [13:10:45] <magesh> kcbabo: Did you see the WS issue that I raised yesterday? [13:11:05] <kcbabo> magesh: re: the threading problem? [13:11:21] <magesh> kcbabo: Yes [13:12:01] <kcbabo> magesh: I saw mention of the WS issue, but not sure I saw an actual JIRA [13:12:10] <kcbabo> magesh: is there one? I probably just missed it. [13:12:28] <magesh> kcbabo: Yes linked to that one [13:12:49] <kcbabo> magesh: so this was an update on our JIRA - I don't think I got a notification [13:13:10] <magesh> kcbabo: :) https://issues.jboss.org/browse/JBWS-3325 [13:13:36] <magesh> kcbabo: I spoke with Alessio and he accepted it for 4.0.0 release of theirs [13:14:26] <kcbabo> magesh: great ... [13:14:40] <magesh> kcbabo: I have one more to go [13:15:55] <magesh> kcbabo: SWITCHYARD-290, will see if I can give a quick solution to that on Monday [13:16:01] <kcbabo> magesh: can we work around this by providing our own Executor? [13:16:31] <magesh> kcbabo: No the executor gets ignored if set on the Endpoint as the server is already in STATE=started [13:19:37] *** ldimaggi has joined #switchyard [13:20:49] <kcbabo> magesh: one more silly question about the WS stuff [13:21:11] <kcbabo> magesh: so when we call Endpoint.create(), the server is started as part of that? [13:21:51] <magesh> kcbabo: One sec [13:22:12] <kcbabo> magesh: just wondering if there is a window between create() and publish() where we can attach the executor [13:22:44] <magesh> kcbabo: It is basically in publish, when the ports are alloted [13:23:10] <magesh> kcbabo: Just then the httpserver addon will create a server and start it before creating a context for that url [13:23:29] <kcbabo> magesh: so can we attach an executor between create and publish? [13:24:06] <magesh> kcbabo: It literally ignores the Executor set on the endpoint, as that is not what is used by the server [13:24:25] <kcbabo> magesh: bleh ? that sux [13:24:38] <magesh> kcbabo: endpoint is just a Bean :) [13:24:45] <magesh> kcbabo: Placeholder [13:25:32] <magesh> kcbabo: I given them the fix, but I feel they can get the executor from endpoints too. But that is upto their implementation [13:26:20] <kcbabo> magesh: seems like we are blazing the trail here with this Endpoint.publish API in our stack [13:28:15] <magesh> kcbabo: Alessio kinda mentioned that there were some more issues with that [13:28:50] <magesh> kcbabo: When we started it [14:06:25] *** magesh has left #switchyard [14:13:35] *** aslak has quit IRC [14:31:34] *** aamonten has joined #switchyard [14:53:46] *** antollinim has joined #switchyard [15:06:13] *** wyer has joined #switchyard [15:19:28] *** bfitzpat has joined #switchyard [15:47:46] *** jgraham_ has joined #switchyard [15:51:11] *** lanceball has joined #switchyard [15:53:33] *** wyer has quit IRC [16:05:54] *** GitHub4 has joined #switchyard [16:05:54] <GitHub4> [core] kcbabo pushed 1 new commit to master: http://bit.ly/o6pYbh [16:05:54] <GitHub4> [core/master] SWITCHYARD-296: NPE when promoted service name is different from the service name itself - David Ward [16:05:54] *** GitHub4 has left #switchyard [16:19:07] *** rcernich has joined #switchyard [16:46:59] *** errantepiphany has joined #switchyard [17:09:13] *** ldimaggi has quit IRC [17:32:57] *** rbalent has quit IRC [17:38:57] *** rcernich is now known as rcernich_brb [17:46:45] *** kcbabo is now known as babo_afk [18:04:09] *** rcernich_brb is now known as rcernich [18:11:11] *** ldimaggi has joined #switchyard [19:03:50] *** babo_afk is now known as kcbabo [19:18:15] *** jgraham_ has quit IRC [19:26:49] <rcernich> kcbabo: hey keith [19:26:54] <kcbabo> rcernich: hey rob [19:27:15] <rcernich> kcbabo: i'm going to start creating some jiras for this management/admin stuff [19:27:30] <rcernich> kcbabo: any preference as to which jira component i use? [19:28:06] <rcernich> kcbabo: i was thinking deployment or tooling [19:28:16] <rcernich> kcbabo: possibly configuration [19:28:58] <kcbabo> rcernich: I just created 'admin' and 'console' components in JIRA [19:29:07] <kcbabo> rcernich: feel free to use the appropriate one [19:29:09] <rcernich> kcbabo: bueno! [19:29:18] <rcernich> kcbabo: thanks! [19:29:28] <kcbabo> rcernich: I'm actually thinking about the admin stuff right now - should be able to post some rough thoughts in about an hour [19:29:37] <rcernich> kcbabo: cool [19:40:13] <rcernich> kcbabo: fyi, i reached out to heiko to get his opinion regarding the use of gwt's json support with javascript overlays vs using autobeans for representing/constructing data/model objects [19:40:33] <kcbabo> rcernich: he's the person to ask [19:43:25] <kcbabo> rcernich: heh ? for a second there I thought you were gonna tell me what he said ;-0 [19:43:32] <kcbabo> whoops ? emoticon slip [19:43:34] <kcbabo> ;-) [19:43:40] <rcernich> kcbabo: :) [19:43:44] <kcbabo> rcernich: I take it you haven't heard back yet? [19:44:03] <rcernich> kcbabo: no. needed to send a follow up. [19:44:20] <rcernich> kcbabo: i was mostly curious as to the direction [19:44:53] <rcernich> kcbabo: it seems like it's pretty easy to create objects based on json using gwt's jsni [19:45:28] <rcernich> kcbabo: json can be represented directly as js and the implementation simply delegates to the js [19:45:50] <kcbabo> rcernich: that sounds like a good thing [19:46:31] <rcernich> kcbabo: saves having to invoke a bunch of setters to initialize the objects [19:46:49] <kcbabo> rcernich: yep [19:46:55] <rcernich> kcbabo: but i wanted to make sure there wasn't some underlying reason why i shouldn't go that route [19:47:06] <kcbabo> rcernich: that's one of the few things I know about JSON and JS - eval makes things pretty easy [19:47:58] <rcernich> kcbabo: yeah, and gwt allows you to create a typesafe implementation to the underlying js object [19:48:13] <rcernich> kcbabo: of course, if the js object isn't what you think it is, all bets are off, but... [20:02:29] *** kcbabo has quit IRC [20:14:58] *** kcbabo has joined #switchyard [20:15:21] <kcbabo> ok, adium crashing is really starting to anger me [20:21:14] <rcernich> kcbabo: can i ask you git question? [20:21:30] <kcbabo> rcernich: sure, does it have to do with processing my pull request? ;-) [20:21:39] <rcernich> kcbabo: not exactly [20:21:48] <kcbabo> rcernich: just kidding, what's up? [20:21:54] <rcernich> kcbabo: has more to do with me being somewhat ignorant [20:22:02] <rcernich> kcbabo: or mostly ignorant [20:22:22] <rcernich> kcbabo: how do i sync my repo with the upstream repo? [20:22:41] <rcernich> kcbabo: do i fetch, rebase upstream/master, then push to my repo? [20:23:11] <rcernich> kcbabo: my local repo shows a bunch of commits after rebasing to upstream/master [20:23:34] <kcbabo> rcernich: which of "my repo" are you referring to? [20:23:42] <rcernich> kcbabo: i wouldn't be surprised if i've completely fubar'd this again [20:23:44] <kcbabo> rcernich: there's your remote repository hosted on github [20:23:50] <kcbabo> rcernich: and your local repo on your machine [20:24:04] <rcernich> kcbabo: my local repo shows a bunch of commits [20:24:17] <kcbabo> rcernich: do you want those commits? [20:24:37] <rcernich> kcbabo: my remote repo shows the last commit being update to 0.2.0 [20:24:43] <rcernich> kcbabo: i assume so [20:24:48] <kcbabo> rcernich: ah, ok [20:24:56] <kcbabo> rcernich: so you need to push to your remote repo [20:25:01] <rcernich> kcbabo: don't i want my remote repo to be in sync with the upstream repo? [20:25:09] <kcbabo> rcernich: think of git as a completely distributed VCS [20:25:21] <kcbabo> rcernich: so everywhere you push or pull to is a full copy of the repository [20:25:22] <rcernich> kcbabo: yeah, i'm having a hard time with that [20:25:35] <kcbabo> rcernich: so the one on your hard disk is a full repository [20:25:41] <rcernich> kcbabo: so, let me make sure i've got everything configured correctly [20:25:44] <kcbabo> rcernich: the one in your github account is a full repository [20:25:53] <rcernich> kcbabo: my local repo has two remotes defined [20:25:53] <kcbabo> rcernich: and the one in upstream (jboss-switchyard) is a full repository [20:26:09] <kcbabo> rcernich: so the key is to keep these repositories synchronizes [20:26:10] <kcbabo> d [20:26:24] <kcbabo> rcernich: so what you've been doing is pulling updates from master into your local repo, which is great [20:26:26] <rcernich> kcbabo: my remote (origin) and the switchyard proper remote (upstream) [20:26:43] <kcbabo> rcernich: now what you want to do is push to your remote repository to bring the upstream changes into that repo [20:26:53] <rcernich> kcbabo: i think so. i've been fetching from upstream, then rebasing upstream/master [20:27:08] <rcernich> kcbabo: ok. wasn't sure about that bit [20:27:36] <rcernich> kcbabo: so, to keep my remote repo in sync with upstream, i need to merge the upstream changes into my local repo, then push those to my reomote repo [20:27:44] <kcbabo> rcernich: git push origin master [20:27:44] <kcbabo> rcernich: correct [20:27:56] <rcernich> kcbabo: surprisingly, that makes sense to me [20:28:05] <kcbabo> rcernich: git has got you! [20:28:42] <rcernich> kcbabo: and i don't need to worry about my remote repo's id's matching the upstream repo's id's [20:29:09] <rcernich> kcbabo: because when a pull request is processed, my changes are merged into the upstream [20:29:40] <rcernich> kcbabo: i.e. the only files that should be different are those that i've changed (unless i didn't rebase prior to issuing the request) [20:29:50] <rcernich> kcbabo: sorry for being so dense on this [20:30:25] <kcbabo> rcernich: not sure I followed you there, but the beautiful thing about git is that the commits are indexed by a digest of the repo [20:30:38] <kcbabo> rcernich: so they are the same no matter where they go [20:30:43] <rcernich> kcbabo: ahh [20:31:05] <kcbabo> rcernich: I should say that's *one* beautiful thing about git [20:31:13] <rcernich> kcbabo: so pushing the commits i pulled from upstream will cause my repo to be exactly the same as upstream? [20:31:24] <kcbabo> rcernich: precisely! [20:31:35] <kcbabo> rcernich: which is exactly the same as your local repo [20:31:42] <rcernich> kcbabo: cool (that was tough. thanks for being patient) [20:32:09] <rcernich> kcbabo: it feels odd pushing changes that you didn't make [20:32:16] <rcernich> kcbabo: but at least i understand it now [20:32:27] <rcernich> kcbabo: while we're on the topic of git... [20:32:32] <rcernich> kcbabo: when processing a pull request [20:32:52] <rcernich> kcbabo: what is the preferred method for synchronizing my local repo? [20:33:03] <rcernich> kcbabo: git fetch, followed by git rebase? [20:33:40] <rcernich> kcbabo: or git pull --rebase [20:33:46] <kcbabo> rcernich: I use a pull and rebase in one step [20:33:49] <kcbabo> rcernich: yep, that's the one [20:34:09] <rcernich> kcbabo: cool [20:34:28] <kcbabo> rcernich: sometimes after doing that, git status will report that you are 'n' commits ahead of remote [20:34:39] <kcbabo> rcernich: just run git fetch and all will be fixed [20:34:39] <rcernich> kcbabo: and i don't need to specify any specs with that (e.g. all that refs/whatever stuff) [20:34:54] <rcernich> kcbabo: ahh, that's what it's reporting on my local repo right now [20:35:12] <kcbabo> rcernich: just git pull ?rebase upstream master [20:35:20] <rcernich> kcbabo: cool [20:35:20] <kcbabo> rcernich: right, but that's something else [20:35:28] <rcernich> kcbabo: right, we discussed that [20:35:36] <kcbabo> rcernich: you really are ahead of your remote repo if you haven't pushed to it [20:35:43] <rcernich> kcbabo: because i've rebased upstream, but haven't pushed [20:35:52] <rcernich> kcbabo: whew... [20:35:54] <kcbabo> rcernich: the thing I explained about git fetch is when dealing with the upstream master [20:36:09] <kcbabo> rcernich: anyway, I think you've got it [20:36:15] <rcernich> kcbabo: i'm assuming that's because the local repo doesn't have all the details about the remote [20:36:37] <kcbabo> rcernich: depends on the case we are talking about [20:37:13] <kcbabo> rcernich: I'm assuming you have two paths locally, one is a clone of your forked remote and the other is a clone of the upstream master repo [20:37:15] <rcernich> kcbabo: for the pull request case: git fetch pulls down the latest details about the remote repo [20:37:20] <rcernich> kcbabo: absolutely [20:37:23] <kcbabo> rcernich: correct [20:37:36] <rcernich> kcbabo: it's starting to gel [20:37:43] <rcernich> kcbabo: thanks for your patience [20:37:53] <kcbabo> rcernich: we've all been there before [20:38:04] <kcbabo> rcernich: in fact, you're picking it up a lot faster than I did [20:38:27] <kcbabo> rcernich: you should have seen us banging about six months ago ? absolutely clueless [20:39:03] <rcernich> kcbabo: well, i have the advantage of your experience:D [20:39:10] <aamonten> kcbabo: rcernich but the you get addicted, add my job we still use svn and it sucks [20:39:26] <kcbabo> aamonten: yeah, that sux :-) [20:39:38] <kcbabo> aamonten: better than CVS though [20:40:03] <rcernich> kcbabo, aamonten: and definitely better than sourcesafe [20:40:10] <aamonten> kcbabo: Im working on spring component, but if you have something urgent let me know [20:40:10] <rcernich> or clearcase [20:40:14] <kcbabo> rcernich: hush your mouth! [20:40:15] <aamonten> aamonten: harvest? [20:41:03] <kcbabo> aamonten: I'm getting read to file another round of JIRAs here based on some scratch notes I have laying around. I'll definitely hit you up once I have them filed. [20:41:47] <aamonten> aamonten: great entertainment for next week [20:42:14] <rcernich> kcbabo: one last question (i promise) [20:42:39] <rcernich> kcbabo: do you recommend doing work on local branches, then merging to master, then pushing to remote? [20:42:51] <kcbabo> rcernich: no [20:43:17] <kcbabo> rcernich: I find it works best to create a 'topic' branch for each JIRA locally [20:43:29] <kcbabo> rcernich: I then push that to my remote repo [20:43:43] <kcbabo> rcernich: and I issue the pull request from that remote branch [20:43:54] <kcbabo> rcernich: easier to separate out individual pull requests [20:44:31] <rcernich> kcbabo: ok, i'll try to figure that out, before asking more questions;) [20:44:43] <aamonten> rcernich: I only do pull from upstream on master [20:45:07] <rcernich> aamonten: ok [20:45:29] <kcbabo> rcernich: here's the quick and dirty [20:45:41] <kcbabo> git checkout -b SWITCHYAR-999 [20:45:49] <kcbabo> (bang out changes) [20:45:53] <kcbabo> git add . [20:46:01] <kcbabo> git commit -m "SWITCHYARD-999 really cool stuff" [20:46:29] <kcbabo> git rebase upstream master (this makes sure you are on top of current upstream master) [20:46:39] <aamonten> kcbabo: I want that issue :) [20:46:59] <kcbabo> ^ sorry that should have been git pull ?rebase upstream master [20:47:16] <kcbabo> git push origin SWITCHYARD-999 [20:47:28] <kcbabo> rcernich: after that, you have the topic branch in your remote repo [20:47:44] <kcbabo> rcernich: so then go into your github page and select the repo [20:47:47] <aamonten> before push I normally do a git rebase -i master [20:47:56] <kcbabo> rcernich: then switch to the appropriate branch [20:48:21] <kcbabo> rcernich: and select Pull Request from the top menu thingy [20:48:26] <kcbabo> rcernich: and that should be it [20:48:41] <rcernich> kcbabo: ahh, so creating a branch on the remote repo is the same as pushing changes (i.e. everything gets to remote via push) [20:48:54] <kcbabo> aamonten: interactive rebase should only be necessary if you need to squash commits - but definitely agree it's best to use that if you have that need [20:49:00] <kcbabo> rcernich: yep [20:49:36] <rcernich> kcbabo: is a "topic" branch different from any other branch? [20:50:13] <rcernich> kcbabo: i.e. is topic a git term or just a term for a branch dedicated to a specific "topic" [20:51:06] <kcbabo> rcernich: it's just a term used to describe a branch that has a specific purpose [20:51:23] <kcbabo> rcernich: nothing specific to git [20:51:25] <rcernich> kcbabo: cool [20:51:41] <rcernich> kcbabo: thanks for all the help [20:51:59] <rcernich> kcbabo: especially on a friday! [20:53:49] <kcbabo> rcernich: my pleasure [21:01:30] *** kcbabo is now known as babo_brb [21:22:46] *** rcernich is now known as rcernich_brb [21:43:25] *** rcernich_brb is now known as rcernich [21:56:36] *** aamonten has quit IRC [22:10:26] *** babo_brb is now known as kcbabo [22:37:21] *** errantepiphany has left #switchyard [22:50:54] *** ldimaggi has quit IRC [23:46:53] *** lanceball has quit IRC