[00:29:13] *** ldimaggi has joined #switchyard
[01:30:42] *** kcbabo has joined #switchyard
[01:30:42] *** kcbabo has joined #switchyard
[01:52:43] *** lance|afk has joined #switchyard
[01:52:49] *** lance|af_ has quit IRC
[02:16:24] *** kcbabo has quit IRC
[03:08:50] *** tcunning has joined #switchyard
[03:49:44] *** lance|afk has quit IRC
[04:03:39] *** ldimaggi has quit IRC
[05:03:36] *** tcunning has quit IRC
[05:04:15] *** magesh has joined #switchyard
[06:59:50] *** dbevenius has joined #switchyard
[07:36:42] *** magesh has left #switchyard
[07:39:51] *** magesh has joined #switchyard
[09:01:04] *** rbalent has joined #switchyard
[09:01:04] *** rbalent has joined #switchyard
[10:47:43] *** vinicius has joined #switchyard
[11:55:34] *** kcbabo has joined #switchyard
[11:55:34] *** kcbabo has joined #switchyard
[13:18:07] *** igarashitm has joined #switchyard
[13:25:46] <gaYak> mm, might be stupid thinking.. but I'll blubber it out anyway. Regarding the Camel bindings, now everything is configured in the XML files (making SwitchYard very static), would it be possible in the future to put the Registry to say Infinispan and load the Camel Routes from there?
[13:25:50] <gaYak> And then be able to refresh them?
[13:26:01] <gaYak> In other words, add dynamically while the Service is running new Camel inputs?
[13:26:19] <gaYak> Thus say one has a service that picks up files from different locations using Camel
[13:26:34] <gaYak> If I needed a new customer, I could just add through JMX / some other gateway new Camel inputs
[13:26:48] <gaYak> Without needing to restart / redeploy anything
[13:27:13] <gaYak> This is something I'm doing in my our JBossESB service (rewriting the Camel Gateway there)
[13:27:18] <gaYak> .. in our.
[13:28:07] <gaYak> And that's usually because we have ESB on the backend, while we have some front-end service with SFTP server and then we fetch them from the front-end to our backend service
[13:28:18] <gaYak> And same service then has hundreds of customers
[13:28:38] <gaYak> And this isn't of course saying that one couldn't also from XML file add the inputs, but that there would also be a more dynamic way of adding them
[13:29:22] <gaYak> But is there anywhere at the moment, where to save and read this information?
[13:29:30] <gaYak> CamelContext itself provides the means to managing routes
[13:30:43] <gaYak> The reason why Infinispan or something is useful is that two different instances of SwitchYard shouldn't try same Camel inputs with all protocols
[13:30:51] <gaYak> Say they want to fetch from the same FTP server
[13:31:02] <gaYak> That could create duplicates, so different nodes should communicate together, who is responsible
[13:31:28] <gaYak> That's part of the multi-HA-what-not-ticket-that's-been-postponed-to-sometime, but still.
[13:32:36] <gaYak> Anyway, random thoughts.. I'll go back to fight with loading SwitchYard components to any IDE..
[13:45:19] *** ldimaggi has joined #switchyard
[13:46:09] <gaYak> That Guvnor NG discussion is .. sort of the same area, but not quite.
[14:26:47] <magesh> gaYak: Hi could you please jot these thoughts in teh forum?
[14:26:55] <magesh> (the)
[14:29:41] *** tcunning has joined #switchyard
[14:30:52] <gaYak> Yea, sure
[14:31:12] <gaYak> I just like to output random thoughts to IRC always.. ;)
[14:41:13] *** bfitzpat has joined #switchyard
[14:42:00] *** lanceball has joined #switchyard
[14:42:04] *** tcunning has left #switchyard
[14:43:56] *** rcernich has joined #switchyard
[14:44:08] *** rcernich has joined #switchyard
[14:46:20] <gaYak> Is there btw magesh instructions somewhere how to get SwitchYard to work with some IDE? Is there an order in which the git repositories should be loaded?
[14:46:42] <gaYak> In NetBeans I get lots of errors, seems they can't find the parts and my Eclipse.. well, it just hangs if I try to load SwitchYard directory ;)
[14:47:34] <magesh> gaYak: Did you try Eclipse? Forge is something on the CLI
[14:47:56] <gaYak> Yea, I loaded core/components/parent/etc to my Eclipse
[14:48:01] <gaYak> Well, first with command line git
[14:48:10] <gaYak> And then tried to import the directory which had all of them
[14:48:18] <gaYak> But that's forever hanging Eclipse
[14:48:35] <gaYak> "importing maven project, updating maven dependencies.. "
[14:48:50] <magesh> gaYak: Eclipse downloads most of the maven artifacts, you need to set the repo properly and wait for it to sync with your maven setup
[14:48:51] <gaYak> That never finishes (this isn't the only project that does it for Eclipse though)
[14:49:06] <magesh> gaYak: Yeah what speeds are you in ;)
[14:49:21] <gaYak> No idea .. prolly 200/200 or whatever this corporate network is at the moment
[14:49:34] <gaYak> My Maven from command line is quick enough
[14:49:44] <gaYak> But m2eclipse never is
[14:50:05] <magesh> gaYak: Hmm ... then your setting in Eclipse may not point to the same repo directory as the CLI one
[14:53:38] <gaYak> mm, I hope it would..
[14:53:45] <gaYak> Maybe I'll leave it for the night
[14:53:51] <gaYak> Maybe it has survived past the magical 36%
[14:54:39] <magesh> gaYak: lol
[15:03:25] <gaYak> Or maybe my Eclipse already has too many projects.. keh.
[15:04:33] *** ee_away is now known as errantepiphany
[15:04:56] *** errantepiphany has left #switchyard
[15:06:29] *** errantepiphany has joined #switchyard
[15:10:28] *** igarashitm has quit IRC
[15:11:25] *** antollinim has joined #switchyard
[15:25:35] *** igarashitm has joined #switchyard
[15:52:40] <errantepiphany> kcbabo: let me go through your email before we talk about 421...
[15:53:25] *** igarashitm has quit IRC
[15:53:49] <kcbabo> errantepiphany:  sounds good ? let's just do it at 1pm if that works for you
[15:53:55] <kcbabo> errantepiphany:  or later if you like
[15:54:02] <kcbabo> errantepiphany:  need to square away a few things here
[15:54:42] <errantepiphany> 1pm is fine.
[15:54:55] <kcbabo> errantepiphany:  cool ? thx
[15:58:19] <errantepiphany> kcbabo: PS - the KnowledgeAgent work is branch SWITCHYARD-517 in my parent, core, components, quickstarts and release repositories. Considering so many repos referenced drools/jbpm, I pushed them into the dependencyManagement (not dependencies) section of parent.
[15:59:22] <errantepiphany> kcbabo: the drools stuff IS in the dependencies section of core/integration/rules (switchyard-integration-rules)
[16:00:41] *** magesh has quit IRC
[16:05:15] *** rcernich is now known as rcernich_away
[16:06:21] *** igarashitm has joined #switchyard
[16:19:35] *** kcbabo has quit IRC
[16:30:01] *** igarashitm has quit IRC
[16:51:22] *** rbalent has quit IRC
[17:12:25] *** igarashitm has joined #switchyard
[17:14:06] *** dbevenius has left #switchyard
[18:08:32] *** kcbabo has joined #switchyard
[18:08:32] *** kcbabo has joined #switchyard
[18:10:24] *** rcernich_away is now known as rcernich
[18:10:26] <kcbabo> errantepiphany:  k, I read your reply and I can kick off a hangout at any time
[18:10:33] <kcbabo> errantepiphany:  just lemme know when you're ready
[18:10:50] <errantepiphany> kcbabo: ready.
[18:11:01] <kcbabo> errantepiphany:  cool, one sec
[18:16:29] *** rbalent has joined #switchyard
[18:16:29] *** rbalent has joined #switchyard
[18:36:34] *** echelog-2 has joined #switchyard
[18:51:00] *** rbalent has quit IRC
[19:00:29] <errantepiphany> kcbabo: One last thing... Did you want the "composition" package renamed to "composer"?
[19:04:33] *** bfitzpat is now known as bfitzpat_away
[19:05:08] <kcbabo> errantepiphany:  yeah, let's do that
[19:06:43] <errantepiphany> kcbabo: okie-dokie
[20:06:27] *** vinicius has quit IRC
[21:01:05] <errantepiphany> kcbabo: okay, well I now see why I had composers on ComponentImplementationModels... :(
[21:02:07] <errantepiphany> kcbabo: It was specifically for Camel ComponentReferences and ComponentServices.  Check out CamelActivator.handleComponentReference(...) and handleImplementation(...)
[21:02:42] <errantepiphany> kcbabo: those create a camel OutputHandler and camel SwitchYardEndpoint.
[21:04:19] <errantepiphany> kcbabo: I think I might need to add <contextMapper/> and <messageComposer> to composite/component/service and composite/component/reference...
[21:05:14] <errantepiphany> kcbabo: Or somehow figure out WHICH composer is being used at the composite/service/binding level, and use that for any component service or component reference. Ugh.
[21:06:07] <kcbabo> errantepiphany:  looking
[21:12:54] <kcbabo> errantepiphany:  this looks to simply be an unfortunate side effect of using the same handler class to handle references and bindings
[21:13:19] <kcbabo> errantepiphany:  the easiest way to view it (I think) is that OutboundHandler could have a null composer reference
[21:13:51] <kcbabo> errantepiphany:  assuming we changed the implementation to allow for that, then the methods you referenced would simply pass in null for composer and everything would work fine
[21:14:18] <kcbabo> errantepiphany:  it's just when the OutboundHandler takes on the stereotype of being a binding provider that a composer is necessary
[21:15:52] <errantepiphany> kcbabo: but doesn't it need to decompose in the other scenario?
[21:16:05] <errantepiphany> OutputHandler.createProcessor(Exchange)
[21:16:08] <errantepiphany> kcbabo: ^^
[21:16:58] *** ldimaggi has quit IRC
[21:17:37] <errantepiphany> kcbabo: also, look at SwitchYardEndpoing createConsumer, createProducer
[21:17:41] <errantepiphany> point
[21:27:29] <kcbabo> errantepiphany:  I need to take a deeper pass through that code to say definitively, but ...
[21:28:29] <kcbabo> errantepiphany:  there does need to be some code which moves from/to a Camel message when it's an implementation
[21:28:51] <kcbabo> errantepiphany:  this does not need to be configurable by the end user, however
[21:29:17] <kcbabo> errantepiphany:  so if we want to continue to use a message composer for that inside the Camel component, we can
[21:29:34] <kcbabo> errantepiphany:  I would just suggest that the composer be purpose-built for that use case
[21:31:01] <errantepiphany> kcbabo: gotcha
[21:31:32] <errantepiphany> kcbabo: in that case, we still don't need model/xsd support for the camel implementation. we can just use the default composer at that point
[21:31:45] <kcbabo> errantepiphany:  yeah ? that's what it feels like to me
[21:32:07] <kcbabo> errantepiphany:  still feels like there's a dangling something or other here, but I'm sure we'll hit it sooner or later
[21:32:25] <errantepiphany> kcbabo: I think it's gonna take people playing with it, honestly.
[21:32:32] <kcbabo> errantepiphany:  agreed
[21:32:46] <kcbabo> errantepiphany:  I'm sure there will be something
[21:33:01] <errantepiphany> kcbabo: ok, well cool. thx. Just wrapping stuff up then. I've made all the changes. Just have to go through and re-build/re-test everything clean, then we can push.
[21:33:09] <kcbabo> errantepiphany:  hey - gotta run to pickup the kiddo to get ready for trick or treating
[21:33:12] <kcbabo> errantepiphany:  awesome
[21:33:22] <kcbabo> errantepiphany:  I'll be working tonight after eating lots of candy
[21:33:28] <kcbabo> errantepiphany:  so I can push whatever then
[21:33:32] <errantepiphany> kcbabo: Cool. There'll be a pull request waiting for you. ;)
[21:33:34] <errantepiphany> have fun.
[21:34:07] <kcbabo> thanks, cya
[21:34:11] *** kcbabo is now known as babo_boo
[22:04:45] *** lanceball is now known as lance|afk
[22:14:11] *** antollinim has quit IRC
[22:33:11] *** bfitzpat_away is now known as bfitzpat
[23:15:27] *** babo_boo has quit IRC
[23:21:11] *** errantepiphany has left #switchyard





top