Re: Policy Attachments Resolution in the Assembly Model
Not sure I understand this. I guess its to do with the ExtensibleURLArtifactProcessor that strips off the extension and searches for processors only by those extensions. So even if the URLArtifactProcessor.getArtifactType() returned 'definitions.xml' we'd still have a problem. I guess we have to designate some files as configuration files that have specific designated processors. When the contribution service picks up these files it must invoke the corresponding artifact processors and in all other cases - for application artifacts it could go by what its going currently. Makes sense ? - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Venkata Krishnan wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks Here's a simple change to make this cleaner: Instead of URLArtifactProcessor.getType() returning .composite for *.composite files definition.xml for definition.xml files URLArtifactProcessor.getType() could return *.composite for *.composites files definitions.xml for definition.xml Thoughts? -- 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]
Re: Policy Attachments Resolution in the Assembly Model
Cool, if you can wait a day, i can take a look at that... Sebastien suggestion seems ok: Instead of URLArtifactProcessor.getType() returning .composite for *.composite files definition.xml for definition.xml files URLArtifactProcessor.getType() could return *.composite for *.composites files definitions.xml for definition.xml But I guess we also need to change the logic on the algorithm that checks for the right processor to be used, as it's now just checking the file extension. On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes Luciano, that's what I am suggesting. - Venkat On 8/8/07, Luciano Resende [EMAIL PROTECTED] wrote: Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Not sure i got this right, but are you asking for the ability to register artifactProcessors by fileName as well as extension ? On 8/8/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi, Now that I have the basic policy model in place I am trying to link up this with the assembly model now. The policy intents and policy sets applicable for a domain are defined in the definitions.xml. There is a SCADefinitions processor that deals with reading and resolving the intents and policysets in the definitions.xml. The SCADefinitions processor has a model resolver into which the the various policy intents and policy sets that are read get added. All of this is a part of the policy-xml module. Now looking into the aspect of dealing with the 'attachments' of policy intents and policy sets into various SCA constructs, I see there is a need to resolve the intents and policysets with those that have been read from the definitions.xml. This means an artifact processor such as the CompositeProcessor needs to be passed a resolver that has the various policy intents and policy sets in it. Now the question is, do we assume that we use the same resolver that is used to add up the read sca contructs is used to also add the policy intents and policysets ? or... Going by the discussion in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19069.html, I am given to understand that its best to keep all of the things related to policies - the processor, the resolver etc. separate from those that we have for the assembly model. If this is the case then the CompositeProcessor, the ConstrainingType Processor etc. all have to be set with the instance of a SCADefinitionsResolver that will be used to resolve to policy related things. Could somebody please help me with some perspectives on which one of the above two is better to follow? Thanks - Venkat I think we can follow the same pattern as implementations, bindings, etc: - In CompositeProcessor.resolve(model, resolver), call resolver.resolveModel(policyToResolve) to resolve an unresolved policy model object, then attach the resolved policy to the composite. - In your policy-xml module, provide a PolicyModelResolver and register it in the ModelResolverExtensionPoint. PolicyModelResolver will handle the resolution of Policy model objects (by qname I guess). Look for CompositeModelResolver for an example of a ModelResolver. -- 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] --
[jira] Assigned: (TUSCANY-1518) Insufficient error message, Pass-by-value not allowed on this object
[ https://issues.apache.org/jira/browse/TUSCANY-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatakrishnan reassigned TUSCANY-1518: Assignee: Venkatakrishnan Insufficient error message, Pass-by-value not allowed on this object --- Key: TUSCANY-1518 URL: https://issues.apache.org/jira/browse/TUSCANY-1518 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Reporter: Rashmi Hunt Assignee: Venkatakrishnan Insufficient error message by Tuscany, Pass-by-value not allowed on this object On a remotable service interface, if user makes a mistake of passing a java type as parameter which is not serializable, Tuscany throws an exception Pass-by-value not allowed on this object. This message is insufficient since user will not be able to understand that the real issue is parameter is not a serilizable type. Better message could be Paramater xxx is not serializable. Pass-by-value not allowed on this object This exception is thrown from org.apache.tuscany.sca.databinding.javabeans.JavaBeansDataBinding.copy() method , line number 78 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1496) Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side
[ https://issues.apache.org/jira/browse/TUSCANY-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518623 ] Raymond Feng commented on TUSCANY-1496: --- Patch applied under r564107. Thank you, Simon. Simplify the callback handling in the core by treating the callback as a special service on the reference side and a special reference on the service side -- Key: TUSCANY-1496 URL: https://issues.apache.org/jira/browse/TUSCANY-1496 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Attachments: patch1 Please see the ML thread @ http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20555.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1518) Insufficient error message, Pass-by-value not allowed on this object
[ https://issues.apache.org/jira/browse/TUSCANY-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatakrishnan resolved TUSCANY-1518. -- Resolution: Fixed The exception message will now include the the class name of the argument that is not Serializable. Fixed in r564108. Insufficient error message, Pass-by-value not allowed on this object --- Key: TUSCANY-1518 URL: https://issues.apache.org/jira/browse/TUSCANY-1518 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Reporter: Rashmi Hunt Assignee: Venkatakrishnan Insufficient error message by Tuscany, Pass-by-value not allowed on this object On a remotable service interface, if user makes a mistake of passing a java type as parameter which is not serializable, Tuscany throws an exception Pass-by-value not allowed on this object. This message is insufficient since user will not be able to understand that the real issue is parameter is not a serilizable type. Better message could be Paramater xxx is not serializable. Pass-by-value not allowed on this object This exception is thrown from org.apache.tuscany.sca.databinding.javabeans.JavaBeansDataBinding.copy() method , line number 78 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy Attachments Resolution in the Assembly Model
Venkata Krishnan wrote: Not sure I understand this. I guess its to do with the ExtensibleURLArtifactProcessor that strips off the extension and searches for processors only by those extensions. So even if the URLArtifactProcessor.getArtifactType() returned 'definitions.xml' we'd still have a problem. I guess we have to designate some files as configuration files that have specific designated processors. When the contribution service picks up these files it must invoke the corresponding artifact processors and in all other cases - for application artifacts it could go by what its going currently. Makes sense ? - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Venkata Krishnan wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks Here's a simple change to make this cleaner: Instead of URLArtifactProcessor.getType() returning .composite for *.composite files definition.xml for definition.xml files URLArtifactProcessor.getType() could return *.composite for *.composites files definitions.xml for definition.xml Thoughts? -- Jean-Sebastien I didn't say that this didn't require any changes in any classes. I'm just proposing a change to how URLArtifactProcessors indicate what they support: *.foo for all files with extension .foo foo.bar for file foo.bar Then, yeah sure, some classes will have to change to accomodate this new way of declaring URLArtifactProcessors. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1 more new component instance per request?
On 8/9/07, shaoguang geng [EMAIL PROTECTED] wrote: Today, I found in respond to each request, Tuscany instantiate new one class for each. I tried binding.ws, it works as well. SCA1.0 does not specify instance management of a component, but I remember J2EE does not mentioned such things for EJB and servlet, it should be managed by the containers. So here comes my question: is it a good idea to make a great deal of component instances in Tuscany, or we might control it to act as singleton? - Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. Hi Shaoguang SCA defines a concept of scope for a component, for example, if you take a look at the Java Annotations and APIs spec you will see an annotation @SCOPE defined which takes the values, STATELESS REQUEST CONVERSATION COMPOSITE This gives you some fairly coarse grained control over how the runtime will manage instances of Java components. For example, if you mark your Java implementation as having @SCOPE(COMPOSITE) you should see that only one instance is created within the composite. Hope that helps Simon
Re: Policy Attachments Resolution in the Assembly Model
:) thanks. That makes sense to me. - Venkat On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Not sure I understand this. I guess its to do with the ExtensibleURLArtifactProcessor that strips off the extension and searches for processors only by those extensions. So even if the URLArtifactProcessor.getArtifactType() returned 'definitions.xml' we'd still have a problem. I guess we have to designate some files as configuration files that have specific designated processors. When the contribution service picks up these files it must invoke the corresponding artifact processors and in all other cases - for application artifacts it could go by what its going currently. Makes sense ? - Venkat On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Venkata Krishnan wrote: Hi Sebastien, thanks. I've figured out all of this already :) Just the one hanging thing - the definitions.xml is an artifact that might have to be picked up by the contribution service. While processors for all other documents could be found by their unique extensions such as .composte or .constrainingType its a bit of a trouble with definitions.xml, the extension .xml being generic. Could we extend the logic in ExtensibleURLArtifactProcessor.read to first look at extensions and if not found try with the name of the file ? So the principle is - search for processors either by extensions or by the file name for specific kind of documents. I sort of feel a bit clumsy about this approach - whats an alternative that could be cleaner ? Thanks Here's a simple change to make this cleaner: Instead of URLArtifactProcessor.getType() returning .composite for *.composite files definition.xml for definition.xml files URLArtifactProcessor.getType() could return *.composite for *.composites files definitions.xml for definition.xml Thoughts? -- Jean-Sebastien I didn't say that this didn't require any changes in any classes. I'm just proposing a change to how URLArtifactProcessors indicate what they support: *.foo for all files with extension .foo foo.bar for file foo.bar Then, yeah sure, some classes will have to change to accomodate this new way of declaring URLArtifactProcessors. -- 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]
Re: Cross-jvm locate service
On 8/8/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Kevin Williams wrote: I am interested in extending the current locate service capability to support the location of services that may be running within the same domain but a separate jvm. The most straightforward approach may be to dynamically create and return a service reference using the same Tuscany runtime elements that now create service references for injection in support of the @reference annotation. Any thoughts or pointers would be appreciated. Thanks, --Kevin This sounds good to me. I guess you're talking about SCADomain.getService(targetComponentName/targetServiceName). We've been flip-flopping between locateService/getService a few times :) ... Here are a few more thoughts. First here's how SCADomain.getService() currently works: 1. look for the target component model object in the in-memory domain composite kept in SCADomain 2. look for the target service on that component 3. find on that component the self-reference created for that service (these self-references are automatically created by CompositeBuilder for each service provided by a component) 4. create a CallableReference for that self-reference 5. get a proxy to the service from the CallableReference Some pointers to code: [1] and [2] - org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getServiceReference () [3] and [4] - org.apache.tuscany.sca.core.component.ComponentContextImpl.createSelfReference () [5] - org.apache.tuscany.sca.core.component.CallableReferenceImpl Now, when the target component/service runs in a different JVM, you won't have an in-memory model object representing it :( but that's not a big issue :) ... As you suggested you can simply create a local reference and bind it to the target service (assuming you know its binding type and endpoint URI), then proceed to get a CallableReference and a proxy for it as usual. This gives us the following steps: 1. determine the binding type and endpoint URI of the target component/service you're looking for (I won't get into the details of how to do that here, as I think Simon is covering it in his distributed binding implementation) 2. dynamically create a reference for your target service and configure it with that binding and endpoint URI 3. perform steps [4] and [5] from above. For step 2, org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.createSelfReference () shows how to create a reference from a service. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Kevin This seems to fit with the distributed work. I hadn't considered opening this up to DefaultSCADomain.getServiceReference() but I don't see why that shouldn't be done. Let me just ask a few questions to make sure I'm clear about what you are after. location of services that may be running within the same domain but a separate jvm How are you intending to refer to the service that is running in a separate JVM. Currently getServiceReference() expects a service name so we can rely on the implication that all contributed composites are notionally included into the domain level composite to reference a component and extend Sebastien's process to say. 1. look for the target component model object in the in-memory domain composite kept in SCADomain if found 2. look for the target service on that component 3. find on that component the self-reference created for that service (these self-references are automatically created by CompositeBuilder for each service provided by a component) 4. create a CallableReference for that self-reference 5. get a proxy to the service from the CallableReference else 2. look for the named component/serivce in other nodes of the distributed (cross JVM) domain I am working up some interfaces to allow this to happen in the distributed domain case, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java Not implemented just yet as I'm currently looking at the sca domain implementation but you get the idea. The implementation could use some simple repository implementation or could derive the information from file. 3. Create a local reference for the remote service Not sure of the details here but you both seem happy that this is straightforward. The thing that does look problematic is determining the binding. In the distributed case I assume that all cross JVM messaging are handled by the sca binding. Are you expecting that you can do a getService for a non-wired service, i.e. a service with an explicit remote binding such as binding.ws, that is running in another VM. If so that we will need, as Sebastien suggests, to be able
Re: Release management for next release, was: SCA 0.92 release?
Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: Raymond Feng wrote: [snip] 2) We could branch for the 1.0 release to contain the candidate modules and keep doing 1.0 developement in the branch and merge them into the trunk. I'm not sure how feasible it is. +1 I think it's feasible if doing 1.0 development is about stabilizing the 1.0 release branch, which I guess a release branch is for :) That means: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. How soon would we be moving into this mode? I presume it would be after we have released 1.0-beta. Does anyone think it would be sooner than that? Simon I'm probably missing something in your question :). What I'm describing here is in response to Raymond's question about doing 1.0 development in the branch. The branch in question is the 1.0-beta release branch, used to release 1.0-beta, i.e. *before* it is released. Sorry about the misunderstanding. I was thinking about 1.0 as being the release that came after 1.0-beta or whatever we decide to call it. So while 1.0-beta is being stabilized in the branch, I would expect development of function targeted at 1.0 (1.0 development) to be happening in the trunk. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: Raymond Feng wrote: [snip] 2) We could branch for the 1.0 release to contain the candidate modules and keep doing 1.0 developement in the branch and merge them into the trunk. I'm not sure how feasible it is. +1 I think it's feasible if doing 1.0 development is about stabilizing the 1.0 release branch, which I guess a release branch is for :) That means: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. How soon would we be moving into this mode? I presume it would be after we have released 1.0-beta. Does anyone think it would be sooner than that? Simon I'm probably missing something in your question :). What I'm describing here is in response to Raymond's question about doing 1.0 development in the branch. The branch in question is the 1.0-beta release branch, used to release 1.0-beta, i.e. *before* it is released. Sorry about the misunderstanding. I was thinking about 1.0 as being the release that came after 1.0-beta or whatever we decide to call it. So while 1.0-beta is being stabilized in the branch, I would expect development of function targeted at 1.0 (1.0 development) to be happening in the trunk. Simon I guess thats what I'd expect as well. If we had committers keen to continue developing post-1.0 function in trunk while we released 0.95 and 1.0 from the one branch that would be a good approach, but we don't have that so i think it will be easier to continue with the trunk for 1.0. That would save a lot of merging and it will keep the 0.95 branch more stable which should make it easier to get a 0.95 release out. ...ant
[jira] Commented: (TUSCANY-1465) Allow passing ResultDescriptor for dynamic Commands
[ https://issues.apache.org/jira/browse/TUSCANY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518654 ] Adriano Crestani commented on TUSCANY-1465: --- - On ReadCommandImpl.setResultDescriptor(List) you are storing the list directly, however I think the list should be copied(also the elements), because the way it is the user can modify the Command's ResultDescriptor List or the ResultDescriptor itself anywhere else on users'code without notify the Command. - The ResultDescriptorSorter.sortList(List) is returning 3 different ways: 1. When the List parameter is null, the method returns null. I think it's ok 2. When the List is empty, the method returns the same List object 3. Otherwise, it's returning a new List object containing the ResultDescriptors sorted by the index I think on 2 the List returned should be a new empty List and not the parameter List. OR the 3 could return the same List but with the objects sorted. I think it's important to define the method logic, if it will always return the same List passed on parameter or return a new List. - Why ResultDescriptor cannot be made Comparable? - Is there any reason not to name the method List Command.set/getResultDescriptor to set/getResultDescriptors? Because it returns a List of ResultDescriptors, and not a single one. Maybe we could use some pattern here, as addResultDescriptor(ResultDescriptor), removeResultDescriptor(ResultDescriptor), and getResultDescriptor(int). - Why the ResultDescriptor Lists paremeters and returns cannot be defined as ListResultDescriptor? I applied the patch on my trunk and it passed on all mvn tests, I think it`s ok. I just want to know your thougths about my questions above : ) Regards, Adriano Crestani Allow passing ResultDescriptor for dynamic Commands --- Key: TUSCANY-1465 URL: https://issues.apache.org/jira/browse/TUSCANY-1465 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1465.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19886.html Action for the issue discussed in above mail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New dependencies on binding-sca? was: svn commit: r563787 - in /incubator/tuscany/java/sca/modules: binding-ejb/pom.xml core-spring/pom.xml host-embedded/pom.xml
The binding-ejb one was a mistake host-embedded/ReallySmallRuntimeBuilder creates a SCABindingProcessor I'll go fix the first one and test against the latest code Thanks Simon On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm not sure what required these dependency changes: - binding-ejb now depending on host-embedded? - host-embedded now depending on binding-sca-xml? Could you please help me understand? Thanks. [EMAIL PROTECTED] wrote: Author: slaws Date: Wed Aug 8 01:29:54 2007 New Revision: 563787 URL: http://svn.apache.org/viewvc?view=revrev=563787 Log: TUSCANY-1512 Correct some binding-sca dependencies that I missed on the last checkin Modified: incubator/tuscany/java/sca/modules/binding-ejb/pom.xml incubator/tuscany/java/sca/modules/core-spring/pom.xml incubator/tuscany/java/sca/modules/host-embedded/pom.xml Modified: incubator/tuscany/java/sca/modules/binding-ejb/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/binding-ejb/pom.xml?view=diffrev=563787r1=563786r2=563787 == --- incubator/tuscany/java/sca/modules/binding-ejb/pom.xml (original) +++ incubator/tuscany/java/sca/modules/binding-ejb/pom.xml Wed Aug 8 01:29:54 2007 @@ -38,6 +38,12 @@ artifactIdtuscany-extension-helper/artifactId version1.0-incubating-SNAPSHOT/version /dependency + +dependency +groupIdorg.apache.tuscany.sca/groupId +artifactIdtuscany-host-embedded/artifactId +version1.0-incubating-SNAPSHOT/version +/dependency dependency groupIdorg.apache.geronimo.specs/groupId Modified: incubator/tuscany/java/sca/modules/core-spring/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/core-spring/pom.xml?view=diffrev=563787r1=563786r2=563787 == --- incubator/tuscany/java/sca/modules/core-spring/pom.xml (original) +++ incubator/tuscany/java/sca/modules/core-spring/pom.xml Wed Aug 8 01:29:54 2007 @@ -100,8 +100,8 @@ groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-sca/artifactId version1.0-incubating-SNAPSHOT/version -scopetest/scope -/dependency +/dependency + /dependencies /project Modified: incubator/tuscany/java/sca/modules/host-embedded/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-embedded/pom.xml?view=diffrev=563787r1=563786r2=563787 == --- incubator/tuscany/java/sca/modules/host-embedded/pom.xml (original) +++ incubator/tuscany/java/sca/modules/host-embedded/pom.xml Wed Aug 8 01:29:54 2007 @@ -45,14 +45,12 @@ groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-sca/artifactId version1.0-incubating-SNAPSHOT/version -scoperuntime/scope /dependency dependency groupIdorg.apache.tuscany.sca/groupId artifactIdtuscany-binding-sca-xml/artifactId version1.0-incubating-SNAPSHOT/version -scoperuntime/scope /dependency dependency - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
ant elder wrote: On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: Raymond Feng wrote: [snip] 2) We could branch for the 1.0 release to contain the candidate modules and keep doing 1.0 developement in the branch and merge them into the trunk. I'm not sure how feasible it is. +1 I think it's feasible if doing 1.0 development is about stabilizing the 1.0 release branch, which I guess a release branch is for :) That means: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. How soon would we be moving into this mode? I presume it would be after we have released 1.0-beta. Does anyone think it would be sooner than that? Simon I'm probably missing something in your question :). What I'm describing here is in response to Raymond's question about doing 1.0 development in the branch. The branch in question is the 1.0-beta release branch, used to release 1.0-beta, i.e. *before* it is released. Sorry about the misunderstanding. I was thinking about 1.0 as being the release that came after 1.0-beta or whatever we decide to call it. So while 1.0-beta is being stabilized in the branch, I would expect development of function targeted at 1.0 (1.0 development) to be happening in the trunk. Simon I guess thats what I'd expect as well. If we had committers keen to continue developing post-1.0 function in trunk while we released 0.95 and 1.0 from the one branch that would be a good approach, but we don't have that so i think it will be easier to continue with the trunk for 1.0. That would save a lot of merging and it will keep the 0.95 branch more stable which should make it easier to get a 0.95 release out. ...ant Sure, 1.0 development should happen in trunk, but I was trying to respond to a different point brought up by Raymond. On Aug 18, we are going to cut the August release branch. The point is about allowing small changes, bug fixes and improvements to continue in that branch while we are putting the release distros together, with the following conditions: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Column Converter - why not to associate with ResultDescriptor?
Nice idea, I have no objections about your propose. But, I think we need some more opnions from those who helped to implement Java DAS, mainly the ColumnConverters. Regards, Adriano Crestani On 8/7/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: With JIRA-1465, ResultDescriptor can be set dynamically for DAS Commands which are created with DAS.createCommand(). Further on this, will it be helpful to associate ColumnConverter with ResultDescriptor? So, when there is no Config File, user will have a choice to use ColumnConveter on-the-fly /Command basic from inside the dynamic ResultDescriptor. The scope of this converter will be per Command. Whereas, the ColumnConverter we define in Config File inTableColumn, has a scope of Table. When column conveter is available for a Command, it will be used and in its absence, the one available at Table/Column scope will be use and in its absence it will be Default/No converter as usual. This will have a benefit for clients, which need frequent use of column converter and have changing needs (based on say, Locale, TimeZone,). Suggestions? Regards, Amita
Re: SVN Props
On 8/8/07, Luciano Resende [EMAIL PROTECTED] wrote: Please update the following too https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/set_svn_properties.sh On 8/7/07, Simon Laws [EMAIL PROTECTED] wrote: The following appear to be missing from etc/svn-props DISCLAIMER = svn:eol-style=native;svn:mime-type=text/plain *.composite = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Rev Date Is there a good reason? If not I'll go add them Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok, I've updated both files with the new changes. However the two files don't match for other reasons. I'll take a look if I get a chance. Simon
Re: Java2WSDL/WSDL2Java tools
Thats right, these are the Axis2 tools just with some patches on top to add support for SDOs and to fix bugs we've come across before we got the bugs fixed in the Axis2 code. The problem with doing it like this has been we fall be hind Axis2 and loose track of what we changed and its a headache to merge things each time there's a new Axis2 release, which is why our versions have slipped behind like this. I agree we should do just as you say and work more closely with Axis2, ideally make SDO a first class Axis2 databinding so we don't even need to modify the Axis2 code. Thats kind of why I started this thread - to prompt some discussion on what we want this tooling to be doing. ...ant On 8/8/07, Brady Johnson [EMAIL PROTECTED] wrote: I thought I saw a post recently where someone mentioned that these tools were taken from axis. If so, are we going to maintain a parallel implementation? It might be useful to talk with the axis folks to see if these tools can be refactored in such a way as to easily allow the types of extensions/additions that Tuscany will be doing, thus avoiding duplicate code. On another note: Has anyone ever seen the same tools for C++? If not, maybe we could open another thread to discuss implementing them for TuscanySCA Native. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 08, 2007 12:47 PM To: tuscany-dev Subject: Java2WSDL/WSDL2Java tools Our Java2WSDL and WSDL2Java tools have been a bit neglected and thats starting to get a few comments, so what should we do with these? Is the intention that these are specifically for SDO or should they be more general tools with options to be compatible with all the data binding's that Tuscany SCA supports? The ws binding generating wsdl on the fly seems related to Java2WSDL, do we expect the wsdl be identical whether generated on the fly or from java2wsdl? Should the on the fly generation and java2wsdl tool share any common code? There's also the java/xsd tools on the SDO project, should any of that code get used by the SCA tools when using SDOs? ...ant
Re: Release management for next release, was: SCA 0.92 release?
On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Sure, 1.0 development should happen in trunk, but I was trying to respond to a different point brought up by Raymond. On Aug 18, we are going to cut the August release branch. The point is about allowing small changes, bug fixes and improvements to continue in that branch while we are putting the release distros together, with the following conditions: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. Sure ok, the branch wont be immediately frozen, but, and its a big but, we need to be really careful with that as every time we've allowed development to continue in the branch it has ended up delaying a release. No one can on each commit do a full review including running all the samples, reading all the readme's and vetting all the legal stuff, so things get missed. Its also hard to review things thoroughly after you've already done a review a couple of times, so things start getting missed. I'd rather delay taking the branch than plan on being able to continue development in the branch. There's been a lot of change in trunk since 0.91, maybe what we should do is start the clean up work, legal review, sorting out the distributions for all the module changes etc in trunk towards then end of next week but not take the branch till very early the following week with the expectation of getting RC1 out really quickly. ...ant
Re: Cross-jvm locate service
Comments inline. [snip] Simon Laws wrote: Currently getServiceReference() expects a service name so we can rely on the implication that all contributed composites are notionally included into the domain level composite to reference a component and extend Sebastien's process to say. Just to make sure it's clear, as I'm not sure I completely follow the above sentence, components deployed to other nodes will not be present in the in-memory composite model kept in an SCAdomain object. 1. look for the target component model object in the in-memory domain composite kept in SCADomain if found 2. look for the target service on that component 3. find on that component the self-reference created for that service (these self-references are automatically created by CompositeBuilder for each service provided by a component) 4. create a CallableReference for that self-reference 5. get a proxy to the service from the CallableReference else 2. look for the named component/serivce in other nodes of the distributed (cross JVM) domain I am working up some interfaces to allow this to happen in the distributed domain case, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java Not implemented just yet as I'm currently looking at the sca domain implementation but you get the idea. The implementation could use some simple repository implementation or could derive the information from file. 3. Create a local reference for the remote service Your if/else proposal looks good to me. Not sure of the details here but you both seem happy that this is straightforward. The thing that does look problematic is determining the binding. Not so problematic if it's part of the info returned by your ServiceDiscovery :) In the distributed case I assume that all cross JVM messaging are handled by the sca binding. No, any binding can be used inside an SCA domain. Are you expecting that you can do a getService for a non-wired service, i.e. a service with an explicit remote binding such as binding.ws, that is running in another VM. Not sure what you mean by a non-wired service. Services with binding.ws can be wired too. If so that we will need, as Sebastien suggests, to be able to get hold of more information about the remote component than I have taken account of to date so that a partial model can be constructed in order to create the correct binding. Yes :) 4 5 as above Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
Hi, Theres been lots of discussion. So let me summarize my understanding / imaginiation : - - We will cut a branch around Aug 18th for Release 0.95. As always, once the branch is cut we need to be watchful on the commits (including getting the RMs nod to significant ones) to the branch and also ensure the trunk is always in sync. - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. Is that all right ? - Venkat On 8/9/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Sure, 1.0 development should happen in trunk, but I was trying to respond to a different point brought up by Raymond. On Aug 18, we are going to cut the August release branch. The point is about allowing small changes, bug fixes and improvements to continue in that branch while we are putting the release distros together, with the following conditions: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. Sure ok, the branch wont be immediately frozen, but, and its a big but, we need to be really careful with that as every time we've allowed development to continue in the branch it has ended up delaying a release. No one can on each commit do a full review including running all the samples, reading all the readme's and vetting all the legal stuff, so things get missed. Its also hard to review things thoroughly after you've already done a review a couple of times, so things start getting missed. I'd rather delay taking the branch than plan on being able to continue development in the branch. There's been a lot of change in trunk since 0.91, maybe what we should do is start the clean up work, legal review, sorting out the distributions for all the module changes etc in trunk towards then end of next week but not take the branch till very early the following week with the expectation of getting RC1 out really quickly. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[
https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518670
]
Adriano Crestani commented on TUSCANY-1464:
---
- On code below, it checks for the fk COC that is table_id, however this code
will take _id as fk, but there is no table name before the '_'. I think the
condition below should be = 1 instead of 0.
ResultMetadata Constructor:
...
String colName = ;
if (columnName.indexOf(_ID) = 0) {
...
-Another doubt, is the String column name always upper case? Otherwise the
indexof will look for the _ID on sensitive case mode, when it shouldn't.
- Why do you check for null pks twice on method
ResultSetProcessor.addRowToGraph?
if (!rawDataFromRow.hasValidPrimaryKey() ||
(rawDataFromRow.hasNullPrimaryKey()
!rawDataFromRow.isTableEmpty())) {//some PK null , but other data present
//continue; - need to throw exception as anyway the result will
give a wrong impression
//when any one table in result set misses PK column or has null
value in PK column
throw new RuntimeException(Table
+rawDataFromRow.getTableName()+ in query does not include Primary Key +
column or has null value in it, can not
proceed!);
}
String tableName = rawDataFromRow.getTableName();
DataObject tableObject = registry.get(tableName,
rawDataFromRow.getPrimaryKeyValues());
if (tableObject == null
rawDataFromRow.getPrimaryKeyValues() != null
!rawDataFromRow.getPrimaryKeyValues().contains(null)
rawDataFromRow.getPrimaryKeyValues().size() 0)
{//2nd check for null data in PK,
//as TableData.addData() - hasValidPrimaryKey=false is
commented for a reason
//with this, DataObjs with null PK will not be added to
registry and tableObjects
tableObject = doMaker.createAndAddDataObject(rawDataFromRow,
resultMetadata);
if (this.logger.isDebugEnabled()) {
this.logger.debug(Putting table + tableName + with PK
+ rawDataFromRow.getPrimaryKeyValues() + into
registry);
}
registry.put(tableName, rawDataFromRow.getPrimaryKeyValues(),
tableObject);
}
else{
if (this.logger.isDebugEnabled()) {
this.logger.debug(Not Null tableObject or NULL PK);
}
}
I applied the patch on trunk, but when mvn compiled there was a class using
ResultDescriptor.getColumnIndex method, but this getter was only added on patch
from JIRA 1465. Then I applied both, 1464 and then 1465, is it ok? Perhaps, the
mvn tests failed on test:
FAILURE!
testReplaceResultDescriptor(org.apache.tuscany.das.rdb.test.DynamicResultDescrip
torTests) Time elapsed: 0.02 sec FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at org.apache.tuscany.das.rdb.test.DynamicResultDescriptorTests.testRepl
aceResultDescriptor(DynamicResultDescriptorTests.java:147)
at org.apache.tuscany.das.rdb.test.DynamicResultDescriptorTests.testRepl
aceResultDescriptor(DynamicResultDescriptorTests.java:147)
I don't know if I did something wrong, but I will try it tomorrow, needing to
sleep now ; )
Regards,
Adriano Crestani
Wrong query results when SELECT misses PKs
--
Key: TUSCANY-1464
URL: https://issues.apache.org/jira/browse/TUSCANY-1464
Project: Tuscany
Issue Type: Bug
Components: Java DAS RDB
Affects Versions: Java-DAS-Next
Reporter: Amita Vadhavkar
Assignee: Amita Vadhavkar
Fix For: Java-DAS-Next
Attachments: 1464.patch, 1464.patch, 1464.patch
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html
Fix the bug uncovered in above mail discussion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1445) SDO - README.txt in resources/META-INF should be deleted
[ https://issues.apache.org/jira/browse/TUSCANY-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1445. - Resolution: Fixed Fix Version/s: (was: Java-SDO-Next) Java-SDO-1.0 Fixed as part of the 1.0-incubating release. SDO - README.txt in resources/META-INF should be deleted Key: TUSCANY-1445 URL: https://issues.apache.org/jira/browse/TUSCANY-1445 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-beta1 Reporter: Tom Seelbach Priority: Minor Fix For: Java-SDO-1.0 There is a README.txt in each of the following directories: plugin\src\main\resources\META-INF impl\src\main\resources\META-INF tools\src\main\resources\META-INF the first line of the README refers to the M1 (May 2006) which is incorrect. The next part of the README is a subset of the information from the NOTICE and should not be duplicated in a README. The Support section of the README is not needed at this level of the project. It is better to put support statements like this on the wiki, or at the top level of the project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross-jvm locate service
On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Comments inline. [snip] Simon Laws wrote: Currently getServiceReference() expects a service name so we can rely on the implication that all contributed composites are notionally included into the domain level composite to reference a component and extend Sebastien's process to say. Just to make sure it's clear, as I'm not sure I completely follow the above sentence, components deployed to other nodes will not be present in the in-memory composite model kept in an SCAdomain object. I was just pointing out that regardless of where a component is actually running one of it's services can be identified in the domain composite using the component/service name by virtue of the implicit inclusion of contributed composites into the domain composite. This is an important assumption as it means that people can arbitrarily locate services deployed into the domain. I was making no statement about what is in the model inside each JVM. I assume that the model in each JVM will contain whatever artifacts that have been contributed to that JVM. So if you have different contributions for each JVM in the domain then you get whatever is contributed to the JVM in your model. If you want to reference a component that is not part of the contributions loaded by the JVM then you are forced to look elsewhere in the distributed domain. If you want the components in a single contribution/composite to be distributed across JVMs then this is a different scenario. We have done this before with the distributed runtime by recording the component/JVM mapping in a topology file. This still doesn't imply that the components will make it into the model (although they do in the current distributed implementation). 1. look for the target component model object in the in-memory domain composite kept in SCADomain if found 2. look for the target service on that component 3. find on that component the self-reference created for that service (these self-references are automatically created by CompositeBuilder for each service provided by a component) 4. create a CallableReference for that self-reference 5. get a proxy to the service from the CallableReference else 2. look for the named component/serivce in other nodes of the distributed (cross JVM) domain I am working up some interfaces to allow this to happen in the distributed domain case, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java Not implemented just yet as I'm currently looking at the sca domain implementation but you get the idea. The implementation could use some simple repository implementation or could derive the information from file. 3. Create a local reference for the remote service Your if/else proposal looks good to me. Not sure of the details here but you both seem happy that this is straightforward. The thing that does look problematic is determining the binding. Not so problematic if it's part of the info returned by your ServiceDiscovery :) Agreed I just hadn't put it there yet because I was only dealing with the case where cross JVM call is constructed automatically with the sca binding. You are probably right that I should make it more generally applicable. In the distributed case I assume that all cross JVM messaging are handled by the sca binding. No, any binding can be used inside an SCA domain. Sorry I misslead you here unintentionally.What I mean is that in the case I am concentrating on at the moment I'm only dealing with the sca binding. I didn't mean to imply that you can't manually specify remote bindings between components within an sca domain. If you do this though AND you specify the endpoint you are duty bound to bet it right. I.e. I'm not currently putting in code to fix up remote bindings so that the the correct endpoint is obtained regardless of what someone has put in the SCDL, WSDL etc. Are you expecting that you can do a getService for a non-wired service, i.e. a service with an explicit remote binding such as binding.ws, that is running in another VM. Not sure what you mean by a non-wired service. Services with binding.ws can be wired too. I was specifically asking about the case that you do a getService for a service that defines binding.ws with all the trimmings, i.e. endpoint information. Actually maybe this works already. I'll have to go and try. If so that we will need, as Sebastien suggests, to be able to get hold of more information about the remote component than I have taken account of to date so that a partial model can be constructed in order to create the correct binding. Yes :) 4 5 as above Simon -- Jean-Sebastien - To unsubscribe,
Creating a o.a.t.s.interfacedef.wsdl.WSDLInterface from an o.a.t.s.interfacedef.java.JavaInterface
As part of the binding.ws on the fly wsdl generation i've been struggling with creating a working Tuscany WSDLInterface object from a JavaInterface object. I just can't seem to get things set up correctly so a complete invocation flow works and the data binding interceptor works correctly doing all the transformations and wrapping/unwrapping etc. I've not been able to worked out exactly whats required to initialize all the various objects and variables manually so that things work and that approach seems to end up duplicating a lot of existing code which doesn't seem ideal, but it also doesn't seem easy to get access to and use use the various existing idl code we already have to create all the operations and wrapper objects etc. So anyone have any hints how and where would be the best place to be doing this type of thing? ...ant
Service visibility (was Re: Cross-jvm locate service)
This is technically feasible (see other discussion on this thread) but I think we need to be careful about how wide open we are making the services within a Tuscany SCA domain. I don't think we want every service within every domain to be wide open for anyone to reach down from the sky and call it. As the owner of a service, I would want to decide whether it is exposed for local calling, distributed calling within my domain (which can consist of multiple runtime nodes), or revealed to other domains via some global locateService API. I think the right way for me to exercise this control is to create a self-reference or a service reference within my domain, then selectively pass this out to other domains in a manner that I can control, e.g., in a service registry that is able to implement a governance policy. Simon Kevin Williams wrote: I am interested in extending the current locate service capability to support the location of services that may be running within the same domain but a separate jvm. The most straightforward approach may be to dynamically create and return a service reference using the same Tuscany runtime elements that now create service references for injection in support of the @reference annotation. Any thoughts or pointers would be appreciated. Thanks, --Kevin - 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]
Re: Java2WSDL/WSDL2Java tools
sounds sensible to me, +1 to handling this within Axis2. Kelvin. On 09/08/07, ant elder [EMAIL PROTECTED] wrote: Thats right, these are the Axis2 tools just with some patches on top to add support for SDOs and to fix bugs we've come across before we got the bugs fixed in the Axis2 code. The problem with doing it like this has been we fall be hind Axis2 and loose track of what we changed and its a headache to merge things each time there's a new Axis2 release, which is why our versions have slipped behind like this. I agree we should do just as you say and work more closely with Axis2, ideally make SDO a first class Axis2 databinding so we don't even need to modify the Axis2 code. Thats kind of why I started this thread - to prompt some discussion on what we want this tooling to be doing. ...ant On 8/8/07, Brady Johnson [EMAIL PROTECTED] wrote: I thought I saw a post recently where someone mentioned that these tools were taken from axis. If so, are we going to maintain a parallel implementation? It might be useful to talk with the axis folks to see if these tools can be refactored in such a way as to easily allow the types of extensions/additions that Tuscany will be doing, thus avoiding duplicate code. On another note: Has anyone ever seen the same tools for C++? If not, maybe we could open another thread to discuss implementing them for TuscanySCA Native. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 08, 2007 12:47 PM To: tuscany-dev Subject: Java2WSDL/WSDL2Java tools Our Java2WSDL and WSDL2Java tools have been a bit neglected and thats starting to get a few comments, so what should we do with these? Is the intention that these are specifically for SDO or should they be more general tools with options to be compatible with all the data binding's that Tuscany SCA supports? The ws binding generating wsdl on the fly seems related to Java2WSDL, do we expect the wsdl be identical whether generated on the fly or from java2wsdl? Should the on the fly generation and java2wsdl tool share any common code? There's also the java/xsd tools on the SDO project, should any of that code get used by the SCA tools when using SDOs? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1522) @ConversationID injection incorrectly assumes target type is a String
[
https://issues.apache.org/jira/browse/TUSCANY-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518687
]
Mark Combellack commented on TUSCANY-1522:
--
The problem is with the following code in the visitField() and visitMethod()
methods of ConversationIDProcessor
Class? paramType = field.getType();
if (String.class.equals(paramType)) {
. Does the injection here...
} else {
throw new UnknownContextTypeException(paramType.getName());
}
As can be seen, before doing the injection, it checks that the type of the
field/method parameter is a String. If it is not, then it throws an exception.
@ConversationID injection incorrectly assumes target type is a String
-
Key: TUSCANY-1522
URL: https://issues.apache.org/jira/browse/TUSCANY-1522
Project: Tuscany
Issue Type: Bug
Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-Next
Environment: Was using Tuscany revision 563420
Reporter: Mark Combellack
Fix For: Java-SCA-Next
Tuscany injection of @ConversationID assumes the target field is a String.
This is not the always the case according to the specification
Page 33 of the Java Common Annotations and API says:
1713 The type of this field is not necessarily String
However, the Tuscany
org.apache.tuscany.sca.implementation.java.introspect.impl.ConversationIDProcessor
class throws UnknownContextTypeException if the field is not a String.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1006) ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe
[ https://issues.apache.org/jira/browse/TUSCANY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518690 ] Kelvin Goodson commented on TUSCANY-1006: - Looks good to me -- caters for all possibilities. Will this be a one time check and store state? ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe -- Key: TUSCANY-1006 URL: https://issues.apache.org/jira/browse/TUSCANY-1006 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-beta1 Environment: Sun JDK 1.4.2_11, 2-CPU server Reporter: Ron Gavlin Priority: Critical Fix For: Java-SDO-beta1 I have an application in which multiple threads access a shared ChangeSummaryImpl. Each thread invokes ChangeSummaryImpl.getOldValues() repeatedly. This causes one or more of the threads to enter an infinite while (true) - loop in HashMap.get(Object) with the following stack trace: HashMap.get(Object) line: 323 ChangeSummaryImpl.getOldValues(DataObject) line: 481 ... I suspect this occurs because the access to HashMap cachedSDOObjectChanges is not synchronized. I have been unable as of yet to create a simple test case that demonstrates the problem. In the meantime, I will try to implement a short-term fix by changing line 93 of ChangeSummaryImpl from protected HashMap cachedSDOObjectChanges = new HashMap(); to protected Map cachedSDOObjectChanges = Collections.synchronizedMap(new HashMap()); I will let you know if that fixes the problem. Any insight or assistance you can offer concerning this problem is appreciated. This is a show-stopper problem for us. Regards, - Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
Ant talked about cutting the branch very early next week. I'd prefer that to doing it on August 18th. I will be away for a few days, returning home late on the 18th, and I could take advantage of the extra couple of days to help with last-minute things. Simon Venkata Krishnan wrote: Hi, Theres been lots of discussion. So let me summarize my understanding / imaginiation : - - We will cut a branch around Aug 18th for Release 0.95. As always, once the branch is cut we need to be watchful on the commits (including getting the RMs nod to significant ones) to the branch and also ensure the trunk is always in sync. - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. Is that all right ? - Venkat On 8/9/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Sure, 1.0 development should happen in trunk, but I was trying to respond to a different point brought up by Raymond. On Aug 18, we are going to cut the August release branch. The point is about allowing small changes, bug fixes and improvements to continue in that branch while we are putting the release distros together, with the following conditions: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. Sure ok, the branch wont be immediately frozen, but, and its a big but, we need to be really careful with that as every time we've allowed development to continue in the branch it has ended up delaying a release. No one can on each commit do a full review including running all the samples, reading all the readme's and vetting all the legal stuff, so things get missed. Its also hard to review things thoroughly after you've already done a review a couple of times, so things start getting missed. I'd rather delay taking the branch than plan on being able to continue development in the branch. There's been a lot of change in trunk since 0.91, maybe what we should do is start the clean up work, legal review, sorting out the distributions for all the module changes etc in trunk towards then end of next week but not take the branch till very early the following week with the expectation of getting RC1 out really quickly. ...ant - 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]
Intent and Policy attachments on Operations
Hi, The Assembly Specs and the PolicyFramework specs allows for intents and policysets to be specified on Operations. To implement this I'd expect that the Operation interface support methods to hold a set of required intents and policysets. This also seems in sync with the schema definition for Operation. However in the existing code this has been modeled as an Intent instance having a list of operations over which the intent could apply. Similarly a PolicySet instance has a list of operations to which the policyset applies. Is there any specific reason for modeling it this way? I am in progress with changes that change this to what I have mentioned in the second paragraph of this mail. If I am heading in the wrong direction, could somebody shout please. Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1465) Allow passing ResultDescriptor for dynamic Commands
[ https://issues.apache.org/jira/browse/TUSCANY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518709 ] Amita Vadhavkar commented on TUSCANY-1465: -- Hi , am checking for your comments for 1464 and 1465, will reply/give improved patch for both in a day. Please do not commit any of these. Regards Amita Allow passing ResultDescriptor for dynamic Commands --- Key: TUSCANY-1465 URL: https://issues.apache.org/jira/browse/TUSCANY-1465 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1465.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19886.html Action for the issue discussed in above mail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1465) Allow passing ResultDescriptor for dynamic Commands
[ https://issues.apache.org/jira/browse/TUSCANY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518711 ] ant elder commented on TUSCANY-1465: I wonder if this is case where be liberal in what we accept, conservative in what we do might apply? If a patch has been tried and it looks ok and all tests pass but there's just a some questions on approach i think it can be good to just apply it and then incrementally develop things further once its in. Allow passing ResultDescriptor for dynamic Commands --- Key: TUSCANY-1465 URL: https://issues.apache.org/jira/browse/TUSCANY-1465 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1465.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19886.html Action for the issue discussed in above mail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Contribution URLs
I've just noticed that if I have a contribution directory as follows /my/contribution/dir/mycomposite.composite And I pass the source URL /my/contribution/dir to the contribution service it complains that it can't find /my/contribution/mycomposite.composite. If I pass the source URL /my/contribution/dir/ it works (note slash on end). Is this a fault? Simon
Re: Build problem in binding-ws-axis2
On 8/9/07, ant elder [EMAIL PROTECTED] wrote: Yes, i've been seeing this today as well, seemed to be fine earlier in the week. ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm seeing java.net.ConnectException: Connection refused: connect errors when building binding-ws-axis2 from a clean checkout of trunk. The failure is slightly intermittent in terms of the number of tests that fail, which varies from run to run. Cleaning and rebuilding doesn't help, but running with mvn rather than mvn -o seems to slightly reduce the number of failing tests. I almost never see the whole set of tests run without this error. I started seeing it last night, and it was not happening on my previous checkout of a few days ago. This was a big problem for me a few months ago and I provided a patch that seemed to solve the problem, but now it is back with a vengeance. Is anyone else seeing this problem? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I haven't been seeing this and that was the symptom we say before, i.e. some people saw it and some didn't. Simon
[jira] Commented: (TUSCANY-1465) Allow passing ResultDescriptor for dynamic Commands
[ https://issues.apache.org/jira/browse/TUSCANY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518716 ] Adriano Crestani commented on TUSCANY-1465: --- I agree with you ant, I applied the patches from JIRA 1465 and 1464 separately and both passed on maven tests. Then I applied both on the same trunk, but the tests failed, so I couldn't commit :( These errors are commented on https://issues.apache.org/jira/browse/TUSCANY-1464 Regards, Adraino Crestani Allow passing ResultDescriptor for dynamic Commands --- Key: TUSCANY-1465 URL: https://issues.apache.org/jira/browse/TUSCANY-1465 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1465.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19886.html Action for the issue discussed in above mail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build problem in binding-ws-axis2
Yes, i've been seeing this today as well, seemed to be fine earlier in the week. ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm seeing java.net.ConnectException: Connection refused: connect errors when building binding-ws-axis2 from a clean checkout of trunk. The failure is slightly intermittent in terms of the number of tests that fail, which varies from run to run. Cleaning and rebuilding doesn't help, but running with mvn rather than mvn -o seems to slightly reduce the number of failing tests. I almost never see the whole set of tests run without this error. I started seeing it last night, and it was not happening on my previous checkout of a few days ago. This was a big problem for me a few months ago and I provided a patch that seemed to solve the problem, but now it is back with a vengeance. Is anyone else seeing this problem? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Vote to release Apache Tuscany SDO Java 1.0-incubating
The vote to release Apache Tuscany SDO 1.0-incubating has completed with 5 +1 votes being cast (3 IPMC binding) and no -1s (see the tuscany-dev list vote thread [1] and the incubator-general vote approval thread [2]). Thank you for reviewing and voting. I will therefore proceed with the deployment and announcement. Kelvin. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21169.html [2] http://www.mail-archive.com/[EMAIL PROTECTED]/msg14882.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build problem in binding-ws-axis2
This is so bad for me now that i can no longer get a build through of the Axis2 binding, always one of the tests will fail with the connect exception. I've just tried on a spare machine and that is working fine. Both machines are winxp with jdk5, the only difference i can see is that the one that works is using maven 2.0.6 and the one that doesn't is on maven 2.0.4. ...ant On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, ant elder [EMAIL PROTECTED] wrote: Yes, i've been seeing this today as well, seemed to be fine earlier in the week. ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm seeing java.net.ConnectException: Connection refused: connect errors when building binding-ws-axis2 from a clean checkout of trunk. The failure is slightly intermittent in terms of the number of tests that fail, which varies from run to run. Cleaning and rebuilding doesn't help, but running with mvn rather than mvn -o seems to slightly reduce the number of failing tests. I almost never see the whole set of tests run without this error. I started seeing it last night, and it was not happening on my previous checkout of a few days ago. This was a big problem for me a few months ago and I provided a patch that seemed to solve the problem, but now it is back with a vengeance. Is anyone else seeing this problem? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I haven't been seeing this and that was the symptom we say before, i.e. some people saw it and some didn't. Simon
Re: Service visibility (was Re: Cross-jvm locate service)
Kevin and I are considering in extending the current locate service with a mechanism that is aware of the composite context. That is, services exposed by a domain level composite would be visible to all and services available on other composites would only be visible to the containing composite. If this is not a correct interpretation of the SCA Assembly Model, please correct me. Paul Simon Nash [EMAIL PROTECTED] 2007-08-09 06:27 AM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Service visibility (was Re: Cross-jvm locate service) This is technically feasible (see other discussion on this thread) but I think we need to be careful about how wide open we are making the services within a Tuscany SCA domain. I don't think we want every service within every domain to be wide open for anyone to reach down from the sky and call it. As the owner of a service, I would want to decide whether it is exposed for local calling, distributed calling within my domain (which can consist of multiple runtime nodes), or revealed to other domains via some global locateService API. I think the right way for me to exercise this control is to create a self-reference or a service reference within my domain, then selectively pass this out to other domains in a manner that I can control, e.g., in a service registry that is able to implement a governance policy. Simon Kevin Williams wrote: I am interested in extending the current locate service capability to support the location of services that may be running within the same domain but a separate jvm. The most straightforward approach may be to dynamically create and return a service reference using the same Tuscany runtime elements that now create service references for injection in support of the @reference annotation. Any thoughts or pointers would be appreciated. Thanks, --Kevin
[ANNOUNCE] Apache Tuscany Java SDO 1.0-incubating released
The Apache Tuscany team are pleased to announce the 1.0-incubating release of the Java SDO project. This project provides an implementation of the SDO 2.1 specification [1] and this is our first release to provide full coverage of the specification. In addition to completing the few remaining SDO 2.1 features there are a number of new features relating to XML serialization, new support for handling dynamic derivation from static classes and improvement to the sample programs. For the full change history take a look at [2] To download SDO Java or for more information about the release go to: http://incubator.apache.org/tuscany/sdo-java-releases.html Apache Tuscany welcomes your help. Any contribution, including code, testing, improving the documentation, or bug reporting is always appreciated. For more information on how to get involved in Apache Tuscany visit the website at: http://incubator.apache.org/tuscany. Thank you for your interest in Apache Tuscany! The Apache Tuscany Team. --- Tuscany is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Web services PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. [1] http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1 [2] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating/distribution/src/main/release/RELEASE_NOTES - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1473) Define component's service with interface.wsdl ,throws 'No matching operation' error.
[ https://issues.apache.org/jira/browse/TUSCANY-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518747 ] Scott Kurz commented on TUSCANY-1473: - This problem looks similar to TUSCANY-1342 which I opened. I commented there that for a remotable interface you can't overload the method names anyway ... and WSDL interfaces are always remotable. Define component's service with interface.wsdl ,throws 'No matching operation' error. - Key: TUSCANY-1473 URL: https://issues.apache.org/jira/browse/TUSCANY-1473 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: wangfeng Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: testcase.zip I define the component's service with interface.java,the sample runs fine. but when I modify the component's service with interface.wsdl,the sample throws an exception. The throwable stack is : Exception in thread main java.lang.IllegalArgumentException: No matching operation is found: public abstract java.lang.String helloworld.HelloWorldService.getGreetings(java.lang.String) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:69) at $Proxy10.getGreetings(Unknown Source) at helloworld.HelloWorldClient.main(HelloWorldClient.java:33) I look into the code,found the invoke mothod's input type is 'String',but the method which name is operation.getInputType().getLogical().get(i).getPhysical() on the SourceOperation of the InvocationChain is always return 'Object' type,so can't find an operation to match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New itest folder: guidelines
Folks, I am planing to create my own folder (venu) in java/sca/itests and write few sample tests. Can any one please post if you have any guidelines on writing pom.xml (\java\sca\itests\venu\pom.xml) to include my sample tests for maven to build and execute. Thanks, Venu. - A 'wish' changes nothing. A 'decision' changes everything! Anon
[jira] Updated: (TUSCANY-1006) ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe
[ https://issues.apache.org/jira/browse/TUSCANY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Gavlin updated TUSCANY-1006: Attachment: tuscany-sdo-impl.TUSCANY-1006.patch Patch attached. ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe -- Key: TUSCANY-1006 URL: https://issues.apache.org/jira/browse/TUSCANY-1006 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-beta1 Environment: Sun JDK 1.4.2_11, 2-CPU server Reporter: Ron Gavlin Priority: Critical Fix For: Java-SDO-beta1 Attachments: tuscany-sdo-impl.TUSCANY-1006.patch I have an application in which multiple threads access a shared ChangeSummaryImpl. Each thread invokes ChangeSummaryImpl.getOldValues() repeatedly. This causes one or more of the threads to enter an infinite while (true) - loop in HashMap.get(Object) with the following stack trace: HashMap.get(Object) line: 323 ChangeSummaryImpl.getOldValues(DataObject) line: 481 ... I suspect this occurs because the access to HashMap cachedSDOObjectChanges is not synchronized. I have been unable as of yet to create a simple test case that demonstrates the problem. In the meantime, I will try to implement a short-term fix by changing line 93 of ChangeSummaryImpl from protected HashMap cachedSDOObjectChanges = new HashMap(); to protected Map cachedSDOObjectChanges = Collections.synchronizedMap(new HashMap()); I will let you know if that fixes the problem. Any insight or assistance you can offer concerning this problem is appreciated. This is a show-stopper problem for us. Regards, - Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1006) ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe
[ https://issues.apache.org/jira/browse/TUSCANY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Gavlin updated TUSCANY-1006: Patch Info: [Patch Available] ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe -- Key: TUSCANY-1006 URL: https://issues.apache.org/jira/browse/TUSCANY-1006 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-beta1 Environment: Sun JDK 1.4.2_11, 2-CPU server Reporter: Ron Gavlin Priority: Critical Fix For: Java-SDO-beta1 Attachments: tuscany-sdo-impl.TUSCANY-1006.patch I have an application in which multiple threads access a shared ChangeSummaryImpl. Each thread invokes ChangeSummaryImpl.getOldValues() repeatedly. This causes one or more of the threads to enter an infinite while (true) - loop in HashMap.get(Object) with the following stack trace: HashMap.get(Object) line: 323 ChangeSummaryImpl.getOldValues(DataObject) line: 481 ... I suspect this occurs because the access to HashMap cachedSDOObjectChanges is not synchronized. I have been unable as of yet to create a simple test case that demonstrates the problem. In the meantime, I will try to implement a short-term fix by changing line 93 of ChangeSummaryImpl from protected HashMap cachedSDOObjectChanges = new HashMap(); to protected Map cachedSDOObjectChanges = Collections.synchronizedMap(new HashMap()); I will let you know if that fixes the problem. Any insight or assistance you can offer concerning this problem is appreciated. This is a show-stopper problem for us. Regards, - Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New itest folder: guidelines
You could use some of the other project existing pom[1] as guidelines. The poms are all inheriting the necessary configuration to run the tests from the parent pom [2] and it looks like below : !-- surefire plugin configuration -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.3/version configuration includes include**/*TestCase.java/include /includes reportFormatbrief/reportFormat useFilefalse/useFile forkModeonce/forkMode argLine-ea -Xmx128m/argLine /configuration /plugin [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/contribution/pom.xml [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/pom.xml On 8/9/07, venu reddy [EMAIL PROTECTED] wrote: Folks, I am planing to create my own folder (venu) in java/sca/itests and write few sample tests. Can any one please post if you have any guidelines on writing pom.xml (\java\sca\itests\venu\pom.xml) to include my sample tests for maven to build and execute. Thanks, Venu. - A 'wish' changes nothing. A 'decision' changes everything! Anon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build problem in binding-ws-axis2
Could you try moving to maven 2.0.5 on the one that does not work ? On 8/9/07, ant elder [EMAIL PROTECTED] wrote: This is so bad for me now that i can no longer get a build through of the Axis2 binding, always one of the tests will fail with the connect exception. I've just tried on a spare machine and that is working fine. Both machines are winxp with jdk5, the only difference i can see is that the one that works is using maven 2.0.6 and the one that doesn't is on maven 2.0.4. ...ant On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, ant elder [EMAIL PROTECTED] wrote: Yes, i've been seeing this today as well, seemed to be fine earlier in the week. ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm seeing java.net.ConnectException: Connection refused: connect errors when building binding-ws-axis2 from a clean checkout of trunk. The failure is slightly intermittent in terms of the number of tests that fail, which varies from run to run. Cleaning and rebuilding doesn't help, but running with mvn rather than mvn -o seems to slightly reduce the number of failing tests. I almost never see the whole set of tests run without this error. I started seeing it last night, and it was not happening on my previous checkout of a few days ago. This was a big problem for me a few months ago and I provided a patch that seemed to solve the problem, but now it is back with a vengeance. Is anyone else seeing this problem? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I haven't been seeing this and that was the symptom we say before, i.e. some people saw it and some didn't. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accessing global domain information
I need some advice on the way the code is structures. In various places in the code I need to get at some information that logically belongs to the sca domain. For example, CompositeWireBuilderImpl.connectComponentReferences() Tries to resolve services. In the distributed case this resolution may validly fail and I need to ask the domain whether the service is available elsewhere. So I need access to some domain management services. Ideally I would like to have access to a domain interface but am unsure how to plumb it in as this kind of thing isn't generally available now. Anyone care to offer some advice how I get at such an interface without breaking the SPIs? Thanks Simon
Re: New itest folder: guidelines
Hi Venu, To start with, you could also simply copy over one of the poms in the existing itests and modify the artifact names, dependencies etc. that is specific to what you plan to do. - Venkat On 8/9/07, venu reddy [EMAIL PROTECTED] wrote: Folks, I am planing to create my own folder (venu) in java/sca/itests and write few sample tests. Can any one please post if you have any guidelines on writing pom.xml (\java\sca\itests\venu\pom.xml) to include my sample tests for maven to build and execute. Thanks, Venu. - A 'wish' changes nothing. A 'decision' changes everything! Anon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mvn eclipse:eclipse fails on java
Hi, I tried checking out java and eclipseefying the build, but I get this error: 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intent and Policy attachments on Operations
Venkata Krishnan wrote: Hi, The Assembly Specs and the PolicyFramework specs allows for intents and policysets to be specified on Operations. To implement this I'd expect that the Operation interface support methods to hold a set of required intents and policysets. This also seems in sync with the schema definition for Operation. However in the existing code this has been modeled as an Intent instance having a list of operations over which the intent could apply. Similarly a PolicySet instance has a list of operations to which the policyset applies. Is there any specific reason for modeling it this way? I am in progress with changes that change this to what I have mentioned in the second paragraph of this mail. If I am heading in the wrong direction, could somebody shout please. Thanks - Venkat The Intent - operations relationship was modeled like this intentionally. Here's why: If you're talking about o.a.t.interfacedef.Operation, then I don't think it can hold intents. Operation represents a business method/operation on a business interface, potentially used in multiple Services or References... with different sets of intents. The operation element in SCA assembly XML does not represent the actual operation on the business interface, it is just the syntax used to group the intents that apply to a given operation, within the context of a particular service or reference. So basically we need to represent the association: a set of intents - a set of operations in the context of a particular service/reference There's basically two ways to represent this: a) In an intent, list the business operations that the intent applies to or b) Invent a new object representing an operation used within the context of a reference/service, pointing to the actual operation + listing the intents The assembly model being a logical model it does not have to follow the convolutions of the particular XML syntax, and it seems to me that (a) is more logical than (b). At least it'll allow us to easily find which operations a particular intent (and the corresponding interceptors) applies to. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1523) Enhance ArtifactProcessors to be registered for file names, as well as for file types
Enhance ArtifactProcessors to be registered for file names, as well as for file types - Key: TUSCANY-1523 URL: https://issues.apache.org/jira/browse/TUSCANY-1523 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-Next Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-Next Details on the following thread: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21338.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing global domain information
Simon Laws wrote: I need some advice on the way the code is structures. In various places in the code I need to get at some information that logically belongs to the sca domain. For example, CompositeWireBuilderImpl.connectComponentReferences() Tries to resolve services. In the distributed case this resolution may validly fail and I need to ask the domain whether the service is available elsewhere. So I need access to some domain management services. Ideally I would like to have access to a domain interface but am unsure how to plumb it in as this kind of thing isn't generally available now. Anyone care to offer some advice how I get at such an interface without breaking the SPIs? Thanks Simon WireCompositeBuilderImpl is not an SPI, so you can pass whatever you want to its constructor without breaking any SPI. But I have a preliminary question: Why do you need to ask the domain (management service) about remote services at that specific point in WireCompositeBuilderImpl? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New itest folder: guidelines
venu reddy wrote: Folks, I am planing to create my own folder (venu) in java/sca/itests and write few sample tests. Can any one please post if you have any guidelines on writing pom.xml (\java\sca\itests\venu\pom.xml) to include my sample tests for maven to build and execute. Thanks, Venu. - A 'wish' changes nothing. A 'decision' changes everything! Anon There's no strict naming convention for itests but I'd suggest to give a meaningful name to the folder, clearly showing what the test case is about. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1328) can not locate service from a component whose implementation is composite
[
https://issues.apache.org/jira/browse/TUSCANY-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende resolved TUSCANY-1328.
--
Resolution: Fixed
This scenario is now working, and I also added a test case in recursive iTest
can not locate service from a component whose implementation is composite
-
Key: TUSCANY-1328
URL: https://issues.apache.org/jira/browse/TUSCANY-1328
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.90
Environment: Windows XP
Reporter: Yang Lei
Assignee: Luciano Resende
Fix For: Java-SCA-Next
default.composite:
composite autowire=false
local=true
name=Iteration3Composite
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
component name=MySimpleServiceInRecursive
implementation.composite
name=foo:MySimpleService/
/component
/composite
MySimpleService.composite:
composite autowire=false
local=true
name=MySimpleService
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
service name=MyServiceOrig1
promote=MyServiceComponentOrig/MyService
interface.java
interface=mysca.test.myservice.MyService/
/service
component name=MyServiceComponentOrig
implementation.java
class=mysca.test.myservice.impl.MyServiceImpl/
/component
/composite
MyServiceImpl
@Service(interfaces={MyService.class, MyServiceByDate.class,
MyListService.class, MyListServiceByYear.class})
public class MyServiceImpl implements MyService, MyServiceByDate,
MyListService, MyListServiceByYear{
...
}
When I try to locateService of MySimpleServiceInRecursive/MyServiceOrig1,
got the following exception
org.osoa.sca.ServiceRuntimeException: Service not found:
MySimpleServiceInRecursive/MyServiceOrig1 at
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:230)
at
org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
at test.sca.tests.MySimpleServiceInRecursiveTest.setUp(Unknown Source) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke
Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1182) Add multi-threaded test case for data object creation
[ https://issues.apache.org/jira/browse/TUSCANY-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518771 ] Kelvin Goodson commented on TUSCANY-1182: - TUSCANY-1006 also discussed a multi threaded test case. I am closing that JIRA, so the test case can be included in this fix. Add multi-threaded test case for data object creation - Key: TUSCANY-1182 URL: https://issues.apache.org/jira/browse/TUSCANY-1182 Project: Tuscany Issue Type: Test Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Reporter: Kelvin Goodson Priority: Minor Fix For: Java-SDO-Next The fix contributed for TUSCANY-1179 includes a test case that uses GroboUtils for extending the unit test capability. This JIRA is opened to decouple the fixing of the issue from the addition of the test case in order to ensure that we are clean with regards to licensing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn eclipse:eclipse fails on java
What version of maven are you using ? Does it work with maven 2.0.5 ? See more info here [1] [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21031.html On 8/9/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I tried checking out java and eclipseefying the build, but I get this error: 1 required artifact is missing. for artifact: org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT Thoughts? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1524) Need to fix file permission with DAS beta1 release distros
Need to fix file permission with DAS beta1 release distros -- Key: TUSCANY-1524 URL: https://issues.apache.org/jira/browse/TUSCANY-1524 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-DAS-beta1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1328) can not locate service from a component whose implementation is composite
[
https://issues.apache.org/jira/browse/TUSCANY-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518779
]
Paul Golick commented on TUSCANY-1328:
--
What svn revision includes the fix?
can not locate service from a component whose implementation is composite
-
Key: TUSCANY-1328
URL: https://issues.apache.org/jira/browse/TUSCANY-1328
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.90
Environment: Windows XP
Reporter: Yang Lei
Assignee: Luciano Resende
Fix For: Java-SCA-Next
default.composite:
composite autowire=false
local=true
name=Iteration3Composite
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
component name=MySimpleServiceInRecursive
implementation.composite
name=foo:MySimpleService/
/component
/composite
MySimpleService.composite:
composite autowire=false
local=true
name=MySimpleService
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
service name=MyServiceOrig1
promote=MyServiceComponentOrig/MyService
interface.java
interface=mysca.test.myservice.MyService/
/service
component name=MyServiceComponentOrig
implementation.java
class=mysca.test.myservice.impl.MyServiceImpl/
/component
/composite
MyServiceImpl
@Service(interfaces={MyService.class, MyServiceByDate.class,
MyListService.class, MyListServiceByYear.class})
public class MyServiceImpl implements MyService, MyServiceByDate,
MyListService, MyListServiceByYear{
...
}
When I try to locateService of MySimpleServiceInRecursive/MyServiceOrig1,
got the following exception
org.osoa.sca.ServiceRuntimeException: Service not found:
MySimpleServiceInRecursive/MyServiceOrig1 at
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:230)
at
org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
at test.sca.tests.MySimpleServiceInRecursiveTest.setUp(Unknown Source) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke
Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1328) can not locate service from a component whose implementation is composite
[
https://issues.apache.org/jira/browse/TUSCANY-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende updated TUSCANY-1328:
-
Test cases in working state added in revision #564288
can not locate service from a component whose implementation is composite
-
Key: TUSCANY-1328
URL: https://issues.apache.org/jira/browse/TUSCANY-1328
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.90
Environment: Windows XP
Reporter: Yang Lei
Assignee: Luciano Resende
Fix For: Java-SCA-Next
default.composite:
composite autowire=false
local=true
name=Iteration3Composite
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
component name=MySimpleServiceInRecursive
implementation.composite
name=foo:MySimpleService/
/component
/composite
MySimpleService.composite:
composite autowire=false
local=true
name=MySimpleService
policySets=sns:secure requires=cns:confidentiality
targetNamespace=http://foo;
xmlns:foo=http://foo;
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osoa.org/xmlns/sca/1.0
http://www.osoa.org/xmlns/sca/1.0
service name=MyServiceOrig1
promote=MyServiceComponentOrig/MyService
interface.java
interface=mysca.test.myservice.MyService/
/service
component name=MyServiceComponentOrig
implementation.java
class=mysca.test.myservice.impl.MyServiceImpl/
/component
/composite
MyServiceImpl
@Service(interfaces={MyService.class, MyServiceByDate.class,
MyListService.class, MyListServiceByYear.class})
public class MyServiceImpl implements MyService, MyServiceByDate,
MyListService, MyListServiceByYear{
...
}
When I try to locateService of MySimpleServiceInRecursive/MyServiceOrig1,
got the following exception
org.osoa.sca.ServiceRuntimeException: Service not found:
MySimpleServiceInRecursive/MyServiceOrig1 at
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:230)
at
org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
at test.sca.tests.MySimpleServiceInRecursiveTest.setUp(Unknown Source) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke
Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1525) documentBaseURI is incorrect in wsdl Definition
documentBaseURI is incorrect in wsdl Definition --- Key: TUSCANY-1525 URL: https://issues.apache.org/jira/browse/TUSCANY-1525 Project: Tuscany Issue Type: Bug Reporter: Lou Amodeo I found that with the recent changes in T4 to merge wsdl documnet namespaces the Definition documentBaseURI attribute no longer contains the correct path to the base wsdl document that was loaded. I found that if you preserve and restore the documentBaseURI in the WSDLDocumentProcessor around the merge this can be corrected.I have attached a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1525) documentBaseURI is incorrect in wsdl Definition
[ https://issues.apache.org/jira/browse/TUSCANY-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lou Amodeo updated TUSCANY-1525: Attachment: WSDLDocumentProcessor.java documentBaseURI is incorrect in wsdl Definition --- Key: TUSCANY-1525 URL: https://issues.apache.org/jira/browse/TUSCANY-1525 Project: Tuscany Issue Type: Bug Reporter: Lou Amodeo Attachments: WSDLDocumentProcessor.java I found that with the recent changes in T4 to merge wsdl documnet namespaces the Definition documentBaseURI attribute no longer contains the correct path to the base wsdl document that was loaded. I found that if you preserve and restore the documentBaseURI in the WSDLDocumentProcessor around the merge this can be corrected.I have attached a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Raymond Feng wrote:
Hi,
Your latest proposal sounds good.
Thanks,
Raymond
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Sunday, August 05, 2007 7:20 PM
Subject: Re: Dynamic registration of databindings, was: 0.91 Memory
Footprint
Jean-Sebastien Delfino wrote:
Raymond Feng wrote:
Hi,
Your proposal looks good. I think it is consistent with the pattern
that we use to deal with unresolved models. IMO, the proxy/delegate
objects for databindings could be:
DataBindingDelegate:
className = my.MyDataBinding (or ClassReference?)
DataBinding databinding; // transient instance lazily
instantiated from the class name
id = db1
TransformerDelegate:
className = my.DB12DB2Transformer
Transformer instance; // transient instance lazily instantiated
from the class name
source = DB1
target = DB2
weight = 100
Thanks,
Raymond
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Sunday, August 05, 2007 10:57 AM
Subject: Dynamic registration of databindings, was: 0.91 Memory
Footprint
Jean-Sebastien Delfino wrote:
[EMAIL PROTECTED] wrote:
We recently migrated our version of Tuscany from M2 to 0.91, and
we noticed that the memory consumption seems to have increased
by quite a bit. When doing memory profiling, the culprit
appeared to be classes related to Xerces DOM
(DeferredElementNSImpl, several other schema element related
classes). When profiling the samples (helloworld-ws-sdo-webapp)
and our application in M2, those classes don't seem to get
called. We are going through the jars to determine which module
is triggering the Xerces parser, but any suggestions would be
greatly appreciated.
I'm not sure which Tuscany extension triggers the loading of
Xerces yet, but the SDO-Axiom and JSON databindings and the EJB
and Script bindings seem to pull Xerces in their pom.xml.
I noticed that in 0.91 most Tuscany extensions on the classpath
(and most of them are going to be on the classpath if you're
using tuscany-sca-all.jar) are aggressively loaded and
initialized when the runtime starts. I'm going to make some
changes to a number of binding and implementation extensions to
allow them to be loaded only when they are actually required by
an SCA assembly.
I hope this will help.
I looked into most of the bindings and implementations, they are
now loaded dynamically, this should help with the footprint. I
think we need to do the same with data bindings as they are
dragging a lot of dependencies and in most cases people will stick
to a single databinding in their environment.
Registering databindings should be easy:
file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
databinding class name,id=databinding id
databinding class name,id=databinding id
etc.
I'm not sure about transformers, but was thinking about something
like this:
file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
transformer class name,source=databinding
id,target=databinding id,weight=weight
transformer class name,source=databinding
id,target=databinding id,weight=weight
etc.
Thoughts?
--
Jean-Sebastien
Most of the data binding initialization code seems to assume that
data bindings extend BaseDataBinding by calling
BaseDataBinding.setRegistry(...).
I'm trying to understand why data bindings need to keep a pointer to
the registry (actually the DataBindingExtensionPoint) and the only
occurrence where it's used is in XMLStringDataBinding in:
@Override
public boolean introspect(DataType type, Annotation[] annotations) {
if (registry.getDataBinding(type.getDataBinding()) == this) {
type.setDataBinding(getName());
type.setLogical(XMLType.UNKNOWN);
return true;
} else {
return false;
}
}
I don't understand what this code is for :) What does it do?
Would the following alternative work?
@Override
public boolean introspect(DataType type, Annotation[] annotations) {
if (getName().equals(type.getDataBinding())) {
type.setLogical(XMLType.UNKNOWN);
return true;
} else {
return false;
}
}
Thanks
or better (as it looks like data bindings can be identified by name
or by alias)?
@Override
public boolean introspect(DataType type, Annotation[] annotations) {
String dataBinding = type.getDataBinding();
if (NAME.equals(dataBinding) || ALIASES[0].equals(dataBinding)) {
type.setLogical(XMLType.UNKNOWN);
return true;
} else {
return false;
}
}
--
Jean-Sebastien
I just commited some changes to load the databindings dynamically. This
should help with the footprint.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Re: Release management for next release, was: SCA 0.92 release?
I guess early the following week still leaves time for an August release. It will be real tight though so we'll all need to be quick and thorough with our RC reviews as one problem once we get to the IPMC voting and it could easily slip it into September. So does taking the branch on the 21st sound ok to everyone? ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: Ant talked about cutting the branch very early next week. I'd prefer that to doing it on August 18th. I will be away for a few days, returning home late on the 18th, and I could take advantage of the extra couple of days to help with last-minute things. Simon Venkata Krishnan wrote: Hi, Theres been lots of discussion. So let me summarize my understanding / imaginiation : - - We will cut a branch around Aug 18th for Release 0.95. As always, once the branch is cut we need to be watchful on the commits (including getting the RMs nod to significant ones) to the branch and also ensure the trunk is always in sync. - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. Is that all right ? - Venkat On 8/9/07, ant elder [EMAIL PROTECTED] wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip Sure, 1.0 development should happen in trunk, but I was trying to respond to a different point brought up by Raymond. On Aug 18, we are going to cut the August release branch. The point is about allowing small changes, bug fixes and improvements to continue in that branch while we are putting the release distros together, with the following conditions: - No completely new function, only bug fixes and improvements. - No changes to dependencies or structure of the distro (unless required to fix a major bug, and approved by the RM). - Commits go with a full build of the runtime, itests, samples and demos, and verification that the samples still work following the steps documented in their readmes. Sure ok, the branch wont be immediately frozen, but, and its a big but, we need to be really careful with that as every time we've allowed development to continue in the branch it has ended up delaying a release. No one can on each commit do a full review including running all the samples, reading all the readme's and vetting all the legal stuff, so things get missed. Its also hard to review things thoroughly after you've already done a review a couple of times, so things start getting missed. I'd rather delay taking the branch than plan on being able to continue development in the branch. There's been a lot of change in trunk since 0.91, maybe what we should do is start the clean up work, legal review, sorting out the distributions for all the module changes etc in trunk towards then end of next week but not take the branch till very early the following week with the expectation of getting RC1 out really quickly. ...ant - 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]
Re: Cross-jvm locate service
Sebastien and Simon, Thanks for this conversation. Its been very helpful. I would like to recap a little and ask a couple of questions. At the highest level the steps to locate a service are: 1. Look locally and if found proceed as Tuscany does today, otherwise 2. Dynamically create a reference for the target service using binding and end-point URI info 3. Create a CallableReference for that self-reference 4. Get a ServiceReference proxy to the service from the CallableReference 5. Return the ServiceReference For an example of how to dynamically create a reference(2) you mentioned: CompositeConfigurationBuilderImpl.createSelfReference() and I assume you meant CompositeBuilderImpl.createSelfReference(Component, ComponentService), right? Since I won't have a ComponentService available I will need to somehow provide the required binding and InterfaceContract information. I think there are factories for these. Can you point me to code that creates a CallableReference from a ComponentReference (3) ? Thanks! --Kevin On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Comments inline. [snip] Simon Laws wrote: Currently getServiceReference() expects a service name so we can rely on the implication that all contributed composites are notionally included into the domain level composite to reference a component and extend Sebastien's process to say. Just to make sure it's clear, as I'm not sure I completely follow the above sentence, components deployed to other nodes will not be present in the in-memory composite model kept in an SCAdomain object. I was just pointing out that regardless of where a component is actually running one of it's services can be identified in the domain composite using the component/service name by virtue of the implicit inclusion of contributed composites into the domain composite. This is an important assumption as it means that people can arbitrarily locate services deployed into the domain. I was making no statement about what is in the model inside each JVM. I assume that the model in each JVM will contain whatever artifacts that have been contributed to that JVM. So if you have different contributions for each JVM in the domain then you get whatever is contributed to the JVM in your model. If you want to reference a component that is not part of the contributions loaded by the JVM then you are forced to look elsewhere in the distributed domain. If you want the components in a single contribution/composite to be distributed across JVMs then this is a different scenario. We have done this before with the distributed runtime by recording the component/JVM mapping in a topology file. This still doesn't imply that the components will make it into the model (although they do in the current distributed implementation). 1. look for the target component model object in the in-memory domain composite kept in SCADomain if found 2. look for the target service on that component 3. find on that component the self-reference created for that service (these self-references are automatically created by CompositeBuilder for each service provided by a component) 4. create a CallableReference for that self-reference 5. get a proxy to the service from the CallableReference else 2. look for the named component/serivce in other nodes of the distributed (cross JVM) domain I am working up some interfaces to allow this to happen in the distributed domain case, for example, http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java Not implemented just yet as I'm currently looking at the sca domain implementation but you get the idea. The implementation could use some simple repository implementation or could derive the information from file. 3. Create a local reference for the remote service Your if/else proposal looks good to me. Not sure of the details here but you both seem happy that this is straightforward. The thing that does look problematic is determining the binding. Not so problematic if it's part of the info returned by your ServiceDiscovery :) Agreed I just hadn't put it there yet because I was only dealing with the case where cross JVM call is constructed automatically with the sca binding. You are probably right that I should make it more generally applicable. In the distributed case I assume that all cross JVM messaging are handled by the sca binding. No, any binding can be used inside an SCA domain. Sorry I misslead you here unintentionally.What I mean is that in the case I am concentrating on at the moment I'm only dealing with the sca binding. I didn't mean to imply that you can't manually specify remote bindings between
[jira] Updated: (TUSCANY-1438) Change TuscanySCA Native build system to use ant
[ https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1438: --- Attachment: tuscany_patch_update9_jira1438 Adding the ability to compile in debug mode. Debug is turned on by one of the following: - ant -Ddebug=true # true, on, yes turns on debug, anything else turns it off - set platform.properties platform.debug.compile property to true, on, or yes Adding ability to specify additional ant targets/definitions, which would be useful for defining more compilers/linkers for compiling on additional platforms. Just set the platform.properties platform.external.definitions.file property to the path of the external definitions file. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] Change TuscanySCA Native build system to use ant Key: TUSCANY-1438 URL: https://issues.apache.org/jira/browse/TUSCANY-1438 Project: Tuscany Issue Type: Improvement Components: C++ SCA Affects Versions: Cpp-Next Environment: all platforms Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next Attachments: README_ANT_INSTALL.txt, samples.CppBigBank.build.xml, tuscany_patch_update2_jira1438, tuscany_patch_update3_jira1438, tuscany_patch_update4_jira1438, tuscany_patch_update5_jira1438, tuscany_patch_update6_jira1438, tuscany_patch_update7_jira1438, tuscany_patch_update8_jira1438, tuscany_patch_update9_jira1438, TuscanySCANative.ant.display.system, tuscanySCAnative_ant.tar.gz, tuscanySCAnative_ant_update1.tar.gz In an effort to simplify the build process, I would like to propose switching over to use ant instead of automake. It will be much easier to maintain, and is used by many more developers today than automake. Per a request by Pete Robbins to show what the build scripts would look like for cpp/sca/runtime/core, I will attach a patch with the build infrastructure to build, link, and install said library. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
On 8/9/07, Venkata Krishnan [EMAIL PROTECTED] wrote: snip - Post 0.95, maybe a couple of weeks after the release, we'd cut another branch and head with that for 1.0 release. Being a 1.0 release, we prob. need a branch early as that so that we can whet the things we are targetting for the release. Thats an interesting proposal :) Its pretty aggressive but actually sounds ok to me, what do others think about a 1.0 in this sort of time frame? It'll make a for a busy next few weeks to make 1.0 good...don't get a 2nd chance for a first impression... If we do go for this then would naming the August release 0.99 instead of 0.95 be more favourable to those who've been preferring the 1.0-beta name over 0.95? ...ant
[jira] Updated: (TUSCANY-1509) Change TuscanySDO Native build system to use ant
[ https://issues.apache.org/jira/browse/TUSCANY-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1509: --- Attachment: tuscany_patch_update1_jira1509 Adding the ability to compile in debug mode. Debug is turned on by one of the following: - ant -Ddebug=true # true, on, yes turns on debug, anything else turns it off - set platform.properties platform.debug.compile property to true, on, or yes Adding ability to specify additional ant targets/definitions, which would be useful for defining more compilers/linkers for compiling on additional platforms. Just set the platform.properties platform.external.definitions.file property to the path of the external definitions file. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] Change TuscanySDO Native build system to use ant Key: TUSCANY-1509 URL: https://issues.apache.org/jira/browse/TUSCANY-1509 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-M3 Environment: All platforms Reporter: Brady Johnson Fix For: Cpp-Next Attachments: build.xml, README_ANT_INSTALL.txt, tuscany_patch_update1_jira1509, tuscanySDONative_ant.jar In an effort to simplify the build process, I would like to propose switching over to use ant instead of automake. It will be much easier to maintain, and is used by many more developers today than automake. I have already converted most of TuscanySCA to ant. I based this SDO build system on the SCA build system. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SCA/SDO Native] ant : compile debug and specify additional compilers, etc
Hello all, I added two new features to the SCA and SDO ant build system. The first is the ability to compile in debug mode. To compile debug, just do one of the following: - from the command line ant -Ddebug=true # set it to on, yes, or true to turn on debugging - platform.properties file set the platform.debug.compile property to true, on, or yes to compile debug. The second feature allows you to import additional targets/definitions which is very useful for defining additional compilers/linkers for compiling on additional platforms. To use this feature, in the platform.properties file, set the platform.external.definitions.file property to the path of the external file. The patches have been uploaded to the following JIRAs https://issues.apache.org/jira/browse/TUSCANY-1438(SCA) https://issues.apache.org/jira/browse/TUSCANY-1509(SDO) Can someone please submit the patches to the SCA and SDO code bases. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED]
Re: Accessing global domain information
On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: I need some advice on the way the code is structures. In various places in the code I need to get at some information that logically belongs to the sca domain. For example, CompositeWireBuilderImpl.connectComponentReferences() Tries to resolve services. In the distributed case this resolution may validly fail and I need to ask the domain whether the service is available elsewhere. So I need access to some domain management services. Ideally I would like to have access to a domain interface but am unsure how to plumb it in as this kind of thing isn't generally available now. Anyone care to offer some advice how I get at such an interface without breaking the SPIs? Thanks Simon WireCompositeBuilderImpl is not an SPI, so you can pass whatever you want to its constructor without breaking any SPI. But I have a preliminary question: Why do you need to ask the domain (management service) about remote services at that specific point in WireCompositeBuilderImpl? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Sebastien I was thinking about this on the drive home. Just looking back at the code I had missed the important point that a reference target remains unresolved if the target component cannot be found. I could use this instead of the actual service lookup at this point. The issue I have though is that the CompositeWireBuilder dumps the bindings from the reference if it can't find a matching service/binding. This will be the case if the model for the references service/binding is not read into the model for the current node, i.e. if the target component is not included in the current nodes contributions. Is it valid to only replace the current bindings with selectedBindings if some selected bindings have actually be found? Simon Have been looking into this a little more and it seems that the list of matched bindings takes into account the reference multiplicities and then is used during activation to create the runtime wires so we do have to be a little cleverer in terms of creating a dummy resolved target to keep the bindings in play. Anyone out there intimately familiar with the resolution process? What I want to be able to do is have an sca binding (or any other binding for that matter) remain in place even in the case where the referenced target is not available in the local domain composite. Come runtime wire generation time the binding itself can take responsibility for creating the correct providers and invokers so that, assuming the referenced service is remoteable, the request can be routed to the correct node. Simon
Re: Build problem in binding-ws-axis2
Doesn't seem to make any difference. I guess it must be differences between the local repositories as everything else seems to be the same. ...ant On 8/9/07, Luciano Resende [EMAIL PROTECTED] wrote: Could you try moving to maven 2.0.5 on the one that does not work ? On 8/9/07, ant elder [EMAIL PROTECTED] wrote: This is so bad for me now that i can no longer get a build through of the Axis2 binding, always one of the tests will fail with the connect exception. I've just tried on a spare machine and that is working fine. Both machines are winxp with jdk5, the only difference i can see is that the one that works is using maven 2.0.6 and the one that doesn't is on maven 2.0.4. ...ant On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/9/07, ant elder [EMAIL PROTECTED] wrote: Yes, i've been seeing this today as well, seemed to be fine earlier in the week. ...ant On 8/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm seeing java.net.ConnectException: Connection refused: connect errors when building binding-ws-axis2 from a clean checkout of trunk. The failure is slightly intermittent in terms of the number of tests that fail, which varies from run to run. Cleaning and rebuilding doesn't help, but running with mvn rather than mvn -o seems to slightly reduce the number of failing tests. I almost never see the whole set of tests run without this error. I started seeing it last night, and it was not happening on my previous checkout of a few days ago. This was a big problem for me a few months ago and I provided a patch that seemed to solve the problem, but now it is back with a vengeance. Is anyone else seeing this problem? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I haven't been seeing this and that was the symptom we say before, i.e . some people saw it and some didn't. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: Accessing global domain information
Comments inline.
Thanks,
Raymond
- Original Message -
From: Simon Laws [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, August 09, 2007 3:46 PM
Subject: Re: Accessing global domain information
On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote:
On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Laws wrote:
I need some advice on the way the code is structures. In various
places in
the code I need to get at some information that logically belongs to
the sca
domain. For example,
CompositeWireBuilderImpl.connectComponentReferences()
Tries to resolve services. In the distributed case this resolution
may
validly fail and I need to ask the domain whether the service is
available
elsewhere. So I need access to some domain management services.
Ideally I
would like to have access to a domain interface but am unsure how to
plumb
it in as this kind of thing isn't generally available now. Anyone
care
to
offer some advice how I get at such an interface without breaking the
SPIs?
Thanks
Simon
WireCompositeBuilderImpl is not an SPI, so you can pass whatever you
want to its constructor without breaking any SPI.
But I have a preliminary question: Why do you need to ask the domain
(management service) about remote services at that specific point in
WireCompositeBuilderImpl?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien
I was thinking about this on the drive home. Just looking back at the
code
I had missed the important point that a reference target remains
unresolved
if the target component cannot be found. I could use this instead of the
actual service lookup at this point. The issue I have though is that the
CompositeWireBuilder dumps the bindings from the reference if it can't
find
a matching service/binding. This will be the case if the model for the
references service/binding is not read into the model for the current
node,
i.e. if the target component is not included in the current nodes
contributions.
Is it valid to only replace the current bindings with selectedBindings
if some selected bindings have actually be found?
Simon
Have been looking into this a little more and it seems that the list of
matched bindings takes into account the reference multiplicities and then
is
used during activation to create the runtime wires so we do have to be a
little cleverer in terms of creating a dummy resolved target to keep the
bindings in play.
Let's assume the reference is wired to a remote SCA service for this
discussion. For non-SCA services, it's simpler as we just have to pick a
binding locally for the reference and the binding URI will be good enough
for the routing.
There are two factors here:
1) What information is required from the service side for the reference side
to choose the right binding?
service: {service uri in the domain, a list of bindings} (I intentionally
skip the intent/policy stuff here). The key is that should be able to build
a call routing to this service endpoint.
2) When should we try to do the matching between the reference and the
service?
In some cases, the remote service information is not available when the
runtime wires are constructed. It means we have to defer the process when
the reference is used.
Anyone out there intimately familiar with the resolution process? What I
want to be able to do is have an sca binding (or any other binding for
that
matter) remain in place even in the case where the referenced target is
not
available in the local domain composite. Come runtime wire generation time
the binding itself can take responsibility for creating the correct
providers and invokers so that, assuming the referenced service is
remoteable, the request can be routed to the correct node.
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API
[ https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1375: --- Attachment: TUSCANY-1375.txt This patch privatizes the internal helper classes used in SDO for processing XML Schema, and removes their use from SCA. C++ SDO spec portability: C++ type definition API - Key: TUSCANY-1375 URL: https://issues.apache.org/jira/browse/TUSCANY-1375 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1375.txt The Tuscany C++ SDO implementation has off-spec type definition classes which are used by SCA. These should be removed or used only internally by the implementation until or unless they can be incorporated into the specification. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:45 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: C++ type definition API Hi, C++ Tuscany SDO extends type definition API with the off-spec classes PropertyDefinition and TypeDefinition, which are used externally by SCA. We also have found the C++ SDO specification type definition API lacking, and have added the Impl member function DataFactoryImpl::define(DataObjectPtr) to parallel the Java type definition API using DataObject's of Types commonj.sdo#Type and commonj.sdo#Property. Should a Jira be raised for these classes to be removed or kept internal to Tuscany C++ SDO? Is there API here that it would be good to present to the comittee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API
Hi, I have uploaded a patch for TUSCANY-1375. If it could be reviewed and applied that would be great. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 9:16 PM To: Michael Yoder Subject: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API [ https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1375: --- Attachment: TUSCANY-1375.txt This patch privatizes the internal helper classes used in SDO for processing XML Schema, and removes their use from SCA. C++ SDO spec portability: C++ type definition API - Key: TUSCANY-1375 URL: https://issues.apache.org/jira/browse/TUSCANY-1375 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1375.txt The Tuscany C++ SDO implementation has off-spec type definition classes which are used by SCA. These should be removed or used only internally by the implementation until or unless they can be incorporated into the specification. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:45 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: C++ type definition API Hi, C++ Tuscany SDO extends type definition API with the off-spec classes PropertyDefinition and TypeDefinition, which are used externally by SCA. We also have found the C++ SDO specification type definition API lacking, and have added the Impl member function DataFactoryImpl::define(DataObjectPtr) to parallel the Java type definition API using DataObject's of Types commonj.sdo#Type and commonj.sdo#Property. Should a Jira be raised for these classes to be removed or kept internal to Tuscany C++ SDO? Is there API here that it would be good to present to the comittee? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1465) Allow passing ResultDescriptor for dynamic Commands
[
https://issues.apache.org/jira/browse/TUSCANY-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518904
]
Amita Vadhavkar commented on TUSCANY-1465:
--
1) The way ResultDescriptor can be replaced on a Command is thru set method.
And in this, I am
replacing the resultSetShape for the Command (way to notify) as well. In
forming ResultSetShape,
the list gets sorted. So the sorting will happen once for each new call to
setResultDescriptor().
So, where will be the problem?
2) Done. (always return a new ArrayList from sorter)
3) ResultDescriptor is generated code, so directly can not add comparable
interface to it.
Another way will be extend ResultDescriptor implement Comparable in this
extension and
use this as wrapper over ResultDescriptor internal to DAS. But as the present
requirement
is just a simple sorting of index, avoided it and used directly
ResultDescriptor. Any suggestion?
4) renamed to set/getResultDescriptors(). Also added
addResultDescriptor(ResultDescriptor),
removeResultDescriptor(ResultDescriptor), and getResultDescriptor(int) and used
in a test case.
Please see below, if it looks OK, so I will submit patch based on this.
/**
* Add/replace based on index (=0)embedded in resultDescriptor else add at
end
* @param resultDescriptor
*/
void addResultDescriptor(ResultDescriptor resultDescriptor);
/**
* remove ResultDescriptor at given index(=0) and return same. If not
* present return null. For -ve index, return null
* @param index
* @return
*/
ResultDescriptor removeResultDescriptor(int index);
/**
* Remove resultDescriptor only if matched for index(=0), name, type,
schema
* name and table name and return same, else return null For -ve index,
ignore
* index and if unique match for rest of the attriutes, remove/return, if
multiple
* matches found, throw RuntimeException
* @param resultDescriptor
* @return
*/
ResultDescriptor removeResultDescriptor(ResultDescriptor resultDescriptor);
/**
* Return resultDescriptor if exact match for index(=0) found
* else return null;
*
* @param index
* @return
*/
ResultDescriptor getResultDescriptor(int index);
5) ListType , is JDK5 feature and recently we resolved JIRA-1237 to ensure
compatibility with JDK1.4
so avoided use of JDK5.
6) The test fail is the test case code problem ..please see..from 1464 last
comment -
{I took a clean base from trunk and applied 1464 and 1465 to it.
The problem was in the test cases of 1465 and I am creating new patch for it.
(As 1464 is now catching absence of PK from select, the 2 cases were failing in
1465, as in converter
column name should match table (dbms) column name and can not be aby arbitrary
names)
.}
Allow passing ResultDescriptor for dynamic Commands
---
Key: TUSCANY-1465
URL: https://issues.apache.org/jira/browse/TUSCANY-1465
Project: Tuscany
Issue Type: Bug
Components: Java DAS RDB
Affects Versions: Java-DAS-Next
Reporter: Amita Vadhavkar
Assignee: Amita Vadhavkar
Fix For: Java-DAS-Next
Attachments: 1465.patch
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19886.html
Action for the issue discussed in above mail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing global domain information
On 8/10/07, Raymond Feng [EMAIL PROTECTED] wrote:
Comments inline.
Thanks,
Raymond
- Original Message -
From: Simon Laws [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, August 09, 2007 3:46 PM
Subject: Re: Accessing global domain information
On 8/9/07, Simon Laws [EMAIL PROTECTED] wrote:
On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Laws wrote:
I need some advice on the way the code is structures. In various
places in
the code I need to get at some information that logically belongs
to
the sca
domain. For example,
CompositeWireBuilderImpl.connectComponentReferences()
Tries to resolve services. In the distributed case this resolution
may
validly fail and I need to ask the domain whether the service is
available
elsewhere. So I need access to some domain management services.
Ideally I
would like to have access to a domain interface but am unsure how
to
plumb
it in as this kind of thing isn't generally available now. Anyone
care
to
offer some advice how I get at such an interface without breaking
the
SPIs?
Thanks
Simon
WireCompositeBuilderImpl is not an SPI, so you can pass whatever you
want to its constructor without breaking any SPI.
But I have a preliminary question: Why do you need to ask the domain
(management service) about remote services at that specific point in
WireCompositeBuilderImpl?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sebastien
I was thinking about this on the drive home. Just looking back at the
code
I had missed the important point that a reference target remains
unresolved
if the target component cannot be found. I could use this instead of
the
actual service lookup at this point. The issue I have though is that
the
CompositeWireBuilder dumps the bindings from the reference if it can't
find
a matching service/binding. This will be the case if the model for the
references service/binding is not read into the model for the current
node,
i.e. if the target component is not included in the current nodes
contributions.
Is it valid to only replace the current bindings with
selectedBindings
if some selected bindings have actually be found?
Simon
Have been looking into this a little more and it seems that the list of
matched bindings takes into account the reference multiplicities and
then
is
used during activation to create the runtime wires so we do have to be a
little cleverer in terms of creating a dummy resolved target to keep the
bindings in play.
Let's assume the reference is wired to a remote SCA service for this
discussion. For non-SCA services, it's simpler as we just have to pick a
binding locally for the reference and the binding URI will be good enough
for the routing.
There are two factors here:
1) What information is required from the service side for the reference
side
to choose the right binding?
service: {service uri in the domain, a list of bindings} (I intentionally
skip the intent/policy stuff here). The key is that should be able to
build
a call routing to this service endpoint.
2) When should we try to do the matching between the reference and the
service?
In some cases, the remote service information is not available when the
runtime wires are constructed. It means we have to defer the process when
the reference is used.
Anyone out there intimately familiar with the resolution process? What I
want to be able to do is have an sca binding (or any other binding for
that
matter) remain in place even in the case where the referenced target is
not
available in the local domain composite. Come runtime wire generation
time
the binding itself can take responsibility for creating the correct
providers and invokers so that, assuming the referenced service is
remoteable, the request can be routed to the correct node.
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks Raymond, I'm with you there. I'm not sure whether you are agreeing
or disagreeing that maintaining the list of unresolved targets will be
problematic. I'm going ahead on the basis that we need to maintain the list,
i.e. I'll change
if (!targets.isEmpty() ) {
// Add all the effective bindings
to
if (!targets.isEmpty()
!selectedBindings.isEmpty()) {
// Add all the effective bindings
at the bottom of
CompositeWireBuilderImpl.connectComponentReferences()
and see how I get on. In this way the candidate bindings hang around until
later on in the case
[jira] Updated: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[
https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amita Vadhavkar updated TUSCANY-1464:
-
Attachment: 1464.patch
1)In case of if (columnName.indexOf(_ID) = 0), and indeed if column name in
database table is just _ID, then later in the same class,
String pkTableName = columnName.substring(0, columnName.indexOf(_ID));
will give null value to pkTableName and so List pkTableProperties = (List)
tableToPropertyMap.get(pkTableName); will have null list pkTableProperties.
So, if ((pkTableProperties != null) (pkTableProperties.contains(ID))) {
configWrapper.addImpliedRelationship(pkTableName, fkTableName,
columnName);
}
will do nothing as first condition will fail.
So, I guess we are safe here. As anyways, COC will not be able to do anything
with a column _ID
___
2)case sensitivity, this is a good point, as just below this code, we are
liberal about it for detecting COC based PK (allow any case) and as you said,
for FK purpose, we are not allowing only _ID. I can fix this, even though this
is not part of the problem statement of this patch, in
ResultMetadata. (Our documentation does not talk anything about case, but at
least
we should treat both PK and FK in same manner, so if PK is allowed id,Id,iD,
ID, same should be with FK)
___
3)
if (!rawDataFromRow.hasValidPrimaryKey() ||
(rawDataFromRow.hasNullPrimaryKey() !rawDataFromRow.isTableEmpty()))
The above check is for case, when any one PK in table has null Data , but there
are other not null data columns in the row, this should be exception case
-
if (tableObject == null
rawDataFromRow.getPrimaryKeyValues() != null
!rawDataFromRow.getPrimaryKeyValues().contains(null)
rawDataFromRow.getPrimaryKeyValues().size() 0)
The above check, it can be modified/simplified as below, as
getPrimaryKeyValues() can never be null (see constructor of TableData) and
with new hasNullPrimaryKey() check, PrimaryKeyValues will not contain null and
as hasValidPK is true, getPrimaryKeyValues().size() will be 0
if (tableObject == null
!rawDataFromRow.hasNullPrimaryKey())
___
4) I took a clean base from trunk and applied 1464 and 1465 to it.
The problem was in the test cases of 1465 and I am creating new patch for it.
(As 1464 is now catching absence of PK from select, the 2 cases were failing in
1465, as in converter column name should match table (dbms) column name and can
not be aby arbitrary names)
Please see the 1464.patch dated Aug 10 for fixes of 2) and 3) above.
Wrong query results when SELECT misses PKs
--
Key: TUSCANY-1464
URL: https://issues.apache.org/jira/browse/TUSCANY-1464
Project: Tuscany
Issue Type: Bug
Components: Java DAS RDB
Affects Versions: Java-DAS-Next
Reporter: Amita Vadhavkar
Assignee: Amita Vadhavkar
Fix For: Java-DAS-Next
Attachments: 1464.patch, 1464.patch, 1464.patch, 1464.patch
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html
Fix the bug uncovered in above mail discussion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New dependencies on binding-sca? was: svn commit: r563787 - in /incubator/tuscany/java/sca/modules: binding-ejb/pom.xml core-spring/pom.xml host-embedded/pom.xml
On 8/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: The binding-ejb one was a mistake host-embedded/ReallySmallRuntimeBuilder creates a SCABindingProcessor I'll go fix the first one and test against the latest code Thanks Ah OK. If you're talking about this: SCABindingProcessor scaBindingProcessor = new SCABindingProcessor(assemblyFactory, policyFactory, scaBindingFactory); StAXArtifactProcessorExtensionPoint processors = registry.getExtensionPoint(StAXArtifactProcessorExtensionPoint.class); processors.addArtifactProcessor(scaBindingProcessor); then, as part of factoring the SCA binding out, this initialization should move the binding-sca module, right? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Actually Sebastien, you are right (no change there ;-). Now that the binding-sca-xml module is loaded via the services mechanism this manual registration is not required. I'll go remove it. Thanks for spotting that Smon
