from:"Dan Becker"


[ 
https://issues.apache.org/jira/browse/TUSCANY-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682767#action_12682767
 ] 

Dan Becker commented on TUSCANY-2883:
-

Problem looks valid and I've recreated on 1.x 755259. It seems like wiring 
needs an extra level processing to connect the promoted AComponent/b reference 
to the c service.

 [1.x] NPE occurs when doing negative test about conformace item 60008
 -

 Key: TUSCANY-2883
 URL: https://issues.apache.org/jira/browse/TUSCANY-2883
 Project: Tuscany
  Issue Type: Task
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.4
Reporter: Shu Chao Wan
 Attachments: composite.patch


 In ASM60008, it says that The interfaces of the component references 
 promoted by a composite reference MUST be the same, or if the composite 
 reference itself declares an interface then all the component reference 
 interfaces must be compatible with the composite reference interface. 
 Compatible means that the component reference interface is the same or is a 
 strict subset of the composite reference interface. 
 In order to verify this statement in negative way, I wrote a composite file 
 whose  promoted component interface is incompatible with the composite 
 reference's interface, one is CService, and the other is BService, and then a 
 ServiceRuntimeException is expected as the result. But actually I got a 
 NullPointerException.
 
 TestCase
 
 @Test
 public void ASM60008_n() throws Exception {
 initDomain(differentreferenceinterface_outer.composite);
 AService service = ServiceFinder.getService(AService.class, 
 DifferentInterfaceComponent/AService);
 System.out.println(service.getState());
 cleanupDomain();
 }
 
 differentreferenceinterface_outer.composite
 
 composite ..
 component name=DifferentInterfaceComponent
 implementation.composite 
 name=assembly-tests:Assembly-different-reference-interface-inner-Composite/
 reference name=c target=CComponent/
  /component
 component name=CComponent
 implementation.java 
 class=org.apache.tuscany.sca.vtest.assembly.composite.impl.CServiceImpl/
 /component
 /composite
 
 differentreferenceinterface_inner.composite
 
 composite ..
 service name=AService promote=AComponent/
 component name=AComponent
 implementation.java  
 class=org.apache.tuscany.sca.vtest.assembly.composite.impl.AServiceImpl /
reference name=b   
 interface.java 
 interface=org.apache.tuscany.sca.vtest.assembly.composite.BService /
  /reference
 /component
  reference name=c promote=AComponent/b
   interface.java 
 interface=org.apache.tuscany.sca.vtest.assembly.composite.CService /
   /reference
 /composite
 
 NullPointerException
 
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sca.vtest.assembly.composite.impl.AServiceImpl.getState(AServiceImpl.java:39)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:162)
   at 
 org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:310)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:163)
   at $Proxy9.getState(Unknown Source)
   at 
 org.apache.tuscany.sca.vtest.assembly.composite.CompositeTestCase.ASM60008_n(CompositeTestCase.java:330)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run

[jira] Resolved: (TUSCANY-2822) Focus samples names on the Tuscany feature being tested.

[
https://issues.apache.org/jira/browse/TUSCANY-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dan Becker resolved TUSCANY-2822.
-

Resolution: Duplicate

Since this is superceded by TUSCANY-2917, I will let the later, more
comprehensive Jira take care of the fix.

Focus samples names on the Tuscany feature being tested.

Key: TUSCANY-2822
URL: https://issues.apache.org/jira/browse/TUSCANY-2822
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Samples
Affects Versions: Java-SCA-2.0
Environment: All
Reporter: Simon Laws
Priority: Minor

In 1.x our samples were names
calculator-???
helloworld-???
Which puts the focus on the application scenario rather that the Tuscany
feature being demonstrated by the sample. Change sample names and directory
names to the form
binding-rmi-reference-calculator
binding-rmi-service-calculator
binding-ws-calculator
host-webapp-calculator
implementation-java-calculator
launcher-osgi-calculator
launcher-jse-calculator
maven-osgi-junit-calculator
To focus on the main thing being shown by the sample. This has the effect of
focusing the samples on specific extensions (of course each sample will use
more features but these features are not the focus of the sample). It also
has the effect of grouping samples in the sample directory according to what
feature they are testing so it is easier to find a sample of interest.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2797) Update the homepage URL to refer to the new org.oasisopen URL


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2797.
-

   Resolution: Fixed
Fix Version/s: (was: Java-SCA-2.0)
   Java-SCA-Next

Fixed or updated pages at:

http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Articles+About+Tuscany
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Getting+started+with+Tuscany+SCA+development

Please open a Jira with any other pages that need updating with better Open 
OASIS spec linkgs.


 Update the homepage URL to refer to the new org.oasisopen URL
 ---

 Key: TUSCANY-2797
 URL: https://issues.apache.org/jira/browse/TUSCANY-2797
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.0-M1
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 Currently various files refer to thehomepage for SCA as:
 http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
 This should be updated to refer to the equivalent OASIS Open SCA-J page

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (TUSCANY-2822) Focus samples names on the Tuscany feature being tested.

[
https://issues.apache.org/jira/browse/TUSCANY-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dan Becker reopened TUSCANY-2822:
-

As Simon commented on the mailing list, the subject of TUSCANY-2917 is less
encompassing than I infered. I am reopening this because I agree.

Focus samples names on the Tuscany feature being tested.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2686) Vtest code for Java SCA assembly componentType ASM40002

2009-03-13 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2686.
-

Resolution: Won't Fix

Yiwen states that TUSCANY-2686 is superceded by TUSCANY-2765.

 Vtest code for Java SCA assembly componentType ASM40002
 ---

 Key: TUSCANY-2686
 URL: https://issues.apache.org/jira/browse/TUSCANY-2686
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.3
Reporter: Yiwen Huang
Assignee: Simon Laws
Priority: Minor
 Attachments: ASM40002.patch, ASM40002_b.patch, ASM40002_c.patch


 Hello,
 I'd like to submit my first vtest patch, for conformance test ASM40002.  
 As this is my first attempt at writing vtest, please let me know if there is 
 any problem with the patch or the test method.
 As I mentioned in my post 
 (http://www.mail-archive.com/dev@tuscany.apache.org/msg03443.html), the test 
 does not fail for me, which it should.  Let me know what we should do about 
 it too, thanks!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2884) [1.x] This jira is used to submit test case

2009-03-11 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2884.
-

Resolution: Won't Fix

 [1.x] This jira is used to submit test case 
 

 Key: TUSCANY-2884
 URL: https://issues.apache.org/jira/browse/TUSCANY-2884
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.4
Reporter: Shu Chao Wan
Assignee: Dan Becker
 Attachments: composite.patch


 It's used to submit test case for conformance items 60001-60008, and 
 60015-60016. Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [2.x] OSGi RFC 119 implemention using Tuscany Java SCA

2009-03-11 Thread Dan Becker

Hi Raymond,

Fantastic job with both the presentation and the accompanying code.

I have one question. I see from the osgitest.composite that the service
interface is referenced by the following element:
tuscany:implementation.osgi bundle=OSGiTestService
bundleSymbolicName=org.apache.tuscany.sca.implementation.osgi.test.OSGiTestInterface
/

How is the bundle and bundleSymbolicName used to look up the bundle of
the component service? Is this information enough to find the required
service?

(P.S. Perhaps I missed the answer in the presentation, but this might be
a useful question and answer for your PDF.)

Raymond Feng wrote:
OSGi RFC 119 [2] specifies how OSGi services can be distributed using
SCA as the distribution software. We have seen user interests in Tuscany
community to implement RFC 119 using Java SCA [3].

I begin to look into this area recently. You can find a set of slides
[1] I put together to better understand the usage scenario and a high
level view of the work. The main idea is to use implementation.osgi to
model an OSGi bundle in SCA and provide remoting for OSGi services using
SCA bindings and intents. I have also started to port (from 1.x) and
develop the implemention.osgi module. The code is available at [4].

[1]
http://cwiki.apache.org/confluence/download/attachments/112304/RFC+119+with+Tuscany+SCA.pdf

[2]
http://www.osgi.org/Download/File?url=/download/osgi-4.2-early-draft2.pdf

[3] http://www.mail-archive.com/dev@tuscany.apache.org/msg05305.html
[4]
http://svn.apache.org/repos/asf/tuscany/java/sca/modules/implementation-osgi/

--
Thanks, Dan Becker

[jira] Issue Comment Edited: (TUSCANY-2884) [1.x] This jira is used to submit test case

2009-03-11 Thread Dan Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680904#action_12680904
 ] 

Dan Becker edited comment on TUSCANY-2884 at 3/11/09 12:30 PM:
---

Whoops. These vtests are in fact unrelated to the Tuscany-2907 stests. Let me 
reopen

  was (Author: beckerdo):
Whoops. These vtests are in fact unrelated to the Tuscany-2904 stests. Let 
me reopen
  
 [1.x] This jira is used to submit test case 
 

 Key: TUSCANY-2884
 URL: https://issues.apache.org/jira/browse/TUSCANY-2884
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.4
Reporter: Shu Chao Wan
Assignee: Dan Becker
 Attachments: composite.patch


 It's used to submit test case for conformance items 60001-60008, and 
 60015-60016. Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2907) Stest code submit by kujunguo 2009_03_06


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2907:
---

Assignee: Dan Becker

 Stest code submit by kujunguo 2009_03_06
 

 Key: TUSCANY-2907
 URL: https://issues.apache.org/jira/browse/TUSCANY-2907
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.3.1
Reporter: Ku Jun Guo
Assignee: Dan Becker
Priority: Minor
 Attachments: Kujunguo_SCA_Assembly_TestCases.doc, 
 stest_20090306_kujunguo.diff


 Simon,
 Here is my TestCases from ASM_0025 to ASM_0031, you can apply it  to stest 
 directory. Any problem pls let me know.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2898) SCA 1.x failed to get the property value for the complex type


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2898:
---

Assignee: Dan Becker

 SCA 1.x failed to get the property value for the complex type
 -

 Key: TUSCANY-2898
 URL: https://issues.apache.org/jira/browse/TUSCANY-2898
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.3.1
Reporter: Ku Jun Guo
Assignee: Dan Becker

 When I ran the stest case for SCA 1.x, I found it failed
 !-- Tests that where a component/ property/ has its value set by means 
  of a child value/ element, that the type of the value/ element 
 matches 
  the type declared for the property/ element   --
 composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://oasis/tests;
xmlns:tns=http://oasis/tests;
xmlns:test=http://oasis/tests;
name=TEST_ASM_0025

 component name=TestClient
   implementation.composite name=tns:TestClient_0002/
   service name=TestInvocation
   interface.java interface=test.TestInvocation/
 binding.ws/
   /service
 reference name=reference1 target=TestComponent1/Service1 /
 property name=testNameASM_0025/property
 /component
 
 component name=TestComponent1
   implementation.composite name=tns:TestComposite12/
 service name=Service1
   interface.java interface=test.Service1/
 /service
 property name=serviceNameservice1/property
 !-- Property with complex type with a value declared using a 
 value/ subelement --
 property name=complexType type=test:ComplexType1
   ComplexType1Value type=test:ComplexType1
   test:firstDatacomplex1/test:firstData
   test:secondDatacomplex2/test:secondData
 /ComplexType1Value
 
 !--
 value
   firstDatacomplex1/firstData
   secondDatacomplex2/secondData
 /value
 --
 /property
 /component 
 
 /composite
 TestComposite12.composite:: 
 composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://oasis/tests;
xmlns:test=http://oasis/tests;
name=TestComposite12

   service name=Service1 promote=TestComponent1/Service1
   interface.java interface=test.Service1/interface.java
   /service
 property name=serviceName type=string/
 
 property name=complexType type=test:ComplexType1/
  
 component name=TestComponent1
   implementation.java class=test.service1Impl5/
 service name=Service1
   interface.java interface=test.Service1/
 /service
 property name=serviceName source=$serviceName/
 property name=serviceData1 source=$complexType/firstData/
 property name=serviceData2 source=$complexType/secondData/
 /component
 /composite
 service1Impl5.java :
 @Service(Service1.class)
 public class service1Impl5 implements Service1 {
   
   @Property
   public String serviceName = service1;
   @Property
   public String serviceData1;
   @Property
   public String serviceData2;
   public String operation1(String input) {
   return serviceName +  operation1 invoked + serviceData1 + 
 serviceData2;
   }
 }
 Test_Types.xsd:
 schema xmlns=http://www.w3.org/2001/XMLSchema; 
 targetNamespace=http://oasis/tests;
 xmlns:test=http://oasis/tests;
 xmlns:sca=http://www.osoa.org/xmlns/sca/1.0;
 elementFormDefault=qualified
 !-- A complex type --
 complexType name=ComplexType1
   element name=firstData type=string /
 element name=secondData type=string /
 /complexType
 
 !-- A global element with a complex type --
 element name=globalElement1 type=test:ComplexType1/

 /schema
 Anything wrong with my artifacts?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2907) Stest code submit by kujunguo 2009_03_06


[ 
https://issues.apache.org/jira/browse/TUSCANY-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680504#action_12680504
 ] 

Dan Becker commented on TUSCANY-2907:
-

Hello Ku Jun Guo,
I am seeing test failures in the following test case on branch 1.x, revision 
752101:
Failed tests: 
  testDummy(client.BaseJAXWSTestCase)
  testDummy(client.ASM_0028_TestCase)
  testDummy(client.ASM_0023_TestCase)

Are these expected until other Jiras are fixed? Do these match your testing or 
do we differ?

 Stest code submit by kujunguo 2009_03_06
 

 Key: TUSCANY-2907
 URL: https://issues.apache.org/jira/browse/TUSCANY-2907
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.3.1
Reporter: Ku Jun Guo
Assignee: Dan Becker
Priority: Minor
 Attachments: Kujunguo_SCA_Assembly_TestCases.doc, 
 stest_20090306_kujunguo.diff


 Simon,
 Here is my TestCases from ASM_0025 to ASM_0031, you can apply it  to stest 
 directory. Any problem pls let me know.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2901) It should throw a runtime exception when component property name is not matched


[ 
https://issues.apache.org/jira/browse/TUSCANY-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680510#action_12680510
 ] 

Dan Becker commented on TUSCANY-2901:
-

I can see no requirement in the OSOA or OASIS assembly specification that 
requires a failure or exception if a property does not exist in an 
implementation. In my view, a warning is appropriate since the value is not 
being used, and the builder is letting you know about this. Since the user is 
being notified, I think the current behavior is adequate and acceptable.

 It should throw a runtime exception when component property name is not 
 matched
 ---

 Key: TUSCANY-2901
 URL: https://issues.apache.org/jira/browse/TUSCANY-2901
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.3.1
Reporter: Ku Jun Guo

 If the property name in composite file is not matched with the 
 implementation, it should throw a ServiceRuntimeException, but in my test, it 
 just 
 gave some warning messages.
 Mar 4, 2009 9:54:57 AM 
 org.apache.tuscany.sca.assembly.builder.impl.ComponentConfigurationBuilderImpl
 WARNING: Property not found for component property: Component = 
 TestComponent1 Property = randomName
 Mar 4, 2009 9:54:57 AM 
 org.apache.tuscany.sca.assembly.builder.impl.CompositeBindingURIBuilderImpl
 WARNING: Property not found for component property: Component = 
 TestComponent1 Property = randomName
 My composite file:
 component name=TestComponent1
   implementation.composite name=tns:TestComposite1/
 service name=Service1
   interface.java interface=test.Service1/
 /service
 
 !--
 property name=serviceNameservice1/property
 --
 
 !-- Property with @name attribute that does not match the @name
  attribute of any of the property/ elements in the 
  componentType/ of the implementation/ --
 property name=randomNamerandomValue/property
 /component 
 Service Impl class :
 @Service(Service1.class)
 public class service1Impl implements Service1 {
   
   @Property
   public String serviceName = service1;
   public String operation1(String input) {
   return serviceName +  operation1 invoked;
   }
 }
 Anyone has comments on this? Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2905) Default operation selection does not implement third rule which is supposed to look for an operation name in the root element of the XML payload


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2905:
---

