[00:20:14] *** aslak has quit IRC
[00:22:43] *** errantepiphany has left #switchyard
[00:53:00] *** bfitzpat has quit IRC
[01:15:23] *** tfennelly has quit IRC
[02:00:47] *** ldimaggi has joined #switchyard
[02:20:37] *** lanceball has quit IRC
[03:29:55] *** kcbabo has joined #switchyard
[03:52:55] *** kcbabo has quit IRC
[05:29:58] *** ldimaggi has quit IRC
[05:57:47] *** magesh has joined #switchyard
[07:55:08] *** tcunning has quit IRC
[08:15:53] *** aslak has joined #switchyard
[08:51:01] *** dbevenius has joined #switchyard
[09:50:41] *** aslak has quit IRC
[09:51:06] *** aslak has joined #switchyard
[09:53:38] *** aslak has quit IRC
[10:09:44] *** aslak has joined #switchyard
[11:25:08] *** rbalent has joined #switchyard
[11:25:09] *** rbalent has joined #switchyard
[12:12:18] *** tfennelly has joined #switchyard
[12:36:36] <tfennelly> aslak: hey Aslak.... do you know whether or not cdi extensions are supported on tomcat?
[12:37:07] <tfennelly> aslak: we have an extension but it doesn't seem to get picked up from the cp
[12:37:22] <tfennelly> aslak: just wondering if you knew off hand
[12:38:19] <aslak> tfennelly, hmm, would think they were.. are you deploying unpackaged ?
[12:38:51] <aslak> tfennelly, there is a bug in weld-servlet on tomcat that if not deployed unpackaged, it can't scan
[12:39:21] <tfennelly> aslak: I'm adding the extension using addAsLibraries
[12:39:47] <aslak> https://github.com/arquillian/arquillian-container-tomcat/blob/master/tomcat-embedded-6/src/test/resources/arquillian.xml#L11
[12:39:49] <tfennelly> aslak: ah OK... maybe that explains then
[12:41:17] <tfennelly> aslak: addAsLibraries... from reading the javadoc on that I'm assuming those archives are added to the container's lib dir
[12:41:40] <tfennelly> aslak: or by any chance would it be the war's lib dir?
[12:42:10] <aslak> tfennelly, it depends on the Archive type, but for WebArchives, it's WEB-INF/lib
[12:42:23] <tfennelly> aslak: ahhh
[12:42:43] <tfennelly> aslak: I'll try the unpack config then
[12:43:07] <tfennelly> aslak: not sure if weld picks up extensions from WEB-INF/lib
[12:43:16] <tfennelly> aslak: we'll find out soon enough :)
[12:44:02] <aslak> tfennelly, i believe weld picks them up from ClassPath, web-inf/* is on cp so
[12:45:20] <tfennelly> aslak: hopefully
[12:45:51] <tfennelly> aslak: right... I suppose I meant I don't know whether or not weld looks for new extensions on deployment of a war (or whatever)
[12:47:38] <aslak> tfennelly, i believe it does..
[12:47:58] <aslak> tfennelly, seam3 works with weld-servlet as far as i know.. and that's just CDI extensions so.. :)
[12:49:34] <tfennelly> aslak: right... but the extensions might be installed somewhere in the container and picked up on startup Vs in the war... I dunno :)
[12:50:11] <tfennelly> aslak: if I just add the arquillian.xml in the resources it should get auto picked up, right?
[12:52:18] <aslak> tfennelly, yea, src/test/resources or similar
[12:52:21] <aslak> basically anywhere on cp
[12:52:23] <aslak> client cp
[12:54:43] <tfennelly> aslak: should it say something on the console re unpacking?
[12:55:11] <aslak> hmm.. don't think so
[12:55:16] <tfennelly> aslak: it's picking up the arquillian.xml for sure coz I can see the port number is 8888 now (was 8080)
[12:55:45] <tfennelly> aslak: still not kicking the extension
[12:55:47] <aslak> you might see a slightly different  deployment url, but
[12:58:58] <tfennelly> aslak: I stuck a breakpoint in it to stop it and then went to the temp folder... there's a temp war created there, but I don't see anything else being created, which is prob fine
[13:01:33] <aslak> hmm.. maybe extensions needs to be extracted as well..
[13:02:17] <aslak> tfennelly, can you try just adding a simple Extension class in WEB-INF/classes and add a ServiceProvider file to WEB-INF/classes/META-INF
[13:02:25] <aslak> just to see that it actually tries to load something
[13:04:22] <tfennelly> aslak: sure
[13:05:16] <tfennelly> aslak: I just tried turning on and off the unpack thing there... the content and structure of the tomcat-embedded-6 folder seems the same in both cases
[13:05:45] <tfennelly> aslak: actually... I just removed the arquillian.xml file... I didn't explicitly turn it off
[13:11:59] *** kcbabo has joined #switchyard
[13:13:31] <aslak> tfennelly, it might be that it is only exploded inside the appBase or similar, not where the Archive is first written
[13:14:09] <tfennelly> aslak: I tried adding a noddy extension in the war... it didn't get fired either
[13:14:30] <aslak> tfennelly, which weld-servlet v. ?
[13:14:41] <aslak> tfennelly, you cna see weld start righ t?
[13:14:43] <aslak> can
[13:15:08] <tfennelly> aslak: added the extension class and then beans.xml to WEB-INF/classes/META-INF... THAT'S ENOUGH, RIGHT?
[13:16:47] <aslak> do you have the Listener registered in web.xml ?
[13:17:01] <aslak> and the BeanManager jndi thinggy in context.xml ?
[13:17:09] <tfennelly> aslak: good point... initially I had a warning that the BeanManager was NOT bound into the jndi tree... that went away after adding arquillian-testenricher-cdi to the pom, so I assumed Arq had set it all up
[13:17:25] <aslak> not at all
[13:17:26] <aslak> :)
[13:17:30] <tfennelly> aslak: hahaha
[13:17:42] <tfennelly> aslak: assumptions assumptions assumtions ;)
[13:17:45] <aslak> ew helpt to confuse, but don't baby sit.. :P
[13:17:49] <aslak> we
[13:18:03] <tfennelly> aslak: ah come on man ;)
[13:18:20] <tfennelly> aslak: ok... well that's good news though
[13:18:32] <tfennelly> aslak: I feel like an idiot yet again, but I'm used to that
[13:18:38] <tfennelly> aslak: ;)
[13:18:41] <aslak> hehe
[13:19:26] <tfennelly> aslak: so I still need to make the configs outlined here: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/environments.html#d0e4998
[13:20:03] <tfennelly> aslak: actually... perhaps Arq is doing half of that for me
[13:20:25] <aslak> yea
[13:20:35] <aslak> no arq is going nothing
[13:20:36] <aslak> doing
[13:20:50] <tfennelly> aslak: okidoki
[13:36:52] <tfennelly> aslak: got it now aslak... thanks
[13:37:17] *** magesh1 has joined #switchyard
[13:37:30] <aslak> tfennelly, excellent!
[13:37:40] *** tcunning has joined #switchyard
[13:38:04] <tfennelly> aslak: and that's with unpack set to false too, so that seems to work fine actually
[13:38:34] <aslak> tfennelly, might have been fixed then.. :)
[13:38:44] <tfennelly> aslak: yep
[13:38:49] <tfennelly> aslak: thanks man !!
[13:39:28] <aslak> tfennelly, happy testing.. :)
[13:39:55] *** magesh has quit IRC
[13:41:13] *** rbalent has quit IRC
[13:42:01] *** rbalent has joined #switchyard
[13:42:02] *** rbalent has joined #switchyard
[13:44:05] <kcbabo> tfennelly:  rolling back to last week fixed the AS6 failure
[13:44:15] <kcbabo> tfennelly:  so now I need to find the culprit
[13:46:27] *** magesh1 is now known as magesh
[14:00:22] <tfennelly> kcbabo: oh I pray to the almighty ungabunga that it's not me
[14:00:31] <tfennelly> kcbabo: you'd just love to lay some shit on me lol
[14:00:44] <kcbabo> tfennelly:  i'm betting it's a merge commit ;-)
[14:00:59] <tfennelly> kcbabo: hahahaha.... you'd love that
[14:01:12] <tfennelly> kcbabo: that would be "proof", wouldn't it lol
[14:01:30] <kcbabo> tfennelly:  hehe ? well, magesh is safe for now
[14:01:38] <kcbabo> tfennelly:  continuing to move up the commit history
[14:01:43] <kcbabo> tfennelly:  you're coming up next
[14:03:02] <tfennelly> kcbabo: jays.... it's like that quiz show "who wnats to be a millionaire"... I've give my answer and now I'm waiting to find out if I win or loose it all... the tense music is playing in the background, getting louder and louder lol
[14:05:53] *** bfitzpat has joined #switchyard
[14:11:16] <magesh> kcbabo, tfennelly: I am off guys, heavy tooth-ache
[14:12:02] <tfennelly> magesh: good luck man... I hear whiskey is great for that ;)
[14:12:22] <magesh> tfennelly: ;)
[14:13:38] *** magesh has left #switchyard
[14:15:32] <tfennelly> aslak: Aslak... is there a way I can get the weld-tomcat-support.jar into $TOMCAT_HOME/lib for an embedded tomcat?
[14:15:35] <tfennelly> aslak: ala http://docs.jboss.org/weld/reference/1.0.0/en-US/html/environments.html#d0e4998
[14:24:37] <aslak> tfennelly, i think you can define tomcatHome and place it under tomcatHome/lib in arq.xml
[14:24:39] <aslak> https://docs.jboss.org/author/display/ARQ/Tomcat+6.0+-+Embedded
[14:25:30] <aslak> maybe.. :)
[14:26:31] <tfennelly> aslak: wouldn't that would require manual intervention, no?
[14:26:51] <tfennelly> aslak: as in... the jar needs to be copied in their somehow
[14:26:58] <aslak> tfennelly, yea
[14:27:07] <tfennelly> aslak: could get maven to do it though I guess
[14:27:18] <aslak> tfennelly, yea
[14:27:24] <tfennelly> aslak: but that might screw up running via your ide
[14:27:31] <tfennelly> aslak: okidoki... thanks man
[14:27:37] <aslak> yea
[14:27:38] <aslak> :)
[14:33:03] *** ldimaggi has joined #switchyard
[15:36:47] *** ldimaggi has quit IRC
[15:43:01] *** dbevenius has left #switchyard
[16:02:01] *** errantepiphany has joined #switchyard
[16:09:01] *** ldimaggi has joined #switchyard
[16:16:11] <kcbabo> errantepiphany:  what's up bro?
[16:18:09] <errantepiphany> kcbabo: nice.
[16:18:40] <kcbabo> errantepiphany:  that pained me, given that it will be captured forever in IRC logs
[16:18:46] <kcbabo> errantepiphany:  I'm the guy that calls people bro
[16:19:06] <kcbabo> errantepiphany:  bro-man has to be worse, right?
[16:19:22] *** antollinim has joined #switchyard
[16:23:14] *** lanceball has joined #switchyard
[16:27:32] <errantepiphany> kcbabo: There are 2 main "party" neighborhoods in Rochester. One is the "South Wedge", where I live, and one is "East and Alexander".  It's sort of like West Side Story's "Sharks" and "Jets", or "other side of the tracks" mentality.  People who say "bro" are from East and Alexander. The preppy, sporty, pop, tight pink shirts, backwards baseball hats, meat-market sports bars, I'm gonna fight you for any reason, get wasted
[16:28:00] <kcbabo> errantepiphany:  I know that crowd
[16:28:39] <kcbabo> errantepiphany:  except around here they wear blue blazers and seersucker shorts
[16:31:00] <errantepiphany> kcbabo: yes they wear seersucker shorts at E&A too. But honestly, I had to first google what "seersucker" meant - LOL. "Blue blazers?" You mean like jackets?
[16:31:21] <kcbabo> errantepiphany:  oh yes, that's the frat boy uniform
[16:31:35] <errantepiphany> kcbabo: gotcha. (shudder)
[17:06:51] *** GitHub97 has joined #switchyard
[17:06:52] <GitHub97> [components] kcbabo pushed 1 new commit to master: http://bit.ly/pzTaDb
[17:06:52] <GitHub97> [components/master] SWITCHYARD-374 rolling back to Camel 2.6.0 until this issue is resolved - Keith Babo
[17:06:52] *** GitHub97 has left #switchyard
[17:07:09] <kcbabo> tfennelly:  found the bad commit
[17:09:13] <errantepiphany> kcbabo: my bad. I didn't re-build the release repo when I was testing this. :(
[17:09:26] <kcbabo> errantepiphany:  it happens
[17:09:35] <kcbabo> errantepiphany:  bugger to chase down though
[17:09:45] <kcbabo> errantepiphany:  part of the problem is our release build has been kind of flaky
[17:09:56] <kcbabo> errantepiphany:  otherwise I would have picked up on this immediately
[17:10:10] <kcbabo> errantepiphany:  and it's always a nice back-up if you don't run release locally
[17:10:25] <kcbabo> errantepiphany:  but some random stuff has been failing that build in the past week - I think it's all sorted now
[17:10:50] <errantepiphany> kcbabo: ah. yeah, sorry again.
[17:34:13] <kcbabo> wyer:  yt?
[17:38:48] <kcbabo> errantepiphany:  bpm component has a dependency on eclipse JDT core ? any idea what that's all about?
[17:43:14] *** rbalent has quit IRC
[17:45:25] <kcbabo> errantepiphany:  nevermind ? think I found it
[17:53:39] <errantepiphany> kcbabo: sorry; didn't see you typing to me. yeah, it's for drools compilation.
[18:02:06] <kcbabo> errantepiphany:  what I'm trying to figure out is why we have a dependency on all of jdt core in the bpm component
[18:02:15] <kcbabo> errantepiphany:  and not just jdt.core.compiler
[18:02:22] <kcbabo> errantepiphany:  did you and justin talk about that at all?
[18:02:54] <kcbabo> errantepiphany:  for example, in drools the dependency is just on core.compiler
[18:05:58] *** rcernich has joined #switchyard
[18:20:19] <errantepiphany> kcbabo: no, we haven't talked about it.
[18:20:36] <kcbabo> errantepiphany:  ok, I'm trying it with just the compiler dependency now
[18:21:09] <errantepiphany> kcbabo: it *should* work with just the compiler
[18:25:48] <rcernich> kcbabo: got some time to chat about components in the admin model?
[18:26:15] <kcbabo> rcernich:  hey - aren't you on vacation?
[18:26:38] <rcernich> kcbabo: a bit
[18:26:56] <kcbabo> rcernich:  I'm happy to wait until Monday :-)
[18:26:56] <rcernich> kcbabo: just taking a break from the break
[18:27:02] <kcbabo> rcernich:  gotcha
[18:30:11] <kcbabo> rcernich:  well either works for me ? if you want to talk now, that works.  Otherwise, we can always talk after the meeting on Monday.
[18:30:28] <rcernich> kcbabo: just trying to collect some thoughts
[18:30:35] <rcernich> kcbabo: so i can ruminate on the plane;)
[18:31:07] <kcbabo> rcernich:  okie dokie
[18:31:07] <rcernich> kcbabo: so, a component can expose one or more implementation types and/or one or more binding types
[18:31:59] <rcernich> kcbabo: did you anticipate the Component object representing the component module, or just one of those bindings/implementations?
[18:32:06] <kcbabo> rcernich:  that is true ? although it's quite likely that it will either be (0 .. 1) & (0 ..1)
[18:32:49] <rcernich> kcbabo: e.g. camel contributes a slew of bindings and an implementation
[18:33:28] <kcbabo> rcernich:  yeah, I guess that's true actually
[18:34:08] <kcbabo> rcernich:  my initial thought was that it would just be a list of components that we found during startup
[18:34:14] <kcbabo> rcernich:  and that's really just the list of activators
[18:35:07] <kcbabo> rcernich:  camel, for example, will have one implementation and multiple bindings
[18:35:18] <rcernich> kcbabo: ok, i guess it just depends on the level of fidelity
[18:35:31] <rcernich> kcbabo: e.g. camel has one activator
[18:35:50] <kcbabo> rcernich:  the main purpose behind this from a UI perspective is really just to know which components are installed
[18:36:08] <kcbabo> rcernich:  I guess another way to get this info would be to just query the subsystem definition, but that's pretty AS specific
[18:36:18] <kcbabo> rcernich:  it would be nice to have something more generic
[18:37:04] <rcernich> kcbabo: i was thinking of using a service loader to load a class that would present that information to the system
[18:38:50] <kcbabo> rcernich:  or I wonder if we can just tie it to the activator somehow
[18:39:19] <rcernich> kcbabo: i was thinking the extra fidelity would be nice in the services view
[18:39:39] <kcbabo> rcernich:  some of the info is there already, but not everything
[18:39:44] <rcernich> kcbabo: e.g. camel:binding.file
[18:40:10] <kcbabo> rcernich:  of course that could start stretching that interface beyond it's original intent
[18:40:26] <rcernich> kcbabo: yeah, i think that's the point i was getting to
[18:40:45] <rcernich> kcbabo: hmm
[18:41:31] <kcbabo> rcernich:  I think the best thing would be for us to walk through the existing UI on Monday after the meeting and talk about what we think we can get in there near term (next week) and what we shouuld target for 0.3
[18:42:11] <rcernich> kcbabo: sounds good.
[18:42:43] <rcernich> kcbabo: to keep beating on camel, the way the admin api is currently setup, we'd just display came for binding and implementation
[18:42:51] <rcernich> kcbabo: came=>camel
[18:43:36] <rcernich> kcbabo: and then is it important at all to distinguish between implementation and binding
[18:43:38] <kcbabo> rcernich:  yeah, I hear you there
[18:43:52] <kcbabo> rcernich:  definitely need to think that through
[18:44:07] <rcernich> kcbabo: well, fodder for the weekend;)
[18:44:19] <kcbabo> rcernich:  I like the idea of having a single activator that handles multiple types
[18:44:28] <kcbabo> rcernich:  so maybe this does push us to a separate contract
[18:45:21] <rcernich> kcbabo: are you thinking, e.g., having a binding and implementation object contained by the service, referencing back to the component?
[18:46:37] <kcbabo> rcernich:  maybe - I'm trying to think of it more from the end user standpoint first  - like which information would they want to see and how it's related
[18:47:04] <kcbabo> rcernich:  for example, I think they would definitely want to know which bindings are available and which implementations are avaiable
[18:47:12] <kcbabo> rcernich:  not just a list of activators
[18:47:20] <rcernich> kcbabo: absolutely
[18:47:29] <rcernich> kcbabo: e.g. camel:file
[18:47:43] <rcernich> kcbabo: or soap:http
[18:47:58] <rcernich> kcbabo: for bindings
[18:48:15] <rcernich> kcbabo: that's what i would like to see in the gateways section
[18:49:41] <rcernich> kcbabo: if there were multiple bindings of the same type, those would all show up, e.g. three soap:http
[18:50:07] <kcbabo> rcernich:  I think types need to be unique
[18:50:25] <kcbabo> rcernich:  well, unique within a namespace I guess
[18:50:48] <kcbabo> rcernich:  although we most likely have some runtime dependencies on the string itself being unique
[18:53:01] <rcernich> kcbabo:  i haven't given it that much thought, just throwing things out there for example
[18:53:22] <kcbabo> rcernich:  I think that's headed down the right track
[18:55:30] <rcernich> kcbabo: well, i'll think on it some more, see what i can come up with
[18:55:42] <rcernich> kcbabo: we can talk it over monday
[18:56:09] <kcbabo> rcernich:  sounds great.  thanks, rob
[18:56:35] <rcernich> kcbabo: btw, sorry about the messy commit
[18:56:50] <kcbabo> rcernich:  looked ok to me ? didn't notice
[18:57:01] <rcernich> kcbabo: i should have mentioned the component stuff and the xnio errors in the log
[18:57:38] <kcbabo> rcernich:  ah, no worries
[18:57:46] <kcbabo> rcernich:  particularly since you are on vacation!
[18:58:15] <rcernich> kcbabo: no worries
[18:58:27] <rcernich> kcbabo: i've got looney toons on in the background
[19:23:53] <tfennelly> kcbabo: we only create bean proxies if there's a @Reference annotated bean property
[19:24:20] <tfennelly> kcbabo: I think... actually.... I'll check that
[19:24:56] <tfennelly> kcbabo: thinking though that we should be creating client proxies for all bean services
[19:25:08] <tfennelly> kcbabo: so they can be used in JSF etc
[19:37:58] <tfennelly> kcbabo: would it be useful to have CDI bean proxies registered for all <interface.java> interfaces, irrespective of the implementation type?
[19:38:48] <tfennelly> kcbabo: so you could have a Camel route service impl exposed as a CDI bean
[19:40:19] <tfennelly> kcbabo: could use it in JSF say
[19:40:28] <tfennelly> kcbabo: that any use I wonder
[19:43:18] <tfennelly> kcbabo: I have this war based deployment working... trying to find a use for it now lol
[19:43:26] <tfennelly> kcbabo: a solution looking for a problem
[19:44:38] <tfennelly> kcbabo: thought JSF would be one, but need to change SwitchYardCDIServiceDiscovery for that... to register client proxies in CDI for all services, not just those that are @Referenced from another bean
[20:04:00] <kcbabo> tfennelly:  catching up now
[20:04:23] <tfennelly> kcbabo: no worries... I was just rambling really
[20:06:01] <kcbabo> tfennelly:  I agree that it would be nice to inject directly into a JSP
[20:06:16] <tfennelly> kcbabo: but
[20:06:46] <kcbabo> tfennelly:  alejandro had it working with numberguess but he was injecting an object which had an @Reference in it
[20:07:04] <tfennelly> kcbabo: ah right
[20:07:18] <kcbabo> tfennelly:  when you say that you'll register a proxy for all services, when would this registration take place?
[20:07:24] <tfennelly> kcbabo: yeah... would work for a bean that just so happened to be referenced from somewhere else too
[20:08:43] <tfennelly> kcbabo: all bean services... reg them same place and time I do it for situations where there are @References
[20:10:24] <kcbabo> tfennelly:  so it's just bean services?  I didn't know if you were talking about all services in the runtime
[20:11:01] <kcbabo> tfennelly:  the real idea with the war deployment is to make it possible to deploy to a runtime that has not been pre-configured with SwitchYard
[20:11:18] <kcbabo> tfennelly:  so kind of like how people bundle up Spring + any other dependencies inside their webapp
[20:11:29] <tfennelly> kcbabo: well... I did mention in passing that it might make sense to do it for all <interface.java> interfaces
[20:11:38] <tfennelly> kcbabo: sure
[20:11:58] <tfennelly> kcbabo: I get that and I know I migh be going off in a slight tangent here ;)
[20:12:34] <kcbabo> tfennelly:  I'm wondering if there's a dynamic way to address this
[20:12:53] <tfennelly> kcbabo: how do you mean?
[20:13:08] <kcbabo> tfennelly:  well, if there's a reference to a bean in a JSP, let's say in EL
[20:13:18] <kcbabo> tfennelly:  the bean manager is gonna go looking for it
[20:13:34] <kcbabo> tfennelly:  I guess that lookup is just based on the beans that have been discovered so far?
[20:13:48] <tfennelly> kcbabo: right... that's what I'm talking about
[20:13:53] <kcbabo> tfennelly:  vs. us being able to intercept that call and check to see if there is a SwitchYard service registered
[20:14:03] <tfennelly> kcbabo: I'm talking about making a bean available in a situation like that
[20:14:31] <kcbabo> tfennelly:  right, but there's an issue right now with how you would know that those services are even available
[20:14:51] <tfennelly> kcbabo: if we just register proxies for all services, vs just those that are @Referenced, then I think we cover this
[20:15:09] <kcbabo> tfennelly:  how do you know when a service is registered?
[20:16:19] <tfennelly> kcbabo: well you don't... you're just registering a proxy for the interface... if that's invoked at a later point and the services is not there... you have a problem for sure
[20:16:38] <tfennelly> kcbabo: but that's not a problem in this case since we register services for all the beans
[20:16:46] <tfennelly> kcbabo: no?
[20:16:52] <kcbabo> tfennelly:  ok, but I'm asking what's the trigger for even registering a proxy for the interface?
[20:16:56] <tfennelly> kcbabo: or is this a trick question :) ?
[20:17:12] *** rcernich has quit IRC
[20:17:15] <tfennelly> kcbabo: SwitchYardCDIServiceDiscovery
[20:17:17] <kcbabo> tfennelly:  in other words, what happens in order for us to create a proxy for a bean named "foo"
[20:17:39] <kcbabo> tfennelly:  and what is it discovering?
[20:18:04] <kcbabo> tfennelly:  with beans today, it scans for classes which include @Inject @Reference, right?
[20:18:15] <kcbabo> tfennelly:  so what would be added to pick up any service/
[20:18:16] <kcbabo> ?
[20:18:21] <tfennelly> kcbabo: CDI discovers the CDI bean... we captre that data so we can create a SwithcYard service for it + create Proxies to those
[20:18:54] <tfennelly> kcbabo: it does more than that
[20:18:55] <kcbabo> tfennelly:  ok, so I have a JSP which injects "FooBean"
[20:19:12] <kcbabo> tfennelly:  there's no Bean @Service named "FooBean"
[20:19:25] <kcbabo> tfennelly:  but there is a service in SwitchYard called "FooBean"
[20:19:39] <tfennelly> kcbabo: right
[20:19:40] <kcbabo> tfennelly:  so how does the CDI discovery pick that up?
[20:21:00] <kcbabo> tfennelly:  if it just picks that out of the JSP and notifies the extension, then that seems like enough
[20:21:32] <tfennelly> kcbabo: what you're talking about is normal JSF stuff... nothing to do with SwitchYard
[20:22:03] <tfennelly> kcbabo: not being invoked via SwitchYard
[20:22:24] <kcbabo> tfennelly:  I just said above that the service was available in SwitchYard
[20:22:31] <tfennelly> kcbabo: right... so our CDI beans could be invoked directly from a JSF anyway
[20:22:49] <kcbabo> tfennelly:  isn't that what we're talking about ?  Making SwitchYard services available without an @Reference required?
[20:23:22] <tfennelly> kcbabo: oh sorry... got mixed up with the line before
[20:23:48] <tfennelly> kcbabo: here... I think I'm talking out of my batty
[20:24:00] <tfennelly> kcbabo: :)
[20:24:04] <tfennelly> kcbabo: brb
[20:24:09] <kcbabo> tfennelly:  :-)
[20:39:29] <tfennelly> kcbabo: back... so I'm fairly sure our beans would just work in JSF etc... no need for adding client proxies... but they'd just be beans like any other CDI bean and would not be invoked via our exchange mechanism
[20:39:47] <tfennelly> kcbabo: so that was a brain fart from me... no need for the proxies
[20:40:51] <tfennelly> kcbabo: the part that maybe wasn't a brain fart was the idea of creating proxies for non-bean impl services that have a java interface (<interface.java>)
[20:40:54] <kcbabo> tfennelly:  the case that's more interesting to me is removing the requirement for using a "dummy" bean that has an @Reference in it
[20:41:02] <kcbabo> tfennelly:  but that's probably something we can chase up later
[20:41:23] <kcbabo> tfennelly:  right, which brings us back to the question of how you would detect that those proxies need to be created
[20:41:48] <tfennelly> kcbabo: not sure about that... but I'm sure there's a way
[20:42:26] <kcbabo> tfennelly:  there's always a way :-)
[20:42:43] <kcbabo> tfennelly:  but like I said, the dummy bean route works for now
[20:42:44] <tfennelly> kcbabo: anyway... lets forget about it for now
[20:42:53] <kcbabo> tfennelly:  just add a bean which contains an @Reference and voila
[20:43:00] <tfennelly> kcbabo: lovely
[20:43:06] <kcbabo> tfennelly:  JSP calls that which already has the proxy created
[20:43:48] <kcbabo> tfennelly:  you know what?  maybe we just supporting adding a reference to the config directly?
[20:43:49] <tfennelly> kcbabo: I think the JSP would work for any of our beans directly if you add the @Named annotation... no need for the Dummy
[20:43:58] <kcbabo> tfennelly:  then that gets merged in with the generated config
[20:44:11] <kcbabo> tfennelly:  it's not our beans that I'm talking about
[20:44:19] <kcbabo> tfennelly:  JSP calls a Camel service
[20:44:26] <tfennelly> kcbabo: ah right... sorry
[20:44:27] <kcbabo> tfennelly:  that's what I'm talking about
[20:44:30] <tfennelly> kcbabo: gotcha
[20:44:50] <kcbabo> tfennelly:  anyway, I think we could probably make something work there driven through config
[20:45:21] <tfennelly> kcbabo: don't you have all the info in the config already?
[20:45:29] <tfennelly> kcbabo: is there a need to add more?
[20:45:55] <tfennelly> kcbabo: is the existence of <interface.java> in the config not enough
[20:45:59] <tfennelly> kcbabo: ?
[20:46:07] <kcbabo> tfennelly:  well, you wouldn't know about services that are available outside the app
[20:46:15] <kcbabo> tfennelly:  you would need a reference for that
[20:46:31] <kcbabo> tfennelly:  which would be the configuration I'm talking about adding
[20:46:52] <tfennelly> kcbabo: so you mean just a reference version of <interface.java> ?
[20:46:53] <kcbabo> tfennelly:  add a reference to the config of a bean component impl to declare that it's used
[20:47:11] <tfennelly> kcbabo: right.... that would work
[20:47:21] <kcbabo> tfennelly:  yeah, something along those lines
[20:47:27] <kcbabo> tfennelly:  might work
[20:47:39] <tfennelly> kcbabo: would work for sure
[20:49:13] <tfennelly> kcbabo: ok... I think I'll create a different test for this thing then... just use the soap gateway or something
[20:49:27] <tfennelly> kcbabo: I was trying to get funky with servlets and jsf etc
[20:49:32] <kcbabo> tfennelly:  fair enough
[20:51:34] *** aamonten has joined #switchyard
[21:03:01] <kcbabo> errantepiphany:  can you please push this pull request when you have a minute?
[21:03:02] <kcbabo> https://github.com/jboss-switchyard/components/pull/199
[21:03:08] <errantepiphany> kcbabo: yup.
[21:03:08] <kcbabo> errantepiphany:  fixes up the bpm component packaging
[21:03:25] <kcbabo> errantepiphany:  next failure is a slf4j version conflict in your quickstart
[21:03:31] <kcbabo> errantepiphany:  which is not your fault
[21:03:52] <kcbabo> errantepiphany:  but I think bringing in the extra dependencies for bpm packaging has bled in slf4j
[21:04:08] <kcbabo> errantepiphany:  which leads to an API and impl version conflict when running the test
[21:04:28] <errantepiphany> kcbabo: gotcha
[21:04:34] <kcbabo> errantepiphany:  so I'm just going to add a test-scope dependency to that test for the correct slfj4 version impl
[21:04:52] <kcbabo> errantepiphany:  it's amazing how much stuff goes wrong when the build is broken
[21:48:21] *** GitHub5 has joined #switchyard
[21:48:21] <GitHub5> [components] errantepiphany pushed 1 new commit to master: http://bit.ly/qvXOv6
[21:48:21] <GitHub5> [components/master] SWITCHYARD-375 Change BPM component dependency to jdt.core.compiler from jdt.core - Keith Babo
[21:48:21] *** GitHub5 has left #switchyard
[22:07:51] <kcbabo> errantepiphany:  here's the other one related to that
[22:07:53] <kcbabo> errantepiphany:  https://github.com/jboss-switchyard/quickstarts/pull/59
[22:08:00] <kcbabo> errantepiphany:  whenever you have a chance
[22:08:12] <kcbabo> errantepiphany:  I should say "related to our discussion about slf4j"
[22:08:26] <kcbabo> errantepiphany:  after that, all of the builds should be back to green
[22:09:03] <errantepiphany> kcbabo: yeah, yeah - I saw it.
[22:09:04] <errantepiphany> ;)
[22:09:15] <kcbabo> errantepiphany:  hehe ? just wanted to make sure
[22:09:34] <kcbabo> errantepiphany:  I dropped about a day and a half on this, so I'm anxious to get the builds back to green
[22:09:49] <kcbabo> errantepiphany:  and I'm gonna watch them like a hawk now
[22:15:02] *** ldimaggi has quit IRC
[22:19:02] *** antollinim has quit IRC
[22:25:47] *** aamonten has quit IRC
[22:30:29] *** GitHub187 has joined #switchyard
[22:30:29] <GitHub187> [quickstarts] errantepiphany pushed 1 new commit to master: http://bit.ly/oFfANm
[22:30:29] <GitHub187> [quickstarts/master] SWITCHYARD-376 Add slfj4 dependency at test-scope for helpdesk quickstart - Keith Babo
[22:30:29] *** GitHub187 has left #switchyard
[23:04:58] *** bfitzpat has quit IRC





top