Re: [jira] Updated: (TUSCANY-611) RMI Binding
On Aug 10, 2006, at 10:53 PM, Venkata Krishnan wrote: Thanks Ant and Jim. Ant, I shall certainly work on the formatting and a couple of other issues and posted an updated patch asap. Jim, you point was something that I did vacillate about. I was wondering if the registry should be started by the binding or should it be done offline. My imagination of the Registry is that it is lightweight and it should be ok to host several instances of it on a host, ofcourse each on a different port. Hence we might actually allow the assemblies to mention which port number is preferred to host the RMI Service. If a registry for the port already exists then we simply use that otherwise start one. So if is possible that a registry on a port will host more than one service. It is also a good idea that we clearly have one registry per host and implement it the way you have mentioned out here. I am open to do this as well. Let me know your final thoughts on this. Jerermy and others what are your thoughts on this? One per host (runtime) sounds good. The port should be a property of the system component that initializes the registry - by making it a property we can potentially configure it in scdl. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r430621 - in /incubator/tuscany/java: samples/sca/helloworldws/ samples/sca/helloworldwsclient/ samples/sca/helloworldwsclient/src/main/java/helloworld/ samples/sca/helloworldwsclient/
Hi, Rick. With your check-in, I'm seeing the EchoBinding test case is failing with the following exception: org.apache.tuscany.spi.loader.InvalidReferenceException: No target for service [ClientService] at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java) at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java:1) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:75) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:50) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:107) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:46) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:20) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:157) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:111) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:90) at org.apache.tuscany.core.launcher.Launcher.bootApplication(Launcher.java:171) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:63) at echo.BootstrapTestCase.setUp(BootstrapTestCase.java:23) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I adjusted the scdl file per SCA 0.95 spec: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=echo.sample service name=ClientService interface.java class=echo.Client/ binding.echo/ referenceClient/reference /service component name=Client implementation.java class=echo.ClientImpl/ reference name=echoReferenceEchoReference/reference /component reference name=EchoReference interface.java interface=echo.Echo/ binding.echo/ /reference /composite Now the ServiceLoader.java is problematic because it assumes it'll get reference before the binding which is not case per SCA 0.95 spec: service name=xs:NCName multiplicity=0..1 or 1..1 or 0..n or 1..n?* interface/ binding uri=xs:anyURI?/* referencewire-target-URI/reference+ /service component name=xs:NCName* implementation/ property name=xs:NCName source=sca:Property?* property-value /property reference name=xs:NCName/* wire-target-URI /reference /component The ComponentLoader.java cannot handle the reference element either since the SCA spec 0.95 also use the element content instead of target attribute. I attached a patch to fix the problem but some of the SCDLs and test cases need to be adjusted to conform to the SCA 0.95 spec. Thanks, Raymond - Original Message - From: [EMAIL PROTECTED] To: tuscany-commits@ws.apache.org Sent: Thursday, August 10, 2006 6:59 PM Subject: svn commit: r430621 - in /incubator/tuscany/java: samples/sca/helloworldws/ samples/sca/helloworldwsclient/ samples/sca/helloworldwsclient/src/main/java/helloworld/ samples/sca/helloworldwsclient/src/main/resources/META-INF/sca/ sca/bindings/binding.ax... Author: rineholt Date: Thu Aug 10 18:59:40 2006 New Revision: 430621 URL: http://svn.apache.org/viewvc?rev=430621view=rev Log: TUSCANY-575 http://issues.apache.org/jira/browse/TUSCANY-575 fix service element to use child reference element instead of target attribute mock can be a pain feed java interface specified in service to service element (still a tad of a hack) Added: incubator/tuscany/java/samples/sca/helloworldwsclient/src/main/java/helloworld/HelloWorldServiceComponent.java Modified: incubator/tuscany/java/samples/sca/helloworldws/setup.bat incubator/tuscany/java/samples/sca/helloworldwsclient/run.bat incubator/tuscany/java/samples/sca/helloworldwsclient/src/main/java/helloworld/HelloWorldClient.java incubator/tuscany/java/samples/sca/helloworldwsclient/src/main/java/helloworld/HelloWorldService.java
Re: [C++] Do we need Tuscany-model.config?
This is similar to what Java had. I think htis is replaced by include.wsdl and include.xsd or soemthing. Not sure if this got into the spec. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: It looks like Tuscany-model.config just lists the WSDLs and XSDs used in an application. Do we still need it? or could we just figure out ourselves what the WSDLs and XSDs are? Just trying to make it simpler for users to write SCA applications, and limit the number of things that they have to worry about... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Do we need Tuscany-model.config?
Pete Robbins wrote: This is similar to what Java had. I think htis is replaced by include.wsdl and include.xsd or soemthing. Not sure if this got into the spec. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: It looks like Tuscany-model.config just lists the WSDLs and XSDs used in an application. Do we still need it? or could we just figure out ourselves what the WSDLs and XSDs are? Just trying to make it simpler for users to write SCA applications, and limit the number of things that they have to worry about... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] As far as I know include.wsdl and include.xsd are not in the spec yet. I'm actually thinking that placing the WSDL and XSD files in the directory containing the application should be enough to indicate that they should be used. In other words, no need to edit an XML file telling the runtime that some WSDL and XSD files are there, the runtime should be smart enough to just scan and find them... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
A lot of things referenced from a .composite are a path relative to the .composite file (the compsite root). This is defined in the spec. For example, component name=MyValueServiceComponent implementation.cpp library=MyValuelibrary path=MyValue header=MyValue/MyValueImpl.h/implementation.cpp so if the composite file is in .../deploy/configuration/myValue.composite the library will be located at .../deploy/configuration/MyValue/libMyValuelibrary.so. Similarly the implementation header will be located at .../deploy/configuration/MyValue/MyValueImpl.h ...so I don't think you can have an arbitrary separation of configuration and packages. I think we can use a very simple deployment which is that the runtime will find all the composites under the system root so it could look like: .../deploy fred.composite ( composite name=abc/ ) some_other_artifacts /ANOtherCompo joe.composite ( composite name=xyz/ ) /joes_libraries joe.dll So the name of the folder and composite file is irrelevent as the actual composite name comes from the scdl name=. This, of course, is a little harder for the runtime to load but a lot simpler for the user IMO. So for a MyValue sample I'd develop my composites in a structure that matches the deploy layout. This is necessary for the scagen step that requires the scdl and the interface headers to generate the proxies and wrappers. This strcture may or may not have multiple directories at the choice of the developer, he may want each component in a separate dir for instance. Deployment is simply copying the scdl, libraries and headers to wherever they are to be deployed. (Although the headers are not currently used at runtime it is possible that they may be in the future). So I may end up with: .../MyValue myValue.composite myVal.componentType /CustomerInfo custinfo.componentType custinfo.h etc.. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: When I started to implement the new composite assembly model I felt a need to adjust a little the folder structure under the Tuscany system root, did half of it, which triggered some questions :) This is a new thread to discuss these changes. Here's what we had in M1: $TUSCANY_SCAPP_SYSTEM_ROOT/ -- your Tuscany-system-root subsystems/ CalculatorSubsystem/ sca.subsystem -- creates and configures the Calculator module component modules/ Calculator -- the Calculator module and code sca.module other artifacts, *.so, *.wsdl, *.xsd etc. Now that the spec has removed subsystem, module and fragment, and generalized the use of composites, here's what I'd like to propose: deploy/ -- your Tuscany-system-root configuration/ CalculatorApp.composite -- creates the Calculator component, we don't need sub-folders here since we can give meaningful name to composite files now packages/ Calculator -- the Calculator composite and code Calculator.composite other artifacts, *.so, *.wsdl, *.xsd etc. - Configuration contains the composites included in your system creating and configuring your top level components. - Packages contains all your other development artifacts (not necessarily just composites that's why I'm proposing packages/ instead of modules/ or composites/). - I think that the samples should use consistent naming convenvions, but you should also be able to pick the names you want for your folders and artifacts and have Foo/Bar.composite containing composite name=Abc/ for example. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Do we need Tuscany-model.config?
Actually the wsdl/xsd are loaded for a particular composite so if there were more say 2 .composites in a folder and 3 xsds we would load all 3 xsds twice, once for each composite. On 11/08/06, Pete Robbins [EMAIL PROTECTED] wrote: so we load any wsdl/xsd in the same folder as the .composite file? Sounds reasonable. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: This is similar to what Java had. I think htis is replaced by include.wsdl and include.xsd or soemthing. Not sure if this got into the spec. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: It looks like Tuscany-model.config just lists the WSDLs and XSDs used in an application. Do we still need it? or could we just figure out ourselves what the WSDLs and XSDs are? Just trying to make it simpler for users to write SCA applications, and limit the number of things that they have to worry about... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] As far as I know include.wsdl and include.xsd are not in the spec yet. I'm actually thinking that placing the WSDL and XSD files in the directory containing the application should be enough to indicate that they should be used. In other words, no need to edit an XML file telling the runtime that some WSDL and XSD files are there, the runtime should be smart enough to just scan and find them... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete -- Pete
Re: [C++] Do we need Tuscany-model.config?
of course this supposes that all the schema and wsdl is local. We probably need to support the case where the wsdl is remote e.g. http://mySite/flobber.wsdl Cheers, On 11/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Actually the wsdl/xsd are loaded for a particular composite so if there were more say 2 .composites in a folder and 3 xsds we would load all 3 xsds twice, once for each composite. On 11/08/06, Pete Robbins [EMAIL PROTECTED] wrote: so we load any wsdl/xsd in the same folder as the .composite file? Sounds reasonable. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: This is similar to what Java had. I think htis is replaced by include.wsdl and include.xsd or soemthing. Not sure if this got into the spec. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: It looks like Tuscany-model.config just lists the WSDLs and XSDs used in an application. Do we still need it? or could we just figure out ourselves what the WSDLs and XSDs are? Just trying to make it simpler for users to write SCA applications, and limit the number of things that they have to worry about... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] As far as I know include.wsdl and include.xsd are not in the spec yet. I'm actually thinking that placing the WSDL and XSD files in the directory containing the application should be enough to indicate that they should be used. In other words, no need to edit an XML file telling the runtime that some WSDL and XSD files are there, the runtime should be smart enough to just scan and find them... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete -- Pete -- Pete
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Pete Robbins wrote: A lot of things referenced from a .composite are a path relative to the .composite file (the compsite root). This is defined in the spec. For example, component name=MyValueServiceComponent implementation.cpp library=MyValuelibrary path=MyValue header=MyValue/MyValueImpl.h/implementation.cpp so if the composite file is in .../deploy/configuration/myValue.composite the library will be located at .../deploy/configuration/MyValue/libMyValuelibrary.so. Similarly the implementation header will be located at .../deploy/configuration/MyValue/MyValueImpl.h ...so I don't think you can have an arbitrary separation of configuration and packages. I think we can use a very simple deployment which is that the runtime will find all the composites under the system root so it could look like: .../deploy fred.composite ( composite name=abc/ ) some_other_artifacts /ANOtherCompo joe.composite ( composite name=xyz/ ) /joes_libraries joe.dll So the name of the folder and composite file is irrelevent as the actual composite name comes from the scdl name=. This, of course, is a little harder for the runtime to load but a lot simpler for the user IMO. So for a MyValue sample I'd develop my composites in a structure that matches the deploy layout. This is necessary for the scagen step that requires the scdl and the interface headers to generate the proxies and wrappers. This strcture may or may not have multiple directories at the choice of the developer, he may want each component in a separate dir for instance. Deployment is simply copying the scdl, libraries and headers to wherever they are to be deployed. (Although the headers are not currently used at runtime it is possible that they may be in the future). So I may end up with: .../MyValue myValue.composite myVal.componentType /CustomerInfo custinfo.componentType custinfo.h etc.. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: When I started to implement the new composite assembly model I felt a need to adjust a little the folder structure under the Tuscany system root, did half of it, which triggered some questions :) This is a new thread to discuss these changes. Here's what we had in M1: $TUSCANY_SCAPP_SYSTEM_ROOT/ -- your Tuscany-system-root subsystems/ CalculatorSubsystem/ sca.subsystem -- creates and configures the Calculator module component modules/ Calculator -- the Calculator module and code sca.module other artifacts, *.so, *.wsdl, *.xsd etc. Now that the spec has removed subsystem, module and fragment, and generalized the use of composites, here's what I'd like to propose: deploy/ -- your Tuscany-system-root configuration/ CalculatorApp.composite -- creates the Calculator component, we don't need sub-folders here since we can give meaningful name to composite files now packages/ Calculator -- the Calculator composite and code Calculator.composite other artifacts, *.so, *.wsdl, *.xsd etc. - Configuration contains the composites included in your system creating and configuring your top level components. - Packages contains all your other development artifacts (not necessarily just composites that's why I'm proposing packages/ instead of modules/ or composites/). - I think that the samples should use consistent naming convenvions, but you should also be able to pick the names you want for your folders and artifacts and have Foo/Bar.composite containing composite name=Abc/ for example. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Pete, I'm OK too with a simpler structure without separate configuration/ and packages/. I was initially trying to build on the structure that we already have with separate subsystems and modules directories. On the other hand, I'm not sure how we'd handle the following scenario with all composites under a single structure: I have developed two composites, bigbank.account and bigbank.client (in 0.9 speak these would be modules). I install these two composites on my runtime. I now want to actually make them live. For this I need to create a new composite, let's call it bigbank. My bigbank composite declares two components (instances of bigbank.account and bigbank.client) configures them, and wires them together. With SCA 0.9 bigbank was a subsytem. I now have 3 composites on my runtime. How will we distinguish between bigbank (describing the composition and configuration of my system and used to create actual instances) and bigbank.account + bigbank.client (just describing composite implementations), once we have these 3 composites under a single folder structure? The other thing is that in the scenario above we probably have 3 different roles: - The developer putting
[jira] Updated: (TUSCANY-582) Date fields sometimes not preserved when using DataHelper.
[ http://issues.apache.org/jira/browse/TUSCANY-582?page=all ]
Brian Murray updated TUSCANY-582:
-
Attachment: Tuscany582.patch
The attached patch addresses the problem mentioned in this issue (Tuscany-582).
The change for this original problem is a one line fix (setting isLenient to
false). Previously, an earlier SimpleDateFormat in the list of possibilties
was matching for a String that should have matched the Day format.
It also includes changes to the toDate method to allow permitted variations
(e.g. incusion or exclusion of time zone) to be converted to a Date using
DataHelper.toDate(). Previously, many Strings that should give a valid result
from DateHelper.toDate() would have resulted in null.
I have created a test case that addresses both the original issue, as well as
the secondary issue also addressed. I will attach it shortly.
Would a committer please review the patch and test case and let me know of any
issues?
Date fields sometimes not preserved when using DataHelper.
--
Key: TUSCANY-582
URL: http://issues.apache.org/jira/browse/TUSCANY-582
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Brian Murray
Assigned To: Frank Budinsky
Priority: Minor
Attachments: Tuscany582.patch
While I find it mildly surprising that you can convert from a Day to a Date,
I would expect that in doing so the Day (Date.getDate()) value within Date
would be accurate (even if all other fields are meaningless).
// The output of each println (from a single run) is placed in comments
beside it
public void testShowErrorsInSimpleFashion() throws Exception
{
Date temp = new Date(System.currentTimeMillis());
// In following sequence - would expect the Day value (here, 21) to be
maintained.
System.out.println(temp = + temp); // temp = Fri Jul 21 03:51:01 EDT
2006
String day = data_helper.toDay(temp);
System.out.println(day = + day); // day = ---21 EDT
Date date2 = data_helper.toDate(day);
System.out.println(date2 = + date2); // date2 = Thu Feb 29 23:00:00
EST 1968
String day2 = data_helper.toDay(date2);
System.out.println(day2 = + day2); // day2 = ---29 EST
}
When I look in DataHelperImpl.java, I see a series of Date Patterns. It
seems that Day is being matched to an earlier pattern than the expected one
(the expected one is ---dd zz). When I move that pattern to first in the
list, the outcome is affected. Were it not matching an earlier pattern, I
would think that moving the correct one to the front of the list would not
have an effect.
Leaving DataHelperImpl.java unaltered, Day = 21 EDT, and Day2 = 29 EST (in
the case above). However, if I put the appropriate pattern first in the list,
Day2 is instead = 20 EST. Interestingly, it is still not the correct day
(21).
Frank pointed out that there have been recent updates to DataHelper, however
I've retested with build level 425652 and see the same behavior.
Side note:
The following is not a JIRA issue, but it is related. In the second table
on page 146 the Date conversions for most types are essentially to the same
type, to Date, and to String. It seems that several more are possible. The
following seem capable of being added:
DateTime- Month, MonthDay, YearMonth, YearMonthDay, Time, Year,
Duration, Day
Duration-Month, MonthDay, YearMonth, YearMonthDay, Time, Year,
DateTime, Day
MonthDay-Month, Day
YearMonth-Month, Year
YearMonthDay-Month, Year, Day, YearMonth, MonthDay
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
Ok I've added a TargetInvokerExtension. The clone method doesn't seem perfect yet as subclasses now aren't forced to implement clone by the compiler. ...ant On 8/10/06, Jim Marino [EMAIL PROTECTED] wrote: Yea we could do that. Probably the one invoke method that takes the payload from the message could be abstracted and if there is a special target type that needs access to message headers or something it could just override it. Do you want to create one as I'm out later today? Jim On Aug 10, 2006, at 5:35 AM, ant elder wrote: Great stuff Jim, these changes look really good to me. Makes implementing a binding way easier. What do you think about having an abstract SPI class for the TargetInvoker which includes all the cachable, optimizable and invoke methods? ...ant On 8/10/06, Jim Marino [EMAIL PROTECTED] wrote: I've checked in an example of a simple binding (r430211) that demonstrates creating services and references. For references, the binding just echoes a single param back to the client. Related to this, I've also completed a series of commits that move application wiring from the responsibility of the builders to initiate up into the builder registry which delegates to the system wire service. Once a Service, Reference, or Component is created and returned from a builder, the builder registry will invoke the wire service to create the appropriate inbound and outbound wires. These wires will then be injected into the Service, Reference or Component. At a later point, the connector will bridge outbound (source) to inbound (target) wires. Services and References will generally not need to do anything other than hold onto the wires (implemented as a convenience by the extension base classes), but components are responsible for implementing a strategy for injecting them onto implementation instances as the latter are requested. In the case of Java, this involves delegating back to the wire service to create a proxy fronting the wire and implementing the appropriate reference interface. This proxy will be injected onto an implementation instance as it is created. BPEL or an other implementation type may do something entirely different and maybe not even use proxies. Certain types of composite components may need to manually bridge Services to targets. For example, a Spring composite is opaque to the SCA wiring fabric in that its beans are not visible as components. The Spring builder is responsible for delegating to the builder registry to create a service which it then must provide with a target invoker capable of dispatching into the Spring application context and to a target bean. This can be viewed as the SCA wiring mechanism delegating to Spring for internal wiring. Jim - 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: using stdcxx in tuscany/C++
Martin Sebor wrote: Hi again, Just following up on this thread to see if there's anything we can do from our side to help you all with the migration, or any concerns or questions I can answer. I have noticed that some people are still using MSVC 6 to compile Tuscany. I'm curious whether there are any plans to upgrade to a more recent and more conforming compiler. Stdcxx is being tested with 7.1, and 8.0 (i86, IA64, and EM64T) but the 6.0 port would likely need some work. Regards Martin Martin, I downloaded your 4.1.3 release, compiled it on Redhat Enterprise Linux 4, and ran some of your samples. I have two questions: - How do I run all your test cases? I found a run executable in build/test, tried ./run ./* and got this: Summary: out of 69 programs 45 exited with non-zero status 24 failed to compile 0 failed to link 0 failed at least one assertion 0 exited with a signal 0 killed with signal 9 no regressions (this is baseline) 34% pass rate I'm assuming that the failures are my problem and I'm not running this correctly since all the samples I tried worked nicely :) - Also, I noticed that the build generates .a files. Is there an option to generate a .so shared library? Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Recommendation for sample composite names
Sounds good to me. I guess we leave the Calculator sample as is to show that we can manage either style? Andy On 8/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Here's a note from the SCA spec 0.95: Note: The Eclipse naming convention for plugins provides a good way to achieve unique names, e.g. com.mycompany.myvaluecomposite . This format is recommended but is not normative. I'd like to adjust our samples to follow that recommendation (e.g. bigbank.client, bigbank.account). What do you think? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-582) Date fields sometimes not preserved when using DataHelper.
[ http://issues.apache.org/jira/browse/TUSCANY-582?page=all ]
Brian Murray updated TUSCANY-582:
-
Attachment: DateConversionTestCase.java
Attached is the test case that uncovered the original issue and has been used
to verify both the fix for that defect as well as the other defect mentioned
above. Please let me know of any concerns.
Date fields sometimes not preserved when using DataHelper.
--
Key: TUSCANY-582
URL: http://issues.apache.org/jira/browse/TUSCANY-582
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Brian Murray
Assigned To: Frank Budinsky
Priority: Minor
Attachments: DateConversionTestCase.java, Tuscany582.patch
While I find it mildly surprising that you can convert from a Day to a Date,
I would expect that in doing so the Day (Date.getDate()) value within Date
would be accurate (even if all other fields are meaningless).
// The output of each println (from a single run) is placed in comments
beside it
public void testShowErrorsInSimpleFashion() throws Exception
{
Date temp = new Date(System.currentTimeMillis());
// In following sequence - would expect the Day value (here, 21) to be
maintained.
System.out.println(temp = + temp); // temp = Fri Jul 21 03:51:01 EDT
2006
String day = data_helper.toDay(temp);
System.out.println(day = + day); // day = ---21 EDT
Date date2 = data_helper.toDate(day);
System.out.println(date2 = + date2); // date2 = Thu Feb 29 23:00:00
EST 1968
String day2 = data_helper.toDay(date2);
System.out.println(day2 = + day2); // day2 = ---29 EST
}
When I look in DataHelperImpl.java, I see a series of Date Patterns. It
seems that Day is being matched to an earlier pattern than the expected one
(the expected one is ---dd zz). When I move that pattern to first in the
list, the outcome is affected. Were it not matching an earlier pattern, I
would think that moving the correct one to the front of the list would not
have an effect.
Leaving DataHelperImpl.java unaltered, Day = 21 EDT, and Day2 = 29 EST (in
the case above). However, if I put the appropriate pattern first in the list,
Day2 is instead = 20 EST. Interestingly, it is still not the correct day
(21).
Frank pointed out that there have been recent updates to DataHelper, however
I've retested with build level 425652 and see the same behavior.
Side note:
The following is not a JIRA issue, but it is related. In the second table
on page 146 the Date conversions for most types are essentially to the same
type, to Date, and to String. It seems that several more are possible. The
following seem capable of being added:
DateTime- Month, MonthDay, YearMonth, YearMonthDay, Time, Year,
Duration, Day
Duration-Month, MonthDay, YearMonth, YearMonthDay, Time, Year,
DateTime, Day
MonthDay-Month, Day
YearMonth-Month, Year
YearMonthDay-Month, Year, Day, YearMonth, MonthDay
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
I think we use our samples to demonstrate different ways of working - have the Calculator be deployed in a single directory and have the BigBank show the use of multiple directories. So perhaps have configuration, packages/account and packages/client directories under the root directory? What do you think? Andy On 8/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: Can't we allow both ways of working? i.e. with or without subdirectory structures? As long as we recurse into directories looking for any .composite files then it should still work (as long as we check for name clashes, etc). Then it's up to users how they package their projects - they can follow structures that make most sense to them. Andy Yes, makes sense. I agree that users should be free to package their projects in the way that makes most sense to them. We can only show and recommend some practices in our samples. So I guess the only remaining question is: one big root directory, or two configuration/ and packages/ directories, and how do we handle my little Bigbank deployment scenario below :) On 8/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: A lot of things referenced from a .composite are a path relative to the .composite file (the compsite root). This is defined in the spec. For example, component name=MyValueServiceComponent implementation.cpp library=MyValuelibrary path=MyValue header=MyValue/MyValueImpl.h/implementation.cpp so if the composite file is in .../deploy/configuration/myValue.composite the library will be located at .../deploy/configuration/MyValue/libMyValuelibrary.so. Similarly the implementation header will be located at .../deploy/configuration/MyValue/MyValueImpl.h ...so I don't think you can have an arbitrary separation of configuration and packages. I think we can use a very simple deployment which is that the runtime will find all the composites under the system root so it could look like: .../deploy fred.composite ( composite name=abc/ ) some_other_artifacts /ANOtherCompo joe.composite ( composite name=xyz/ ) /joes_libraries joe.dll So the name of the folder and composite file is irrelevent as the actual composite name comes from the scdl name=. This, of course, is a little harder for the runtime to load but a lot simpler for the user IMO. So for a MyValue sample I'd develop my composites in a structure that matches the deploy layout. This is necessary for the scagen step that requires the scdl and the interface headers to generate the proxies and wrappers. This strcture may or may not have multiple directories at the choice of the developer, he may want each component in a separate dir for instance. Deployment is simply copying the scdl, libraries and headers to wherever they are to be deployed. (Although the headers are not currently used at runtime it is possible that they may be in the future). So I may end up with: .../MyValue myValue.composite myVal.componentType /CustomerInfo custinfo.componentType custinfo.h etc.. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: When I started to implement the new composite assembly model I felt a need to adjust a little the folder structure under the Tuscany system root, did half of it, which triggered some questions :) This is a new thread to discuss these changes. Here's what we had in M1: $TUSCANY_SCAPP_SYSTEM_ROOT/ -- your Tuscany-system-root subsystems/ CalculatorSubsystem/ sca.subsystem -- creates and configures the Calculator module component modules/ Calculator -- the Calculator module and code sca.module other artifacts, *.so, *.wsdl, *.xsd etc. Now that the spec has removed subsystem, module and fragment, and generalized the use of composites, here's what I'd like to propose: deploy/ -- your Tuscany-system-root configuration/ CalculatorApp.composite -- creates the Calculator component, we don't need sub-folders here since we can give meaningful name to composite files now packages/ Calculator -- the Calculator composite and code Calculator.composite other artifacts, *.so, *.wsdl, *.xsd etc. - Configuration contains the composites included in your system creating and configuring your top level components. - Packages contains all your other development artifacts (not necessarily just composites that's why I'm proposing packages/ instead of modules/ or composites/). - I think that the samples should use consistent naming convenvions, but you should also be able to pick the names you want for your folders and artifacts and have Foo/Bar.composite containing composite name=Abc/ for example. Any thoughts? -- Jean-Sebastien
New woodstox release
While we talking about moving to more recent releases of things, there's a Woodstox 3.0 out now, should we look at upgrading to that as well? Probably not too hard a change if some budding contributor wants to check out if its an easy upgrade and submit a patch when Woodstox hits a maven repos. Or should we stick with 2.9.3 for now while we know it works fine? ..ant
Compile errors in Eclipse
When I set up the Tuscany eclipse projects with mvn -Peclipse eclipse:eclipse there are some compile errors in the eclipse projects. One in the Groovy container: The method andReturn(capture-of ?) in the type IExpectationSetterscapture-of ? is not applicable for the arguments (String)PropertyTestCase.java groovy/src/test/java/org/apache/tuscany/container/groovyline 5211 August 2006 12:54:0411027 and half a dozen of these errors in the databinding code: Type mismatch: cannot convert from DirectedGraphString,Object.Vertex to DirectedGraphV,E.VertexDirectedGraphTestCase.java databinding-framework/src/test/java/org/apache/tuscany/databinding/impl line 4711 August 2006 12:53:3610535 The code compiles fine outside of eclipse with mvn, so I guess this is an eclipse compiler thing. Do others see these in eclipse or know how to fix them? ...ant
Re: Moving WS binding from Axis 2.0 release to an Axis2 SNAPSHOT build
Well with some hacks I have been able to get the client (reference) to execute a web service. With what I checked in the server side was also loaded but there are some configuring issues I haven't looked at but they are axis related and something that may even be different with a newer version of Axis. So I guess I'm saying is if no other issues and using snap shots of Axis is the way to go... let the fun begin:-) I'm actually available to help out now.. I was thinking we could split server/client, how does that sound? If we want we could work on this in a branch so as to not disrupt others. ant elder wrote: There was an offline chat yesterday about moving up to a newer Axis2 build to pick up some recent fixes. I'm a bit nervous about doing this right now while Rick is in the middle of trying to get the WS binding to go, and while the WS binding doesn't really work yet so we wont be able to easily confirm our code still works with the newer Axis2. How should we do this? Should we have a known SNAPSHOT build that we keep in a private maven repository like we did pre-M1? Should I just go ahead and make the necessary changes or wait till you're at some clean point Rick? Should I wait till we have a service and reference working before upgrading so we can know if the upgrade causes us any problems? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Do we need SDO annotations in the SCDL XSDs?
Yes, the SDO Xpath support was always one of those 'must rewrite when theres
time' items.
It doesnt support dots in property names, as it uses the . or a [ to
indicate that the property being referenced is a many-valued property and
must be accessed via getList, using the index following the . or [.
I guess a better solution would be to take the element of the path between
path separators, and first validate whether the element is an expected
property of the current object. If it is just use it, otherwise see of the
last lump of the element is an index, and try again with the remainder of
the element.
It would be interesting to see what the current java implementation makes
of:
data object type bar
{
property fred - type DataObject.
}
data object type foo
{
property a.property.name - many valued data object of type bar
property a.property.name.1 - single valued data object
}
foo-getDataObject(a.property.name.2); // getting from the array
foo-getDataObject(a.property.name.1); // getting from the single value
foo-getDataObject(a.property.name.1/fred); // getting from element 1 of
the array
BTW - in terms of 'special characters' I assumed it meant path separators -
I guess theres no requirement to have a property name like this/property?
cheers,
Ed.
On 09/08/06, Pete Robbins [EMAIL PROTECTED] wrote:
Good! because the SDO XPath code looks a bit messy :-(
Cheers,
On 09/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
Pete Robbins wrote:
I'll take a look at the XPath stuff in SDO and see if we can avoid
the
annotations for the new assembly model schema. It may not be simple
so we
may have to annotate the schema to start with and fix this later.
Cheers,
OK, let me know. If it turns out that we need the annotations to start
with as a workaround to this issue with dots, then no problem I'll add
them. Thanks.
Interesting how sometimes expected design issues turn into non-issues
once you actually write code :) I tried to use the XSDs without
annotations, and... everything works!
This is because the ModelLoader works with the base XSD complex types
and substitution groups, which contain no dots in their names. We never
do DataObject.get(interface.cpp) for example, we only do
DataObject.get(interface)... So there was no problem after all :) we
don't need any annotations in the SCDL XSDs.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
Re: [C++] Do we need SDO annotations in the SCDL XSDs?
On 11/08/06, Edward Slattery [EMAIL PROTECTED] wrote:
Yes, the SDO Xpath support was always one of those 'must rewrite when
theres
time' items.
It doesnt support dots in property names, as it uses the . or a [ to
indicate that the property being referenced is a many-valued property and
must be accessed via getList, using the index following the . or [.
I guess a better solution would be to take the element of the path between
path separators, and first validate whether the element is an expected
property of the current object. If it is just use it, otherwise see of the
last lump of the element is an index, and try again with the remainder of
the element.
It would be interesting to see what the current java implementation makes
of:
data object type bar
{
property fred - type DataObject.
}
data object type foo
{
property a.property.name - many valued data object of type bar
property a.property.name.1 - single valued data object
}
foo-getDataObject(a.property.name.2); // getting from the array
foo-getDataObject(a.property.name.1); // getting from the single value
foo-getDataObject(a.property.name.1/fred); // getting from element 1 of
the array
Fuhwei answered this above and I think it's a reasonable approach (and I
think what you are suggesting):
First, it checks whether a.property.name.1 is a valid property name. If
yes, getDataObject() would return the value of a.property.name.1 otherwise
it treats a.property.name.1 as an XPath string.
Cheers,
--
Pete
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Hmm, ok, first off a bit of clarification on the terminology. When I say local callback (or plain invocation) via a reference, I was thinking about the case of a component in a composite talking to a component in another composite via their respective composite reference and service, where both composites are contained in a third (larger) composite, all in the same process or machine. Perhaps this is not a valid or considered use case but it seems to be different from a wire between two components, and from a wire whose target is a reference that has a remote binding, e.g., ws. Wires between components are already taken care of. A wire to a reference with a remote binding needs to involve the Reference (or Service) defined by the appropriate binding, e.g., Axis2Reference (or Axis2Service). But before we get there I thought we were trying to take care of the 'local via a reference' case as above. If this is something we intend to do I am open to the idea of not requiring a JavaReference or a JavaService. However, two things come to mind: (1) A Reference on a composite in this case may represent an external service but not a remote one, i.e., a service external to the composite but local wrt the process or machine. If this is a valid scenario, then one question is what is the binding to be used by this reference? Can it be plugged in depending on deployment scenario? If such scenario is as above then binding.ws or some such may not be appropriate, what's the alternative, binding.sca or even something like binding.java? (2) If what we are doing is connecting two composites in the same machine via their respective Reference and Service as above, then the target invoker for the Reference of the source composite needs to behave like the target invoker for an atomic component with the difference that no user-defined logic is invoked, only the proxy for the Reference's outbound wire. Perhaps this is what you meant by optimizing away a JavaReference and only using a proxy. But the optimization seems to be dependent on the Reference's binding, i.e., whether it is a remote binding (e.g., ws) or not (as above). Hopefully things are not getting more confused. Thanks - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 10, 2006 10:42 PM Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks On Aug 10, 2006, at 8:37 AM, Ignacio Silva-Lepe wrote: Sure, I want to make sure I understand what local callbacks (or plain invocations for that matter) via references means. I was defining a local callback as being a bidirectional wire to a target component, which (by definition) is in the same composite. A wire whose target is a reference would be a remote callback since the invocation flows outside a composite. For local callbacks, we don't need to persist ids and have more control of things (lifecycle, thread dispatching, by-ref, etc.). For remote callbacks, I don't think we should allow direct wiring to a child component in another composite as that breaks visibility rules for composites. Rather, I was thinking we would need to design for a durable store to be able to map back to the callback wire and target instance (target instance id may be able to be calculated using an FQN of its component name in the composite hierarchy). On the outbound leg, the reference target invoker would persist the id to wire chain mapping. The binding would be responsible for flowing the ids. In this case, references act as services and services act as references during a callback and would have to re-associate the ids with invocation chains. A ReferenceExtension is built wrt a binding, e.g., Axis2Reference. So for 'local' we treat the binding as a (dummy) special case and wire directly to a component's or a composite's service, as in EchoReference but more fleshed out. Similarly, for service, which for local could be wired from a component's or a composite's reference. If this makes sense, then it means we need new JavaReference, JavaService and JavaBindingBuilder implementations that don't currently exist and that use a dummy JavaBinding similar to EchoBinding. I may be misunderstanding but for the local case, I think things are conceptually the same but there are some optimizations and implementation differences that do not require us to have JavaReference or JavaService. References on composites are just representations of some external service and are responsible for dispatching an invocation to it over a binding. Similarly, a reference on a Java component is just a representation of the target service and the binding can be considered something like pass-by- reference or vm. However, implementations vary with the composite reference being realized as a Reference and a Java component reference being just a proxy. I don't think we need the extra step of
Re: [C++] Do we need Tuscany-model.config?
In the Java version we are using WSDL2.0's wsdlLocation feature: http://www.w3.org/TR/wsdl20/#wsdlLocation-aii For an example of how a service would look you might check this thread: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/% [EMAIL PROTECTED] -- Jeremy On Aug 11, 2006, at 12:57 AM, Pete Robbins wrote: of course this supposes that all the schema and wsdl is local. We probably need to support the case where the wsdl is remote e.g. http://mySite/flobber.wsdl Cheers, On 11/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Actually the wsdl/xsd are loaded for a particular composite so if there were more say 2 .composites in a folder and 3 xsds we would load all 3 xsds twice, once for each composite. On 11/08/06, Pete Robbins [EMAIL PROTECTED] wrote: so we load any wsdl/xsd in the same folder as the .composite file? Sounds reasonable. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: This is similar to what Java had. I think htis is replaced by include.wsdl and include.xsd or soemthing. Not sure if this got into the spec. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: It looks like Tuscany-model.config just lists the WSDLs and XSDs used in an application. Do we still need it? or could we just figure out ourselves what the WSDLs and XSDs are? Just trying to make it simpler for users to write SCA applications, and limit the number of things that they have to worry about... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: tuscany-dev- [EMAIL PROTECTED] As far as I know include.wsdl and include.xsd are not in the spec yet. I'm actually thinking that placing the WSDL and XSD files in the directory containing the application should be enough to indicate that they should be used. In other words, no need to edit an XML file telling the runtime that some WSDL and XSD files are there, the runtime should be smart enough to just scan and find them... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete -- Pete -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Do we need Tuscany-model.config?
I really like that auto discovery of WSDL without having to explicitly have anything pointing to it in the scdl. Didn't the really old Java code that was first given to Apache work like this? I think Ken has also mentioned that the JAXWS binding he's doing will work like that as well. Probably there still needs to be a way to explicitly define this in the SCDL, i did like the old import.wsdl way that the Java M1 code had, it was much nicer than the tuscany-model.config we used to use and i think it makes things clearer than having a wsdlLocation on the interface.wsdl or biniding.wselements. Whatever we do we should try to keep this consistent across the Java and C++ runtimes. ...ant On 8/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ As far as I know include.wsdl and include.xsd are not in the spec yet. I'm actually thinking that placing the WSDL and XSD files in the directory containing the application should be enough to indicate that they should be used. In other words, no need to edit an XML file telling the runtime that some WSDL and XSD files are there, the runtime should be smart enough to just scan and find them... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving WS binding from Axis 2.0 release to an Axis2 SNAPSHOT build
Could you describe how to get the ws client sample running? I'll just have a go moving to a snapshot build on my local machine and see if there's any issues. Don't think we need a branch or to split this btw client and service just yet, it may end up being quite a painless upgrade ...ant On 8/11/06, Rick [EMAIL PROTECTED] wrote: Well with some hacks I have been able to get the client (reference) to execute a web service. With what I checked in the server side was also loaded but there are some configuring issues I haven't looked at but they are axis related and something that may even be different with a newer version of Axis. So I guess I'm saying is if no other issues and using snap shots of Axis is the way to go... let the fun begin:-) I'm actually available to help out now.. I was thinking we could split server/client, how does that sound? If we want we could work on this in a branch so as to not disrupt others. ant elder wrote: There was an offline chat yesterday about moving up to a newer Axis2 build to pick up some recent fixes. I'm a bit nervous about doing this right now while Rick is in the middle of trying to get the WS binding to go, and while the WS binding doesn't really work yet so we wont be able to easily confirm our code still works with the newer Axis2. How should we do this? Should we have a known SNAPSHOT build that we keep in a private maven repository like we did pre-M1? Should I just go ahead and make the necessary changes or wait till you're at some clean point Rick? Should I wait till we have a service and reference working before upgrading so we can know if the upgrade causes us any problems? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
On Aug 11, 2006, at 2:04 AM, ant elder wrote:
Ok I've added a TargetInvokerExtension. The clone method doesn't seem
perfect yet as subclasses now aren't forced to implement clone by the
compiler.
I've not had coffee yet but AIUI you don't need to override clone in
subclasses unless you need a deep copy. The way it is implemented at
the moment does an unnecessary copy of the cacheable field (as that
member will be cloned by the implementation in Object.clone()).
Something like this should work:
Index: spi/src/main/java/org/apache/tuscany/spi/extension/
TargetInvokerExtension.java
===
--- spi/src/main/java/org/apache/tuscany/spi/extension/
TargetInvokerExtension.java (revision 430795)
+++ spi/src/main/java/org/apache/tuscany/spi/extension/
TargetInvokerExtension.java (working copy)
@@ -54,10 +54,13 @@
return isCacheable();
}
-public Object clone() throws CloneNotSupportedException {
-TargetInvokerExtension clonedInvoker =
(TargetInvokerExtension) super.clone();
-clonedInvoker.cacheable = this.cacheable;
-return clonedInvoker;
+public Object clone() {
+try {
+return super.clone();
+} catch (CloneNotSupportedException e) {
+// TargetInvoker extends Cloneable so this should not
have been thrown
+throw new AssertionError(e);
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
I did wonder about this, doesn't it need to be a deep copy? I don't really
understand the purpose of cacheable, but if its set on the one instance
shouldn't it be also set on the clone? And do subclasses need to copy their
fields? Say the RMI binding was using this abstract class should it setting
the remoteMethod field on the clone?
...ant
On 8/11/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
On Aug 11, 2006, at 2:04 AM, ant elder wrote:
Ok I've added a TargetInvokerExtension. The clone method doesn't seem
perfect yet as subclasses now aren't forced to implement clone by the
compiler.
I've not had coffee yet but AIUI you don't need to override clone in
subclasses uouldnless you need a deep copy. The way it is implemented at
the moment does an unnecessary copy of the cacheable field (as that
member will be cloned by the implementation in Object.clone()).
Something like this should work:
Index: spi/src/main/java/org/apache/tuscany/spi/extension/
TargetInvokerExtension.java
===
--- spi/src/main/java/org/apache/tuscany/spi/extension/
TargetInvokerExtension.java (revision 430795)
+++ spi/src/main/java/org/apache/tuscany/spi/extension/
TargetInvokerExtension.java (working copy)
@@ -54,10 +54,13 @@
return isCacheable();
}
-public Object clone() throws CloneNotSupportedException {
-TargetInvokerExtension clonedInvoker =
(TargetInvokerExtension) super.clone();
-clonedInvoker.cacheable = this.cacheable;
-return clonedInvoker;
+public Object clone() {
+try {
+return super.clone();
+} catch (CloneNotSupportedException e) {
+// TargetInvoker extends Cloneable so this should not
have been thrown
+throw new AssertionError(e);
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving WS binding from Axis 2.0 release to an Axis2 SNAPSHOT build
run.bat ... ran it against old M1 server. Right now it set for just that sample.. there is a hack there where I suspect the databinding will generate the method/parameter elements as it once did to conform to the wsdl.. ant elder wrote: Could you describe how to get the ws client sample running? I'll just have a go moving to a snapshot build on my local machine and see if there's any issues. Don't think we need a branch or to split this btw client and service just yet, it may end up being quite a painless upgrade ...ant On 8/11/06, Rick [EMAIL PROTECTED] wrote: Well with some hacks I have been able to get the client (reference) to execute a web service. With what I checked in the server side was also loaded but there are some configuring issues I haven't looked at but they are axis related and something that may even be different with a newer version of Axis. So I guess I'm saying is if no other issues and using snap shots of Axis is the way to go... let the fun begin:-) I'm actually available to help out now.. I was thinking we could split server/client, how does that sound? If we want we could work on this in a branch so as to not disrupt others. ant elder wrote: There was an offline chat yesterday about moving up to a newer Axis2 build to pick up some recent fixes. I'm a bit nervous about doing this right now while Rick is in the middle of trying to get the WS binding to go, and while the WS binding doesn't really work yet so we wont be able to easily confirm our code still works with the newer Axis2. How should we do this? Should we have a known SNAPSHOT build that we keep in a private maven repository like we did pre-M1? Should I just go ahead and make the necessary changes or wait till you're at some clean point Rick? Should I wait till we have a service and reference working before upgrading so we can know if the upgrade causes us any problems? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
On Aug 11, 2006, at 7:36 AM, ant elder wrote: I did wonder about this, doesn't it need to be a deep copy? I don't really understand the purpose of cacheable, but if its set on the one instance shouldn't it be also set on the clone? And do subclasses need to copy their fields? Say the RMI binding was using this abstract class should it setting the remoteMethod field on the clone? http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone() And remember deep copy only applies to mutable objects -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
I'm not sure I understand what you're trying to say? The JavaDoc for TargetInvoker.clone says Implementations must support deep cloning. ...ant On 8/11/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 11, 2006, at 7:36 AM, ant elder wrote: I did wonder about this, doesn't it need to be a deep copy? I don't really understand the purpose of cacheable, but if its set on the one instance shouldn't it be also set on the clone? And do subclasses need to copy their fields? Say the RMI binding was using this abstract class should it setting the remoteMethod field on the clone? http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone() And remember deep copy only applies to mutable objects -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-197) Fix Java5 warnings with references to un-parameterized ComponentT
[ http://issues.apache.org/jira/browse/TUSCANY-197?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-197: -- Assignee: (was: Jean-Sebastien Delfino) Fix Java5 warnings with references to un-parameterized ComponentT --- Key: TUSCANY-197 URL: http://issues.apache.org/jira/browse/TUSCANY-197 Project: Tuscany Issue Type: Sub-task Components: Java SCA Model Affects Versions: Java-Mx Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-Mx We need to fix the Java5 compiler warnings caused by references to un-parameterized ComponentT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Status of the MyValue sample
I'm not sure if the old MyValue sample actually builds or works at all. Do you want to keep it? or would it be better to just remove it for now to minimize work (since it's old, not used in the spec anymore and duplicates some of Bigbank) and instead get new interesting scenarios to work? What do you think? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding an interceptor
On Aug 10, 2006, at 3:13 PM, Raymond Feng wrote: Hi, I'm exploring the possibility to add interceptors to deal with data binding transformations. It seems that PolicyBuilder is one place that interceptors can be added to the invocation chain. Can other builders (such as component builders and binding builders) contribute interceptors as well? I read the code briefly and found out the wires are not connected when the builders are invoked. Yes the interceptors are added before the connect phase. Do you need knowledge of both ends of the wire? If so, we may have to look at moving the PolicyBuilder into the connector, which wouldn't be that big of a deal. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using stdcxx in tuscany/C++
Jean-Sebastien Delfino wrote: [...] I downloaded your 4.1.3 release, compiled it on Redhat Enterprise Linux 4, and ran some of your samples. I have two questions: - How do I run all your test cases? Unfortunately, in 4.1.3 you need to run them one at a time by hand (the stdcxx test suite was and still is being migrated from the Rogue Wave test harness and so things have been a bit in flux). Alternatively, you can try applying the following patch to see if it resolves the problem: http://svn.apache.org/viewvc?view=revrevision=419995 This is resolved on trunk (where make run works again). I found a run executable in build/test, tried ./run ./* and got this: Invoking the run script directly will work but using make run is the recommended way to run the tests and examples (and locales). Summary: out of 69 programs 45 exited with non-zero status The tests fail due to incompatible command line options being passed to them by the test harness. This is the subject of the already fixed STDCXX-254: http://issues.apache.org/jira/browse/STDCXX-254. 24 failed to compile I'm not sure what exactly is behind these failures but it's not anything in the library. 0 failed to link 0 failed at least one assertion 0 exited with a signal 0 killed with signal 9 no regressions (this is baseline) 34% pass rate I'm assuming that the failures are my problem and I'm not running this correctly since all the samples I tried worked nicely :) They're not your problem but they're nothing to worry about, either. FWIW, we're working on publishing stdcxx test results across all our platforms. This project is very much in a proof of concept stage but you can get a glimpse of what it might look like here (ignore the links on the page, they are not functional yet): http://people.apache.org/~sebor/stdcxx-results.html - Also, I noticed that the build generates .a files. Is there an option to generate a .so shared library? Yes, there certainly is. For now you can use the BUILDMODE make variable. In the (near) future we also plan to provide a configure like interface to the build infrastructure to let people use the usual --enable-xxx switches (such as --enable-shared). The BUILDMODE variable is specified as taking a build-mode argument defined in the README as follows: build-mode is a comma-separated list of keywords describing how to build the library and the rest of the binaries. The following arguments are recognized: dcethreads - create a thread-safe library, use DCE threads debug - include debugging information optimized - optimized pthreads - create a thread safe library, use POSIX threads shared - create a shared library (archive is default) shared,archive - create an AIX shared archive threads - create a thread-safe library, use Solaris threads wide - generate wide (64-bit) code Read the full details here: http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/etc/config/README Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Status of the MyValue sample
It's not currently built. I was actually experimenting with it as a development - deployment sample so that I could write a how to article. Time got in the way though! I may resurrect it using the recursive model at some point. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm not sure if the old MyValue sample actually builds or works at all. Do you want to keep it? or would it be better to just remove it for now to minimize work (since it's old, not used in the spec anymore and duplicates some of Bigbank) and instead get new interesting scenarios to work? What do you think? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: Compile errors in Eclipse
Hi, I'm seeing the same error on Groovy container inside Eclipse. And the following diff fixes the complaint (I assume the existing code is valid). -expect(factory.getInstance()).andReturn(bar); +expect((String) factory.getInstance()).andReturn(bar); I also ran into an issue that Eclipse cannot recognize MapString, InboudWire. It seems that it's an eclipse bug. BTW, I'm running Eclipse 3.2. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 11, 2006 5:03 AM Subject: Compile errors in Eclipse When I set up the Tuscany eclipse projects with mvn -Peclipse eclipse:eclipse there are some compile errors in the eclipse projects. One in the Groovy container: The method andReturn(capture-of ?) in the type IExpectationSetterscapture-of ? is not applicable for the arguments (String)PropertyTestCase.java groovy/src/test/java/org/apache/tuscany/container/groovyline 5211 August 2006 12:54:0411027 and half a dozen of these errors in the databinding code: Type mismatch: cannot convert from DirectedGraphString,Object.Vertex to DirectedGraphV,E.VertexDirectedGraphTestCase.java databinding-framework/src/test/java/org/apache/tuscany/databinding/impl line 4711 August 2006 12:53:3610535 The code compiles fine outside of eclipse with mvn, so I guess this is an eclipse compiler thing. Do others see these in eclipse or know how to fix them? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compile errors in Eclipse
On Aug 11, 2006, at 9:48 AM, Raymond Feng wrote: Hi, I'm seeing the same error on Groovy container inside Eclipse. And the following diff fixes the complaint (I assume the existing code is valid). -expect(factory.getInstance()).andReturn(bar); +expect((String) factory.getInstance()).andReturn(bar); I also ran into an issue that Eclipse cannot recognize MapString, InboudWire. It seems that it's an eclipse bug. BTW, I'm running Eclipse 3.2. FWIW I do not get any errors reported by IDEA. With IDEA and the compiler not having a problem I would agree this looks like an Eclipse bug. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving WS binding from Axis 2.0 release to an Axis2 SNAPSHOT build
Rick, I've had a look at the latest Axis2 snapshot builds and it doesn't seem so bad, just a few changes and it all compiles ok in eclipse. Haven't got your WS client sample running yet but hopefully will soon and I'll looking at moving to the snapshot builds over the weekend or maybe Monday. I'll watch out for you on IRC over the weekend to coordinate with what you're doing. ...ant On 8/11/06, ant elder [EMAIL PROTECTED] wrote: Could you describe how to get the ws client sample running? I'll just have a go moving to a snapshot build on my local machine and see if there's any issues. Don't think we need a branch or to split this btw client and service just yet, it may end up being quite a painless upgrade ...ant On 8/11/06, Rick [EMAIL PROTECTED] wrote: Well with some hacks I have been able to get the client (reference) to execute a web service. With what I checked in the server side was also loaded but there are some configuring issues I haven't looked at but they are axis related and something that may even be different with a newer version of Axis. So I guess I'm saying is if no other issues and using snap shots of Axis is the way to go... let the fun begin:-) I'm actually available to help out now.. I was thinking we could split server/client, how does that sound? If we want we could work on this in a branch so as to not disrupt others. ant elder wrote: There was an offline chat yesterday about moving up to a newer Axis2 build to pick up some recent fixes. I'm a bit nervous about doing this right now while Rick is in the middle of trying to get the WS binding to go, and while the WS binding doesn't really work yet so we wont be able to easily confirm our code still works with the newer Axis2. How should we do this? Should we have a known SNAPSHOT build that we keep in a private maven repository like we did pre-M1? Should I just go ahead and make the necessary changes or wait till you're at some clean point Rick? Should I wait till we have a service and reference working before upgrading so we can know if the upgrade causes us any problems? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding extension example
What I am saying is that the documentation on clone() is quite explicit about what it does and answers the questions that you raised. this method creates a new instance of the class of this object and initializes all its fields with exactly the contents of the corresponding fields of this object, as if by assignment; the contents of the fields are not themselves cloned In other words, the object itself is duplicated at a low level by the VM (allowing it to do things like clone final fields). This has the effect of copying all primitives and object references. This is a shallow copy because only the references to objects are copied and not their nested contents. This is ok if a class contains only primitive fields or references to immutable objects and means that no fields in the object returned by super.clone need to be modified. So in this case where the only field cacheable is a primitive it does not need to be set on the clone. Because Object.clone() applies to the entire object this behaviour also applies to all subclasses. Only when a field contains a reference to a mutable object does the subclass need to worry about doing a deep copy of that referenced object. As for RMIInvoker, the remoteMethod field is of type Method which is effectively immutable and so does not need to be deep copied. -- Jeremy On Aug 11, 2006, at 7:53 AM, ant elder wrote: I'm not sure I understand what you're trying to say? The JavaDoc for TargetInvoker.clone says Implementations must support deep cloning. ...ant On 8/11/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 11, 2006, at 7:36 AM, ant elder wrote: I did wonder about this, doesn't it need to be a deep copy? I don't really understand the purpose of cacheable, but if its set on the one instance shouldn't it be also set on the clone? And do subclasses need to copy their fields? Say the RMI binding was using this abstract class should it setting the remoteMethod field on the clone? http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone() And remember deep copy only applies to mutable objects -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-615) The SCDL syntax for reference doesn't conform to SCA spec 0.95
The SCDL syntax for reference doesn't conform to SCA spec 0.95 -- Key: TUSCANY-615 URL: http://issues.apache.org/jira/browse/TUSCANY-615 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Raymond Feng Assigned To: Raymond Feng Priority: Critical Attachments: rfeng-scdl.txt With Rick check-in of r430621, I'm seeing the EchoBinding test case is failing with the following exception: org.apache.tuscany.spi.loader.InvalidReferenceException: No target for service [ClientService] at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java) at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java:1) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:75) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:50) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:107) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:46) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:20) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:157) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:111) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:90) at org.apache.tuscany.core.launcher.Launcher.bootApplication(Launcher.java:171) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:63) at echo.BootstrapTestCase.setUp(BootstrapTestCase.java:23) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I adjusted the scdl file per SCA 0.95 spec: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=echo.sample service name=ClientService interface.java class=echo.Client/ binding.echo/ referenceClient/reference /service component name=Client implementation.java class=echo.ClientImpl/ reference name=echoReferenceEchoReference/reference /component reference name=EchoReference interface.java interface=echo.Echo/ binding.echo/ /reference /composite Now the ServiceLoader.java is problematic because it assumes it'll get reference before the binding which is not case per SCA 0.95 spec: service name=xs:NCName multiplicity=0..1 or 1..1 or 0..n or 1..n?* interface/ binding uri=xs:anyURI?/* referencewire-target-URI/reference+ /service component name=xs:NCName* implementation/ property name=xs:NCName source=sca:Property?* property-value /property reference name=xs:NCName/* wire-target-URI /reference /component The ComponentLoader.java cannot handle the reference element either since the SCA spec 0.95 also use the element content instead of target attribute. I attached a patch to fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Improved site look and feel
Hello everyone, The recent changes to the main site included a number of modifications to the site's content, but the look and feel of the site seems to have slipped . I feel In order to attract people into the site and get them to actually read that content, it needs to be presented in an appealing manner. So I've started working on addressing this problem. I've attached a mockup (no HTML yet) of a possible revision to the site. I tried to take the logo and continue down that line with rounded corners and a light green theme. http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/SiteMock%288-11-06%29.png?1155321723.49 Please let me know what you think and if you have any ideas. -David W
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
I have a feeling there may be some confusion here with terminology - heck, I know I'm confused :-) I think there are several scenarios here and would like to make sure they are all being covered. 1) Component-Component - this must lie within a Composite and may have local or remote semantics 2) Component-Reference with remote Binding - the wire lies within a Composite and disappears into the remote binding 3) Component-Reference wired by the Composite - there is a local wire between the Component and the Reference and an external wire from the CompositeComponent to a sibling Component or Reference (aka the uncle) I believe cases 1) and 2) are well covered. A target SCAObject is created with an inbound wire which is then connected to an outbound wire from the source. The resulting connection may be optimized away, or may have policy or other interceptors applied. I am confused about how case 3) is being handled, specifically how the connection is being made between the Reference and the CompositeComponent. I think there is a good case to me made for having an SCAObject to represent the Reference - for example, you may want to manage the reference in some way. Having it there does not mean that it needs to be part of the invocation path. For example, during connection the wire could be optimized in a way that allowed the uncle to be directly injected into the source. Perhaps JavaReference is confusing here - how about we call it a CompositeReference, as in a Reference whose wiring is handled by the composite component that contains it. This would work in conjunction with a CompositeComponent to pass wires around - for example, CompositeComponent.addOutboundWire could just delegate down to the appropriate CompositeReference (selected by name). -- Jeremy On Aug 11, 2006, at 6:46 AM, Ignacio Silva-Lepe wrote: Hmm, ok, first off a bit of clarification on the terminology. When I say local callback (or plain invocation) via a reference, I was thinking about the case of a component in a composite talking to a component in another composite via their respective composite reference and service, where both composites are contained in a third (larger) composite, all in the same process or machine. Perhaps this is not a valid or considered use case but it seems to be different from a wire between two components, and from a wire whose target is a reference that has a remote binding, e.g., ws. Wires between components are already taken care of. A wire to a reference with a remote binding needs to involve the Reference (or Service) defined by the appropriate binding, e.g., Axis2Reference (or Axis2Service). But before we get there I thought we were trying to take care of the 'local via a reference' case as above. If this is something we intend to do I am open to the idea of not requiring a JavaReference or a JavaService. However, two things come to mind: (1) A Reference on a composite in this case may represent an external service but not a remote one, i.e., a service external to the composite but local wrt the process or machine. If this is a valid scenario, then one question is what is the binding to be used by this reference? Can it be plugged in depending on deployment scenario? If such scenario is as above then binding.ws or some such may not be appropriate, what's the alternative, binding.sca or even something like binding.java? (2) If what we are doing is connecting two composites in the same machine via their respective Reference and Service as above, then the target invoker for the Reference of the source composite needs to behave like the target invoker for an atomic component with the difference that no user-defined logic is invoked, only the proxy for the Reference's outbound wire. Perhaps this is what you meant by optimizing away a JavaReference and only using a proxy. But the optimization seems to be dependent on the Reference's binding, i.e., whether it is a remote binding (e.g., ws) or not (as above). Hopefully things are not getting more confused. Thanks - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 10, 2006 10:42 PM Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks On Aug 10, 2006, at 8:37 AM, Ignacio Silva-Lepe wrote: Sure, I want to make sure I understand what local callbacks (or plain invocations for that matter) via references means. I was defining a local callback as being a bidirectional wire to a target component, which (by definition) is in the same composite. A wire whose target is a reference would be a remote callback since the invocation flows outside a composite. For local callbacks, we don't need to persist ids and have more control of things (lifecycle, thread dispatching, by-ref, etc.). For remote callbacks, I don't think we should allow direct
Re: Improved site look and feel
Very nice. Thank you. Just one tiny suggestion, the green color and blue color are right next to each other, is it possible to change one of them since there might be people having difficulty to distinguish them? On 8/11/06, David Wheeler [EMAIL PROTECTED] wrote: Hello everyone, The recent changes to the main site included a number of modifications to the site's content, but the look and feel of the site seems to have slipped . I feel In order to attract people into the site and get them to actually read that content, it needs to be presented in an appealing manner. So I've started working on addressing this problem. I've attached a mockup (no HTML yet) of a possible revision to the site. I tried to take the logo and continue down that line with rounded corners and a light green theme. http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/SiteMock%288-11-06%29.png?1155321723.49 Please let me know what you think and if you have any ideas. -David W -- Yang ZHONG
Re: Improved site look and feel
Do you mean the blue in the project diagram? As I can create an updated version of that, but it wasn't going to be a part of the changes. On 8/11/06, Yang ZHONG [EMAIL PROTECTED] wrote: Very nice. Thank you. Just one tiny suggestion, the green color and blue color are right next to each other, is it possible to change one of them since there might be people having difficulty to distinguish them? On 8/11/06, David Wheeler [EMAIL PROTECTED] wrote: Hello everyone, The recent changes to the main site included a number of modifications to the site's content, but the look and feel of the site seems to have slipped . I feel In order to attract people into the site and get them to actually read that content, it needs to be presented in an appealing manner. So I've started working on addressing this problem. I've attached a mockup (no HTML yet) of a possible revision to the site. I tried to take the logo and continue down that line with rounded corners and a light green theme. http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/SiteMock%288-11-06%29.png?1155321723.49 Please let me know what you think and if you have any ideas. -David W -- Yang ZHONG
Re: New woodstox release
3.0.0 works only on 1.5 and above :( http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200608.mbox/[EMAIL PROTECTED] -- dims On 8/11/06, ant elder [EMAIL PROTECTED] wrote: While we talking about moving to more recent releases of things, there's a Woodstox 3.0 out now, should we look at upgrading to that as well? Probably not too hard a change if some budding contributor wants to check out if its an easy upgrade and submit a patch when Woodstox hits a maven repos. Or should we stick with 2.9.3 for now while we know it works fine? ..ant -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REMINDER: AUGUST REPORTS ARE ***DUE***
I'll add some C++ content. Will you add the nominations of new committers etc.? Cheers, On 11/08/06, Jeremy Boynes [EMAIL PROTECTED] wrote: This means us. I can pull together the Java/SCA side - can someone please add information on the C++ side. The report covers the last 3 months. -- Jeremy Begin forwarded message: From: Noel J. Bergman [EMAIL PROTECTED] Date: August 11, 2006 11:07:35 AM PDT To: general@incubator.apache.org Subject: REMINDER: AUGUST REPORTS ARE ***DUE*** Reply-To: general@incubator.apache.org The page has been sitting waiting for content: http://wiki.apache.org/incubator/August2006 Reports are due every month folks. I should not have to constantly nag you to get them in. --- Noel - 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] -- Pete
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Using a CompositeReference SCAObject to handle case 3) sounds reasonable to me. At the risk of complicating matters, what about services? For symmetry we should also consider a couple more scenarios 4) Service with remote Binding-Component - the wire lies within the composite and comes from the remote binding; this case seems to be well covered as well 5) Service wired by the Composite-Component - there is an external wire to the CompositeComponent from a sibling Component or Service, and a local wire between the Service and the Component To account for case 5), a case could also be made for a CompositeService SCAObject that could work in conjunction with its containing CompositeComponent to pass wires around. - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 11, 2006 2:58 PM Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks I have a feeling there may be some confusion here with terminology - heck, I know I'm confused :-) I think there are several scenarios here and would like to make sure they are all being covered. 1) Component-Component - this must lie within a Composite and may have local or remote semantics 2) Component-Reference with remote Binding - the wire lies within a Composite and disappears into the remote binding 3) Component-Reference wired by the Composite - there is a local wire between the Component and the Reference and an external wire from the CompositeComponent to a sibling Component or Reference (aka the uncle) I believe cases 1) and 2) are well covered. A target SCAObject is created with an inbound wire which is then connected to an outbound wire from the source. The resulting connection may be optimized away, or may have policy or other interceptors applied. I am confused about how case 3) is being handled, specifically how the connection is being made between the Reference and the CompositeComponent. I think there is a good case to me made for having an SCAObject to represent the Reference - for example, you may want to manage the reference in some way. Having it there does not mean that it needs to be part of the invocation path. For example, during connection the wire could be optimized in a way that allowed the uncle to be directly injected into the source. Perhaps JavaReference is confusing here - how about we call it a CompositeReference, as in a Reference whose wiring is handled by the composite component that contains it. This would work in conjunction with a CompositeComponent to pass wires around - for example, CompositeComponent.addOutboundWire could just delegate down to the appropriate CompositeReference (selected by name). -- Jeremy On Aug 11, 2006, at 6:46 AM, Ignacio Silva-Lepe wrote: Hmm, ok, first off a bit of clarification on the terminology. When I say local callback (or plain invocation) via a reference, I was thinking about the case of a component in a composite talking to a component in another composite via their respective composite reference and service, where both composites are contained in a third (larger) composite, all in the same process or machine. Perhaps this is not a valid or considered use case but it seems to be different from a wire between two components, and from a wire whose target is a reference that has a remote binding, e.g., ws. Wires between components are already taken care of. A wire to a reference with a remote binding needs to involve the Reference (or Service) defined by the appropriate binding, e.g., Axis2Reference (or Axis2Service). But before we get there I thought we were trying to take care of the 'local via a reference' case as above. If this is something we intend to do I am open to the idea of not requiring a JavaReference or a JavaService. However, two things come to mind: (1) A Reference on a composite in this case may represent an external service but not a remote one, i.e., a service external to the composite but local wrt the process or machine. If this is a valid scenario, then one question is what is the binding to be used by this reference? Can it be plugged in depending on deployment scenario? If such scenario is as above then binding.ws or some such may not be appropriate, what's the alternative, binding.sca or even something like binding.java? (2) If what we are doing is connecting two composites in the same machine via their respective Reference and Service as above, then the target invoker for the Reference of the source composite needs to behave like the target invoker for an atomic component with the difference that no user-defined logic is invoked, only the proxy for the Reference's outbound wire. Perhaps this is what you meant by optimizing away a JavaReference and only using a proxy. But the optimization seems to be dependent on the Reference's binding, i.e., whether it is a remote binding
Re: New woodstox release
On Aug 11, 2006, at 12:07 PM, Davanum Srinivas wrote: 3.0.0 works only on 1.5 and above :( http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200608.mbox/ [EMAIL PROTECTED] So does Tuscany :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New woodstox release
You got me :) -- dims On 8/11/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 11, 2006, at 12:07 PM, Davanum Srinivas wrote: 3.0.0 works only on 1.5 and above :( http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200608.mbox/ [EMAIL PROTECTED] So does Tuscany :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New woodstox release
Java SDO hasn't depended on 1.5 yet, how about Java SDO also takes advantage of 1.5 to improve code readability (and reduce type error)? On 8/11/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 11, 2006, at 12:07 PM, Davanum Srinivas wrote: 3.0.0 works only on 1.5 and above :( http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200608.mbox/ [EMAIL PROTECTED] So does Tuscany :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
Re: New woodstox release
Hi, If I remember correctly, JDK1.4 compatibility is a requirement by the SDO for java spec 2.0.1. But for the tuscany extensions, for example, StAX support, the bar can be lifted if we have these features in an optional package. Raymond - Original Message - From: Yang ZHONG [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 11, 2006 1:15 PM Subject: Re: New woodstox release Java SDO hasn't depended on 1.5 yet, how about Java SDO also takes advantage of 1.5 to improve code readability (and reduce type error)? On 8/11/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 11, 2006, at 12:07 PM, Davanum Srinivas wrote: 3.0.0 works only on 1.5 and above :( http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200608.mbox/ [EMAIL PROTECTED] So does Tuscany :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New woodstox release
I don't see 1.4 requirement in Java SDO spec 2.01, the version I'm using is November 2005. On 8/11/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, If I remember correctly, JDK1.4 compatibility is a requirement by the SDO for java spec 2.0.1. But for the tuscany extensions, for example, StAX support, the bar can be lifted if we have these features in an optional package. Raymond - Original Message - From: Yang ZHONG [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 11, 2006 1:15 PM Subject: Re: New woodstox release Java SDO hasn't depended on 1.5 yet, how about Java SDO also takes advantage of 1.5 to improve code readability (and reduce type error)? On 8/11/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Aug 11, 2006, at 12:07 PM, Davanum Srinivas wrote: 3.0.0 works only on 1.5 and above :( http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200608.mbox/ [EMAIL PROTECTED] So does Tuscany :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
Re: [jira] Updated: (TUSCANY-611) RMI Binding
On Aug 10, 2006, at 10:53 PM, Venkata Krishnan wrote: Thanks Ant and Jim. Ant, I shall certainly work on the formatting and a couple of other issues and posted an updated patch asap. Jim, you point was something that I did vacillate about. I was wondering if the registry should be started by the binding or should it be done offline. My inclination is to start the registry in a system service. One way to do this is to create a system POJO implementing something like RMIHost with an @Init method and set to eager init and you can also have a destroy method to do any shutdown. I'd then have the builder take an autowire to the system service which would pass it to the service. When Service.stop() is called, the service would perform an unbind by using RMIHost.unbind() or something similar. My imagination of the Registry is that it is lightweight and it should be ok to host several instances of it on a host, ofcourse each on a different port. Hence we might actually allow the assemblies to mention which port number is preferred to host the RMI Service. I think this could be accomplished with one system service. The RMIHost API could have overloaded versions of register(), one that takes an explicit port and one that uses a default. If an explicit port is passed, the RMIHost would look for a cached Registry, creating one if needed. If a registry for the port already exists then we simply use that otherwise start one. So if is possible that a registry on a port will host more than one service. It is also a good idea that we clearly have one registry per host and implement it the way you have mentioned out here. I am open to do this as well. Let me know your final thoughts on this. One other thing is I think it is important for the business interface of the Reference (and probably the Service) not to have to extend Remote since the binding could be changed (I think you may have brought this up before). In this case, the binding should perform a mediation during the invoke. What do you think? Jerermy and others what are your thoughts on this? Thanks - Venkat On 8/11/06, Jim Marino [EMAIL PROTECTED] wrote: Thanks Venkat. Just a quick question: do you think it is best to have one Registry per service or could we have one Registry per runtime instance and have services register with that? If you think the latter may be something that works better, one thing that could be done is to create a separate system component that instantiates the registry. This system component would be like ServletHost (RMIHost?) and could be autowired to the builder which could then pass it to the service implementation which would in turn perform the bind operation. Jim On Aug 10, 2006, at 12:30 PM, ant elder wrote: Hi Venkat, I've committed this patch now. Had some problems getting the patch to apply cleanly so had to fiddle about a bit, could you check it looks ok to you? The code needs formatting so maybe you could send in another patch doing that? I've also not added the service and reference samples to the main samples pom.xml yet. As you've pointed out the testcases for them only work in eclipse so we'll need to figure out what to do about that. Looks great, really good to have a real binding working at last. ...ant On 8/10/06, Venkatakrishnan (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-611?page=all ] Venkatakrishnan updated TUSCANY-611: Attachment: Tuscany-RMI-Binding-Aug-10-Updated.diff Hi... there is one addition that has been missed out in the prev. patch. My sincere apologies for that goof-up here is the updated patch. Thanks. RMI Binding --- Key: TUSCANY-611 URL: http://issues.apache.org/jira/browse/ TUSCANY-611 Project: Tuscany Issue Type: Bug Reporter: Venkatakrishnan Assigned To: ant elder Attachments: Tuscany-RMI-Binding-Aug-10-Updated.diff , Tuscany-RMI-Binding-Aug-10.diff, Tuscany-RMI-Binding-Reference-Sample-Aug-10.diff , Tuscany-RMI-Binding-Service-Sample-Aug-10.diff SCA RMI Binding with samples for SCA Reference and SCA Service using RMI Binding. Here is a first cut implementation for this. Could somebody please review and apply? Also I have had the following issues un- resolved: - - The samples can be tested thro the Testcases in them. These testcases work from eclipse as long as I have added the RMI-Binding Eclipse project to the classpath. Otherwise the binding does get picked up. The same is the issue when trying to execute the testcases from maven. Could somebody please help in fixing this? Thanks. Note :- I shall be working further with this binding to address the following : - - there is single attribute called 'uri' for the binding. I
Re: [jira] Updated: (TUSCANY-611) RMI Binding
On Aug 11, 2006, at 1:49 PM, Jim Marino wrote: On Aug 10, 2006, at 10:53 PM, Venkata Krishnan wrote: My imagination of the Registry is that it is lightweight and it should be ok to host several instances of it on a host, ofcourse each on a different port. Hence we might actually allow the assemblies to mention which port number is preferred to host the RMI Service. I think this could be accomplished with one system service. The RMIHost API could have overloaded versions of register(), one that takes an explicit port and one that uses a default. If an explicit port is passed, the RMIHost would look for a cached Registry, creating one if needed. I think one component per registry would be easier to manage. Each registry would register with the RMIHost by socket address; service instances would register with the RMIHost which would delegate to the appropriate registry based on the endpoint address. Specifying just port number in the assembly is not enough - you need to be able to specify host/port combinations. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
On Aug 11, 2006, at 11:58 AM, Jeremy Boynes wrote: I have a feeling there may be some confusion here with terminology - heck, I know I'm confused :-) Yes, I think it is a terminology thing. I was thinking of the three scenarios below and local only being a case of #1. I think there are several scenarios here and would like to make sure they are all being covered. 1) Component-Component - this must lie within a Composite and may have local or remote semantics 2) Component-Reference with remote Binding - the wire lies within a Composite and disappears into the remote binding 3) Component-Reference wired by the Composite - there is a local wire between the Component and the Reference and an external wire from the CompositeComponent to a sibling Component or Reference (aka the uncle) I believe cases 1) and 2) are well covered. A target SCAObject is created with an inbound wire which is then connected to an outbound wire from the source. The resulting connection may be optimized away, or may have policy or other interceptors applied. Yes but #2 still need to be done. I am confused about how case 3) is being handled, specifically how the connection is being made between the Reference and the CompositeComponent. I think there is a good case to me made for having an SCAObject to represent the Reference - for example, you may want to manage the reference in some way. Having it there does not mean that it needs to be part of the invocation path. For example, during connection the wire could be optimized in a way that allowed the uncle to be directly injected into the source. Perhaps JavaReference is confusing here - how about we call it a CompositeReference, as in a Reference whose wiring is handled by the composite component that contains it. This would work in conjunction with a CompositeComponent to pass wires around - for example, CompositeComponent.addOutboundWire could just delegate down to the appropriate CompositeReference (selected by name). Yes having the special type of reference makes sense because this is a type of binding. The target invoker in this case could actually be an interceptor which flowed the invocation to the head interceptor of the uncle. If this is the case, we may need to have the Connector handle this case of finding the target in the outer grandparent composite (if that makes sense). -- Jeremy On Aug 11, 2006, at 6:46 AM, Ignacio Silva-Lepe wrote: Hmm, ok, first off a bit of clarification on the terminology. When I say local callback (or plain invocation) via a reference, I was thinking about the case of a component in a composite talking to a component in another composite via their respective composite reference and service, where both composites are contained in a third (larger) composite, all in the same process or machine. Perhaps this is not a valid or considered use case but it seems to be different from a wire between two components, and from a wire whose target is a reference that has a remote binding, e.g., ws. Wires between components are already taken care of. A wire to a reference with a remote binding needs to involve the Reference (or Service) defined by the appropriate binding, e.g., Axis2Reference (or Axis2Service). But before we get there I thought we were trying to take care of the 'local via a reference' case as above. If this is something we intend to do I am open to the idea of not requiring a JavaReference or a JavaService. However, two things come to mind: (1) A Reference on a composite in this case may represent an external service but not a remote one, i.e., a service external to the composite but local wrt the process or machine. If this is a valid scenario, then one question is what is the binding to be used by this reference? Can it be plugged in depending on deployment scenario? If such scenario is as above then binding.ws or some such may not be appropriate, what's the alternative, binding.sca or even something like binding.java? (2) If what we are doing is connecting two composites in the same machine via their respective Reference and Service as above, then the target invoker for the Reference of the source composite needs to behave like the target invoker for an atomic component with the difference that no user-defined logic is invoked, only the proxy for the Reference's outbound wire. Perhaps this is what you meant by optimizing away a JavaReference and only using a proxy. But the optimization seems to be dependent on the Reference's binding, i.e., whether it is a remote binding (e.g., ws) or not (as above). Hopefully things are not getting more confused. Thanks - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 10, 2006 10:42 PM Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks On Aug 10, 2006, at 8:37 AM, Ignacio
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
On Aug 11, 2006, at 12:37 PM, Ignacio Silva-Lepe wrote: At the risk of complicating matters, what about services? For symmetry we should also consider a couple more scenarios 1) Component-Component - this must lie within a Composite and may have local or remote semantics 2) Component-Reference with remote Binding - the wire lies within a Composite and disappears into the remote binding 3) Component-Reference wired by the Composite - there is a local wire between the Component and the Reference and an external wire from the CompositeComponent to a sibling Component or Reference (aka the uncle) 4) Service with remote Binding-Component - the wire lies within the composite and comes from the remote binding; this case seems to be well covered as well 5) Service wired by the Composite-Component - there is an external wire to the CompositeComponent from a sibling Component or Service, and a local wire between the Service and the Component and 6) Composite(Component-Reference)-Composite(Service-Component) - a combination of 3) and 5) which may provide opportunities for wire optimization To account for case 5), a case could also be made for a CompositeService SCAObject that could work in conjunction with its containing CompositeComponent to pass wires around. Agreed - I was thinking that would be symmetrical but decided to stick with just references :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What happens if no binding is defined for services/references in a composite?
Hi, I ran into an issue for services/references for a composite. Here is the SCDL file: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:db=http://tuscany.apache.org/xmlns/databinding/1.0; name=org.apache.tuscany.databinding.sample service name=ClientService interface.java class=org.apache.tuscany.databinding.sample.Client / referenceClient/reference db:databinding name=sdo/ /service component name=Client implementation.java class=org.apache.tuscany.databinding.sample.ClientImpl / reference name=echoReferenceEchoReference/reference db:databinding name=jaxb/ /component reference name=EchoReference interface.java interface=org.apache.tuscany.databinding.sample.Echo / /reference /composite Please note there is no binding defined for the service and reference. Per SCA spec, this is valid. Now we have two cases: 1) The bindings are to be added when the composite is assembled with other composites 2) Is it possible to support local invocation for reference/service without binding (assuming in the same address space)? The current CompositeBuilder implementation only adds the bound services and references to the context. As a result, I get the following exception: org.apache.tuscany.spi.builder.BuilderConfigException: Target not found for reference echoReference [EchoReference] Context stack trace: [application][Client] at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:53) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:75) at org.apache.tuscany.core.deployer.DeployerImpl.connect(DeployerImpl.java:134) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:96) at org.apache.tuscany.core.launcher.Launcher.bootApplication(Launcher.java:171) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:63) at org.apache.tuscany.databinding.sample.BootstrapTestCase.setUp(BootstrapTestCase.java:39) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Is it the correct behavior? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-615) The SCDL syntax for reference doesn't conform to SCA spec 0.95
[ http://issues.apache.org/jira/browse/TUSCANY-615?page=comments#action_12427625 ] Jeremy Boynes commented on TUSCANY-615: --- There seem to be quite a few changes in this patch unrelated to the problem described above. Please can you submit these separately. The SCDL syntax for reference doesn't conform to SCA spec 0.95 -- Key: TUSCANY-615 URL: http://issues.apache.org/jira/browse/TUSCANY-615 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Raymond Feng Assigned To: Raymond Feng Priority: Critical Attachments: rfeng-scdl.txt With Rick check-in of r430621, I'm seeing the EchoBinding test case is failing with the following exception: org.apache.tuscany.spi.loader.InvalidReferenceException: No target for service [ClientService] at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java) at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java:1) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:75) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:50) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:107) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:46) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:20) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:157) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:111) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:90) at org.apache.tuscany.core.launcher.Launcher.bootApplication(Launcher.java:171) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:63) at echo.BootstrapTestCase.setUp(BootstrapTestCase.java:23) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I adjusted the scdl file per SCA 0.95 spec: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=echo.sample service name=ClientService interface.java class=echo.Client/ binding.echo/ referenceClient/reference /service component name=Client implementation.java class=echo.ClientImpl/ reference name=echoReferenceEchoReference/reference /component reference name=EchoReference interface.java interface=echo.Echo/ binding.echo/ /reference /composite Now the ServiceLoader.java is problematic because it assumes it'll get reference before the binding which is not case per SCA 0.95 spec: service name=xs:NCName multiplicity=0..1 or 1..1 or 0..n or 1..n?* interface/ binding uri=xs:anyURI?/* referencewire-target-URI/reference+ /service component name=xs:NCName* implementation/ property name=xs:NCName source=sca:Property?* property-value /property reference name=xs:NCName/* wire-target-URI /reference /component The ComponentLoader.java cannot handle the reference element either since the SCA spec 0.95 also use the element content instead of target attribute. I attached a patch to fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-610) Initial OSGi support effort
Thanks a lot Joel. I'm kind of out just checking email once and a while until Monday so when I get back I'll commit the patch and we can talk some more. Jim On Aug 10, 2006, at 1:06 PM, Joel Hawkins (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-610? page=comments#action_12427336 ] Joel Hawkins commented on TUSCANY-610: -- Hi Thomas. I'm trying to write up some documentation now. In short, however, the code breaks down into 2 parts: 1. The OSGi hosting of the SCA core. This is a bundle that bootstraps SCA instances for bundles that have SCA components (scdl files). The host makes a distinction between system extension and applications. For example, the OSGi binding code that supports interacting with the OSGi service framework is packaged as a system extension. The samples are packaged as applications. To me, these application instances feel like web apps. 2. The OSGi Services system extension, which in turn has two major parts: a. An OSGi Service binding, which allows SCA components to be exposed as OSGi services. This is pretty straightforward. The only tricky bit (assuming away the intricacies of SCA's wiring) is dealing with the need for a ServiceFactory during service registration. This is added to the target class using a dynamic proxy if required. b. An OSGi implementation, which wraps OSGi services as SCA components, allowing them to be wire in seamlessly (once I'm done :-) )into SCA applications. This binding allows the specification of a filter for aquiring an appropriate service reference, and acts as a service listener to clean up stale references. The code currently attempts to rebind the service if the service has changed (using the same reference) or gone away (using a different reference). Not sure if this is desirable in all cases, but it gives good demo. :-) Please remember this is an 'initial' implementation! There's enough code to get my simple scenarios working - but I'm sure there's plenty left to do. Also, the recent work that's been checked in to have some of the wiring handled by the wire service probably means some of this code can go away. Some of the things I like about the combination of SCA and OSGi is that OSGi services provide a really simple and efficient way to communicate between SCA applications running in a single OSGi instance, and OSGi's bundle isolation characteristics make dealing with multiple application deployments much more deterministic. From my perspective (having a toe dipped in both worlds), SCA and OSGi look really complementary. I'll also try and package the rest of my eclipse environment so that you can get this running. It's mostly bundle-izing the required Tuscany jars. Initial OSGi support effort --- Key: TUSCANY-610 URL: http://issues.apache.org/jira/browse/TUSCANY-610 Project: Tuscany Issue Type: New Feature Environment: Equinox implementation of OSGi Reporter: Joel Hawkins Attachments: ClassloaderHook.java, OSGI-SCA.zip An initial implementation of an OSGi binding for exposing SCA services as OSGi services. An initial implementation of an OSGi implementation for reusing OSGi services as SCA atomic components An OSGi-aware bootstrap environment (which can probably be reduced a bit) A repackaging of some of the SupplyChain example There's one class derived from an EPL-copyrighted class - I left the EPL copyright intact. The zip contains the samples, the OSGi binding, and a patch for the core. Most of the patch is the OSGi launcher code. I don't think it belongs in the core, but that's where I had it while developing. The only other bit in the patch is a change of two of the Defaultbootstrapper's fields from private to protected. Also, some of the OSGi packaging for existing jars (spi, commands, etc) aren't part of the zip. Not sure how you want to deal with the repackaging issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - 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: [jira] Updated: (TUSCANY-585) Initial support for callbacks
On Aug 11, 2006, at 1:59 PM, Jeremy Boynes wrote: On Aug 11, 2006, at 12:37 PM, Ignacio Silva-Lepe wrote: At the risk of complicating matters, what about services? For symmetry we should also consider a couple more scenarios 1) Component-Component - this must lie within a Composite and may have local or remote semantics 2) Component-Reference with remote Binding - the wire lies within a Composite and disappears into the remote binding 3) Component-Reference wired by the Composite - there is a local wire between the Component and the Reference and an external wire from the CompositeComponent to a sibling Component or Reference (aka the uncle) 4) Service with remote Binding-Component - the wire lies within the composite and comes from the remote binding; this case seems to be well covered as well 5) Service wired by the Composite-Component - there is an external wire to the CompositeComponent from a sibling Component or Service, and a local wire between the Service and the Component and 6) Composite(Component-Reference)-Composite(Service-Component) - a combination of 3) and 5) which may provide opportunities for wire optimization To account for case 5), a case could also be made for a CompositeService SCAObject that could work in conjunction with its containing CompositeComponent to pass wires around. Agreed - I was thinking that would be symmetrical but decided to stick with just references :-) Yes and we also need to deal with cycle detection at some point too :-( -- Jeremy - 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: [jira] Updated: (TUSCANY-611) RMI Binding
On Aug 11, 2006, at 1:59 PM, Jeremy Boynes wrote: On Aug 11, 2006, at 1:49 PM, Jim Marino wrote: On Aug 10, 2006, at 10:53 PM, Venkata Krishnan wrote: My imagination of the Registry is that it is lightweight and it should be ok to host several instances of it on a host, ofcourse each on a different port. Hence we might actually allow the assemblies to mention which port number is preferred to host the RMI Service. I think this could be accomplished with one system service. The RMIHost API could have overloaded versions of register(), one that takes an explicit port and one that uses a default. If an explicit port is passed, the RMIHost would look for a cached Registry, creating one if needed. I think one component per registry would be easier to manage. Each registry would register with the RMIHost by socket address; service instances would register with the RMIHost which would delegate to the appropriate registry based on the endpoint address. Specifying just port number in the assembly is not enough - you need to be able to specify host/port combinations. Forgot about the host. If we want to have one component per registry, what happens when two services register at the same host/port combination? -- Jeremy - 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: [jira] Updated: (TUSCANY-611) RMI Binding
On Aug 11, 2006, at 2:25 PM, Jim Marino wrote: On Aug 11, 2006, at 1:59 PM, Jeremy Boynes wrote: On Aug 11, 2006, at 1:49 PM, Jim Marino wrote: On Aug 10, 2006, at 10:53 PM, Venkata Krishnan wrote: My imagination of the Registry is that it is lightweight and it should be ok to host several instances of it on a host, ofcourse each on a different port. Hence we might actually allow the assemblies to mention which port number is preferred to host the RMI Service. I think this could be accomplished with one system service. The RMIHost API could have overloaded versions of register(), one that takes an explicit port and one that uses a default. If an explicit port is passed, the RMIHost would look for a cached Registry, creating one if needed. I think one component per registry would be easier to manage. Each registry would register with the RMIHost by socket address; service instances would register with the RMIHost which would delegate to the appropriate registry based on the endpoint address. Specifying just port number in the assembly is not enough - you need to be able to specify host/port combinations. Forgot about the host. If we want to have one component per registry, what happens when two services register at the same host/ port combination? If two registries register, the second should fail (as it won't be able to get the socket anyway). Services will have a uri whose path will distinguish them. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-615) The SCDL syntax for reference doesn't conform to SCA spec 0.95
[ http://issues.apache.org/jira/browse/TUSCANY-615?page=all ] Raymond Feng updated TUSCANY-615: - Attachment: rfeng-scdl-fixed-1.txt For some reason, the 2nd patch failed to be applied. Here's 3rd one and hopefully it works. The SCDL syntax for reference doesn't conform to SCA spec 0.95 -- Key: TUSCANY-615 URL: http://issues.apache.org/jira/browse/TUSCANY-615 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Raymond Feng Assigned To: Raymond Feng Priority: Critical Attachments: rfeng-scdl-fixed-1.txt, rfeng-scdl-fixed.txt, rfeng-scdl.txt With Rick check-in of r430621, I'm seeing the EchoBinding test case is failing with the following exception: org.apache.tuscany.spi.loader.InvalidReferenceException: No target for service [ClientService] at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java) at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java:1) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:75) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:50) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:107) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:46) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:20) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:157) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:111) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:90) at org.apache.tuscany.core.launcher.Launcher.bootApplication(Launcher.java:171) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:63) at echo.BootstrapTestCase.setUp(BootstrapTestCase.java:23) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I adjusted the scdl file per SCA 0.95 spec: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=echo.sample service name=ClientService interface.java class=echo.Client/ binding.echo/ referenceClient/reference /service component name=Client implementation.java class=echo.ClientImpl/ reference name=echoReferenceEchoReference/reference /component reference name=EchoReference interface.java interface=echo.Echo/ binding.echo/ /reference /composite Now the ServiceLoader.java is problematic because it assumes it'll get reference before the binding which is not case per SCA 0.95 spec: service name=xs:NCName multiplicity=0..1 or 1..1 or 0..n or 1..n?* interface/ binding uri=xs:anyURI?/* referencewire-target-URI/reference+ /service component name=xs:NCName* implementation/ property name=xs:NCName source=sca:Property?* property-value /property reference name=xs:NCName/* wire-target-URI /reference /component The ComponentLoader.java cannot handle the reference element either since the SCA spec 0.95 also use the element content instead of target attribute. I attached a patch to fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New woodstox release
The upcoming SDO 2.1 specification will state the minimum JDK level for SDO 2.1 is JDK 1.4. This requirement has been clarified and agreed by all the participants in the SDO Spec working group. For SDO 3.0, although it's not decided yet, Java 5 may become the minimum level. Regards, Fuhwei Lwo Yang ZHONG [EMAIL PROTECTED] wrote: I don't see 1.4 requirement in Java SDO spec 2.01, the version I'm using is November 2005. On 8/11/06, Raymond Feng wrote: Hi, If I remember correctly, JDK1.4 compatibility is a requirement by the SDO for java spec 2.0.1. But for the tuscany extensions, for example, StAX support, the bar can be lifted if we have these features in an optional package. Raymond - Original Message - From: Yang ZHONG To: Sent: Friday, August 11, 2006 1:15 PM Subject: Re: New woodstox release Java SDO hasn't depended on 1.5 yet, how about Java SDO also takes advantage of 1.5 to improve code readability (and reduce type error)? On 8/11/06, Jeremy Boynes wrote: On Aug 11, 2006, at 12:07 PM, Davanum Srinivas wrote: 3.0.0 works only on 1.5 and above :( http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200608.mbox/ [EMAIL PROTECTED] So does Tuscany :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
svn properties
rant I've just wasted an hour or so working with Raymond trying to figure out why a patch he supplied would not apply. I am writing this in a suitably frustrated mood ... It appears that there are many many files in our svn tree that do not have the correct properties set. Some files are missing the svn:eol-style=native setting which means files are being checked in with inconsistent line endings. Specifically, there are a lot of files with DOS \r\n endings which don't work so well for those of us not using Windows. There are also quite a few with svn:keywords set to Rev,Date as opposed to the correct value Rev Date meaning the date/version info is not being updated. I would ask everyone to double, triple check their SVN settings to make sure that they have the appropriate auto-properties configured. I am going to waste yet more time fixing the java/samples and java/ sca trees so we don't waste even more time in the future Can someone please spend the time to fix the java/sdo tree /rant -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Design of SCA and SDO public API classes
I noticed two different patterns in the definition of the public SCA and SDO API classes. SCA: A delegation pattern where the public API class delegates calls to an implementation class. For example ComponentContext contains a private pointer to ComponentContextImpl. ComponentContextImpl implements the methods from ComponentContext but does not extend ComponentContext. SDO: Inheritance, where the implementation class extends the public API class. For example DataFactoryImpl extends DataFactory. Is there any particular reason for the two different patterns? Any advantages or issues with one compared the other? A related question. What do you think about reorganizing the folder structure a little to clearly separate the spec includes from the implementation specific ones? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-494) Specification of implementation library in scdl is not platform neutral
[ http://issues.apache.org/jira/browse/TUSCANY-494?page=comments#action_12427637 ] Jean-Sebastien Delfino commented on TUSCANY-494: This is now implemented, except for the optional path attribute, which is still ignored. Specification of implementation library in scdl is not platform neutral --- Key: TUSCANY-494 URL: http://issues.apache.org/jira/browse/TUSCANY-494 Project: Tuscany Issue Type: Improvement Components: Specification, C++ SCA Affects Versions: Cpp-current Reporter: Pete Robbins Assigned To: Pete Robbins Specification of a component implementation for C++ requires e.g. implementation.cpp dll=libMyValue.so header=MyValueImpl.h/implementation.cpp for linux and implementation.cpp dll=MyValue.dll header=MyValueImpl.h/implementation.cpp for Windows. This means we can not have a common sca.module defintion across the platforms. I propose we change this to implementation.cpp library=MyValue header=MyValueImpl.h/implementation.cpp and allow the platform code to add the prefix and suffix lib and .so for linux and the suffix .dll for windows. This is consistent with other C++ projects for specifying libraries. We would need an extra parameter path= to specify the relative pass to the location of the library. Existing schema: element name=implementation.cpp type=sca:CPPImplementation substitutionGroup=sca:implementation sdo:name=implementationCpp/ complexType name=CPPImplementation complexContent extension base=sca:Implementation sequence any namespace=##other processContents=lax minOccurs=0 maxOccurs=unbounded/ /sequence attribute name=dll type=NCName use=required/ attribute name=header type=NCName use=required/ attribute name=class type=Name use=optional/ anyAttribute namespace=##any processContents=lax/ /extension /complexContent /complexType would become: element name=implementation.cpp type=sca:CPPImplementation substitutionGroup=sca:implementation sdo:name=implementationCpp/ complexType name=CPPImplementation complexContent extension base=sca:Implementation sequence any namespace=##other processContents=lax minOccurs=0 maxOccurs=unbounded/ /sequence attribute name=library type=NCName use=required/ attribute name=path type=NCName use=optional/ attribute name=header type=NCName use=required/ attribute name=class type=Name use=optional/ anyAttribute namespace=##any processContents=lax/ /extension /complexContent /complexType -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-508) Big Bank GetQute signature
[ http://issues.apache.org/jira/browse/TUSCANY-508?page=all ] Jean-Sebastien Delfino resolved TUSCANY-508. Resolution: Fixed This is now fixed the interfaces are in line with the WSDL and the actual Web Service which is invoked. Big Bank GetQute signature -- Key: TUSCANY-508 URL: http://issues.apache.org/jira/browse/TUSCANY-508 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws ChangedGetQuote to getQuote in StockQuoteService_StockQuoteExternal_Proxy.cpp and associated StockQuoteExternal files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-510) Big Bank getQuote return type error
[ http://issues.apache.org/jira/browse/TUSCANY-510?page=all ] Jean-Sebastien Delfino resolved TUSCANY-510. Resolution: Invalid This is actually consistent with what the Web service that we are using is returning. It may look strange, but the StockQuote Web service actually returns a string containing an XML document. We have to then parse it in the client component code to extract the (float) quote. We may want to look into using another good StockQuote Web service that would return a float to avoid confusing users in our Bigbank sample but the one that we are currently using has proven to be the most reliable of all... Big Bank getQuote return type error --- Key: TUSCANY-510 URL: http://issues.apache.org/jira/browse/TUSCANY-510 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-current Environment: windows XP Reporter: Simon Laws StockQuoteExternalService.h/StockQuoteServiceImpl.cpp has incorrect return type for getQuote const char * should be float. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New woodstox release
We're talking about at least 2 kinds of JDK levels. 2-1. SDO usage(byte code) level: as long as SDO libraries can run on JDK 1.4, spec 2.1 is satisfied. 2-2. SDO implementation(source code) compilation level: SDO implementation can be compiled by JDK 1.5 as long as the generated byte code can run on JDK 1.4 -- Yang ZHONG
[C++] Patches TUSCANY-606 and 613, was: BigBank scenario working end to end
Andrew Borley wrote: [snip] I needed to update the deploy.bat file that puts the various files in the right places in the samples/BigBank/deploy directory so I've put a patch up at TUSCANY-606. Andy, I am not able to apply patch TUSCANY-606 (and similar problem with TUSCANY-613). patch -p0 /home/delfinoj/Tuscany/patches/TUSCANY-606.patch gives me this error: (Stripping trailing CRs from patch.) patching file sca/samples/BigBank/deploy.bat Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file sca/samples/BigBank/deploy.bat.rej I have no idea what 1 out of 1 hunk failed means :) but svn info deploy.bat tells me: Last Changed Rev 429833, and the patch was generated on an earlier revision 429611... Could this be the problem? Sorry about the inconvenience but could you try svn up then svn diff again and attach new patches to the JIRA issues? I'll try applying them again... Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Andrew Borley wrote: [snip] I think we use our samples to demonstrate different ways of working - have the Calculator be deployed in a single directory and have the BigBank show the use of multiple directories. So perhaps have configuration, packages/account and packages/client directories under the root directory? What do you think? Andy Andy, where would you place the two composites files describing the calculator implementation and component? Just to recap, here's what we had in M1: subsystems/ CalculatorSubsystem/ CalculatorSubsystem.composite BigBankSubsystem/ BigBankSubsystem.composite modules/ CalculatorModule/ CalculatorModule.module Accounts/ Accounts.composite I am proposing something like this: configuration/ sample.calculator.composite bigbank.composite packages/ calculator/ calculator.composite bigbank.account/ bigbank.account.composite bigbank.client/ bigbank.client.composite The configuration directory contains the composites included in your system, the packages directory contains implementations (composites or other things). And here's another option: system.composite file ... containing include name=sample.calculator.composite/ include name=bigbank.composite/ and a more free form distribution for the other artifacts: sample.calculator.composite bigbank.composite calculator/ calculator.composite bigbank.account/ bigbank.account.composite bigbank.client/ bigbank.client.composite This would provide less guidance to our users but maybe more flexibility. They would have to edit this central system.composite file instead of just placing files in a well known folder. I'm OK with both the folder structure option or the cenral composite file option. I suggest we start experimenting with a simple scheme that you guys are comfortable and evolve it over time as we implement more scenarios. What do you think? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Finally posted: src file header and copyright policy
Having just made modifications to most of the sca source tree to fix the CR problems, I plan to make this change later today. -- Jeremy On Jul 19, 2006, at 1:43 PM, Jeremy Boynes wrote: On Jul 19, 2006, at 11:50 AM, Jeremy Boynes wrote: Is this is good time to do this to the trunk (thinking that most people will not have any work that will conflict)? I'll see if the tools work and if there are no issues think about doing this later this week. We had a problem with some of the files not having license headers in them :-( so I modified Roy's script to be a little more aggressive and replace everything before the package statement with the new header. I ran these on a few files and they seemed to do the right thing but additional review would be appreciated. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-536) Cannot mix both WS Entrypoint and WS External Service
[
http://issues.apache.org/jira/browse/TUSCANY-536?page=comments#action_12427657
]
Jean-Sebastien Delfino commented on TUSCANY-536:
Is TUSCANY-511 just a duplicate of 536 and therefore should just be closed as
such?
Cannot mix both WS Entrypoint and WS External Service
-
Key: TUSCANY-536
URL: http://issues.apache.org/jira/browse/TUSCANY-536
Project: Tuscany
Issue Type: Bug
Components: C++ SCA
Affects Versions: Cpp-current, Cpp-M1
Reporter: Andrew Borley
Priority: Minor
A component invoked via a WS Entrypoint fails after invoking a WS External
Service. I believe this is a problem with freeing memory in Axis2C have
asked a question on the Axis2C mailing list. Currently this causes the server
to crash.
A workaround can be used - comment out the block that frees the Axis2C
service client in Axis2Client.cpp at line 169:
//if (svc_client)
//{
//AXIS2_SVC_CLIENT_FREE(svc_client, env);
//svc_client = NULL;
//}
Unfortunately this can cause memory leakage problems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-615) The SCDL syntax for reference doesn't conform to SCA spec 0.95
[ http://issues.apache.org/jira/browse/TUSCANY-615?page=all ] Raymond Feng updated TUSCANY-615: - Attachment: rfeng-scdl-fixed-2.txt New patch on top of Jeremy's svn property fix. The SCDL syntax for reference doesn't conform to SCA spec 0.95 -- Key: TUSCANY-615 URL: http://issues.apache.org/jira/browse/TUSCANY-615 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Raymond Feng Assigned To: Raymond Feng Priority: Critical Attachments: rfeng-scdl-fixed-1.txt, rfeng-scdl-fixed-2.txt, rfeng-scdl-fixed.txt, rfeng-scdl.txt With Rick check-in of r430621, I'm seeing the EchoBinding test case is failing with the following exception: org.apache.tuscany.spi.loader.InvalidReferenceException: No target for service [ClientService] at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java) at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java:1) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:75) at org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:50) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:107) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:46) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:20) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:157) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:111) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:90) at org.apache.tuscany.core.launcher.Launcher.bootApplication(Launcher.java:171) at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:63) at echo.BootstrapTestCase.setUp(BootstrapTestCase.java:23) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I adjusted the scdl file per SCA 0.95 spec: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=echo.sample service name=ClientService interface.java class=echo.Client/ binding.echo/ referenceClient/reference /service component name=Client implementation.java class=echo.ClientImpl/ reference name=echoReferenceEchoReference/reference /component reference name=EchoReference interface.java interface=echo.Echo/ binding.echo/ /reference /composite Now the ServiceLoader.java is problematic because it assumes it'll get reference before the binding which is not case per SCA 0.95 spec: service name=xs:NCName multiplicity=0..1 or 1..1 or 0..n or 1..n?* interface/ binding uri=xs:anyURI?/* referencewire-target-URI/reference+ /service component name=xs:NCName* implementation/ property name=xs:NCName source=sca:Property?* property-value /property reference name=xs:NCName/* wire-target-URI /reference /component The ComponentLoader.java cannot handle the reference element either since the SCA spec 0.95 also use the element content instead of target attribute. I attached a patch to fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] indent on case
In our code guidelines (or at least the IDE setup files), case is not
indented
switch (i) {
case 1:
break;
but the checkstyle profile is looking for a 4 character indent:
switch (i) {
case 1:
break;
which do we want?
[ ] No indent
[ ] Indent 4 characters
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] indent on case
My vote
On Aug 11, 2006, at 5:55 PM, Jeremy Boynes wrote:
In our code guidelines (or at least the IDE setup files), case is
not indented
switch (i) {
case 1:
break;
[X] No indent
[ ] Indent 4 characters
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improved site look and feel
David, Your prototype is more user friendly. Would it be possible to see a mock up with these changes for comparison? Your talent in graphics is much appreciated :) - Choose a lighter green than the one we have in the header for community, general, etc. boxes. Perhaps the same as the background in the logo. - Don't grey the boxes for community, general, etc. This would get rid of the empty grey box below header in the larger frame where the diagram resides - Leave the grey shadow line around the boxes. It is nice. - Tone down the architecture diagram colors. Use shades/variation of the same color. Perhaps light blue, mat blue and grey - possibly extend the architecture diagram to show an SCA composite application diagram which when clicked on would take us to a code sample - Change the red font for the links on the webpage to dark grey Thanks, Haleh On 8/11/06, David Wheeler [EMAIL PROTECTED] wrote: Do you mean the blue in the project diagram? As I can create an updated version of that, but it wasn't going to be a part of the changes. On 8/11/06, Yang ZHONG [EMAIL PROTECTED] wrote: Very nice. Thank you. Just one tiny suggestion, the green color and blue color are right next to each other, is it possible to change one of them since there might be people having difficulty to distinguish them? On 8/11/06, David Wheeler [EMAIL PROTECTED] wrote: Hello everyone, The recent changes to the main site included a number of modifications to the site's content, but the look and feel of the site seems to have slipped . I feel In order to attract people into the site and get them to actually read that content, it needs to be presented in an appealing manner. So I've started working on addressing this problem. I've attached a mockup (no HTML yet) of a possible revision to the site. I tried to take the logo and continue down that line with rounded corners and a light green theme. http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/SiteMock%288-11-06%29.png?1155321723.49 Please let me know what you think and if you have any ideas. -David W -- Yang ZHONG
Re: [jira] Updated: (TUSCANY-611) RMI Binding
On Aug 11, 2006, at 2:32 PM, Jeremy Boynes wrote: On Aug 11, 2006, at 2:25 PM, Jim Marino wrote: On Aug 11, 2006, at 1:59 PM, Jeremy Boynes wrote: On Aug 11, 2006, at 1:49 PM, Jim Marino wrote: On Aug 10, 2006, at 10:53 PM, Venkata Krishnan wrote: My imagination of the Registry is that it is lightweight and it should be ok to host several instances of it on a host, ofcourse each on a different port. Hence we might actually allow the assemblies to mention which port number is preferred to host the RMI Service. I think this could be accomplished with one system service. The RMIHost API could have overloaded versions of register(), one that takes an explicit port and one that uses a default. If an explicit port is passed, the RMIHost would look for a cached Registry, creating one if needed. I think one component per registry would be easier to manage. Each registry would register with the RMIHost by socket address; service instances would register with the RMIHost which would delegate to the appropriate registry based on the endpoint address. Specifying just port number in the assembly is not enough - you need to be able to specify host/port combinations. Forgot about the host. If we want to have one component per registry, what happens when two services register at the same host/ port combination? If two registries register, the second should fail (as it won't be able to get the socket anyway). Right so that's why I was thinking it would be better to allow for multiple components per registry. Do you think that's not something that really is a problem? Services will have a uri whose path will distinguish them. -- Jeremy - 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: [VOTE] indent on case
I'm note sure this requires a vote but I prefer indent 4.
Jim
On Aug 11, 2006, at 5:55 PM, Jeremy Boynes wrote:
In our code guidelines (or at least the IDE setup files), case is
not indented
switch (i) {
case 1:
break;
but the checkstyle profile is looking for a 4 character indent:
switch (i) {
case 1:
break;
which do we want?
[ ] No indent
[ ] Indent 4 characters
--
Jeremy
-
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: Improved site look and feel
On Aug 11, 2006, at 6:04 PM, haleh mahbod wrote: David, Your prototype is more user friendly. Would it be possible to see a mock up with these changes for comparison? Your talent in graphics is much appreciated :) - Choose a lighter green than the one we have in the header for community, general, etc. boxes. Perhaps the same as the background in the logo. - Don't grey the boxes for community, general, etc. This would get rid of the empty grey box below header in the larger frame where the diagram resides - Leave the grey shadow line around the boxes. It is nice. - Tone down the architecture diagram colors. Use shades/variation of the same color. Perhaps light blue, mat blue and grey - possibly extend the architecture diagram to show an SCA composite application diagram which when clicked on would take us to a code sample - Change the red font for the links on the webpage to dark grey Thanks David I think this looks nice too. Generally I don't get too much into color schemes but I think lightening the green or limiting the number of colors/contrast may make the important things stand out a little more. We could do something like adopt the colors of the Tuscan flag :-) http://www.flagsonline.it/asp/bandiera.asp/bandiera_Toscana/Toscana.html Jim Thanks, Haleh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] indent on case
switch clause may have statements other than case, and people normally indent sub elements... -- Yang ZHONG
Re: [VOTE] indent on case
The other elements would go at the level of the break - indent 4 or indent 8 respectively. That's actually why I prefer the no-indent case as it puts the other elements at the same indent as if you were using an if block in rather than an additional 4 characters in. -- Jeremy On Aug 11, 2006, at 6:46 PM, Yang ZHONG wrote: switch clause may have statements other than case, and people normally indent sub elements... -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-611) RMI Binding
On Aug 11, 2006, at 6:29 PM, Jim Marino wrote: Forgot about the host. If we want to have one component per registry, what happens when two services register at the same host/port combination? If two registries register, the second should fail (as it won't be able to get the socket anyway). Right so that's why I was thinking it would be better to allow for multiple components per registry. Do you think that's not something that really is a problem? An RMI registry can support multiple services, see next statement. Services will have a uri whose path will distinguish them. RMI services have a URI path that they use to register with the registry so that it can contain multiple ones - like a servlet context is used to allow multiple webapps on the same socket. RHIHost= Web container (ServletHost) RMIRegistry= HTTP listener Remote Service = Servlet RMIRegistry instances are components deployed to the system that listen on sockets and dispatch requests to registered services based on URI path. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