Assignee: Dan Becker

 Default operation selection does not implement third rule which is supposed 
 to look for an operation name in the root element of the XML payload
 

 Key: TUSCANY-2905
 URL: https://issues.apache.org/jira/browse/TUSCANY-2905
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Reporter: Kaushik Mukherjee
Assignee: Dan Becker
 Attachments: TUSCANY-2905.patch


 Default operation selection does not implement third rule which is supposed 
 to look for an operation name in the root element of the XML payload
 The Oasis spec adds a rule to default operation selection as follows:
 290 • Otherwise, if the message is a JMS text or bytes message containing 
 XML, then the selected
 291 operation name is taken from the local name of the root element of the 
 XML payload.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2905) Default operation selection does not implement third rule which is supposed to look for an operation name in the root element of the XML payload

[
https://issues.apache.org/jira/browse/TUSCANY-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dan Becker resolved TUSCANY-2905.
-

Resolution: Fixed

Hello Kaushik,
Thanks for contributing the patch. I've applied it to the 1.x branch and run
unit, stests, and itests, and it passes.

I have a few suggestions for future patches that will help make it easier to
integrate and test:
1) Let us know whether the branch is for trunk or one of the branches.
2) Generate the diff from the module or higher level.
3) Provide a unit test in the patch that tests the positive and negative
aspects of the patch.

These steps make it easier to find which directory to apply the patch, and the
unit tests make it easy to see the fix in action.

Default operation selection does not implement third rule which is supposed
to look for an operation name in the root element of the XML payload

Key: TUSCANY-2905
URL: https://issues.apache.org/jira/browse/TUSCANY-2905
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Reporter: Kaushik Mukherjee
Assignee: Dan Becker
Attachments: TUSCANY-2905.patch

Default operation selection does not implement third rule which is supposed
to look for an operation name in the root element of the XML payload
The Oasis spec adds a rule to default operation selection as follows:
290 • Otherwise, if the message is a JMS text or bytes message containing
XML, then the selected
291 operation name is taken from the local name of the root element of the
XML payload.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: FYI: Tuscany Java SCA 2.0-M1 is announced on InfoQ.com

2009-03-05 Thread Dan Becker


Raymond Feng wrote:

http://www.infoq.com/news/2009/03/apache-tuscany-java-sca




Great article. It's nice how they linked so much of the text back to the 
actual web sites and resources.


It's also good to see the blog updated so frequently recently in support 
of Tuscany's OSGi as well. Hopefully it will generate some buzz and 
raise even more interest in Tuscany 2.0.


--
Thanks, Dan Becker

[jira] Assigned: (TUSCANY-2897) requestConnection and responseConnection in JMSBinding model should be QNames not Strings


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2897:
---

Assignee: Dan Becker

 requestConnection and responseConnection in JMSBinding model should be QNames 
 not Strings
 -

 Key: TUSCANY-2897
 URL: https://issues.apache.org/jira/browse/TUSCANY-2897
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Reporter: Greg Dritschler
Assignee: Dan Becker
Priority: Minor
 Attachments: tuscany-2897.patch


 In the JMSBinding model the requestConnection and responseConnection 
 attributes are treated as Strings.  According to the schema they are supposed 
 to be QNames (where the namespace is used to locate the definition document 
 and the local part is the binding name).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2897) requestConnection and responseConnection in JMSBinding model should be QNames not Strings


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2897.
-

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

Resolved in branch 1.x at revision: 750052  . Thanks for the fix.


 requestConnection and responseConnection in JMSBinding model should be QNames 
 not Strings
 -

 Key: TUSCANY-2897
 URL: https://issues.apache.org/jira/browse/TUSCANY-2897
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Reporter: Greg Dritschler
Assignee: Dan Becker
Priority: Minor
 Fix For: Java-SCA-Next

 Attachments: tuscany-2897.patch


 In the JMSBinding model the requestConnection and responseConnection 
 attributes are treated as Strings.  According to the schema they are supposed 
 to be QNames (where the namespace is used to locate the definition document 
 and the local part is the binding name).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2884) [1.x] This jira is used to submit test case


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2884:
---

Assignee: Dan Becker

 [1.x] This jira is used to submit test case 
 

 Key: TUSCANY-2884
 URL: https://issues.apache.org/jira/browse/TUSCANY-2884
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.4
Reporter: Shu Chao Wan
Assignee: Dan Becker
 Attachments: composite.patch


 It's used to submit test case for conformance items 60001-60008, and 
 60015-60016. Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2884) [1.x] This jira is used to submit test case


[ 
https://issues.apache.org/jira/browse/TUSCANY-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678915#action_12678915
 ] 

Dan Becker commented on TUSCANY-2884:
-

Hello Shu Chao Wan,
Can you investigate this patch? I attempt to use the patch on my 
\branches\sca-java-1.x\vtest\assembly\composite\ repos and svn complains. For 
example CService.java in your patch was made from revision 743607. However, 
when I look at the public repos, CService.java is at the 721498 level. And the 
branch 1.4 version of CService is at the 722428 revision.

So please let us know how you made this patch or let me know if I've misapplied 
your patch. Thanks.

 [1.x] This jira is used to submit test case 
 

 Key: TUSCANY-2884
 URL: https://issues.apache.org/jira/browse/TUSCANY-2884
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.4
Reporter: Shu Chao Wan
Assignee: Dan Becker
 Attachments: composite.patch


 It's used to submit test case for conformance items 60001-60008, and 
 60015-60016. Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2871) ClassCastException using atom-abdera binding


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2871:
---

Assignee: Dan Becker

 ClassCastException using atom-abdera binding
 

 Key: TUSCANY-2871
 URL: https://issues.apache.org/jira/browse/TUSCANY-2871
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA ATOM Binding Extension
Affects Versions: Java-SCA-1.4
Reporter: Brent Daniel
Assignee: Dan Becker

 If you use the atom-abdera binding with a reference that points to an RSS 
 feed rather than an atom feed, you get a ClassCastException rather than a 
 reasonable error. This occurs in the Tuscany feed-aggregator sample, but the 
 exception is being swallowed in the java implementation.
 From FeedAggregator.composite in the feed-aggregator sample (the uri points 
 to an RSS 2.0 feed): 
 reference name=atomFeed1
   tuscany:binding.atom 
 uri=http://www.oreillynet.com/pub/feed/35/
   /reference
 The following code in AtomBindingInvoker (346-348) results in the 
 ClassCastException:
  DocumentFeed doc = abderaParser.parse(new 
 InputStreamReader(getMethod.getResponseBodyAsStream()));
 parsing = true;
 Feed feed = doc.getRoot();
 doc.getRoot() returns an instance of 
 org.apache.abdera.parser.stax.FOMExtensibleElement rather than Feed. 
 AggregatorImpl in the feed-aggregator sample is swallowing the exception here 
 (85-89):
  if (atomFeed1 != null) {
 try {
 entries.addAll(atomFeed1.getFeed().getEntries());
 } catch (Exception e) {}
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (TUSCANY-2879) [1.x] ITest failure in TEST-interfacewsdl.xml.InvalidWSDLInterfaceAttrTestCase

2009-02-26 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker closed TUSCANY-2879.
---


I'm getting a clean build as well.

 [1.x] ITest failure in TEST-interfacewsdl.xml.InvalidWSDLInterfaceAttrTestCase
 --

 Key: TUSCANY-2879
 URL: https://issues.apache.org/jira/browse/TUSCANY-2879
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-Next
 Environment: branch 1.x revision 747826
Reporter: Dan Becker
 Fix For: Java-SCA-Next


  testcase time=0.094 name=testCalculator
 failure message=null 
 expected:amp;lt;[InvalidWSDLInterfaceAttr]amp;gt; 
 but was:amp;lt;[AttributeCannotBeProcessed]amp;gt; 
 
 type=junit.framework.ComparisonFailurejunit.framework.ComparisonFailure: 
 null expected:amp;lt;[InvalidWSDLInterfaceAttr]amp;gt; but 
 was:amp;lt;[AttributeCannotBeProcessed]amp;gt;
   at junit.framework.Assert.assertEquals(Assert.java:81)
   at junit.framework.Assert.assertEquals(Assert.java:87)
   at 
 interfacewsdl.xml.InvalidWSDLInterfaceAttrTestCase.testCalculator(InvalidWSDLInterfaceAttrTestCase.java:58)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at junit.framework.TestCase.runTest(TestCase.java:168)
   at junit.framework.TestCase.runBare(TestCase.java:134)
   at junit.framework.TestResult$1.protect(TestResult.java:110)
   at junit.framework.TestResult.runProtected(TestResult.java:128)
   at junit.framework.TestResult.run(TestResult.java:113)
   at junit.framework.TestCase.run(TestCase.java:124)
   at junit.framework.TestSuite.runTest(TestSuite.java:232)
   at junit.framework.TestSuite.run(TestSuite.java:227)
   at 
 org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:79)
   at 
 org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
 /failure

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (TUSCANY-2856) 'property' validation conflicts with osoa spec


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reopened TUSCANY-2856:
-


I see when running itest-jms PolicyHeadersTestCase the following error:
Feb 25, 2009 8:26:37 AM 
org.apache.tuscany.sca.contribution.processor.ValidatingXMLStreamReader
SEVERE: XMLSchema validation error occured in: null ,line = 25, column = 19, 
Message = cvc-type.3.1.1: Element 'property' is a simple type, so it cannot 
have attributes, excepting those whose namespace name is identical to 
'http://www.w3.org/2001/XMLSchema-instance' and whose [local name] is one of 
'type', 'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, the 
attribute, 'name' was found.

This appears to be the same error as reported by Christopher. I will look into 
this.

 'property' validation conflicts with osoa spec
 --

 Key: TUSCANY-2856
 URL: https://issues.apache.org/jira/browse/TUSCANY-2856
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: Java JMS Binding extention
Reporter: Christopher N. Ortiz
Assignee: Dan Becker

 The validation of 'property' element like this property name=propName 
 type=stringmyvalue/property produced this error:
 Element 'property' is a simple type, so it cannot have attributes, excepting 
 those whose namespace name is identical to 
 'http://www.w3.org/2001/XMLSchema-instance' and whose [local name] is one of 
 'type', 'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, the 
 attribute, 'name' was found. XMLSchema validation error occured in: null 
 ,line = -1, column = -1, Message = cvc-type.3.1.1:
 But the OSOA SCA JMS spec defines property in header element like this:
 property name=NMTOKEN type=NMTOKEN*

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TUSCANY-2879) [1.x] ITest failure in TEST-interfacewsdl.xml.InvalidWSDLInterfaceAttrTestCase

[1.x] ITest failure in TEST-interfacewsdl.xml.InvalidWSDLInterfaceAttrTestCase
--

 Key: TUSCANY-2879
 URL: https://issues.apache.org/jira/browse/TUSCANY-2879
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-Next
 Environment: branch 1.x revision 747826
Reporter: Dan Becker


 testcase time=0.094 name=testCalculator
failure message=null expected:amp;lt;[InvalidWSDLInterfaceAttr]amp;gt; 
but was:amp;lt;[AttributeCannotBeProcessed]amp;gt; 

type=junit.framework.ComparisonFailurejunit.framework.ComparisonFailure: 
null expected:amp;lt;[InvalidWSDLInterfaceAttr]amp;gt; but 
was:amp;lt;[AttributeCannotBeProcessed]amp;gt;
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at 
interfacewsdl.xml.InvalidWSDLInterfaceAttrTestCase.testCalculator(InvalidWSDLInterfaceAttrTestCase.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:79)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
/failure


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TUSCANY-2880) [1.x] ITest failure in TEST-binding.jms.UnexpectedElementTestCase

[1.x] ITest failure in TEST-binding.jms.UnexpectedElementTestCase
-

 Key: TUSCANY-2880
 URL: https://issues.apache.org/jira/browse/TUSCANY-2880
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-Next
 Environment: Branch 1.x revision 747826
Reporter: Dan Becker
Priority: Minor


failure message=null expected:amp;lt;[UnexpectedElement]amp;gt; but 
was:amp;lt;[SchemaError]amp;gt; 

type=junit.framework.ComparisonFailurejunit.framework.ComparisonFailure: 
null expected:amp;lt;[UnexpectedElement]amp;gt; but 
was:amp;lt;[SchemaError]amp;gt;
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at 
binding.jms.UnexpectedElementTestCase.testCalculator(UnexpectedElementTestCase.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:79)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
/failure


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2857) Correct handling of JMSDeliveryMode and JMSPriority


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2857.
-

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

Completed in branch 1.x: At revision: 747867  


 Correct handling of JMSDeliveryMode and JMSPriority
 ---

 Key: TUSCANY-2857
 URL: https://issues.apache.org/jira/browse/TUSCANY-2857
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Reporter: Greg Dritschler
Assignee: Dan Becker
Priority: Minor
 Fix For: Java-SCA-Next


 I've noticed that JMSHeaderReferencePolicyInterceptor and 
 TransportServiceInterceptor set the JMSDeliveryMode and JMSPriority headers 
 in the request and response JMS messages respectively before the messages are 
 sent.  I am under the impression that the JMS API requires these header 
 values to be set via the MessageProducer interface.  The values in the 
 Message are ignored.
 See Table 31-1 here:  
 http://docs.sun.com/app/docs/doc/819-3669/bnceh?l=jaa=view
 This issue was discussed on dev list on January 20, 2009 and it was agreed 
 this is a bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Validation of XML composites

2009-02-25 Thread Dan Becker


Simon Laws wrote:

On Wed, Feb 25, 2009 at 8:02 PM, Dan Becker dan.o.bec...@gmail.com wrote:

I notice that JMSBindingProcessorTestCase sets up its own
ExtensibleStAXArtifactProcessor. PolicyHeadersTestCase uses
SCADomain.newInstance to create a NodeImpl which sets up a
StAXArtifactProcessor.

Can anyone point me in a direction as to which StAX processor set up method
is correct or other insight as to how to validate these composites properly?


Firstly the schema we currently have in 1.x doesn't specify that a name
attribute can appear in this place so the error is correctly being reported.
However what I didn't notice when I reported the problem in the first place
is that the OSOA spec is internally inconsistent in that the psuedo schema
shows that the name attribute is intended to the allowable but the actual
schema at the back of the spec doesn't include it. I think we need to fix
the schema we have on the assumption that this is just an editorial error in
the spec. The OASIS spec goes this way anyhow so it would seem to be taking
us in the right direction.



Thanks Simon. I hear what you are saying, and it makes sense that we 
should allow the more complex property elements with name and type 
attributes. I'll update the schema for TUSCANY-2856.


Additionally, the Tuscany JMSBindingProcessor is already set up to read 
the complex binding properties with name and type attributes. So even 
though the older schema disallows it, the read and write code already 
processes it.


--
Thanks, Dan Becker

[jira] Resolved: (TUSCANY-2856) 'property' validation conflicts with osoa spec


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2856.
-

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

