Re: [DISCUSS] Declaring extensions as being available in the domain
Yes, I think each of those specific ones should be allowed to have its own definitions.xml and bindingType info simply because each of them could have their own list what intents it provides inherently. Maybe I am missing the alternative here. - Venkat On Tue, May 13, 2008 at 2:54 AM, Raymond Feng [EMAIL PROTECTED] wrote: I share the same concerns as Sebastien raised. Mixing the policy definitions with tuscany runtime extensions in one file doesn't seem to be right. For example, we could have two tuscany extensions to support binding.ws, one is based on Axis2 while the other one is based on CXF. With the current approach, we will see three files: definitions.xml for binding.ws bindingType which is independent of the underlying ws stack two META-INF/services/... files, one for binding-ws-axis2 and the other for binding-ws-cxf With the new proposal, I cannot achieve the pluggability unless we duplicate the bindingType info for binding.ws in two definitions.xml. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:56 PM To: tuscany-dev@ws.apache.org Subject: Re: [DISCUSS] Declaring extensions as being available in the domain Venkata Krishnan wrote: Hi Ant, Yes, this sounds good to me - that will make all meta-data related to an extension available in just one place. - Venkat What i was thinking of was along the lines of adding Tuscany specific xml to the definitions file that replaces everything we currently put in the meta-inf/services files for binding and implementation extensions, eg something like: definitions xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.0; ... bindingType type=binding.ws ... tuscany:binding providerFactory=org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory model=org.apache.tuscany.sca.binding.ws.WebServiceBinding / /bindingType /definitions IMHO this is mixing different concerns that should be kept independent: - domain != runtime - policy definitions != runtime extensions - application level definitions != system definitions If you don't like the current META-INF/services approach and really want to change all that, I'd suggest to come up with a proper extension mechanism, independent of SCA policy definitions, something like OSGi for example would be more suitable for this. -- Jean-Sebastien
Re: [DISCUSS] Declaring extensions as being available in the domain
Agreed to all that ONLY IF definitions.xml is going to contain things related to policies only. Though it is at the present moment my belief is that it could evolve to represent information more than just policy related things. This belief of mine is based on the following : - - the name of the file is 'definitions.xml' and is not 'policy-definitions.xml' - this is defined in the assembly model specs and not in the PolicyFwk specs. If its just for policies, I'd reckon that it would have been defined completely in the PolicySpecs and only referred to in the Assembly Model specs. Right now its vice-versa. Maybe some Specs folks should give us their perspective on this. - Venkat On Tue, May 13, 2008 at 11:32 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes, I think each of those specific ones should be allowed to have its own definitions.xml and bindingType info simply because each of them could have their own list what intents it provides inherently. Maybe I am missing the alternative here. - Venkat On Tue, May 13, 2008 at 2:54 AM, Raymond Feng [EMAIL PROTECTED] wrote: I share the same concerns as Sebastien raised. Mixing the policy definitions with tuscany runtime extensions in one file doesn't seem to be right. For example, we could have two tuscany extensions to support binding.ws, one is based on Axis2 while the other one is based on CXF. With the current approach, we will see three files: definitions.xml for binding.ws bindingType which is independent of the underlying ws stack two META-INF/services/... files, one for binding-ws-axis2 and the other for binding-ws-cxf With the new proposal, I cannot achieve the pluggability unless we duplicate the bindingType info for binding.ws in two definitions.xml. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, May 12, 2008 1:56 PM To: tuscany-dev@ws.apache.org Subject: Re: [DISCUSS] Declaring extensions as being available in the domain Venkata Krishnan wrote: Hi Ant, Yes, this sounds good to me - that will make all meta-data related to an extension available in just one place. - Venkat What i was thinking of was along the lines of adding Tuscany specific xml to the definitions file that replaces everything we currently put in the meta-inf/services files for binding and implementation extensions, eg something like: definitions xmlns:tuscany= http://tuscany.apache.org/xmlns/sca/1.0; ... bindingType type=binding.ws ... tuscany:binding providerFactory=org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory model=org.apache.tuscany.sca.binding.ws.WebServiceBinding / /bindingType /definitions IMHO this is mixing different concerns that should be kept independent: - domain != runtime - policy definitions != runtime extensions - application level definitions != system definitions If you don't like the current META-INF/services approach and really want to change all that, I'd suggest to come up with a proper extension mechanism, independent of SCA policy definitions, something like OSGi for example would be more suitable for this. -- Jean-Sebastien
Re: [DISCUSS] Declaring extensions as being available in the domain
On Mon, May 12, 2008 at 10:24 PM, Raymond Feng [EMAIL PROTECTED] wrote: I share the same concerns as Sebastien raised. Mixing the policy definitions with tuscany runtime extensions in one file doesn't seem to be right. For example, we could have two tuscany extensions to support binding.ws, one is based on Axis2 while the other one is based on CXF. With the current approach, we will see three files: definitions.xml for binding.ws bindingType which is independent of the underlying ws stack two META-INF/services/... files, one for binding-ws-axis2 and the other for binding-ws-cxf With the new proposal, I cannot achieve the pluggability unless we duplicate the bindingType info for binding.ws in two definitions.xml. I don't think thats quite true, as Venkat said there can be multiple definitions files and they get merged together so its no problem at all for each extension to its on extension specific file. ...ant
Re: [DISCUSS] Declaring extensions as being available in the domain
On Tue, May 13, 2008 at 7:12 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Agreed to all that ONLY IF definitions.xml is going to contain things related to policies only. Though it is at the present moment my belief is that it could evolve to represent information more than just policy related things. This belief of mine is based on the following : - - the name of the file is 'definitions.xml' and is not 'policy-definitions.xml' - this is defined in the assembly model specs and not in the PolicyFwk specs. If its just for policies, I'd reckon that it would have been defined completely in the PolicySpecs and only referred to in the Assembly Model specs. Right now its vice-versa. Maybe some Specs folks should give us their perspective on this. - Venkat Those are good points. Especially the last one as its they that ask for this in an offline discussion so it would be really good to get their input here. ...ant
Re: How to deploy standalone and webapp nodes in an SCA domain, was: Tomcat and the new distributed domain modules
On Tue, May 13, 2008 at 2:25 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Sun, May 11, 2008 at 7:34 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: I've been trying to use the new distributed domain stuff - domain-manager and node2* etc - to get Tomcat as a domain manager with SCA webapps being individual nodes, but not really making much progress getting it to work so asking here to see if there are any suggestions - mainly from you Sebastien as you've written most of those new modules :-) I'm going to send steps to show how to run an SCA node as a web app in a different email. Here's a scenario and detailed steps showing how to deploy and run the tutorial's catalog-webapp on Tomcat and integrate it with the other tutorial modules running on other nodes in the same SCA domain. Note: I had to fix PackageTypeDescriberImpl as its support for WARs was broken by a recent patch in SVN r641645 so these steps should work with the 1.2 release and trunk but won't work with r641645 = SVN r655704. First build a Tuscany distribution or just have Maven place all the required Tuscany dependency JARs in a directory as follows: cd tutorial/domain mvn dependency:copy-dependencies That will copy the required JARs to tutorial/domain/target/dependency. Start the domain manager app as follows: java -jar Tuscany distribution root or location of the JARs /tuscany-node2-launcher-2.0-incubating-SNAPSHOT.jar domain Browse http://localhost:9990/ui/workspace/ You should see the tutorial contributions already deployed to the tutorial SCA domain. Browse http://localhost:9990/ui/cloud/ to see the SCA nodes declared in the tutorial. Check CurrencyNode and CatalogsNode Press Start, the two nodes should appear as started (clicking the started link shows their log). cd tutorial/store-eu Edit store-eu.composite and change: reference name=fruitsCatalog target=FruitsCatalogWebService to reference name=fruitsCatalog target=WebFruitsCatalog to make it use the catalog packaged in catalog-webapp. mvn clean install to rebuild store-eu Browse http://localhost:9990/ui/cloud/ Check StoreEUNode, press Start to start the store application. Copy tutorial/catalog-webapp/target/tutorial-catalog-webapp.war to CatalogWebAppNode.war in some folder. If you open CatalogWebAppNode.war you'll see that it only contains a minimum of Tuscany runtime JARs (basically just the API JARs needed to compile application code like JSPs for example) and a Tuscany launcher JAR, responsible for launching the SCA node inside the Webapp. CatalogWebAppNode is the name of the SCA node allocated to the catalog-webapp composite. Having the Web context named CatalogWebAppNode tells the launcher that it's dealing with CatalogWebAppNode. It also makes it easy to find, manage, start/stop these Tomcat nodes using the Tomcat manager app. You can also deploy the same composite Webapp to multiple nodes this way, you just need to name use the proper Web context name when you're deploying the Webapp to the Web container. Note that other application servers like WebSphere or Geronimo (IIRC) allow you to set the Web context name without renaming the WAR. It may be possible to do the same with Tomcat too using a Tomcat deployment descriptor, I'm not sure but anyway I think that there's more power in being portable and Web server independent here, as an SCA domain can include many servers of different types. Configure environment variable TUSCANY_HOME=location of the JARs used earlier or root of Tuscany distribution install. This will tell the launcher where to find these JARs, as an alternative to shared libraries that are not supported by all servers. Start Tomcat Deploy CatalogWebAppNode.war to Tomcat, it should start right away. Browse http://localhost:8080/CatalogWebAppNode/ You should see a catalog of fruits. Browse http://localhost:8104/ui/store-eu.html You should see the store catalog, listing some fruits and vegetables. Assuming that everything worked to this point, you've basically run 4 SCA nodes, 3 running as J2SE standalone nodes and one running as a webapp on Tomcat. Here are the details: - The store widget component runs in your Web browser; - The widget talks to the store components running on a 1st standalone SCA node; - The store components use two catalogs, a vegetables catalog running on a 2nd standalone SCA node and a fruits catalog running on a 3rd SCA node, configured as a Webapp on Tomcat; - Both catalogs use the same currency converter service running on a fourth standalong SCA node. In addition to Webapp deployment this scenario also showed the ability to start nodes in any order - you can try different sequences :) - and update and rewire a composite already deployed to the domain (store-eu was updated and rebuilt then changes were picked up
Re: Tomcat and the new distributed domain modules
ant elder wrote: On Sun, May 11, 2008 at 7:34 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: I've been trying to use the new distributed domain stuff - domain-manager and node2* etc - to get Tomcat as a domain manager with SCA webapps being individual nodes, but not really making much progress getting it to work so asking here to see if there are any suggestions - mainly from you Sebastien as you've written most of those new modules :-) I'm going to send steps to show how to run an SCA node as a web app in a different email. What i'd like is for during Tomcat startup to create a domain manager and then as each webapp is initialized create a new node for each webapp and register it with the domain, and to do that registration with in-JVM calls. Right now the domain manger needs to know about all the nodes before the domain can be started (i think?) but thats problematic in this scenario as the webapps are initialized one by one and its hard to batch all those up and then initialize the domain and then correctly insert the node into the webapps context. This is discussed in a bit more detail in the thread at [1]. I wondered about enhancing the domain manager so that it can be created empty and then create/register nodes one-by-one and then activate the domain once thats done (which probably would require the more dynamic endpoint stuff being talked about in [2]), but I'm not sure that approach really fits in with the current design of the distributed domain support? WDYT, any comments or suggestions? ...ant [1] http://apache.markmail.org/message/2i6gtkveapk3n4nr [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30314.html I'd like to make sure I understand your question and scenario correctly before trying answering the wrong question. Here are the parts that I'm not following: - create a domain manager (did u mean create an domain? deploy a domain manager as a web app? start an instance of a domain manager?) You tell me, I'm trying to understand how to use all this distributed domain stuff you've written to support the scenario described above. Well, I'm not sure what to tell you unless I understand what you meant by 'create a domain manager' before Tomcat starts deploying webapps and what the purpose would be. Some of those distributed domain classes need to created/initialized/started before Tomcat starts deploying webapps No not really, you don't need to create/initialize/start anything before deploying a webapp to Tomcat. I posted a description of a scenario to this thread earlier today, and it doesn't require to start anything before deploying the tutorial webapp to Tomcat. You need to have the configuration of the application (resolved and configured composite) before starting it, but not before deploying it (actually I think you can deploy the app with nothing started, not even Tomcat). Also even though the configuration of the application can be generated on the fly using the domain manager application, you don't have to do that, you could just provide it as a file on disk, or just use give it programmatically (a composite and a set of contributions) to the SCANode using one of the SCANodeFactory.create methods. Maybe you can look at the samples under samples/domain-management, they show how to bootstrap things using the various SPIs and APIs. - is that the domain-manger? the domain-impl? Some combination? Something else? - there is no such thing as 'start a domain', Well, the SCADomain interface does have a start method... If I understand correctly, the SCADomain class represents the combination of a view of an SCA domain, and a runtime instance capable of running a set of components belonging to the domain (which I prefer to call an SCA node). SCADomain.start() starts that view and runtime instance. This is different from starting an SCA administration domain. I think you can start an SCA node, start an administration/manager application that gives you access to an SCA domain, but starting an SCA domain does not make sense IMHO. does it help if its Right now the domain manger needs to know about all the nodes before all the services in the domain can be started (I think?)? No it doesn't, and I think that it would be pretty inconvenient if it id. The requirement at the moment is the following: The domain manager app needs to know the endpoints of the targets of service references to be able to provide that information in a resolved composite. If the target endpoint is available then you'll get it. Note that it doesn't mean that the target service is started or even deployed to a node, it just means that the target service appears with an endpoint in an SCA composite included in the SCA domain composite. If the target service endpoint is not known when you ask the domain manager app to resolve a reference, then the reference will remain unresolved, and then the logic that
Re: SCA 2.0, was Re: Next SCA release
Luciano Resende wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant I think it's time to restart that discussion. I was busy with conferences the last two weeks and had less time to keep up with the dev discussions. Now that I'm catching up with email it is becoming very apparent to me that there are a number of good discussions and initiatives that can lead to good changes and improvements of our code base. Here are a few examples, in no particular order: - Databinding work, with some brainstorming started by Raymond. - OSGi integration, which may lead to SPI and module changes, maybe even some distribution changes. - Extension mechanism, with some discussions about switching to XML and/or using definitions.xml or similar mechanisms. - SCA domain implementation, I'm starting to see emerge different trends / directions, not addressed by the recent work that Simon and I have done in that area. - Runtime integration in particular with Web containers. I think that We now have 3 or 4 different variants of this. - Model changes, in particular in the area of Bindings/Endpoints, which will lead to Provider SPI changes too. - Changes to our WSDL modeling story, Java2WSDL generation, and looking at the difficulties Mike went through in the BPEL integration to get his hands on WSDL, I think we can improve that WSDL model and handling too. - New SCA client APIs (still need to catch up with that but it looks like there's good discussions about that too). - Support for the SCA/JEE spec, which I think will bring new requirements to our models and SPIs. I'm probably missing a few more items like that, but the point is that we need a place to work on all these new ideas. On the other hand, I think it's really important to continue to maintain the code base that works today alive with it's APIs and SPIs, for all the people who currently use, integrate and embed Tuscany, and to be able to continue to promote SOA and the SCA programming model with that code base. So, how about starting a 2.0 branch for the new stuff that we want to rework, and a 1.x branch for the existing code base? Here's my +1 :) -- Jean-Sebastien
[jira] Updated: (TUSCANY-2248) SOAP intents not being honored
[ https://issues.apache.org/jira/browse/TUSCANY-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2248: - Attachment: TUSCANY-2248.patch TUSCANY-2248.patch: Takes care of converting soap11 and soap12 to the qualified forms soap.1_1 and soap.1_2. SOAP intents not being honored Key: TUSCANY-2248 URL: https://issues.apache.org/jira/browse/TUSCANY-2248 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Reporter: Lou Amodeo Fix For: Java-SCA-Next Attachments: TUSCANY-2248.patch Hi, It looks like there are a couple issues with the handling of the SOAP version intents with the Web Services binding. The first one is the literal used to identify the SOAP version and the second is the alrogitym used to apply the SOAP intent. 1) Tuscany is currently using soap. soap11 and soap12 for the literals to identify the soap version. I believe these should be soap, soap.1_1, soap.1_2 according to section 2.3.1 of WS Binding specification. 2) During WSDL generation the soap.1_1 intent is not being honored. It appears that the algorithm to determine which soap version to use is incorrect. I believe it should be as follows: I think this is the algorithym: no requires= specifying a soap version or requires=soap - generate soap.1_1 and soap.1_2 port and binding requires = soap.1_1 - generate soap.1_1 port and binding only requires = soap.1_.2 - generate soap.1_2. port and binding only I also see that an http port/binding is generated by Axis2 by default. Since he intetns are based on soap version I would think the http:address should not be generated. wsdl:port name=HelloWorldServiceHttpEndpoint binding=ns:HelloWorldServiceHttpBinding http:address location=http://localhost:8080/axis2/services/HelloWorldService/ /wsdl:port -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How do you plug in validation monitoring?
Patches for TUSCANY-2277 are now available with the following changes: - The monitors now have access to all of the errors and warnings that are raised during validation in the read, resolve and build phase of an SCA composite. - The code still throws all kind of exceptions as it was doing earlier, to avoid a null pointer exception in furthur processing. - All the exception/warning messages are customized using specified resource bundle. Each module has its own resource bundle. Here are few work items that are currently in progress: - itest for the validation errors. - Identify which exceptions are safe to ignore, so that we allow the processing to proceed furthur. This way we could catch hold of max possible user-errors in one go. On 5/6/08, Simon Laws [EMAIL PROTECTED] wrote: On Mon, May 5, 2008 at 5:54 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: So if plugins want to create their own monitor, what will happen in this case? Now, the way plugins have control is, by looking at the messageID of the problem, they can decide whether they want to change the behaviour from a warning to error, etc. regard Hasan On Fri, May 2, 2008 at 11:23 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Depending where you actually catch the exception you should be able to continue on and process the next artifact. Hmmm, the idea with monitors is to allow the processing code to report warnings and continue or multiple errors per artifact for example. Not sure about how it'll work with exceptions? -- Jean-Sebastien The suggestion is still that monitors get access to all the errors/warnings that the system generates for display to the user so you will be able to take the same approach. Simon -- Thanks Regards, Ramkumar Ramalingam
Re: How do you plug in validation monitoring?
Hi Simon, Noticed an issue, while we do itest to test the exception messages raised by the monitor during the validation, since we are still throwing all kind of exceptions from the code, for any kind of exception that's thrown the domain creation is stopped and hence we end-up in returning null for the domain. Since we have the domain as null, it would not be possible for us to catch hold of the monitor and check if we have got the required message. I believe we need changes in the code, by either ways: 1. To create a monitor and ask the domain to make use of the same, so that we have a control over the monitor. OR 2. Allow the domain creation to complete, irrespective of any user-errors that are encountered during validation. Like to know your thoughts on this. Thanks. On 5/13/08, Ramkumar R [EMAIL PROTECTED] wrote: Patches for TUSCANY-2277 are now available with the following changes: - The monitors now have access to all of the errors and warnings that are raised during validation in the read, resolve and build phase of an SCA composite. - The code still throws all kind of exceptions as it was doing earlier, to avoid a null pointer exception in furthur processing. - All the exception/warning messages are customized using specified resource bundle. Each module has its own resource bundle. Here are few work items that are currently in progress: - itest for the validation errors. - Identify which exceptions are safe to ignore, so that we allow the processing to proceed furthur. This way we could catch hold of max possible user-errors in one go. On 5/6/08, Simon Laws [EMAIL PROTECTED] wrote: On Mon, May 5, 2008 at 5:54 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: So if plugins want to create their own monitor, what will happen in this case? Now, the way plugins have control is, by looking at the messageID of the problem, they can decide whether they want to change the behaviour from a warning to error, etc. regard Hasan On Fri, May 2, 2008 at 11:23 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Depending where you actually catch the exception you should be able to continue on and process the next artifact. Hmmm, the idea with monitors is to allow the processing code to report warnings and continue or multiple errors per artifact for example. Not sure about how it'll work with exceptions? -- Jean-Sebastien The suggestion is still that monitors get access to all the errors/warnings that the system generates for display to the user so you will be able to take the same approach. Simon -- Thanks Regards, Ramkumar Ramalingam -- Thanks Regards, Ramkumar Ramalingam
Re: Improving support for running in OSGi
On 5/12/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: At the moment, itest/osgi-tuscany generates a manifest jar file called tuscany-sca-manifest.jar using a copy of the pom in distribution. I was hoping that we could use a single jar for both OSGi and non-OSGi. The list of virtual 3rd party bundles to be installed and the location of their plain jar files is based on the Class-Path entry in this tuscany-sca-manifest.jar. I do understand that this jar doesn't work in Eclipse, but I am not sure what we gain by having an additional jar for OSGi rather than reuse the jar which is already in distribution. Are we planning to get rid of tuscany-sca-manifest.jar in distribution? Here's what really puzzles me: a) We want to use OSGi as it allows us to cut Tuscany in self contained and isolated bundle JARs, enables us to pick the right subsets of JARs for a particular environment, can even enable us to combine different levels of dependency JARs when required by our extensions. b) But now all the info for all the dependency JARs is mashed in a single tuscany-sca-manifest.jar, and frozen in that 'manifest' JAR when we build the Tuscany distribution. Sorry, but I'm having a hard time understanding how to reconcile (a) and (b). We are learning to walk (or in this case crawl), before starting to run. (b) is a temporary step - it is the way it is purely because I work on Tuscany in my (rather non-existent) free time. And it was meant to provide something for Graham to get started on. Can't it just be much simpler than that? - 1 bundle per dependency JAR - containing the OSGi metadata describing that JAR and what it actually imports/exports? Yes, that is the goal. But unfortunately this is not simpler - it requires some more work with the build. The code itself works with individual meta-data or a collective one. The build at the moment is naive and creates a single manifest file. This is the approach that SpringSource for example seems to have chosen for they application platform OSGi repository. IMHO they are on the right path with this. Well, this is not quite the approach SpringSource have taken. SpringSource repositories contain actual OSGi bundles (jars with OSGi manifest entries including export/import statements). From what I have seen and heard so far, Tuscany seems very reluctant to take that step. We still seem to take the view that OSGi is an add-on, something that we would like to use (maybe, but not quite so sure yet). And that is part of the problem. OSGi tools are geared for building OSGi bundles - maven-pax-plugin for instance would be easy to use for converting our third party jars to bundles. It is slightly harder (messier, but not impossible) to just generate the meta-data we need for using virtual bundles. And we still haven't addressed the issue of bundle dependencies - how do we decide which bundles to install? Do we go for something like OBR in Felix, or invent something else? SpringSource have their own implementation of repositories. Having 100 separate 3rd party bundles (virtual or otherwise) doesn't make sense until we also have a mechanism for automagically determining dependencies across bundles and installing the required bundles. We need additional meta-data apart from the manifest entries to enable this. I do agree that all this needs to be done to get the full benefit of OSGi - I just feel that it requires a lot more thought. -- Jean-Sebastien -- Thank you... Regards, Rajini
Re: SDO Databinding and classloaders
Raymond/Mike, Thank you for your responses. I like the idea that it is the responsibility of the binding provider to ensure that data is correctly copied for cross-classloader calls. But will that require the default binding.sca to be aware of classloaders? I will have to look at the code in more detail (my next free weekend) to understand how this will fit in. On 5/12/08, Mike Edwards [EMAIL PROTECTED] wrote: Raymond Feng wrote: snip There is one more player: binding. The remote interaction is controlled by the binding protocol. When the source and target components are running under different context (such as classloader), the binding provider should be responsible to make sure the data are correctly marshalled/unmarshalled. If the binding decides to optimize for the co-located cases (in same VM), it needs to take care of the cross-context data mapping. It is similar that RMI/IIOP copies the data for the co-located services. snip Maybe the binding should handle the cross-classloader data mapping instead of the implementation.osgi. I think you're getting close to the right behaviour here. IF the interface is marked as remotable, then it is expected that the data is copied between client and service provider. Where there is serialization to a real wire protocol, this is obvious. Where the client and the provider live in the same VM, it is possible to *optimise* and avoid formal serialization, but it should really be the binding layer that makes this decision as other factors like security and other policies may come into play. So, data copying between client SDO and provider SDO is one approach. AllowsPassByReference is a feature worth thinking about. The idea is this is a yet further optimisation that allows passing of object(s) between client and provider when they live in the same VM. This clearly requires that the classes on both sides share the same classloader. I'm not sure how the bindings are meant to work this out for the Tuscany runtime. Finally there is the question of local interfaces. These are meant to be by-reference and the same classloader considerations apply as for the last paragraph. Does your brain hurt yet?? Yours, Mike. -- Thank you... Regards, Rajini
[jira] Updated: (TUSCANY-2248) SOAP intents not being honored
[
https://issues.apache.org/jira/browse/TUSCANY-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated TUSCANY-2248:
-
Attachment: TUSCANY-2248-2.patch
TUSCANY-2248-2.patch:
Since soap.1_1 and soap.1_2 are now qualified intents of soap, even though
it seems logical that
sca:bindingType type=sca:binding.ws mayProvide=soap soap11 soap12
alwaysProvides=/
can be replaced with
sca:bindingType type=sca:binding.ws mayProvide=soap alwaysProvides=/
I am hitting some warning messages like the following:
May 13, 2008 3:13:06 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyConfigurationException: The
following are unfulfilled intents for binding in service - ep2
Unfulfilled Intents = [{http://www.osoa.org/xmlns/sca/1.0}soap.1_1]
SOAP intents not being honored
Key: TUSCANY-2248
URL: https://issues.apache.org/jira/browse/TUSCANY-2248
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-1.0
Reporter: Lou Amodeo
Fix For: Java-SCA-Next
Attachments: TUSCANY-2248-2.patch, TUSCANY-2248.patch
Hi, It looks like there are a couple issues with the handling of the SOAP
version intents with the Web Services binding. The first one is the literal
used to identify the SOAP version and the second is the alrogitym used to
apply the SOAP intent.
1) Tuscany is currently using soap. soap11 and soap12 for the literals to
identify the soap version. I believe these should be soap, soap.1_1,
soap.1_2 according to section 2.3.1 of WS Binding specification.
2) During WSDL generation the soap.1_1 intent is not being honored. It
appears that the algorithm to determine which soap version to use is
incorrect. I believe it should be as follows:
I think this is the algorithym:
no requires= specifying a soap version or requires=soap
- generate soap.1_1 and soap.1_2 port and binding
requires = soap.1_1
- generate soap.1_1 port and binding only
requires = soap.1_.2
- generate soap.1_2. port and binding only
I also see that an http port/binding is generated by Axis2 by default.
Since he intetns are based on soap version I would
think the http:address should not be generated.
wsdl:port name=HelloWorldServiceHttpEndpoint
binding=ns:HelloWorldServiceHttpBinding
http:address
location=http://localhost:8080/axis2/services/HelloWorldService/
/wsdl:port
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TUSCANY-2248) SOAP intents not being honored
[
https://issues.apache.org/jira/browse/TUSCANY-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596341#action_12596341
]
vamsic edited comment on TUSCANY-2248 at 5/13/08 3:03 AM:
---
TUSCANY-2248-2.patch:
Since soap.1_1 and soap.1_2 are now qualified intents of soap, even though
it seems logical that
sca:bindingType type=sca:binding.ws mayProvide=soap soap.1_1 soap.1_2
alwaysProvides=/
can be replaced with
sca:bindingType type=sca:binding.ws mayProvide=soap alwaysProvides=/
I am hitting some warning messages like the following:
May 13, 2008 3:13:06 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyConfigurationException: The
following are unfulfilled intents for binding in service - ep2
Unfulfilled Intents = [{http://www.osoa.org/xmlns/sca/1.0}soap.1_1]
was (Author: vamsic):
TUSCANY-2248-2.patch:
Since soap.1_1 and soap.1_2 are now qualified intents of soap, even though
it seems logical that
sca:bindingType type=sca:binding.ws mayProvide=soap soap11 soap12
alwaysProvides=/
can be replaced with
sca:bindingType type=sca:binding.ws mayProvide=soap alwaysProvides=/
I am hitting some warning messages like the following:
May 13, 2008 3:13:06 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyConfigurationException: The
following are unfulfilled intents for binding in service - ep2
Unfulfilled Intents = [{http://www.osoa.org/xmlns/sca/1.0}soap.1_1]
SOAP intents not being honored
Key: TUSCANY-2248
URL: https://issues.apache.org/jira/browse/TUSCANY-2248
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-1.0
Reporter: Lou Amodeo
Fix For: Java-SCA-Next
Attachments: TUSCANY-2248-2.patch, TUSCANY-2248.patch
Hi, It looks like there are a couple issues with the handling of the SOAP
version intents with the Web Services binding. The first one is the literal
used to identify the SOAP version and the second is the alrogitym used to
apply the SOAP intent.
1) Tuscany is currently using soap. soap11 and soap12 for the literals to
identify the soap version. I believe these should be soap, soap.1_1,
soap.1_2 according to section 2.3.1 of WS Binding specification.
2) During WSDL generation the soap.1_1 intent is not being honored. It
appears that the algorithm to determine which soap version to use is
incorrect. I believe it should be as follows:
I think this is the algorithym:
no requires= specifying a soap version or requires=soap
- generate soap.1_1 and soap.1_2 port and binding
requires = soap.1_1
- generate soap.1_1 port and binding only
requires = soap.1_.2
- generate soap.1_2. port and binding only
I also see that an http port/binding is generated by Axis2 by default.
Since he intetns are based on soap version I would
think the http:address should not be generated.
wsdl:port name=HelloWorldServiceHttpEndpoint
binding=ns:HelloWorldServiceHttpBinding
http:address
location=http://localhost:8080/axis2/services/HelloWorldService/
/wsdl:port
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
Axis2 Binding Provider does not handle services references with WSDL interfaces correctly --- Key: TUSCANY-2316 URL: https://issues.apache.org/jira/browse/TUSCANY-2316 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Environment: - any - Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-Next Attachments: sample-helloworld-bpel-ws.zip Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked. The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use. I've attached a sample application that I created which found this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards updated TUSCANY-2316: -- Attachment: sample-helloworld-bpel-ws.zip Sample BPEL application which exposes the BPEL component as a Web service Axis2 Binding Provider does not handle services references with WSDL interfaces correctly --- Key: TUSCANY-2316 URL: https://issues.apache.org/jira/browse/TUSCANY-2316 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Environment: - any - Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-Next Attachments: sample-helloworld-bpel-ws.zip Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked. The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use. I've attached a sample application that I created which found this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Move the JSP tag lib to the tuscany-sca-api module?
On Mon, May 12, 2008 at 9:50 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Sun, May 11, 2008 at 7:38 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: I may not have been very clear in the first email and also left out the link - it is just a single file that doesn't drag in any additional dependencies - https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-webapp/src/main/resources/META-INF/sca.tld Is a whole new module really necessary? ...ant IMO a new module is necessary, the taglib is from a different spec, for a different usage scenario. -- Jean-Sebastien What we'd be saying is if you're developing SCA applications - JSPs, Servlets, POJOs whatever - you need the tuscany-sca-api jar on your classpath. Why is this a different usage scenario? Developing a J2SE client and developing a Web app are different scenarios. Right now this is just a single file so an entire module really does seem to unnecessarily complicate things. When we implement more of the JEE spec and it turns out that there are more API files then maybe i'd agree but would it be so bad untill then to put this in the tuscany-sca-api module? ...ant I think I gave you my opinion. I don't think it's right to mix different specs in the same JAR. -- Jean-Sebastien Guess this has hit the eternal lots of individual jars versus fewer jars with combined function wall. I'll just leave the taglib where it is for the time being. ...ant
[jira] Created: (TUSCANY-2317) calculator-implementation-policies fails with localized exception-message
calculator-implementation-policies fails with localized exception-message
-
Key: TUSCANY-2317
URL: https://issues.apache.org/jira/browse/TUSCANY-2317
Project: Tuscany
Issue Type: Bug
Components: Java SCA Samples
Affects Versions: Java-SCA-1.2
Environment: MacOS 10.5.2
Java SE 1.6.0_05-b13-120
Reporter: Joachim Roth
Priority: Trivial
In the calculator-implementation-policies sample calculator.CalculatorClient
checks for the SecurityException-Message being equal to a certain text.
(Line35: e.getMessage().equals(Unable to locate a login configuration) ).
On my System the Message of the Exception is localized to German (
Anmeldekonfiguration kann nicht gefunden werden.) resulting in the throw of
the exception as it is not handeled by setting the system-property in line 36.
For me it helped to check for the class of the exception rather than for the
message. Makes it less readable, but more international.
Changed line 35 to:
if (e.getCause().getClass().getName().equals(IOException.class.getName())) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: SCA 2.0, was Re: Next SCA release
On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant I think it's time to restart that discussion. I was busy with conferences the last two weeks and had less time to keep up with the dev discussions. Now that I'm catching up with email it is becoming very apparent to me that there are a number of good discussions and initiatives that can lead to good changes and improvements of our code base. Here are a few examples, in no particular order: - Databinding work, with some brainstorming started by Raymond. - OSGi integration, which may lead to SPI and module changes, maybe even some distribution changes. - Extension mechanism, with some discussions about switching to XML and/or using definitions.xml or similar mechanisms. - SCA domain implementation, I'm starting to see emerge different trends / directions, not addressed by the recent work that Simon and I have done in that area. - Runtime integration in particular with Web containers. I think that We now have 3 or 4 different variants of this. - Model changes, in particular in the area of Bindings/Endpoints, which will lead to Provider SPI changes too. - Changes to our WSDL modeling story, Java2WSDL generation, and looking at the difficulties Mike went through in the BPEL integration to get his hands on WSDL, I think we can improve that WSDL model and handling too. - New SCA client APIs (still need to catch up with that but it looks like there's good discussions about that too). - Support for the SCA/JEE spec, which I think will bring new requirements to our models and SPIs. I'm probably missing a few more items like that, but the point is that we need a place to work on all these new ideas. On the other hand, I think it's really important to continue to maintain the code base that works today alive with it's APIs and SPIs, for all the people who currently use, integrate and embed Tuscany, and to be able to continue to promote SOA and the SCA programming model with that code base. So, how about starting a 2.0 branch for the new stuff that we want to rework, and a 1.x branch for the existing code base? Here's my +1 :) -- Jean-Sebastien It would be good to clean up and improve all the things that have been mentioned in this thread, but I still believe what I said in [1]. So if we're ready to put the 1.x in maintenance mode and start doing this new work in trunk thats great, but if we've still significant development work to do in 1.x then I don't think we should have a 2.0 branch yet. That shouldn't stop us doing most of this new work in trunk though as most of what we're talking in about in this thread can continue to be done in the current trunk without being too disruptive. ...ant [1] http://apache.markmail.org/message/75wp2p3juyzb4xym
Re: Registering ModuleActivators without specifying a META-INF/services/org.apache.tuscany.sca.core.ModuleActivator file
Hi, I'm using a pre-1.2 code base. I'll grab the 1.2 base and give it a try. This refactoring sounds like it's exactly what I'm looking for. Thanks Jean-Sebastion. Richard On Wed, Apr 23, 2008 at 4:20 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Richard Mah wrote: Hi, Yes. I'm interested in only a subset of Tuscany and not the entire runtime. Thanks for the answer. The ModuleActivators I'm trying to use are WSDLInterfaceRuntimeModuleActivator, JavaInterfaceRuntimeModuleActivator, and JavaRuntimeModuleActivator. This leads to another question. For the JavaRuntimeModuleActivator, it seems to require bootstraping code which adds a ContextFactoryExtensionPoint/DefaultContextFactoryExtensionPoint to the registry. However ContextFactoryExtensionPoint and DefaultContextFactoryExtensionPoint are non SPI. What do I need in my bootstraping code in order for me to use JavaRuntimeModuleActivator without SPI violations? Thanks. Richard Mah I can't find WSDLInterfaceRuntimeModuleActivator in the 1.2 code base. What level of Tuscany are you using? JavaRuntimeModuleActivator belongs to the runtime layer (in module implementation-java-runtime) so that's probably not what you want if you want to use the Tuscany models without bringing the whole runtime. In SVN revision r650720 of trunk I've moved some of the Java model initialization out of JavaRuntimeModuleActivator into a new JavaImplementationModuleActivator in module implementation-java. This will allow you to get an initialized model environment (and in particular a JavaImplementationFactory configured with all the right Java 5 annotation processors that introspect Java component implementation classes and populate the Java models) without having to drag module implementation-java-runtime and its runtime dependencies. So the short answer to your question is: You shouldn't need JavaRuntimeModuleActivator anymore :) I've also committted new sample programs [1] that show how to bootstrap a subset of Tuscany to work with the various models without runtime dependencies. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/domain-management/ Hope this helps. -- Jean-Sebastien
[jira] Resolved: (TUSCANY-2317) calculator-implementation-policies fails with localized exception-message
[
https://issues.apache.org/jira/browse/TUSCANY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende resolved TUSCANY-2317.
--
Resolution: Fixed
Fix Version/s: Java-SCA-Next
Fixed by applying the same fix discussed on the thread below :
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02533.html
calculator-implementation-policies fails with localized exception-message
-
Key: TUSCANY-2317
URL: https://issues.apache.org/jira/browse/TUSCANY-2317
Project: Tuscany
Issue Type: Bug
Components: Java SCA Samples
Affects Versions: Java-SCA-1.2
Environment: MacOS 10.5.2
Java SE 1.6.0_05-b13-120
Reporter: Joachim Roth
Priority: Trivial
Fix For: Java-SCA-Next
Original Estimate: 0.17h
Remaining Estimate: 0.17h
In the calculator-implementation-policies sample calculator.CalculatorClient
checks for the SecurityException-Message being equal to a certain text.
(Line35: e.getMessage().equals(Unable to locate a login configuration) ).
On my System the Message of the Exception is localized to German (
Anmeldekonfiguration kann nicht gefunden werden.) resulting in the throw of
the exception as it is not handeled by setting the system-property in line 36.
For me it helped to check for the class of the exception rather than for the
message. Makes it less readable, but more international.
Changed line 35 to:
if (e.getCause().getClass().getName().equals(IOException.class.getName())) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Improving support for running in OSGi
Rajini Sivaram wrote: Can't it just be much simpler than that? - 1 bundle per dependency JAR - containing the OSGi metadata describing that JAR and what it actually imports/exports? Yes, that is the goal. But unfortunately this is not simpler - it requires some more work with the build. The code itself works with individual meta-data or a collective one. The build at the moment is naive and creates a single manifest file. Maybe I can help, can you say what 'more work with the build' this will require? This is the approach that SpringSource for example seems to have chosen for they application platform OSGi repository. IMHO they are on the right path with this. Well, this is not quite the approach SpringSource have taken. SpringSource repositories contain actual OSGi bundles (jars with OSGi manifest entries including export/import statements). It is the approach that SpringSource has taken, or maybe I've not been clear... I meant 1 bundle per dependency JAR, i.e. that bundle is the JAR itself. From what I have seen and heard so far, Tuscany seems very reluctant to take that step. That's too bad, as it's the right approach IMO. -- Jean-Sebastien
Re: SCA 2.0, was Re: Next SCA release
ant elder wrote: On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant I think it's time to restart that discussion. I was busy with conferences the last two weeks and had less time to keep up with the dev discussions. Now that I'm catching up with email it is becoming very apparent to me that there are a number of good discussions and initiatives that can lead to good changes and improvements of our code base. Here are a few examples, in no particular order: - Databinding work, with some brainstorming started by Raymond. - OSGi integration, which may lead to SPI and module changes, maybe even some distribution changes. - Extension mechanism, with some discussions about switching to XML and/or using definitions.xml or similar mechanisms. - SCA domain implementation, I'm starting to see emerge different trends / directions, not addressed by the recent work that Simon and I have done in that area. - Runtime integration in particular with Web containers. I think that We now have 3 or 4 different variants of this. - Model changes, in particular in the area of Bindings/Endpoints, which will lead to Provider SPI changes too. - Changes to our WSDL modeling story, Java2WSDL generation, and looking at the difficulties Mike went through in the BPEL integration to get his hands on WSDL, I think we can improve that WSDL model and handling too. - New SCA client APIs (still need to catch up with that but it looks like there's good discussions about that too). - Support for the SCA/JEE spec, which I think will bring new requirements to our models and SPIs. I'm probably missing a few more items like that, but the point is that we need a place to work on all these new ideas. On the other hand, I think it's really important to continue to maintain the code base that works today alive with it's APIs and SPIs, for all the people who currently use, integrate and embed Tuscany, and to be able to continue to promote SOA and the SCA programming model with that code base. So, how about starting a 2.0 branch for the new stuff that we want to rework, and a 1.x branch for the existing code base? Here's my +1 :) -- Jean-Sebastien It would be good to clean up and improve all the things that have been mentioned in this thread, but I still believe what I said in [1]. So if we're ready to put the 1.x in maintenance mode and start doing this new work in trunk thats great, but if we've still significant development work to do in 1.x then I don't think we should have a 2.0 branch yet. That shouldn't stop us doing most of this new work in trunk though as most of what we're talking in about in this thread can continue to be done in the current trunk without being too disruptive. ...ant [1] http://apache.markmail.org/message/75wp2p3juyzb4xym I don't think we should be putting 1.x into maintenance mode now. I'm open to having an exploratory branch for 2.0 that would be used as a place to experiment with new ideas that can't be done in the 1.x trunk because they are too disruptive. If we do this, we'll need to have a clear understanding of what things would be done in the 2.0 branch and what activity would continue in
Re: SCA 2.0, was Re: Next SCA release
Simon Nash wrote: ant elder wrote: On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant I think it's time to restart that discussion. I was busy with conferences the last two weeks and had less time to keep up with the dev discussions. Now that I'm catching up with email it is becoming very apparent to me that there are a number of good discussions and initiatives that can lead to good changes and improvements of our code base. Here are a few examples, in no particular order: - Databinding work, with some brainstorming started by Raymond. - OSGi integration, which may lead to SPI and module changes, maybe even some distribution changes. - Extension mechanism, with some discussions about switching to XML and/or using definitions.xml or similar mechanisms. - SCA domain implementation, I'm starting to see emerge different trends / directions, not addressed by the recent work that Simon and I have done in that area. - Runtime integration in particular with Web containers. I think that We now have 3 or 4 different variants of this. - Model changes, in particular in the area of Bindings/Endpoints, which will lead to Provider SPI changes too. - Changes to our WSDL modeling story, Java2WSDL generation, and looking at the difficulties Mike went through in the BPEL integration to get his hands on WSDL, I think we can improve that WSDL model and handling too. - New SCA client APIs (still need to catch up with that but it looks like there's good discussions about that too). - Support for the SCA/JEE spec, which I think will bring new requirements to our models and SPIs. I'm probably missing a few more items like that, but the point is that we need a place to work on all these new ideas. On the other hand, I think it's really important to continue to maintain the code base that works today alive with it's APIs and SPIs, for all the people who currently use, integrate and embed Tuscany, and to be able to continue to promote SOA and the SCA programming model with that code base. So, how about starting a 2.0 branch for the new stuff that we want to rework, and a 1.x branch for the existing code base? Here's my +1 :) -- Jean-Sebastien It would be good to clean up and improve all the things that have been mentioned in this thread, but I still believe what I said in [1]. So if we're ready to put the 1.x in maintenance mode and start doing this new work in trunk thats great, but if we've still significant development work to do in 1.x then I don't think we should have a 2.0 branch yet. That shouldn't stop us doing most of this new work in trunk though as most of what we're talking in about in this thread can continue to be done in the current trunk without being too disruptive. ...ant [1] http://apache.markmail.org/message/75wp2p3juyzb4xym I don't think we should be putting 1.x into maintenance mode now. I agree. In my initial email I said 'maintain ... live'. By 'live' I meant that non-breaking changes, evolutions, improvements would still go into 1.x to support our user community and the efforts to help increase adoption of SCA based on that code (tutorials, samples,
Re: SCA 2.0, was Re: Next SCA release
snip I prefer a branch to make it clear that all in the community can work in it, to make it clear that it's accepted by the project, that it's buildable etc, instead of having work buried in the middle of a sandbox together with obsolete or broken stuff, with an unclear status. So you mean a branch for 2.0 (you did say this in your previous post and my eyes skipped over it) and trunk would remain as 1.x ? Simon
Re: SCA 2.0, was Re: Next SCA release
Simon Laws wrote: snip I prefer a branch to make it clear that all in the community can work in it, to make it clear that it's accepted by the project, that it's buildable etc, instead of having work buried in the middle of a sandbox together with obsolete or broken stuff, with an unclear status. So you mean a branch for 2.0 (you did say this in your previous post and my eyes skipped over it) and trunk would remain as 1.x ? Simon It doesn't really make a difference for me: just 2 folders, one for 1.x one for 2.0, and just make clear which one is which and what's its purpose. I'm fine with whatever option people prefer: trunk for 2.0 and branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0, whatever keeps our community happy. -- Jean-Sebastien
SCA BPEL - ODE Database dependency
In Apache Tuscany, we have a embedded ODE Server that has a dependency on the ODE database (ode-dao-jpa-ojpa-derby-1.1.zip) that get's unzip by the build process when the app is run. I see two issues with this approach : The build infrastructure to unzip the db needs to be copied on every sample app and when running from an IDE, this code might not have been executed, and will require the application developer to go outside of the ide, to run some build command to create the db and make it available on the classpath. I was wondering if there is some kind of script that could be used to generate the db structure and any initial content. If so, I was thinking to integrate this script into the Embedded ODE Server initialization code, and create the proper db dependencies if not found. Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: SCA BPEL - ODE Database dependency
I think Alex didn't mean it's there already, just pointed out a way to add this :) We already have something similar in bpel-store [1]. You can configure OpenJPA to create the schema for you if it can't find it. So what you would do is basically: 1. Create a derby instance. 2. Point OpenJPA to it with the right option (just add it as a property in [2]). 3. Instantiate the store asking it to create its schema as well. 4. There's no 4. Given that Tuscany already has its own IL, you have all the freedom to do this when assembling the pieces. The only missing one is the property in 2. Cheers, Matthieu [1] http://svn.apache.org/repos/asf/ode/trunk/bpel-store/src/main/java/org/apache/ode/store/jpa/DbConfStoreConnectionFactory.java [2] http://svn.apache.org/repos/asf/ode/trunk/dao-jpa/src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java On Tue, May 13, 2008 at 12:04 PM, Luciano Resende [EMAIL PROTECTED] wrote: Good to know we already have the code to create a new Derby dabase instance with a fresh Ode Schema. I guess I have missed this when creating the Tuscany Embedded Ode Server. Could you please point me to where this is available ? On Tue, May 13, 2008 at 11:56 AM, Alex Boisvert [EMAIL PROTECTED] wrote: Perhaps by defining a new database mode SAMPLE (we already have EMBEDDED, INTERNAL, EXTERNAL), that creates a new Derby database instance with a fresh Ode schema everytime the server is started? alex On Tue, May 13, 2008 at 11:50 AM, Luciano Resende [EMAIL PROTECTED] wrote: In Apache Tuscany, we have a embedded ODE Server that has a dependency on the ODE database (ode-dao-jpa-ojpa-derby-1.1.zip) that get's unzip by the build process when the app is run. I see two issues with this approach : The build infrastructure to unzip the db needs to be copied on every sample app and when running from an IDE, this code might not have been executed, and will require the application developer to go outside of the ide, to run some build command to create the db and make it available on the classpath. I was wondering if there is some kind of script that could be used to generate the db structure and any initial content. If so, I was thinking to integrate this script into the Embedded ODE Server initialization code, and create the proper db dependencies if not found. Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
[jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596503#action_12596503 ] Scott Kurz commented on TUSCANY-2316: - The binding-ws-axis2 is overwriting the databinding on the IC obtained from the binding.ws model object (WebServiceBindingImpl).So far, that would seem to be correct, then. What do the ClassCastExceptions you're getting look like? Axis2 Binding Provider does not handle services references with WSDL interfaces correctly --- Key: TUSCANY-2316 URL: https://issues.apache.org/jira/browse/TUSCANY-2316 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Environment: - any - Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-Next Attachments: sample-helloworld-bpel-ws.zip Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked. The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use. I've attached a sample application that I created which found this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SCA BPEL - ODE Database dependency
Good to know we already have the code to create a new Derby dabase instance with a fresh Ode Schema. I guess I have missed this when creating the Tuscany Embedded Ode Server. Could you please point me to where this is available ? On Tue, May 13, 2008 at 11:56 AM, Alex Boisvert [EMAIL PROTECTED] wrote: Perhaps by defining a new database mode SAMPLE (we already have EMBEDDED, INTERNAL, EXTERNAL), that creates a new Derby database instance with a fresh Ode schema everytime the server is started? alex On Tue, May 13, 2008 at 11:50 AM, Luciano Resende [EMAIL PROTECTED] wrote: In Apache Tuscany, we have a embedded ODE Server that has a dependency on the ODE database (ode-dao-jpa-ojpa-derby-1.1.zip) that get's unzip by the build process when the app is run. I see two issues with this approach : The build infrastructure to unzip the db needs to be copied on every sample app and when running from an IDE, this code might not have been executed, and will require the application developer to go outside of the ide, to run some build command to create the db and make it available on the classpath. I was wondering if there is some kind of script that could be used to generate the db structure and any initial content. If so, I was thinking to integrate this script into the Embedded ODE Server initialization code, and create the proper db dependencies if not found. Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: SCA BPEL - ODE Database dependency
Perhaps by defining a new database mode SAMPLE (we already have EMBEDDED, INTERNAL, EXTERNAL), that creates a new Derby database instance with a fresh Ode schema everytime the server is started? alex On Tue, May 13, 2008 at 11:50 AM, Luciano Resende [EMAIL PROTECTED] wrote: In Apache Tuscany, we have a embedded ODE Server that has a dependency on the ODE database (ode-dao-jpa-ojpa-derby-1.1.zip) that get's unzip by the build process when the app is run. I see two issues with this approach : The build infrastructure to unzip the db needs to be copied on every sample app and when running from an IDE, this code might not have been executed, and will require the application developer to go outside of the ide, to run some build command to create the db and make it available on the classpath. I was wondering if there is some kind of script that could be used to generate the db structure and any initial content. If so, I was thinking to integrate this script into the Embedded ODE Server initialization code, and create the proper db dependencies if not found. Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: More Java security fixes on the way
Hi, Dan. I'm looking into the patch you contributed with https://issues.apache.org/jira/browse/TUSCANY-2290. There is one issue catching my eyes. We have samples in Tuscany today which use some technology APIs, for example, to start the ActiveMQ JMS broker. To run these samples with Java2 security enabled, we have to surround some of the calls with privileged block. That seems to complicate/pollute the samples. Should we leave these samples as-is without supporting Java2 security (or grant permissions to the sample code directly with a policy file)? Thanks, Raymond -- From: Dan Becker [EMAIL PROTECTED] Sent: Friday, May 02, 2008 7:29 AM To: tuscany-dev tuscany-dev@ws.apache.org Subject: More Java security fixes on the way FYI, so every one is aware of recent Tuscany security changes and for your comments. Over the last few weeks I have been making fixes to the Tuscany core in order to make the code a bit safer with Java 2 security enabled. There are many instances in which we want Tuscany code to perform some privileged action (such as read a system property or write a file to the file system), yet we do not want client code to have this ability. There are over 300 Tuscany calls to privileged Java APIs which may throw some sort of security exception if proper access is not granted. Since there are so many APIs, I have have been issuing patches in smaller increments. This makes the patch easier to review, commit, and reverse if there is a problem. Following is a list of past changes related to security. TUSCANY-2108 - Enabled Simple Calculator to run with security on TUSCANY-2227 - Enabled ITests to run with secuirty on TUSCANY-2030 - Enabled Simple Caclulator to run on WebSphere Expect a few JIRAs in the next weeks to enable the demos, samples, and vtests to run with security on. And then I would like to make a maven profile that allows a user to test with security on or off. If you have any other ideas related to Java 2 security, I encourage you to mention them here. -- Thanks, Dan Becker
Re: More Java security fixes on the way
Raymond Feng wrote: I'm looking into the patch you contributed with https://issues.apache.org/jira/browse/TUSCANY-2290. There is one issue catching my eyes. We have samples in Tuscany today which use some technology APIs, for example, to start the ActiveMQ JMS broker. To run these samples with Java2 security enabled, we have to surround some of the calls with privileged block. That seems to complicate/pollute the samples. Should we leave these samples as-is without supporting Java2 security (or grant permissions to the sample code directly with a policy file)? Hi Raymond, Thanks for the code review. Those are excellent points you bring up which not only apply to the Tuscany-provided samples, but potentially also to user-solutions which exploit Tuscany as the samples do. Do you require such code to implement security blocks (and grant permissions with policy files) or do you simplify and not support security? In my opinion, the answer would depend on what you would expect the user to do and what the purpose of the user code would be. For instance with application level code and samples I would never expect the user to have to add privileged blocks or add security policy permissions. On the other hand, for extensions and code that used Tuscany SPIs, I would expect requirements for the extension to provide privileged blocks and security policy permissions. In the current situation you mention (starting the ActiveMQ JMS broker), I agree it does complicate the samples. But any user application that attempts to start the JMS broker and support Java 2 security would have to do the same thing. I am fine removing the complicating security code from the sample, but then I should write a wiki page or other documentation that shows how to support this. Other opinions? -- Thanks, Dan Becker
Re: Improving support for running in OSGi
On 5/13/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Can't it just be much simpler than that? - 1 bundle per dependency JAR - containing the OSGi metadata describing that JAR and what it actually imports/exports? Yes, that is the goal. But unfortunately this is not simpler - it requires some more work with the build. The code itself works with individual meta-data or a collective one. The build at the moment is naive and creates a single manifest file. Maybe I can help, can you say what 'more work with the build' this will require? I have modified the code to generate manifest entries for virtual bundles and install 3rd party jars as individual bundles. These bundles export everything in the jar, and import any required package dynamically. itest/osgi-tuscany now installs 200 bundles into OSGi - the performance impact on classloading is quite severe - explicit imports in 3rd party bundles will help improve this, but I am not sure to what extent. The work that still needs to be done is the build-time generation of manifest entries for 3rd party bundles. Based on your comment below, should we start a discussion on whether we can convert 3rd party jars into bundles, rather than generate separate manifests? That would give us a cleaner distribution (and make the build easier). We have been working on the assumption that we cannot modify 3rd party jars, and hence the manifest entries had to be generated and stored separately - hence the virtual bundles. This is the approach that SpringSource for example seems to have chosen for they application platform OSGi repository. IMHO they are on the right path with this. Well, this is not quite the approach SpringSource have taken. SpringSource repositories contain actual OSGi bundles (jars with OSGi manifest entries including export/import statements). It is the approach that SpringSource has taken, or maybe I've not been clear... I meant 1 bundle per dependency JAR, i.e. that bundle is the JAR itself. From what I have seen and heard so far, Tuscany seems very reluctant to take that step. That's too bad, as it's the right approach IMO. -- Jean-Sebastien -- Thank you... Regards, Rajini
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
On Sat, May 10, 2008 at 12:17 AM, ant elder [EMAIL PROTECTED] wrote: Restarting the graduation vote with the updated proposal words, please vote on the proposal below to graduate Tuscany to a TLP. +1 Matthieu +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged.
