Here is the IRC chat we had around exposing DAS as an SCA container.
3[15:48] * ant_away is now known as ant_
3[15:50] * kevin_ has joined #TUSCANY
3[15:55] * Amita has joined #tuscany
[15:56] <ant_> hi Amita
[15:59] <Amita> Hi Ant
1[15:59] <lresende> hello Amita
[15:59] <Amita> Hi Luciano and Kevin, shall we start now?
[15:59] <kevin_> SOUNDS GOOD .... GOOD MORNING
[15:59] <kevin_> oops caps lock
1[16:00] <lresende> sure
2[16:00] * Amita has quit IRC (Client Quit)
3[16:00] * Amita has joined #tuscany
[16:00] <Amita> sorry lost connection for 1 min
[16:00] <kevin_> sorry i missed your invite last night
[16:00] <Amita> np
[16:01] <kevin_> did you and luciano get a chance to discuss the SCA
integration?
1[16:01] <lresende> we chated little bit, more towards getting the meeting
today
[16:01] <kevin_> i see
1[16:02] <lresende> i was just looking into the documentation and some code
provided by Amita
[16:02] <kevin_> i committed Luciano's sample this morning ... mayb e we can
start with that
1[16:02] <lresende> sure
[16:02] <ant_> quick question from me before you get into that,
1[16:02] <lresende> i conside the sample a first step on getting
integration between DAS and SCA
[16:02] <kevin_> you may have to help me with some terminology
[16:02] <kevin_> sure
[16:02] <kevin_> right
[16:02] <ant_> Amita, are you still looking at the stored procedure stuff?
[16:02] <kevin_> that makes sense
1[16:03] <lresende> in that, i expose DAS as simple SCA service and uses a
web app to consume it
[16:03] <Amita> looking at all CRUD+SP support and not only SP
1[16:03] <lresende> the service supports any kind of command supported by
das today
[16:03] <Amita> have a container supporting that for static and dynamic
approaches
[16:03] <ant_> so not a binding or container specifically for stored
procedures?
[16:03] <kevin_> ant , i think we can treat SP and CRUD the same
[16:03] <Amita> yes
[16:04] <ant_> was that a yes to me or kevin_?
[16:04] <Amita> yes - support all DAS commands not only SP
[16:04] <ant_> hmm
[16:05] <kevin_> ant ... do you think we need something specific to SP
[16:05] <Amita> ant - you have some point to deal with only SP - some
reason?
[16:05] <ant_> well thats what TUSCANY-876 was for. The use of DAS was just
an implementtaion detail
[16:06] <kevin_> my motivation id SCA/DAS
[16:06] <ant_> i understand
[16:06] <ant_> that
[16:06] <kevin_> do we need a seperate effort?
1[16:08] <lresende> ant: i have closed that, as Amita created a new one,
more generic... but looks like i should re-open that?
[16:08] <ant_> well both venkat and i have suggested that yes
[16:08] <kevin_> sounds like it is more and less generic :-)
[16:09] <ant_> you guys continue with what talking about on this chat, i
don't want to hold that up
[16:09] <kevin_> np, thanks
1[16:09] <lresende> thanks ant...
[16:09] <kevin_> luciano. i did not see a working test with the sample
[16:10] <kevin_> is that in the works or, did i just miss it
[16:10] <Amita> ant, still not clear about separate effort for SP?
[16:10] <kevin_> ok
1[16:10] <lresende> kevin: you mean, junit testing for das.service ?
[16:10] <kevin_> any test ... junit woiuld be good ... htmlUnit
1[16:11] <lresende> i'm planning to have same way we do for companyweb,
with htmlUnit and TC
[16:11] <kevin_> i did not see a way to test the sample
[16:11] <kevin_> cool
1[16:11] <lresende> comming
1[16:11] <lresende> soon
[16:11] <ant_> Amita, you're a volunteer so I want you to work on what
interests you. TUSCANY-876 can wait for who ever is interested
[16:12] <Amita> kevin: Kevin - one question - could not get you point on
Update SQL - in code am using dObj.set(idx, val);
[16:12] <kevin_> amita/ant . DAS/SCA integration is one thing ... I guess
that a generic SP integration couls be another
1[16:12] <lresende> TUSCANY-876 is reopened
[16:12] <Amita> OK
[16:13] <ant_> thx
[16:13] <kevin_> Amita. Are you referring to my question about using Change
History to drive updates?
1[16:14] <lresende> ok, Amita, do you have specific topics, questions
around the das container ? or around das ?
[16:15] <Amita> yes - one question - about DAS
[16:15] <Amita> would like to know use of ConnectionInfo tag for a non web
scenario
[16:15] <Amita> is there some code - I can take a look at - where for non
web , it is used?
1[16:15] <lresende> ok, first...
1[16:16] <lresende> i think we should probably add a SCDL tag for
connection info
[16:16] <kevin_> the connection tag is only used today to specify a
DataSource
[16:16] <kevin_> so, that us is specific to DataSource not web
[16:17] <kevin_> the other option is to explicitly provide the DAS with a
JDBC Connection instance3
1[16:17] <lresende> as we might deploy the same service into a C++
environment, and that connection info would be invalid
[16:17] <Amita> yes
[16:18] <Amita> so in Java, how to make the context available ? in web - we
can have it in server conf of tomcat etc
[16:18] <kevin_> so, all RDB DAS test cases use the Connection instance
approach since ...
[16:18] <Amita> but when standalone and want to use Connection info, how to
do?
1[16:18] <lresende> you would use something like :
[16:18] <kevin_> i have not found a nice way to exercise DataSource in J2SE
1[16:18] <lresende> private static String _driverName = "
org.apache.derby.jdbc.EmbeddedDriver";
1[16:18] <lresende> private static String _databaseURL =
"jdbc:derby:dastest;create=true";
1[16:18] <lresende> private static Connection createConnection() {
1[16:18] <lresende> Connection connection = null;
1[16:18] <lresende> try {
1[16:18] <lresende> Class.forName(_driverName).newInstance();
1[16:18] <lresende> // Get a connection
1[16:18] <lresende> connection = DriverManager.getConnection
(_databaseURL);
1[16:18] <lresende> connection.setAutoCommit(false);
1[16:18] <lresende> } catch (Exception except) {
1[16:18] <lresende> except.printStackTrace();
1[16:18] <lresende> }
1[16:18] <lresende> return connection;
[16:18] <Amita> oh ok
[16:19] <kevin_> but that is not the question
[16:19] <Amita> another question
[16:19] <kevin_> the question (if i understand) is whether ConnectionInfo
means anything outside of a managed environment
[16:19] <Amita> in DAS - lot of useful code is in Test Framework
[16:20] <Amita> can it be part of DAS core?
[16:20] <kevin_> it is meaningful today only if DataSource is available
[16:20] <Amita> got it
[16:20] <kevin_> a better name might be DataSourceInfo
1[16:20] <lresende> what do you mean ? code in test framework if more
towards buiding an environment for testing the api, like creating a canned
db and populating it
1[16:21] <lresende> not sure you really want to move that to core
[16:21] <Amita> I mean - the explicit connection stuff
[16:21] <Amita> is in TestFrameWork
1[16:21] <lresende> (e.g what you have in dataAccessHelper )
[16:21] <Amita> yes
[16:21] <kevin_> there is an API on the DASFactory to provide a Connection
instance
[16:21] <kevin_> so, it is in the core
[16:21] <Amita> OK
[16:22] <Amita> OK
[16:22] <Amita> will use that
[16:22] <kevin_> let me know if you see a better way to do this
[16:22] <Amita> yes, thank you, will do
1[16:22] <lresende> so, in a real environment, some of those would be
unecessary, like populating the db, as a db would be available...
[16:23] <Amita> yes
[16:23] <kevin_> right. that is all part of the test framework ...
1[16:23] <lresende> one way we simulate that, is also using integration
with TC, and setting up a pre-existing db there, for the client to use
[16:23] <kevin_> not in the "core"
1[16:23] <lresende> right.. and i don't see that in core.. right ?
[16:23] <kevin_> right
1[16:23] <lresende> k
[16:24] <Amita> another question, regarding static approach - in
CommandHelper -today
[16:24] <Amita> I have a very simple, logic for mapping Command<->API
3[16:24] * skurz_ has joined #tuscany
[16:25] <Amita> if we can have some code generation kind of tooling
[16:25] <kevin_> saw that ... looks interesting
[16:25] <Amita> and on the same lines
[16:25] <Amita> does DAS need to follow some convention for Command name?
1[16:25] <lresende> i think i heard people on the open source does not like
too much code generation
1[16:25] <lresende> can't we solve this with annotations /
[16:25] <kevin_> not today
1[16:25] <lresende> ?
[16:26] <Amita> kevin, what is not today?
[16:26] <kevin_> command naming conventions
[16:26] <Amita> ok
1[16:26] <lresende> ok, can i ask a question in your interface ?
1[16:27] <lresende> if I'm defining a service using CustomersOrdersService
interface...
1[16:27] <lresende> i'd expect order related methods there, right ?
1[16:27] <lresende> so, instead of execute.... we would have getOrders
[16:27] <Amita> yes
1[16:28] <lresende> and what I think you are considering dynamic way, we
might think about using Annotations or then we could introduce command
conventions
1[16:28] <lresende> where we would map getOrders to a getOrders command
1[16:28] <lresende> or...
1[16:29] <lresende> we would force the mapping to something like
1[16:29] <lresende> @AdHocQuery(SQL)
[16:29] <Amita> yes
1[16:29] <lresende> but i think we could start simple
1[16:29] <lresende> and keep growing
[16:29] <kevin_> yes
1[16:29] <lresende> so what you are providing is very good and give us a
start...
[16:29] <Amita> yes
[16:30] <kevin_> we should think about where this new container might live
1[16:30] <lresende> i have a question for ant and kevin and other old
commiters... what is best practice for two non-commiters to collaborate code
?
[16:30] <kevin_> is this part of DAS or part of SCA/
1[16:30] <lresende> the container would be part of SCA, i'd think
[16:31] <Amita> ok, another very basic question
[16:31] <Amita> about same
1[16:31] <lresende> and we might have the client in either place
1[16:31] <lresende> otherwise we would bring lot's of dependencies to DAS,
right ?
[16:31] <Amita> will it be useful to have service as well as container both
for the same thing?
[16:31] <kevin_> yes. we don't want DAS to depend on SCA
1[16:32] <lresende> then it definetly should go into sca
1[16:32] <lresende> unless they don't want sca to depend on das :)
1[16:32] <lresende> Amita: didn't get your last question...
[16:32] <kevin_> Luciano has done the sample as a step towards a container
1[16:32] <lresende> y
[16:32] <kevin_> so, eventually, i think we want only the container\
1[16:33] <lresende> sample gives you today, the ability to expose das for a
multilingual environment
[16:33] <Amita> oh ok
[16:33] <Amita> yes
1[16:33] <lresende> so, C++, or other language can consume a das service
from java
[16:33] <Amita> another question Kevin
[16:34] <Amita> in todays RDB DAS, the need to support diff dbs - is served
through test framework
[16:34] <kevin_> demonstrated ... nt served
[16:34] <Amita> for ConnectionInfo - the URL will point to reqd db right?
[16:34] <kevin_> "not"
[16:34] <Amita> ok
[16:35] <Amita> I mean say test framework is not there (assume)
[16:35] <Amita> how I will do it using Connection Info?
[16:35] <kevin_> if the Connection instance mechanism is used hen that is
the path to some JDBC database
[16:35] <Amita> ok
[16:35] <kevin_> if ConnectionInfo is used then that specifies a specific
Datasource over a database
[16:35] <kevin_> not sure if I answered your question
[16:35] <Amita> but credentials etc? id/pwd
[16:36] <kevin_> that is taken care of before we get the connection
[16:36] <kevin_> unless i have missed something
[16:36] <Amita> what I want to ask...
[16:36] <Amita> if Test Framework does not exist
[16:37] <kevin_> if the client is providing the Connection then id/psswd has
been done
[16:37] <Amita> and I want connection to DB2 using xml config of DAS only
[16:37] <Amita> how will I do it?
[16:37] <kevin_> the CompanyWeb sample demos this
1[16:37] <lresende> but needs to be in a j2ee environment
1[16:37] <lresende> right ?
[16:37] <Amita> thats my question
1[16:37] <lresende> otherwise you have to pass the connection
[16:38] <kevin_> The xml config specifies a DataSource
[16:38] <kevin_> yes. as far as i know , DataSource is not available in J2SE
1[16:38] <lresende> so, back to my first comment, we might need to have
something on the SCDL level, that would work on both cases
[16:39] <kevin_> at one point, we considered allowing DriverManager info in
the config
[16:39] <Amita> ok
1[16:39] <lresende> and we would create a connection if J2SE
[16:39] <Amita> so not xml nbut scdl will need to serve this info
[16:39] <Amita> got it
1[16:39] <lresende> as one idea / options
[16:39] <kevin_> i have not thoought through that but it makes sense
2[16:40] * skurz_ has quit IRC ("Chatzilla 0.9.75 [Firefox
1.5.0.7/2006090918]")
1[16:40] <lresende> that would help when you want to deploy the service in
different language too
1[16:40] <lresende> as what we define in SCDL wounldn't be java specific
(eg DataSource)
[16:40] <kevin_> is that your concern ... that it miust be deployable to
J2SE and a managed environment without modification?
1[16:41] <lresende> or in c++, php ... yes
[16:41] <Amita> yes
[16:41] <kevin_> ok
[16:42] <Amita> also, another thing for Update support in DAS
1[16:43] <lresende> back to my previous question... any best practices for
Amita and I collaborate ? if I was a commiter, I'd have said... use
sandbox.. but i don't have apache acount yet...
[16:43] <Amita> if we look at the guide or WIKI etc
[16:43] <Amita> the client needs to first have a root and the do set()...etc
[16:43] <Amita> so if the DAS config has a command..
[16:43] <Amita> update x set y = z where ...
[16:44] <Amita> is there a chance that DAS will serve this like insert etc?
[16:44] <Amita> that is take care of getting DataObject and do set
internally
[16:44] <Amita> what is there in DAS today is
[16:44] <Amita> Update - using SDO
[16:44] <kevin_> i think i don't understand the question yet
[16:44] <Amita> and other methods using Command
[16:45] <kevin_> DAS.applyChanges(root)
[16:45] <Amita> so a diff way to support select/delete/insert
[16:45] <Amita> so only for Update DAS wants SDO
[16:45] <kevin_> processes the change history and ..
[16:45] <Amita> yes
[16:45] <kevin_> generates INSERT/UPDATE/DELETE statements
1[16:46] <lresende> so, this is preferend way... but we also support the
"other" way.. right kevin...
[16:46] <kevin_> yes
1[16:46] <lresende> just to make it clear for Amitsa
1[16:46] <lresende> Amita
[16:46] <Amita> ok, so it supports Command too? for Update?
1[16:46] <lresende> y
[16:47] <Amita> got it
[16:47] <Amita> thank you
1[16:47] <lresende> there is an exmple in BigBank i think... if not in the
test framework
[16:47] <kevin_> yeah, boith places ...
[16:47] <Amita> and for the container - we need to support both ways ?
[16:47] <kevin_> Amita ...
[16:47] <kevin_> that would be best
[16:48] <kevin_> i would start with the "preferred" way
[16:48] <kevin_> i have been working on some user level documentation here
...
[16:48] <kevin_>
http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview/RDBDAS_Java_User_Guide
[16:48] <kevin_> not sure if you have seen it
[16:48] <Amita> yes
[16:48] <kevin_> ok\
1[16:49] <lresende> anyone: can we build incremental patches over patches ?
[16:49] <kevin_> regarding collaboration ...
1[16:50] <lresende> yes.. what's the best way ?
1[16:50] <lresende> i don't expect having a apache account anytime soon
(before 2 weeks i think)
[16:50] <kevin_> i think we should commit the container and develop it in
the trucnk
[16:50] <kevin_> as long as it never breaks the build
1[16:50] <lresende> we should consult SCA team, first
[16:51] <kevin_> I am happy to apply both of your patches as we develop of a
commo nbase
1[16:51] <lresende> as it would reside in their "land"
[16:51] <kevin_> off of
1[16:51] <lresende> k
[16:51] <kevin_> yeah, when we are ready we need to ask where it should go
1[16:51] <lresende> ok, i can initiate the discussion on that
[16:51] <kevin_> ant , are you still here?
[16:52] <Amita> can we discuss some work items for next steps?
[16:52] <kevin_> sure
1[16:52] <lresende> Amita... we also should refactor and cleanup what you
have in your jar
[16:52] <Amita> will help me in getting some direction
[16:52] <Amita> yes
1[16:52] <lresende> so, 1st goal should be to have a basica container and a
client app
1[16:52] <lresende> 1st - refactor clean up
1[16:53] <lresende> 2nd - create a client app (today is all together)
[16:53] <kevin_> and , perhaps, executing the basic test i suggeted
3[16:53] * cr22rc is now known as cr22rc_away
1[16:53] <lresende> k
1[16:53] <lresende> and we could have that in a J2EE env, so we could use
connectionInfo on the config xml for now
1[16:53] <lresende> once we have that...
1[16:54] <lresende> then we can start talking about adding capabilities...
right ?
1[16:54] <lresende> what you guys think ?
[16:54] <Amita> yes, will do that
[16:54] <kevin_> regarding J2EER, either way seems fine
[16:54] <kevin_> sounds good to me.
[16:54] <kevin_> i am very excited about this
1[16:54] <lresende> and Amita and I can discuss breaking up tasks
offline... is that ok ?
1[16:55] <lresende> yes.. it's good progress
[16:56] <kevin_> anything else?
1[16:56] <lresende> not from me...
1[16:56] <lresende> btw, i'll post the chat over the mailing list when we
are done
[16:56] <kevin_> great
1[16:56] <lresende> Amita: anything else ?
[16:56] <Amita> will ask any further questions in ML
1[16:57] <lresende> thanks
[16:57] <Amita> nothing as of now
[16:57] <Amita> this helped a lot
1[16:57] <lresende> thanks for your help as well
[16:57] <Amita> thanks both of you
[16:57] <kevin_> ok... then Luciano and I can get dinner and Amita can have
breakfast :-)
1[16:57] <lresende> :)
[16:57] <Amita> :), so we stop here?
[16:57] <kevin_> bye
1[16:57] <lresende> bye
[16:57] <Amita> bye, GN
3[16:58] * kevin_ has left #TUSCANY