Fixed in branch 1.x  at revision: 747933  . Thanks Christopher.


 'property' validation conflicts with osoa spec
 --

 Key: TUSCANY-2856
 URL: https://issues.apache.org/jira/browse/TUSCANY-2856
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: Java JMS Binding extention
Reporter: Christopher N. Ortiz
Assignee: Dan Becker
 Fix For: Java-SCA-Next


 The validation of 'property' element like this property name=propName 
 type=stringmyvalue/property produced this error:
 Element 'property' is a simple type, so it cannot have attributes, excepting 
 those whose namespace name is identical to 
 'http://www.w3.org/2001/XMLSchema-instance' and whose [local name] is one of 
 'type', 'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, the 
 attribute, 'name' was found. XMLSchema validation error occured in: null 
 ,line = -1, column = -1, Message = cvc-type.3.1.1:
 But the OSOA SCA JMS spec defines property in header element like this:
 property name=NMTOKEN type=NMTOKEN*

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2849) Unable to define operation-level intents on binding.jms

2009-02-19 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2849.
-

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

Completed in branch 1.x at revision: 745909  


 Unable to define operation-level intents on binding.jms
 ---

 Key: TUSCANY-2849
 URL: https://issues.apache.org/jira/browse/TUSCANY-2849
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Reporter: Greg Dritschler
Assignee: Dan Becker
Priority: Minor
 Fix For: Java-SCA-Next


 binding.jms does not appear to support operation-level policy intents.
 I believe the following needs to be done to add the support.
 (1) org.apache.tuscany.sca.binding.jms.impl.JMSBinding needs to implement the 
 org.apache.tuscany.sca.assembly.OperationsConfigurator interface.
 (2) org.apache.tuscany.sca.binding.jms.impl.JMSBindingProcessor needs to 
 implement calls to 
 org.apache.tuscany.sca.assembly.xml.ConfiguredOperationProcessor to read and 
 write the operation elements.  The web service binding has an example of 
 how to do this (although it seems to be missing the write logic).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2856) 'property' validation conflicts with osoa spec

2009-02-19 Thread Dan Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675112#action_12675112
 ] 

Dan Becker commented on TUSCANY-2856:
-

Christopher,
On which element of the JMS binding did you specify this property? I tried the 
following property and found no validation error:
   binding.jms uri=jms:testQueue 
  headers
 property name=propName type=stringmyvalue/property
  /headers
   /binding.jms

I will test other locations for properties in binding.jms to see if Tuscany has 
different validations. I will report back here if I find a specific location 
that has a problem.

If you have a sample that demonstrates the validation issue, please comment 
here.


 'property' validation conflicts with osoa spec
 --

 Key: TUSCANY-2856
 URL: https://issues.apache.org/jira/browse/TUSCANY-2856
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: Java JMS Binding extention
Reporter: Christopher N. Ortiz
Assignee: Dan Becker

 The validation of 'property' element like this property name=propName 
 type=stringmyvalue/property produced this error:
 Element 'property' is a simple type, so it cannot have attributes, excepting 
 those whose namespace name is identical to 
 'http://www.w3.org/2001/XMLSchema-instance' and whose [local name] is one of 
 'type', 'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, the 
 attribute, 'name' was found. XMLSchema validation error occured in: null 
 ,line = -1, column = -1, Message = cvc-type.3.1.1:
 But the OSOA SCA JMS spec defines property in header element like this:
 property name=NMTOKEN type=NMTOKEN*

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2856) 'property' validation conflicts with osoa spec

2009-02-19 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2856.
-

Resolution: Cannot Reproduce

Was able to read and validate the following composite XML using 
JMSBindingProcessorTestCase code:
  public static final String HEADERS2 =
  ?xml version=\1.0\ encoding=\ASCII\? 
  + composite xmlns=\http://www.osoa.org/xmlns/sca/1.0\; 
targetNamespace=\http://binding-jms\; name=\binding-jms\
  +  component name=\HelloWorldComponent\
  +implementation.java class=\services.HelloWorld\/
  +   service name=\HelloWorldService\
  +   binding.jms uri=\jms:testQueue\ 
  +  headers JMSType=\myType\ 
JMSCorrelationID=\myCorrelId\ JMSDeliveryMode=\PERSISTENT\ 
JMSTimeToLive=\54321\ JMSPriority=\5\
  + property name=\First prop\ type=\string\that 
prop/property
  + property name=\Second prop\ 
type=\long\1234567/property
  +  /headers 
  +   /binding.jms
  +   /service
  +  /component
  + /composite;


Tuscany had no problem validating and returning the properties. Since this 
property read code is shared throughout the Tuscany jms.binding, I think the 
issue is caused outside of Tuscany.

 'property' validation conflicts with osoa spec
 --

 Key: TUSCANY-2856
 URL: https://issues.apache.org/jira/browse/TUSCANY-2856
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: Java JMS Binding extention
Reporter: Christopher N. Ortiz
Assignee: Dan Becker

 The validation of 'property' element like this property name=propName 
 type=stringmyvalue/property produced this error:
 Element 'property' is a simple type, so it cannot have attributes, excepting 
 those whose namespace name is identical to 
 'http://www.w3.org/2001/XMLSchema-instance' and whose [local name] is one of 
 'type', 'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, the 
 attribute, 'name' was found. XMLSchema validation error occured in: null 
 ,line = -1, column = -1, Message = cvc-type.3.1.1:
 But the OSOA SCA JMS spec defines property in header element like this:
 property name=NMTOKEN type=NMTOKEN*

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2856) 'property' validation conflicts with osoa spec

2009-02-18 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2856:
---

Assignee: Dan Becker

 'property' validation conflicts with osoa spec
 --

 Key: TUSCANY-2856
 URL: https://issues.apache.org/jira/browse/TUSCANY-2856
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: Java JMS Binding extention
Reporter: Christopher N. Ortiz
Assignee: Dan Becker

 The validation of 'property' element like this property name=propName 
 type=stringmyvalue/property produced this error:
 Element 'property' is a simple type, so it cannot have attributes, excepting 
 those whose namespace name is identical to 
 'http://www.w3.org/2001/XMLSchema-instance' and whose [local name] is one of 
 'type', 'nil', 'schemaLocation' or 'noNamespaceSchemaLocation'. However, the 
 attribute, 'name' was found. XMLSchema validation error occured in: null 
 ,line = -1, column = -1, Message = cvc-type.3.1.1:
 But the OSOA SCA JMS spec defines property in header element like this:
 property name=NMTOKEN type=NMTOKEN*

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Operation-level intents on binding.jms

2009-02-18 Thread Dan Becker

I've been looking into TUSCANY-2849 Operation-level intents on 
binding.jms, and I have a few questions that possibly the group can answer.


The Jira states that the Tuscany web service binding implements to read 
and write these intents, but being new to intents, I would like to be 
sure I'm on the right track. First of all, is it true that the spec is 
contained in SCA_Policy_Framework_V100.pdf, section 1.4.5 and the schema 
in the appendix?


Secondly, I would like to see some example. For instance, in 
PoliciedCalculator.composite in binding-wss-xml, I see the following 
operation intent:
   binding.ws uri=http://localhost:8085/Calculator; 
wsdlElement=http://sample/calculator#wsdl.service(CalculatorService)

  operation name=add requires=IntentOne IntentTwo/
   /binding.ws
I assume, the operation intent on the JMS binding would be similar. Is 
this true? If anyone could point be to other examples that would make 
useful test case, I would appreciate it.


I see Tuscany already had processors (e.g. ConfiguredOperationProcessor) 
to read the intents, so binding.jms would make use of these processors.


[1] http://issues.apache.org/jira/browse/TUSCANY-2849
--
Thanks, Dan Becker

Re: Operation-level intents on binding.jms

2009-02-18 Thread Dan Becker


Luciano Resende wrote:

On Wed, Feb 18, 2009 at 10:57 AM, Dan Becker dan.o.bec...@gmail.com wrote:

Secondly, I would like to see some example. For instance, in
PoliciedCalculator.composite in binding-wss-xml, I see the following
operation intent:
  binding.ws uri=http://localhost:8085/Calculator;
wsdlElement=http://sample/calculator#wsdl.service(CalculatorService)
 operation name=add requires=IntentOne IntentTwo/
  /binding.ws
I assume, the operation intent on the JMS binding would be similar. Is this
true? If anyone could point be to other examples that would make useful test
case, I would appreciate it.

I see Tuscany already had processors (e.g. ConfiguredOperationProcessor) to
read the intents, so binding.jms would make use of these processors.



Should the JMS Binding processor delegate to the extension point, and
then the operations element would be handled by compositeProcessor /
Policy processor ? If you run
org.apache.tuscany.sca.assembly.xml.ReadAllTestCase and make a
breakpoint in compositeProcessor line 423 you should see how this is
delegation is happening.


[1] http://issues.apache.org/jira/browse/TUSCANY-2849


Hi Luciano,

Thanks for your comments. That helps me with understanding my third 
question about how the policy and intents are read. I see that the 
CompositeProcessor calls the JMSBindingProcessor which then tries to 
read the intent. Cool, I understand this part now.


Which brings me to the part that I am implementing. I'm getting some 
unexpected element errors in the JMSBindingProcess, and I'm trying to 
understand what a valid operation-level intent looks like.


Would this be a legal JMS binding with a configured operation-level intent?
   binding.jms uri=\jms:testQueue\ 
  operationProperties name=\op1\
  /operationProperties 
  operation name=\op1\ requires=\IntentOne IntentTwo\/
   /binding.jms

--
Thanks, Dan Becker

[jira] Assigned: (TUSCANY-2849) Unable to define operation-level intents on binding.jms

2009-02-17 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2849:
---

Assignee: Dan Becker

 Unable to define operation-level intents on binding.jms
 ---

 Key: TUSCANY-2849
 URL: https://issues.apache.org/jira/browse/TUSCANY-2849
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Reporter: Greg Dritschler
Assignee: Dan Becker
Priority: Minor

 binding.jms does not appear to support operation-level policy intents.
 I believe the following needs to be done to add the support.
 (1) org.apache.tuscany.sca.binding.jms.impl.JMSBinding needs to implement the 
 org.apache.tuscany.sca.assembly.OperationsConfigurator interface.
 (2) org.apache.tuscany.sca.binding.jms.impl.JMSBindingProcessor needs to 
 implement calls to 
 org.apache.tuscany.sca.assembly.xml.ConfiguredOperationProcessor to read and 
 write the operation elements.  The web service binding has an example of 
 how to do this (although it seems to be missing the write logic).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TUSCANY-2855) Holder sample not appearing in 1.x repos

2009-02-17 Thread Dan Becker (JIRA)

Holder sample not appearing in 1.x repos


 Key: TUSCANY-2855
 URL: https://issues.apache.org/jira/browse/TUSCANY-2855
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-Next
 Environment: All
Reporter: Dan Becker
Assignee: Dan Becker
Priority: Minor
 Fix For: Java-SCA-Next


Had a bit of trouble comitting holder sample wia Tuscany-2768. Will add holder 
sample via this Jira.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2855) Holder sample not appearing in 1.x repos

2009-02-17 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2855.
-

Resolution: Fixed

Commited in 1.x branch Completed: At revision: 745215  


 Holder sample not appearing in 1.x repos
 

 Key: TUSCANY-2855
 URL: https://issues.apache.org/jira/browse/TUSCANY-2855
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-Next
 Environment: All
Reporter: Dan Becker
Assignee: Dan Becker
Priority: Minor
 Fix For: Java-SCA-Next


 Had a bit of trouble comitting holder sample wia Tuscany-2768. Will add 
 holder sample via this Jira.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release Tuscany Maven Eclipse Compiler 1.0

2009-02-13 Thread Dan Becker


+1 here. Looks good.

Luciano Resende wrote:

Looks good to me, +1

On Fri, Feb 13, 2009 at 6:35 AM, ant elder antel...@apache.org wrote:


On Fri, Feb 13, 2009 at 2:29 PM, Simon Laws simonsl...@googlemail.com
wrote:


On Fri, Feb 13, 2009 at 11:33 AM, ant elder ant.el...@gmail.com wrote:


On Tue, Feb 10, 2009 at 9:52 AM, ant elder ant.el...@gmail.com wrote:

Please vote on releasing the Tuscany Maven Eclipse Compiler module. The
tag for the release is:


https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/maven-eclipse-compiler-1.0/

the Maven staging repository is:

http://people.apache.org/~antelder/tuscany/maven-eclipse-compiler-1.0/

   ...ant


Adding my vote to remind people this is pending still.

+1

Also, in case the location of the tag is bothering anyone we can put the
tag anywhere we like and can rename and move the tag after the release vote
as we do with the SCA releases, eg i've just copied it to
https://svn.apache.org/repos/asf/tuscany/tags/java/maven-eclipse-compiler-1.0/

   ...ant



Just ran a build from the staging repo. Didn't get a clean build but I
don't think that's this plugin's fault.

B.t.w. For anyone wishing to actually test this you'll need to change the
dependency in sca/pom.xml around line 461...

dependencies
dependency

groupIdorg.apache.tuscany.maven.plugins/groupId

artifactIdmaven-eclipse-compiler/artifactId
version1.0/version
scopeprovided/scope
/dependency
/dependencies

The LICENSE/NOTICES are at the top level and signatures verify.

I do notice that  the artifact name is a little inconsistent re. how these
things usually appear, e.g. it should really be
artifactIdmaven-eclipse-compiler-plugin/artifactId? However it's not
bothered me before otherwise I would have raised if on the original thread.
Not bothering me enought to -1 this vote unless someone finds another reason
to respin.

+1

Simon


Thanks for voting!  Re the artifactid, i think thats as this isn't actually
a maven plugin module its a compiler. Our other modules that are proper
maven plugins do end in plugin, eg tools\maven\maven-bundle-plugin.

   ...ant








--
Thanks, Dan Becker

[jira] Resolved: (TUSCANY-2825) JMSBindingProcessor missing 'write' method implementation

2009-02-12 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2825.
-

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

Fixed in branch 1.x at revision: 743796  


 JMSBindingProcessor missing 'write' method implementation
 -

 Key: TUSCANY-2825
 URL: https://issues.apache.org/jira/browse/TUSCANY-2825
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: JAva SCA JMS extension
Reporter: Christopher N. Ortiz
Assignee: Dan Becker
 Fix For: Java-SCA-Next


 The 'write' method in JMSBindingProcessor is just a stub and needs to be 
 implemented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release Tuscany Java SCA 2.0-M1 (RC3)

2009-02-12 Thread Dan Becker


Luciano Resende wrote:

Please review and vote on the 2.0-M1 release artifacts of Tuscany SCA for Java.

The artifacts are available for review at:
http://people.apache.org/~lresende/tuscany/2.0-M1-RC3/


+1 from me. All samples seem to be working.

--
Thanks, Dan Becker

[jira] Updated: (TUSCANY-2825) JMSBindingProcessor missing 'write' method implementation

2009-02-11 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker updated TUSCANY-2825:


Due Date: 12/Feb/09

 JMSBindingProcessor missing 'write' method implementation
 -

 Key: TUSCANY-2825
 URL: https://issues.apache.org/jira/browse/TUSCANY-2825
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: JAva SCA JMS extension
Reporter: Christopher N. Ortiz
Assignee: Dan Becker

 The 'write' method in JMSBindingProcessor is just a stub and needs to be 
 implemented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2825) JMSBindingProcessor missing 'write' method implementation


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2825:
---

