[00:28:56] *** antollinim__ has joined #switchyard
[00:29:09] *** antollinim_ has quit IRC
[00:38:09] *** antollinim__ has quit IRC
[00:56:31] *** bfitzpat has quit IRC
[01:05:29] *** rcernich_away is now known as rcernich
[01:06:08] *** ldimaggi has joined #switchyard
[01:09:50] *** aslak has quit IRC
[01:52:12] *** kcbabo has joined #switchyard
[14:09:18] *** echelog-2 has joined #switchyard
[14:16:49] *** antollinim__ has joined #switchyard
[14:17:34] *** antollinim__ is now known as antollinim
[14:22:23] *** kcbabo has quit IRC
[15:02:41] *** ldimaggi has joined #switchyard
[15:07:13] *** aamonten has joined #switchyard
[15:20:56] *** bfitzpat has joined #switchyard
[15:39:01] *** magesh has left #switchyard
[15:43:09] *** rcernich has joined #switchyard
[16:04:31] *** kcbabo has joined #switchyard
[16:12:08] *** tcunning has joined #switchyard
[16:14:29] *** rbalent has quit IRC
[16:32:19] <kcbabo> rcernich:  sorry it's taking longer than expected with the admin stuff
[16:32:26] <kcbabo> rcernich:  still plugging away - soon
[16:32:28] <rcernich> no worries
[16:32:45] <rcernich> kcbabo: i had one question: what do components map to?
[16:32:58] <rcernich> kcbabo: are they switchyard components or sca components
[16:33:06] <kcbabo> rcernich:  switchyard components
[16:33:20] <rcernich> kcbabo: ok
[16:33:32] <kcbabo> rcernich:  i've really tried to come to a set of terms where those can be clearly separated
[16:33:42] <kcbabo> rcernich:  best explanation I could come up with is this:
[16:34:46] <kcbabo> rcernich:  components represent modular packages of functionality and can be broken down into : implementation components, gateway components, service components
[16:36:12] <rcernich> kcbabo: so are they part of the application or the system?
[16:36:30] <kcbabo> rcernich:  implementation and gateway components?
[16:36:37] <kcbabo> rcernich:  part of the system
[16:36:47] <rcernich> kcbabo: e.g. is the camel component a component which delivers implementation, gateway and service capabilities?
[16:37:03] <kcbabo> rcernich:  applications deliver service components
[16:38:38] <rcernich> kcbabo: so if i call getComponents(), i'll get things like camel, clojure, bean, etc.?
[16:38:56] <kcbabo> rcernich:  correct
[16:39:09] <rcernich> kcbabo: cool.  just needed some clarification
[16:39:52] <rcernich> kcbabo: if you've got the basic framework laid, i don't mind filling in the details
[16:40:10] <rcernich> kcbabo: if you want to hand it off
[16:41:57] <kcbabo> rcernich:  sadly enough, I'm still on the basic stuff :-(
[16:42:04] <kcbabo> rcernich:  couple hours should be enough
[16:42:12] <rcernich> kcbabo: ok
[16:42:41] <rcernich> kcbabo: just offering
[16:43:11] <kcbabo> rcernich:  oh, I'll definitely hand off quickly and leave the work to you :-)
[16:43:13] <rcernich> kcbabo: i think i will adjust the terms used in the console to match what you're using in the api
[16:43:18] <rcernich> :D
[16:43:26] <kcbabo> rcernich:  just not going to force you to write my javadoc and fix checkstyle ? even I'm not that bad
[16:43:59] <kcbabo> rcernich:  I already have more thoughts on name and API changes, but I figured we should just press forward with what's there now, then sit back and pick it apart
[16:44:04] <rcernich> kcbabo: that's ok.  i could probably use the practice;)
[16:44:35] <rcernich> kcbabo: checkstyle is good thing for me
[16:45:03] <rcernich> kcbabo: i've been one of those, just read the code, types of fellows
[16:45:08] <rcernich> kcbabo: if you get my meaning;)
[16:45:37] <rcernich> kcbabo: which is one of the reasons i love maven with m2eclipse
[16:45:46] <rcernich> kcbabo: i can, just read the code
[16:46:24] <kcbabo> yeah, it's super nci
[16:46:25] <kcbabo> nice
[16:46:48] <rcernich> kcbabo: anyway, it's more important your comfortable with the terminology
[16:46:57] <rcernich> kcbabo: i'm not a good name generator
[16:50:01] *** rcernich is now known as rcernich_brb
[17:04:11] *** tcunning has quit IRC
[17:04:44] *** tcunning has joined #switchyard
[17:06:47] *** rcernich_brb is now known as rcernich
[17:15:07] *** errantepiphany has joined #switchyard
[17:32:30] <antollinim> kcbabo: hey Keith, are you there?. I see you looked for me yesterday
[18:04:22] *** rcernich is now known as rcernich_away
[18:17:27] *** aslak has quit IRC
[18:17:51] *** aslak has joined #switchyard
[19:36:05] *** rcernich_away is now known as rcernich
[19:45:13] <antollinim> kcbabo: hey Keith, are you there?. I see you looked for me yesterday
[20:01:28] *** tfennelly has quit IRC
[20:05:07] <kcbabo> antollinim:  I reviewed the jaxb quickstart and I wasn't sure why OrderAck and OrderAckType are required
[20:05:41] <kcbabo> antollinim:  seems like you could just have OrderAck and have the annotations directly on that class
[20:06:30] <antollinim> kcbabo: I didn't want to mess with the wsdl too much. I think this works that way because of the wsdl
[20:07:09] <antollinim> kcbabo: I will try to remove the OrderAckType from the WSDL and make it work with the single class OrderAck
[20:07:30] <antollinim> kcbabo: the same could be done with the Order and OrderType, right?
[20:08:06] <kcbabo> antollinim:  I think there are two approaches here with the JAXB stuff
[20:08:37] <kcbabo> antollinim:  case 1 : you have a set of Java objects and you want to map them to XML
[20:09:13] <kcbabo> antollinim:  for this, I would expect that you would annotate your classes with JAXB annotations and then generate a schema from them
[20:09:23] <kcbabo> antollinim:  this schema would then be included in any WSDL that you created
[20:09:42] <kcbabo> antollinim:  case 2 : you have an existing WSDL and you want to create a Java implementation that maps to it
[20:09:57] <antollinim> kcbabo: I followed approach 2
[20:10:03] <kcbabo> antollinim:  for this, I would expect that you would generate the objects off of the schema with JAXB
[20:10:10] <kcbabo> antollinim:  well, not exactly :-)
[20:10:36] <antollinim> kcbabo: why not?
[20:10:44] <kcbabo> antollinim:  the quickstart you are using already has the objects for the interface, which I think is what is causing the confusion
[20:10:57] <kcbabo> antollinim:  at least, as far as I can tell
[20:11:38] <kcbabo> antollinim:  so in case 2 I described above, you have the schema and you generate the objects that map to it
[20:11:40] <antollinim> kcbabo: yes, I am starting with the WSDL and generating the JAXB Objects with wsconsume
[20:11:54] <antollinim> kcbabo: yes, that is exaclty what I did
[20:12:09] <antollinim> kcbabo: however....
[20:12:29] <antollinim> kcbabo: I had in mind the way the Service should look like
[20:13:03] <antollinim> kcbabo: so, after the objects where generated, I had to create a Service which did not look like I expected
[20:13:19] <antollinim> kababo: that was way I triggered the discussion on the forum
[20:13:42] <antollinim> kcbabo: you gave me the right hint, the wsdl was not good enough
[20:14:37] <antollinim> kcbabo: so I changed it and it still is not generating what we would like: having a single order and a single OrderAck
[20:15:33] <antollinim> kcbabo: am I confussing you?
[20:17:32] <wyer> errantepiphany, i am going through the bpm wiki and the code now this is really awesome stuff!
[20:18:06] <kcbabo> antollinim:  I see the change you made w/r/t changing the wrapper element name ? is that what you are referring to?
[20:18:46] *** kcbabo has quit IRC
[20:18:54] *** kcbabo has joined #switchyard
[20:19:48] <errantepiphany> wyer: Glad you like it. And it's about to get "awesomer" with a commit you'll see later today or tomorrow... ;)
[20:20:38] <antollinim> kcbabo: I changed the submitOrder and submitOrderResponse element types in the wsdl
[20:21:29] <antollinim> kcbabo: they looked like this: <xs:element name="submitOrder" type="tns:submitOrderType"/>         <xs:element name="submitOrderResponse" type="tns:submitOrderResponseType"/>
[20:21:42] <antollinim> kcbabo: now they look like this: <xs:element name="submitOrder" type="tns:Order"/>         <xs:element name="submitOrderResponse" type="tns:OrderAck"/>
[20:22:10] <kcbabo> antollinim:  can you elaborate on why you did that?
[20:22:17] <wyer> errantepiphany, i'll keep an eye open for that i am running on the edge so you can expect me to try it out as soon as its available
[20:22:59] <errantepiphany> wyer: nice. thx. :)
[20:23:43] <antollinim> kcbabo: I had taken the WSDL from the orders Demo, then used the wsconsume to generat the jaxbelements then, they did not look as I expected
[20:23:58] <antollinim> kcbabo: you hinted me to modify the wsdl, I did so
[20:24:41] <antollinim> kcbabo: I renamed the submitOrderType type to Order
[20:24:58] <antollinim> kcbabo: and submitOrderResponseType type to OrderAck
[20:25:34] <antollinim> kcbabo: them I regenerated the jaxb objects with wsconsume tool
[20:25:43] <kcbabo> antollinim:  I think what I said is that if you are staring with an existing class definition for the message content, you can annotate that class directly vs. generating from WSDL
[20:27:13] <wyer> errantepiphany, how do you envisage interaction with running processes ? embedding the current jbpm 5 gwt console into the SY console ?
[20:27:56] <antollinim> kcbabo: in the forum you mentioned the same both aproaches you mentioned here, so I took the "start from a correct wsdl" approach
[20:28:32] <errantepiphany> wyer: I don't personally see the benefit of embedding one within the other. Just have both consoles deployed.
[20:28:45] <antollinim> kcbabo: I could redo the quickstarts but starting from java Classes an then annotating them if you want
[20:28:52] <errantepiphany> wyer: *maybe* link from the SY console to the jbpm one... Maybe.
[20:29:18] <antollinim> kcbabo: maybe that is the exercise you want to try
[20:29:37] <wyer> errantepiphany, hrm the current jbpm console server runs the JBPM runtime within it doesn't it ?
[20:29:56] <kcbabo> antollinim:  so what you have today works, right?
[20:30:15] <kcbabo> antollinim:  it's just that it doesn't *feel* right because the type names and structure are a bit off
[20:30:24] <kcbabo> antollinim:  did I get that right?
[20:30:33] <antollinim> kcbabo: yeah, exactly that
[20:30:44] <wyer> errantepiphany, so i imagine just the console needs to be deployed and connected to the jbpm runtime within SY
[20:30:45] <errantepiphany> wyer: I don't know for sure. My bet is it just uses the jBPM APIs required to interact/query/manage jBPM processes.
[20:30:48] <kcbabo> antollinim:  right, so that's why I was going through the bit about the two cases
[20:31:01] <kcbabo> antollinim:  I think you are sandwiched in between the two cases :-)
[20:31:24] <kcbabo> antollinim:  so you followed approach #2 up to the point where it got you to the service implementation
[20:31:32] <kcbabo> antollinim:  but the existing service implementation didn't match up exactly right
[20:31:37] <errantepiphany> wyer: There isn't really a jBPM "runtime". Well, besides a few threads that see if there's any auto/timed-triggering that needs to occur. Everything else happens because of external interactions that trigger work to be done, and state to be changed in the databased.
[20:31:54] <wyer> errantepiphany, its two projects atm console and console-server, the console-server part exposes a whole lot of REST api's for the console to use
[20:32:23] <antollinim> kcbabo: exactly, the generated code from the wsdl made me change the Service I was expecting to have
[20:32:34] <errantepiphany> wyer: well, that's how the old jbpm was anyway... there could be more interesting things going on now that it's tightly integrated with the drools runtime.
[20:32:45] <wyer> errantepiphany, i imagine its just a case of exposing those API's ah well was just wondering :)
[20:32:53] <errantepiphany> wyer: ah, yeah - I'm not that familiar with that (admin) end of things.
[20:33:36] <wyer> errantepiphany, me either i was trying to get 5.1 deployed into AS 7 so i did a lot of digging heh
[20:33:53] <wyer> errantepiphany, the console server from 5.1 i mean
[20:34:22] <errantepiphany> understood
[20:34:46] <kcbabo> antollinim:  right, so my expectation is that if you are going the generation route, you take the wsdl, generate the jAXB objects, then go about implementing the service using those types
[20:34:53] <kcbabo> antollinim:  so nothing would appear off there
[20:35:14] <antollinim> kcbabo: exactly this is exactly what I did
[20:35:54] <kcbabo> antollinim:  then what was it about the service implementation that you did not expect?
[20:36:00] <antollinim> kcbabo: why do you have the impression that I did sth different?
[20:36:18] <kcbabo> antollinim:  because you are saying that the service implementation is different from what you expected
[20:36:28] <antollinim> kcbabo: yes yes...
[20:36:28] <kcbabo> antollinim:  I'm trying to understand what it is you expected
[20:37:54] <antollinim> kcbabo: I was expecting the service to look exaclty like the one used in the submitOrder demo, with a parameter called "Order" and a reponse called "OrderAck"
[20:38:28] <kcbabo> antollinim:  but that's exactly what I said above - you have an existing implementation
[20:38:37] *** rbalent has joined #switchyard
[20:38:38] *** rbalent has joined #switchyard
[20:39:01] <wyer> errantepiphany, build the helpdesk demo it built and passed tests and i deployed and it blew up on deployment with http://pastebin.com/gDb89JyD
[20:39:13] <antollinim> kcbabo: I had an existing implementation in mind, it was what I was expecting to look like
[20:40:02] <antollinim> kcbabo: I had seen (no implemented) how the submitOrder should look like, so I was expecting to be able ti implement it that way
[20:40:25] <errantepiphany> wyer: Probably because of this: https://issues.jboss.org/browse/SWITCHYARD-336
[20:40:30] <errantepiphany> wyer: I'm hitting that one this week.
[20:40:41] <antollinim> kcbabo: but the generated code forced me to implement the service in a different way that the one I had in mind
[20:41:00] <errantepiphany> wyer: You certainly are "bleeding edge"... LOL.
[20:41:26] <kcbabo> antollinim:  right, so you went with approach #2 and it did not result in the same implementation that you might have had with approach #1
[20:41:40] <antollinim> kcbabo: exactly!
[20:41:53] <wyer> errantepiphany, heh ;)
[20:42:17] <kcbabo> antollinim:  don't expect that ;-)
[20:42:23] <wyer> errantepiphany, can i work around it for now ?
[20:42:34] <kcbabo> antollinim:  the reason is that there are default WSDL generation rules in JAX-WS
[20:43:06] <kcbabo> antollinim:  which represents one way to structure the object definition
[20:43:24] <errantepiphany> wyer: You *could*, but it would be a PITA... Basically hafta go through and make sure all of the bpm components dependencies, and their dependencies, are included in the assembly of the as7 distribution. Basically, what that Jira represents...
[20:43:41] <kcbabo> antollinim:  so I have an interesting idea here
[20:43:55] <antollinim> kcbabo: that was looked weird to me, that the databinding procedure would impact into the service implementation
[20:44:05] <errantepiphany> wyer: If you can wait until the end of the week, it will be there (at least on github).
[20:44:09] <antollinim> kcbabo: I was expecting it to be transparent
[20:44:24] <kcbabo> antollinim: it impacts the object model that the implementation is using
[20:44:34] <kcbabo> antollinim:  that's just gonna go along with the territory with JAXB
[20:44:57] <wyer> errantepiphany, i'll go through that and if i get it working (AS 7 at least) will push to my fork you can pull that it may save you some sweat
[20:45:08] <kcbabo> antollinim:  if you don't want that to happen, then going with another transformer (e.g. Smooks) would be the best bet
[20:45:08] <errantepiphany> wyer: much appreciated.
[20:45:24] <kcbabo> antollinim:   can you implement a @WebService bean real quick that has the same interface?
[20:45:44] <kcbabo> antollinim:  basically a single method called submitOrder with the Order and OrderAck objects?
[20:45:57] <kcbabo> antollinim:  then generate a WSDL off of that and see what it looks like
[20:46:08] <kcbabo> antollinim:  I think it would be interesting to compare to the one we are using for OrderService
[20:46:18] <antollinim> kcbabo: you mean to go with the approach #1?
[20:46:59] <kcbabo> antollinim:  approach #1 would be to take the existing OrderService quickstart and add JAXB annotations to it
[20:47:42] <kcbabo> antollinim:  but it would not involve generating the WSDL
[20:47:54] <kcbabo> antollinim:  you would just generate schema from the JAXB annotated classes
[20:48:03] <antollinim> kcbabo: so you mean letting switchyard aside, just use a java to wsdl tool?
[20:48:12] <kcbabo> antollinim:  exactly!
[20:48:18] <kcbabo> antollinim:  let's see what that looks like
[20:48:33] <antollinim> kbabo: ok, let me do that...
[20:48:35] <kcbabo> antollinim:  then my suggestion would be to take that WSDL and follow the exact same approach you have done
[20:49:08] <kcbabo> antollinim:  and you should be able to simply strip off the @WebService from the service interface and use that as the basis for your implementation.bean
[20:49:33] <antollinim> kcbabo: you want to check if it is a bi-directional method?
[20:50:02] <kcbabo> antollinim:  yeah, kind of
[20:50:16] <antollinim> kcbabo: ok, good
[20:50:18] <kcbabo> antollinim:  the WSDL that we have there now is quite likely not how JAX-WS would generate it for a web service
[20:50:39] <kcbabo> antollinim:  I wrote it myself from scratch, so you know that it's gonna be unique (to use a nice word) :-)
[20:51:31] <antollinim> kcbabo: you are brave, I always avoid to write XMLs myself
[20:51:51] <kcbabo> antollinim:  which means you are wise and I am not ;-)
[20:52:15] <antollinim> kcbabo: the other side of the coin haha
[20:58:33] *** rbalent has quit IRC
[21:04:01] *** rbalent has joined #switchyard
[21:04:02] *** rbalent has joined #switchyard
[21:06:47] *** rbalent has quit IRC
[21:08:44] <wyer> errantepiphany, the modules in the src/build/resources/module.xml file are those the dependencies ?
[21:09:03] <wyer> errantepiphany, if i look at soap or bean components
[21:09:37] <errantepiphany> wyer: yup
[21:09:53] <wyer> errantepiphany, and those refer to maven artifacts ?
[21:12:04] <errantepiphany> wyer: yes
[21:23:17] <kcbabo> rcernich:  did my email make sense w/r/t where the admin stuff needs to hook in?
[21:23:23] <rcernich> yep
[21:23:35] <rcernich> kcbabo: created the service
[21:23:40] <rcernich> kcbabo: hooking it in now
[21:23:51] <kcbabo> rcernich:  awesome ? sorry to leave you short there
[21:24:00] <rcernich> kcbabo: i'm adding it in through the subsystem add operation
[21:24:02] <kcbabo> rcernich:  but sounds like you just flew right past it
[21:24:12] <rcernich> kcbabo: no worries
[21:24:37] <rcernich> kcbabo: i've been mucking around with the as7 extension mechanism and management stuff for a while now
[21:24:37] <kcbabo> rcernich:  ok, so after we get that plumbed, I have plenty of nasty stuff to say about the API I created :-)
[21:24:52] <rcernich> kcbabo: it's a start!
[21:25:16] <kcbabo> rcernich:  yeah, from prior experience I've learned that it's best to get some data on the screen first, then start picking it apart
[21:25:30] <rcernich> kcbabo: yep
[21:25:45] <kcbabo> rcernich:  I think this has potential to be pretty damn cool
[21:25:57] <rcernich> kcbabo: yeah
[21:26:35] <rcernich> kcbabo: i'm excited about getting something going with guvnor and/or savara
[21:26:45] <rcernich> kcbabo: baby steps, though:)
[21:26:56] <kcbabo> rcernich:  ooh, that reminds me ? need to double back to your email
[21:27:14] <kcbabo> rcernich:  sorry, I've been so scattered this week - stuff coming from all directions
[21:27:18] <rcernich> kcbabo: no worries
[21:27:30] <rcernich> kcbabo: i'm still getting up to speed on all things jboss.org
[21:28:21] <rcernich> kcbabo: john g asked me to talk to kurt and that ended up moving me in all sorts of directions
[21:28:21] <kcbabo> rcernich:  that is a neverending adventure ? kind of like downloading all of your maven dependencies
[21:28:35] <rcernich> kcbabo: tell me about it:)
[21:28:43] <kcbabo> rcernich:  I never pass up an opportunity to take a swipe at maven ;-)
[21:29:04] <rcernich> kcbabo: i've always thought that one of the keys to adoption of soa across the enterprise was the repo piece
[21:29:25] <kcbabo> rcernich:  tom and I were talking about this a bit this morning
[21:29:26] <wyer> kcbabo, maven is the yang to git's ying
[21:29:49] <kcbabo> wyer: more like the yuck to git's yum
[21:29:50] <rcernich> kcbabo: it's easy enough to create departmental solutions, but once you start moving out across teams, things start to get hairy fast
[21:30:10] <kcbabo> rcernich:  totally, also very easy with just one org to create so many services over time that you lose track
[21:30:15] <rcernich> kcbabo: and then, knowing what's deployed where, ugh
[21:30:32] <rcernich> kcbabo: yep. have to create a new team just to track it all
[21:30:36] <kcbabo> rcernich: don't worry, switchyard solves all of those problems ? let me know when it's done
[21:30:42] <kcbabo> ;-)
[21:30:44] <wyer> haha
[21:30:53] <rcernich> kcbabo: will do :D
[21:31:26] <wyer> switchyard our last, best hope for soa ;)
[22:00:31] *** ldimaggi has quit IRC
[22:03:25] <wyer> errantepiphany, okay i've got it generating the zip for the bpm component but i must be missing a step
[22:04:59] <wyer> errantepiphany, the release build fails on testing because: Caused by: org.jboss.modules.ModuleLoadError: Module org.drools.drools-core:main is not found
[22:05:21] <wyer> errantepiphany, i added org.drools.drools-core to the modules.xml
[22:07:02] <wyer> errantepiphany, ah i missed some things in assembly.xml i think let me try again
[22:07:45] <errantepiphany> wyer: :)
[22:38:30] <wyer> errantepiphany, to clarify, i would include drools as a dependency because jbpm depends on it ?
[22:39:09] <errantepiphany> wyer: yes
[22:39:22] <wyer> errantepiphany, great
[22:39:23] <wyer>
[22:39:27] <wyer> i ma
[22:39:31] <errantepiphany> wyer: jbpm 5.1.0.Final depends on drools 5.2.0.Final, iir
[22:39:34] <wyer> %&&^%$ cat
[22:39:58] <wyer> errantepiphany, thats right
[22:40:09] <wyer> i may just pull this off ;)
[22:40:18] <errantepiphany> wyer: ;)
[22:46:14] <wyer> errantepiphany, if i miss a dependency would i see something along the lines of a class not found exception at runtime ?
[22:48:36] <errantepiphany> wyer: most likely. sorry I haven't had a chance to get as far down as the path as you... otherwise I'd be more help. I will look at what you have once you push to your remote repo tmrw or whenev. Gotta finish up some other stuff right now then run...
[22:49:20] <wyer> errantepiphany, no problem thanks for been such a help
[22:50:45] <errantepiphany> wyer: np
[23:09:56] *** errantepiphany has left #switchyard
[23:16:53] *** PeteRoyle has joined #switchyard
[23:31:47] *** aamonten has quit IRC
[23:34:25] <antollinim> kcbabo: you there?
[23:36:18] <antollinim> kcbabo: I was able to start from Java -> using axis2 got the wsdl -> using wsconsume got the jaxb classes
[23:36:54] <antollinim> kcbabo: the final output does not look very nice...
[23:47:47] <antollinim> kcbabo: have to go now. I'll talk to you tomorrow. good night
[23:53:26] *** antollinim has quit IRC





top