Trouble with aggregating definitions.xml in distro
Hi, I have accidentally deleted this thread from my mail box. I am not sure how this happened when I save a draft of my reply. So, continuing with that thread... 1) Sebastien suggested that I check out a couple of scenarios merging definitions.xml files using the XMLAppendingTransformer. As suspected by him, the transformer messes up namespaces. 2) Moving to the Provider option, I wanted to write a provider that reads the definitions.xml document and returns the model. With this I had quite a bit of trouble placing this provider - it could best be in the definitions-xml module. But then to instantiate the SCADefnDocProcessor I need the STaxProcessorExtensionPoint. I could have this extracted in the Provider if I passed around the ExtensionPointRegistry to the Provider. But the ExtensionPointRegistry interface is in the core module. So what seemed best as of now is only a SCADefinitionsFileLocationProvider thro which the various modules can return the path to the definitions.xml file within them. Meanwhile, I have written a simple shade transformer that will aggregate the definitions.xml and add a wrapper element tuscany:definitions in our distribution bundle. I have added some code in the SCADefinitionsDocProcessor to deal with this wrapper element. I am in the process of checking this out in a full distro and then will commit. Thanks - Venkat
Re: Trouble with aggregating definitions.xml in distro
Hi, I verified the distro and it seems like the transformer is working. So I have checked in the transformer under sca\tools\maven\maven-definitions and have also checked in the changes that I have done to distribution\bundle\pom.xml Thanks - Venkat On Sun, Mar 2, 2008 at 12:22 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have accidentally deleted this thread from my mail box. I am not sure how this happened when I save a draft of my reply. So, continuing with that thread... 1) Sebastien suggested that I check out a couple of scenarios merging definitions.xml files using the XMLAppendingTransformer. As suspected by him, the transformer messes up namespaces. 2) Moving to the Provider option, I wanted to write a provider that reads the definitions.xml document and returns the model. With this I had quite a bit of trouble placing this provider - it could best be in the definitions-xml module. But then to instantiate the SCADefnDocProcessor I need the STaxProcessorExtensionPoint. I could have this extracted in the Provider if I passed around the ExtensionPointRegistry to the Provider. But the ExtensionPointRegistry interface is in the core module. So what seemed best as of now is only a SCADefinitionsFileLocationProvider thro which the various modules can return the path to the definitions.xml file within them. Meanwhile, I have written a simple shade transformer that will aggregate the definitions.xml and add a wrapper element tuscany:definitions in our distribution bundle. I have added some code in the SCADefinitionsDocProcessor to deal with this wrapper element. I am in the process of checking this out in a full distro and then will commit. Thanks - Venkat
Re: Trouble with aggregating definitions.xml in distro
snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon
Re: Trouble with aggregating definitions.xml in distro
Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon
Re: Trouble with aggregating definitions.xml in distro
On Fri, Feb 29, 2008 at 11:58 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon So why do we specify transformers for some things and not for others. All the transformers specified are AppendingTransformer which I assume is what is appending the definitions.xml files together by default. Simon
Re: Trouble with aggregating definitions.xml in distro
Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. Ant, thanks for point me to this. :) - Venkat On Fri, Feb 29, 2008 at 5:52 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 11:58 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon So why do we specify transformers for some things and not for others. All the transformers specified are AppendingTransformer which I assume is what is appending the definitions.xml files together by default. Simon
Re: Trouble with aggregating definitions.xml in distro
I only pointed at that as an example of how to write a transformer, I hadn't realized it did what we needed either :) ...ant On Fri, Feb 29, 2008 at 12:52 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. Ant, thanks for point me to this. :) - Venkat On Fri, Feb 29, 2008 at 5:52 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 11:58 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon So why do we specify transformers for some things and not for others. All the transformers specified are AppendingTransformer which I assume is what is appending the definitions.xml files together by default. Simon
Re: Trouble with aggregating definitions.xml in distro
On Fri, Feb 29, 2008 at 12:22 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 11:58 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon So why do we specify transformers for some things and not for others. All the transformers specified are AppendingTransformer which I assume is what is appending the definitions.xml files together by default. Simon I'm not sure i understand what you're asking but here's what i understand happens: The shade plugin is configured in the distribution/bundle/pom.xml. In there we say set the shadedGroupFilter as org.apache.tuscany so all the dependencies in that group get processed by the plugin and by default it will just take all the files in those resources and munged them into the one jar built for the bundle module. That works fine for most files as they have unique names but for files that are duplicated the default will i guess be that the last one processed overwrites the others so all the contents of all the other files gets lost. To fix that we configure a transformer that deals with what to do. For example, we use the AppendingTransformer for all our meta-inf/services files and that just takes the contents of the named file for each it finds it appends the contents into a single file. That works fine for text files but for xml files like definitions.xml there needs to be a way to merge the file contents not to just append the contents at the end. ...ant
Re: Trouble with aggregating definitions.xml in distro
Venkata Krishnan wrote: Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. If I understand correctly, it looks like you're now going away from the solution we discussed before in this thread (and which was going to work), and are going to use the above shade plugin transformer to merge multiple definitions.xml files. I'm OK with that if you make it really work, but at first sight the logic in the XmlAppendingTransformer looks a little 'fragile' :) Can you please try two things? - two definitions.xml files that use different namespaces for their policySets? - two definitions.xml files that use a namespace prefix 'policy' mapped to two different namespaces? If it works, then, great! If it doesn't work you'll just need to write your own shade transformer, and/or contribute a fix to Shade. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
My understanding is that there are two different issues here: 1) Where definitions.xml should be packaged in a SCA contribution? 2) How do we merge multiple definitions.xml when we build the all-in-one binary distro? So I assume Sebastien's proposal is for 1) and the maven/shade discussion is for 2). Am I right? If yes, we should have two separate threads as it becomes confusing. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, February 29, 2008 8:17 AM To: tuscany-dev@ws.apache.org Subject: Re: Trouble with aggregating definitions.xml in distro Venkata Krishnan wrote: Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. If I understand correctly, it looks like you're now going away from the solution we discussed before in this thread (and which was going to work), and are going to use the above shade plugin transformer to merge multiple definitions.xml files. I'm OK with that if you make it really work, but at first sight the logic in the XmlAppendingTransformer looks a little 'fragile' :) Can you please try two things? - two definitions.xml files that use different namespaces for their policySets? - two definitions.xml files that use a namespace prefix 'policy' mapped to two different namespaces? If it works, then, great! If it doesn't work you'll just need to write your own shade transformer, and/or contribute a fix to Shade. -- 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: Trouble with aggregating definitions.xml in distro
Jean-Sebastien Delfino wrote: Raymond Feng wrote: My understanding is that there are two different issues here: 1) Where definitions.xml should be packaged in a SCA contribution? 2) How do we merge multiple definitions.xml when we build the all-in-one binary distro? So I assume Sebastien's proposal is for 1) and the maven/shade discussion is for 2). Am I right? If yes, we should have two separate threads as it becomes confusing. My proposal handled 1 (not forcing definitions.xml to be in a fixed location in the JAR) and 2 (as it didn't require any XML merging). My latest comments below in this email apply to 2 (I'm basically saying if you really want to do this XML merging, then make sure it works). I'm branching a new thread for 1 :) Here's your new thread, starting with two statements: I think that contributors should be able to place their definitions.xml files wherever they want in an SCA contribution JAR. I also think that we'll have to support external policy attachments at some point (see the Open CSA POLICY-15 JIRA already discussed on tuscany-dev on other threads), and these policy attachments won't be in a fixed place in the contributions either. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Raymond Feng wrote: My understanding is that there are two different issues here: 1) Where definitions.xml should be packaged in a SCA contribution? 2) How do we merge multiple definitions.xml when we build the all-in-one binary distro? So I assume Sebastien's proposal is for 1) and the maven/shade discussion is for 2). Am I right? If yes, we should have two separate threads as it becomes confusing. My proposal handled 1 (not forcing definitions.xml to be in a fixed location in the JAR) and 2 (as it didn't require any XML merging). My latest comments below in this email apply to 2 (I'm basically saying if you really want to do this XML merging, then make sure it works). I'm branching a new thread for 1 :) -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, February 29, 2008 8:17 AM To: tuscany-dev@ws.apache.org Subject: Re: Trouble with aggregating definitions.xml in distro Venkata Krishnan wrote: Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. If I understand correctly, it looks like you're now going away from the solution we discussed before in this thread (and which was going to work), and are going to use the above shade plugin transformer to merge multiple definitions.xml files. I'm OK with that if you make it really work, but at first sight the logic in the XmlAppendingTransformer looks a little 'fragile' :) Can you please try two things? - two definitions.xml files that use different namespaces for their policySets? - two definitions.xml files that use a namespace prefix 'policy' mapped to two different namespaces? If it works, then, great! If it doesn't work you'll just need to write your own shade transformer, and/or contribute a fix to Shade. -- 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] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Location of policy definitions in SCA contributions: was: Trouble with aggregating definitions.xml in distro
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Raymond Feng wrote: My understanding is that there are two different issues here: 1) Where definitions.xml should be packaged in a SCA contribution? 2) How do we merge multiple definitions.xml when we build the all-in-one binary distro? So I assume Sebastien's proposal is for 1) and the maven/shade discussion is for 2). Am I right? If yes, we should have two separate threads as it becomes confusing. My proposal handled 1 (not forcing definitions.xml to be in a fixed location in the JAR) and 2 (as it didn't require any XML merging). My latest comments below in this email apply to 2 (I'm basically saying if you really want to do this XML merging, then make sure it works). I'm branching a new thread for 1 :) Here's your new thread, starting with two statements: I think that contributors should be able to place their definitions.xml files wherever they want in an SCA contribution JAR. I also think that we'll have to support external policy attachments at some point (see the Open CSA POLICY-15 JIRA already discussed on tuscany-dev on other threads), and these policy attachments won't be in a fixed place in the contributions either. Sorry, pressed send before updating the subject :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Hi, Alright, point taken :). I am going to resolve this with the provider option and also clean up based on your suggestions. Thanks. - Venkat On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, Thanks for the suggestion. Going by the ProviderExtesionPoint way... - first I'd prefer load the definitions.xml instead of creating programmatically so that we don't have to touch the code for every change to the definitions. Definitions.xml is code, it's just XML code and not Java code. The choice really depends on what you have in your policy definitions, and which one is simpler in each extension case: SCADefinitions definition = new SCADefinitionsImpl(); SCABindingType bindingType = new SCABindingTypeImpl(); definition.getBindingTypes().add(bindingType); or sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; bindingType.../ /sca:definitions BTW I noticed that there are two copies of BindingTypeImpl in the policy and definitions modules, but no factories for these policy model objects (forcing code to depend on the model implementation classes). Also I think it would be simpler to regroup the definitions model and the policies model in a single module. - every module that has its own definitions.xml must define it in a unique path so that the file does not get lost when we are making the tuscany-sca-all jar file in the distro. So, given that every module HAS to define its definitions.xml in a unique path I am wondering if it would just enuf for each module then to just about publish the path for this in a file similar to the ones in META-INF/services. So even when this file is aggregated by the shade plugin when making the tuscany-sca-all jar, we still have the location paths of all definitions.xml. Is this a viable alternative ? It is a viable alternative but adds yet another mechanism to contribute pieces of extensions. I think it's better to stick to a single consistent mechanism. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
I also quiet liked being able to define these in definitions.xml files instead of programmatically, is that still going to be an option? Seems a shame if we have to give that up just because of a problem with our build assembly. ...ant On Thu, Feb 28, 2008 at 9:27 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Alright, point taken :). I am going to resolve this with the provider option and also clean up based on your suggestions. Thanks. - Venkat On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, Thanks for the suggestion. Going by the ProviderExtesionPoint way... - first I'd prefer load the definitions.xml instead of creating programmatically so that we don't have to touch the code for every change to the definitions. Definitions.xml is code, it's just XML code and not Java code. The choice really depends on what you have in your policy definitions, and which one is simpler in each extension case: SCADefinitions definition = new SCADefinitionsImpl(); SCABindingType bindingType = new SCABindingTypeImpl(); definition.getBindingTypes().add(bindingType); or sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; bindingType.../ /sca:definitions BTW I noticed that there are two copies of BindingTypeImpl in the policy and definitions modules, but no factories for these policy model objects (forcing code to depend on the model implementation classes). Also I think it would be simpler to regroup the definitions model and the policies model in a single module. - every module that has its own definitions.xml must define it in a unique path so that the file does not get lost when we are making the tuscany-sca-all jar file in the distro. So, given that every module HAS to define its definitions.xml in a unique path I am wondering if it would just enuf for each module then to just about publish the path for this in a file similar to the ones in META-INF/services. So even when this file is aggregated by the shade plugin when making the tuscany-sca-all jar, we still have the location paths of all definitions.xml. Is this a viable alternative ? It is a viable alternative but adds yet another mechanism to contribute pieces of extensions. I think it's better to stick to a single consistent mechanism. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Hi, This is certainly a good option. We just about have to do two simple things in this transformer. - Create a definitions.xml file with the xml declaration and sca:definitions start element - The for every definitions.xml file read, skip upto the sca: definitions.xml and copy everything else upto the /sca:definitions element - Finally end this aggregated file with /sca:definitions Let me look up the link you provided to see if this is quickly workable. Thanks. - Venkat On Fri, Feb 29, 2008 at 1:09 PM, ant elder [EMAIL PROTECTED] wrote: Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer You can see the src of other Shade plugins and they're not too complicated - https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.java ...ant On Fri, Feb 29, 2008 at 6:35 AM, ant elder [EMAIL PROTECTED] wrote: I also quiet liked being able to define these in definitions.xml files instead of programmatically, is that still going to be an option? Seems a shame if we have to give that up just because of a problem with our build assembly. ...ant On Thu, Feb 28, 2008 at 9:27 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Alright, point taken :). I am going to resolve this with the provider option and also clean up based on your suggestions. Thanks. - Venkat On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, Thanks for the suggestion. Going by the ProviderExtesionPoint way... - first I'd prefer load the definitions.xml instead of creating programmatically so that we don't have to touch the code for every change to the definitions. Definitions.xml is code, it's just XML code and not Java code. The choice really depends on what you have in your policy definitions, and which one is simpler in each extension case: SCADefinitions definition = new SCADefinitionsImpl(); SCABindingType bindingType = new SCABindingTypeImpl(); definition.getBindingTypes().add(bindingType); or sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; bindingType.../ /sca:definitions BTW I noticed that there are two copies of BindingTypeImpl in the policy and definitions modules, but no factories for these policy model objects (forcing code to depend on the model implementation classes). Also I think it would be simpler to regroup the definitions model and the policies model in a single module. - every module that has its own definitions.xml must define it in a unique path so that the file does not get lost when we are making the tuscany-sca-all jar file in the distro. So, given that every module HAS to define its definitions.xml in a unique path I am wondering if it would just enuf for each module then to just about publish the path for this in a file similar to the ones in META-INF/services. So even when this file is aggregated by the shade plugin when making the tuscany-sca-all jar, we still have the location paths of all definitions.xml. Is this a viable alternative ? It is a viable alternative but adds yet another mechanism to contribute pieces of extensions. I think it's better to stick to a single consistent mechanism. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Hi Ant, Thats going to remain. The providers that I have in mind will just about load the definitions.xml file using the DocProcessor and hand the resulting model out. If we do end up with a need to create the model programmatically then its upto the provider that gets to be written at that time. Thanks - Venkat On Fri, Feb 29, 2008 at 12:05 PM, ant elder [EMAIL PROTECTED] wrote: I also quiet liked being able to define these in definitions.xml files instead of programmatically, is that still going to be an option? Seems a shame if we have to give that up just because of a problem with our build assembly. ...ant On Thu, Feb 28, 2008 at 9:27 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Alright, point taken :). I am going to resolve this with the provider option and also clean up based on your suggestions. Thanks. - Venkat On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, Thanks for the suggestion. Going by the ProviderExtesionPoint way... - first I'd prefer load the definitions.xml instead of creating programmatically so that we don't have to touch the code for every change to the definitions. Definitions.xml is code, it's just XML code and not Java code. The choice really depends on what you have in your policy definitions, and which one is simpler in each extension case: SCADefinitions definition = new SCADefinitionsImpl(); SCABindingType bindingType = new SCABindingTypeImpl(); definition.getBindingTypes().add(bindingType); or sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; bindingType.../ /sca:definitions BTW I noticed that there are two copies of BindingTypeImpl in the policy and definitions modules, but no factories for these policy model objects (forcing code to depend on the model implementation classes). Also I think it would be simpler to regroup the definitions model and the policies model in a single module. - every module that has its own definitions.xml must define it in a unique path so that the file does not get lost when we are making the tuscany-sca-all jar file in the distro. So, given that every module HAS to define its definitions.xml in a unique path I am wondering if it would just enuf for each module then to just about publish the path for this in a file similar to the ones in META-INF/services. So even when this file is aggregated by the shade plugin when making the tuscany-sca-all jar, we still have the location paths of all definitions.xml. Is this a viable alternative ? It is a viable alternative but adds yet another mechanism to contribute pieces of extensions. I think it's better to stick to a single consistent mechanism. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer You can see the src of other Shade plugins and they're not too complicated - https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.java ...ant On Fri, Feb 29, 2008 at 6:35 AM, ant elder [EMAIL PROTECTED] wrote: I also quiet liked being able to define these in definitions.xml files instead of programmatically, is that still going to be an option? Seems a shame if we have to give that up just because of a problem with our build assembly. ...ant On Thu, Feb 28, 2008 at 9:27 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Alright, point taken :). I am going to resolve this with the provider option and also clean up based on your suggestions. Thanks. - Venkat On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Hi Sebastien, Thanks for the suggestion. Going by the ProviderExtesionPoint way... - first I'd prefer load the definitions.xml instead of creating programmatically so that we don't have to touch the code for every change to the definitions. Definitions.xml is code, it's just XML code and not Java code. The choice really depends on what you have in your policy definitions, and which one is simpler in each extension case: SCADefinitions definition = new SCADefinitionsImpl(); SCABindingType bindingType = new SCABindingTypeImpl(); definition.getBindingTypes().add(bindingType); or sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; bindingType.../ /sca:definitions BTW I noticed that there are two copies of BindingTypeImpl in the policy and definitions modules, but no factories for these policy model objects (forcing code to depend on the model implementation classes). Also I think it would be simpler to regroup the definitions model and the policies model in a single module. - every module that has its own definitions.xml must define it in a unique path so that the file does not get lost when we are making the tuscany-sca-all jar file in the distro. So, given that every module HAS to define its definitions.xml in a unique path I am wondering if it would just enuf for each module then to just about publish the path for this in a file similar to the ones in META-INF/services. So even when this file is aggregated by the shade plugin when making the tuscany-sca-all jar, we still have the location paths of all definitions.xml. Is this a viable alternative ? It is a viable alternative but adds yet another mechanism to contribute pieces of extensions. I think it's better to stick to a single consistent mechanism. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Venkata Krishnan wrote: Hi Sebastien, Thanks for the suggestion. Going by the ProviderExtesionPoint way... - first I'd prefer load the definitions.xml instead of creating programmatically so that we don't have to touch the code for every change to the definitions. Definitions.xml is code, it's just XML code and not Java code. The choice really depends on what you have in your policy definitions, and which one is simpler in each extension case: SCADefinitions definition = new SCADefinitionsImpl(); SCABindingType bindingType = new SCABindingTypeImpl(); definition.getBindingTypes().add(bindingType); or sca:definitions xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.osoa.org/xmlns/sca/1.0; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; bindingType.../ /sca:definitions BTW I noticed that there are two copies of BindingTypeImpl in the policy and definitions modules, but no factories for these policy model objects (forcing code to depend on the model implementation classes). Also I think it would be simpler to regroup the definitions model and the policies model in a single module. - every module that has its own definitions.xml must define it in a unique path so that the file does not get lost when we are making the tuscany-sca-all jar file in the distro. So, given that every module HAS to define its definitions.xml in a unique path I am wondering if it would just enuf for each module then to just about publish the path for this in a file similar to the ones in META-INF/services. So even when this file is aggregated by the shade plugin when making the tuscany-sca-all jar, we still have the location paths of all definitions.xml. Is this a viable alternative ? It is a viable alternative but adds yet another mechanism to contribute pieces of extensions. I think it's better to stick to a single consistent mechanism. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Hi, First, thanks a ton for all the comments / opinions. I agree, META-INF/services is not the right place for this. I suppose META-INF is ok because the definitions.xml does contain meta-data about binding and implementation types. For example, the definitions.xml in the binding.ws.axis module will define a binding type that will describe the mayProvides and alwaysProvides intents. Or, isn't this metadata at all ? Yes, the point is that definitions.xml can be a part of any contribution and hence can be anywhere. Infact, the samples / demos have the definitions.xml in the resources directory only. The issue is with the definitons.xml in the tuscany modules. They need to be loaded when the runtime is started and hence need to be explicitly searched for and loaded. Whereas in the case of contributions, the definitions.xml get processed like any other artifact in the contribution. So, the bottom line is how do we identify these various definitions.xml in the various tuscany modules ? Thanks - Venkat On Tue, Feb 26, 2008 at 4:55 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: ... For example, could you use something like policy-logging\src\main\resources\org\apache\tuscany\policy\logging\definitions.xml What you're proposing makes sense to me: let's put definitions.xml file in logically named folders. I'm not sure that we even need a naming convention like org/apache/tuscany/module-name. Definitions.xml files live in SCA contributions and the Tuscany contribution code should be able to find them wherever they are in the contribution (like we find WSDLs, XSDs, composite files etc). -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Hi Sebastien,
Thanks for the suggestion. Going by the ProviderExtesionPoint way...
- first I'd prefer load the definitions.xml instead of creating
programmatically so that we don't have to touch the code for every change to
the definitions.
- every module that has its own definitions.xml must define it in a unique
path so that the file does not get lost when we are making the
tuscany-sca-all jar file in the distro.
So, given that every module HAS to define its definitions.xml in a unique
path I am wondering if it would just enuf for each module then to just about
publish the path for this in a file similar to the ones in
META-INF/services. So even when this file is aggregated by the shade plugin
when making the tuscany-sca-all jar, we still have the location paths of all
definitions.xml. Is this a viable alternative ?
Thanks
- Venkat
On Tue, Feb 26, 2008 at 8:48 PM, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:
Venkata Krishnan wrote:
Hi,
First, thanks a ton for all the comments / opinions.
I agree, META-INF/services is not the right place for this. I suppose
META-INF is ok because the definitions.xml does contain meta-data about
binding and implementation types. For example, the definitions.xml in
the
binding.ws.axis module will define a binding type that will describe the
mayProvides and alwaysProvides intents. Or, isn't this metadata at all
?
Yes, the point is that definitions.xml can be a part of any contribution
and
hence can be anywhere. Infact, the samples / demos have the
definitions.xml in the resources directory only.
The issue is with the definitons.xml in the tuscany modules. They need
to
be loaded when the runtime is started and hence need to be explicitly
searched for and loaded. Whereas in the case of contributions, the
definitions.xml get processed like any other artifact in the
contribution.
So, the bottom line is how do we identify these various definitions.xmlin
the various tuscany modules ?
I think the main issue is that you're trying to use an SCA contribution
based mechanism in non SCA contributions.
I think we should do the following:
- Definitions.xml is metadata, so is .composite, .componentType, etc,
none of them should be under META-INF, we should give a good example in
our own code, i.e. place them out of META-INF.
- Either use proper SCA contributions and the capability of the Tuscany
runtime to load them, and use definitions.xml files in these
contributions.
- Or, if these are not SCA contributions, use the extension point
mechanism we're using everywhere else. For example do something similar
to what we do for XML schemas used for validation, as follows...
a) define a DefinitionProviderExtensionPoint
interface DefinitionProviderExtensionPoint {
void addDefinitionProviderExtensionPoint(DefinitionProvider provider);
void removeDefinitionProviderExtensionPoint(
DefinitionProvider provider);
}
b) define a DefinitionProvider
interface DefinitionProvider {
Definition getDefinition();
}
c) register the DefinitionProviders as we register all extensions.
d) in a DefinitionProvider load definitions.xml from wherever you want
and however, or even better just create that model in code.
class MyDefinitionProvider implements DefinitionProvider {
Definition getDefinition() {
// load or create the Definition model
...
return definition;
}
}
Hope this helps.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
On Mon, Feb 25, 2008 at 1:12 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have been working on modifying the existing bigbank demo to include security (things that have been tried and working in the securie-bigbank demo). All seemed fine, until I tried the modified bigbank demo from a distribution. One of things we do now is aggregating the various definitions.xml in META-INF/services since we now allow various modules and contributions to have their own definitions.xml if needs be. In a distro all of these definitions.xml are aggregated into a single file using the shade transformer. I end up with a definitions.xml that has multiple sca:definitions elements but no root. Also there seems to be multiple 'xml' declarations - ?xml version=1.0 encoding=ASCII?. All these creates trouble for the XMLStreamReader. At the present moment I am thinking of the following : 1) In the Definitions Document Processor prepend and append the xml with dummy elements so that there is a root element 2) Either strip all the duplicate xml declarations when doing step (1) or go an manually delete this in all the definitions.xml in our modules Though most of it has been tried and works, I feel its like some 'trick code' and could give us troubles in maintainability. Does anybody have a better idea to deal with this ? Thanks. - Venkat Hi Venkat Can I just clarify that you are saying that you are having problems because of the way that the shader plugin is aggregating the definitions.xml files that now appear in various extension modules, e.g. binding-ws-axis2, poilcy-logging et. and that this is not specifically related to the bingbank demo or to the way that Tuscany subsequently aggregates the contents is finds in definitions.xml files. Does definitions.xml have to appear in META-INF/services. Could we, for example, further qualify the definitions.xml file by putting it in a directory that represents the name of the extension module to which it refers? Or does that make it difficult to pick them up generically? Simon
Re: Trouble with aggregating definitions.xml in distro
Hi Simon, Thanks for responding. Please see my comments inline. - Venkat On Mon, Feb 25, 2008 at 6:36 PM, Simon Laws [EMAIL PROTECTED] wrote: On Mon, Feb 25, 2008 at 1:12 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have been working on modifying the existing bigbank demo to include security (things that have been tried and working in the securie-bigbank demo). All seemed fine, until I tried the modified bigbank demo from a distribution. One of things we do now is aggregating the various definitions.xml in META-INF/services since we now allow various modules and contributions to have their own definitions.xml if needs be. In a distro all of these definitions.xml are aggregated into a single file using the shade transformer. I end up with a definitions.xml that has multiple sca:definitions elements but no root. Also there seems to be multiple 'xml' declarations - ?xml version=1.0 encoding=ASCII?. All these creates trouble for the XMLStreamReader. At the present moment I am thinking of the following : 1) In the Definitions Document Processor prepend and append the xml with dummy elements so that there is a root element 2) Either strip all the duplicate xml declarations when doing step (1) or go an manually delete this in all the definitions.xml in our modules Though most of it has been tried and works, I feel its like some 'trick code' and could give us troubles in maintainability. Does anybody have a better idea to deal with this ? Thanks. - Venkat Hi Venkat Can I just clarify that you are saying that you are having problems because of the way that the shader plugin is aggregating the definitions.xml files that now appear in various extension modules, e.g. binding-ws-axis2, poilcy-logging et. and that this is not specifically related to the bingbank demo or to the way that Tuscany subsequently aggregates the contents is finds in definitions.xml files. Yes I am talking about aggregating the definitions.xml files from the various modules. The shade plugin is working alright. This is not specific to the bigbank demo - more a general problem. I think I have been caught on wrong foot trying to use this META-INF/services aggregation for the definitions.xml file as well. :( Does definitions.xml have to appear in META-INF/services. Could we, for example, further qualify the definitions.xml file by putting it in a directory that represents the name of the extension module to which it refers? Or does that make it difficult to pick them up generically? I did think of including the extension module where it is defined, but then we must enlist all extension modules then or in otherwords enlist the locations of these definitions.xml file somewhere. Am not sure if we can search for resources using regular expressions - something like /*/definitions.xml. Thanks. Simon
Re: Trouble with aggregating definitions.xml in distro
Raymond Feng wrote: Why don't we use META-INF/definitions.xml? META-INF/services folder is for the java service provider pattern. ... We don't even need the META-INF/ part, IMO definitions.xml is a development artifact like .java, .composite, .wsdl, .xsd and doesn't need to be in META-INF. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
I was trying to follow the META-INF/sca-contribution.xml pattern as the file name is defined by the spec and we only have at most one definitions.xml in the same contribution. For .java, .compostem .wsdl, and .xsd artifacts, they could have different artifact names, such as A.java and B.java. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, February 25, 2008 10:00 AM Subject: Re: Trouble with aggregating definitions.xml in distro Raymond Feng wrote: Why don't we use META-INF/definitions.xml? META-INF/services folder is for the java service provider pattern. ... We don't even need the META-INF/ part, IMO definitions.xml is a development artifact like .java, .composite, .wsdl, .xsd and doesn't need to be in META-INF. -- 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: Trouble with aggregating definitions.xml in distro
So, just to be clear again... Hi Venkat Can I just clarify that you are saying that you are having problems because of the way that the shader plugin is aggregating the definitions.xmlfiles that now appear in various extension modules, e.g. binding-ws-axis2, poilcy-logging et. and that this is not specifically related to the bingbank demo or to the way that Tuscany subsequently aggregates the contents is finds in definitions.xml files. Yes I am talking about aggregating the definitions.xml files from the various modules. The shade plugin is working alright. In as much that the shade plugin is identifying that there are multiple files with the same name, definitions.xml in this case, and is blindly concatenating them? This is not specific to the bigbank demo - more a general problem. I think I have been caught on wrong foot trying to use this META-INF/services aggregation for the definitions.xml file as well. :( I agree that having all of the files called definitions.xml located in the same logical place on the classpath is causing problems and also that the choice of META-INF/services doesn't seem to be right. Don't think these two things are related though. Does definitions.xml have to appear in META-INF/services. Could we, for example, further qualify the definitions.xml file by putting it in a directory that represents the name of the extension module to which it refers? Or does that make it difficult to pick them up generically? I did think of including the extension module where it is defined, but then we must enlist all extension modules then or in otherwords enlist the locations of these definitions.xml file somewhere. Am not sure if we can search for resources using regular expressions - something like /*/definitions.xml. For example, could you use something like policy-logging\src\main\resources\org\apache\tuscany\policy\logging\definitions.xml Thanks. Simon
Re: Trouble with aggregating definitions.xml in distro
Raymond Feng wrote: I was trying to follow the META-INF/sca-contribution.xml pattern as the file name is defined by the spec and we only have at most one definitions.xml in the same contribution. For .java, .compostem .wsdl, and .xsd artifacts, they could have different artifact names, such as A.java and B.java. There is a difference though. META-INF/sca-contribution.xml is metadata about the contribution, definitions.xml is not. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Simon Laws wrote: ... For example, could you use something like policy-logging\src\main\resources\org\apache\tuscany\policy\logging\definitions.xml What you're proposing makes sense to me: let's put definitions.xml file in logically named folders. I'm not sure that we even need a naming convention like org/apache/tuscany/module-name. Definitions.xml files live in SCA contributions and the Tuscany contribution code should be able to find them wherever they are in the contribution (like we find WSDLs, XSDs, composite files etc). -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Trouble with aggregating definitions.xml in distro
Hi, I have been working on modifying the existing bigbank demo to include security (things that have been tried and working in the securie-bigbank demo). All seemed fine, until I tried the modified bigbank demo from a distribution. One of things we do now is aggregating the various definitions.xml in META-INF/services since we now allow various modules and contributions to have their own definitions.xml if needs be. In a distro all of these definitions.xml are aggregated into a single file using the shade transformer. I end up with a definitions.xml that has multiple sca:definitions elements but no root. Also there seems to be multiple 'xml' declarations - ?xml version=1.0 encoding=ASCII?. All these creates trouble for the XMLStreamReader. At the present moment I am thinking of the following : 1) In the Definitions Document Processor prepend and append the xml with dummy elements so that there is a root element 2) Either strip all the duplicate xml declarations when doing step (1) or go an manually delete this in all the definitions.xml in our modules Though most of it has been tried and works, I feel its like some 'trick code' and could give us troubles in maintainability. Does anybody have a better idea to deal with this ? Thanks. - Venkat
