[00:33:12] *** ldimaggi has quit IRC
[03:20:18] *** tcunning has joined #switchyard
[04:01:37] *** ldimaggi has joined #switchyard
[04:02:57] *** ldimaggi has quit IRC
[04:03:14] *** ldimaggi has joined #switchyard
[05:50:40] *** ldimaggi has quit IRC
[06:43:30] *** magesh has joined #switchyard
[06:48:52] *** tcunning has quit IRC
[08:04:59] *** rbalent has joined #switchyard
[08:59:46] *** dbevenius has joined #switchyard
[09:34:40] *** aslak has joined #switchyard
[11:29:24] *** dbevenius1 has joined #switchyard
[11:29:24] *** dbevenius has quit IRC
[12:22:35] *** kcbabo has joined #switchyard
[12:25:13] <wyer> kcbabo, morning Keith
[12:25:25] <kcbabo> wyer:  hey justin
[12:26:51] <wyer> kcbabo, i'll finish up SWITCHYARD-336 this week, seems i am over the worst of the flu and the missus is going away to the beach so i'll have plenty of time ;)
[12:27:10] <kcbabo> wyer:  that would be great, thanks very much
[12:36:48] *** aslak has quit IRC
[12:37:12] *** aslak has joined #switchyard
[12:48:55] *** tfennelly has joined #switchyard
[12:57:54] *** tcunning has joined #switchyard
[13:24:36] *** tcunning has quit IRC
[13:43:14] <tfennelly> magesh: hey magesh
[13:44:33] <magesh> tfennelly: Hi Tom
[13:44:46] <magesh> tfennelly: You changed your timezone :)
[13:44:49] <magesh> tfennelly: ?
[13:44:54] <tfennelly> magesh: hey man
[13:45:00] <tfennelly> magesh: sorry?
[13:45:18] <magesh> tfennelly: I see you only after Keith logs in
[13:45:32] <magesh> tfennelly: :)
[13:45:41] <tfennelly> magesh: ahhh... funny man
[13:45:52] <wyer> tfennelly, blame it on maven
[13:45:53] <tfennelly> magesh: anyway...
[13:46:14] <tfennelly> magesh: I think it was you that added the camel-as7 module, right?
[13:46:14] <magesh> tfennelly: Whats up?
[13:46:45] <tfennelly> magesh: ^^^
[13:46:59] <magesh> tfennelly: Let me refresh ...
[13:47:51] <magesh> tfennelly: Yes
[13:48:11] <magesh> tfennelly: I know where you are arriving at ... the mvel stuff?
[13:49:01] <tfennelly> magesh: nope...
[13:49:44] <magesh> tfennelly: Okay then I am assumed wrong, please go ahead
[13:49:45] <tfennelly> magesh: just wondering about the dependency camel-core has on it... would see to be in the wrong direction to me and I was wondering if it was just because of the assembly requirements?
[13:50:06] <tfennelly> (would seem)
[13:50:52] <tfennelly> magesh: what I'm getting at is... I would not have expected camel-core to have any dependencies on the other camel modules
[13:51:14] * magesh thinking evil, now I get to ask questions like Tom did earlier, but I will not play like that ;)
[13:51:19] <tfennelly> magesh: the other way around would have seemed ok, if needed
[13:51:27] <magesh> tfennelly: One sec, let me take a look at the files
[13:51:58] <tfennelly> magesh: I'll ignore that comment... whatever it was supposed to mean
[13:53:51] <magesh> tfennelly: You mean those javax.api, javax.xml.*, org.fusesource, commons.logging?
[13:54:13] <magesh> tfennelly: What are you talking about? org.apache.camel.core has only these
[13:55:40] <tfennelly> magesh: nope... the maven pom dependency that camel-core has on camel-as7
[13:55:48] <tfennelly> magesh: just thought it seemed odd
[13:56:11] <magesh> tfennelly: Let me look at the pom now
[13:56:17] <tfennelly> magesh: but... I'm guessing it's happening because of the assembly, maybe?
[13:56:55] <magesh> tfennelly: Oh yes that is just the asembly thing <scope>package</scope>
[13:57:12] <tfennelly> magesh: right
[13:57:18] <tfennelly> magesh: hmmm
[13:57:50] *** tcunning has joined #switchyard
[13:58:07] <tfennelly> magesh: I need to add a camel-cdi module to the assembly, but I can't add it there because the camel-cdi module depends on camel-core (a circular dep would result)
[13:58:57] <tfennelly> magesh: but that then got me thinking... should we not have another maven module for doing the assembly... so as to avoid funky dependencies like the one camel-core has on camel-as7?
[13:59:24] <magesh> tfennelly: Yeah probably, are you depending on the camel-as7 stuff? That is just a packageScanClassResolver
[13:59:39] <magesh> tfennelly: The order in maven is
[13:59:39] <magesh>         <module>camel/camel-as7</module>
[13:59:40] <magesh>         <module>camel/camel-core</module>
[14:00:40] <magesh> tfennelly: camle-core is our switchyard camel-plugin-core
[14:00:50] <magesh> tfennelly: Maybe that arouse the confusion?
[14:01:11] <tfennelly> magesh: no... my issue doesn't really have anything to do with the camel-as7 module... that was just a question wondering how that dep was there and if it was because of the assembly requirements
[14:01:55] <tfennelly> magesh: my issue is really to do with the fact that we are tring to assemble all the came stuff from the camel-core module
[14:02:51] <magesh> tfennelly: You are free to refactor the assembly build stuff to anywhere you need, if it pleases kcbabo. I have no issues. The final release would test that up.
[14:03:25] <tfennelly> magesh: cool.. thanks
[14:03:38] <magesh> tfennelly: The fact that camel component was refactored later once the assemblies were created could have led to this structure.
[14:03:57] <magesh> tfennelly: nps
[14:04:15] <tfennelly> magesh: sure... it's no prob... these things happen... we can just sort them out easy... no biggie
[14:05:51] <magesh> tfennelly: I did not say that it is no prob with the problem. I said no prob for the thanks :)
[14:05:53] <tfennelly> kcbabo: you see any of the above conversation magesh and I just had... summary... the camel-core module is responsible for assembling all the camel stuff, which is then used by the distro builds in release....
[14:06:20] <kcbabo> tfennelly:  I've been following at a distance
[14:06:29] <tfennelly> kcbabo: with the result that we have some funky deps e.g. camel-core depending on camel-as7, which is not what we want
[14:06:43] <tfennelly> kcbabo: peeping through the keyhole
[14:06:50] <kcbabo> tfennelly:  hehe ...
[14:07:07] <kcbabo> tfennelly:  so is this due to the fact that the camel component packaging is different between platforms?
[14:07:16] <kcbabo> tfennelly:  we include different bits for AS6 vs. AS7
[14:07:17] <tfennelly> kcbabo: seems like we need a module dedicated to producing the assembly, so as not to polute the camel-core pom
[14:08:01] <kcbabo> tfennelly:  cause the other components all use the same packaging approach - the component essentially packages itself
[14:08:15] <tfennelly> kcbabo: yeah.. that's part of the issue... but not the nub of it really... just that we're using the camel-core pom for 2 purposes really is the issue
[14:08:52] <kcbabo> tfennelly:  right, I'm just saying that you are seeing this issue with camel because of the as7-specific dependency
[14:09:06] <tfennelly> kcbabo: right.. but in the case of camel (not sure if it's the same for the others)... the assembly requirements mean we have some deps going the wrong direction
[14:09:37] <kcbabo> tfennelly:  I think we are talking about the same thing
[14:09:39] <tfennelly> kcbabo: ok... yeah... that sort of thing is what's creating the issue in that case
[14:09:55] <kcbabo> tfennelly: right, it's just an example
[14:10:04] <kcbabo> tfennelly:  so I guess there are two ways to go here
[14:10:34] <kcbabo> 1) completely externalize the packaging so that each component packaging has to be defined in a separate (perhaps shared) assembly module
[14:10:40] <tfennelly> kcbabo: not create a camel-cdi module is one, but I was guessing you'd want a sep module for it... you like them I think
[14:11:19] <kcbabo> 2) package everything up that's local to a module and if dependencies on other modules is required, then that has to happen in a separate module (e.g. camel as7 module)
[14:11:44] <tfennelly> kcbabo: right
[14:12:08] <tfennelly> kcbabo: becoming a bit of a maint nightmare
[14:12:42] <tfennelly> kcbabo: really... I'd like to see all this assembly for as6, as7 etc done in the release distro modules
[14:12:59] <tfennelly> kcbabo: vs scattering it all over the place
[14:13:19] <kcbabo> tfennelly:  yeah, I guess a case can be made for both directions
[14:13:20] <tfennelly> kcbabo: anyway... that's going off the point a bit... sorry
[14:13:34] <kcbabo> tfennelly:  no, I think it's a good discussion to have
[14:13:49] <tfennelly> kcbabo: btw... those assemblies are as7 specific
[14:15:08] <tfennelly> kcbabo: i.e. they're useless for as6 or anything else we decide to do
[14:15:30] <kcbabo> tfennelly:  it would be interesting to see what a shared module for this would look like
[14:15:45] <kcbabo> tfennelly:  another dist that's gonna come soon is OSGi
[14:16:12] <tfennelly> kcbabo: the more I think about it the more I think it should all be done by the release distros themselves
[14:16:29] *** aamonten has joined #switchyard
[14:16:34] <kcbabo> tfennelly:  so let's say it's in release
[14:17:20] <kcbabo> tfennelly:  there would be a directory structure where we have the various assembly instructions and module definitions for each one?
[14:17:32] <tfennelly> kcbabo: if in the release... they would be solely responsible for pulling all deps in and assembling them into the target structure
[14:17:37] <tfennelly> kcbabo: right
[14:17:51] <tfennelly> kcbabo: as6 is done this way... it is not able to use those assemblies
[14:18:04] <kcbabo> tfennelly:  it's interesting - would have to see how crazy the layout became
[14:18:23] <kcbabo> tfennelly:  if it's nice and logical, then putting the stuff in one place might be nice
[14:18:27] <tfennelly> kcbabo: it just pulls in the deps... creates the structures it needs and then copies them into the target distro... then zips it all up
[14:18:43] <kcbabo> tfennelly:  well, the module definitions are there as well, right?
[14:19:27] <tfennelly> kcbabo: for as7? ... nope... all that is done in the modules themselves I think... in those assemblies
[14:19:42] <kcbabo> tfennelly:  it is today, yes
[14:19:55] <kcbabo> tfennelly:  so I guess I don't understand what we are pulling out then
[14:19:55] <tfennelly> kcbabo: oh right.. sorry
[14:20:15] <kcbabo> tfennelly:  let's continue this on the call this morning - I have to drive the bus to school ;-)
[14:20:27] <tfennelly> kcbabo: for as6... you would not be doing all that much I think because it is done this way anyway... for as7...
[14:20:35] *** kcbabo has quit IRC
[14:21:05] <tfennelly> kcbabo: all that assembly work for as7 that's currenly being done in each module would instead be done in one place... in the release distro
[14:55:10] *** ldimaggi has joined #switchyard
[15:11:13] *** rcernich has joined #switchyard
[15:17:01] *** bfitzpat has joined #switchyard
[15:33:17] *** tfennelly has quit IRC
[15:39:26] *** kcbabo has joined #switchyard
[15:49:52] *** tfennelly has joined #switchyard
[15:51:08] <wyer> hey guys
[15:51:19] <rcernich> hey
[15:51:26] <wyer> the switchyard.bean forge plugin is foobar it seems
[15:52:39] <wyer> http://www.fpaste.org/VvYm/
[15:53:15] <kcbabo> wyer:  rm -rf ~/.m2/repository/org/switchyard
[15:53:41] <kcbabo> wyer:  my guess is that you have stale core artifact in your repo - probably api
[15:53:50] <wyer> kcbabo, thanks tactical nuke inbound
[15:54:22] <kcbabo> wyer:  are you building core when this occurs?
[15:54:35] <kcbabo> wyer:  or are you using Forge itself?
[15:54:48] <kcbabo> wyer:  sorry, should have asked prior to hitting the nuke button
[15:54:51] <wyer> kcbabo, using forge
[15:54:58] *** errantepiphany has joined #switchyard
[15:55:07] <wyer> kcbabo, when installing the plugin into forge
[15:55:11] <kcbabo> wyer:  k, temporarily disregard my prior instruction
[15:55:17] <kcbabo> wyer:  which forge version?
[15:55:19] <wyer> kcbabo, too late :P
[15:55:24] <kcbabo> wyer:  ah, no biggie
[15:55:27] <wyer> kcbabo, master ;)
[15:55:46] <wyer> switchyard plugin and switchyard.soap install fine
[15:56:55] <kcbabo> wyer:  you are using a local build of forge and you have copied all the SY forge jars in from a nightly build ?
[15:57:10] <kcbabo> wyer:  trying to get a feel for what your environment is here
[15:58:26] <wyer> kcbabo, sure sorry let me answer, a local build of forge master as of 30 min ago with an  local build of SY as of 6 hours ago (With SWITCHYARD-329 if thats not on master yet)
[15:59:13] <kcbabo> wyer:  k, I still think it's a stale artifact issue then
[15:59:29] <kcbabo> wyer:  CNF exception with a class that definitely exists
[15:59:31] <wyer> kcbabo, i am installing into forge with: forge source-plugin /path/to/plugin/source
[15:59:38] <wyer> kcbabo, yeah
[15:59:55] <kcbabo> wyer:  oh, now you are really off the radar
[16:00:04] <wyer> kcbabo, rebuilding it now
[16:00:15] <wyer> kcbabo, how so ?
[16:00:21] <kcbabo> wyer:  use the recommended/test way of copying in the jars to $FORGE_HOME/lib
[16:00:32] <kcbabo> wyer:  I have had mixed success with other methods in the past
[16:00:49] <wyer> kcbabo, ah okay will do so, was following https://docs.jboss.org/author/display/SEAMFORGE/Make+your+Plugin+available+to+Forge
[16:01:02] <kcbabo> wyer:  yeah, I would use our instructions instead
[16:03:31] *** errantepiphany has left #switchyard
[16:03:57] *** errantepiphany has joined #switchyard
[16:05:14] <wyer> kcbabo, is supporting AS7 domain mode on the cards yet just wondering
[16:06:14] <kcbabo> wyer:  yes
[16:06:52] <wyer> awesome
[16:18:02] *** mriet has joined #switchyard
[16:18:45] *** mriet has quit IRC
[16:26:35] *** antollinim has joined #switchyard
[16:31:48] *** rcernich is now known as rcernich_brb
[16:57:26] <ldimaggi> kcbabo, have to drop off - bye!
[16:57:48] <wyer> errantepiphany, hi David
[16:57:52] <bfitzpat> kcbabo - me too, sorry
[16:58:10] <errantepiphany> wyer: Hey Justin. I'm in a meeting right now, sorry....
[16:58:27] <errantepiphany> wyer: I'll let you know when we're done.
[17:01:27] <dbevenius1> kcbabo: I need to head off in a few mins
[17:02:26] *** ldimaggi has quit IRC
[17:03:23] <antollinim> kcbabo: hi Keith, have a minute?
[17:03:39] <kcbabo> antollinim:  on a meeting at the moment
[17:03:46] <kcbabo> antollinim:  will ping you later if that's ok?
[17:03:55] <antollinim> kcbabo: sure, thanks
[17:04:08] *** dbevenius1 has quit IRC
[17:11:28] *** rbalent has quit IRC
[17:17:29] <errantepiphany> wyer: I'm out of the meeting but now I have an appointment. I'll be back soon.
[17:17:39] *** errantepiphany is now known as ee_appt
[17:18:16] *** ldimaggi has joined #switchyard
[17:23:17] *** rcernich_brb is now known as rcernich
[17:24:35] *** magesh has left #switchyard
[18:12:55] *** antollinim is now known as antollinim_lunch
[18:16:30] *** ldimaggi has quit IRC
[18:26:02] <tfennelly> kcbabo: in a bit of trouble with AS7 classloading... have 2 mins?
[18:28:23] *** ldimaggi has joined #switchyard
[18:28:40] <rcernich> tfennelly: maybe i can help?
[18:29:05] <tfennelly> rcernich: thanks Rob....
[18:29:08] <rcernich> tfennelly: i spent some time in cl purgatory last week
[18:29:27] <tfennelly> rcernich: haha... well it will be an easy one for you then
[18:29:44] <kcbabo> tfennelly:  yeah, what's up?
[18:29:45] <rcernich> tfennelly: we'll see;)
[18:29:52] *** aamonten is now known as aamonten_afk
[18:30:48] <tfennelly> rcernich: so in the camel component I have some code that uses the ServiceLoader to load a class, the default of which also happens to be in the camel component
[18:31:15] <tfennelly> rcernich: when running on AS7 I get a java.lang.NoClassDefFoundError
[18:31:48] <tfennelly> rcernich: do I need to export the class package in the module.xml ?
[18:32:06] <tfennelly> rcernich: wouldn't have thought so, considering the class is in the same package
[18:32:23] <rcernich> tfennelly: does the extension module have a dependency on the camel component?
[18:32:29] <tfennelly> rcernich: ah no... wrong analysis
[18:32:35] <rcernich> tfennelly: also, could it be something upstream?
[18:33:04] <rcernich> tfennelly: e.g. the interface has a dependency on something coming from another module?
[18:33:15] <tfennelly> rcernich: so since it is actually java.util.ServiceLoader that's trying to load the class, I would need to "export" it in some way, right?
[18:33:27] <rcernich> tfennelly: ahh
[18:33:44] <tfennelly> Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.switchyard.component.camel.cdi.CDIAwareRegistry
[18:33:44] <tfennelly> 	at java.lang.Class.forName0(Native Method) [:1.6.0_26]
[18:33:44] <tfennelly> 	at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
[18:33:45] <tfennelly> 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345) [:1.6.0_26]
[18:33:53] <tfennelly> rcernich: ^^^
[18:34:10] <tfennelly> rcernich: that would be it Rob, yeah?
[18:34:21] <rcernich> tfennelly: yeah
[18:34:27] <tfennelly> rcernich: need to export it so java.util.ServiceLoader can see it
[18:34:58] <tfennelly> rcernich: okidoki... next question... where do they keep the xsd for the <module> xml?
[18:35:03] <tfennelly> rcernich: which jar?
[18:35:08] <tfennelly> rcernich: do you know
[18:36:46] <rcernich> tfennelly: looking
[18:40:02] <rcernich> tfennelly: https://docs.jboss.org/author/display/MODULES/Module+descriptors
[18:40:20] *** kcbabo has quit IRC
[18:40:21] <tfennelly> rcernich: awesome... thanks Rob
[18:40:46] <rcernich> tfennelly: does your interface use classes from other components?
[18:40:58] <tfennelly> rcernich: this makes me wonder though... how did magesh get all this working for PackageScanClassResolver
[18:41:05] <rcernich> tfennelly: if so, you may want to export those dependencies
[18:42:11] <tfennelly> rcernich: right... need to look at that... puzzled how/if this works for PackageScanClassResolver though
[18:42:34] <tfennelly> rcernich: in theory... looks like it should suffer from the same problem
[18:42:54] <tfennelly> rcernich: don't see anything special for it in the modules.xml file though
[18:51:43] <tfennelly> rcernich: everything is exported by default, so that's not the issue it seems
[18:53:50] <rcernich> tfennelly: where are you calling service loader from?
[18:54:16] <tfennelly> rcernich: the camel component code... CamelActivator class
[18:56:41] *** antollinim_lunch is now known as antollinim
[18:57:21] <tfennelly> rcernich: must be something to do with one of the classes CDIAwareRegistry depends on... I'll dig into that... thanks rob
[18:58:09] <rcernich> tfennelly: that would be my guess.  if the module implementing that service doesn't have that dependency, that would cause its parent to fail to load
[18:58:31] <rcernich> tfennelly: and java doesn't tell you why it didn't load
[18:58:58] <tfennelly> rcernich: yeah... I'll just start commenting stuff out 'till I find the culprit
[18:59:53] *** ee_appt has left #switchyard
[19:00:37] *** errantepiphany has joined #switchyard
[19:04:55] <rcernich> tfennelly: could it be the dependencies on the bean component?
[19:05:31] <rcernich> tfennelly: e.g. BeanDeploymentMetaData and CDIBean
[19:06:47] <tfennelly> rcernich: yep... could well be
[19:07:02] <tfennelly> rcernich: I prob need to import them then I guess
[19:07:08] <rcernich> tfennelly: the odd thing is, if this is invoked during deployment, that should be in the classpath
[19:07:14] <tfennelly> rcernich: oh... add them as a dep in the module of course
[19:07:50] <tfennelly> rcernich: yeah... not sure... the as7 modules thing is new to me
[19:07:52] <rcernich> tfennelly: i believe the subsystem adds all the modules defined in the subsystem config as dependencies on the application
[19:08:45] <rcernich> tfennelly: not sure how that interacts with service loader
[19:11:16] <tfennelly> rcernich: I bet you're right wrt to the bean code... I hadn't added the module for those to the camel component's module
[19:11:21] <tfennelly> rcernich: testing that now
[19:14:16] <rcernich> tfennelly: i have to run, back in about 30 mins
[19:14:26] *** rcernich is now known as rcernich_brb
[19:39:44] *** tfennelly has quit IRC
[19:49:49] *** kcbabo has joined #switchyard
[19:50:12] *** rcernich_brb is now known as rcernich
[20:01:15] <rcernich> kcbabo: hey keith, got time for a quick git question?
[20:01:29] <kcbabo> rcernich:  sure thing
[20:02:23] <rcernich> kcbabo: is it possible to separate my changes for this admin stuff into separate branches?
[20:02:46] <kcbabo> rcernich:  need more info
[20:02:48] <rcernich> kcbabo: e.g. to separate out the as7 management operations from the actual admin classes
[20:03:03] <rcernich> kcbabo: i've got this a little better organized in my head now
[20:03:23] <kcbabo> rcernich:  do you mean like commit #1 goes in branch A
[20:03:23] <kcbabo> rcernich:  and commit #2 goes in branch B (which already contains A) ?
[20:03:35] <rcernich> kcbabo: yes
[20:03:43] <kcbabo> rcernich:  	yeah, that's possible
[20:03:52] <rcernich> kcbabo: i'm assuming i can create the second branch, then remove the commit from the first?
[20:03:55] <kcbabo> rcernich:  you need to commit your work in branch A
[20:04:16] <kcbabo> rcernich:  then create a new branch while in branch A.  The new branch, B, will inherit the current history of A
[20:04:22] <kcbabo> rcernich:  then commit other stuff in B
[20:04:33] <rcernich> kcbabo: and if it's already committed;)
[20:05:03] <kcbabo> rcernich: always an asterisk ....
[20:05:23] <rcernich> kcbabo: never mind
[20:05:32] <kcbabo> rcernich:  interesting question
[20:05:36] <rcernich> kcbabo: i didn't commit the changes separately
[20:05:51] <kcbabo> rcernich:  right, I think I understand
[20:05:53] <rcernich> kcbabo: so it doesn't matter
[20:06:23] <rcernich> kcbabo: i may scrap my changes and start over
[20:06:34] <kcbabo> rcernich:  it should be possible in theory, but I'm trying to sort what the commands would be
[20:06:52] <rcernich> kcbabo: i was guessing an interactive rebase that removed the commit
[20:07:00] <kcbabo> rcernich:  basically what you want to do is revert your last commit so that all the changes are simply staged
[20:07:06] <rcernich> kcbabo: e.g. kept commits 1, 2, 3, 5
[20:07:23] <kcbabo> rcernich:  then split that staged change up by stashing some of it and committing the rest
[20:07:47] <kcbabo> rcernich:  then unstash the remainder and commit that as part of a separate commit
[20:07:52] <kcbabo> rcernich:  in a new branch
[20:08:16] <rcernich> kcbabo: yeah, but i think, at this point, it's probably easier for me to just recreate the branch
[20:08:41] <rcernich> kcbabo: sorry for bothering you, i should have thought it out better before asking
[20:08:51] <kcbabo> rcernich:  no worries ? still thinking about it
[20:10:59] <kcbabo> rcernich:  ok, think I have it
[20:11:06] <kcbabo> rcernich:  one sec ? let me test
[20:12:10] <kcbabo> rcernich:  ok, first thing - make a copy of your repo to protect your changes!  :-)
[20:12:24] <kcbabo> rcernich:  I'm pretty sure that "git reset ?soft" is what you are after
[20:12:38] <kcbabo> rcernich:  is it just one commit that you want to break up?
[20:13:26] <rcernich> kcbabo: yes.
[20:13:36] <rcernich> kcbabo: does it matter that i've already pushed the changes?
[20:13:50] <kcbabo> rcernich:  to your own remote repo?  No, that doesn't matter
[20:13:58] <rcernich> kcbabo: whew
[20:14:30] <kcbabo> rcernich:  because you can always ( a ) delete that remote branch or ( b ) push a forced update or ( c) change branch names locally and push using a new branch name
[20:15:29] *** dbevenius has joined #switchyard
[20:15:50] <rcernich> kcbabo: here's what i was thinking...
[20:15:56] <kcbabo> rcernich:  ok, what you want to do is reset the current branch to HEAD~1, then stash the stuff you don't want to commit
[20:16:24] <kcbabo> rcernich:  so "git reset ?soft HEAD~1" should get you to the point where you have simply staged, but not committed your last commit
[20:16:40] <rcernich> kcbabo: ahh, that's cool
[20:17:33] <rcernich> kcbabo: i'll give it a try
[20:17:51] <rcernich> kcbabo: i have another branch with the changes, so i should be ok
[20:18:03] <rcernich> kcbabo: rewriting history only affects the active branch, correct?
[20:18:26] <kcbabo> rcernich:  correct
[20:18:38] <kcbabo> rcernich:  definitely make a backup of your stuff before proceeding
[20:18:48] <kcbabo> rcernich:  "cp -R" is your friend :-)
[20:19:08] <rcernich> kcbabo: :D
[20:19:40] <kcbabo> antollinim:  sorry about missing you earlier - what's up?
[20:20:49] <antollinim> kcbabo: np. I tried to improve the WSDL to avoid having to create Order and OrderType. I did not manage to do that.
[20:21:25] <kcbabo> antollinim:  I was just about to look at it right now, so give me a moment and I'll share an example of what I was thinking
[20:21:55] <antollinim> kcbabo: sure
[20:38:53] *** aslak has quit IRC
[20:50:50] *** jgraham_ has joined #switchyard
[20:53:05] <rcernich> kcbabo: worked like a charm
[20:53:11] <rcernich> kcbabo: we'll see how the commit goes
[20:53:20] <rcernich> kcbabo: thanks for the help
[20:53:22] <kcbabo> rcernich:  cool
[21:04:15] <kcbabo> antollinim:  here ya go:
[21:04:16] <kcbabo> https://github.com/kcbabo/quickstarts/tree/SWITCHYARD-333
[21:04:34] <antollinim> kcbabo: let's see
[21:04:46] <kcbabo> antollinim:  there's a couple things worth mentioning here
[21:05:34] <kcbabo> antollinim:  as we discussed previously, the orders quickstart uses it's own transformers to strip off  and add the doc/lit wrappers (submitOrder, submitOrderResponse)
[21:06:02] <antollinim> kcbabo: yes
[21:06:03] <kcbabo> antollinim:  if you are going to use JAXB with doc/lit wrapped, then that wrapper element is going to show up as an object type
[21:06:20] <kcbabo> antollinim:  that's where you thought things looked weird before
[21:06:51] <kcbabo> antollinim:  so I switched the WSDL to use plain-old doc-lit and it looks a bit cleaner
[21:07:12] <kcbabo> antollinim:  of course, it's pretty much up to the user which path they want to take
[21:07:54] <kcbabo> antollinim:  I did stumble across a bug in SOAP gateway while doing this, which you can find documented here:
[21:07:55] <kcbabo> https://issues.jboss.org/browse/SWITCHYARD-347
[21:08:11] <antollinim> kcbabo: so you changed the wsdl and then re-generated the jaxb objects? and then re-implemented the service bean?
[21:08:27] <kcbabo> antollinim:  the upshot of that is I had to ignore the WebServiceTest because SOAP gateway wasn't finding the operation when doc/lit was used
[21:08:31] <kcbabo> antollinim:  yep
[21:09:30] <antollinim> kcbabo: I was trying to write the proper wsdl to no avail...
[21:10:01] <kcbabo> antollinim:  "proper" is kind of a relative term ehre
[21:10:02] <kcbabo> here
[21:10:03] <antollinim> kcbabo: so you consider your transform-jaxb is ready now?
[21:10:23] <kcbabo> antollinim:  well, that test is ignored until the SOAP gateway can be fixed
[21:10:31] <antollinim> kcbabo: by proper I mean, having nicely loiking jaxb objects
[21:11:02] <antollinim> kcbabo: but did you try it with soapui, for example?
[21:11:06] <kcbabo> antollinim:  right and I think that's kind of relative to how individuals want to model it
[21:11:11] <antollinim> kcbabo: I mean, was it tested at all?
[21:11:55] <kcbabo> antollinim:  the type transformation test checks the JAXB transform
[21:12:14] <kcbabo> antollinim:  I accidentally removed a test in that now that I remember
[21:12:32] <kcbabo> antollinim:  anyway, there's no testing of the web service until the SOAP gateway issue is fixed
[21:12:41] <kcbabo> antollinim:  the only other option for now is to simply use doc/lit wrapped
[21:13:03] <antollinim> kcbabo: the soap gateway is in charge of gettin the soap service up?
[21:13:20] <kcbabo> antollinim: yep, that's what the soap gateway does
[21:13:34] <antollinim> kcbabo: ok, so no way to test it then
[21:14:06] <antollinim> kcbabo: thanks for your help
[21:14:07] <kcbabo> antollinim:  it can be tested within the runtime with XML messages
[21:14:11] <kcbabo> antollinim:  but not from SOAP
[21:14:22] <kcbabo> antollinim:  I'll take another crack with doc/lit wrapped and push that out
[21:14:42] <kcbabo> antollinim:  and you can take a look at how that shakes out
[21:14:59] <antollinim> kcbabo: good...
[21:15:08] <antollinim> kcbabo: in the meantime, any other task I can help with then?
[21:15:39] <kcbabo> antollinim:  I'll do my bit now, so there should be an updated quickstart in about 15 minutes
[21:15:57] <kcbabo> antollinim:  you can talk to magesh to see if maybe fixing the SOAP gateway bug is interesting
[21:16:18] <kcbabo> antollinim: but hopefully you can push this quickstart soon after I update it
[21:16:34] <kcbabo> antollinim:  one other thing about your test methods
[21:16:51] <antollinim> kcbabo: what's up?
[21:16:55] <kcbabo> antollinim:  I noticed you are using jUnit Assert instead of XMLUnit
[21:17:01] <kcbabo> antollinim:  I would use the latter when dealing with XML
[21:17:17] <kcbabo> antollinim:  takes care of whitespace and namespace issues that crop up between platforms
[21:17:45] <antollinim> kcbabo: ah, did not know that, I had to deal with that manually too
[21:17:55] <antollinim> kcbabo: thanks for the tip
[21:18:19] <kcbabo> antollinim:  right, which brings me to another item - it's generally more maintainable to store the XML test data in an external file, IMHO
[21:18:47] <antollinim> kcbabo: instead of having it hardcoded, you mean?
[21:18:50] <kcbabo> antollinim:  but that's not a project requirement
[21:18:58] <kcbabo> antollinim:  just my personal bias :-)
[21:19:07] <kcbabo> antollinim:  right, instead of having it in the Java source file
[21:19:28] <antollinim> kcbabo: no problem, best practices are there for a reason :)
[21:20:25] <antollinim> kcbabo: so I wait for your update and then I do the push?
[21:21:12] <kcbabo> antollinim:  yeah, although it would be good if you could take care of the XML issues we just discussed
[21:21:27] <kcbabo> antollinim:  I think there are examples in the quickstart that can serve as a basis
[21:22:10] <antollinim> kcbabo: yes, I'll improve the tests and will merge your code as well, ok?
[21:22:25] <kcbabo> antollinim:  right
[21:52:40] *** aslak has joined #switchyard
[22:08:39] *** dbevenius has quit IRC
[22:20:09] <rcernich> kcbabo: i followed the pattern in the man page for git-reset "interrupted workflow"
[22:20:18] <rcernich> kcbabo: seems to have worked
[22:20:41] <rcernich> kcbabo: next question: should i squash the commits before creating another topic branch?
[22:20:52] <rcernich> kcbabo: or does it matter
[22:21:01] <kcbabo> rcernich:  need a bit more context
[22:21:08] <rcernich> kcbabo: the only commits are your initial commit (which i pulled) and the commit i just made
[22:21:27] <kcbabo> rcernich:  you can't squash commits which have already been pushed to upstream
[22:21:48] <rcernich> kcbabo: ahh, did you push your changes upstream?
[22:22:06] <rcernich> kcbabo: i've only pushed your commit and my commit to my repo
[22:22:44] <rcernich> kcbabo: https://github.com/rcernich/core/commits/SWITCHYARD-338
[22:27:41] <kcbabo> rcernich:  oh, sorry
[22:27:52] <kcbabo> rcernich:  thought we were talking about something else
[22:27:55] <rcernich> kcbabo: no worries
[22:28:00] <kcbabo> rcernich:  squishing into one commit would be best I thikn
[22:28:02] <kcbabo> think
[22:28:11] <kcbabo> rcernich:  it will still give author attribution
[22:28:21] <rcernich> kcbabo: okie doke
[22:28:33] <kcbabo> rcernich:  I have to drop for a bit, but I'll be back online later in case something goes wrong :-)
[22:28:44] <rcernich> kcbabo: ok, thanks
[22:28:45] *** kcbabo has quit IRC
[22:29:10] *** aamonten_afk has quit IRC
[22:33:46] *** rcernich is now known as rcernich_lunch
[22:47:25] *** lanceball has joined #switchyard
[22:58:28] *** ldimaggi has quit IRC
[23:11:06] *** antollinim has quit IRC
[23:15:49] *** rcernich_lunch is now known as rcernich
[23:29:29] *** lanceball has quit IRC





top