[02:59:22] *** ldimaggi has joined #switchyard
[05:30:36] *** ldimaggi has quit IRC
[07:04:42] *** magesh has joined #switchyard
[08:59:06] *** rbalent has joined #switchyard
[08:59:06] *** rbalent has joined #switchyard
[09:15:23] *** wyer has joined #switchyard
[09:22:26] *** rbalent has quit IRC
[09:24:19] *** rbalent has joined #switchyard
[10:51:40] *** tfennelly has joined #switchyard
[10:59:30] *** aslak has joined #switchyard
[11:17:55] *** tfennelly has quit IRC
[11:36:35] *** tfennelly has joined #switchyard
[12:42:42] *** kcbabo has joined #switchyard
[14:18:25] *** antollinim has joined #switchyard
[14:34:07] <kcbabo> tfennelly:  hey tom
[14:34:35] *** aamonten has joined #switchyard
[14:39:53] <tfennelly> kcbabo: hey Keith
[14:40:15] <kcbabo> tfennelly:  hey - how was the break?
[14:40:27] <tfennelly> kcbabo: was great
[14:40:29] <tfennelly> kcbabo: short
[14:40:34] <tfennelly> kcbabo: hehehe
[14:41:10] <tfennelly> kcbabo: anything wild or wonderful here?
[14:41:11] <kcbabo> tfennelly:  yeah, just when you start to get relaxed it's back into the fray
[14:41:24] <tfennelly> kcbabo: exactly
[14:41:34] <kcbabo> tfennelly:  not much - just chugging through
[14:41:45] <tfennelly> kcbabo: ah right
[14:42:08] <kcbabo> tfennelly:  when you have a sec, would you mind processing the pull requests associated with https://issues.jboss.org/browse/SWITCHYARD-287 ?
[14:42:33] <tfennelly> kcbabo: sure
[14:42:41] <kcbabo> tfennelly:  thanks very much
[14:43:34] <tfennelly> kcbabo: nps... I didn't see the notifications... otherwise I'd have done it already
[14:43:56] <tfennelly> kcbabo: btw... I'm looking at https://issues.jboss.org/browse/SWITCHYARD-320
[14:43:58] <kcbabo> tfennelly:  hmmm ? wonder if that's why no one else picked it up either
[14:44:33] <kcbabo> tfennelly:  cool, we need to talk about the CDI integration with Camel this week for sure
[14:45:00] <tfennelly> kcbabo: sure
[14:45:28] <tfennelly> kcbabo: so for SWITCHYARD-320... is doing a class hierarchy and working out distances getting a bit too funky do you think?
[14:45:40] <tfennelly> kcbabo: I think it is
[14:46:13] <kcbabo> tfennelly:  probably - to be honest, I think the best thing to do right now is just make the debug logging very clear
[14:46:25] <tfennelly> kcbabo: yeah.. I think so
[14:46:38] <tfennelly> kcbabo: sometimes being too clever is not so clever
[14:46:40] <kcbabo> tfennelly:  and if we end up running into a problem, users can clip the debug logs and point out to us what the correct behavior should be
[14:46:46] <kcbabo> tfennelly:  hehe ? exactly
[14:47:10] <tfennelly> kcbabo: okidoki... I'll just improve the logging there then
[14:47:28] <kcbabo> tfennelly:  just seems better to me that we print "x, y, and z would work - we're choosing x"
[14:47:43] <tfennelly> kcbabo: right
[14:48:00] <kcbabo> tfennelly:  then if someone thinks that "z" is clearly better, they can send us the app and the debug output and we can see what can be done
[14:48:23] <kcbabo> tfennelly:  maybe there are some simple things that could help - but I would prefer to drive that off of concrete use cases
[14:48:42] <tfennelly> kcbabo: in reality... there's no right way of doing this I think... whatever we choose as the default algo will be wrong in some situations
[14:48:47] <kcbabo> tfennelly:  as you said, just looking at the code in isolation can lead to your mind playing tricks on you
[14:49:09] <kcbabo> tfennelly:  agreed ? I think just sensible and consistent behavior is key
[14:49:39] <kcbabo> tfennelly:  and I'm pretty sure that this type of thing can be overridden to eliminate dupes by simply using a unique message type name
[14:49:44] <tfennelly> kcbabo: right... so pick the easiest thing to implement and maintain as the default... and that's a log message :)
[14:50:11] <kcbabo> tfennelly:  so if people have that fallback available if the default algorithm doesn't suit their needs, we should be good
[14:50:26] <tfennelly> kcbabo: right
[14:51:23] <tfennelly> kcbabo: we already have this in the @DefaultType anno
[14:51:44] <tfennelly> kcbabo: but that can't be used for types outside the control of us or the user
[14:51:59] <tfennelly> kcbabo: e.g. that BodyElement saaj type
[14:53:18] <kcbabo> tfennelly:  even in that case, users can register an exact type match for the conversion, right?
[14:53:58] <kcbabo> tfennelly:  not want I want to see (which is why we changed to Source instead), but it's a good example of a component using a type that requires a specific transformation
[14:54:53] <tfennelly> kcbabo: oh for sure
[14:55:34] <tfennelly> kcbabo: @DefaultType is handy where you are controlling all the types
[14:56:51] <tfennelly> kcbabo: you can basically tell the runtime... all Java types that extend type X are of type "java:com.acm.X" when it comes to transformations
[14:57:24] <tfennelly> kcbabo: an example is our HandlerException
[14:57:26] *** ldimaggi has joined #switchyard
[14:57:57] <tfennelly> kcbabo: so we don't need to define transformers for all HandlerException impls
[14:58:00] *** tcunning has joined #switchyard
[15:23:17] <wyer> kcbabo, regarding SWITCHYARD-253 if i wanted to implement something along those lines, its a two part problem, one would be exposing services via a message pack component i believe i can follow the soap component as a guide here
[15:24:09] <wyer> kcbabo, the other part of the problem is the requirement for a generic idl expression
[15:25:10] *** bfitzpat has joined #switchyard
[15:25:17] <kcbabo> wyer:  how coupled is msgpack encoding to the underlying transport/
[15:25:18] <kcbabo> ?
[15:25:37] <kcbabo> wyer:  that will determine whether a specific component is required
[15:25:56] <wyer> kcbabo, i'll need to double check to be 100% sure but you could implement it over soap if you were feeling so inclined heh
[15:26:21] <kcbabo> wyer:  sorry, I meant application-layer transport
[15:26:37] <kcbabo> wyer:  so SOAP is an encoding/enveloping over HTTP
[15:27:12] <kcbabo> wyer:  that's the most common use anway
[15:28:08] <wyer> kcbabo, yeah so msgpack is the serialization and the transport can be anything really by default its msgpack over tcp but it could be over http too
[15:28:37] <wyer> kcbabo, or carrier pigeon
[15:29:16] <kcbabo> wyer:  carrier pigeon is so 2010
[15:29:27] <wyer> kcbabo, but if we want it to work out the box with as many languages as possible i would say msgpack over tcp is the way to go
[15:30:14] <kcbabo> wyer:  so I imagine that a common way to use it would be to pair it with something like Netty to handle the TCP layer
[15:30:29] <wyer> kcbabo, the java implementation uses netty already
[15:31:13] <kcbabo> wyer:  so as a conceptual exercise, I wonder how msgpack would plug in if we already had a netty component
[15:31:30] <kcbabo> wyer:  so netty would handle the transport-level bit shuffling
[15:31:50] <kcbabo> wyer:  and somewhere inside the ESB, the content needs to be unmarshalled into something significant to the consumer of the message
[15:32:45] <wyer> kcbabo, yeah that makes sense
[15:32:50] <kcbabo> wyer:  so when you pull a msgpack message off the wire, and you crank it through msgpack decoding, what comes out?
[15:33:02] <kcbabo> wyer:  a string ?  a POJO ? a poodle?
[15:33:08] <wyer> kcbabo, a pojo
[15:33:35] <kcbabo> wyer:  ok , so it's a bit like Jackson and JSON then?
[15:33:47] <wyer> kcbabo, or jaxb and xml yeah
[15:33:58] <kcbabo> wyer:  yeah, ok
[15:34:27] <kcbabo> wyer:  so it sounds to me like this might be a transformer in that case
[15:35:17] <wyer> kcbabo, okay
[15:35:22] <kcbabo> wyer:  but I also think it might be promising as a interface definition assuming that remote clients can take a msgpack definition and use that as a machine-interpretable contract to generate a client
[15:35:49] <wyer> kcbabo, yes they can do that
[15:36:04] <wyer> kcbabo, so we would also need to publish the idl for a service
[15:36:24] <kcbabo> wyer:  yeah, that's the interesting bit that's not fully explored right now
[15:36:37] <kcbabo> wyer:  how we can incorporate alternate interface definition languages
[15:37:06] <kcbabo> wyer:  and how they play nicely with other definitions potentially
[15:37:16] <wyer> kcbabo, yeah there are a number of possibilities there
[15:37:27] <kcbabo> wyer:  so would the actual interface definition be thrift or something specific to msgpack?
[15:38:04] <wyer> kcbabo, it would be thrift
[15:38:20] <kcbabo> wyer:  interesting ....
[15:38:28] <wyer> kcbabo, but a thrift client would not work they just reused the idl
[15:38:40] <wyer> kcbabo, the serialization and transport is very different
[15:38:51] <kcbabo> wyer:  ooh, that's kinda stinky ? boo
[15:39:32] <kcbabo> wyer:  at least from our standpoint, because we want to advertise a contract which consumers can interpret
[15:40:00] <kcbabo> wyer:  so in this case, it sounds like the interface definition is specific to the implementation, despite the fact that it's thrift
[15:40:05] <wyer> kcbabo, there are more languages with client libraries for msgpack than thrift
[15:40:49] <wyer> kcbabo, but there is no reason not to support msgpack and thrift the idl remains the same after all
[15:40:49] <kcbabo> wyer:  fair enough, I'm just trying to sort what the actual interface type would be
[15:41:00] <kcbabo> wyer:  and it sounds like it would clearly be msgpack and not thrift
[15:41:25] <kcbabo> wyer:  even though the actual expression is thrift, the client must use msgpack
[15:42:06] <wyer> kcbabo, well if we only support msgpack, if we supported both it could be a thrift or msgpack client
[15:43:01] <wyer> kcbabo, i am not sure of the state of thrift its quite dark, but there is quite a bit of activity on the JIRA
[15:45:12] <wyer> kcbabo, i mean ultimately the clients have to be different since msgpack supports async and parallel pipeling but the idl is identical
[15:46:16] *** rcernich has joined #switchyard
[15:48:45] *** GitHub158 has joined #switchyard
[15:48:45] <GitHub158> [parent] tfennelly pushed 1 new commit to master: http://bit.ly/oimuzw
[15:48:45] <GitHub158> [parent/master] SWITCHYARD-287 added pom property for forge.version - Keith Babo
[15:48:45] *** GitHub158 has left #switchyard
[15:49:06] *** GitHub57 has joined #switchyard
[15:49:06] <GitHub57> [core] tfennelly pushed 1 new commit to master: http://bit.ly/p7A1sz
[15:49:06] <GitHub57> [core/master] SWITCHYARD-287 Move to Seam Forge Alpha 4 - Keith Babo
[15:49:06] *** GitHub57 has left #switchyard
[15:49:48] *** GitHub110 has joined #switchyard
[15:49:49] <GitHub110> [components] tfennelly pushed 1 new commit to master: http://bit.ly/qmwJeH
[15:49:49] <GitHub110> [components/master] SWITCHYARD-287 Move to Seam Forge Alpha 4 - Keith Babo
[15:49:49] *** GitHub110 has left #switchyard
[15:57:23] *** lanceball has joined #switchyard
[16:03:36] <wyer> kcbabo, in either case i'll start with netty then
[16:03:54] <wyer> and a transformer
[16:04:27] <wyer> optimus prime probably needs some work now that his movie career is over
[16:07:51] <tcunning> oh man was that a spoiler
[16:09:38] <wyer> tcunning, no i just reckon the franchise will probably be taking a break (which sucks cos huge robots rule)
[16:41:31] <magesh> kcbabo: A reference for any new component to run on AS7 http://community.jboss.org/wiki/SwitchYardAS7Development
[16:46:28] <bfitzpat> kcbabo - just fyi you can skip me - I'm just lurking to try and stay in the loop on SY these days :)
[17:11:31] *** magesh has left #switchyard
[17:13:40] <antollinim> tfennelly: Hi Tom, are you there?
[17:15:18] *** errantepiphany has joined #switchyard
[17:15:20] <tfennelly> antollinim: Alejandro... how are you?
[17:15:43] <antollinim> tfennelly: I am working on a quickstart using wsdl and JAXB. I am following your screencast. When I am invoking the service I get this error: Cannot convert from 'com.sun.xml.internal.messaging.saaj.soap.ver1_1.BodyElement1_1Impl...
[17:15:52] <antollinim> tfennelly: good, thanks, you?
[17:16:11] <tfennelly> antollinim: I'm good too thanks
[17:16:37] <tfennelly> antollinim: so have you updated all the modules, rebuilt and rebuilt the AS7 distribution?
[17:18:29] <antollinim> tfennelly: what I did is this: I impleemented the service, generated the Types, everyhitng compiles ok, I start the service in a test using mixin
[17:19:20] <antollinim> tfennelly: I make the test stop (usign a breakpoint) just after the service is published
[17:19:20] <tfennelly> antollinim: right... but did you also do the things I listed above?
[17:19:59] <tfennelly> antollinim: I mean... fistly forget about the changes you need to make and instead get your modules all up-to-date
[17:20:04] <antollinim> tfennely: then I use soapUI to inovke the service (the rquest is generated by SoapUI
[17:20:18] <tfennelly> antollinim: ^^^^
[17:20:49] <tfennelly> antollinim: and then the last step is the most important... rebuild your AS7 distro in the releases module
[17:20:50] <antollinim> tfennelly: what do you mean bye "get your modules all up-to-date"?
[17:20:58] *** rcernich is now known as rcernich_brb
[17:21:11] <tfennelly> antollinim: I mean... "git pull upstream master" on each of them
[17:21:29] <tfennelly> antollinim: make sure you have them all up-to-date
[17:21:32] <antollinim> tfenelly: they are up to date
[17:21:35] <tfennelly> antollinim: rebuild them
[17:21:41] <antollinim> tfennyl: I did not recompile AS7 though
[17:22:02] <antollinim> tfennelly: ok, and then?
[17:22:09] <tfennelly> antollinim: ok... that step is important too... otherwise you will def hit the error you are getting
[17:22:32] <tfennelly> antollinim: and then....
[17:22:51] <tfennelly> antollinim: if you deploy your app on the newly built as7 distro.... you should not see that error anymore
[17:23:07] <antollinim> tfennelly: ok, good, let me try that. Thanks!
[17:40:01] *** rcernich_brb is now known as rcernich
[17:40:06] <antollinim> tfennelly: that was it. It worked. Thanks Tom
[17:41:01] *** antollinim is now known as antollinim_lunch
[17:43:13] <tfennelly> antollinim_lunch: no probs Alejandro :)
[18:02:29] *** kcbabo is now known as babo_lunch
[18:05:54] <tfennelly> antollinim_lunch: Mario... sorry for calling you Alejandro
[18:07:58] <tfennelly> babo_lunch: have a look at https://github.com/tfennelly/jboss-switchyard-core/tree/SWITCHYARD-244 when you get a chance
[18:08:18] <tfennelly> babo_lunch: small change... I will issue the pull requests anyway, assuming there's no issue
[18:10:07] <babo_lunch> tfennelly:  looks good to me
[18:22:26] <babo_lunch> tfennelly:  that components build failure was b.s.
[18:22:33] <babo_lunch> tfennelly:  just re-ran the build and it's fine
[18:23:05] <babo_lunch> tfennelly:  going to lunch now for reals.  I'll push your pull request when I get back.
[18:25:02] *** GitHub131 has joined #switchyard
[18:25:02] <GitHub131> [core] tfennelly pushed 1 new commit to master: http://bit.ly/pDF5lC
[18:25:02] <GitHub131> [core/master] SWITCHYARD-334: Unnecessary service registration if promoted service name same as component service name - David Ward
[18:25:02] *** GitHub131 has left #switchyard
[18:36:24] *** GitHub95 has joined #switchyard
[18:36:24] <GitHub95> [core] tfennelly pushed 1 new commit to master: http://bit.ly/n8eRWx
[18:36:24] <GitHub95> [core/master] SWITCHYARD-335 create mechanism for identifying switchyard deployments - rcernich
[18:36:24] *** GitHub95 has left #switchyard
[18:48:33] *** rbalent has quit IRC
[18:53:06] *** antollinim_lunch is now known as antollinim
[18:58:04] *** tfennelly has quit IRC
[19:07:00] *** wyer has quit IRC
[19:27:41] *** babo_lunch is now known as kcbabo
[20:05:14] <rcernich> kcbabo: hey keith
[20:05:23] <kcbabo> rcernich:  hey rob
[20:05:24] <rcernich> kcbabo: been thinking about this admin/mgt api
[20:05:45] <rcernich> kcbabo: should we also be thinking about how this ties in with a repo solution?
[20:06:17] <kcbabo> rcernich:  for sure, although I'm not sure how concrete we can be about that
[20:06:20] <rcernich> kcbabo: from the perspective of meta-data, i think there's a definite tie in
[20:06:26] <kcbabo> rcernich:  oh yeah, for sure
[20:06:28] <rcernich> kcbabo: sure
[20:06:54] <kcbabo> rcernich:  for now, I think the best we can say is "I expect this type of information to be accessible in a repository"
[20:06:59] <rcernich> kcbabo: :)
[20:07:06] <kcbabo> rcernich:  so like the example I gave this morning
[20:07:36] <kcbabo> rcernich:  when viewing service details, the WSDL interface and associated schemas may be linkable to a repository
[20:07:58] <rcernich> kcbabo: i was just thinking that if we are going to create an api for accessing that data, perhaps a possible implementation should use some sort of repo on the backend
[20:08:20] <kcbabo> rcernich:  so modeshape would likely be the repository backing that
[20:08:30] <rcernich> kcbabo: whether this is simply a service registered with as or a real soa repo backend
[20:08:45] <rcernich> kcbabo: should we be considering something like s-ramp
[20:09:01] <rcernich> kcbabo: (was looking at some of the stuff kurt is working on)
[20:09:55] <kcbabo> rcernich:  I wouldn't expect us to implement that directly, but I do think it's interesting to look at the points where we might integrate with it
[20:10:41] <rcernich> kcbabo: ok.  just a thought.  i wasn't sure if the repo piece was something that might be pluggable
[20:11:02] <rcernich> kcbabo: e.g. using uddi, s-ramp, modeshape, ldap, whatever
[20:12:11] <rcernich> kcbabo: or even a custom repo service which simply describes artifacts in local switchyard deployments
[20:12:29] <kcbabo> rcernich:  my understanding was that modeshape would be the backing implementation for their repository
[20:14:09] <rcernich> kcbabo: ok
[20:15:01] <rcernich> kcbabo: so something like s-ramp would be implemented atop modeshap?
[20:18:37] <kcbabo> rcernich:  that was my understanding - modeshape already has the ability to sequence, store, and establish relationships between artifacts, IINM
[20:19:07] <rcernich> kcbabo: ok.  cool.
[20:31:33] <kcbabo> aamonten:  release build is finally done - sorry about the wait
[20:31:34] <kcbabo> http://ci.jboss.org/jenkins/job/SwitchYard-Release/
[20:33:09] <aamonten> no problem..
[20:33:21] <aamonten> kcbabo: downloading..
[20:36:48] *** wyer has joined #switchyard
[21:04:20] *** rcernich is now known as rcernich_away
[22:03:47] *** rcernich_away is now known as rcernich
[22:08:47] *** GitHub194 has joined #switchyard
[22:08:47] <GitHub194> [core] kcbabo pushed 1 new commit to master: http://bit.ly/pXU7zT
[22:08:47] <GitHub194> [core/master] SWITCHYARD-320: Improve sorting logic of fallback transformers where multiple unrelated transformers are resolved for a given type - Tom Fennelly
[22:08:47] *** GitHub194 has left #switchyard
[22:34:03] *** wyer has quit IRC
[22:35:35] *** bfitzpat is now known as bfitzpat_away
[23:10:14] *** ldimaggi has quit IRC
[23:12:56] *** tcunning has quit IRC
[23:24:35] *** aamonten has quit IRC
[23:29:26] *** errantepiphany has left #switchyard
[23:46:49] *** lanceball has quit IRC





top