Assignee: Dan Becker

 JMSBindingProcessor missing 'write' method implementation
 -

 Key: TUSCANY-2825
 URL: https://issues.apache.org/jira/browse/TUSCANY-2825
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: JAva SCA JMS extension
Reporter: Christopher N. Ortiz
Assignee: Dan Becker

 The 'write' method in JMSBindingProcessor is just a stub and needs to be 
 implemented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2835) JMS Binding does not save operation names unless there are properties.

[
https://issues.apache.org/jira/browse/TUSCANY-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dan Becker reassigned TUSCANY-2835:
---

Assignee: Dan Becker

JMS Binding does not save operation names unless there are properties.
--

Key: TUSCANY-2835
URL: https://issues.apache.org/jira/browse/TUSCANY-2835
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
Environment: All
Reporter: Dan Becker
Assignee: Dan Becker
Priority: Minor
Fix For: Java-SCA-Next

Christopher Ortiz: I believe there is still a problem with the way the
OperationProperties element is being processed in the JMSBinding. The new
method getOperationNames() will return the keySet from the
operationProperties map. However, operationProperties is the map of
'property' found in the 'header' subelement of OperationProperties. If no
header element with a property is present in OperationProperties, the
operationProperties name (opName) is never set in this map.
When the 'operations properties' element is parsed in JMSBindingProcessor in
parseOperationProperties, the operation Name attribute (opName) is retrieved
from the reader. But it is not saved anywhere. The nativeOperation
attribute is read next. If it is present, it is set to a map with the opName
as a key. But since the NativeOperation attribute is optional, it may not be
present, and the opName is not preserved.
Dan Becker: I see what you're saying. It sounds like we need to add
operation names, even if there are no properties for the operation name.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TUSCANY-2835) JMS Binding does not save operation names unless there are properties.

JMS Binding does not save operation names unless there are properties.
--

 Key: TUSCANY-2835
 URL: https://issues.apache.org/jira/browse/TUSCANY-2835
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: All
Reporter: Dan Becker
Priority: Minor
 Fix For: Java-SCA-Next


Christopher Ortiz: I believe there is still a problem with the way the 
OperationProperties element is being processed in the JMSBinding.  The new 
method getOperationNames()  will return the keySet from the operationProperties 
map.  However, operationProperties is the map of 'property' found in the 
'header' subelement of OperationProperties. If no header element with a 
property is present in OperationProperties, the operationProperties name 
(opName) is never set in this map.

When the 'operations properties' element is parsed in JMSBindingProcessor in 
parseOperationProperties, the operation Name attribute (opName) is retrieved 
from the reader.  But it is not saved anywhere.  The nativeOperation attribute 
is read next.  If it is present, it is set to a map with the opName as a key.  
But since the NativeOperation attribute is optional, it may not be present, and 
the opName is not preserved.

Dan Becker: I see what you're saying. It sounds like we need to add operation 
names, even if there are no properties for the operation name.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2835) JMS Binding does not save operation names unless there are properties.

[
https://issues.apache.org/jira/browse/TUSCANY-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dan Becker resolved TUSCANY-2835.
-

Resolution: Fixed

Fixed in branch 1.x at revision: 743094

JMS Binding does not save operation names unless there are properties.
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2825) JMSBindingProcessor missing 'write' method implementation


[ 
https://issues.apache.org/jira/browse/TUSCANY-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672416#action_12672416
 ] 

Dan Becker commented on TUSCANY-2825:
-

In progress.

I'm using the following process to test the JMSBinding write method:
1. Create a new JMSBindingProcessorWriteTestCase
2. For each composite in JMSBindingProcessorTestCase (about 16 examples).
   2a. Read the composite from XML String to a JMSBinding model.
   2b. Write the JMSBinding model to a XML String.
   2c. Read the XML String of 2b to a second JMSBinding model.
   2d. Compare the JMSBinding  model of 2a to 2c. They should be equal.

 JMSBindingProcessor missing 'write' method implementation
 -

 Key: TUSCANY-2825
 URL: https://issues.apache.org/jira/browse/TUSCANY-2825
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: JAva SCA JMS extension
Reporter: Christopher N. Ortiz
Assignee: Dan Becker

 The 'write' method in JMSBindingProcessor is just a stub and needs to be 
 implemented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release Tuscany Java SCA 2.0-M1 (RC1)

2009-02-09 Thread Dan Becker


I'm still testing the M1 RC1, but I notice a few issues:

1) README in samples directory mentions lib directory rather than 
modules directory, and it does not match the README info in lower sample 
subdirs. I will open a Jira and take care of this one.


2) implementation-java-calculator does not run with instructions given 
in its README (on Windows XP, IBM JDK 1.6.0) From this launch:
java -jar ..\..\features\tuscany-sca-equinox-manifest.jar -composite 
Calculator.composite -config ..\..\features\configuration\ -ttl 0 
target\implementation-java-calculator.jar


I get:
SEVERE: SCA Node could not be created
Throwable occurred: java.lang.reflect.InvocationTargetException
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

 ...
org.apache.tuscany.sca.node.equinox.launcher.NodeMain.main(NodeMain.java:59)
Caused by: org.oasisopen.sca.ServiceRuntimeException: 
org.apache.tuscany.sca.contribution.processor.ContributionReadException: 
java.io.FileNotFoundException: 
E:\t\tuscany-sca-2.0-M1\samples\implementation-java-calculator\target\implementati

on-java-calculator.jar (The system cannot find the file specified.)
  ...

The file is named sample-implementation-java-calculator.jar and not 
implementation-java-calculator.jar


ant elder wrote:

On Mon, Feb 9, 2009 at 7:44 AM, Ramkumar R ramkumar...@gmail.com wrote:


I was able to download the artifacts and run the samples in the binary
distribution successfully.

Few things that I would like to see:

1. RELEASE_NOTES and CHANGES file in the RC1 folder.
2. The modules folder seems to little confusing, contains both libraries
and the tuscany modules?



I agree with that, its common practice in multi module maven projects to use
a folder named modules for the individual module jars but using that
folder for the jars used by the actual runtime is at best unusual. I don't
think this is a blocker for M1 though.



3. A README file in the bin folder to explain the purpose of this folder
and how to use it?



I've added a README to the bin folder in r742337

The license header added to the tuscany.bat script was gets printed out when
running the script, i fixed that in r742405

   ...ant




--
Thanks, Dan Becker

[jira] Created: (TUSCANY-2826) Sample READMEs have mistakes

2009-02-09 Thread Dan Becker (JIRA)

Sample READMEs have mistakes


 Key: TUSCANY-2826
 URL: https://issues.apache.org/jira/browse/TUSCANY-2826
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-2.0
 Environment: All 
Reporter: Dan Becker
Priority: Minor


1) README in samples directory mentions lib directory rather than modules 
directory, and it does not match the README info in lower sample subdirs.

2) implementation-java-calculator does not run with instructions given in its 
README (on Windows XP, IBM JDK 1.6.0) From this launch:
java -jar ..\..\features\tuscany-sca-equinox-manifest.jar -composite 
Calculator.composite -config ..\..\features\configuration\ -ttl 0 
target\implementation-java-calculator.jar

I get:
SEVERE: SCA Node could not be created
Throwable occurred: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 ...
org.apache.tuscany.sca.node.equinox.launcher.NodeMain.main(NodeMain.java:59)
Caused by: org.oasisopen.sca.ServiceRuntimeException: 
org.apache.tuscany.sca.contribution.processor.ContributionReadException: 
java.io.FileNotFoundException: 
E:\t\tuscany-sca-2.0-M1\samples\implementation-java-calculator\target\implementati
on-java-calculator.jar (The system cannot find the file specified.)
  ...

The file is named sample-implementation-java-calculator.jar and not 
implementation-java-calculator.jar


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2826) Sample READMEs have mistakes

2009-02-09 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2826.
-

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

Resolved in trunk at revision: 742589  


 Sample READMEs have mistakes
 

 Key: TUSCANY-2826
 URL: https://issues.apache.org/jira/browse/TUSCANY-2826
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-2.0
 Environment: All 
Reporter: Dan Becker
Assignee: Dan Becker
Priority: Minor
 Fix For: Java-SCA-Next


 1) README in samples directory mentions lib directory rather than modules 
 directory, and it does not match the README info in lower sample subdirs.
 2) implementation-java-calculator does not run with instructions given in its 
 README (on Windows XP, IBM JDK 1.6.0) From this launch:
 java -jar ..\..\features\tuscany-sca-equinox-manifest.jar -composite 
 Calculator.composite -config ..\..\features\configuration\ -ttl 0 
 target\implementation-java-calculator.jar
 I get:
 SEVERE: SCA Node could not be created
 Throwable occurred: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
  ...
 org.apache.tuscany.sca.node.equinox.launcher.NodeMain.main(NodeMain.java:59)
 Caused by: org.oasisopen.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.contribution.processor.ContributionReadException: 
 java.io.FileNotFoundException: 
 E:\t\tuscany-sca-2.0-M1\samples\implementation-java-calculator\target\implementati
 on-java-calculator.jar (The system cannot find the file specified.)
   ...
 The file is named sample-implementation-java-calculator.jar and not 
 implementation-java-calculator.jar

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (TUSCANY-2806) Modules in the build depend on modules later on in the build


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reopened TUSCANY-2806:
-


Raymond, your fix helped and got me further on into a clean build, but I see 
the following clean repos build error

  [jar] Building jar: E:\t\java\sca\distribution\all\target\apache-tuscany-s
ca-all-2.0-SNAPSHOT-dir\tuscany-sca-2.0-SNAPSHOT\samples\calculator-rmi-referenc
e\target\sample-calculator-rmi-reference.jar

run:
 [java] Feb 6, 2009 9:28:05 AM org.apache.tuscany.sca.node.impl.NodeImpl in
it
 [java] INFO: Creating node: CalculatorRMIReference.composite
 [java] Feb 6, 2009 9:28:05 AM org.apache.tuscany.sca.node.impl.NodeImpl con
figureNode
 [java] INFO: Loading contribution: file:/E:/t/java/sca/distribution/all/tar
get/apache-tuscany-sca-all-2.0-SNAPSHOT-dir/tuscany-sca-2.0-SNAPSHOT/samples/cal
culator-rmi-reference/target/sample-calculator-rmi-reference.jar
 [java] Feb 6, 2009 9:28:06 AM org.apache.tuscany.sca.node.impl.NodeImpl sta
rt
 [java] INFO: Starting node: CalculatorRMIReference.composite
 [java] Exception in thread main java.lang.reflect.InvocationTargetExcepti
on
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:39)
 [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
 [java] at java.lang.reflect.Method.invoke(Method.java:597)
 [java] at org.apache.tuscany.sca.launcher.LauncherMain.invokeMainMethod
(LauncherMain.java:110)
 [java] at org.apache.tuscany.sca.launcher.LauncherMain.main(LauncherMai
n.java:55)
 [java] Caused by: org.apache.tuscany.sca.host.rmi.RMIHostRuntimeException:
Connection refused to host: localhost; nested exception is:
 [java] java.net.ConnectException: Connection refused: connect
 [java] at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:
601)
 [java] at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.
java:198)
 [java] at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.jav
a:184)
 [java] at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
 [java] at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
 [java] at org.apache.tuscany.sca.host.rmi.DefaultRMIHost.findService(De
faultRMIHost.java:106)
 [java] at org.apache.tuscany.sca.host.rmi.ExtensibleRMIHost.findService
(ExtensibleRMIHost.java:56)
 [java] at org.apache.tuscany.sca.binding.rmi.provider.RMIBindingInvoker
.invokeTarget(RMIBindingInvoker.java:80)
 [java] at org.apache.tuscany.sca.binding.rmi.provider.RMIBindingInvoker
.invoke(RMIBindingInvoker.java:54)
 [java] at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHand
ler.invoke(JDKInvocationHandler.java:289)
 [java] at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHand
ler.invoke(JDKInvocationHandler.java:156)
 [java] at $Proxy6.add(Unknown Source)
 [java] at calculator.CalculatorServiceImpl.add(CalculatorServiceImpl.ja
va:54)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:39)
 [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:25)
 [java] at java.lang.reflect.Method.invoke(Method.java:597)
 [java] at org.apache.tuscany.sca.implementation.java.invocation.JavaImp
lementationInvoker.invoke(JavaImplementationInvoker.java:132)
 [java] at org.apache.tuscany.sca.core.databinding.wire.PassByValueInter
ceptor.invoke(PassByValueInterceptor.java:112)
 [java] at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker
.invoke(SCABindingInvoker.java:61)
 [java] at org.apache.tuscany.sca.core.databinding.wire.PassByValueInter
ceptor.invoke(PassByValueInterceptor.java:112)
 [java] at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHand
ler.invoke(JDKInvocationHandler.java:289)
 [java] at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHand
ler.invoke(JDKInvocationHandler.java:156)
 [java] at $Proxy5.add(Unknown Source)
 [java] at calculator.CalculatorClient.main(CalculatorClient.java:40)
 [java] ... 6 more
 [java] Feb 6, 2009 9:28:26 AM org.apache.tuscany.sca.node.launcher.NodeLaun
cher main
 [java] INFO: SCA Node is now started.
 [java] Feb 6, 2009 9:28:26 AM org.apache.tuscany.sca.node.launcher.NodeLaun
cher main
 [java] INFO: Waiting for 4000 milliseconds ...
 [java] Feb 6, 2009 9:28:30 AM org.apache.tuscany.sca.node.impl.NodeImpl sto
p
 [java] INFO: Stopping node: null
 [java] Feb 6, 2009 9:28:30 AM org.apache.tuscany.sca.node.launcher.NodeLaun
cher stopNode

[jira] Assigned: (TUSCANY-2804) Component-Type Calculator iTest fails with NPE


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2804:
---

Assignee: (was: Dan Becker)

Unassigning as I do not have a machine to reproduce the problem on Red Hat.

 Component-Type Calculator iTest fails with NPE
 --

 Key: TUSCANY-2804
 URL: https://issues.apache.org/jira/browse/TUSCANY-2804
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.0-M1
Reporter: Luciano Resende
 Fix For: Java-SCA-2.0-M1


 java.lang.NullPointerException
   at calculator.CalculatorServiceImpl.add(CalculatorServiceImpl.java:48)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:132)
   at 
 org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
   at 
 org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:156)
   at $Proxy6.add(Unknown Source)
   at 
 calculator.CalculatorTestCase.testCalculator(CalculatorTestCase.java:55)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
   at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
   at 
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
   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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2821) No method available on JMSBinding to retreive set of operationPropertiesNames


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2821.
-

Resolution: Fixed

Fixed in 1.x branch at revision: 741694 .

Added JMS binding APIs:
 public SetString getOperationNames();
 public Object getOperationProperty(String opName, String propName );
and appropriate test cases.



 No method available on JMSBinding to retreive set of operationPropertiesNames
 -

 Key: TUSCANY-2821
 URL: https://issues.apache.org/jira/browse/TUSCANY-2821
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: Java SCA JMSBinding
Reporter: Christopher N. Ortiz
Assignee: Dan Becker
Priority: Critical

 The operationProperties element can appear multiple times in a JMS Binding.  
 All of the get methods for sub elements of the operationProperties require 
 the opName as an argument to determine which operationProperties element to 
 access.  But there is no method available to get the key set of 
 operationProperties Names.  Without the name set to key off of, it is 
 impossible to determine which operationProperties element to reference.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2806) Modules in the build depend on modules later on in the build


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2806.
-

Resolution: Fixed

