July 8, 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

[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

top