Raymond, I agree with your suggestion below. In addition, I think SCA still needs to provide an option (injection or API) for the applications to explicitly retrieve the data model scope from the Contribution. Other databinding technology APIs beside SDO may not have default context helper concept.
1) SDO defines the pluggability to supply the default HelperContext. 2) SCA plugs its own scoping scheme to the SDO default HelperContext. The HelperContext will be populated based on the Contribution. 3) Application code will use HelperProvider.getDefaultContext() to retrieve the default HelperContext. Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Please see my comments inline. Thanks, Raymond ----- Original Message ----- From: "Jean-Sebastien Delfino" To: Sent: Friday, April 20, 2007 9:23 AM Subject: Re: Scoping SDO metadata, was: How to access a composite's data model scope in an application? > Fuhwei Lwo wrote: >> Hi Sebastien, >> >> Here is my understanding of requirements about getting rid of import.sdo >> and switching to contribution - >> >> 1) A contribution will be created by contribution processor for each >> application. - Contribution processor has been done for Jar and file >> system. >> >> > > Yes > >> 2) The contribution processor will create a SDO scope (HelperContext >> instance) to associate with the contribution. Currently calling >> SDOUtil.createHelperContext() is enough. >> > > That's what I was poking at in my previous email. Creating our own > context, different from the default SDO context forces SCA to introduce a > new API to get to that context, and forces all SDO users to use that new > API. So I'm wondering if it wouldn't be better to play more nicely with > SDO, and have the SCA runtime just populate the default SDO context in use > in a particular application in the server environment. > I have a slightly different view here. IMHO, the SDO should provide the scoping mechanism and the pluggability of scoping schemes. I assume the HelperContext is provided by SDO for scoping metadata. What's missing from SDO is the pluggability of the scoping schemes. Currently, the default HelperContext is based on TCCL and it's not replaceable. I agree SDO cannot define scoping schemes for all environment so the pluggability is desirable. >> 3) Tuscany SCA needs to provide a way for the application to get hold of >> the HelperContext in association with the contribution in step 2 above. >> Currently the application is forced to use SDO API - >> HelperProvider.getDefaultContext() which is using TCCL. >> > > I'm not getting this one :) Is it bad for an SDO user to be "forced to" > use an SDO API to get an SDO context? It seems better to me than forcing > an SDO user to use an SCA API, simply because his code may be used at some > point in an SCA environment... and then his code wouldn't work in a JSP, a > servlet, or any other non-SCA environment... > > If the fact that HelperProvider.getDefaultContext() is using the TCCL to > find the correct SDO context is a problem, then we just need to fix that. > We went through the same discussion with SCA CompositeContext about a year > ago. Associating context with the TCCL is not always convenient in a > server environment, and it may be better to associate context with the > current Thread (using a threadlocal or an inheritable thread local for > example). This is what we did for SCA CompositeContext. Maybe SDO could > provide a way to associate an SDO context with the current thread instead > or in addition to associating the SDO context with the TCCL? I agree that we should try to use the SDO API to retrieve the current context. But I think in the SCA application, the default context should be associated with the Contribution. Then it would be a win-win situation if we can do the following: 1) SDO defines the pluggability to supply the default HelperContext. 2) SCA plugs its own scoping scheme to the SDO default HelperContext. The HelperContext will be populated based on the Contribution. 3) Application code will use HelperProvider.getDefaultContext() to retrieve the default HelperContext. > > This would seem a good thing to have anyway since these contexts are not > thread safe as far as I know :) > > Thoughts? >> I am not sure my understanding above is correct so please bear with me. >> Based on my understanding above, currently there is no additional >> requirement from SDO. > > I wouldn't reach that conclusion so fast :) I think that there is a > requirement to provide a way to get to an SDO context independent of TCCL > if people don't like that association with TCCL. > >> In the future, if we decided to support contribution import/export that >> may require SDO scoping hierarchy support. But I think we should start >> using contribution and getting rid of import.sdo as the first step. >> >> > > Yes I'd like to get rid of import.sdo, as I indicated earlier in this > discussion thread. > > I would like to support contribution import/export at some point. I'm not > sure that we'll be able to use SDO scope hierarchy support as an SCA > contribution import does not necessarily import the whole scope of another > SCA contribution, but I guess we'll know more when we start to look at the > details. I'm thinking of the following approach to discover SDO metadata from a SCA contribution. When the Contribution is processed, the generated SDO factories (the class name and the namespace) are recognized. Other models such as WSDL/XSD are handled as well. We don't have to convert all of them into SDO model upfront as the conversion can be performed on-demand upon the query of a particular namespace. > >> What do you think? Thanks for your reply. >> >> Fuhwei Lwo >> >> Jean-Sebastien Delfino wrote: Fuhwei Lwo wrote: >> >>> Hi, >>> >>> In my composite, I defined in the default.scdl file that would prompt >>> the SCA container to register my data types using SDO databinding. The >>> question I have is what API I should use in my service implementation >>> code to obtain the registered data types. If I have two composites that >>> are using two different data type definition but with the same namespace >>> URI, I definitely don't want to obtain the wrong data type definition. >>> Thanks for your help. >>> >>> Below is the previous message from Raymond Feng about associating >>> databinding type system context/scope with a composite. I think this is >>> related to my question but from Tuscany SCA development perspective. >>> >>> How to associate some context with a composite? >>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200702.mbox/[EMAIL >>> PROTECTED] >>> >> >> Hi, >> >> The short (and not perfect) answer to your question is. With the current >> code in trunk, use: >> commonj.sdo.impl.HelperProvider.getDefaultContext() >> >> But I thought about this a bit and your question triggered some comments, >> and more questions :) >> >> Import.sdo extension: >> I think we should be able to remove that Tuscany extension to SCA >> assembly XML, now that we have the SCA contribution service in place. We >> know which WSDLs and XSDs are available in a given SCA contribution and, >> with sca-contribution.xml import elements, we also know which XML >> namespaces are imported from other SCA contributions or other locations >> outside of an SCA domain. So we probably don't need another element >> duplicating part of this information in .composite files. >> >> Scope of XML metadata: >> My understanding of the SCA assembly spec is that the scope of XML >> metadata is an SCA contribution (plus what it imports from outside) and >> not an individual Composite. >> >> Scope of metadata contributed by Java classes: >> Our runtime currently supports SCA contributions packaged as JARs or file >> system folders. With these packaging schemes an SCA contribution is self >> contained and cannot reference application classes in other SCA >> contributions. At some point we'll probably want to support packaging of >> SCA contributions as OSGI bundles and then leverage OSGI to allow an OSGI >> bundle to see classes in another bundle, but we don't support that OSGI >> packaging scheme yet. As a side comment I'd like to see if we could >> reactivate some work on the OSGI extensions that we have under >> java/sca/contrib/ and are not integrated in our build at the moment. So, >> the scope of Java metadata is an SCA contribution as well, with no >> external import mechanism. >> >> So the bottom line is: >> References to types in SCA artifacts are resolved at the SCA contribution >> level. There is no relationship between an SCA composite and a metadata >> scope. >> >> More comments, on databinding specific handling of metadata: >> We need to support multiple databindings. Each databinding comes with its >> own form of metadata and different APIs to get to that metadata and >> define metadata scopes. I guess it's important for a databinding >> technology to define a way to scope metadata if it wants to be >> successfully used in a server environment, and isolate the metadata for >> the different applications running on the server. >> >> In such an environment, our SCA runtime should play nicely with the other >> pieces of runtime and application code (not necessarily running as SCA >> components), and use the metadata scoping mechanism defined by each >> databinding in such a way that non-SCA code and SCA component code >> running together in the server environment are able to see the same >> metadata for a given application. >> >> I'd like to start a discussion to cover this aspect for our various >> databindings and make sure that the metadata story for each databinding >> holds together. >> >> To help feed this discussion with concrete data, could the SDO folks jump >> in here, and describe the various ways of maintaining SDO metadata scopes >> in a server environment, running with multiple classloaders and threads? >> >> Thanks, >> >> > > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