Like ointment on the infected area, revisions 741409 and 741626 cleared up my 
build problems. Thanks Raymond and Ant.

 Modules in the build depend on modules later on in the build 
 -

 Key: TUSCANY-2806
 URL: https://issues.apache.org/jira/browse/TUSCANY-2806
 Project: Tuscany
  Issue Type: Bug
Reporter: ant elder
Priority: Blocker
 Fix For: Java-SCA-2.0-M1


 Modules in the build depend on modules later on in the build which means when 
 building them they either fail if its the first time you are building or if 
 the later on module has been changed then the change isn't used until a 
 subsequent build. I think this is one of the reasons we're having so many 
 build problems - you make a change run a build and its fine so check it in, 
 but the changed wasn't used and its not till the next build it gets picked up 
 and you can see if the change was ok or not.
 I think we need to move some thing out of the sca build into separate build 
 and releasable artifacts and other things restructure the build so it runs in 
 a better order.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2766) Warning message conflicts with conformance item ASM60008


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2766:
---

Assignee: Dan Becker

 Warning message conflicts with conformance item ASM60008 
 -

 Key: TUSCANY-2766
 URL: https://issues.apache.org/jira/browse/TUSCANY-2766
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.3
Reporter: Shu Chao Wan
Assignee: Dan Becker
 Attachments: ASM60008.patch


 I'm testing conformance item ASM60008, and found something strange. 
 In ASM60008, it says that The interfaces of the component references 
 promoted by a composite reference MUST be the same, or if the composite 
 reference itself declares an interface then all the component reference 
 interfaces must be compatible with the composite reference interface. 
 Compatible means that the component reference interface is the same or is a 
 strict subset of the composite reference interface. 
 In order to verify this statement, I wrote a composite file like that 
 composite... 
  service name=AService promote=AComponent/ 
 component name=AComponent 
 implementation.java 
 
 class=org.apache.tuscany.sca.vtest.assembly.composite.impl.AServiceImpl / 
 reference name=b/ 
 reference name=c 
 interface.java 
 interface=org.apache.tuscany.sca.vtest.assembly.composite.CService / 
 /reference 
 /component 
 reference name=c promote=AComponent/c 
 interface.java 
 interface=org.apache.tuscany.sca.vtest.assembly.composite.CSuperService / 
 /reference 
 reference name=b promote=AComponent/b/ 
  service 
 /composite 
 Here, the interface CSuperService is super set of interface CService, that is 
 to say, interface CSuperServicecontains more methods than interface CService 
 does. 
 But when I load this composite file, I got warning message: 
 Jan 12, 2009 11:27:27 AM 
 org.apache.tuscany.sca.assembly.builder.impl.CompositePromotionBuilderImpl
 WARNING: Interface of composite reference AComponent/c must be compatible 
 with the interface declared by promoted component reference.
 Jan 12, 2009 11:27:27 AM 
 org.apache.tuscany.sca.assembly.builder.impl.ComponentReferenceWireBuilderImpl
 WARNING: Incompatible interfaces on component reference and target: Composite 
 = {http://assembly-tests}Assembly-sub-reference-interface-outer-Composite 
 Reference = c Service = CComponent
 It seems that this warning message conflicts with this conformance item, 
 which causes that service can not be invoked correctly in the following test. 
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2755) Tuscany 1.3.2 and STP-SCA tooling Integration


[ 
https://issues.apache.org/jira/browse/TUSCANY-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670827#action_12670827
 ] 

Dan Becker commented on TUSCANY-2755:
-

https://bugs.eclipse.org/bugs/show_bug.cgi?id=261222  
   Status|RESOLVED
Resolution|FIXED

--- Comment #10 from Stéphane Drapeau stephane.drap...@obeo.fr  2009-02-05 
11:48:24 -0400 ---
Fixed. Commit #2883.
Tuscany 1.4 is now supported.

Dan, if you have an opportunity to test the tools, I'm interested in your
feedback. Thanks for your contribution.

I will give this one a test in the near future. If anyone else wants to test 
the Eclipse STP tools, feel free to do a 1.4 composite, and report back here or 
on the dev list.





 Tuscany 1.3.2 and STP-SCA tooling Integration
 -

 Key: TUSCANY-2755
 URL: https://issues.apache.org/jira/browse/TUSCANY-2755
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Tools
Reporter: Dhaval Chauhan
Assignee: Dan Becker
 Attachments: Tuscany-Eclipse_STP_SCA integration.doc


 Attached word document explains the current status of integration of eclipse 
 STP-SCA tool with Tuscany's latest release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2701) NPE when verifying conformance item ASM60006 in OASIS sepc


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2701:
---

Assignee: Dan Becker

 NPE when verifying conformance item ASM60006 in OASIS sepc
 --

 Key: TUSCANY-2701
 URL: https://issues.apache.org/jira/browse/TUSCANY-2701
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.3
Reporter: Shu Chao Wan
Assignee: Dan Becker
Priority: Minor

 Conformance item 60006 says that, The name of a composite reference/ 
 element MUST be unique across all the composite references in the composite.
 According to the above description, I wrote a composite file inner.composite 
 with two same composite  reference/ element  NonUniqueReference within 
 the composite. 
 ---
 inner.composite
 ---
 composite ...
  service name=AService promote=AComponent/
  component name=AComponent
  reference name=b /
  reference name=c /
  /component
  reference name=NonUniqueReference promote=AComponent/b /
  reference name=NonUniqueReference promote=AComponent/c / 
 /composite
 And a outer composite file to use inner composite as the implementation of 
 component.
 ---
 outer.composite
 ---
 composite
   component name=TestNonUniqueReferenceComponent
  implementation.composite 
 name=assembly-tests:Assembly-non-unique-reference-inner--Composite/
  reference name=NonUniqueReference target=BComponent/
  reference name=NonUniqueReference target=CComponent/   
  /component
 component name=BComponent
 implementation.java 
 class=org.apache.tuscany.sca.vtest.assembly.composite.impl.BServiceImpl/
 property name=somePropertysome b component value/property
 /component
 
 component name=CComponent
 implementation.java 
 class=org.apache.tuscany.sca.vtest.assembly.composite.impl.CServiceImpl/   
  
 /component
 /composite
 When I invoke two different methods from the component service AService, I 
 got NullPointerException from one method invocation.
 --
 TestCase
 --
 initDomain(nonuniquereference_outer.composite);
 AService service = ServiceFinder.getService(AService.class, 
 TestNonUniqueReferenceComponent/AService);
 service.getBProperty();
 service.getState();
 cleanupDomain();
 Here is the detailed info about exception
 ---
 Exception Trace
 ---
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sca.vtest.assembly.composite.impl.AServiceImpl.getBProperty(AServiceImpl.java:43)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:132)
   at 
 org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:287)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
   at $Proxy9.getBProperty(Unknown Source)
   at 
 org.apache.tuscany.sca.vtest.assembly.composite.CompositeTestCase.ASM60006(CompositeTestCase.java:209)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46

[jira] Assigned: (TUSCANY-2821) No method available on JMSBinding to retreive set of operationPropertiesNames


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2821:
---

Assignee: Dan Becker

 No method available on JMSBinding to retreive set of operationPropertiesNames
 -

 Key: TUSCANY-2821
 URL: https://issues.apache.org/jira/browse/TUSCANY-2821
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: Java SCA JMSBinding
Reporter: Christopher N. Ortiz
Assignee: Dan Becker
Priority: Critical

 The operationProperties element can appear multiple times in a JMS Binding.  
 All of the get methods for sub elements of the operationProperties require 
 the opName as an argument to determine which operationProperties element to 
 access.  But there is no method available to get the key set of 
 operationProperties Names.  Without the name set to key off of, it is 
 impossible to determine which operationProperties element to reference.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2806) Modules in the build depend on modules later on in the build


[ 
https://issues.apache.org/jira/browse/TUSCANY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670907#action_12670907
 ] 

Dan Becker commented on TUSCANY-2806:
-

I see this issue as well. I updated to trunk revision 741267 and I see
---
 T E S T S
---
Running calculator.CalculatorTestCase
Feb 5, 2009 2:49:59 PM org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher
Util collectClasspathEntries
INFO: Runtime classpath: 1 JAR from E:\t\java\sca\modules\node-launcher-equinox\
target
Feb 5, 2009 2:49:59 PM org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher
Util collectClasspathEntries
INFO: Runtime classpath: 6 JARs from E:\t\java\sca\modules\node-launcher-equinox

Feb 5, 2009 2:49:59 PM org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher
Util collectClassLoaderClasspathEntries
INFO: Runtime classpath: 1 JAR from application classpath.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.813 sec  FA
ILURE!
calculator.CalculatorTestCase  Time elapsed: 0 sec   ERROR!
java.lang.IllegalStateException: java.lang.NullPointerException
at org.apache.tuscany.sca.node.equinox.launcher.EquinoxHost.start(Equino
xHost.java:329)
at org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.init(Node
Launcher.java:62)
at org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.newInstance
(NodeLauncher.java:71)
at calculator.CalculatorTestCase.setUpBeforeClass(CalculatorTestCase.jav
a:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
Method.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal
lable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe
thod.java:41)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.
java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.ja
va:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
tSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:338)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:997)
Caused by: java.lang.NullPointerException
at org.apache.tuscany.sca.node.equinox.launcher.EquinoxHost.start(Equino
xHost.java:289)
... 23 more


This is on Windows with Sun JDK 1.6.0_11. I'll report in a moment how the 
subsequent build runs.

 Modules in the build depend on modules later on in the build 
 -

 Key: TUSCANY-2806
 URL: https://issues.apache.org/jira/browse/TUSCANY-2806
 Project: Tuscany
  Issue Type: Bug
Reporter: ant elder
Priority: Blocker
 Fix For: Java-SCA-2.0-M1


 Modules in the build depend on modules later on in the build which means when 
 building them they either fail if its the first time you are building or if 
 the later on module has been changed then the change isn't used until a 
 subsequent build. I think this is one of the reasons we're having so many 
 build problems - you make a change run a build and its fine so check it in, 
 but the changed wasn't used and its not till the next build it gets picked up 
 and you can see if the change was ok or not.
 I think we need to move some thing out of the sca build into separate build 
 and releasable artifacts and other things restructure the build so it runs in 
 a better order.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [2.0-M1] Building the source distribution with a clean maven repo

2009-02-05 Thread Dan Becker

I see this issue as well when I build (Windows, Sun 1.6.0_11) with a 
clean repos. I've added a comment to the defect. Let me try with the 
mvn-Psetup and report on whether it works or not.


ant elder wrote:

On Thu, Feb 5, 2009 at 6:55 PM, Luciano Resende luckbr1...@gmail.comwrote:


Is anyone seeing issues when trying to build the source distribution
with a clean maven repo. It looks like it fails for the first time
(totally clean maven repo), but if you retry it works (probably
because the repo has some stuff already)  ?  I'm guessing this might
be related or same issue as TUSCANY-2806 ?


[1] http://issues.apache.org/jira/browse/TUSCANY-2806

--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende http://people.apache.org/%7Elresende
http://lresende.blogspot.com/



I was hoping i'd fixed all of that except for
TUSCANY-2818http://issues.apache.org/jira/browse/TUSCANY-2818so it
would be going if you first do mvn -Psetup to build the eclipse
compiler and then the rest of the build would be working. I have seen some
intermittent problems with it not working like you describe but not for a
day or so so i was hoping they were done now.

   ...ant




--
Thanks, Dan Becker

Re: Moving the contrib folder out of tuscany/java/sca?

2009-02-04 Thread Dan Becker


Mike Edwards wrote:

ant elder wrote:
What do people think about moving the contrib folder out of the 
tuscany/java/sca tree? The reason being so that when you check out the 
trunk code you don't have to also get all the contrib folder which is 
quite big now so takes a long time and is full of code that doesn't work.


If no one objects i will move tuscany/java/sca/contrib to 
tuscany/java/sca-contrib


   ...ant

+1 from me




+1. That will save some bandwidth.

--
Thanks, Dan Becker

Re: [PROPOSAL] Tuscany Documentation

2009-02-04 Thread Dan Becker

This is a good proposal Luciano. I like the idea of branching the 
docs. Just as the Sun JDKs provide versioned docs from the 1.0 days to 
the current 1.6 days, I too would like to see versioned Tuscany docs.


In addition to versioned wiki spaces, we might want to think about 
versioned public pages. Right now there is an export plugin that moves 
the wiki pages to the external site html pages. Perhaps we need to 
branch the tuscany web site so there would be a latest html snap shot 
at http://tuscany.apache.org and earlier versioned html snap shots, 
perhaps at http://tuscany.apache.org/1.4, etc.


Much of our site shows up here [1] in the svn repos, perhaps we need to 
add versions under this point in the repos.


[1] http://svn.apache.org/repos/asf/tuscany/site/

Luciano Resende wrote:

As we discussed in [1], please take a look at a proposed structure to
use as our Java SCA Documentation for both 1.x and 2.x development
streams.

The idea is to have two separate wikis, where we would have the latest
documentation for each of the development streams, and during the
releases we would export a snapshot of the wiki space and make it
available either online in our website, or as a doc distribution. The
concept of guide books would allow us to group related contents, and
the new navigation outline in the left gives the user a better user
experience, and is built automatically by Confluence based on the page
name and hierarchy. Please take a look at the initial contents in the
2.x Documentation space [3] and it's PDF version that we could use in
a release [4] and provide feedback.

If people are OK, I can spend some time documenting some usage
guidelines to make sure the generated outline give us the right
navigation benefits and exporting does not contain unwanted navigation
markup; and then we could start migrating more of the contents from
our website to the new wikis.

Thoughts ?


[1] http://www.mail-archive.com/dev@tuscany.apache.org/msg04344.html
[2] http://cwiki.apache.org/confluence/display/TUSCANYxDOCx1x/Index
[3] http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/Index
[4] 
http://people.apache.org/~lresende/tuscany/doc/TUSCANYxDOCx2x-20090203-16_21_57.pdf




--
Thanks, Dan Becker

Re: [PROPOSAL] Tuscany Documentation

2009-02-04 Thread Dan Becker


Luciano Resende wrote:

On Wed, Feb 4, 2009 at 7:32 AM, Dan Becker dan.o.bec...@gmail.com wrote:

This is a good proposal Luciano. I like the idea of branching the docs.
Just as the Sun JDKs provide versioned docs from the 1.0 days to the current
1.6 days, I too would like to see versioned Tuscany docs.

In addition to versioned wiki spaces, we might want to think about versioned
public pages. Right now there is an export plugin that moves the wiki pages
to the external site html pages. Perhaps we need to branch the tuscany web
site so there would be a latest html snap shot at
http://tuscany.apache.org and earlier versioned html snap shots, perhaps
at http://tuscany.apache.org/1.4, etc.



What problem are you trying to solve here ? Confluence is much like
SVN and provides a change history for each page. Would that be ok for
website ?


I am thinking more along the line of what the user sees for the Tuscany 
website after the wikis are exported to the world. Is the user going to 
see several site versions, e.g:

http://tuscany.apache.org  (latest)
http://tuscany.apache.org/1.5 (previous release)
http://tuscany.apache.org/1.4 (previous release)

Or is the user going to see several article versions on one site?, e.g.:
http://tuscany.apache.org/sca-java-user-guide.html (latest)
http://tuscany.apache.org/sca-java-user-guide-1.5.html (previous version)
http://tuscany.apache.org/sca-java-user-guide-1.4.html (previous version)

Or maybe we have other version publishing ideas in mind. Of the two I 
mention here, I prefer the first one.

--
Thanks, Dan Becker

