[00:28:28] *** errantepiphany has left #switchyard
[01:10:34] *** bfitzpat has quit IRC
[01:46:37] *** antollinim has quit IRC
[02:54:36] *** rcernich_away is now known as rcernich
[03:14:41] *** ldimaggi has joined #switchyard
[03:42:15] *** javahorn has quit IRC
[04:05:07] *** rcernich has quit IRC
[04:23:57] *** magesh has joined #switchyard
[04:48:39] *** antollinim has joined #switchyard
[05:07:31] *** antollinim has left #switchyard
[05:30:01] *** dbevenius has joined #switchyard
[06:03:08] *** echelog-2 has joined #switchyard
[06:10:09] *** ldimaggi has quit IRC
[07:31:21] *** echelog-2 has joined #switchyard
[07:47:52] *** magesh1 has joined #switchyard
[07:51:32] *** magesh has quit IRC
[08:01:06] *** magesh1 has quit IRC
[10:19:12] *** magesh has joined #switchyard
[11:51:20] *** rbalent has joined #switchyard
[11:51:20] *** rbalent has joined #switchyard
[12:08:08] <gaYak> Does anyone have experience of frontend for ESB solutions?
[12:09:46] <gaYak> Deployed to DMZ and would mostly do routing to backend systems
[12:09:58] <gaYak> Such as the SOA-P or SwitchYard or what not.. SFTP -> JMS etc
[12:12:12] <gaYak> Seems like everything is just bundled with something else I don't want/need.
[13:19:39] *** kcbabo has joined #switchyard
[14:18:08] *** igarashitm has joined #switchyard
[14:22:41] *** igarashitm has quit IRC
[14:34:32] *** igarashitm has joined #switchyard
[14:43:02] *** lanceball has joined #switchyard
[15:12:11] *** mriet has joined #switchyard
[15:12:37] *** ldimaggi has joined #switchyard
[15:13:52] *** mriet has quit IRC
[15:33:42] *** antollinim has joined #switchyard
[15:38:14] *** bfitzpat has joined #switchyard
[16:11:16] *** rcernich has joined #switchyard
[16:23:58] *** errantepiphany has joined #switchyard
[16:27:40] *** magesh1 has joined #switchyard
[16:30:04] *** magesh has quit IRC
[17:01:17] *** dbevenius has left #switchyard
[17:03:01] <kcbabo> errantepiphany:  I'm OK with validation at build-time in general, but not at the end of the release
[17:03:15] <kcbabo> errantepiphany:  haven't had enough time to sort through any side effects it might cause
[17:04:32] <errantepiphany> kcbabo: I disagree with you, but you're the boss. I can comment out the one line in the switchyard maven plugin that does that, and create a 0.3 jira to uncomment it.
[17:04:55] <kcbabo> errantepiphany:  that will work
[17:06:05] <kcbabo> errantepiphany:  although I think we should make schema validation in both tests and build optional
[17:06:17] <kcbabo> errantepiphany:  default to on, but can be set to false
[17:06:36] <kcbabo> errantepiphany:  not for 0.2, but for 0.3
[17:08:38] <errantepiphany> kcbabo: why would anyone ever want invalid config?
[17:09:21] <kcbabo> errantepiphany:  that assumes what exits our build/configure plugin is the final version of the config
[17:09:25] <errantepiphany> kcbabo: I will 'push -f' momentarily with the change.
[17:09:50] <kcbabo> errantepiphany:  there may, for example, be a user-introduced plugin or post-processing step that changes the config
[17:10:15] <kcbabo> errantepiphany:  I don't anticipate that it's a common use case, but it's definitely something that we should leave open
[17:10:27] <errantepiphany> kcbabo: understood.
[17:10:36] <kcbabo> errantepiphany:  the common use case would be for the final config to be generated by us and that's why I think a default of validation=true is good
[17:13:10] *** errantepiphany has left #switchyard
[17:17:57] *** errantepiphany has joined #switchyard
[17:49:17] <errantepiphany> kcbabo: I added a new parameter to the maven switchyard plugin <validate>true|false</validate>. The default is now defined as false. However, now that there IS a mechanism to disable it, can the default be true?
[17:54:31] <kcbabo> errantepiphany:  yeah, that's fine
[17:54:43] <errantepiphany> kcbabo: hehehe - we BOTH win!
[17:54:56] <kcbabo> errantepiphany:  :-)
[17:59:02] *** magesh has joined #switchyard
[17:59:43] <errantepiphany> kcbabo: It looks like github fixed their issue of not updating the diffs of a commit when someone overwrites with a "push -f". I now see my change in the commit associated with the pull requst.
[18:00:01] <kcbabo> errantepiphany:  ah, nice ? good for them
[18:00:11] <errantepiphany> kcbabo: http://goo.gl/Kgebe
[18:01:29] *** magesh1 has quit IRC
[18:08:55] *** magesh has left #switchyard
[18:32:07] *** rbalent has quit IRC
[18:50:49] *** lanceball has quit IRC
[18:51:15] *** lanceball has joined #switchyard
[18:51:56] *** lancebal_ has joined #switchyard
[18:52:02] *** lancebal_ has quit IRC
[18:52:26] *** lancebal_ has joined #switchyard
[18:55:29] *** lanceball has quit IRC
[18:56:51] *** lancebal_ has quit IRC
[18:56:52] <errantepiphany> kcbabo: Do I need to copy all the original-switchyard*.jar files into $FORGE_HOME/lib, or just the switchyard*.jar files?
[18:57:28] <kcbabo> errantepiphany:  just switchyard-forge-*
[18:57:55] <kcbabo> errantepiphany:  I'm gonna chow and then I'll push your pull request
[18:58:02] <kcbabo> errantepiphany:  sorry, got hung up on something else
[18:58:02] <errantepiphany> kcbabo: thx
[18:58:07] <errantepiphany> kcbabo: no worries
[18:58:23] *** kcbabo is now known as babo_brb
[19:55:31] *** babo_brb is now known as kcbabo
[20:21:38] <kcbabo> errantepiphany:  out of curiosity, did you try building the test app I attached to the JIRA with your changes?
[20:23:49] <errantepiphany> kcbabo: yes, and it built with the proper order after the fix. I didn't try running it, though.
[20:24:16] <kcbabo> errantepiphany:  hmmm ?. something's up there, because when I build with it, I get a schema error
[20:24:26] <kcbabo> errantepiphany:  schema error is correct (and surprising)
[20:24:42] <kcbabo> errantepiphany:  multiplicity attribute on composite level reference is required
[20:26:46] <errantepiphany> kcbabo: oh, right. You should add that to your <reference> in src/main/resources/....etc
[20:27:09] <kcbabo> errantepiphany:  problem is I'm gonna have to add that to our implementation as well
[20:27:27] <kcbabo> errantepiphany:  otherwise forge tooling is creating invalid composite definition ? bleh
[20:29:32] <errantepiphany> kcbabo: well, 2 choices: add a hardcoded multiplicity="1..1" to what the forge tooling spits out, or change the default to false for the validate parameter of the maven plugin.
[20:30:05] <kcbabo> errantepiphany:  well, this is a real problem, so I think it needs to be fixed
[20:30:14] <kcbabo> errantepiphany:  so validation should remain
[20:30:26] <errantepiphany> kcbabo: I can go back in and add it to the forge plugin if you want.
[20:30:27] <kcbabo> errantepiphany:  but this setting really has no impact from a user standpoint
[20:30:41] <kcbabo> errantepiphany:  nah, don't worry about that
[20:30:47] <errantepiphany> kcbabo: are you going to do it then?
[20:30:52] <kcbabo> errantepiphany:  thinking about how deep I want to dig this hole
[20:30:55] <kcbabo> errantepiphany:  yeah, I'll do it
[20:31:11] <errantepiphany> kcbabo: it's not really that deep. And I'm all set up to do it in my workspace if you want me to...
[20:31:31] <kcbabo> errantepiphany:  well, I think probably the proper thing is to add it in the config layer
[20:31:48] <kcbabo> errantepiphany:  but thinking about it, you were probably just gonna call setModelAttribute or some such thing from forge?
[20:31:57] <kcbabo> errantepiphany:  which produces less fallout
[20:32:00] <kcbabo> errantepiphany:  I gues
[20:32:01] <kcbabo> s
[20:32:14] <errantepiphany> kcbabo: you mean ask the user what they want for multiplicity? Since it doesn't affect them yet, I would just hardcode add it or now.
[20:32:30] <errantepiphany> kcbabo: yup.
[20:32:34] <kcbabo> errantepiphany:  no, I meant what method are you gonna call on the config model to add this attribute
[20:32:39] <kcbabo> errantepiphany:  definitely don't ask the user :-)
[20:33:53] <kcbabo> errantepiphany:  setModelAttribute is protected in the config class, so I think this will require some changes in config
[20:34:14] <errantepiphany> kcbabo: I was gonna add a set/getMultiplicity(String) to (V1)ComponentReferenceModel.
[20:34:35] <errantepiphany> kcbabo: which calls the protected method(s)
[20:34:40] <errantepiphany> kcbabo: but default it to "1..1"
[20:34:49] <errantepiphany> kcbabo: that is the *correct* way of doing it
[20:35:01] <errantepiphany> kcbabo: instead of changing the visibility o the setModelAttribute method
[20:35:10] <errantepiphany> kcbabo: why don't you let me do it?
[20:35:20] <kcbabo> errantepiphany:  oh yeah, not suggesting a change to setModelAttribute
[20:36:38] <kcbabo> errantepiphany:  so the only other thing I was wondering is whether ComponentReferenceModel should default to that value in it's constructor
[20:37:39] <kcbabo> errantepiphany:  that provides a sensible default when creating the reference (for example, forge tooling will not have to change)
[20:38:03] <kcbabo> errantepiphany:  ah, anyway ? if you can fix it up that would be great
[20:38:09] <errantepiphany> kcbabo: If we do it in the constructor as a sensible default, then neither the forge tooling nor the switchyard scanner has to change.
[20:38:18] <kcbabo> errantepiphany:  right
[20:38:28] <errantepiphany> kcbabo: okay I'll do it now.
[20:38:33] <errantepiphany> kcbabo: sorry for the trouble.
[20:38:34] <kcbabo> errantepiphany:  cool, thanks
[20:38:44] <kcbabo> errantepiphany:  not at all ? it's my fault really
[20:38:58] <kcbabo> errantepiphany:  completely caught me by surprise that this was required
[20:39:16] <kcbabo> errantepiphany:  I should have caught it when I added the option to forge
[20:40:00] <errantepiphany> kcbabo: well, the forge tooling doesn't validate... https://issues.jboss.org/browse/SWITCHYARD-427 ;)
[20:40:19] <errantepiphany> kcbabo: otherwise, it would have become obvious.
[20:40:34] <kcbabo> errantepiphany:  :-)
[20:40:43] <kcbabo> errantepiphany:  eh ? it all gets caught by the build ;-)
[21:04:50] *** ldimaggi has quit IRC
[21:10:54] <kcbabo> errantepiphany:  I'm switching to work on the only remaining issue for 0.2 - which is adding the hornetq binding to the distro
[21:11:05] <kcbabo> errantepiphany:  I'm going to stage the release tonight
[21:11:11] <errantepiphany> kcbabo: okay; almost done - testing... I'll ping you.
[21:11:24] <errantepiphany> kcbabo: I'll have my docs done before tonight.
[21:11:49] <kcbabo> errantepiphany:  need to head out in about 20 minutes, but if I don't catch the change before then, I'll get it tonight
[21:11:58] <errantepiphany> kcbabo:  no worries
[21:12:17] <kcbabo> errantepiphany:  ok, the docs want go in the distro, so don't feel like you have to kill yourself to get 'em done by tonight
[21:12:33] <kcbabo> errantepiphany:  won't
[21:12:41] <errantepiphany> kcbabo: well what's the process for getting stuff out of confluence and into git?
[21:12:57] <kcbabo> errantepiphany:  they go in github for sure
[21:13:09] <kcbabo> errantepiphany:  but that's separate than producing the downloaded switchyard distro
[21:13:18] <kcbabo> errantepiphany:  I will create the 0.2 branch tonight
[21:13:20] <errantepiphany> kcbabo: okay then.
[21:13:22] <errantepiphany> 0.3.
[21:13:25] <errantepiphany> ?
[21:13:26] <kcbabo> errantepiphany:  setup a hudson release build for that
[21:13:36] <errantepiphany> kcbabo: oh wait, right.
[21:13:37] <kcbabo> errantepiphany:  then we cut the release bits off that hudson build
[21:13:47] <kcbabo> errantepiphany:  after that, we can commit the confluence docbook to 0.2 branch
[21:14:01] <errantepiphany> kcbabo: now I get it.
[21:14:19] <kcbabo> errantepiphany:  bit of a hassle with confluence, but oh well
[21:19:37] *** ldimaggi has joined #switchyard
[21:31:08] <errantepiphany> kcbabo: okay, ready to rock - but with a twist. 1) I "push -f" 'ed in both core and components, which contains the change that adds multiplicity of 1..1 by default, 2)...
[21:32:17] <errantepiphany> kcbabo: 2) According to the sca schema, multiplicity is only required on composite references, NOT component references. So although I added the set/getMultiplicity accessors to both, I only default the composite reference to "1..1".  In the example you gave me, the ordering is fixed, however multiplicity does NOT have to be there.
[21:32:48] <errantepiphany> kcbabo: Sooo... I'm wondering what's up with your environment. I would suggest blowing away ~/.m2/repository/org/switchyard and starting clean with parent, core, components, quickstarts, console, release.
[21:33:08] <errantepiphany> kcbabo: then try to build your "soapcamel" app again (cleanly too, of course).
[21:34:33] <kcbabo> errantepiphany:  ok, thanks david
[21:34:43] <kcbabo> errantepiphany:  I'll give this a whirl when I get back
[21:34:45] <errantepiphany> kcbabo: np
[21:35:29] <errantepiphany> kcbabo: thx
[21:41:06] <antollinim> kcbabo: quick question. Do you know how to create a reference with forge?
[21:41:32] <antollinim> kcbabo: I cannot find the command for that
[21:42:17] <errantepiphany> kcbabo: oops. Actually I just push -f 'd core. I had done in components but must've forgotten core. I know you weren't going to do it until later anyway, so we should still be cool.
[23:16:51] *** ldimaggi has quit IRC
[23:23:31] *** kcbabo has quit IRC
[23:39:16] *** igarashitm has quit IRC
[23:43:25] *** babo has joined #switchyard
[23:44:01] <babo> errantepiphany: ok, so we're cool with the updates now, right?
[23:44:02] <errantepiphany> babo: are you back?
[23:44:05] <errantepiphany> :)
[23:44:18] <babo> errantepiphany:  indeed .. temporarily :-)
[23:44:31] <errantepiphany> babo: yes, make sure you pull core, components and quickstarts fresh from my remote repo, though.
[23:44:45] <babo> errantepiphany:  ok, will do
[23:48:59] <babo> bfitzpat:  hey brian, got a jboss tools question for ya
[23:49:22] <babo> bfitzpat:  we are putting together some content for USB sticks
[23:50:45] <babo> bfitzpat:  so I should be able to just download the zip from here, right?
[23:50:50] <babo> http://www.jboss.org/tools/download/dev
[23:54:04] <bfitzpat> babo - sorry, was at school with my daughters for a meeting with a teacher
[23:54:17] <bfitzpat> looking for JBDS or JBoss Tools?
[23:54:38] <babo> bfitzpat: it's ok, I just asked the question three minutes ago :-)
[23:54:48] <babo> bfitzpat:  JBoss Tools
[23:55:02] <babo> bfitzpat:  unfortunately, I have to put the stuff on the stick tonight
[23:55:10] <babo> bfitzpat:  so I'm a bit nervous about using a nightly :-)
[23:56:14] <bfitzpat> yup... looking...
[23:56:32] <bfitzpat> you need AS7 support, right?
[23:56:42] <bfitzpat> so that means JBT 3.3
[23:57:15] <bfitzpat> http://www.jboss.org/tools/download
[23:57:23] <bfitzpat> should have all the links you need to the M2 milestone
[23:57:45] <bfitzpat> if you want to update to the latest trunk for AS7 fixes,
[23:57:46] <bfitzpat>  * JBT 3.3 Nightly Trunk -
[23:57:46] 
[23:57:46] 
[23:57:46] <bfitzpat> * JBT 3.3 SOA Tooling Nightly Trunk -
[23:57:46] 
[23:57:47] <bfitzpat>
[23:58:49] <bfitzpat> babo ^^^^ - hope all that helps. 3.3 M2 should be pretty stable, but we're almost at code freeze for M3, so trunk should be pretty stable as well
[23:59:14] <babo> bfitzpat:  I'm thinking I will put M2 on the main set of sticks
[23:59:26] <babo> bfitzpat:  and then bring M3 with me on the "extra stuff" sticks





top