[00:13:11] *** bfitzpat_away has quit IRC
[00:13:30] *** rcernich has joined #switchyard
[00:46:16] *** rcernich is now known as rcernich_away
[02:01:56] *** kcbabo has joined #switchyard
[02:11:09] *** kcbabo has quit IRC
[02:27:24] *** rcernich_away is now known as rcernichy
[02:27:28] *** rcernichy is now known as rcernich
[03:16:40] *** rcernich has quit IRC
[04:37:57] *** ldimaggi has joined #switchyard
[05:05:30] *** ldimaggi has quit IRC
[05:38:28] *** dbevenius has joined #switchyard
[05:39:01] *** magesh has joined #switchyard
[05:56:57] *** tcunning has left #switchyard
[06:31:09] *** magesh1 has joined #switchyard
[06:32:22] *** magesh has quit IRC
[06:35:15] *** magesh1 has quit IRC
[06:37:26] *** magesh has joined #switchyard
[06:42:49] *** magesh has quit IRC
[06:44:25] *** magesh has joined #switchyard
[06:52:36] *** dbevenius has quit IRC
[07:02:16] *** magesh1 has joined #switchyard
[07:03:03] *** magesh has quit IRC
[07:48:37] *** aslak has joined #switchyard
[07:48:37] *** aslak has joined #switchyard
[07:55:36] *** dbevenius has joined #switchyard
[07:59:21] *** magesh has joined #switchyard
[07:59:30] *** magesh1 has quit IRC
[08:03:52] *** magesh has quit IRC
[08:33:42] *** rbalent has joined #switchyard
[08:33:42] *** rbalent has joined #switchyard
[08:58:21] *** magesh has joined #switchyard
[11:32:30] *** dbevenius has quit IRC
[11:32:39] *** dbevenius has joined #switchyard
[11:42:35] *** dbevenius has quit IRC
[12:01:16] *** rbalent has quit IRC
[12:39:23] *** dbevenius has joined #switchyard
[14:05:16] *** kcbabo has joined #switchyard
[14:05:19] *** kcbabo has joined #switchyard
[14:30:26] *** magesh has quit IRC
[15:02:35] *** ldimaggi has joined #switchyard
[15:24:00] *** bfitzpat has joined #switchyard
[15:49:45] *** tcunning has joined #switchyard
[15:51:31] *** errantepiphany has joined #switchyard
[16:00:34] *** antollinim has joined #switchyard
[16:08:26] *** ldimaggi has quit IRC
[16:15:06] *** rcernich has joined #switchyard
[16:24:07] *** ldimaggi has joined #switchyard
[16:38:54] *** rcernich is now known as rcernich_brb
[17:16:38] *** rcernich_brb is now known as rcernich
[17:35:00] *** kcbabo has quit IRC
[17:39:25] *** ldimaggi has quit IRC
[17:46:29] *** kcbabo has joined #switchyard
[17:53:00] *** ldimaggi has joined #switchyard
[18:16:37] *** lanceball has joined #switchyard
[18:47:56] *** antollinim is now known as antollinim_lunch
[19:06:17] *** lanceball has quit IRC
[19:12:47] *** rcernich is now known as rcernich_brb
[19:20:02] *** ldimaggi has quit IRC
[19:22:12] *** tfennelly has quit IRC
[19:31:21] <kcbabo> rcernich_brb:  hey - what's the current state of the admin api?
[19:31:35] <kcbabo> rcernich_brb:  wanted to review it again, but wasn't sure if you had some stuff locally that needs to be pushed
[19:31:41] <kcbabo> rcernich_brb:  just about to reply to your forum post
[19:33:09] *** ldimaggi has joined #switchyard
[19:50:38] *** rbalent has joined #switchyard
[19:52:42] *** rcernich_brb is now known as rcernich
[19:53:05] <rcernich> kcbabo: hey keith
[19:53:20] <rcernich> kcbabo: i have been pushing changes as i work through stuff
[19:53:20] <kcbabo> rcernich:  hey rob
[19:53:32] <rcernich> kcbabo: lemme get the latest commit
[19:54:14] <rcernich> kcbabo: https://github.com/rcernich/core/commit/250a7ddbfa1ebf554dbebb12910d51b439c8bc97
[19:54:14] <kcbabo> rcernich:  sure, no rush
[19:54:23] <kcbabo> rcernich:  just figured I should comment on the latest and greatest :-)
[19:54:32] *** aslak has quit IRC
[19:54:51] <rcernich> kcbabo: i've been using "append to previous" as opposed to creating separate commits for every bit of work
[19:54:56] <rcernich> not sure if that is best or not
[19:55:17] <kcbabo> rcernich:  what the heck is "append to previous"?
[19:55:28] <rcernich> kcbabo: creates the same problem as squashing if the branch was upstream of another branch
[19:55:49] <rcernich> kcbabo: ahh, you can modify the previous commit with current changes
[19:56:09] <rcernich> kcbabo: but, because it changes the commit, it changes the history
[19:56:25] <kcbabo> rcernich:  is this part of push?
[19:56:34] <rcernich> kcbabo: sorry, git commit --amend
[19:56:46] <kcbabo> rcernich:  ah, ok
[19:57:03] <kcbabo> rcernich:  yeah, that sounds about right
[19:57:04] <rcernich> kcbabo: (i'm getting used to the egit terminology.  having to straddle egit and cli)
[19:57:18] <kcbabo> rcernich:  so the link above is the latest?
[19:57:40] <rcernich> kcbabo: yeah
[19:58:14] <rcernich> kcbabo: everything is in my 345 branch, so you can always look at the commits for that branch to see what the heck i'm up to w.r.t. 345
[20:00:06] *** antollinim_lunch is now known as antollinim
[20:01:44] <kcbabo> rcernich:  I'm still scratching my head a bit on the archive name
[20:01:55] <rcernich> kcbabo: yeah
[20:02:08] <rcernich> kcbabo: i think it's ugly
[20:02:34] <rcernich> kcbabo: but i think we're probably going to need to have some relationship between application name and deployment archive
[20:03:20] <kcbabo> rcernich:  why is that?
[20:05:11] <kcbabo> rcernich:  regarding name - the name attribute on an sca:composite is required
[20:05:12] <rcernich> kcbabo: one, if we intend to do allow any server operation off the application node
[20:05:24] <kcbabo> rcernich:  we should just use that if the switchyard application name is not specified
[20:05:35] <rcernich> kcbabo: also, from a user perspective, i think it would be nice to know which package is contributing the application
[20:06:31] <rcernich> kcbabo: i can remove it and push it down to the runtime specific implementation to manage that relationship
[20:06:55] <kcbabo> rcernich:  just trying to think how it might map elsewhere
[20:07:06] <kcbabo> rcernich:  OSGi bundle provides the original bundle archive name?
[20:07:10] <rcernich> kcbabo: i understand
[20:07:18] <kcbabo> rcernich:  can't remember if that's part of the bundle metadata available or not
[20:07:33] <rcernich> kcbabo: i think.  there may be a couple different identifiers
[20:07:42] <rcernich> kcbabo: there's bundle name and bundle id
[20:07:45] <kcbabo> rcernich:  symbolic name is definitely there
[20:07:47] <rcernich> kcbabo: if i recall correctly
[20:07:50] <rcernich> kcbabo: yes
[20:07:53] <kcbabo> rcernich:  right, but those are distinct from the archive name
[20:08:09] <rcernich> kcbabo: yep.  do you want to change the name maybe?
[20:08:11] <kcbabo> rcernich:  which I think largely becomes irrelevant from an admin perspective in OSGi
[20:08:20] <rcernich> kcbabo: exactly
[20:08:20] <kcbabo> rcernich:  everything is driven off of the bundle id or the symbolic name
[20:08:24] <rcernich> kcbabo: yes
[20:08:50] <kcbabo> rcernich:  nah - I should just shut my mouth
[20:08:53] <rcernich> kcbabo: would a more generic term be better
[20:08:59] <kcbabo> rcernich:  we're still experimenting here, so archive name is fine
[20:08:59] <rcernich> kcbabo: please don't
[20:09:16] <kcbabo> rcernich:  but I do think we want to can that logic which sets the application name based on archive name
[20:09:23] <kcbabo> rcernich:  and the generation logic based on UUID
[20:09:47] <antollinim> kcbabo: hi Keith, please let me know when you have a minute...
[20:10:04] <kcbabo> rcernich:  since composite name is required, we can use that if no application name is specified in the switchyard config
[20:10:30] <rcernich> kcbabo: but composite isn't required
[20:11:09] <kcbabo> rcernich:  it is for any application that we will be using in the admin api
[20:11:18] <rcernich> kcbabo: fyi, i added that uuid crap because some of the deployment extensions used in the test framework don't specify a config
[20:11:44] <rcernich> kcbabo: i can leave it null in that case
[20:12:11] <kcbabo> rcernich:  I think that may be optional because we planned to support independent domain deployments
[20:12:18] <kcbabo> rcernich:  but I wouldn't view those as applications
[20:12:28] <kcbabo> rcernich:  so to put a bit of a cleaner definition on it
[20:12:42] <kcbabo> rcernich:  if a switchyard deployment does not contain a composite, then it's not an application
[20:12:55] <rcernich> kcbabo: ok
[20:13:09] <rcernich> kcbabo: would we have another category?
[20:13:10] <kcbabo> rcernich:  that's clearly not evident from the schema - so sorry about the confusion
[20:13:22] <kcbabo> rcernich:  yes, if you deploy a domain independently
[20:13:25] <rcernich> kcbabo: for deployments that contain domain details or transformations
[20:13:32] <kcbabo> rcernich:  right-o
[20:13:43] <kcbabo> rcernich:  still a bit of hand waving there, but that's the plan
[20:13:52] <kcbabo> antollinim:  hey mario - what's up?
[20:13:54] <rcernich> kcbabo: would you have all three in one deployment?
[20:14:22] <kcbabo> rcernich:  you can certainly have transformations and and a composite in one
[20:14:26] <antollinim> kababo: hey... I have been working on the standard doclit thing
[20:14:27] <kcbabo> rcernich:  and a domain as well
[20:14:29] <kcbabo> rcernich:  so yes
[20:14:32] <kcbabo> antollinim:  cool
[20:14:40] <rcernich> kcbabo: ok.  lemme think some more
[20:14:51] <kcbabo> rcernich:  but I wouldn't worry about the domain stuff for now
[20:14:54] <antollinim> kcbabo: but I want to double check with you that you intended to do this with the new wsdl
[20:14:57] <kcbabo> rcernich:  I need to hammer the details out on that
[20:15:10] <kcbabo> antollinim:  the new wsdl?
[20:15:32] <kcbabo> rcernich:  and I don't think we currently track transformers with the admin api
[20:15:39] <antollinim> kcbabo: yeah, the new one you generated: the not wrapped one
[20:15:45] <kcbabo> rcernich:  but that would be an interesting extension once we get this initial stuff popped
[20:15:58] <kcbabo> antollinim:  ah, for the jaxb quickstart?
[20:16:05] <kcbabo> antollinim:  yes, that's an example of doc lit
[20:16:10] <antollinim> kcbabo: yes
[20:16:11] <kcbabo> antollinim:  that's not wrapped
[20:16:15] <rcernich> kcbabo: have a look at SwitchYardDeploymentListener in admin.base
[20:16:20] <antollinim> kcbabo: http://cl1p.com/wsdl
[20:16:28] <rcernich> kcbabo: that guy is using the listener to populate the model
[20:16:33] <rcernich> kcbabo: when you get a chance
[20:16:53] <antollinim> kcbabo: the SOAP requeste generated from the old WSDL looks different than the one that gets generated for the new wsdl
[20:17:10] <antollinim> kcbabo: was that intended?
[20:17:10] <kcbabo> antollinim:  you mean one has a wrapper and the other doesn't? ;-)
[20:18:19] <antollinim> kcbabo: exactly, the soap generated from the non-wrapped wsdl does not have the operation. Is that ok?
[20:19:12] <kcbabo> antollinim:  yes, that's doc-lit
[20:19:38] <kcbabo> antollinim:  which is the bug - the SOAP gateway expects it to be wrapped with the operation name
[20:20:55] <antollinim> kcbabo: ok, thought the bug somewhere in the association between wsdl and soap, not just in reading the soap itself
[20:21:05] <antollinim> kcbabo: ok, I am in the good track, thanks
[20:22:17] <kcbabo> antollinim:  so the bug is that the SOAP gateway should check to see if the top-level element matches the part definition in the WSDL
[20:22:25] <kcbabo> antollinim:  so there is an interaction with the WSDL there
[20:23:40] <antollinim> kcbabo: yeah, I am almost there
[20:23:49] <kcbabo> antollinim:  okie dokie
[20:23:54] <antollinim> kcbabo: btw
[20:25:01] <antollinim> kcbabo: no, nothing, I'm good
[20:25:26] <kcbabo> antollinim:  ok - as you progress, it would be a good idea to keep magesh in the loop
[20:25:44] <kcbabo> antollinim:  he wrote that code and I'm sure he'll have some good ideas on how to fix it
[20:26:08] <kcbabo> rcernich:  looked at admin.base.SwitchYardDeploymentLIstener
[20:26:14] <antollinim> kcbabo: ok, good. What is his timezone?
[20:26:25] <kcbabo> rcernich:  he's in India, so whatever that is :-)
[20:26:43] <kcbabo> rcernich:  you can always send him email or a private message through the forum as well
[20:26:57] <antollinim> kcbabo: I'll guess he was ahaed of us, I barely see him
[20:27:14] <antollinim> kcbabo: sure, thanks
[20:27:17] <kcbabo> antollinim:  yeah, it's almost exactly the opposite of ET, IIRC
[20:27:31] <kcbabo> antollinim:  you can normally catch him in here in the early morning ET
[20:29:34] <kcbabo> antollinim:  just noticed that I replied to rcernich above, but meant it for you :-)
[20:29:41] <kcbabo> antollinim:  I think you figured that out though
[20:29:52] <antollinim> kcbabo: yeah, I did :)
[20:30:00] <kcbabo> rcernich:  the deployment listener looks ok to me
[20:30:13] <kcbabo> rcernich:  certainly good for getting us up and running to kick the tires
[20:30:15] <rcernich> kcbabo: so the way i have that setup now, it is relying on the name being initialized prior to the initializing notification
[20:31:15] <rcernich> kcbabo: i guess i could not add the application until service deployed is invoked
[20:31:40] <kcbabo> rcernich:  sorry, I lost you there
[20:32:00] <rcernich> kcbabo: sorry, just working through my crappy logic in that listener
[20:32:00] <kcbabo> rcernich:  is there a problem with setting the name prior to that notification?
[20:32:12] <rcernich> kcbabo: problem is setting it after
[20:32:15] <kcbabo> rcernich:  well, I've written tons of crappy logic, so I'm sure I can help
[20:32:27] <rcernich> kcbabo: or using the composite name
[20:32:45] <rcernich> kcbabo: i think i need to give this a bit more thought
[20:33:07] <rcernich> kcbabo: specifically how i am populating the model using the notifications
[20:33:37] <rcernich> kcbabo: i'll move on to prototyping the as7 integration and see what pops up there
[20:34:05] <kcbabo> rcernich:  you currently set the name in AbstractDeployment.init() right?
[20:34:13] <rcernich> kcbabo:  yep
[20:34:20] <kcbabo> rcernich:  you have access to the composite name there
[20:34:25] <rcernich> kcbabo: yep
[20:34:34] <kcbabo> rcernich:  ok, I'm lost :-)
[20:34:39] <kcbabo> rcernich:  what's the problem?
[20:34:42] <rcernich> kcbabo: i was just mulling the case where it's a domain or transformations deployment
[20:35:16] <rcernich> kcbabo: here's a thought
[20:35:39] <rcernich> kcbabo: would it be horrendously bad if we injected the concept of a deployment into the admin model
[20:35:58] <rcernich> kcbabo: with application, transforms and domain hanging off it?
[20:36:17] <rcernich> kcbabo: or, application being simply services
[20:36:38] <rcernich> kcbabo: i think that would clean up a lot of this
[20:36:55] <rcernich> kcbabo: i'll let you think on it
[20:39:12] <kcbabo> rcernich:  so in that case, I wonder if application would simply be replaced by deployment?
[20:39:32] <rcernich> kcbabo: i like having that concept: application
[20:40:08] <rcernich> kcbabo: it does distinguish between something that contributes services: an application
[20:40:18] <kcbabo> rcernich:  in that case, I think we should proceed with what we have now, with the understanding that we may insert a level above application called deployment
[20:40:21] <rcernich> kcbabo: vs. something that contributes transformations or domain settings
[20:40:37] <rcernich> kcbabo: and since a deployment may contain all three...
[20:41:41] <rcernich> kcbabo: and it gives the runtime implementation a nice handle for resolving the resource that is contributing those
[20:42:16] <rcernich> kcbabo: and they could still be rolled up in the global services, domains, transformations accessors in SwitchYard
[20:42:25] <rcernich> kcbabo: i'll move along for now
[20:42:31] <rcernich> kcbabo: thanks for looking at it
[20:42:39] <rcernich> kcbabo: and especially for all the feedback
[20:42:52] <kcbabo> rcernich:  yeah, sorry it's still a bit in flux
[20:42:59] <rcernich> kcbabo: no worries at all
[20:43:01] <kcbabo> rcernich:  but I think this was a productive conversation
[20:43:32] <rcernich> kcbabo: i'm still finding my way a bit
[20:44:34] <kcbabo> rcernich:  makes two of us
[20:44:47] <rcernich> kcbabo: :D
[20:52:38] *** aslak has joined #switchyard
[21:10:48] *** ldimaggi has quit IRC
[21:22:41] *** ldimaggi has joined #switchyard
[21:30:06] *** dbevenius has quit IRC
[22:03:04] *** ldimaggi has quit IRC
[22:18:38] *** ldimaggi has joined #switchyard
[22:59:27] *** errantepiphany has left #switchyard
[23:04:51] *** ldimaggi has quit IRC
[23:28:26] *** kcbabo has quit IRC
[23:38:15] *** antollinim has quit IRC





top