A Tour of Tuscany Information Resources (video)

2009-02-04 Thread Dan Becker

I've created a video overview of many of the Tuscany information 
resources. From the Tuscany web site, to the mailing lists, to the 
blogs, there certainly are many avenues to learning Tuscany. New users 
especially will benefit from seeing the many resources. Experienced 
users may enjoy my guitar solo in the first 5 seconds of the video.


Vcasmo version (password tuscany): http://vcasmo.com/video/beckerdo/4177
You Tube version: http://youtube.com/watch?v=jgC_597HrC0

--
Thanks, Dan Becker

Re: [PROPOSAL] Tuscany Documentation

2009-02-04 Thread Dan Becker


Luciano Resende wrote:

On Wed, Feb 4, 2009 at 8:49 AM, Dan Becker dan.o.bec...@gmail.com wrote:

Luciano Resende wrote:

On Wed, Feb 4, 2009 at 8:08 AM, Dan Becker dan.o.bec...@gmail.com wrote:

Luciano Resende wrote:

On Wed, Feb 4, 2009 at 7:32 AM, Dan Becker dan.o.bec...@gmail.com
wrote:

This is a good proposal Luciano. I like the idea of branching the
docs.
Just as the Sun JDKs provide versioned docs from the 1.0 days to the
current
1.6 days, I too would like to see versioned Tuscany docs.

In addition to versioned wiki spaces, we might want to think about
versioned
public pages. Right now there is an export plugin that moves the wiki
pages
to the external site html pages. Perhaps we need to branch the tuscany
web
site so there would be a latest html snap shot at
http://tuscany.apache.org and earlier versioned html snap shots,
perhaps
at http://tuscany.apache.org/1.4, etc.


What problem are you trying to solve here ? Confluence is much like
SVN and provides a change history for each page. Would that be ok for
website ?

I am thinking more along the line of what the user sees for the Tuscany
website after the wikis are exported to the world. Is the user going to
see
several site versions, e.g:
http://tuscany.apache.org  (latest)
http://tuscany.apache.org/1.5 (previous release)
http://tuscany.apache.org/1.4 (previous release)

Or is the user going to see several article versions on one site?, e.g.:
http://tuscany.apache.org/sca-java-user-guide.html (latest)
http://tuscany.apache.org/sca-java-user-guide-1.5.html (previous version)
http://tuscany.apache.org/sca-java-user-guide-1.4.html (previous version)


What kind of release specific information do you think we are going to
have in the website, if we remove the documentation out to the wikis ?


I don't propose removing documentation from the wikis or changing any part
of your proposal for the wikis on the thread.

I am just wondering what the version scheme will look like when the various
files reach the web site. What will customers see? Where will a customer
look for articles of the 1.x flavor versus the articles of the 2.x flavor?



Haaa, I think I got your question now, we would have something (but
probably not exactly) like this :

http://db.apache.org/derby/manuals/index.html

Or just a link on our website pointing to the wiki documentation




Excellent example! I like their organization. Notice for example that 
the developers guide follows this kind of structure for the HTML pages:

http://db.apache.org/derby/docs/10.3/devguide/
http://db.apache.org/derby/docs/10.2/devguide/
http://db.apache.org/derby/docs/10.1/devguide/

This is similar to the idea I prefered above:
 http://tuscany.apache.org  (latest)
 http://tuscany.apache.org/1.5 (previous release)
 http://tuscany.apache.org/1.4 (previous release

--
Thanks, Dan Becker

Re: A Tour of Tuscany Information Resources (video)

2009-02-04 Thread Dan Becker


Luciano Resende wrote:

BTW, there was a typo on the user list information... it should be
user-subscr...@tuscany.apache.org instead of usr-


Thanks, will update it shortly.



On Wed, Feb 4, 2009 at 6:25 AM, Simon Laws simonsl...@googlemail.com wrote:


On Wed, Feb 4, 2009 at 2:22 PM, ant elder ant.el...@gmail.com wrote:

Wonderful, i did enjoy the guitar intro :)

   ...ant

On Wed, Feb 4, 2009 at 2:00 PM, Dan Becker dan.o.bec...@gmail.com wrote:

I've created a video overview of many of the Tuscany information
resources. From the Tuscany web site, to the mailing lists, to the blogs,
there certainly are many avenues to learning Tuscany. New users especially
will benefit from seeing the many resources. Experienced users may enjoy my
guitar solo in the first 5 seconds of the video.

Vcasmo version (password tuscany): http://vcasmo.com/video/beckerdo/4177
You Tube version: http://youtube.com/watch?v=jgC_597HrC0

--
Thanks, Dan Becker

Yes Dan, just watched this also. Nice one.  I didn't realize Eric Clapton
was moonlighting as a Tuscany developer;-)


--
Thanks, Dan Becker

Re: [2.x] Trouble finding manifest resources in Eclips

2009-02-04 Thread Dan Becker



That one is missing. Even a mvn -U did not pull it in.

I added it manually (with an manually updated MANIFEST.MF), but got the 
same errors. Here is what I put in the geronimo-jsp_2.1_spec-1.0 
MANIFEST.MF:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.apache.geronimo.specs.geronimo-jsp_2.1_spec-1.0
Bundle-Name: org.apache.geronimo.specs.geronimo-jsp_2.1_spec-1.0
Bundle-Version: 1.1.0
DynamicImport-Package: *
Bundle-ClassPath: geronimo-jsp_2.1_spec-1.0-1.1.jar
Export-Package: javax.servlet;version=2.1.0


Raymond Feng wrote:

Do you have the following bundle?

C:\Tuscany\java\sca\distribution\all\target\modules\geronimo-jsp_2.1_spec-1.0\geronimo-jsp_2.1_spec-1.0.jar 



Thanks,
Raymond
--
From: Dan Becker dan.o.bec...@gmail.com
Sent: Wednesday, February 04, 2009 11:55 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] Trouble finding manifest resources in Eclips

Hmm, I am still getting 738 errors in Eclipse. These two errors seem 
to be the main problem:

Description Resource Path Location Type
No available bundle exports package 'javax.servlet.jsp.tagext' 
MANIFEST.MF tuscany-host-webapp/META-INF line 30 Plug-in Problem
No available bundle exports package 'javax.servlet.jsp' MANIFEST.MF 
tuscany-host-webapp/META-INF line 29 Plug-in Problem


The mvn -Peclipse and distribution/all builds both run successfully 
for me.


Any other steps? I've pointed the JRE to default and to the Sun and 
IBM 1.6 JREs on my system. No luck.




Raymond Feng wrote:
How did you set up the target platform for your Eclipse? Please try 
this:


1) Build distribution/all using mvn clean install
2) In your Eclipse, use File -- Open File to open 
distribution/all/target/features/tuscany.target

3) Click on Set as target platform

Thanks,
Raymond

--
From: Dan Becker dan.o.bec...@gmail.com
Sent: Wednesday, February 04, 2009 8:17 AM
To: dev@tuscany.apache.org
Subject: [2.x] Trouble finding manifest resources in Eclips

This morning I did an svn update and mvn clean build on my system. 
No problems there (BUILD SUCCESSFUL).


However, I rebuilt the project for Eclipse via mvn -Peclipse 
eclipse:eclipse, and I see many errors along the lines of this:


Description Resource Path Location Type
No available bundle exports package 'org.apache.ws.commons.schema' 
MANIFEST.MF tuscany-binding-ws-axis2/META-INF line 142 Plug-in Problem


Are other people seeing this error? Did I miss a step in the process?
--
Thanks, Dan Becker






--
Thanks, Dan Becker 






--
Thanks, Dan Becker

Re: [2.x] Trouble finding manifest resources in Eclips

2009-02-04 Thread Dan Becker

]|  +- 
org.apache.tuscany.sca:tuscany-host-jetty:jar:2.0-SNAPSHOT:compile

[INFO]|  |  +- org.mortbay.jetty:jetty:jar:6.1.7:compile
[INFO]|  |  \- org.mortbay.jetty:jetty-util:jar:6.1.7:compile
[INFO]|  \- 
org.apache.tuscany.sca:tuscany-policy-xml-ws:jar:2.0-SNAPSHOT:compile
[INFO]+- 
org.apache.tuscany.sca:tuscany-feature-ejava:pom:2.0-SNAPSHOT:compile
[INFO]|  +- 
org.apache.tuscany.sca:tuscany-binding-rmi-runtime:jar:2.0-SNAPSHOT:compile
[INFO]|  |  \- 
org.apache.tuscany.sca:tuscany-binding-rmi:jar:2.0-SNAPSHOT:compile
[INFO]|  \- 
org.apache.tuscany.sca:tuscany-host-rmi:jar:2.0-SNAPSHOT:compile
[INFO]\- 
org.apache.tuscany.sca:tuscany-launcher:jar:2.0-SNAPSHOT:compile












--
From: Dan Becker dan.o.bec...@gmail.com
Sent: Wednesday, February 04, 2009 1:26 PM
To: dev@tuscany.apache.org
Subject: Re: [2.x] Trouble finding manifest resources in Eclips



That one is missing. Even a mvn -U did not pull it in.

I added it manually (with an manually updated MANIFEST.MF), but got 
the same errors. Here is what I put in the geronimo-jsp_2.1_spec-1.0 
MANIFEST.MF:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.apache.geronimo.specs.geronimo-jsp_2.1_spec-1.0
Bundle-Name: org.apache.geronimo.specs.geronimo-jsp_2.1_spec-1.0
Bundle-Version: 1.1.0
DynamicImport-Package: *
Bundle-ClassPath: geronimo-jsp_2.1_spec-1.0-1.1.jar
Export-Package: javax.servlet;version=2.1.0


Raymond Feng wrote:

Do you have the following bundle?

C:\Tuscany\java\sca\distribution\all\target\modules\geronimo-jsp_2.1_spec-1.0\geronimo-jsp_2.1_spec-1.0.jar 
Thanks,

Raymond
--
From: Dan Becker dan.o.bec...@gmail.com
Sent: Wednesday, February 04, 2009 11:55 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] Trouble finding manifest resources in Eclips

Hmm, I am still getting 738 errors in Eclipse. These two errors seem 
to be the main problem:

Description Resource Path Location Type
No available bundle exports package 'javax.servlet.jsp.tagext' 
MANIFEST.MF tuscany-host-webapp/META-INF line 30 Plug-in Problem
No available bundle exports package 'javax.servlet.jsp' MANIFEST.MF 
tuscany-host-webapp/META-INF line 29 Plug-in Problem


The mvn -Peclipse and distribution/all builds both run successfully 
for me.


Any other steps? I've pointed the JRE to default and to the Sun and 
IBM 1.6 JREs on my system. No luck.




Raymond Feng wrote:
How did you set up the target platform for your Eclipse? Please try 
this:


1) Build distribution/all using mvn clean install
2) In your Eclipse, use File -- Open File to open 
distribution/all/target/features/tuscany.target

3) Click on Set as target platform

Thanks,
Raymond

--
From: Dan Becker dan.o.bec...@gmail.com
Sent: Wednesday, February 04, 2009 8:17 AM
To: dev@tuscany.apache.org
Subject: [2.x] Trouble finding manifest resources in Eclips

This morning I did an svn update and mvn clean build on my system. 
No problems there (BUILD SUCCESSFUL).


However, I rebuilt the project for Eclipse via mvn -Peclipse 
eclipse:eclipse, and I see many errors along the lines of this:


Description Resource Path Location Type
No available bundle exports package 'org.apache.ws.commons.schema' 
MANIFEST.MF tuscany-binding-ws-axis2/META-INF line 142 Plug-in 
Problem


Are other people seeing this error? Did I miss a step in the process?
--
Thanks, Dan Becker






--
Thanks, Dan Becker






--
Thanks, Dan Becker 






--
Thanks, Dan Becker
[INFO] Scanning for projects...
[INFO] 
[INFO] Building Apache Tuscany SCA All-in-one Distribution
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory E:\t\java\sca\distribution\all\target
Downloading: 
http://people.apache.org/repo/m2-incubating-repository/org/apache/santuario/xmlsec/1.4.2/xmlsec-1.4.2.pom
Downloading: 
http://ws.zones.apache.org/repository2/org/apache/santuario/xmlsec/1.4.2/xmlsec-1.4.2.pom
Downloading: 
http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//org/apache/santuario/xmlsec/1.4.2/xmlsec-1.4.2.pom
Downloading: 
http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2/org/apache/santuario/xmlsec/1.4.2/xmlsec-1.4.2.pom
Downloading: 
http://repo1.maven.org/maven2/org/apache/santuario/xmlsec/1.4.2/xmlsec-1.4.2.pom
Downloading: 
http://people.apache.org/repo/m2-incubating-repository/org/apache/santuario/xmlsec/1.4.0/xmlsec-1.4.0.pom
Downloading: 
http://ws.zones.apache.org/repository2/org/apache/santuario/xmlsec/1.4.0/xmlsec-1.4.0.pom
Downloading: 
http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//org/apache/santuario/xmlsec/1.4.0/xmlsec-1.4.0.pom
Downloading: 
http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2/org/apache/santuario/xmlsec/1.4.0/xmlsec-1.4.0.pom

[jira] Commented: (TUSCANY-2804) Component-Type Calculator iTest fails with NPE

2009-02-04 Thread Dan Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670532#action_12670532
 ] 

Dan Becker commented on TUSCANY-2804:
-

Hey Luciano. I definitely have component-type running (it is not commented 
out). I tried clean/build/test with IBM Java 1.5 and Sun and IBM Java 1.6. All 
seemed to work for me. Strange. So it could be Red-Hat issue. Could you try 
with a different JVM?

 Component-Type Calculator iTest fails with NPE
 --

 Key: TUSCANY-2804
 URL: https://issues.apache.org/jira/browse/TUSCANY-2804
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.0-M1
Reporter: Luciano Resende
Assignee: Dan Becker
 Fix For: Java-SCA-2.0-M1


 java.lang.NullPointerException
   at calculator.CalculatorServiceImpl.add(CalculatorServiceImpl.java:48)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:132)
   at 
 org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:289)
   at 
 org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:156)
   at $Proxy6.add(Unknown Source)
   at 
 calculator.CalculatorTestCase.testCalculator(CalculatorTestCase.java:55)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
   at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
   at 
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
   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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Tuscany JavaDocs Refresh

2009-02-03 Thread Dan Becker


Luciano Resende wrote:


   Thanks a lot for taking care of this :) It was long due.
   Any chance you have steps or a unix script that we could use to
generate this during release process ?


I used a progammable editor to generate the docs, but I think it would 
be a good idea to create some scripts and add it to our build, perhaps a 
Maven docs profile. Let me take this action item.


One limitation we have right now is a Sun JavaDocs bug that causes a 
ClassCastException and kills the docs generation. Individual class doc 
files are created but some links in the index file are missing. It seems 
that classes that use annotations (e.g. Tuscany) can cause this problem. 
There are a few workarounds, but the one I tried (putting Annotation 
classes on the classpath) did not prevent the issue.


Vote for this Sun bug if you have a free bug vote!
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982



On Thu, Jan 29, 2009 at 8:10 AM, Dan Becker dan.o.bec...@gmail.com wrote:

ant elder wrote:

Certainly an improvement over only having the 0.9 level doc, can see why
no
one has done it since then if it takes over 7 hours :)

One thing is that doesn't include the spec defined API classes, i guess
they
were filtered out as they're org.osoa.sca not org.apache.tuscany.sca.

I will add those. Good find.


  ...ant

