[00:10:51] *** tfennelly has quit IRC
[00:55:16] *** bfitzpat has quit IRC
[01:16:54] *** aslak has quit IRC
[01:52:14] *** rcernich_away is now known as rcernich
[03:12:18] *** kcbabo has joined #switchyard
[04:42:07] *** rcernich has quit IRC
[05:13:55] *** magesh has joined #switchyard
[05:19:21] *** ldimaggi has quit IRC
[05:38:45] *** kcbabo has quit IRC
[06:13:04] *** dbevenius has joined #switchyard
[06:17:41] *** tcunning has quit IRC
[06:32:51] *** dbevenius has quit IRC
[06:44:25] *** tcunning has joined #switchyard
[06:49:01] *** tcunning has quit IRC
[07:30:18] *** dbevenius has joined #switchyard
[08:17:02] *** aslak has joined #switchyard
[09:48:12] *** rbalent has joined #switchyard
[09:48:13] *** rbalent has joined #switchyard
[11:22:48] *** tfennelly has joined #switchyard
[12:46:20] *** rbalent has quit IRC
[13:00:03] *** kcbabo has joined #switchyard
[14:05:52] *** kcbabo has quit IRC
[14:32:27] *** aamonten has joined #switchyard
[14:57:19] *** antollinim has joined #switchyard
[15:07:10] *** ldimaggi has joined #switchyard
[15:22:29] *** bfitzpat has joined #switchyard
[15:44:30] *** tcunning has joined #switchyard
[15:47:04] *** kcbabo has joined #switchyard
[15:52:00] *** rcernich has joined #switchyard
[15:56:18] *** dbevenius has quit IRC
[16:03:36] <antollinim> magesh: hi magesh, how are you? I merged your code
[16:03:52] <antollinim> magesh: can you please reject my pull request so I can send the new one?
[16:11:07] <kcbabo> antollinim:  you don't have to cancel the pull request
[16:11:20] <kcbabo> antollinim:  just push the new changes to your branch and the pull request will automatically update
[16:12:00] <antollinim> kcbabo: I did that and github shows me a screen where I can press a "Update Commit Range" button
[16:12:25] <antollinim> kcbabo: I am not sure whether I should press it or not
[16:12:29] <kcbabo> antollinim:  you shouldn't have to do anything with github
[16:12:44] <kcbabo> antollinim:  did you push your changes to your branch?
[16:12:51] <antollinim> kcbabo: yes
[16:13:08] <antollinim> kcbabo: you mean I do not have to press "Pull Request" again?
[16:13:31] <antollinim> kcbabo: the previous pull request gets updated with the new code automatically?
[16:13:50] <kcbabo> antollinim:  no, I'm just asking if you pushed the new changes to your branch
[16:13:58] <kcbabo> antollinim:  I don't see them here:
[16:13:59] <kcbabo> https://github.com/antollinim/components/commits/SWITCHYARD-347
[16:14:04] <antollinim> kcbabo: yes, i pushed
[16:14:13] <kcbabo> antollinim:  where?
[16:14:49] <antollinim> kcbabo: to the topic branch you just pasted here
[16:14:55] <antollinim> kcbabo: 347
[16:15:02] <kcbabo> antollinim:  that shows the last update was 2 days ago
[16:15:22] <kcbabo> antollinim:  did you rebase and all that?
[16:15:29] <antollinim> kcbabo: yes
[16:15:46] <kcbabo> antollinim:  if you look at that commit, do you see the change that you made?
[16:15:50] <kcbabo> https://github.com/antollinim/components/commit/b198eee64a5ecabb6866ab0a017e912e9b7eff46
[16:15:56] <antollinim> kcbabo: if you press the "commit" link it shows the latest code I have just commited
[16:16:13] <antollinim> kcbabo: yes, that is the new code
[16:17:17] <antollinim> kcbabo: so I do not need to notify the fact that I updated the code after I sent the pull request?
[16:17:45] <kcbabo> antollinim:  normally, github automatically recognizes that
[16:17:52] <kcbabo> antollinim:  not sure why it's not in this case
[16:18:44] <antollinim> kcbabo: so, are we good? no need for me to do anything else from here?
[16:18:54] <kcbabo> antollinim:  in any case, if someone pulls directly from your branch to push, then they will get the latest
[16:19:17] <kcbabo> antollinim:  should be good
[16:19:36] <antollinim> kcbabo: yes, that is ok, however my confission arises since I would expect a pull request to be "inmutable"
[16:20:09] <kcbabo> antollinim:  a pull request is simply a notification, nothing more
[16:20:23] <kcbabo> antollinim:  the pull request points to a commit in another branch
[16:20:31] <kcbabo> antollinim:  sorry, another repository
[16:20:47] <antollinim> kcbabo: so it points to a commit or to a branch?
[16:21:08] <antollinim> kcbabo: if I push I am changig the commit
[16:21:11] <kcbabo> antollinim:  the pull request itself, should point to a commit - but I can't say for sure since it's a github thing
[16:21:25] <kcbabo> antollinim:  that's correct, which is why the pull request normally updates itself
[16:21:44] <kcbabo> wyer:  hey, justin
[16:21:47] <antollinim> kcbabo: ok, I understand now, thanks
[16:21:59] *** rcernich is now known as rcernich_away
[16:22:29] <kcbabo> antollinim:  not sure what magic they have going on at github with pull requests, but I can tell you we could simulate the same thing without github in the mix
[16:22:43] <kcbabo> antollinim:  you could just push to your repo and then give me the repo URL and the topic branch name
[16:22:53] <kcbabo> antollinim:  I could pull that directly into my repository and push from there
[16:23:01] <kcbabo> antollinim:  all without a pull request
[16:23:08] *** errantepiphany has joined #switchyard
[16:23:12] <antollinim> kcbabo: exactly
[16:23:13] <kcbabo> antollinim:  so the pull request itself is really just a collaboration tool
[16:33:41] <errantepiphany> kcbabo: I guess I need help understanding the difference between the xmlns and targetNamespace attributes.  If you have an element <foo xlmns="bar"/>, then foo's namespaceURI is "bar". But <foo targetNamespace="whiz"/> doesn't mean the namespaceURI is "whiz", right? And what about <foo xmlns="bar" targetNamespace="whiz"/>? Wouldn't the namespaceURI still be bar?
[16:34:20] <kcbabo> errantepiphany:  the namespace for the foo element is "bar"
[16:35:00] <kcbabo> errantepiphany:  the namespace for the value "bar" (say if you referenced it elsewhere in the definition) would be = "whiz" (the target namespace)
[16:35:24] <kcbabo> errantepiphany:  basically, the same principle as WSDL or XSD
[16:35:33] <kcbabo> errantepiphany:  like if you reference an element definition in a schema
[16:35:41] <kcbabo> errantepiphany:  it's target namespace uri + element name
[16:37:21] <errantepiphany> kcbabo, magesh: Then I don't understand the comments on http://community.jboss.org/message/618025#618025 .
[16:38:12] <kcbabo> errantepiphany:  which one in particular?
[16:38:28] <kcbabo> errantepiphany:  a test would be nice so that we can all look at the same thing
[16:38:36] <kcbabo> errantepiphany:  just haven't had a chance to write one yet
[16:38:39] <errantepiphany> I would assume the returned namespaceURI of the qname of the componentService to be "http://docs.oasis-open.org/ns/opencsa/sca/200912", not "urn:switchyard-quickstart-demo:orders:0.1.0-SNAPSHOT"
[16:39:01] <errantepiphany> kcbabo, magesh: I'll write up a quick example.
[16:39:01] <kcbabo> errantepiphany:  ok, that helps
[16:39:22] <kcbabo> errantepiphany:  the namespace of the component service = target namespace
[16:39:33] <kcbabo> errantepiphany:  that is the namespace of the values you define in your application
[16:39:49] <kcbabo> errantepiphany:  so the element itself has a namespace = to the SCA one you listed
[16:40:03] <kcbabo> errantepiphany:  the name defined by the element has a namespace = target namespace
[16:40:06] <errantepiphany> kcbabo: But the component service is a child element of the component, which is a child element of the composite, which has an xmlns of "http://docs.oasis-open.org/ns/opencsa/sca/200912"
[16:40:48] <kcbabo> errantepiphany:  I think we are getting mixed up here on the element vs. value thing
[16:41:03] <errantepiphany> kcbabo: let me whip up an example and put it on pastebin.
[16:41:10] <kcbabo> errantepiphany:  sounds great
[16:45:06] <kcbabo> errantepiphany:  for a related example, you can look at our own schema for SwitchYard
[16:46:38] <kcbabo> errantepiphany:  the xmlns is defined as "http://www.w3.org/2001/XMLSchema" and the targetNamespace is "urn:switchyard-config:switchyard:1.0"
[16:47:05] <kcbabo> errantepiphany:  so the element definition for "domain" has a namespace = XMLSchema
[16:47:41] <kcbabo> errantepiphany:  but the element name has a namespace = SwitchYard
[16:50:56] *** dbevenius has joined #switchyard
[17:08:33] <errantepiphany> kcbabo, magesh: I need to read what you wrote... In the meantime, this is the current behavior: http://pastebin.com/pzrmi7AH
[17:10:12] <kcbabo> errantepiphany:  so what you have there is right
[17:10:54] <kcbabo> errantepiphany:  it's not exactly the same as the naming issue with service names though
[17:11:19] <kcbabo> errantepiphany:  I would take a look at the schema example with our config, or better still what WSDL does
[17:11:32] <kcbabo> errantepiphany:  I need to step away for a short bit, back in two shakes
[17:11:37] *** kcbabo is now known as babo_afk
[17:11:38] <errantepiphany> kcbabo: okay.
[17:11:48] *** errantepiphany is now known as ee_coffee
[17:24:03] *** ee_coffee is now known as errantepiphany
[17:45:36] <errantepiphany> babo_afk: I think I see where the problem is.
[17:47:14] *** rcernich_away is now known as rcernich
[18:00:17] *** aslak has quit IRC
[18:00:32] *** babo_afk is now known as kcbabo
[18:00:40] *** aslak has joined #switchyard
[18:01:01] <kcbabo> errantepiphany:  cool, saw the JIRA
[18:01:20] <errantepiphany> :)
[18:01:51] <errantepiphany> kcbabo: Yeah, I get it now.
[18:16:08] <magesh> antollinim: Awesome, thanks very much. I will push it in now
[18:16:37] <antollinim> magesh: thanks to you for your help
[18:16:58] <magesh> antollinim: nps.
[18:17:16] <magesh> kcbabo: Do you find anything that I missed with antollinim's pull request?
[18:18:04] <kcbabo> magesh:  you are the man, magesh.  If it's good for you, it's good for me.
[18:18:32] <magesh> kcbabo: Thanks Keith for helping antollinim about the github magic ;)
[18:19:19] <kcbabo> magesh:  hope it works out :-)
[18:21:54] <magesh> kcbabo: I am not sure if the quickstarts should be updated, what do you think?
[18:22:30] <kcbabo> magesh:  heh ? I was on the fence on that one
[18:22:45] <kcbabo> magesh:  I think mario was just closing the loop since we originally hit this issue with that quickstart
[18:22:59] <kcbabo> magesh:  tbh, I don't think it's all that important for that quickstart, but it doesn't hurt either
[18:23:01] <kcbabo> magesh:  your call
[18:23:32] <antollinim> magesh: I updated the  transform-jaxb quickstarts to have a webservice test which uses standard doclit
[18:23:56] <magesh> kcbabo: Okay, antollinim I did see that, thanks again
[18:24:00] <antollinim> magesh: kcbabo discovered the docli issue while trying to do a doclit test in quickstarts
[18:24:31] <antollinim> magesh: so, that caused me to first add doclit support and then get back to the quickstart to add the test
[18:24:46] <magesh> antollinim: Nice, I will push that in too.
[18:25:04] <magesh> kcbabo: So what is with the release not getting built?
[18:25:46] <kcbabo> magesh:  I was gonna email you about that - hoping that you would have an idea
[18:25:52] <kcbabo> magesh:  my local release build is A-OK
[18:26:06] <kcbabo> magesh:  tried deleting the workspace in the hudson build and it still doesn't work
[18:26:10] <magesh> kcbabo: My local fails, hmm are you cheating ;)
[18:26:13] <kcbabo> magesh:  all the changes have been pushed to nexus
[18:26:21] <kcbabo> magesh:  really?  with the same error?
[18:26:26] <magesh> kcbabo: Yep
[18:26:40] <kcbabo> magesh:  have you updated your quickstarts with David's latest commit?
[18:27:07] <kcbabo> magesh:  or stated differently - are you up-to-date with upstream master on quickstarts?
[18:27:10] <magesh> kcbabo: I will investigate these, is there anything urgent? I checked last a few hours ag
[18:27:13] <kcbabo> magesh:  that's the error it's throwing
[18:27:15] <magesh> (ago)
[18:27:20] <kcbabo> magesh:  nah, it can wait
[18:27:28] *** aslak has quit IRC
[18:27:32] <magesh> kcbabo: Okay
[18:27:54] <kcbabo> magesh:  seems like it's picking up an old version of the camel-service quickstart
[18:28:11] <kcbabo> magesh:  but I checked the workspace and it is the most recent (switchyard.xml has been updated)
[18:28:19] <kcbabo> magesh:  so not sure what the heck is going on there
[18:28:43] <kcbabo> magesh:  in the meantime, I'll ask a few more folks to try out the release build locally
[18:28:46] <kcbabo> magesh:  see what happens
[18:29:11] <kcbabo> tfennelly:  can you try out a release build in your local environment and see what happens?
[18:29:31] <antollinim> kcbabo: can I help with that?
[18:29:48] <kcbabo> antollinim:  yes, please
[18:29:56] <kcbabo> antollinim:  if you can try out a release build as well, that would be great
[18:30:09] <kcbabo> antollinim:  just clone the release repository and run "mvn install"
[18:30:21] <antollinim> kcbabo: ok, good
[18:30:25] <aamonten> kcbabo: I will do the same..
[18:30:31] <kcbabo> aamonten:  thanks very much
[18:31:04] <magesh> kcbabo: cool!
[18:31:24] <tfennelly> kcbabo: sure... I just did the AS7 part of that a ew mins ago and it built OK
[18:31:57] <kcbabo> tfennelly:  yeah, I think there's something funky with the hudson environment
[18:33:00] <kcbabo> tfennelly:  but maybe it's just OSX folks that have all the luck
[18:33:05] <kcbabo> tfennelly:  style matters ;-)
[18:34:14] <tfennelly> kcbabo: for sure it does
[18:34:31] <tfennelly> kcbabo: so want me to build it then or is there any point?
[18:34:43] <tfennelly> kcbabo: was it something other than the AS7 part?
[18:35:20] <kcbabo> tfennelly:  strictly speaking, it's a full build that's failing
[18:35:44] <kcbabo> tfennelly:  can't see why running AS7 alone wouldn't cause the same error, but ...
[18:35:46] <tfennelly> kcbabo: okidoki... will do that now
[18:36:19] <tfennelly> kcbabo: just in the middle of building the rest of it now and then I'll run the release build
[18:37:16] <kcbabo> tfennelly:  thanks
[18:37:40] <tfennelly> kcbabo: have some initial stuff on SWITCHYARD-239
[18:37:50] <kcbabo> tfennelly:  nice
[18:37:53] <tfennelly> kcbabo: context type stuff injection
[18:38:01] <kcbabo> tfennelly:  ah crap, forgot to send you that link to the SCA Java spec
[18:38:16] <tfennelly> kcbabo: loads more to do but worth checking and letting ye look at it
[18:38:27] <tfennelly> kcbabo: no worries... found it myself anyway
[18:38:33] <kcbabo> tfennelly:  oh, cool
[18:40:46] <tfennelly> kcbabo: ah balls... test failure... sorry... little delay
[18:40:56] *** aslak has joined #switchyard
[18:41:00] <kcbabo> tfennelly:  crap
[18:41:02] *** aslak has quit IRC
[18:41:02] *** aslak has joined #switchyard
[18:41:11] <kcbabo> tfennelly:  can you try again with a clean maven repo?
[18:41:15] <kcbabo> tfennelly:  just the switchyard stuff
[18:41:29] <kcbabo> tfennelly:  oh, you meant with your stuff
[18:41:31] <kcbabo> ?
[18:41:34] <tfennelly> kcbabo: no... test failure has nothing to do with release... related to my changes
[18:41:56] <tfennelly> kcbabo: and I think it's sorted now so
[18:42:54] <aamonten> kcbabo: downloading distributions, meantime going for lunch..
[18:43:03] *** aamonten is now known as aamonten_lunch
[18:43:34] <antollinim> kcbabo: same here, it is taking long, I am getting sth to eat
[18:44:02] *** antollinim is now known as antollinim_lunch
[18:44:47] <kcbabo> hmmm ? wonder if that's it
[18:45:04] <kcbabo> nah, nevermind
[18:48:31] <tfennelly> kcbabo: it's building there now
[18:48:47] <tfennelly> kcbabo: for later for you... https://issues.jboss.org/browse/SWITCHYARD-239?focusedCommentId=12617338&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12617338
[18:50:32] <tfennelly> kcbabo: build succcessful
[18:50:47] <kcbabo> tfennelly:  thanks ? looking more like hudson weirdness
[18:51:24] <tfennelly> kcbabo: I gave you a link to some changes relating to that JIRA I'm working on... have a look later
[18:51:32] <kcbabo> tfennelly:  looking now
[18:51:56] <tfennelly> kcbabo: there are loads of obvious bugs... incomplete methods etc... just ignore them
[18:51:57] *** antollinim_lunch is now known as antollinim
[18:52:04] <kcbabo> tfennelly:  that's cool
[18:52:32] <kcbabo> tfennelly:  so can you describe how this maps onto injection into an actual bean service?
[18:52:34] <tfennelly> kcbabo: ExchangeContext is along the lines of the RequestContext in the SCA API
[18:53:10] <kcbabo> tfennelly:  right, I was thinking that would be a bean component interface and not a core api interface
[18:53:16] <kcbabo> tfennelly:  that was my initial thought anway
[18:53:17] <kcbabo> anyway
[18:53:33] <kcbabo> tfennelly:  so the SCA API is for implementation.java
[18:53:47] <kcbabo> tfennelly:  i.e. java (or in our case ' bean') services
[18:53:50] <tfennelly> kcbabo: I never seem to be able to guess whether you want something in the API or not
[18:53:55] <kcbabo> tfennelly:  :-)
[18:54:06] *** GitHub197 has joined #switchyard
[18:54:06] <GitHub197> [components] mageshbk pushed 1 new commit to master: https://github.com/jboss-switchyard/components/commit/b198eee64a5ecabb6866ab0a017e912e9b7eff46
[18:54:06] <GitHub197> [components/master] SWITCHYARD-347 SOAP gateway does not detect operation name property for doc/lit - Mario Antollini
[18:54:06] *** GitHub197 has left #switchyard
[18:54:13] <kcbabo> tfennelly:  it's my fault for not making it clearer
[18:54:48] <tfennelly> kcbabo: makes sense to me in the API
[18:54:52] <kcbabo> tfennelly:  so the idea was to make it possible to inject the existing exchange context properties into a Java bean
[18:55:02] <tfennelly> kcbabo: I didn't realise you just wanted this to be a bean component thing
[18:55:21] <kcbabo> tfennelly:  yeah, that's why I mentioned the Java component spec in SCA
[18:55:42] <kcbabo> tfennelly:  of course, I provided no additional context, so that wasn't very helpful in retrospect
[18:56:00] <kcbabo> tfennelly:  we already have access to context properties via the core API
[18:56:13] <kcbabo> tfennelly:  bean services, on the other hand, do not have access to context properties
[18:56:39] <tfennelly> kcbabo: ok... I thought it was also for stuff like security info
[18:57:14] <kcbabo> tfennelly:  security info, transaction context, etc. will all definitely flow as context properties
[18:57:16] *** rbalent has joined #switchyard
[18:57:17] *** rbalent has joined #switchyard
[18:57:22] <tfennelly> kcbabo: ok... what I have is arse then so don't waste yer time looking at it
[18:57:37] <kcbabo> tfennelly:  sorry about that ? my bad
[18:58:37] <tfennelly> kcbabo: https://github.com/tfennelly/jboss-switchyard-quickstarts/blob/0c982c29e9577bd53cdb6e73bdfc2aa1a137ab8a/demos/orders/src/main/java/org/switchyard/quickstarts/demos/orders/OrderServiceBean.java
[18:59:48] <tfennelly> kcbabo: so you just want to do this around cdi bean services
[19:00:01] <kcbabo> tfennelly:  the injection part, yeah
[19:00:28] <kcbabo> tfennelly:  we probably still need to work through the context properties stuff in core api
[19:00:41] <tfennelly> kcbabo: :)
[19:00:46] <kcbabo> tfennelly:  still split between message and scope
[19:00:52] <kcbabo> sorry, message and exchange
[19:01:19] <kcbabo> tfennelly:  and I have thought of some use cases for domain-level properties as well
[19:01:55] <kcbabo> tfennelly:  which makes me wonder whether they all should go into one flat context
[19:02:09] <kcbabo> tfennelly:  which could then map directly onto what you inject into the bean service
[19:02:30] <tfennelly> kcbabo: I don't really like that tbh
[19:02:37] <tfennelly> kcbabo: the flat context
[19:02:52] <magesh> kcbabo: I even get the same hudson failure with a clean switchyard repo
[19:03:23] <tfennelly> kcbabo: ask errantepiphany to run a build on linux
[19:04:00] <magesh> tfennelly: :) I would +1 that
[19:05:13] <tfennelly> magesh: :)
[19:05:54] <magesh> tfennelly: I thought you were talking about the release build, never mind :)
[19:06:20] <magesh> tfennelly: We always cross-talk, my bad!
[19:06:41] <tfennelly> magesh: nps
[19:07:59] <tfennelly> kcbabo: ok... I'll try poop out a bean specific version of that tomorrow
[19:08:10] <tfennelly> l8rs guys
[19:08:15] *** tfennelly has quit IRC
[19:11:31] *** aamonten_lunch has quit IRC
[19:12:58] <kcbabo> errantepiphany:  can you run a release build when you get a chance?
[19:15:09] <errantepiphany> kcbabo: sure
[19:27:58] * magesh Oh the irony of my OS :(
[19:32:07] <magesh> kcbabo: Hi Keith, should I send a pull request for this now? http://hudson.qa.jboss.com/hudson/job/SwitchYard-Components/732/
[19:32:52] <kcbabo> magesh:  sure thing :-)
[19:41:34] <magesh> kcbabo: Please pull this https://github.com/jboss-switchyard/components/pull/192
[19:41:57] <kcbabo> magesh:  too funny :-)
[19:42:00] <kcbabo> magesh:  doing it now
[19:42:33] <magesh> kcbabo: Don't tell Switchyard config pullers
[19:42:38] <magesh> kcbabo: Shh...
[19:46:10] <kcbabo> magesh:  bad news - after the test failure, there are going to be checkstyle violations
[19:46:48] <kcbabo> magesh:  I will go ahead and fix those up - it's getting mighty late for you
[19:46:58] <magesh> kcbabo: Are you sure, I ran it several times
[19:47:14] <magesh> kcbabo: I don't mind if I can update my pull with those
[19:47:25] <kcbabo> magesh:  here's what I see
[19:47:27] <kcbabo> org/switchyard/component/soap/InboundHandler.java
[19:48:17] <magesh> kcbabo: Yes, man, my bad
[19:48:25] <magesh> kcbabo: Will fix them
[19:51:46] *** kcbabo has quit IRC
[19:52:02] *** kcbabo has joined #switchyard
[19:53:27] 
[19:54:32] *** kcbabo has quit IRC
[19:54:45] *** kcbabo has joined #switchyard
[19:56:04] <magesh> kcbabo: It should have been updated by now, sorry for that
[19:56:14] <magesh> kcbabo: What is with your login?
[19:56:28] <kcbabo> magesh:  not sure - acting crazy
[19:56:37] <magesh> kcbabo: I will remember to re-check any re-commits heron, good lesson
[19:56:47] <magesh> (here on)
[19:56:52] <kcbabo> magesh:  I've done the exact same thing recently
[19:57:46] <magesh> kcbabo: There should be some way to share our ordeal so we don't repeat it. But hell yes only experience is the best teacher! :)
[19:58:22] <kcbabo> magesh:  indeed
[20:00:23] <magesh> kcbabo: I am closing in on the release failure, seems to happen only with Arquillian, the manual deploy seems OK
[20:00:37] <kcbabo> magesh:  sweet
[20:01:06] *** GitHub45 has joined #switchyard
[20:01:06] <GitHub45> [components] kcbabo pushed 1 new commit to master: https://github.com/jboss-switchyard/components/commit/fa79443a80e43c7c6087e2309b5c4e5943ff1b2c
[20:01:06] <GitHub45> [components/master] [SWITCHYARD-347] - WSDL filename mismatched in config - Magesh Kumar B
[20:01:06] *** GitHub45 has left #switchyard
[20:02:08] <magesh> kcbabo: > At least you didn't push a merge commit. ---> He... he...
[20:04:56] *** kcbabo is now known as babo_brb
[20:10:58] <antollinim> kcbabo: release build failed for me: http://cl1p.com/release_failed/
[20:20:36] *** aamonten has joined #switchyard
[20:20:58] <aamonten> babo_brb: tests failed...
[20:23:21] <magesh> antollinim: Can you please try the build now?
[20:23:37] <antollinim> sure
[20:24:45] <antollinim> magesh: I see no update in master
[20:25:04] <antollinim> magesh: something hanged in maven repos?
[20:25:17] <magesh> antollinim: :) no worries, just do a build
[20:25:18] <antollinim> magesh: something changed in maven repos?
[20:25:24] <antollinim> magesh: ok
[20:25:31] <magesh> antollinim: It could be slow sometimes
[20:26:16] <magesh> aamonten: Which tests are you talking about?
[20:26:44] <aamonten> magesh: when running mvn install on sw-release
[20:27:17] <magesh> aamonten: Ahh, the one which we are working on
[20:28:34] <magesh> aamonten: Could you try a clean build now, please?
[20:28:41] *** jgraham_ has joined #switchyard
[20:28:53] <aamonten> magesh: sure, no need to update?
[20:29:35] <magesh> aamonten: Yep, the Arquillian test should pick up the latest quickstarts
[20:29:55] <aamonten> magesh: ok, in progress
[20:30:15] <magesh> antollinim: Any info on the build yet?
[20:30:31] <antollinim> magesh: still building
[20:30:45] <magesh> antollinim: Okay
[20:33:27] <aamonten> magesh: still errors with mvn clean install
[20:33:48] <aamonten> magesh: should I try mvn -U clean install?
[20:35:14] <magesh> aamonten: Thanks, you can try that too. But I now know what the issue is. Will see why the updated quickstarts are not getting downloaded by the tests.
[20:35:46] <magesh> aamonten, antollinim: If you guys build the quickstarts locally before building release it will pass I guess
[20:36:02] <aamonten> magesh: ok, giving it a try
[20:36:10] <magesh> aamonten, antollinim: Thanks for trying that out
[20:36:21] <antollinim> magesh: let me try that
[20:39:24] <antollinim> magesh: my transformation-jaxb quickstarts project is failing now locally, I'll see what is going on
[20:39:57] <magesh> antollinim: :) that is something to do with the latest changes of yours and mine.
[20:40:15] <antollinim> magesh: ups :)
[20:40:31] *** rcernich is now known as rcernich_lunch
[20:45:11] *** dbevenius has quit IRC
[20:57:36] <antollinim> magesh: quickstarts works now for me, I just built and installed components once again
[20:57:56] <antollinim> magesh: release is still building
[20:58:38] <magesh> antollinim: Okay
[21:00:45] <antollinim> magesh: [INFO] SwitchYard: Release Distribution Tests ............ FAILURE [28:40.290s]
[21:01:05] <antollinim> magesh: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.6:test (default-test) on project switchyard-release-test: There are te st failures.
[21:01:52] <antollinim> magesh: the error says: org.jboss.arquillian.spi.client.container.LifecycleException: Could not start remote container      at org.jboss.arquillian.container.jbossas.managed_6.JBossASLocalContainer.start(JBossASLocalContainer.java:105)      at org.jboss.arquillian.impl.client.container.ContainerLifecycleController$5.perform(ContainerLifecycleController.java:145)      at org.jboss.arquillian.impl.client.container.ContainerLifecycleController$5.perf
[21:02:08] *** babo_brb is now known as kcbabo
[21:02:23] <magesh> antollinim: Strange I no longer am getting any failures locally
[21:02:30] <antollinim> magesh: Caused by: java.io.IOException: Server failed to start; see logs. exit code: 1      at org.jboss.jbossas.servermanager.ServerController.waitForServer(ServerController.java:321)
[21:02:39] <antollinim> magesh: I'll retry
[21:02:50] <magesh> antollinim: That seems odd, it should not fail to start server
[21:03:08] <antollinim> magesh: I am on windows, maybe this is a new error
[21:03:31] <magesh> antollinim: Oh, we tested the release build in that platform too
[21:03:39] <antollinim> magesh: I am re-building now
[21:31:14] <antollinim> magesh: I rebuilt everything and the release test keeps saying: Caused by: java.io.IOException: Server failed to start; see logs. exit code: 1      at org.jboss.jbossas.servermanager.ServerController.waitForServer(ServerController.java:321)
[21:34:28] <magesh> antollinim: Can you start the server manually from the target/switchyard-as7-0.2 directory and see what gets added to the log?
[21:34:48] <antollinim> magesh: sure
[21:39:34] <antollinim> magesh: did you mean to start i manually and then build release again?
[21:39:52] <antollinim> magesh: not possible to do so: Caused by: org.jboss.arquillian.spi.client.container.LifecycleException: The server is already running! Managed containers does not support connecting to running server instances due to the possible harmfull effect of connecting to the wrong server. Please stop server before running or change to another type of container.      at org.jboss.arquillian.container.jbossas.managed_6.JBossASLocalContainer.start(JBossASLoca
[21:41:59] <magesh> antollinim: So somewhere your server is running in the background
[21:42:11] <magesh> antollinim: Kill the java/javaw tasks
[21:42:42] <antollinim> magesh: yes, it was running in the background, I started it manually
[21:43:04] <antollinim> magesh: or you are talking about the original error "could not be started"?
[21:44:05] <magesh> antollinim: It could be due to port conflicts too.
[21:44:05] <antollinim> magesh: the "could not be started" error is not due to an already running process since i checked and there is no java process running before starting the build
[21:44:18] <antollinim> magesh: what port does it use?
[21:44:26] <antollinim> magesh: do you know?
[21:44:40] <magesh> antollinim: So manual start gives you "The server is already running!" error?
[21:45:12] <antollinim> magesh: no, manual starting the server and then running the build gives me this error: Caused by: org.jboss.arquillian.spi.client.container.LifecycleException: The server is already running! Managed containers does not support connecting to running server instances due to the possible harmfull effect of connecting to the wrong server. Please stop server before running or change to another type of container.      at org.jboss.arquillian.container.j
[21:46:15] <antollinim> magesh: the previous error (ie. w/o manually starting the server) was "Server failed to start"
[21:46:28] <magesh> antollinim: I just want you to manually start the server and see if the server starts OK. Then shutdown the server and redo the build
[21:46:54] <antollinim> magesh: yes, it started ok manually
[21:47:26] <antollinim> magesh: I have no java process running now
[21:47:31] <antollinim> magesh: i am building now...
[21:48:46] <antollinim> magesh: "Server failed to start"
[21:50:20] <magesh> antollinim: could you paste the complete output to pastebin?
[21:51:06] <magesh> antollinim: I am gonna crash, talk to you tomorrow
[21:51:29] <antollinim> magesh: one last thing
[21:51:46] <magesh> antollinim: Yep
[21:51:47] <antollinim> magesh: could it be this? Running org.switchyard.test.ordersdemo.OrdersDemoQuickstartTest 16:49:26,219 INFO  [ContainerRegistryCreator] Could not read active container configuration: null Starting server "default", with command (start timeout is 120 seconds ):
[21:52:10] <antollinim> magesh: missing container configuration could be the problem?
[21:52:41] <magesh> antollinim: Could you revert all your local changes and test? Did you do any local update?
[21:53:15] <antollinim> magesh: I rebased core, components and release
[21:53:55] <antollinim> magesh: then I deleted swithcyard from maven repo, and I rebuilt the projects in that order
[21:54:13] <antollinim> magesh: i do not have local changes
[21:54:34] <aamonten> kcbabo: do we have a transformer for this No registered Transformer available for transforming from 'java:java.lang.Integer' to 'java:int'
[21:54:40] <magesh> antollinim: Then please post the complete output of maven build, that could help
[21:55:05] <antollinim> magesh: do not worry, let's talk tomorrow
[21:55:13] <antollinim> magesh: I'll take a look at it
[21:55:18] <magesh> antollinim: thanks
[21:55:37] <kcbabo> aamonten:  hmm ? that shouldn't require a transformer
[21:56:00] <kcbabo> aamonten:  then again it's pretty weird to be passing a primitive as the payload :-)
[21:56:02] <aamonten> kcbabo: I also thought that..
[21:56:10] <kcbabo> aamonten:  autoboxing should take care of it
[21:56:24] <kcbabo> aamonten:  there might be a small enhancement necessary to account for that case
[21:57:32] <aamonten> kcbabo: I will just do some changes on my code, but I was just curious about the message..
[21:57:51] <kcbabo> aamonten:  definitely sounds like something we should address
[21:57:57] <kcbabo> aamonten:  would you mind filing a JIRA?
[21:58:11] <aamonten> kcbabo: sure!
[22:00:18] <errantepiphany> kcbabo, magesh: Please check out my comments on https://issues.jboss.org/browse/SWITCHYARD-365 . The fix bubbled out, but I believe in a good way. (We now respect namespaces in Bean @Services!)
[22:01:19] <kcbabo> errantepiphany:  read through it
[22:01:40] <kcbabo> errantepiphany:  I think this came up in the forum thread, but bean services should not declare a namespace in the annotation
[22:01:51] <kcbabo> errantepiphany:  that is part of the application they are included in
[22:01:56] <magesh> errantepiphany: Just saw that. Thanks for understanding!
[22:02:34] <errantepiphany> kcbabo: Well, if you tell me how to get a hold of the application namespace when I'm registering the CDI bean, I can get rid of the annotation.
[22:03:24] <errantepiphany> kcbabo: See CDIBeanServiceDescriptor.getServiceName(Class):QName (on my branch)
[22:03:37] <kcbabo> errantepiphany:  something is going to have to change there then
[22:03:39] <errantepiphany> kcbabo: that's where I need to know it.
[22:03:55] <errantepiphany> kcbabo: http://goo.gl/iW0WA
[22:05:04] <kcbabo> errantepiphany:  the bean component activator has access to the SwitchYardModel, doesn't it?
[22:05:13] <kcbabo> errantepiphany:  that's where the services should be getting registered
[22:05:29] <magesh> kcbabo, errantepiphany: I am off, see you guys tomorrow.
[22:05:35] <kcbabo> magesh:  cya, magesh
[22:05:48] *** magesh has left #switchyard
[22:08:36] <errantepiphany> kcbabo: so you're saying whatever the targetNamespace of the activator's model is, that's what the Bean Service should use as it's namespaceURI when registered in the domain?
[22:08:58] <kcbabo> errantepiphany:  correct
[22:09:10] <errantepiphany> kcbabo: okay; gimme a bit. I'll close those pull requests.
[22:09:41] <kcbabo> errantepiphany:  one more thing
[22:09:50] <kcbabo> errantepiphany:  targetNamespace needs to be at the composite level
[22:17:27] <errantepiphany> kcbabo: why?
[22:18:00] <kcbabo> errantepiphany:  a few reasons
[22:18:00] <errantepiphany> kcbabo: the way I have it now is that it can be, but it can inherit from the switchyard level if need be.
[22:19:37] <kcbabo> errantepiphany:  my primary concern is that it's not schema valid
[22:20:06] <ldimaggi> kcbabo, ping
[22:20:13] <kcbabo> errantepiphany:  so if we extract the composite definition, it's not going to be a valid composite definition
[22:20:44] <kcbabo> errantepiphany:  the second reason (which I see now I'm currently wrong about) is that other things in the switchyard definition don't need a namespace
[22:20:58] <kcbabo> errantepiphany:  but like I said, I'm wrong about that because ServiceDomain names are currently QName
[22:21:20] <errantepiphany> kcbabo: As long as the CompositeModel has a non-null getParentModel()  (aka: the SwitchYardModel), then compositeModel.getQName() will have the appropriate targetNamespace as the namespaceURI
[22:21:21] <kcbabo> errantepiphany:  which IIRC was a flip of the coin thing at the F2F - I would prefer them to be non-namespaced
[22:21:28] <ldimaggi> kcbabo, Hey Keith - are you free to complete that Switchyard Q&A session with the QE team - next week?
[22:21:36] <kcbabo> ldimaggi:  one sec
[22:22:05] <kcbabo> ldimaggi:  I should be - do you have a time in mind?
[22:22:25] <ldimaggi> kcbabo, Wednesday - 9:30
[22:22:48] <kcbabo> ldimaggi:  works for me
[22:23:15] <kcbabo> errantepiphany:  ok, so let's say I try to serialize the composite model as XML
[22:23:33] <kcbabo> errantepiphany:  will it pick up the targetNamespace attribute when it's serialized outside the enclosing switchyard element?
[22:24:43] <kcbabo> errantepiphany:  I really want that composite definition to be valid stand-alone, which is why I'm hung up on this
[22:25:22] <kcbabo> errantepiphany:  with that said, I'm OK with moving your current changes in now and addressing this as a separate issue since the ServiceDomain API will have to change if we get rid of targetNamespace at the switchyard model level
[22:25:42] <errantepiphany> kcbabo: don't push them in yet. I'm experimenting with what you told me.
[22:25:51] <kcbabo> errantepiphany:  which I don't think we need at that level, but I guess we should have more of a discussion around that in the forum
[22:25:51] <kcbabo> errantepiphany:  okie dokie
[22:26:30] <ldimaggi> kcbabo, thx!
[22:28:11] <kcbabo> ldimaggi:  thank you
[22:28:16] <kcbabo> ldimaggi:  looking forward to it
[22:28:26] <errantepiphany> kcbabo: The targetNamespace of the composite will get serialized outside of the enclosing switchyard if it was originally defined at the composite level, but not otherwise. However, if the targetNamespace was specified at the switchyard level, then an API call to composite.getQName() will look upwards to it's parent (aka: switchyard)  to use its targetNamespace as it's namespaceURI.
[22:28:29] <errantepiphany> kcbabo: make sense?
[22:29:01] <kcbabo> errantepiphany:  that makes sense, but that's not the way I want it to work. :-)
[22:29:16] <kcbabo> errantepiphany:  but based on what I said above, I think it's outside the scope of the current JIRA
[22:29:33] <kcbabo> errantepiphany:  we can discuss it as part of a separate issue and thread on the forum
[22:29:39] <errantepiphany> kcbabo: so you're saying that you want targetNamespace to stay required (not optional) on the composite? If that's the case, then the targetNamespace at the switchyard level is pointless.
[22:29:47] <kcbabo> errantepiphany:  exactly!
[22:30:04] <errantepiphany> kcbabo: well I can do that.
[22:30:28] <kcbabo> errantepiphany:  my main thing is that the targetNamespace is very important at the composite level
[22:30:36] <kcbabo> errantepiphany:  and I don't think it's useful at the switchyard level
[22:31:03] <kcbabo> errantepiphany:  so the current evidence points strongly in favor of including it at composite (and remaining schema compliant) and dumping it at switchyard
[22:31:11] <errantepiphany> kcbabo: are you sure? because what about the <transforms> section, or any other future section we add to switchyard that are xml siblings to <composite>?
[22:32:06] <kcbabo> errantepiphany:  so I see a case there for having a switchyard-level targetNamespace if that requirement comes up
[22:32:21] <kcbabo> errantepiphany:  but that strikes me as the namespace definition that's optional
[22:32:41] <errantepiphany> kcbabo: gotcha. okay.
[22:32:47] <kcbabo> errantepiphany:  cool !
[22:35:10] <aamonten> kcbabo: I took the numberguess app (JSF+CDI) from as7 and enhanced it with swyd, should I add it to quickstart/demos or another place?
[22:38:01] <kcbabo> aamonten:  sweet!  Can you post a link to your topic branch in the forum?
[22:38:11] <kcbabo> aamonten:  quickstarts/demos would be perfect
[22:38:39] <kcbabo> aamonten:  I would like to brainstorm about how we could beef it up beyond number guess a bit, so I think the forum would be a great place to do that
[22:38:58] <aamonten> great.. fixing pom and will push in a moment
[22:39:21] <aamonten> kcbabo: yeah making a more complete web app would be great
[22:41:50] *** ldimaggi has quit IRC
[22:57:24] *** rcernich_lunch is now known as rcernich
[23:17:26] *** jgraham_ has quit IRC
[23:28:28] <aamonten> kcbabo: done http://community.jboss.org/thread/170193
[23:29:10] <kcbabo> aamonten:  thanks very much
[23:29:21] <kcbabo> aamonten:  I'm out the door right now, but I'll comment on it tonight
[23:29:45] *** kcbabo has quit IRC
[23:31:24] *** aamonten has quit IRC





top