Hi, One observation while doing work on - "Changes in DAS for using new SDO APIs". DAS uses tuscany-sdo-plugin for generating static classes for config.xsd and some other example exds. It shows that - the generated code has used deprecated method FactoryBase.getProperty(Type,int) and needs to be replaced by getLocalProperty(). Any fix needed in the sdo-plugin? Any suggestions?
Regards, Amita On 8/30/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > Hi Amita, > I'm not aware of anyone planning to fix 761. There were a couple of > possible approaches, either or both of which could be developed. Ron > Gavlin painted a scenario in the JIRA where dropping of individual > types from a namespace would be the right thing to do. > > There's also discussion of dropping whole HelperContexts, which > raises again the question of how we might establish dependencies > between HelperContexts. This could be a useful discussion to open up > and get a design in place for. > > As to your scenario of changing a type, it would be good to check > through the scenarios you envisage. The current Tuscany API > implementations permit alteration of Types after they have been used, > whereas the SDO API implementations freeze the types at creation time. > Depending on which scenarios we support the user would have to take > care to ensure certain preconditions before calling a method such as > createOrReplaceType(). My guess is that this method would end up as a > simple convenience method, involving calls to the type dropping and > creation methods. > > Here are some attributes of scenarios that we might want to consider > in order to see which combinations we support/exclude. Note, exclusion > doesn't necessarily imply enforcement by the SDO implementation and > this kind of area clearly contains hazards > > - a Type is removed from a scope (HelperContext) when no DataObjects > reference it > - a Type is removed from a scope while still referenced by DataObjects > - a Type is replaced in a scope while DataObjects still reference the > displaced Type instance > - a Type is replaced in a scope only when no DataObjects reference the > displaced Type instance > - Properties are added to a Type after instances of the Type have been > created > - an instance of a Type is otherwise updated when still referenced by > DataObjects (expand ...) > - multiple instances of HelperContexts are used to manage multiple > instances of Types with the same name and in the same namespace > > Kelvin. > > > On 30/08/2007, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > What is the plan for JIRA-761(Support the ability to unregister all the > SDO > > Types in a namespace) > > > > Also, I am just trying to understand that in a condition where some Type > is > > defined in > > using SDOUtil.createType() and later some attributes of it need to > change > > during > > the same runtime invocation. So user needs SDOUtil.createOrReplaceType() > - > > how this can be done? > > > > Regards, > > Amita > > > > On 8/29/07, Fuhwei Lwo <[EMAIL PROTECTED]> wrote: > > > > > > Hi Kelvin, > > > > > > Based on my observation on opened JIRAs, I agree we definitely should > pay > > > attention to the first two items you listed below - test generated > static > > > SDO APIs and multi-threaded scenario more easily. > > > > > > I did some investigation on GroboUtils for multi-thread testing and > still > > > couldn't find any remote repository hosting the tool so we may need to > host > > > the tool ourselves or find an alternative. What do you think? > > > > > > Fuhwei > > > > > > kelvin goodson <[EMAIL PROTECTED]> wrote: Having released > > > 1.0-incubating, what are the priorities for SDO Java now. > > > > > > I'm just catching up on reading the lists having taken a break. The > > > major things I had in mind before going away were to > > > > > > - rearrange the project structure to permit generation of java classes > > > during maven tests (TUSCANY-1393) > > > > > > - add multi-threaded test cases (TUSCANY-1182) > > > > > > - for the first of the above, while we are in project reorganisation > > > mode it's probably worth fixing TUSCANY-257 to separate out the Java 5 > > > dependencies > > > > > > - It would be great to get some improvement our web pages; and getting > > > some good user documentation together would be really helpful. > > > > > > My brain hasn't completely returned from vacation, so I've probably > > > missed out some obvious things, so please chip in with your opinions, > > > needs and inspirational ideas! > > > > > > Kelvin. > > > > > > --------------------------------------------------------------------- > > > 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] > >