On Wed, Jan 28, 2009 at 4:38 PM, Dan Becker dan.o.bec...@gmail.com
wrote:


I made some JavaDocs for Tuscany 1.4. If you would like to have a look, I
placed it on my Apache personal space here [1], and once I get a few
comments or change requests, I will check it in.

Please let me know if you would like to change the style, add any titles
or
footers, or remove any packages.

Here is the basic method I used to generate the docs:
1) Get a directory list of all src directories under tuscany modules.
2) Grep only for paths that end in src/main/java.
3) Generate javadoc with
 javadoc -d html -sourcepath $(SRCDIRS) -subpackages org.apache.tuscany

(Note that SRCDIRS contains a list of 133 directories. It took my laptop
over 7 hours to generate all the files. Maybe next time I will copy all
the
src trees to one location to save time. The zip file of the docs is 5.8
MB.)

[1]
http://people.apache.org/~beckerdo/tuscany/http://people.apache.org/%7Ebeckerdo/tuscany/


Luciano Resende wrote:


When we last looked at this, there was an issue around grouping the
java docs produced by multiple modules, and we had to do it manually.

I was thinking about this for 2.x, and one idea would be to use the
same technique we use to produce a all jar, where we group multiple
modules, and then produce the javadoc from that temporary grouped set
of modules ?

On Tue, Jan 27, 2009 at 8:26 AM, Dan Becker dan.o.bec...@gmail.com
wrote:


I noticed an older Tuscany Jira requesting an update on the Tuscany
JavaDocs
[1]. It appears the last public Tuscany JavaDoc we release is at the
0.9
level. I intend on resolving the Jira and making a 1.4 level JavaDoc
and
publishing at http://tuscany.apache.org/doc/javadoc/. Any words of
wisdom or
other helpful hints before I jump?

[1] http://issues.apache.org/jira/browse/TUSCANY-2485



--
Thanks, Dan Becker

[jira] Created: (TUSCANY-2807) Automate JavaDocs production

2009-02-03 Thread Dan Becker (JIRA)

Automate JavaDocs production


 Key: TUSCANY-2807
 URL: https://issues.apache.org/jira/browse/TUSCANY-2807
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Documentation
 Environment: Java
Reporter: Dan Becker
Priority: Minor
 Fix For: Java-SCA-2.0


Provide Maven profile, Ant scripts, or other automation to produce JavaDocs for 
a Tuscany release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2807) Automate JavaDocs production

2009-02-03 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2807:
---

Assignee: Dan Becker

 Automate JavaDocs production
 

 Key: TUSCANY-2807
 URL: https://issues.apache.org/jira/browse/TUSCANY-2807
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Documentation
 Environment: Java
Reporter: Dan Becker
Assignee: Dan Becker
Priority: Minor
 Fix For: Java-SCA-2.0


 Provide Maven profile, Ant scripts, or other automation to produce JavaDocs 
 for a Tuscany release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2743) [Documentation] Improve user documentation for SCA Java

2009-02-03 Thread Dan Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669960#action_12669960
 ] 

Dan Becker commented on TUSCANY-2743:
-

Note that Tuscany Jira http://issues.apache.org/jira/browse/TUSCANY-2485 
provided docs for Tuscany 1.4. This is one component of improving user 
documentation. They are available in SVN at 
http://svn.apache.org/repos/asf/tuscany/site/site-publish/doc/javadoc/java-sca-1.4/

 [Documentation] Improve user documentation for SCA Java
 ---

 Key: TUSCANY-2743
 URL: https://issues.apache.org/jira/browse/TUSCANY-2743
 Project: Tuscany
  Issue Type: Improvement
  Components: Website
Reporter: haleh mahbod
Assignee: haleh mahbod
Priority: Critical
 Fix For: Java-SCA-Next


 Need to majorly enhance user documentation. Trying to get more information 
 from users as to what is exactly missing. Meanwhile I am going through the 
 website and ensuring the basic concepts are clear and have sufficient 
 examples.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Continuous Integration / Automated Builds

2009-02-03 Thread Dan Becker

The Continuum build link is very useful. I did not see it on the mailing 
list or the web site, so I added it to the FAQ (last build question):


http://tuscany.apache.org/tuscany-sca-java-faq.html


Kevan Miller wrote:


On Feb 3, 2009, at 10:05 AM, ant elder wrote:




On Tue, Feb 3, 2009 at 2:51 PM, Kevan Miller kevan.mil...@gmail.com 
wrote:
It seems to me that the Tuscany project would benefit from a 
continuous integration environment / automated build process. Simply 
identifying compile/dependency errors would be a big help. The 
inclusion of higher-level integration tests in the build would, IMO,  
greatly enhance the benefit.


There are a number of options for this. The Hudson project hosts a CI 
server for apache projects -- 
http://hudson.zones.apache.org/hudson/ Or, you can always set up a 
private cron job to run a build and post results to the dev list.


Thoughts?

--kevan

Would be really good. We do have a Continuum build which used to do 
nightly builds but there's not been a successful build since the 18th 
of October! -


http://vmbuild.apache.org/continuum/buildResults.action?projectGroupId=19projectId=277 



Heh. I'd searched the mailing list for evidence of CI/nightly builds, 
but didn't find any. To be of benefit to the community, I think there 
must be success/fail notification emails sent to the mailing list.


--kevan



--
Thanks, Dan Becker

[jira] Assigned: (TUSCANY-2755) Tuscany 1.3.2 and STP-SCA tooling Integration

2009-02-02 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2755:
---

Assignee: Dan Becker

 Tuscany 1.3.2 and STP-SCA tooling Integration
 -

 Key: TUSCANY-2755
 URL: https://issues.apache.org/jira/browse/TUSCANY-2755
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Tools
Reporter: Dhaval Chauhan
Assignee: Dan Becker
 Attachments: Tuscany-Eclipse_STP_SCA integration.doc


 Attached word document explains the current status of integration of eclipse 
 STP-SCA tool with Tuscany's latest release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2803) Module Apache Tuscany SCA Node Implementation Model: stop searching after the first matching component.

2009-02-02 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2803.
-

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

Resolved in branch 1.x at revision: 740031. Thanks for bringing up the issue.


 Module Apache Tuscany SCA Node Implementation Model: stop searching after 
 the first matching component.
 -

 Key: TUSCANY-2803
 URL: https://issues.apache.org/jira/browse/TUSCANY-2803
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-1.4
Reporter: Radu Fantaziu
Assignee: Dan Becker
Priority: Minor
 Fix For: Java-SCA-Next


 The following code extracted from 
 org.apache.tuscany.sca.node.impl.NodeImpl.getServiceReference()
 
 for (Component compositeComponent : composite.getComponents()) {
 if (compositeComponent.getName().equals(componentName)) {
 component = compositeComponent;
 }
 }
 
 should be:
 ..
 for (Component compositeComponent : composite.getComponents()) {
 if (compositeComponent.getName().equals(componentName)) {
 component = compositeComponent;
 break;
 }
 }
 .

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Tuscany 2.0 timeframe

2009-02-02 Thread Dan Becker

Sorry for being late to comment, but I agree this is a very good way to 
go about it. I like the idea of starting with the high level themes and 
features, and creating Jira from that, and driving and tracking work via 
the Jiras. I've added a few minor edits to the wiki release notes, and 
I'll help out on this effort.


ant elder wrote:

On Thu, Jan 29, 2009 at 10:38 AM, ant elder ant.el...@gmail.com wrote:


Back in November we voted to start Tuscany 2.x to create an version of
Tuscany compliant with the new OASIS versions of the SCA specifications (see
[1]) but we've not really discussed any timeframe for that. OASIS are
planning to publish the final versions of the specs along with the
compliance tests around mid 2009, talking to the spec guys they suggest June
or July is looking realistic.

Wouldn't it be good if Apache Tuscany was one of the first to announce a
release supporting those new specs, so how about using that date to aim for
a final Tuscany 2.0 release? If people agree with doing this then we have
just 4 or 5 months to finish 2.0 so i wonder if we need to be a bit more
organised.

One thing I thought could help is if we write the 2.0 release notes _now_
and then we can use that as the high level guide to what we need to get
done.

Another thing that could help is if we use JIRA more to track most of the
work items so we have one central place showing all the work remaining. We
already have the Java-SCA-2.0-M1 and Java-SCA-2.0 categories in the JIRA
system so how about we now try to create JIRAs for all the bits of work we
know we need to do, using things like the release notes, or the 2.0 themes
thread [2], or the various wiki pages already created for 2.0.



I've started a draft 2.0 release notes at:
http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/2.0+Release+Notes



--
Thanks, Dan Becker

[jira] Commented: (TUSCANY-2485) java API documentation outdated

2009-01-31 Thread Dan Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669249#action_12669249
 ] 

Dan Becker commented on TUSCANY-2485:
-

Note that generating the docs for Tuscany 1.4, the javadoc tool exists with a 
ClassCastException, preventing generating the full Javadocs: 

java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl incompatible wi
th com.sun.javadoc.AnnotationTypeDoc
at com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDes
cImpl.java:58)
at com.sun.tools.doclets.internal.toolkit.util.Util.isDeprecated(Util.ja
va:823)
at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printComment(A
bstractIndexWriter.java:191)
at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printDescripti
on(AbstractIndexWriter.java:176)
at com.sun.tools.doclets.formats.html.AbstractIndexWriter.generateConten
ts(AbstractIndexWriter.java:101)
at com.sun.tools.doclets.formats.html.SingleIndexWriter.generateIndexFil
e(SingleIndexWriter.java:89)
at com.sun.tools.doclets.formats.html.SingleIndexWriter.generate(SingleI
ndexWriter.java:64)
at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(Html
Doclet.java:115)
at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration
(AbstractDoclet.java:134)
at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractD
oclet.java:76)
at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:5
4)
at com.sun.tools.doclets.standard.Standard.start(Standard.java:35)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:45)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:577)
at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:227)
at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:103)
at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:352)
at com.sun.tools.javadoc.Start.begin(Start.java:140)
at com.sun.tools.javadoc.Main.execute(Main.java:52)
at com.sun.tools.javadoc.Main.main(Main.java:42)

I ran into this exception with IBM JDK 1.5, IBM JDK 1.6, Sun JDK 1.5 and Sun 
JDK 1.6.0_11. I found this unsolved bug describing the unresolved issue:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982

 java API documentation outdated
 ---

 Key: TUSCANY-2485
 URL: https://issues.apache.org/jira/browse/TUSCANY-2485
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Documentation, Website
Affects Versions: Java-SCA-1.2
Reporter: Malte Marquarding
Assignee: Dan Becker
 Fix For: Java-SCA-Next


 The java API documentation is outdated - it reflects java-sca-0.9, see 
 http://tuscany.apache.org/doc/javadoc/
 Please update this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2776) The JMSBindingProcessor does not perform validation of binding properties

2009-01-30 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2776.
-

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

Commited to the 1.x branch at revision: 739312  


 The JMSBindingProcessor does not perform validation of binding properties
 -

 Key: TUSCANY-2776
 URL: https://issues.apache.org/jira/browse/TUSCANY-2776
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: All
Reporter: Simon Laws
Assignee: Dan Becker
 Fix For: Java-SCA-Next


 The JMS binding spec defines some cross field validations. The validate() 
 method in the JMSBindingProcessor is as follows.
 /**
  * The validation rules for the JMS model are relatively complicated to 
 they all live together here
  */
 public void validate() throws JMSBindingException {
 /*
  * first fix up anything now the model has been read
  */
 /*
  * Now some cross field validation
  */
 // connection factory doesn't contradict destination type
 // connection factory and activation Specification are mutually 
 exclusive
 // TODO check Specification for all validations
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[1.x] JMS Binding model and composite parsing validation

2009-01-30 Thread Dan Becker

Tuscany 2776 (https://issues.apache.org/jira/browse/TUSCANY-2776) in the 
1.x branch adds some validation to JMS binding. Both the XML of the 
binding and the contents of the binding model are validated. Much of 
this validation takes place in the validate method of the 
JMSBindingProcessor. Users might see a JMSBindingException if there is a 
mistake in the XML or the content of the binding.


Most of the validation rules are taken from the contents of the OSOA JMS 
Binding spec 1.0 or the OASIS SCA JMS binding spec 1.1. There are a few 
must must not commands in there which form the basis of the 
validation rules. If you have additional comments or would like to 
suggest other validations, please let us know.

--
Thanks, Dan Becker

Re: Tuscany JavaDocs Refresh

2009-01-29 Thread Dan Becker


ant elder wrote:

Certainly an improvement over only having the 0.9 level doc, can see why no
one has done it since then if it takes over 7 hours :)

One thing is that doesn't include the spec defined API classes, i guess they
were filtered out as they're org.osoa.sca not org.apache.tuscany.sca.


I will add those. Good find.



   ...ant

On Wed, Jan 28, 2009 at 4:38 PM, Dan Becker dan.o.bec...@gmail.com wrote:


I made some JavaDocs for Tuscany 1.4. If you would like to have a look, I
placed it on my Apache personal space here [1], and once I get a few
comments or change requests, I will check it in.

Please let me know if you would like to change the style, add any titles or
footers, or remove any packages.

Here is the basic method I used to generate the docs:
1) Get a directory list of all src directories under tuscany modules.
2) Grep only for paths that end in src/main/java.
3) Generate javadoc with
  javadoc -d html -sourcepath $(SRCDIRS) -subpackages org.apache.tuscany

(Note that SRCDIRS contains a list of 133 directories. It took my laptop
over 7 hours to generate all the files. Maybe next time I will copy all the
src trees to one location to save time. The zip file of the docs is 5.8 MB.)

[1] 
http://people.apache.org/~beckerdo/tuscany/http://people.apache.org/%7Ebeckerdo/tuscany/


Luciano Resende wrote:


When we last looked at this, there was an issue around grouping the
java docs produced by multiple modules, and we had to do it manually.

I was thinking about this for 2.x, and one idea would be to use the
same technique we use to produce a all jar, where we group multiple
modules, and then produce the javadoc from that temporary grouped set
of modules ?

On Tue, Jan 27, 2009 at 8:26 AM, Dan Becker dan.o.bec...@gmail.com
wrote:


I noticed an older Tuscany Jira requesting an update on the Tuscany
JavaDocs
[1]. It appears the last public Tuscany JavaDoc we release is at the 0.9
level. I intend on resolving the Jira and making a 1.4 level JavaDoc and
publishing at http://tuscany.apache.org/doc/javadoc/. Any words of
wisdom or
other helpful hints before I jump?

[1] http://issues.apache.org/jira/browse/TUSCANY-2485




--
Thanks, Dan Becker

Re: What modules should be included in generated JavaDocs ? Re: Tuscany JavaDocs Refresh

2009-01-29 Thread Dan Becker


Both good questions.

1) Definitely SPIs should have well maintained JavaDocs. I would prefer 
in addition to the code we have a more readable and well maintained 
JavaDoc. So these new JavaDocs should help there, bringing our version 
0.9 to 1.4.


2) It is true that many of the impl classes and various infrastructure 
classes are more likely to change.  I think this issue pertains also 
when people mark classes public (rather than protected or private) or 
rewrite an impl class and add or subtract new methods. This is not just 
a JavaDoc issue, but a change issue. For any class we make public, I 
would like to see some JavaDocs on those classes, regardless if they are 
a rock solid SPI or the simplest little util class. If they change we 
should make sure we tag APIs properly with @since, @deprecated, and 
@link tags to help users understand and deal with the change.



Luciano Resende wrote:

In the past, we had generated JavaDocs for what we were considering
somewhat stable SPIs.

I noticed that you have generated JavaDocs for all our source, and I
have two concerns with that :
   1) We usually only do a good/ok job on creating/maintaining
javadocs for SPIs.
   2) What are the user implications of generating javadocs on things
that are in constant change ?
   Are they going to assume these are somewhat stable SPIs ?


Thoughts ?

[1] http://people.apache.org/~beckerdo/tuscany/javadoc-sca-1.4/

On Wed, Jan 28, 2009 at 8:38 AM, Dan Becker dan.o.bec...@gmail.com wrote:

I made some JavaDocs for Tuscany 1.4. If you would like to have a look, I
placed it on my Apache personal space here [1], and once I get a few
comments or change requests, I will check it in.

Please let me know if you would like to change the style, add any titles or
footers, or remove any packages.

Here is the basic method I used to generate the docs:
1) Get a directory list of all src directories under tuscany modules.
2) Grep only for paths that end in src/main/java.
3) Generate javadoc with
  javadoc -d html -sourcepath $(SRCDIRS) -subpackages org.apache.tuscany

(Note that SRCDIRS contains a list of 133 directories. It took my laptop
over 7 hours to generate all the files. Maybe next time I will copy all the
src trees to one location to save time. The zip file of the docs is 5.8 MB.)

[1] http://people.apache.org/~beckerdo/tuscany/

Luciano Resende wrote:

When we last looked at this, there was an issue around grouping the
java docs produced by multiple modules, and we had to do it manually.

I was thinking about this for 2.x, and one idea would be to use the
same technique we use to produce a all jar, where we group multiple
modules, and then produce the javadoc from that temporary grouped set
of modules ?

On Tue, Jan 27, 2009 at 8:26 AM, Dan Becker dan.o.bec...@gmail.com
wrote:

I noticed an older Tuscany Jira requesting an update on the Tuscany
JavaDocs
[1]. It appears the last public Tuscany JavaDoc we release is at the 0.9
level. I intend on resolving the Jira and making a 1.4 level JavaDoc and
publishing at http://tuscany.apache.org/doc/javadoc/. Any words of wisdom
or
other helpful hints before I jump?

[1] http://issues.apache.org/jira/browse/TUSCANY-2485

--



--
Thanks, Dan Becker

Re: Tuscany JavaDocs Refresh

2009-01-28 Thread Dan Becker

I made some JavaDocs for Tuscany 1.4. If you would like to have a look, 
I placed it on my Apache personal space here [1], and once I get a few 
comments or change requests, I will check it in.


Please let me know if you would like to change the style, add any titles 
or footers, or remove any packages.


Here is the basic method I used to generate the docs:
1) Get a directory list of all src directories under tuscany modules.
2) Grep only for paths that end in src/main/java.
3) Generate javadoc with
   javadoc -d html -sourcepath $(SRCDIRS) -subpackages org.apache.tuscany

(Note that SRCDIRS contains a list of 133 directories. It took my laptop 
over 7 hours to generate all the files. Maybe next time I will copy all 
the src trees to one location to save time. The zip file of the docs is 
5.8 MB.)


[1] http://people.apache.org/~beckerdo/tuscany/

Luciano Resende wrote:

When we last looked at this, there was an issue around grouping the
java docs produced by multiple modules, and we had to do it manually.

I was thinking about this for 2.x, and one idea would be to use the
same technique we use to produce a all jar, where we group multiple
modules, and then produce the javadoc from that temporary grouped set
of modules ?

On Tue, Jan 27, 2009 at 8:26 AM, Dan Becker dan.o.bec...@gmail.com wrote:

I noticed an older Tuscany Jira requesting an update on the Tuscany JavaDocs
[1]. It appears the last public Tuscany JavaDoc we release is at the 0.9
level. I intend on resolving the Jira and making a 1.4 level JavaDoc and
publishing at http://tuscany.apache.org/doc/javadoc/. Any words of wisdom or
other helpful hints before I jump?

[1] http://issues.apache.org/jira/browse/TUSCANY-2485


--
Thanks, Dan Becker

[jira] Commented: (TUSCANY-2485) java API documentation outdated

2009-01-28 Thread Dan Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668069#action_12668069
 ] 

Dan Becker commented on TUSCANY-2485:
-

For now we have generated a temporary JavaDoc for Tuscany 1.4 at 
http://people.apache.org/~beckerdo/tuscany/javadoc-sca-1.4/.  After some 
comments on the docs, we will generate a final version and place in SVN. Thanks 
for bringing this up.

 java API documentation outdated
 ---

 Key: TUSCANY-2485
 URL: https://issues.apache.org/jira/browse/TUSCANY-2485
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Documentation, Website
Affects Versions: Java-SCA-1.2
Reporter: Malte Marquarding
Assignee: Dan Becker
 Fix For: Java-SCA-Next


 The java API documentation is outdated - it reflects java-sca-0.9, see 
 http://tuscany.apache.org/doc/javadoc/
 Please update this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Holder-ws-service sample, was Re: svn commit: r736344 - in /tuscany: branches/sca-java-1.x/samples/ java/sca/samples/helloworld-ws-service/ java/sca/samples/helloworld-ws-service/src/main/java/o

2009-01-27 Thread Dan Becker

That is quite strange. Either it is a bug with TortoiseSVN or my misuse 
of it. All those files (e.g. OrderService.java, orderservice.wsdl) 
appear in my file system under 
tuscany/java/sca/samples/holder-ws-service/..., and that is the 
directory they were committed from. It is intended as a new sample 
holder-ws-service and has nothing to do with helloworld-ws-service other 
than they are both web service based services. I will look into it and 
fix it up.


Luciano Resende wrote:

Looks like you have added a holder-ws-service to pom.xml, but I don't
see a sample app with that name.
Is the sample suposed to be the helloworld-ws-service, instead of
holder-ws-service ?

For now I'm commenting out the entry for the pom.

On Wed, Jan 21, 2009 at 9:14 AM,  becke...@apache.org wrote:

Author: beckerdo
Date: Wed Jan 21 09:14:42 2009
New Revision: 736344

URL: http://svn.apache.org/viewvc?rev=736344view=rev
Log:
Tuscany 2768 - sample showing web services Holder support (input/output 
parameters)

Added:
   tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/
   tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/ObjectFactory.java
   (with props)
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/Order.java
   (with props)
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/OrderService.java
   (with props)
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/OrderServiceImpl.java
   (with props)
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/OrderService_Service.java
   (with props)
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/ReviewOrder.java
   (with props)
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/ReviewOrderResponse.java
   (with props)
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/Status.java
   (with props)
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/java/org/example/orderservice/package-info.java
   (with props)
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/META-INF/sca-deployables/orderws.composite
   
tuscany/java/sca/samples/helloworld-ws-service/src/main/resources/wsdl/orderservice.wsdl
   tuscany/java/sca/samples/helloworld-ws-service/src/test/java/org/
   tuscany/java/sca/samples/helloworld-ws-service/src/test/java/org/example/
Modified:
   tuscany/branches/sca-java-1.x/samples/pom.xml
   tuscany/java/sca/samples/helloworld-ws-service/README
   tuscany/java/sca/samples/helloworld-ws-service/build.xml
   tuscany/java/sca/samples/helloworld-ws-service/pom.xml



--
Thanks, Dan Becker

[jira] Resolved: (TUSCANY-2754) NPE received when wsdlElement is incorrectly specified

2009-01-27 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2754.
-

Resolution: Invalid

Invalid port is flagged by Tuscany. Caller program ignores flag and continues 
use of model to build WSDL.

 NPE received when wsdlElement  is incorrectly specified
 ---

 Key: TUSCANY-2754
 URL: https://issues.apache.org/jira/browse/TUSCANY-2754
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-1.3
 Environment: Tuscany 1.3.1
Reporter: Lou Amodeo
Assignee: Dan Becker

 When one inadvertently specifies an incorrect wsdlElement  service name as 
 part of the wsdl.port a NPE is thrown rather than a validation exception.  It 
 also appears that in general there is no validation occurring for the 
 wsdlElment namespace, service, port, or binding names.   Instead NPE 
 exceptions occur in different locations making it difficult to diagnose the 
 problem.   I think the wsdlElement's attributes need to be validated with the 
 appropriate error messages emitted to identify the corrections required.  
   
 This particular error can reproduced by specifying a service in wsdl.port 
 that does not refer to a service in the contributed wsdl.  
 java.lang.NullPointerException
 at 
 org.apache.tuscany.sca.binding.ws.wsdlgen.WSDLServiceGenerator.configureWSDLDefinition(WSDLServiceGenerator.java:247)
 at 
 org.apache.tuscany.sca.binding.ws.wsdlgen.BindingWSDLGenerator.createWSDLDocument(BindingWSDLGenerator.java:277)
 at 
 org.apache.tuscany.sca.binding.ws.wsdlgen.BindingWSDLGenerator.generateWSDL(BindingWSDLGenerator.java:172)
 at 
 org.apache.tuscany.sca.binding.ws.xml.BindingBuilderImpl.build(BindingBuilderImpl.java:55)
 at 
 org.apache.tuscany.sca.assembly.builder.impl.ComponentServiceBindingBuilderImpl.buildServiceBindings(ComponentServiceBindingBuilderImpl.java:66)
 at 
 org.apache.tuscany.sca.assembly.builder.impl.ComponentServiceBindingBuilderImpl.build(ComponentServiceBindingBuilderImpl.java:48)
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2485) java API documentation outdated

2009-01-27 Thread Dan Becker (JIRA)


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2485:
---

Assignee: Dan Becker

 java API documentation outdated
 ---

 Key: TUSCANY-2485
 URL: https://issues.apache.org/jira/browse/TUSCANY-2485
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Documentation, Website
Affects Versions: Java-SCA-1.2
Reporter: Malte Marquarding
Assignee: Dan Becker
 Fix For: Java-SCA-Next


 The java API documentation is outdated - it reflects java-sca-0.9, see 
 http://tuscany.apache.org/doc/javadoc/
 Please update this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2579) Tuscany Schemas use sequences which makes the composite elements to have order, while that is not the case with Spec


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2579.
-

Resolution: Won't Fix

OSOA closed this issue with no action and will not update the spec here. Since 
Tuscany must follow the OSOA spec for this issue, we cannot add choice and must 
follow java.implementation in the same order as OSOA specs.

 Tuscany Schemas use sequences which makes the composite elements to have 
 order, while that is not the case with Spec
 

 Key: TUSCANY-2579
 URL: https://issues.apache.org/jira/browse/TUSCANY-2579
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Problem Determination
 Environment: All
Reporter: Hasan Muhammad
 Fix For: Java-SCA-Next


 The schema for component is as such:
 element name=componentType type=sca:ComponentType/
 complexType name=ComponentType
   sequence
  choice minOccurs=0 maxOccurs=1
element ref=sca:implementation/
any namespace=##other processContents=lax/
  /choice
   choice minOccurs=0 maxOccurs=unbounded
   element name=service type=sca:ComponentService /
   element name=reference type=sca:ComponentReference/
   element name=property type=sca:Property/
   /choice
   !-- 
   any namespace=##other processContents=lax minOccurs=0 
   maxOccurs=unbounded/
   --
 /sequence
 attribute name=constrainingType type=QName use=optional/
 anyAttribute namespace=##any processContents=lax/
 /complexType
 This forces the user to have the element implementation.java before the 
 other elements such as service, reference etc, which should not be the case. 
 The following error is generated
 alidatingXML E   XMLSchema validation error occured in: null ,line = -1, 
 column = -1, Message = cvc-complex-type.2.4.a: Invalid content was found 
 starting with element 'implementation.java'. One of 
 '{http://www.osoa.org/xmlns/sca/1.0:service, 
 http://www.osoa.org/xmlns/sca/1.0:reference, 
 http://www.osoa.org/xmlns/sca/1.0:property}' is expected.
 So the schema needs to be changed. This problem may exist at other places in 
 this schema and other schemas as well

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2583) only first method's parameter is send in JMS Message


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker resolved TUSCANY-2583.
-

Resolution: Fixed

As stated by Ant, the issue has been fixed and now all message parameters are 
sent in the message body. (Spec compliance is another issue which should be 
addressed in another Jira.)

 only first method's parameter is send in JMS Message
 

 Key: TUSCANY-2583
 URL: https://issues.apache.org/jira/browse/TUSCANY-2583
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.3
Reporter: Gaetan RUAULT
Assignee: ant elder
 Fix For: Java-SCA-Next

   Original Estimate: 4h
  Remaining Estimate: 4h

 The JMS provider generate only the first parameter of the service call 
 example :
 for a jms interface service like this : 
 package personne.stub;
 import org.osoa.sca.annotations.Remotable;
 @Remotable
 public interface TestJMSService {
   int add(Integer x, Integer y);
   int subtract(Integer x, Integer y);
 }
 with call like this : testJMSService.add(1,6)
 the XMLTextMessageProcessor class generate this body for the JMS Message :
 arg0 xmlns:ns2=http://stub.personne/;1/arg0
 but il would generated :
 arg0 xmlns:ns2=http://stub.personne/;1/arg0
 arg1 xmlns:ns2=http://stub.personne/;6/arg1
 this problem appear in the method createJMSMessage of 
 org.apache.tuscany.sca.binding.jms.provider.XMLTextMessageProcessor class.
 only the first element of the array is set for body text.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2776) The JMSBindingProcessor does not perform validation of binding properties


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2776:
---

Assignee: Dan Becker

 The JMSBindingProcessor does not perform validation of binding properties
 -

 Key: TUSCANY-2776
 URL: https://issues.apache.org/jira/browse/TUSCANY-2776
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
 Environment: All
Reporter: Simon Laws
Assignee: Dan Becker

 The JMS binding spec defines some cross field validations. The validate() 
 method in the JMSBindingProcessor is as follows.
 /**
  * The validation rules for the JMS model are relatively complicated to 
 they all live together here
  */
 public void validate() throws JMSBindingException {
 /*
  * first fix up anything now the model has been read
  */
 /*
  * Now some cross field validation
  */
 // connection factory doesn't contradict destination type
 // connection factory and activation Specification are mutually 
 exclusive
 // TODO check Specification for all validations
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2794) JMS callback property variable ends with space - not a valid Javaidentifier


 [ 
https://issues.apache.org/jira/browse/TUSCANY-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Becker reassigned TUSCANY-2794:
---

Assignee: Dan Becker

 JMS callback property variable ends with space - not a valid Javaidentifier
 ---

 Key: TUSCANY-2794
 URL: https://issues.apache.org/jira/browse/TUSCANY-2794
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.4
Reporter: Tom Seelbach
Assignee: Dan Becker

 We are seeing this exception when trying to run some JMS callback scenarios:
 org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.binding.jms.impl.JMSBindingException: 
 javax.jms.MessageFormatException: CWSIA0112E:The property name 
 scaCallbackQueue  is not a valid Javaidentifier. at 
 com.ibm.ws.soa.sca.binding.sca.SCAServiceBindingProvider.invokeServiceOperation(SCAServiceBindingProvider.java:540)
  at  
 ...   
 In looking at JMSBindingConstants I see that this property is defined oddly 
 with a trailing space:  
 String CALLBACK_ID_PROPERTY = CallbackID;
 String CALLBACK_Q_PROPERTY  = scaCallbackQueue ;
 String CONVERSATION_ID_PROPERTY = scaConversationId;
 Removing the space fixes the problem for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TUSCANY-2794) JMS callback property variable ends with space - not a valid Javaidentifier