Re: GSoC Project - CORBA Support for Apache Tuscany

2008-04-30 Thread Simon Laws
On Wed, Apr 30, 2008 at 7:10 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> For now, I recommend you to use "mvn clean install -fn" to continue. And
> also please open a JIRA to report the problem you are seeing so that we can
> track and fix it.
>
> Thanks,
> Raymond
> --
> From: "Wojtek Janiszewski" <[EMAIL PROTECTED]>
> Sent: Wednesday, April 30, 2008 10:43 AM
> To: 
> Subject: GSoC Project - CORBA Support for Apache Tuscany
>
>
>  Hi,
> > Raymond Feng checked in some skeleton code for CORBA services and
> > references binding. To start project I've tried to build Tuscany. I've
> > followed this document [1], tried to make top-down build with code from [2]
> > and got Build Failure while testing "Apache Tuscany SCA XML Assembly Model".
> > I'm using maven 2.0.7, jdk1.5.0_09, Slackware Linux running 2.6.23.12kernel.
> >
> > Tests in error:
> >
> >
> > testResolveConstrainingType(org.apache.tuscany.sca.assembly.xml.WireTestCase)
> >  testResolveComposite(org.apache.tuscany.sca.assembly.xml.WireTestCase)
> >
> >
> > testReadWireWriteComposite(org.apache.tuscany.sca.assembly.xml.WriteAllTestCase)
> >
> >
> > testPolicyIntentInheritance(org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase)
> >
> > Exceptions for every test are quite the same:
> > java.util.MissingResourceException: Can't find
> > assembly-validation-messages bundle
> >at java.util.logging.Logger.setupResourceInfo(Logger.java:1309)
> >at java.util.logging.Logger.(Logger.java:204)
> >at java.util.logging.Logger.getLogger(Logger.java:300)
> >at
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1.problem(CompositeBuilderImpl.java:89)
> >at
> > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.warning(BaseConfigurationBuilderImpl.java:297)
> >at
> > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.indexImplementationPropertiesServicesAndReferences(BaseConfigurationBuilderImpl.java:616)
> >at
> > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:197)
> >at
> > org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:85)
> >at
> > org.apache.tuscany.sca.assembly.builder.impl.ComponentConfigurationBuilderImpl.build(ComponentConfigurationBuilderImpl.java:47)
> >at
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:127)
> >at
> > org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase.setUp(BuildPolicyTestCase.java:126)
> >at junit.framework.TestCase.runBare(TestCase.java:132)
> >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.OldTestClassRunner.run(OldTestClassRunner.java:35)
> >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:585)
> >at
> > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> >at
> > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
> >
> >
> >
> > [1] -
> > http://incubator.apache.org/tuscany/sca-java-development-guide.html
> > [2] - http://svn.apache.org/repos/asf/incubator/tuscany/java
> >
> > I'm asking you for a help, does anyone have idea what I'm doing wrong?
> >
> > Thanks,
> > Wojtek
> >
>
>
Hi Wojtek

I cam across this problem also and checked in a fix so maybe it needs a
little something else. Can you tell me when you took the code from svn? Also
can you take a look in the source you have an tell me what properties files
you have in the directory sca/modules/assembly/src/main/resources/. Do they
have the same names as the files in the svn repository?

http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/assembly/src/main/resources/

Thank

[jira] Commented: (TUSCANY-2271) Java runtime should not inject property into an unannotated non-public field

2008-04-30 Thread Vamsavardhana Reddy (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593478#action_12593478
 ] 

Vamsavardhana Reddy commented on TUSCANY-2271:
--

Q 1. protected field and its setter is protected
- there should be no injection.
A: Only in the case of protected field without a setter method, the property 
should not be injected.

Q 2. protected/private field but its setter is public
- there should be no injection, too
Ans: No, the property should be injected in this case.


> Java runtime should not inject property into an unannotated non-public field
> 
>
> Key: TUSCANY-2271
> URL: https://issues.apache.org/jira/browse/TUSCANY-2271
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Verification Tests
>Affects Versions: Java-SCA-1.2
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2271.patch
>
>
> Java Common Annotations and APIs v1.0 - Sec 1.8.13:
> 1349 Properties may also be injected via public setter methods even when the 
> @Property annotation is not
> 1350 present. However, the @Property annotation must be used in order to 
> inject a property onto a non-public
> 1351 field. In the case where there is no @Property annotation, the name of 
> the property is the same as the
> 1352 name of the field or setter.
> Currently the properties are injected into unannotated protected fields too.

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



Re: Improving support for running in OSGi

2008-04-30 Thread Jean-Sebastien Delfino

Graham Charters wrote:

Hi Raymond, thanks for your comments.  I've added some more below.

Regards, Graham.

2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:

More comments inline.

 Thanks,
 Raymond
 --
 From: "Graham Charters" <[EMAIL PROTECTED]>
 Sent: Wednesday, April 30, 2008 9:43 AM

 To: 
 Subject: Re: Improving support for running in OSGi



2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:


"Enforcing" the modularity via OSGi is a good way to validate our
modularity/extensibility story in Tuscany. I think we already have a

fairly

well organized module structure in Tuscany (from the maven dependency
perspective). To be consistent, should we consider directly mapping our
module structure into OSGi bundles (one bundle per existing Tuscany

module)?



I wonder if that might be too fine-grained and unmanageable.
Personally, I'd prefer an approach which took into consideration how
we see folks extending or sub-setting the runtime (e.g. the things
Yang referred to - implementation types, etc.).



 IMHO, big bundles lead to defeat modularity and increase coupling. It also
become difficult to embed subset of the Tuscany runtime. But anyway, we can
adjust the scheme over time as the picture becomes clearer.




To a certain extent I agree with you, but there's also a school of
thought that says when adopting OSGi it's best to start with big
modules and then decompose as understanding grows.  I think the
thought processes we go through will ensure we end up with the right
modules that match the requirements, such as runtime subsetting.


 There may be different levels for the OSGi enablement.

 1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars

can be

consumed as OSGi bundles
 2) Run Tuscany bundles with an OSGi runtime (using OSGi as the
modularization mechanism for the Tuscany runtime, system level)


I think we need this step to occur regularly and frequently to stop
the support decaying.  I've fixed these kinds of issues twice in the
last week, which occur because new modules are added to Tuscany, but
not the OSGi support (not surprising since the OSGi support is outside
the main build).



 Is there a checklist we can use to make sure new modules or changes won't
break the OSGi support? If not, can we produce one and post it to the
Tuscany wiki?




I think we could produce a checklist to help folks.  It would also be
nice to make it easier for people to get things right without it.  The
idea of updating the module structure to reflect the bundles we create
is interesting.  I guess if the number of bundles is changing rapidly
then this might be a bit painful.  We could also have the bundles
build on continuum so we find problems earlier.  Having everyone build
the bundles might not be acceptable.


 3) Support OSGi bundles as SCA contributions (application level, how

does

the OSGi import/export relate to the sca-contributions.xml?).

 The other interesting issue is how we deal with the 3rd party jars,

most of

which are not OSGi bundles. To support the case that different Tuscany
extensions may require different versions of the same 3rd party jar, we

need

to figure out a good way to "turn" 3rd party jars into OSGi bundles.



This is a knotty problem.  It's not a new problem and is discussed
here:  https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/23.html

Licensing and signing can prevent us from adding information to the
jars, which leaves us with three options, I think:

1.  Create wrapper bundles which contain the jars, which raises
concerns about disk space.
2.  Use a non-OSGi mechanism to refer to jars outside a bundle
(Equinox allows this).
3.  Devise a new mechanism to create 'virtual bundles' on the fly (see
https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277).



 Unfortunately, the URL requires a log-in. Is it possible to post the
content here?



My apologies, I hadn't realized this was a member bug and therefore
required access (I must have already been logged in when I tested it).
 I can't paste in the details, but I can summarize.  This bug
discusses the requirement raised in the first link.  It discusses the
approach to allow the bundle classpath to reference jars outside the
bundle (the equinox approach), and also considers a 'virtual bundle'
concept (which seems preferred).  There aren't many details about the
latter.





3 might be the best solution longer term, but is the most work.



 Thanks,
 Raymond

 --
 From: "Yang Lei" <[EMAIL PROTECTED]>
 Sent: Tuesday, April 29, 2008 9:09 PM
 To: 
 Subject: Re: Improving support for running in OSGi





I think enabling OSGI can help modularity with a clear definition of
package visibility, so we can have a much cleaner "module"
dependencies through osgi bundle import/export on package.   I think
it will help Tuscany adopters a lot in the scenarios such as: when
implementing new implementation type, binding type

[jira] Updated: (TUSCANY-2284) Update @Property vtest to test un-annotated non-public field

2008-04-30 Thread Gilbert Kwan (JIRA)

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

Gilbert Kwan updated TUSCANY-2284:
--

Attachment: T2284.vtest.patch
T2284-vtest.new.zip

T2284.vtest.patch contains the update 
T2284-vtest.new.zip contains new files

> Update @Property vtest to test un-annotated non-public field
> 
>
> Key: TUSCANY-2284
> URL: https://issues.apache.org/jira/browse/TUSCANY-2284
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
> Attachments: T2284-vtest.new.zip, T2284.vtest.patch
>
>


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



[jira] Issue Comment Edited: (TUSCANY-2284) Update @Property vtest to test un-annotated non-public field

2008-04-30 Thread Gilbert Kwan (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593454#action_12593454
 ] 

gkwan edited comment on TUSCANY-2284 at 4/30/08 3:40 PM:


T2284.vtest.patch contains the update 
T2284-vtest.new.zip contains new files

This fix will address T2210 and T2271

  was (Author: gkwan):
T2284.vtest.patch contains the update 
T2284-vtest.new.zip contains new files
  
> Update @Property vtest to test un-annotated non-public field
> 
>
> Key: TUSCANY-2284
> URL: https://issues.apache.org/jira/browse/TUSCANY-2284
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
> Attachments: T2284-vtest.new.zip, T2284.vtest.patch
>
>


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



Re: [jira] Commented: (TUSCANY-2275) Problem when with Bean[] and null

2008-04-30 Thread Simon Nash

Raymond Feng (JIRA) wrote:
[ https://issues.apache.org/jira/browse/TUSCANY-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593441#action_12593441 ] 


Raymond Feng commented on TUSCANY-2275:
---

Hi,

I debugged the issue and it turned out an interesting case. 


1) When the client side pass 'null' for the service.processBean() method, the 
body of soap message becomes:



It's the wrapper element with empty children.

2) On the receiving side, the empty data get converted into SimpleBean[0] which 
is an empty array of SimpleBean.

3) The user code in SimpleServiceImpl.java only tests if the simpleBean==null and 
it causes an ArrayOutofBoundException. Adding the test of simpleBean.length>0 
fixes the problem and the client runs successfuly.

I would resolve it as a user error. I'm not so sure if we should present the 
data as null or [0]. If you can find any spec covering this corner case, I 
would be happy to revisit it.


I think the marshalled form should be a wrapper containing a Bean
element with xsi:nil="true", not an empty wrapper.  Would this be
unmarshalled as null instead of an empty array?

  Simon


Thanks,
Raymond


Problem when with Bean[] and null
-

Key: TUSCANY-2275
URL: https://issues.apache.org/jira/browse/TUSCANY-2275
Project: Tuscany
 Issue Type: Bug
 Components: Java SCA Data Binding Runtime
   Affects Versions: Java-SCA-1.2
Environment: Tuscnay 1.2-RC4, WAS
   Reporter: Nishant Joshi
   Assignee: Raymond Feng
Fix For: Java-SCA-1.2

Attachments: null problem.zip


I have one service, in which i m passgin Bean[]... If i try to pass null instead then it gives exception 
-

Exception in thread "main" org.osoa.sca.ServiceRuntimeException: Target fault 
type cannot be resolved: null
at 
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:134)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy6.processBean(Unknown Source)
at com.client.Client.processBean(Client.java:22)
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:109)
at 
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at 
org.apache.tuscany.sca.core.invocation.CglibProxyFactory$CglibMethodInterceptor.intercept(CglibProxyFactory.java:149)
at com.client.Client$$EnhancerByCGLIB$$b5aedbbb.processBean()
at com.client.Client.main(Client.java:34)
Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: Array index 
out of range: 0
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:97)
at 
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:78)
... 15 more
Caused by: org.apache.axis2.AxisFault: Array index out of range: 0
at 
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
at 
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
at 
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
at 
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
at 
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:118)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:89)
... 16 more
-
please find the attached sample to reproduce it.
please note that this error was on client side and can be generated using 
attached sample...
same works for servcie having  bean (not an array of bean)





[jira] Created: (TUSCANY-2284) Update @Property vtest to test un-annotated non-public field

2008-04-30 Thread Gilbert Kwan (JIRA)
Update @Property vtest to test un-annotated non-public field


 Key: TUSCANY-2284
 URL: https://issues.apache.org/jira/browse/TUSCANY-2284
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Verification Tests
Affects Versions: Java-SCA-Next
Reporter: Gilbert Kwan




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



[jira] Resolved: (TUSCANY-2275) Problem when with Bean[] and null

2008-04-30 Thread Raymond Feng (JIRA)

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

Raymond Feng resolved TUSCANY-2275.
---

Resolution: Won't Fix

Resolved as a user error.

> Problem when with Bean[] and null
> -
>
> Key: TUSCANY-2275
> URL: https://issues.apache.org/jira/browse/TUSCANY-2275
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.2
> Environment: Tuscnay 1.2-RC4, WAS
>Reporter: Nishant Joshi
>Assignee: Raymond Feng
> Fix For: Java-SCA-1.2
>
> Attachments: null problem.zip
>
>
> I have one service, in which i m passgin Bean[]... If i try to pass null 
> instead then it gives exception 
> -
> Exception in thread "main" org.osoa.sca.ServiceRuntimeException: Target fault 
> type cannot be resolved: null
>   at 
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:134)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at $Proxy6.processBean(Unknown Source)
>   at com.client.Client.processBean(Client.java:22)
>   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:109)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at 
> org.apache.tuscany.sca.core.invocation.CglibProxyFactory$CglibMethodInterceptor.intercept(CglibProxyFactory.java:149)
>   at com.client.Client$$EnhancerByCGLIB$$b5aedbbb.processBean()
>   at com.client.Client.main(Client.java:34)
> Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: Array 
> index out of range: 0
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:97)
>   at 
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:78)
>   ... 15 more
> Caused by: org.apache.axis2.AxisFault: Array index out of range: 0
>   at 
> org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
>   at 
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:118)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:89)
>   ... 16 more
> -
> please find the attached sample to reproduce it.
> please note that this error was on client side and can be generated using 
> attached sample...
> same works for servcie having  bean (not an array of bean)

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



[jira] Commented: (TUSCANY-2275) Problem when with Bean[] and null

2008-04-30 Thread Raymond Feng (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593441#action_12593441
 ] 

Raymond Feng commented on TUSCANY-2275:
---

Hi,

I debugged the issue and it turned out an interesting case. 

1) When the client side pass 'null' for the service.processBean() method, the 
body of soap message becomes:



It's the wrapper element with empty children.

2) On the receiving side, the empty data get converted into SimpleBean[0] which 
is an empty array of SimpleBean.

3) The user code in SimpleServiceImpl.java only tests if the simpleBean==null 
and it causes an ArrayOutofBoundException. Adding the test of 
simpleBean.length>0 fixes the problem and the client runs successfuly.

I would resolve it as a user error. I'm not so sure if we should present the 
data as null or [0]. If you can find any spec covering this corner case, I 
would be happy to revisit it.

Thanks,
Raymond

> Problem when with Bean[] and null
> -
>
> Key: TUSCANY-2275
> URL: https://issues.apache.org/jira/browse/TUSCANY-2275
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.2
> Environment: Tuscnay 1.2-RC4, WAS
>Reporter: Nishant Joshi
>Assignee: Raymond Feng
> Fix For: Java-SCA-1.2
>
> Attachments: null problem.zip
>
>
> I have one service, in which i m passgin Bean[]... If i try to pass null 
> instead then it gives exception 
> -
> Exception in thread "main" org.osoa.sca.ServiceRuntimeException: Target fault 
> type cannot be resolved: null
>   at 
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:134)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at $Proxy6.processBean(Unknown Source)
>   at com.client.Client.processBean(Client.java:22)
>   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:109)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at 
> org.apache.tuscany.sca.core.invocation.CglibProxyFactory$CglibMethodInterceptor.intercept(CglibProxyFactory.java:149)
>   at com.client.Client$$EnhancerByCGLIB$$b5aedbbb.processBean()
>   at com.client.Client.main(Client.java:34)
> Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: Array 
> index out of range: 0
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:97)
>   at 
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:78)
>   ... 15 more
> Caused by: org.apache.axis2.AxisFault: Array index out of range: 0
>   at 
> org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
>   at 
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:118)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:89)
>   ... 16 more
> -
> please find the attached sample to reproduce it.
> please note that this error was on client side and can be generated using 
> attached sample...
> same works for servcie having  bean (not an array of bean)

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



[jira] Created: (TUSCANY-2283) Conversation should end due to non-business exception

2008-04-30 Thread Kevin Williams (JIRA)
Conversation should end due to non-business exception
-

 Key: TUSCANY-2283
 URL: https://issues.apache.org/jira/browse/TUSCANY-2283
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams


The Java APIs and Annotations spec states:

487 A conversation ends, and any state associated with the conversation is 
freed up, when:
...
492 • Any non-business exception is thrown by a conversational operation

This is not happening as illustrated by the vtest:


org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.LifetimeTestCase.lifetime11

It is currently @Ignore(d)

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



Re: Improving support for running in OSGi

2008-04-30 Thread Simon Nash

Graham Charters wrote:

2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:

"Enforcing" the modularity via OSGi is a good way to validate our
modularity/extensibility story in Tuscany. I think we already have a fairly
well organized module structure in Tuscany (from the maven dependency
perspective). To be consistent, should we consider directly mapping our
module structure into OSGi bundles (one bundle per existing Tuscany module)?



I wonder if that might be too fine-grained and unmanageable.
Personally, I'd prefer an approach which took into consideration how
we see folks extending or sub-setting the runtime (e.g. the things
Yang referred to - implementation types, etc.).


I'd prefer not to equate OSGi bundles 1:1 with maven modules.
For me, one of the values we get from this exercise is to explore
what higher-level combinations of individual maven modules
would form meaningful clusters of functionality from a
user/extender/embedder perspective.  If the answer is none,
then we are back to the only units of modularity being the whole
of Tuscany or the individual maven modules.  My intuition is that
we will be able to find some meaningful larger-grained clusters.

  Simon


 There may be different levels for the OSGi enablement.

 1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars can be
consumed as OSGi bundles
 2) Run Tuscany bundles with an OSGi runtime (using OSGi as the
modularization mechanism for the Tuscany runtime, system level)


I think we need this step to occur regularly and frequently to stop
the support decaying.  I've fixed these kinds of issues twice in the
last week, which occur because new modules are added to Tuscany, but
not the OSGi support (not surprising since the OSGi support is outside
the main build).


 3) Support OSGi bundles as SCA contributions (application level, how does
the OSGi import/export relate to the sca-contributions.xml?).

 The other interesting issue is how we deal with the 3rd party jars, most of
which are not OSGi bundles. To support the case that different Tuscany
extensions may require different versions of the same 3rd party jar, we need
to figure out a good way to "turn" 3rd party jars into OSGi bundles.



This is a knotty problem.  It's not a new problem and is discussed
here:  https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/23.html

Licensing and signing can prevent us from adding information to the
jars, which leaves us with three options, I think:

1.  Create wrapper bundles which contain the jars, which raises
concerns about disk space.
2.  Use a non-OSGi mechanism to refer to jars outside a bundle
(Equinox allows this).
3.  Devise a new mechanism to create 'virtual bundles' on the fly (see
https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277).

3 might be the best solution longer term, but is the most work.


 Thanks,
 Raymond

 --
 From: "Yang Lei" <[EMAIL PROTECTED]>
 Sent: Tuesday, April 29, 2008 9:09 PM
 To: 
 Subject: Re: Improving support for running in OSGi





I think enabling OSGI can help modularity with a clear definition of
package visibility, so we can have a much cleaner "module"
dependencies through osgi bundle import/export on package.   I think
it will help Tuscany adopters a lot in the scenarios such as: when
implementing new implementation type, binding type, or data binding
types, there is clear indication which set of packages can be used
(exported API/SPI ). So upgrading to new Tuscany level can be as
simple as plug and play if there is no API/SPI changes, and  version
control (multiple version co-existence) can also be made available
through OSGI capabilities.

Regards,

Yang

On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT)
<[EMAIL PROTECTED]> wrote:


Hi,


I'd like to get people's thoughts on whether the idea of 'promoting'
OSGi is a good one,

IMHO support of OSGi is very important and I glad to see increasing

interest of the community here.

and get ideas on how best to proceed.

I personally have currently not a very deep insight into implementation

details yet, but we are currently prototyping and have there also OSGi
services.

What I could offer today is only to feed our findings about limitations

and rooms for improvement back.

Another important thing which I see on the horizon, is the ongoing

standardization of Distributed OSGi (RFC119) and the benefit to support that
standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to
keep an eye on that as well.

Regards,
Philipp

-Ursprüngliche Nachricht-
Von: Graham Charters [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 28. April 2008 09:48
An: tuscany-dev@ws.apache.org
Betreff: Improving support for running in OSGi


Hi All,

I'd like to get more involved in the OSGi support in Tuscany (both the
modularity work (itest/osgi-tuscany) and the implementation.osgi).  I
recently started looking at the work to run Tuscany in OSGi, embodied
in itest/osgi-tuscany and des

[jira] Issue Comment Edited: (TUSCANY-2271) Java runtime should not inject property into an unannotated non-public field

2008-04-30 Thread Gilbert Kwan (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593429#action_12593429
 ] 

gkwan edited comment on TUSCANY-2271 at 4/30/08 1:59 PM:


Are followings right?
1. protected field and its setter is protected
- there should be no injection.
2. protected/private field but its setter is public
- there should be no injection, too



  was (Author: gkwan):
Are followings right?
1. protected field and its setter is protected
- there should be no injection.
2. protected/private field but its setter is public
- field should be injected.
- there should be no injection, too


  
> Java runtime should not inject property into an unannotated non-public field
> 
>
> Key: TUSCANY-2271
> URL: https://issues.apache.org/jira/browse/TUSCANY-2271
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Verification Tests
>Affects Versions: Java-SCA-1.2
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2271.patch
>
>
> Java Common Annotations and APIs v1.0 - Sec 1.8.13:
> 1349 Properties may also be injected via public setter methods even when the 
> @Property annotation is not
> 1350 present. However, the @Property annotation must be used in order to 
> inject a property onto a non-public
> 1351 field. In the case where there is no @Property annotation, the name of 
> the property is the same as the
> 1352 name of the field or setter.
> Currently the properties are injected into unannotated protected fields too.

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



[jira] Issue Comment Edited: (TUSCANY-2271) Java runtime should not inject property into an unannotated non-public field

2008-04-30 Thread Gilbert Kwan (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593429#action_12593429
 ] 

gkwan edited comment on TUSCANY-2271 at 4/30/08 1:57 PM:


Are followings right?
1. protected field and its setter is protected
- there should be no injection.
2. protected/private field but its setter is public
- field should be injected.
- there should be no injection, too



  was (Author: gkwan):
Are followings right?
1. protected field and its setter is protected
- there should be no injection.
2. protected/private field but its setter is public
- field should be injected.


  
> Java runtime should not inject property into an unannotated non-public field
> 
>
> Key: TUSCANY-2271
> URL: https://issues.apache.org/jira/browse/TUSCANY-2271
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Verification Tests
>Affects Versions: Java-SCA-1.2
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2271.patch
>
>
> Java Common Annotations and APIs v1.0 - Sec 1.8.13:
> 1349 Properties may also be injected via public setter methods even when the 
> @Property annotation is not
> 1350 present. However, the @Property annotation must be used in order to 
> inject a property onto a non-public
> 1351 field. In the case where there is no @Property annotation, the name of 
> the property is the same as the
> 1352 name of the field or setter.
> Currently the properties are injected into unannotated protected fields too.

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



[jira] Commented: (TUSCANY-2271) Java runtime should not inject property into an unannotated non-public field

2008-04-30 Thread Gilbert Kwan (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593429#action_12593429
 ] 

Gilbert Kwan commented on TUSCANY-2271:
---

Are followings right?
1. protected field and its setter is protected
- there should be no injection.
2. protected/private field but its setter is public
- field should be injected.



> Java runtime should not inject property into an unannotated non-public field
> 
>
> Key: TUSCANY-2271
> URL: https://issues.apache.org/jira/browse/TUSCANY-2271
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime, Java SCA Verification Tests
>Affects Versions: Java-SCA-1.2
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2271.patch
>
>
> Java Common Annotations and APIs v1.0 - Sec 1.8.13:
> 1349 Properties may also be injected via public setter methods even when the 
> @Property annotation is not
> 1350 present. However, the @Property annotation must be used in order to 
> inject a property onto a non-public
> 1351 field. In the case where there is no @Property annotation, the name of 
> the property is the same as the
> 1352 name of the field or setter.
> Currently the properties are injected into unannotated protected fields too.

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



Re: Improving support for running in OSGi

2008-04-30 Thread Graham Charters
Hi Raymond, thanks for your comments.  I've added some more below.

Regards, Graham.

2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:
> More comments inline.
>
>  Thanks,
>  Raymond
>  --
>  From: "Graham Charters" <[EMAIL PROTECTED]>
>  Sent: Wednesday, April 30, 2008 9:43 AM
>
>  To: 
>  Subject: Re: Improving support for running in OSGi
>
>
> > 2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:
> >
> > > "Enforcing" the modularity via OSGi is a good way to validate our
> > > modularity/extensibility story in Tuscany. I think we already have a
> fairly
> > > well organized module structure in Tuscany (from the maven dependency
> > > perspective). To be consistent, should we consider directly mapping our
> > > module structure into OSGi bundles (one bundle per existing Tuscany
> module)?
> > >
> > >
> >
> > I wonder if that might be too fine-grained and unmanageable.
> > Personally, I'd prefer an approach which took into consideration how
> > we see folks extending or sub-setting the runtime (e.g. the things
> > Yang referred to - implementation types, etc.).
> >
> >
>
>  IMHO, big bundles lead to defeat modularity and increase coupling. It also
> become difficult to embed subset of the Tuscany runtime. But anyway, we can
> adjust the scheme over time as the picture becomes clearer.
>
>

To a certain extent I agree with you, but there's also a school of
thought that says when adopting OSGi it's best to start with big
modules and then decompose as understanding grows.  I think the
thought processes we go through will ensure we end up with the right
modules that match the requirements, such as runtime subsetting.

>
> >
> > >  There may be different levels for the OSGi enablement.
> > >
> > >  1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars
> can be
> > > consumed as OSGi bundles
> > >  2) Run Tuscany bundles with an OSGi runtime (using OSGi as the
> > > modularization mechanism for the Tuscany runtime, system level)
> > >
> >
> > I think we need this step to occur regularly and frequently to stop
> > the support decaying.  I've fixed these kinds of issues twice in the
> > last week, which occur because new modules are added to Tuscany, but
> > not the OSGi support (not surprising since the OSGi support is outside
> > the main build).
> >
> >
>
>  Is there a checklist we can use to make sure new modules or changes won't
> break the OSGi support? If not, can we produce one and post it to the
> Tuscany wiki?
>
>

I think we could produce a checklist to help folks.  It would also be
nice to make it easier for people to get things right without it.  The
idea of updating the module structure to reflect the bundles we create
is interesting.  I guess if the number of bundles is changing rapidly
then this might be a bit painful.  We could also have the bundles
build on continuum so we find problems earlier.  Having everyone build
the bundles might not be acceptable.

>
> >
> > >  3) Support OSGi bundles as SCA contributions (application level, how
> does
> > > the OSGi import/export relate to the sca-contributions.xml?).
> > >
> > >  The other interesting issue is how we deal with the 3rd party jars,
> most of
> > > which are not OSGi bundles. To support the case that different Tuscany
> > > extensions may require different versions of the same 3rd party jar, we
> need
> > > to figure out a good way to "turn" 3rd party jars into OSGi bundles.
> > >
> > >
> >
> > This is a knotty problem.  It's not a new problem and is discussed
> > here:  https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/23.html
> >
> > Licensing and signing can prevent us from adding information to the
> > jars, which leaves us with three options, I think:
> >
> > 1.  Create wrapper bundles which contain the jars, which raises
> > concerns about disk space.
> > 2.  Use a non-OSGi mechanism to refer to jars outside a bundle
> > (Equinox allows this).
> > 3.  Devise a new mechanism to create 'virtual bundles' on the fly (see
> > https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277).
> >
> >
>
>  Unfortunately, the URL requires a log-in. Is it possible to post the
> content here?
>

My apologies, I hadn't realized this was a member bug and therefore
required access (I must have already been logged in when I tested it).
 I can't paste in the details, but I can summarize.  This bug
discusses the requirement raised in the first link.  It discusses the
approach to allow the bundle classpath to reference jars outside the
bundle (the equinox approach), and also considers a 'virtual bundle'
concept (which seems preferred).  There aren't many details about the
latter.

>
>
>
> > 3 might be the best solution longer term, but is the most work.
> >
> >
> > >  Thanks,
> > >  Raymond
> > >
> > >  --
> > >  From: "Yang Lei" <[EMAIL PROTECTED]>
> > >  Sent: Tuesday, April 29, 2008 9:09 PM
> > >  To: 
> > >  Subject: Re: Improving support for runnin

Re: [GSoC] Next Steps for Students - Apache CLA

2008-04-30 Thread Chris Trezzo

Luciano,

I have submitted my signed CLA, and my name now appears in the  
Unlisted CLAs section [1].


I have downloaded the latest Tuscany release, and I am going through  
the provided samples. I am also attempting a top-down build of  
Tuscany, and generally getting my development environment set up.


I have added a wiki page for the "Map-Reduce support in Tuscany"  
project [2], which follows the same basic templet that Thilina used.


Finally, I am finding the Tuscany Dashboard [3] a helpful resource  
while getting my feet wet.


Congrats to all the new GSOC students, and I look forward to working  
with the Tuscany community.


[1] http://people.apache.org/~jim/committers.html
[2] 
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Map-Reduce+support+for+Apache+Tuscany
[3] http://incubator.apache.org/tuscany/tuscany-dashboard.html

Thanks,
Chris Trezzo


On Apr 29, 2008, at 3:38 PM, Luciano Resende wrote:


The ASF desires that all contributors of ideas, code, or documentation
to the Apache projects complete, sign, and submit (via postal mail,
fax or email) an Individual Contributor License Agreement (CLA). After
some ASF wide discussions, its a common understanding that the
students participating on the GSoC 2008 should sign a CLA.

Please follow the link to Apache Licenses page [1], and look for
"Contributor License Agreements" and follow the instructions to submit
your CLA [2].

Please let us know when your name is listed on "Unlisted CLAs" section
on the committers page [3].


[1] http://www.apache.org/licenses/
[2] http://www.apache.org/licenses/icla.txt
[3] http://people.apache.org/~jim/committers.html

--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/




Re: GSoC Project - CORBA Support for Apache Tuscany

2008-04-30 Thread Raymond Feng
For now, I recommend you to use "mvn clean install -fn" to continue. And 
also please open a JIRA to report the problem you are seeing so that we can 
track and fix it.


Thanks,
Raymond
--
From: "Wojtek Janiszewski" <[EMAIL PROTECTED]>
Sent: Wednesday, April 30, 2008 10:43 AM
To: 
Subject: GSoC Project - CORBA Support for Apache Tuscany


Hi,
Raymond Feng checked in some skeleton code for CORBA services and 
references binding. To start project I've tried to build Tuscany. I've 
followed this document [1], tried to make top-down build with code from 
[2] and got Build Failure while testing "Apache Tuscany SCA XML Assembly 
Model".
I'm using maven 2.0.7, jdk1.5.0_09, Slackware Linux running 2.6.23.12 
kernel.


Tests in error:

testResolveConstrainingType(org.apache.tuscany.sca.assembly.xml.WireTestCase)
  testResolveComposite(org.apache.tuscany.sca.assembly.xml.WireTestCase)

testReadWireWriteComposite(org.apache.tuscany.sca.assembly.xml.WriteAllTestCase)

testPolicyIntentInheritance(org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase)

Exceptions for every test are quite the same:
java.util.MissingResourceException: Can't find 
assembly-validation-messages bundle

at java.util.logging.Logger.setupResourceInfo(Logger.java:1309)
at java.util.logging.Logger.(Logger.java:204)
at java.util.logging.Logger.getLogger(Logger.java:300)
at 
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1.problem(CompositeBuilderImpl.java:89)
at 
org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.warning(BaseConfigurationBuilderImpl.java:297)
at 
org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.indexImplementationPropertiesServicesAndReferences(BaseConfigurationBuilderImpl.java:616)
at 
org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:197)
at 
org.apache.tuscany.sca.assembly.builder.impl.BaseConfigurationBuilderImpl.configureComponents(BaseConfigurationBuilderImpl.java:85)
at 
org.apache.tuscany.sca.assembly.builder.impl.ComponentConfigurationBuilderImpl.build(ComponentConfigurationBuilderImpl.java:47)
at 
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:127)
at 
org.apache.tuscany.sca.assembly.xml.BuildPolicyTestCase.setUp(BuildPolicyTestCase.java:126)

at junit.framework.TestCase.runBare(TestCase.java:132)
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.OldTestClassRunner.run(OldTestClassRunner.java:35)
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:585)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)




[1] - http://incubator.apache.org/tuscany/sca-java-development-guide.html
[2] - http://svn.apache.org/repos/asf/incubator/tuscany/java

I'm asking you for a help, does anyone have idea what I'm doing wrong?

Thanks,
Wojtek 




[jira] Created: (TUSCANY-2282) Poor warning issued when annotating private field with @Callback

2008-04-30 Thread Kevin Williams (JIRA)
Poor warning issued when annotating private field with @Callback


 Key: TUSCANY-2282
 URL: https://issues.apache.org/jira/browse/TUSCANY-2282
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams
Priority: Minor


I inadvertently marked a private field with @Callback and received the 
following warning:

WARNING: Invalid annotation @org.osoa.sca.annotations.Callback(value=class 
java.lang.Void) is found on private 
org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.AServiceCallback 
org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.impl.BServiceImpl.callback

I should have realized sooner what the real problem was (private fields cannot 
be annotated) but a message like:

"WARNING: Invalid annotation @org.osoa.sca.annotations.Callback(value=class 
java.lang.Void) is found on private 
org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.AServiceCallback 
org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.impl.BServiceImpl.callback.
  You must not annotate private fields and if you do then the runtime will 
ignore them and only give you this warning."

I think an exception would be even better since the application will not work 
without the requested injection.






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



componentType interfaces and data transforms

2008-04-30 Thread Scott Kurz
Consider the use case where I start with a .componentType file, e.g.:

http://www.osoa.org/xmlns/sca/1.0";>
  
  http://helloworld#wsdl.interface(HelloWorld)" />
  


And I proceed to write a Java impl with @Service pointing to a Java
interface.

--

Well, this is going to cause problems today.

I'm not precisely sure where in the code... I know it has something to do
with how we build the wire source/target InterfaceContracts in
CompositeActivatorImpl... but somehow the net seems to be that we assume
that if an interface is specified in the .componentType file then
this .componentType interface will describe something physical on the wire.

Now, one could argue that it is correct that the use case I started with is
not supported.I think the words in the OSOA Assembly spec do more to
suggest the
current interpretation than the one I'm suggesting.

But regardless, I'm arguing that the componentType should be treated as more
of a logical description in this case than a physical description.
So in the code I'd say we should be basing the wire source/target interface
contract's on something which is more of a "client/impl InterfaceContract"
than the componentType
InterfaceContract we're using today.

In particular this allows more of an ability to express top-down,
WSDL-centered, interface design via the componentType file.

Scott


[jira] Issue Comment Edited: (TUSCANY-2280) No data transformation for fault types

2008-04-30 Thread Cezary Wisniewski (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593385#action_12593385
 ] 

cez edited comment on TUSCANY-2280 at 4/30/08 10:35 AM:
--

Yes, my interface is remotable (java interface with @Remotable). It's very 
simple scenario. I have two components, both of them are implemented in Java 
and they are communicating over some binding.

The problem does not occur when binding doesn't require data transformation 
(e.g. RMI).

The problem also doesn't occur when using WS binding because in such a case one 
operation (from JavaInterface) has wrapperStyle=false and the other one (from 
WSDLInterface) has wrapperStyle=true. In case wrapperStyle is different 
DataTransformationInterceptor is added to the chain (again see 
isTransformationRequired(Operation source, Operation target) method from 
DataBindingRuntimeWireProcessor)

The problem occurs with my custom binding. Both operations (from JavaInterface 
and MyInterface) have wrapperStyle=false and isTransformationRequired goes a 
little bit further testing input types and output types. However it omits 
faultTypes.

I believe this is a bug because invocation over the binding is different 
depending on the method having at least one parameter or return type or being 
no-arg void method. Once it does data conversion and once it doesn't. (I don't 
want to add dummy parameters or return types to my methods ;-) to force data 
transformation).

I don't know if the problem occurs for any of the existing bindings because I'm 
using my custom binding. And that's why I don't have a separate test case (But 
I still believe it is a bug in DataBindingRuntimeWireProcessor behavior)

  was (Author: cez):
Yes, my interface is remotable (java interface with @Remotable). It's very 
simple scenario. I have two components, both of them are implemented in Java 
and they are communicating over some binding.

The problem does not occur when binding doesn't require data transformation 
(e.g. RMI).

The problem also doesn't occur when using WS binding because in such a case one 
operation (from JavaInterface) has wrapperStyle=false and the other one (from 
WSDLInterface) has wrapperStyle=true. In case wrapperStyle is different 
DataTransformationInterceptor is added to the chain (again see 
isTransformationRequired(Operation source, Operation target) method from 
DataBindingRuntimeWireProcessor)

The problem occurs with my custom binding. Both operations (from JavaInterface 
and MyInterface) have wrapperStyle=false and isTransformationRequired goes a 
little bit further testing input types and output types. However it omits 
faultTypes.

I believe this is a bug because invocation over the binding is different 
depending on the method having at least one parameter or return type or being 
no-arg void method. Once it does data conversion and once it doesn't. (I don't 
want to add dummy parameters or return types to my methods ;-) to force data 
transformation).

I don't know if the problem occurs for any of the existing bindings because I'm 
using my custom binding. And that's why I don't have a separate test case (But 
I still believe it is a bug in DataBindingRuntimeWireProcessor behavior).
  
> No data transformation for fault types
> --
>
> Key: TUSCANY-2280
> URL: https://issues.apache.org/jira/browse/TUSCANY-2280
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.1, Java-SCA-1.2
>Reporter: Cezary Wisniewski
> Fix For: Java-SCA-1.1, Java-SCA-1.2
>
>
> DataTransformationInterceptor is not added to the InvocationChain when method 
> has no parameters and no return type e.g.
> void someMethod() throws MyException
> DataTransformationInterceptor should be added to the chain because the 
> exception has to be transformed. DataTransformationInterceptor is added to 
> the chain and exception is transformed when the method has at least one 
> parameter or return type e.g.
> MyStruct someMethod() throws MyExcpetions
> or
> void someMethod(MyStruct param) throws MyException
> The reason for such behavior is that DataBindingRuntimeWireProcessor only 
> takes care of parameters and return types and ignores fault types (see 
> DataBindingRuntimeWireProcessor.isTransformationRequired(Operation, Operation)

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



[jira] Issue Comment Edited: (TUSCANY-2280) No data transformation for fault types

2008-04-30 Thread Cezary Wisniewski (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593385#action_12593385
 ] 

cez edited comment on TUSCANY-2280 at 4/30/08 10:36 AM:
--

Yes, my interface is remotable (java interface with @Remotable). It's very 
simple scenario. I have two components, both of them are implemented in Java 
and they are communicating over some binding.

The problem does not occur when binding doesn't require data transformation 
(e.g. RMI).

The problem also doesn't occur when using WS binding because in such a case one 
operation (from JavaInterface) has wrapperStyle=false and the other one (from 
WSDLInterface) has wrapperStyle=true. In case wrapperStyle is different 
DataTransformationInterceptor is added to the chain (again see 
isTransformationRequired(Operation source, Operation target) method from 
DataBindingRuntimeWireProcessor)

The problem occurs with my custom binding. Both operations (from JavaInterface 
and MyInterface) have wrapperStyle=false and isTransformationRequired goes a 
little bit further testing input types and output types. However it omits 
faultTypes.

I believe this is a bug because invocation over the binding is different 
depending on the method having at least one parameter or return type or being 
no-arg void method. Once it does data conversion and once it doesn't. (I don't 
want to add dummy parameters or return types to my methods ;-) to force data 
transformation).

I don't know if the problem occurs for any of the existing bindings because I'm 
using my custom binding. And that's why I don't have a separate test case (But 
I still believe it is a bug in DataBindingRuntimeWireProcessor behavior).

Thanks in advance

  was (Author: cez):
Yes, my interface is remotable (java interface with @Remotable). It's very 
simple scenario. I have two components, both of them are implemented in Java 
and they are communicating over some binding.

The problem does not occur when binding doesn't require data transformation 
(e.g. RMI).

The problem also doesn't occur when using WS binding because in such a case one 
operation (from JavaInterface) has wrapperStyle=false and the other one (from 
WSDLInterface) has wrapperStyle=true. In case wrapperStyle is different 
DataTransformationInterceptor is added to the chain (again see 
isTransformationRequired(Operation source, Operation target) method from 
DataBindingRuntimeWireProcessor)

The problem occurs with my custom binding. Both operations (from JavaInterface 
and MyInterface) have wrapperStyle=false and isTransformationRequired goes a 
little bit further testing input types and output types. However it omits 
faultTypes.

I believe this is a bug because invocation over the binding is different 
depending on the method having at least one parameter or return type or being 
no-arg void method. Once it does data conversion and once it doesn't. (I don't 
want to add dummy parameters or return types to my methods ;-) to force data 
transformation).

I don't know if the problem occurs for any of the existing bindings because I'm 
using my custom binding. And that's why I don't have a separate test case (But 
I still believe it is a bug in DataBindingRuntimeWireProcessor behavior)
  
> No data transformation for fault types
> --
>
> Key: TUSCANY-2280
> URL: https://issues.apache.org/jira/browse/TUSCANY-2280
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.1, Java-SCA-1.2
>Reporter: Cezary Wisniewski
> Fix For: Java-SCA-1.1, Java-SCA-1.2
>
>
> DataTransformationInterceptor is not added to the InvocationChain when method 
> has no parameters and no return type e.g.
> void someMethod() throws MyException
> DataTransformationInterceptor should be added to the chain because the 
> exception has to be transformed. DataTransformationInterceptor is added to 
> the chain and exception is transformed when the method has at least one 
> parameter or return type e.g.
> MyStruct someMethod() throws MyExcpetions
> or
> void someMethod(MyStruct param) throws MyException
> The reason for such behavior is that DataBindingRuntimeWireProcessor only 
> takes care of parameters and return types and ignores fault types (see 
> DataBindingRuntimeWireProcessor.isTransformationRequired(Operation, Operation)

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



[jira] Commented: (TUSCANY-2280) No data transformation for fault types

2008-04-30 Thread Cezary Wisniewski (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593385#action_12593385
 ] 

Cezary Wisniewski commented on TUSCANY-2280:


Yes, my interface is remotable (java interface with @Remotable). It's very 
simple scenario. I have two components, both of them are implemented in Java 
and they are communicating over some binding.

The problem does not occur when binding doesn't require data transformation 
(e.g. RMI).

The problem also doesn't occur when using WS binding because in such a case one 
operation (from JavaInterface) has wrapperStyle=false and the other one (from 
WSDLInterface) has wrapperStyle=true. In case wrapperStyle is different 
DataTransformationInterceptor is added to the chain (again see 
isTransformationRequired(Operation source, Operation target) method from 
DataBindingRuntimeWireProcessor)

The problem occurs with my custom binding. Both operations (from JavaInterface 
and MyInterface) have wrapperStyle=false and isTransformationRequired goes a 
little bit further testing input types and output types. However it omits 
faultTypes.

I believe this is a bug because invocation over the binding is different 
depending on the method having at least one parameter or return type or being 
no-arg void method. Once it does data conversion and once it doesn't. (I don't 
want to add dummy parameters or return types to my methods ;-) to force data 
transformation).

I don't know if the problem occurs for any of the existing bindings because I'm 
using my custom binding. And that's why I don't have a separate test case (But 
I still believe it is a bug in DataBindingRuntimeWireProcessor behavior).

> No data transformation for fault types
> --
>
> Key: TUSCANY-2280
> URL: https://issues.apache.org/jira/browse/TUSCANY-2280
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.1, Java-SCA-1.2
>Reporter: Cezary Wisniewski
> Fix For: Java-SCA-1.1, Java-SCA-1.2
>
>
> DataTransformationInterceptor is not added to the InvocationChain when method 
> has no parameters and no return type e.g.
> void someMethod() throws MyException
> DataTransformationInterceptor should be added to the chain because the 
> exception has to be transformed. DataTransformationInterceptor is added to 
> the chain and exception is transformed when the method has at least one 
> parameter or return type e.g.
> MyStruct someMethod() throws MyExcpetions
> or
> void someMethod(MyStruct param) throws MyException
> The reason for such behavior is that DataBindingRuntimeWireProcessor only 
> takes care of parameters and return types and ignores fault types (see 
> DataBindingRuntimeWireProcessor.isTransformationRequired(Operation, Operation)

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



Re: Improving support for running in OSGi

2008-04-30 Thread Raymond Feng

More comments inline.

Thanks,
Raymond
--
From: "Graham Charters" <[EMAIL PROTECTED]>
Sent: Wednesday, April 30, 2008 9:43 AM
To: 
Subject: Re: Improving support for running in OSGi


2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:

"Enforcing" the modularity via OSGi is a good way to validate our
modularity/extensibility story in Tuscany. I think we already have a 
fairly

well organized module structure in Tuscany (from the maven dependency
perspective). To be consistent, should we consider directly mapping our
module structure into OSGi bundles (one bundle per existing Tuscany 
module)?




I wonder if that might be too fine-grained and unmanageable.
Personally, I'd prefer an approach which took into consideration how
we see folks extending or sub-setting the runtime (e.g. the things
Yang referred to - implementation types, etc.).



IMHO, big bundles lead to defeat modularity and increase coupling. It also 
become difficult to embed subset of the Tuscany runtime. But anyway, we can 
adjust the scheme over time as the picture becomes clearer.



 There may be different levels for the OSGi enablement.

 1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars can 
be

consumed as OSGi bundles
 2) Run Tuscany bundles with an OSGi runtime (using OSGi as the
modularization mechanism for the Tuscany runtime, system level)


I think we need this step to occur regularly and frequently to stop
the support decaying.  I've fixed these kinds of issues twice in the
last week, which occur because new modules are added to Tuscany, but
not the OSGi support (not surprising since the OSGi support is outside
the main build).



Is there a checklist we can use to make sure new modules or changes won't 
break the OSGi support? If not, can we produce one and post it to the 
Tuscany wiki?


 3) Support OSGi bundles as SCA contributions (application level, how 
does

the OSGi import/export relate to the sca-contributions.xml?).

 The other interesting issue is how we deal with the 3rd party jars, most 
of

which are not OSGi bundles. To support the case that different Tuscany
extensions may require different versions of the same 3rd party jar, we 
need

to figure out a good way to "turn" 3rd party jars into OSGi bundles.



This is a knotty problem.  It's not a new problem and is discussed
here:  https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/23.html

Licensing and signing can prevent us from adding information to the
jars, which leaves us with three options, I think:

1.  Create wrapper bundles which contain the jars, which raises
concerns about disk space.
2.  Use a non-OSGi mechanism to refer to jars outside a bundle
(Equinox allows this).
3.  Devise a new mechanism to create 'virtual bundles' on the fly (see
https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277).



Unfortunately, the URL requires a log-in. Is it possible to post the content 
here?



3 might be the best solution longer term, but is the most work.


 Thanks,
 Raymond

 --
 From: "Yang Lei" <[EMAIL PROTECTED]>
 Sent: Tuesday, April 29, 2008 9:09 PM
 To: 
 Subject: Re: Improving support for running in OSGi




> I think enabling OSGI can help modularity with a clear definition of
> package visibility, so we can have a much cleaner "module"
> dependencies through osgi bundle import/export on package.   I think
> it will help Tuscany adopters a lot in the scenarios such as: when
> implementing new implementation type, binding type, or data binding
> types, there is clear indication which set of packages can be used
> (exported API/SPI ). So upgrading to new Tuscany level can be as
> simple as plug and play if there is no API/SPI changes, and  version
> control (multiple version co-existence) can also be made available
> through OSGI capabilities.
>
> Regards,
>
> Yang
>
> On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT)
> <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > > I'd like to get people's thoughts on whether the idea of 
> > > 'promoting'

> > > OSGi is a good one,
> > IMHO support of OSGi is very important and I glad to see increasing
interest of the community here.
> >
> > > and get ideas on how best to proceed.
> > I personally have currently not a very deep insight into 
> > implementation

details yet, but we are currently prototyping and have there also OSGi
services.
> > What I could offer today is only to feed our findings about 
> > limitations

and rooms for improvement back.
> > Another important thing which I see on the horizon, is the ongoing
standardization of Distributed OSGi (RFC119) and the benefit to support 
that
standard in Tuscany's OSGi bits. So from mid-term perspective I suggest 
to

keep an eye on that as well.
> >
> > Regards,
> > Philipp
> >
> > -Ursprüngliche Nachricht-
> > Von: Graham Charters [mailto:[EMAIL PROTECTED]
> > Gesendet: Montag, 28. April 2008 09:48
> > An: tuscany-dev@ws.apache.org

[jira] Assigned: (TUSCANY-2275) Problem when with Bean[] and null

2008-04-30 Thread Raymond Feng (JIRA)

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

Raymond Feng reassigned TUSCANY-2275:
-

Assignee: Raymond Feng

> Problem when with Bean[] and null
> -
>
> Key: TUSCANY-2275
> URL: https://issues.apache.org/jira/browse/TUSCANY-2275
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.2
> Environment: Tuscnay 1.2-RC4, WAS
>Reporter: Nishant Joshi
>Assignee: Raymond Feng
> Fix For: Java-SCA-1.2
>
> Attachments: null problem.zip
>
>
> I have one service, in which i m passgin Bean[]... If i try to pass null 
> instead then it gives exception 
> -
> Exception in thread "main" org.osoa.sca.ServiceRuntimeException: Target fault 
> type cannot be resolved: null
>   at 
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:134)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at $Proxy6.processBean(Unknown Source)
>   at com.client.Client.processBean(Client.java:22)
>   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:109)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at 
> org.apache.tuscany.sca.core.invocation.CglibProxyFactory$CglibMethodInterceptor.intercept(CglibProxyFactory.java:149)
>   at com.client.Client$$EnhancerByCGLIB$$b5aedbbb.processBean()
>   at com.client.Client.main(Client.java:34)
> Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: Array 
> index out of range: 0
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:97)
>   at 
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:78)
>   ... 15 more
> Caused by: org.apache.axis2.AxisFault: Array index out of range: 0
>   at 
> org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
>   at 
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
>   at 
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:118)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:89)
>   ... 16 more
> -
> please find the attached sample to reproduce it.
> please note that this error was on client side and can be generated using 
> attached sample...
> same works for servcie having  bean (not an array of bean)

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



[jira] Commented: (TUSCANY-2280) No data transformation for fault types

2008-04-30 Thread Raymond Feng (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593373#action_12593373
 ] 

Raymond Feng commented on TUSCANY-2280:
---

Is your interface a remotable interface? for example, a WSDL portType or a java 
interface with @Remotable annotation. 

Please also attach a test case (I assume you are trying it:-).

Thanks,
Raymond

> No data transformation for fault types
> --
>
> Key: TUSCANY-2280
> URL: https://issues.apache.org/jira/browse/TUSCANY-2280
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.1, Java-SCA-1.2
>Reporter: Cezary Wisniewski
> Fix For: Java-SCA-1.1, Java-SCA-1.2
>
>
> DataTransformationInterceptor is not added to the InvocationChain when method 
> has no parameters and no return type e.g.
> void someMethod() throws MyException
> DataTransformationInterceptor should be added to the chain because the 
> exception has to be transformed. DataTransformationInterceptor is added to 
> the chain and exception is transformed when the method has at least one 
> parameter or return type e.g.
> MyStruct someMethod() throws MyExcpetions
> or
> void someMethod(MyStruct param) throws MyException
> The reason for such behavior is that DataBindingRuntimeWireProcessor only 
> takes care of parameters and return types and ignores fault types (see 
> DataBindingRuntimeWireProcessor.isTransformationRequired(Operation, Operation)

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



Re: Improving support for running in OSGi

2008-04-30 Thread Graham Charters
2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:
> "Enforcing" the modularity via OSGi is a good way to validate our
> modularity/extensibility story in Tuscany. I think we already have a fairly
> well organized module structure in Tuscany (from the maven dependency
> perspective). To be consistent, should we consider directly mapping our
> module structure into OSGi bundles (one bundle per existing Tuscany module)?
>

I wonder if that might be too fine-grained and unmanageable.
Personally, I'd prefer an approach which took into consideration how
we see folks extending or sub-setting the runtime (e.g. the things
Yang referred to - implementation types, etc.).

>  There may be different levels for the OSGi enablement.
>
>  1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars can be
> consumed as OSGi bundles
>  2) Run Tuscany bundles with an OSGi runtime (using OSGi as the
> modularization mechanism for the Tuscany runtime, system level)

I think we need this step to occur regularly and frequently to stop
the support decaying.  I've fixed these kinds of issues twice in the
last week, which occur because new modules are added to Tuscany, but
not the OSGi support (not surprising since the OSGi support is outside
the main build).

>  3) Support OSGi bundles as SCA contributions (application level, how does
> the OSGi import/export relate to the sca-contributions.xml?).
>
>  The other interesting issue is how we deal with the 3rd party jars, most of
> which are not OSGi bundles. To support the case that different Tuscany
> extensions may require different versions of the same 3rd party jar, we need
> to figure out a good way to "turn" 3rd party jars into OSGi bundles.
>

This is a knotty problem.  It's not a new problem and is discussed
here:  https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/23.html

Licensing and signing can prevent us from adding information to the
jars, which leaves us with three options, I think:

1.  Create wrapper bundles which contain the jars, which raises
concerns about disk space.
2.  Use a non-OSGi mechanism to refer to jars outside a bundle
(Equinox allows this).
3.  Devise a new mechanism to create 'virtual bundles' on the fly (see
https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277).

3 might be the best solution longer term, but is the most work.

>  Thanks,
>  Raymond
>
>  --
>  From: "Yang Lei" <[EMAIL PROTECTED]>
>  Sent: Tuesday, April 29, 2008 9:09 PM
>  To: 
>  Subject: Re: Improving support for running in OSGi
>
>
>
>
> > I think enabling OSGI can help modularity with a clear definition of
> > package visibility, so we can have a much cleaner "module"
> > dependencies through osgi bundle import/export on package.   I think
> > it will help Tuscany adopters a lot in the scenarios such as: when
> > implementing new implementation type, binding type, or data binding
> > types, there is clear indication which set of packages can be used
> > (exported API/SPI ). So upgrading to new Tuscany level can be as
> > simple as plug and play if there is no API/SPI changes, and  version
> > control (multiple version co-existence) can also be made available
> > through OSGI capabilities.
> >
> > Regards,
> >
> > Yang
> >
> > On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT)
> > <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > > I'd like to get people's thoughts on whether the idea of 'promoting'
> > > > OSGi is a good one,
> > > IMHO support of OSGi is very important and I glad to see increasing
> interest of the community here.
> > >
> > > > and get ideas on how best to proceed.
> > > I personally have currently not a very deep insight into implementation
> details yet, but we are currently prototyping and have there also OSGi
> services.
> > > What I could offer today is only to feed our findings about limitations
> and rooms for improvement back.
> > > Another important thing which I see on the horizon, is the ongoing
> standardization of Distributed OSGi (RFC119) and the benefit to support that
> standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to
> keep an eye on that as well.
> > >
> > > Regards,
> > > Philipp
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: Graham Charters [mailto:[EMAIL PROTECTED]
> > > Gesendet: Montag, 28. April 2008 09:48
> > > An: tuscany-dev@ws.apache.org
> > > Betreff: Improving support for running in OSGi
> > >
> > >
> > > Hi All,
> > >
> > > I'd like to get more involved in the OSGi support in Tuscany (both the
> > > modularity work (itest/osgi-tuscany) and the implementation.osgi).  I
> > > recently started looking at the work to run Tuscany in OSGi, embodied
> > > in itest/osgi-tuscany and described in the thread entitled
> > > "Classloading in Tuscany".  I've noticed a couple of others on the
> > > list also interested in Tuscany running in OSGi and wondered if it
> > > might be worth considering making this a "first-class" option.  At the
>

Re: Improving support for running in OSGi

2008-04-30 Thread Raymond Feng
"Enforcing" the modularity via OSGi is a good way to validate our 
modularity/extensibility story in Tuscany. I think we already have a fairly 
well organized module structure in Tuscany (from the maven dependency 
perspective). To be consistent, should we consider directly mapping our 
module structure into OSGi bundles (one bundle per existing Tuscany module)?


There may be different levels for the OSGi enablement.

1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars can be 
consumed as OSGi bundles
2) Run Tuscany bundles with an OSGi runtime (using OSGi as the 
modularization mechanism for the Tuscany runtime, system level)
3) Support OSGi bundles as SCA contributions (application level, how does 
the OSGi import/export relate to the sca-contributions.xml?).


The other interesting issue is how we deal with the 3rd party jars, most of 
which are not OSGi bundles. To support the case that different Tuscany 
extensions may require different versions of the same 3rd party jar, we need 
to figure out a good way to "turn" 3rd party jars into OSGi bundles.


Thanks,
Raymond

--
From: "Yang Lei" <[EMAIL PROTECTED]>
Sent: Tuesday, April 29, 2008 9:09 PM
To: 
Subject: Re: Improving support for running in OSGi


I think enabling OSGI can help modularity with a clear definition of
package visibility, so we can have a much cleaner "module"
dependencies through osgi bundle import/export on package.   I think
it will help Tuscany adopters a lot in the scenarios such as: when
implementing new implementation type, binding type, or data binding
types, there is clear indication which set of packages can be used
(exported API/SPI ). So upgrading to new Tuscany level can be as
simple as plug and play if there is no API/SPI changes, and  version
control (multiple version co-existence) can also be made available
through OSGI capabilities.

Regards,

Yang

On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT)
<[EMAIL PROTECTED]> wrote:

Hi,

> I'd like to get people's thoughts on whether the idea of 'promoting'
> OSGi is a good one,
IMHO support of OSGi is very important and I glad to see increasing 
interest of the community here.


> and get ideas on how best to proceed.
I personally have currently not a very deep insight into implementation 
details yet, but we are currently prototyping and have there also OSGi 
services.
What I could offer today is only to feed our findings about limitations 
and rooms for improvement back.
Another important thing which I see on the horizon, is the ongoing 
standardization of Distributed OSGi (RFC119) and the benefit to support 
that standard in Tuscany's OSGi bits. So from mid-term perspective I 
suggest to keep an eye on that as well.


Regards,
Philipp

-Ursprüngliche Nachricht-
Von: Graham Charters [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 28. April 2008 09:48
An: tuscany-dev@ws.apache.org
Betreff: Improving support for running in OSGi


Hi All,

I'd like to get more involved in the OSGi support in Tuscany (both the
modularity work (itest/osgi-tuscany) and the implementation.osgi).  I
recently started looking at the work to run Tuscany in OSGi, embodied
in itest/osgi-tuscany and described in the thread entitled
"Classloading in Tuscany".  I've noticed a couple of others on the
list also interested in Tuscany running in OSGi and wondered if it
might be worth considering making this a "first-class" option.  At the
moment the five bundles are only built by folks who want the OSGi
support and go into the itest/osgi-tuscany directory to create it.
This can result in any problems being discovered late, but also could
create the impression that OSGi is considered a second-class
environment (which I don't believe is the case).

Aside from the obvious benefits to OSGi users in doing this, I think
there's a potential for Tuscany to use the OSGi build as a test-bed
for highlighting and working through modularity issues, which would
also benefit Tuscany in general, not just in an OSGi runtime.

I'd like to get people's thoughts on whether the idea of 'promoting'
OSGi is a good one, and get ideas on how best to proceed.  We could
then start discussing what some of the issues might be (e.g. size of
builds, time to build, etc...).

Regards,

Graham.



Re: Improving support for running in OSGi

2008-04-30 Thread Graham Charters
Irrespective of the versioning question, the current 5 module
breakdown does not go as far as individual implementation types,
binding types and so on.  I'm presuming here that the goal would be to
be able to add/remove/replace things at that level rather than
requiring the entire 'extensions' bundle to be refreshed, for example?

2008/4/30 Simon Nash <[EMAIL PROTECTED]>:
> Yang Lei wrote:
>
> > I think enabling OSGI can help modularity with a clear definition of
> > package visibility, so we can have a much cleaner "module"
> > dependencies through osgi bundle import/export on package.   I think
> > it will help Tuscany adopters a lot in the scenarios such as: when
> > implementing new implementation type, binding type, or data binding
> > types, there is clear indication which set of packages can be used
> > (exported API/SPI ). So upgrading to new Tuscany level can be as
> > simple as plug and play if there is no API/SPI changes, and  version
> > control (multiple version co-existence) can also be made available
> > through OSGI capabilities.
> >
> >
>  +1 for the benefits to modularity.  For versioning, I see the value
>  more in terms of allowing multiple versions of third-party dependencies
>  to coexist, rather than having multiple versions of some parts of
>  Tuscany loaded at the same time.  Are there any scenarios that would
>  require the latter?
>
>   Simon
>
>
>
>
> > Regards,
> >
> > Yang
> >
> > On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT)
> > <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > >
> > > > I'd like to get people's thoughts on whether the idea of 'promoting'
> > > > OSGi is a good one,
> > > >
> > > IMHO support of OSGi is very important and I glad to see increasing
> interest of the community here.
> > >
> > >
> > > > and get ideas on how best to proceed.
> > > >
> > > I personally have currently not a very deep insight into implementation
> details yet, but we are currently prototyping and have there also OSGi
> services.
> > > What I could offer today is only to feed our findings about limitations
> and rooms for improvement back.
> > > Another important thing which I see on the horizon, is the ongoing
> standardization of Distributed OSGi (RFC119) and the benefit to support that
> standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to
> keep an eye on that as well.
> > >
> > > Regards,
> > > Philipp
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: Graham Charters [mailto:[EMAIL PROTECTED]
> > > Gesendet: Montag, 28. April 2008 09:48
> > > An: tuscany-dev@ws.apache.org
> > > Betreff: Improving support for running in OSGi
> > >
> > >
> > > Hi All,
> > >
> > > I'd like to get more involved in the OSGi support in Tuscany (both the
> > > modularity work (itest/osgi-tuscany) and the implementation.osgi).  I
> > > recently started looking at the work to run Tuscany in OSGi, embodied
> > > in itest/osgi-tuscany and described in the thread entitled
> > > "Classloading in Tuscany".  I've noticed a couple of others on the
> > > list also interested in Tuscany running in OSGi and wondered if it
> > > might be worth considering making this a "first-class" option.  At the
> > > moment the five bundles are only built by folks who want the OSGi
> > > support and go into the itest/osgi-tuscany directory to create it.
> > > This can result in any problems being discovered late, but also could
> > > create the impression that OSGi is considered a second-class
> > > environment (which I don't believe is the case).
> > >
> > > Aside from the obvious benefits to OSGi users in doing this, I think
> > > there's a potential for Tuscany to use the OSGi build as a test-bed
> > > for highlighting and working through modularity issues, which would
> > > also benefit Tuscany in general, not just in an OSGi runtime.
> > >
> > > I'd like to get people's thoughts on whether the idea of 'promoting'
> > > OSGi is a good one, and get ideas on how best to proceed.  We could
> > > then start discussing what some of the issues might be (e.g. size of
> > > builds, time to build, etc...).
> > >
> > > Regards,
> > >
> > > Graham.
> > >
> > >
> >
> >
> >
>
>


[CANCELLED] [VOTE] Graduate Apache Tuscany as a Top Level Project

2008-04-30 Thread ant elder
Turns out we're not quite ready yet.

   ...ant

On Wed, Apr 30, 2008 at 5:03 PM, ant elder <[EMAIL PROTECTED]> wrote:

>
>
> On Wed, Apr 30, 2008 at 4:59 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> 
>
> I'm not happy that we would do this over something as important as
> > the technical charter for the project.  I think we need to formally
> > vote as a project on the words we want to take forward to the IPMC.
> > We should be able to restart the vote with this correction and have
> > it complete in time to get the proposal to the board in time for
> > the May board meeting.
> >
> >
> Ok I'll cancel this vote then.
>
>...ant
>
>
>


Re: [VOTE] Graduate Apache Tuscany as a Top Level Project

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 4:59 PM, Simon Nash <[EMAIL PROTECTED]> wrote:



I'm not happy that we would do this over something as important as
> the technical charter for the project.  I think we need to formally
> vote as a project on the words we want to take forward to the IPMC.
> We should be able to restart the vote with this correction and have
> it complete in time to get the proposal to the board in time for
> the May board meeting.
>
>
Ok I'll cancel this vote then.

   ...ant


Re: [VOTE] Graduate Apache Tuscany as a Top Level Project

2008-04-30 Thread Simon Nash

I'm having email problems and I haven't received via email either
the post [1] that I sent earlier today on this VOTE thread, or
Ant's response [2] to my post.

I'd like to respond to what Ant said, and the only way I can
think of to do that is to post my response here.


ant elder wrote:
We've just had 19 votes in favour of this wording so it could be argued that
that now makes this more the "correct" one than that old one :-)

Seriously though, its a good catch but we've had a solid turn out in this
vote so it would be a shame to abandon now and restart. I think it will be
ok to take this as the "we're ready" project vote and then use the updated
words you've just posted when we take it to the IPMC vote. There's often
tinkering with the proposal wording of other poddlings during graduation
votes without a complete restart so i think its fine for us to do that here
too.


I'm not happy that we would do this over something as important as
the technical charter for the project.  I think we need to formally
vote as a project on the words we want to take forward to the IPMC.
We should be able to restart the vote with this correction and have
it complete in time to get the proposal to the board in time for
the May board meeting.

What do other people think about this?

  Simon

[1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200804.mbox/[EMAIL 
PROTECTED]
[2] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200804.mbox/[EMAIL 
PROTECTED]

Simon Nash wrote:

ant elder wrote:
We've done a lot of work since last October. We now have a diverse 
community
of contributors and have demonstrated the ability to attract new 
committers
to create an even more diverse community, we have shown we can do 
releases
based on Apache guidelines, and we have shown we conduct our 
discussions in

public within full view of the community and can resolve disagreements on
the lists. I think we're ready, so please vote on the proposal below to
graduate Tuscany to a TLP.

+1 from me.

   ...ant

X. Establish the Apache Tuscany Project

WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the Foundation's
purpose to establish a Project Management Committee charged with
the creation and maintenance of open-source software that
simplifies the development and deployment of service oriented
applications and provides a managed service-oriented runtime
based on the standards defined by the OASIS OpenCSA group,
for distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Apache Tuscany Project",
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby is
responsible for the creation and maintenance of software
related to Apache Tuscany;
and be it further

RESOLVED, that the office of "Vice President, Apache Tuscany" be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Tuscany Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Tuscany Project; and be it further

RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Tuscany Project:

   - Adriano Crestani 
   - ant elder 
   - Brady Johnson 
   - Frank Budinsky 
   - Ignacio Silva-Lepe 
   - Jean-Sebastien Delfino 
   - kelvin goodson 
   - Luciano Resende 
   - Mark Combellack 
   - Matthieu Riou 
   - Mike Edwards 
   - Paul Fremantle 
   - Pete Robbins 
   - Raymond Feng 
   - Simon Laws 
   - Simon Nash 
   - Venkata Krishnan 

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
be appointed to the office of Vice President, Apache Tuscany, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Tuscany podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Tuscany podling encumbered upon the Apache Incubator
Project are hereafter discharged.


+1 for this graduation proposal.  I have been very enouraged by
the progress we have made over the last few months on increasing
the diversity of our community.

  Simon






Re: Improving support for running in OSGi

2008-04-30 Thread Graham Charters
Hi Philipp, thanks for your comments.  I think any feedback/findings
you have would be very valuable input.  I think the the Distributed
OSGi angle is interesting from the perspective of implementation.osgi.

Regards, Graham.

2008/4/29 Konradi, Philipp (CT) <[EMAIL PROTECTED]>:
> Hi,
>
>
>  > I'd like to get people's thoughts on whether the idea of 'promoting'
>  > OSGi is a good one,
>  IMHO support of OSGi is very important and I glad to see increasing interest 
> of the community here.
>
>
>  > and get ideas on how best to proceed.
>  I personally have currently not a very deep insight into implementation 
> details yet, but we are currently prototyping and have there also OSGi 
> services.
>  What I could offer today is only to feed our findings about limitations and 
> rooms for improvement back.
>  Another important thing which I see on the horizon, is the ongoing 
> standardization of Distributed OSGi (RFC119) and the benefit to support that 
> standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to 
> keep an eye on that as well.
>
>  Regards,
>  Philipp
>
>  -Ursprüngliche Nachricht-
>  Von: Graham Charters [mailto:[EMAIL PROTECTED]
>  Gesendet: Montag, 28. April 2008 09:48
>  An: tuscany-dev@ws.apache.org
>  Betreff: Improving support for running in OSGi
>
>
>
>  Hi All,
>
>  I'd like to get more involved in the OSGi support in Tuscany (both the
>  modularity work (itest/osgi-tuscany) and the implementation.osgi).  I
>  recently started looking at the work to run Tuscany in OSGi, embodied
>  in itest/osgi-tuscany and described in the thread entitled
>  "Classloading in Tuscany".  I've noticed a couple of others on the
>  list also interested in Tuscany running in OSGi and wondered if it
>  might be worth considering making this a "first-class" option.  At the
>  moment the five bundles are only built by folks who want the OSGi
>  support and go into the itest/osgi-tuscany directory to create it.
>  This can result in any problems being discovered late, but also could
>  create the impression that OSGi is considered a second-class
>  environment (which I don't believe is the case).
>
>  Aside from the obvious benefits to OSGi users in doing this, I think
>  there's a potential for Tuscany to use the OSGi build as a test-bed
>  for highlighting and working through modularity issues, which would
>  also benefit Tuscany in general, not just in an OSGi runtime.
>
>  I'd like to get people's thoughts on whether the idea of 'promoting'
>  OSGi is a good one, and get ideas on how best to proceed.  We could
>  then start discussing what some of the issues might be (e.g. size of
>  builds, time to build, etc...).
>
>  Regards,
>
>  Graham.
>


Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread Simon Laws
On Wed, Apr 30, 2008 at 1:52 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Wed, Apr 30, 2008 at 1:38 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> >
> >
> > On Wed, Apr 30, 2008 at 1:25 PM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > On Wed, Apr 30, 2008 at 1:18 PM, Simon Laws <[EMAIL PROTECTED]
> >
> > > wrote:
> > >
> > > > snip
> > > >
> > > > >
> > > > > Cool thats really helpful. Ok so if we can have a Tomcat
> TuscanyHost
> > > > > (i.e.
> > > > > an extension of org.apache.catalina.core.StandardHost not related
> to
> > > > > the
> > > > > Tuscany host stuff)  that will get its addChild method called for
> > > > > each
> > > > > webapp and we can get a File to the root of the webbapp so call
> > > > > nodeFactory.createSCANode with that and treat each webapp as a
> > > > > seperate
> > > > > contribution which seems reasonable. That would give us a node per
> > > > > webapp
> > > > > which i'm not sure is good or bad till theres some answers to the
> > > > > "what is a
> > > > > node" question.
> > > >
> > > >
> > > > sounds ok to me.
> > > >
> > > >
> > > > >
> > > > >
> > > > > How do nodes talk to each other or become part of a bigger domain?
> > > > > Theres
> > > > > nothing in SCANode2Factory.newInstance().createSCANode or
> node.start
> > > > > that
> > > > > mentions anything about any domain?
> > > > >
> > > > >   ...ant
> > > > >
> > > >
> > > > They don't talk to each other, other other than at the application
> > > > level. If you want to have a node read it's configuration from the
> domain
> > > > you can use the
> > > > following factory method.
> > > >
> > > > public abstract SCANode2 createSCANode(String configurationURI);
> > > >
> > > > and provide the URI of the configuration that you want it to read.
> > > > e.g.
> > > >
> > > > node = factory.createSCANode("http://localhost:9990/node-image/NodeA
> > > > ");
> > > >
> > > > This URL is provided by the domain and is tailored specifically to
> > > > provide just the right configuration (the list of composite and
> contribution
> > > > URLs) for the node in question. NodeA in this case.
> > > >
> > > > Simon
> > > >
> > > >
> > > Now I'm lost again :)
> > >
> > > Stepping back a bit, what and how is the domain involved in this? What
> > > does it mean to "have a node read it's configuration from the domain"?
> > >
> > >...ant
> > >
> > >
> > Apologies. I'm probably confusing you here as I don't have a clear
> > picture. Two scenarios.
> >
> > 1 - the one we know and love where the webapp is self contained and runs
> a
> > node (SCADomain in our current host-webapp) to run the composite that it
> > contains.
> >
> > 2 - the distributed domain scenario. The last time we approached this we
> > had the node contacting the domain for endpoint information for those
> > targets that could not be resolved locally. This gave us start up
> problems.
> > This is still the role of the new domain but the way that the node gets
> this
> > information is different now. This is where I too am suggesting that the
> use
> > case is not clear.
> >
> > So if we agree that there are two slightly different scenarios we can
> > investigate them further.
> >
> > Simon
> >
>
> Agreed, here we are talking about that second one right? Or at least
> something different than the first anyway. Something like what we had
> described here - http://apache.markmail.org/message/ttssxoruzpndkado
>
> So  in the (2) above how does the "domain" get configured? In a previous
> email you said "the webapp will have been contributed to the domain for
> processing" is there any code i can look at showing that type of thing
> happening? And then how do you create a node from a configured domain?
>
>   ...ant
>

So there are three scenarios that have come up now

1 - Standalone webapp

2 - Distributed domiain webapp - reference/service connections to/from
components on other servers.
2a - Distributed domiain webapp - reference/service connection to/from
components running within the same container.

I have been considering that 2 and 2a take the same approach.

Looking at the webapp code now associated with node2 is seems that the
webapp servlet host constructs a URL based on

domainURL/nodeName

Where domainURL is configured through a property/environment var
(TUSCANY_DOMAIN) and nodeName is the context path of the webapp.

This URL is then used to call the domain implementation to retrieve the
fully configured composite and contributions that the node needs. In this
case the application that the webapp is going to run doesn't necessarily
need to be delivered with the webapp itself as the result of doing a GET on
domainURL/nodeName is a list of URLs and the running webapp can resolve
these URLs to anywhere. It could of course resolve them locally as well.

So this all seems OK but I'll have to try it out to really understand it.

Simon


Re: Load balancing demo

2008-04-30 Thread Simon Laws
On Wed, Apr 30, 2008 at 3:05 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Wed, Apr 30, 2008 at 2:44 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> > On Wed, Apr 30, 2008 at 2:00 PM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, Apr 30, 2008 at 1:56 PM, Simon Laws <[EMAIL PROTECTED]
> >
> > > wrote:
> > >
> > > 
> > >
> > > However this all fell apart as the
> > > > balancer webapp is based on HTTP redirects and Axis2 doesn't handle
> > > them.
> > > > Had this worked I had a completely Java demo and I could run the
> whole
> > > > thing
> > > > automatically.
> > > >
> > > > So any thoughts on either A) how to automate Apache installs B) a
> > tomcat
> > > > based load balancer.
> > > >
> > > >
> > > How about also C) how to fix Axis2 to handle redirects? Is it some
> > > fundamental problem or just a bug which we could try to fix?
> > >
> > >   ...ant
> > >
> >
> > I didn't consider C) base on this post
> > http://www.mail-archive.com/[EMAIL PROTECTED]/msg33803.html
> >
> > Simon
> >
>
> Ok, and the JIRA that was raised from that is
> http://issues.apache.org/jira/browse/AXIS2-2809. Not sure I agree it
> shouldn't be supported though so it may be worth reopening that. There's
> the
> case when WS-Addressing is not being used, and even if it is then it
> should
> be possible to just update the WSA TO header while processing the
> redirect.
> There's some doc on how to support redirects with the http client that
> axis2
> uses at http://hc.apache.org/httpclient-3.x/redirects.html. Note that CXF
> does support redirects, see the client AutoRedirect option -
> http://cwiki.apache.org/CXF20DOC/client-http-transport.html.
>
> Still, seems like your options A or B may be quicker to get done :)
>
>
>   ...ant
>

You may be right that it's a sensible thing for Axis to do. However my
adoption of the old tomcat balancer webapp and hence the redirect approach
was really a hack to allow me to fire all this up automatically. Had it
worked I would have put a big banner in the README saying don't set your
load balancing up like this and pointing off to how to do it with Apache.
You wouldn't run really load balancing like this. Indeed the balancer webapp
is no longer shipped with tomcat 6. Hence  It's not sensible to chase a
change through Axis just to get a hack to work for us that makes a demo
easier.

As it turns out it the hack doesn't work so we are forced to do it properly
(ish). This is probably better in the long run as we don't have to explain
why people should do as we say and not as we do.

Simon


Re: Load balancing demo

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 2:44 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> On Wed, Apr 30, 2008 at 2:00 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Apr 30, 2008 at 1:56 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > 
> >
> > However this all fell apart as the
> > > balancer webapp is based on HTTP redirects and Axis2 doesn't handle
> > them.
> > > Had this worked I had a completely Java demo and I could run the whole
> > > thing
> > > automatically.
> > >
> > > So any thoughts on either A) how to automate Apache installs B) a
> tomcat
> > > based load balancer.
> > >
> > >
> > How about also C) how to fix Axis2 to handle redirects? Is it some
> > fundamental problem or just a bug which we could try to fix?
> >
> >   ...ant
> >
>
> I didn't consider C) base on this post
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg33803.html
>
> Simon
>

Ok, and the JIRA that was raised from that is
http://issues.apache.org/jira/browse/AXIS2-2809. Not sure I agree it
shouldn't be supported though so it may be worth reopening that. There's the
case when WS-Addressing is not being used, and even if it is then it should
be possible to just update the WSA TO header while processing the redirect.
There's some doc on how to support redirects with the http client that axis2
uses at http://hc.apache.org/httpclient-3.x/redirects.html. Note that CXF
does support redirects, see the client AutoRedirect option -
http://cwiki.apache.org/CXF20DOC/client-http-transport.html.

Still, seems like your options A or B may be quicker to get done :)


   ...ant


Re: Load balancing demo

2008-04-30 Thread Simon Laws
On Wed, Apr 30, 2008 at 2:00 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Wed, Apr 30, 2008 at 1:56 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> 
>
> However this all fell apart as the
> > balancer webapp is based on HTTP redirects and Axis2 doesn't handle
> them.
> > Had this worked I had a completely Java demo and I could run the whole
> > thing
> > automatically.
> >
> > So any thoughts on either A) how to automate Apache installs B) a tomcat
> > based load balancer.
> >
> >
> How about also C) how to fix Axis2 to handle redirects? Is it some
> fundamental problem or just a bug which we could try to fix?
>
>   ...ant
>

I didn't consider C) base on this post
http://www.mail-archive.com/[EMAIL PROTECTED]/msg33803.html

Simon


Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console

2008-04-30 Thread Thilina Buddhika
Hi,
Thanks Luciano for creating that wiki page. It is really easy to work with
confluence wiki. I created a child page[1] and moved my content to it, from
my earlier wiki page. I'll be use this new wiki page from now onwards.

thanks!

best regards,
/ thilina

[1] -
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console

On Tue, Apr 29, 2008 at 9:05 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Hi Thilina
>
>   Thanks for taking the initiative and creating the wiki page. I just
> created a wiki page/section to be used for GSoC 2008 [1], at the
> Tuscany Wiki, maybe you and all other students create child pages and
> use that one.
>
> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/GSoC+2008
>
> On Tue, Apr 29, 2008 at 6:08 AM, Thilina Buddhika <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >  I started working on my project. According to the Google time line[1],
> now
> >  it is the community bonding period. These days I am going through the
> >  documentations again, and getting more familiar with the project. I
> started
> >  a wiki page[2] to  display the current status of the project. I will be
> >  frequently updating that wiki page. I will be using this thread to for
> the
> >  discussions with the community.
> >
> >  thanks!
> >
> >  best regards,
> >  / thilina
> >
> >
> >
> >
> >  [1] -
> http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> >  [2] - http://wiki.apache.org/incubator/ThilinaBuddhika/GSoC2008_status
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>


Re: Load balancing demo

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 1:56 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:



However this all fell apart as the
> balancer webapp is based on HTTP redirects and Axis2 doesn't handle them.
> Had this worked I had a completely Java demo and I could run the whole
> thing
> automatically.
>
> So any thoughts on either A) how to automate Apache installs B) a tomcat
> based load balancer.
>
>
How about also C) how to fix Axis2 to handle redirects? Is it some
fundamental problem or just a bug which we could try to fix?

   ...ant


Load balancing demo

2008-04-30 Thread Simon Laws
I've just committed a load balancing demo I've had knocking around for a bit
[1]. It balances HTTP based service calls across tomcat servers configured
with an SCA enabled webapp. It's a work in progress and there are a couple
of points I need some help with

1 - There are currently manual steps involved in getting it running.

I set it up using the fairly well trodden Apache -> mod_jk -> Tomcat route.
I've automated the creation and configuration of the tomcat instances but
obviously doing the same for Apache is more tricky. Thinking I was being
smart this week I replaced Apace with the old "balancer" webapp from tomcat
5 days and wrote a round robin rule. However this all fell apart as the
balancer webapp is based on HTTP redirects and Axis2 doesn't handle them.
Had this worked I had a completely Java demo and I could run the whole thing
automatically.

So any thoughts on either A) how to automate Apache installs B) a tomcat
based load balancer.

2 - I'm planning to upgrade the app to make it one part of a distributed
domain. In particular I want to demonstrate how to configure the nodes in
the cloud to reference the tomcat cluster generally rather than the
individual node as logically a composite is deployed to a cluster rather
than all the nodes in a cluster. A conversation has started [2] about what a
webapp means in a distributed domain so comments on that thread would be
useful to this exercise also.

Regards

Simon

[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/demos/load-balancing-webapp/
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg31031.html


Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 1:38 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Wed, Apr 30, 2008 at 1:25 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Wed, Apr 30, 2008 at 1:18 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > > snip
> > >
> > > >
> > > > Cool thats really helpful. Ok so if we can have a Tomcat TuscanyHost
> > > > (i.e.
> > > > an extension of org.apache.catalina.core.StandardHost not related to
> > > > the
> > > > Tuscany host stuff)  that will get its addChild method called for
> > > > each
> > > > webapp and we can get a File to the root of the webbapp so call
> > > > nodeFactory.createSCANode with that and treat each webapp as a
> > > > seperate
> > > > contribution which seems reasonable. That would give us a node per
> > > > webapp
> > > > which i'm not sure is good or bad till theres some answers to the
> > > > "what is a
> > > > node" question.
> > >
> > >
> > > sounds ok to me.
> > >
> > >
> > > >
> > > >
> > > > How do nodes talk to each other or become part of a bigger domain?
> > > > Theres
> > > > nothing in SCANode2Factory.newInstance().createSCANode or node.start
> > > > that
> > > > mentions anything about any domain?
> > > >
> > > >   ...ant
> > > >
> > >
> > > They don't talk to each other, other other than at the application
> > > level. If you want to have a node read it's configuration from the domain
> > > you can use the
> > > following factory method.
> > >
> > > public abstract SCANode2 createSCANode(String configurationURI);
> > >
> > > and provide the URI of the configuration that you want it to read.
> > > e.g.
> > >
> > > node = factory.createSCANode("http://localhost:9990/node-image/NodeA
> > > ");
> > >
> > > This URL is provided by the domain and is tailored specifically to
> > > provide just the right configuration (the list of composite and 
> > > contribution
> > > URLs) for the node in question. NodeA in this case.
> > >
> > > Simon
> > >
> > >
> > Now I'm lost again :)
> >
> > Stepping back a bit, what and how is the domain involved in this? What
> > does it mean to "have a node read it's configuration from the domain"?
> >
> >...ant
> >
> >
> Apologies. I'm probably confusing you here as I don't have a clear
> picture. Two scenarios.
>
> 1 - the one we know and love where the webapp is self contained and runs a
> node (SCADomain in our current host-webapp) to run the composite that it
> contains.
>
> 2 - the distributed domain scenario. The last time we approached this we
> had the node contacting the domain for endpoint information for those
> targets that could not be resolved locally. This gave us start up problems.
> This is still the role of the new domain but the way that the node gets this
> information is different now. This is where I too am suggesting that the use
> case is not clear.
>
> So if we agree that there are two slightly different scenarios we can
> investigate them further.
>
> Simon
>

Agreed, here we are talking about that second one right? Or at least
something different than the first anyway. Something like what we had
described here - http://apache.markmail.org/message/ttssxoruzpndkado

So  in the (2) above how does the "domain" get configured? In a previous
email you said "the webapp will have been contributed to the domain for
processing" is there any code i can look at showing that type of thing
happening? And then how do you create a node from a configured domain?

   ...ant


RE: What's next for SCA & BPEL Integration

2008-04-30 Thread Ashwini Kumar Jeksani

Ok mike. I will try to create the test cases for testing the generation of 
component types from the bpel processes.
Could you tell me if there is any standard format/template that you use in 
Tuscany for writing test cases.

Thanks & Regards
Ashwini Kumar Jeksani


-Original Message-
From: Mike Edwards [mailto:[EMAIL PROTECTED]
Sent: Monday, April 28, 2008 8:41 PM
To: tuscany-dev@ws.apache.org
Subject: Re: What's next for SCA & BPEL Integration

Ashwini Kumar Jeksani wrote:
> Hi,
>
> Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we 
> could look into that one as well.
>
> Thanks & Regards
> Ashwini Kumar Jeksani
>
Ashwini,

Which extensions are thinking about?

Currently I am working on code that scans the BPEL process and creates
the SCA component type.  I am handling the extra @service and @reference
parameters, but there are other ones to do with multi-refs and with
properties that I have not looked at.  It is taking time because of the
referenced WSDL files, which need careful scanning to find the
partnerLinkType definitions and the associated PortType definitions.

One BIG thing that you could do to help here is to start building some
testcase BPEL + WSDL files that express these capabilities, that we can
use to test out the code as we add the function.


Yours,  Mike.

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***


Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 1:18 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> snip
>
> >
> > Cool thats really helpful. Ok so if we can have a Tomcat TuscanyHost
> > (i.e.
> > an extension of org.apache.catalina.core.StandardHost not related to the
> > Tuscany host stuff)  that will get its addChild method called for each
> > webapp and we can get a File to the root of the webbapp so call
> > nodeFactory.createSCANode with that and treat each webapp as a seperate
> > contribution which seems reasonable. That would give us a node per
> > webapp
> > which i'm not sure is good or bad till theres some answers to the "what
> > is a
> > node" question.
>
>
> sounds ok to me.
>
>
> >
> >
> > How do nodes talk to each other or become part of a bigger domain?
> > Theres
> > nothing in SCANode2Factory.newInstance().createSCANode or node.start
> > that
> > mentions anything about any domain?
> >
> >   ...ant
> >
>
> They don't talk to each other, other other than at the application level.
> If you want to have a node read it's configuration from the domain you can
> use the
> following factory method.
>
> public abstract SCANode2 createSCANode(String configurationURI);
>
> and provide the URI of the configuration that you want it to read. e.g.
>
> node = factory.createSCANode("http://localhost:9990/node-image/NodeA";);
>
> This URL is provided by the domain and is tailored specifically to provide
> just the right configuration (the list of composite and contribution URLs)
> for the node in question. NodeA in this case.
>
> Simon
>
>
Now I'm lost again :)

Stepping back a bit, what and how is the domain involved in this? What does
it mean to "have a node read it's configuration from the domain"?

   ...ant


[jira] Resolved: (TUSCANY-2278) Atom Binding Extension does not support PUT operations correctly

2008-04-30 Thread Mike Edwards (JIRA)

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

Mike Edwards resolved TUSCANY-2278.
---

Resolution: Fixed

Fixed by an update to AtomBindingUtil in revision 652361

> Atom Binding Extension does not support PUT operations correctly
> 
>
> Key: TUSCANY-2278
> URL: https://issues.apache.org/jira/browse/TUSCANY-2278
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA ATOM Binding Extension
>Affects Versions: Java-SCA-1.2
> Environment: All
>Reporter: Mike Edwards
>Assignee: Mike Edwards
>Priority: Minor
> Fix For: Java-SCA-Next
>
>
> If a PUT operation is made using the Atom binding, the ID parameter for the 
> data element, given by the client, is not passed to the operation of the 
> component which offers the service.
> The fault appears to be on line 76 of AtomBindingUtil class where an ID is 
> calculated but not passed to a suitable variable

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



Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread Simon Laws
snip

>
> Cool thats really helpful. Ok so if we can have a Tomcat TuscanyHost (i.e.
> an extension of org.apache.catalina.core.StandardHost not related to the
> Tuscany host stuff)  that will get its addChild method called for each
> webapp and we can get a File to the root of the webbapp so call
> nodeFactory.createSCANode with that and treat each webapp as a seperate
> contribution which seems reasonable. That would give us a node per webapp
> which i'm not sure is good or bad till theres some answers to the "what is
> a
> node" question.


sounds ok to me.


>
>
> How do nodes talk to each other or become part of a bigger domain? Theres
> nothing in SCANode2Factory.newInstance().createSCANode or node.start that
> mentions anything about any domain?
>
>   ...ant
>

They don't talk to each other, other other than at the application level. If
you want to have a node read it's configuration from the domain you can use
the
following factory method.

public abstract SCANode2 createSCANode(String configurationURI);

and provide the URI of the configuration that you want it to read. e.g.

node = factory.createSCANode("http://localhost:9990/node-image/NodeA";);

This URL is provided by the domain and is tailored specifically to provide
just the right configuration (the list of composite and contribution URLs)
for the node in question. NodeA in this case.

Simon


Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 1:08 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Wed, Apr 30, 2008 at 12:49 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Apr 30, 2008 at 12:00 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > >
> > >
> > > On Wed, Apr 30, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Bring this comment to the dev list:
> > > >
> > > > "The tuscany web app support doesn't use this evolving node
> > > > implementation
> > > > just yet. I don't imagine it would be difficult to plug it in "
> > > >  - http://apache.markmail.org/message/4hvdrcafhapy3kyy
> > > >
> > > > Coincidentally i was having a look at this just the other day after
> > that
> > > > user posted about support for Tomcat with multiple webapps in the
> > same
> > > > SCA
> > > > domain - http://apache.markmail.org/message/ttssxoruzpndkado.
> > > >
> > > > Could you give any pointers at all on where to start with using this
> > > > evolving node implementation like this? Theres no doc and I'm a bit
> > lost
> > > > on
> > > > even which Tuscany modules, samples or tests are current. What I'd
> > like
> > > > to
> > > > do is start exploring the updating of the old runtime-tomcat code to
> > use
> > > > the
> > > > latest domain stuff so that as Tomcat starts up webapps are detected
> > as
> > > > SCA
> > > > contributions and added to a single Tomcat SCA domain. One issue
> > that I
> > > > remember came up last time doing this is that as this happens during
> > > > Tomcat
> > > > startup no http communication can take place so all the
> > registrations of
> > > > contributions with the domain need to be in-vm.
> > > >
> > > >   ...ant
> > > >
> > >
> > > Hi Ant
> > >
> > > Am keen to work with you on this. While svn has been down I've spent
> > time
> > > to resurrect a load balancing demo I have on my local disc (not
> > checked in
> > > yet) and would like to update the webapps I'm using to the lasted
> > domain
> > > code but of course I can't.
> > >
> > > Here's a summary of what I think is current in terms of
> > > domain/node/runtime support (but have to admit that there is an amount
> > of
> > > guessing here).
> > >
> > > sca/distribution/standalone - not sure but think it's redundant -
> > > forerunner of runtime-standalone?
> > > sca/distribution/tomcat - not sure but think it's redundant -
> > forerunner
> > > of runtime-tomcat?
> > > sca/distribution/war - not sure but think it's redundant - forerunner
> > of
> > > runtime-war?
> > > sca/distribution/webapp - not sure but think it's redundant
> > > sca/modules/domain - old domain SPI
> > > sca/modules/domain-api - old domain API
> > > sca/modules/domain-impl - old domain Implementation - has been
> > superseded
> > > by domain-manager
> > > sca/modules/domain-manager - new domain management application -
> > replaces
> > > domain-impl
> > > sca/modules/host-embedded - original single JVM domain implementation
> > -
> > > still used in most samples
> > > sca/modules/host-webapp - original webapp runtime - fires up tuscany
> > based
> > > on web.xml filter
> > > sca/modules/host-webapp-junit - not sure but have a feeling it's
> > something
> > > to do with running itests in different web containers
> > > sca/modules/node - old node SPI
> > > sca/modules/node-api - old node API
> > > sca/modules/node-impl - old node implementation that runs one or more
> > > composites in a single JVM as part of a distributed domain
> > > sca/modules/node2-api - new node API
> > > sca/modules/node2-impl - new node implementation. This node is coded
> > to
> > > read it's configuration as an atom feed from the new domain-manager
> > > sca/modules/node2-launcher - start up a node from the command line
> > > sca/modules/node2-launcher-webapp - had noticed this before - maybe
> > node2
> > > integration with webapps has been looked at. Let's see!
> > > sca/modules/runtime - I think this was the last attempt at providing a
> > > common runtime baseline to be specialized for different environments
> > > sca/modules/runtime-standalone - command line runtime
> > > sca/modules/runtime-tomcat - deep tomcat integration (IIRC)
> > > sca/modules/runtime-war - war rutime
> > > sca/modules/workspace - SPI for some of the machinery required to
> > process
> > > contributions at the domain level. Used by domain-manager
> > > sca/modules/workspace-impl - Implementation of the workspace
> > > sca/modules/workspace-xml - Reading/writing workspace as XML
> > >
> > > So can we get together here and work out what the true picture is and
> > how
> > > to mode modules/runtime* to node2. First things first I'm going to go
> > look
> > > at node2-launcher-webapp.
> > >
> > > I think the start up process for nodes in a webapp will potentially be
> > > easier now as the node is just reading atom feeds and not making soap
> > calls.
> > > Time will tell!
> > >
> > > Simon
> > >
> >
> > One more question - what is a node?
> >
> > May seem like a silly question but i'm 

Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread Simon Laws
On Wed, Apr 30, 2008 at 12:49 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Wed, Apr 30, 2008 at 12:00 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> >
> >
> > On Wed, Apr 30, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > > Bring this comment to the dev list:
> > >
> > > "The tuscany web app support doesn't use this evolving node
> > > implementation
> > > just yet. I don't imagine it would be difficult to plug it in "
> > >  - http://apache.markmail.org/message/4hvdrcafhapy3kyy
> > >
> > > Coincidentally i was having a look at this just the other day after
> that
> > > user posted about support for Tomcat with multiple webapps in the same
> > > SCA
> > > domain - http://apache.markmail.org/message/ttssxoruzpndkado.
> > >
> > > Could you give any pointers at all on where to start with using this
> > > evolving node implementation like this? Theres no doc and I'm a bit
> lost
> > > on
> > > even which Tuscany modules, samples or tests are current. What I'd
> like
> > > to
> > > do is start exploring the updating of the old runtime-tomcat code to
> use
> > > the
> > > latest domain stuff so that as Tomcat starts up webapps are detected
> as
> > > SCA
> > > contributions and added to a single Tomcat SCA domain. One issue that
> I
> > > remember came up last time doing this is that as this happens during
> > > Tomcat
> > > startup no http communication can take place so all the registrations
> of
> > > contributions with the domain need to be in-vm.
> > >
> > >   ...ant
> > >
> >
> > Hi Ant
> >
> > Am keen to work with you on this. While svn has been down I've spent
> time
> > to resurrect a load balancing demo I have on my local disc (not checked
> in
> > yet) and would like to update the webapps I'm using to the lasted domain
> > code but of course I can't.
> >
> > Here's a summary of what I think is current in terms of
> > domain/node/runtime support (but have to admit that there is an amount
> of
> > guessing here).
> >
> > sca/distribution/standalone - not sure but think it's redundant -
> > forerunner of runtime-standalone?
> > sca/distribution/tomcat - not sure but think it's redundant - forerunner
> > of runtime-tomcat?
> > sca/distribution/war - not sure but think it's redundant - forerunner of
> > runtime-war?
> > sca/distribution/webapp - not sure but think it's redundant
> > sca/modules/domain - old domain SPI
> > sca/modules/domain-api - old domain API
> > sca/modules/domain-impl - old domain Implementation - has been
> superseded
> > by domain-manager
> > sca/modules/domain-manager - new domain management application -
> replaces
> > domain-impl
> > sca/modules/host-embedded - original single JVM domain implementation -
> > still used in most samples
> > sca/modules/host-webapp - original webapp runtime - fires up tuscany
> based
> > on web.xml filter
> > sca/modules/host-webapp-junit - not sure but have a feeling it's
> something
> > to do with running itests in different web containers
> > sca/modules/node - old node SPI
> > sca/modules/node-api - old node API
> > sca/modules/node-impl - old node implementation that runs one or more
> > composites in a single JVM as part of a distributed domain
> > sca/modules/node2-api - new node API
> > sca/modules/node2-impl - new node implementation. This node is coded to
> > read it's configuration as an atom feed from the new domain-manager
> > sca/modules/node2-launcher - start up a node from the command line
> > sca/modules/node2-launcher-webapp - had noticed this before - maybe
> node2
> > integration with webapps has been looked at. Let's see!
> > sca/modules/runtime - I think this was the last attempt at providing a
> > common runtime baseline to be specialized for different environments
> > sca/modules/runtime-standalone - command line runtime
> > sca/modules/runtime-tomcat - deep tomcat integration (IIRC)
> > sca/modules/runtime-war - war rutime
> > sca/modules/workspace - SPI for some of the machinery required to
> process
> > contributions at the domain level. Used by domain-manager
> > sca/modules/workspace-impl - Implementation of the workspace
> > sca/modules/workspace-xml - Reading/writing workspace as XML
> >
> > So can we get together here and work out what the true picture is and
> how
> > to mode modules/runtime* to node2. First things first I'm going to go
> look
> > at node2-launcher-webapp.
> >
> > I think the start up process for nodes in a webapp will potentially be
> > easier now as the node is just reading atom feeds and not making soap
> calls.
> > Time will tell!
> >
> > Simon
> >
>
> One more question - what is a node?
>
> May seem like a silly question but i'm not sure there's ever been much
> consensus on a clear definition. Is it something for running a single
> composite, or a single contribution, or a collection of related
> contributions? How many nodes would there be on a Tomcat instance doing
> what
> that user has posted about, one per webapp, one per Tomcat instance?
>
>   ...ant
>

I don't t

Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 12:52 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Wed, Apr 30, 2008 at 12:40 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Wed, Apr 30, 2008 at 12:00 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > >
> > >
> > > On Wed, Apr 30, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Bring this comment to the dev list:
> > > >
> > > > "The tuscany web app support doesn't use this evolving node
> > > > implementation
> > > > just yet. I don't imagine it would be difficult to plug it in "
> > > >  - http://apache.markmail.org/message/4hvdrcafhapy3kyy
> > > >
> > > > Coincidentally i was having a look at this just the other day after
> > > > that
> > > > user posted about support for Tomcat with multiple webapps in the
> > > > same SCA
> > > > domain - http://apache.markmail.org/message/ttssxoruzpndkado.
> > > >
> > > > Could you give any pointers at all on where to start with using this
> > > > evolving node implementation like this? Theres no doc and I'm a bit
> > > > lost on
> > > > even which Tuscany modules, samples or tests are current. What I'd
> > > > like to
> > > > do is start exploring the updating of the old runtime-tomcat code to
> > > > use the
> > > > latest domain stuff so that as Tomcat starts up webapps are detected
> > > > as SCA
> > > > contributions and added to a single Tomcat SCA domain. One issue
> > > > that I
> > > > remember came up last time doing this is that as this happens during
> > > > Tomcat
> > > > startup no http communication can take place so all the
> > > > registrations of
> > > > contributions with the domain need to be in-vm.
> > > >
> > > >   ...ant
> > > >
> > >
> > > Hi Ant
> > >
> > > Am keen to work with you on this. While svn has been down I've spent
> > > time to resurrect a load balancing demo I have on my local disc (not 
> > > checked
> > > in yet) and would like to update the webapps I'm using to the lasted 
> > > domain
> > > code but of course I can't.
> > >
> > > Here's a summary of what I think is current in terms of
> > > domain/node/runtime support (but have to admit that there is an amount of
> > > guessing here).
> > >
> > > sca/distribution/standalone - not sure but think it's redundant -
> > > forerunner of runtime-standalone?
> > > sca/distribution/tomcat - not sure but think it's redundant -
> > > forerunner of runtime-tomcat?
> > > sca/distribution/war - not sure but think it's redundant - forerunner
> > > of runtime-war?
> > > sca/distribution/webapp - not sure but think it's redundant
> > > sca/modules/domain - old domain SPI
> > > sca/modules/domain-api - old domain API
> > > sca/modules/domain-impl - old domain Implementation - has been
> > > superseded by domain-manager
> > > sca/modules/domain-manager - new domain management application -
> > > replaces domain-impl
> > > sca/modules/host-embedded - original single JVM domain implementation
> > > - still used in most samples
> > > sca/modules/host-webapp - original webapp runtime - fires up tuscany
> > > based on web.xml filter
> > > sca/modules/host-webapp-junit - not sure but have a feeling it's
> > > something to do with running itests in different web containers
> > > sca/modules/node - old node SPI
> > > sca/modules/node-api - old node API
> > > sca/modules/node-impl - old node implementation that runs one or more
> > > composites in a single JVM as part of a distributed domain
> > > sca/modules/node2-api - new node API
> > > sca/modules/node2-impl - new node implementation. This node is coded
> > > to read it's configuration as an atom feed from the new domain-manager
> > > sca/modules/node2-launcher - start up a node from the command line
> > > sca/modules/node2-launcher-webapp - had noticed this before - maybe
> > > node2 integration with webapps has been looked at. Let's see!
> > > sca/modules/runtime - I think this was the last attempt at providing a
> > > common runtime baseline to be specialized for different environments
> > > sca/modules/runtime-standalone - command line runtime
> > > sca/modules/runtime-tomcat - deep tomcat integration (IIRC)
> > > sca/modules/runtime-war - war rutime
> > > sca/modules/workspace - SPI for some of the machinery required to
> > > process contributions at the domain level. Used by domain-manager
> > > sca/modules/workspace-impl - Implementation of the workspace
> > > sca/modules/workspace-xml - Reading/writing workspace as XML
> > >
> > > So can we get together here and work out what the true picture is and
> > > how to mode modules/runtime* to node2. First things first I'm going to go
> > > look at node2-launcher-webapp.
> > >
> > > I think the start up process for nodes in a webapp will potentially be
> > > easier now as the node is just reading atom feeds and not making soap 
> > > calls.
> > > Time will tell!
> > >
> > > Simon
> > >
> >
> > Great, working together would be good and i'm sure make getting
> > somewhere useful happen much quicker :)
> >
> > Thanks for 

Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 12:00 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Wed, Apr 30, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > Bring this comment to the dev list:
> >
> > "The tuscany web app support doesn't use this evolving node
> > implementation
> > just yet. I don't imagine it would be difficult to plug it in "
> >  - http://apache.markmail.org/message/4hvdrcafhapy3kyy
> >
> > Coincidentally i was having a look at this just the other day after that
> > user posted about support for Tomcat with multiple webapps in the same
> > SCA
> > domain - http://apache.markmail.org/message/ttssxoruzpndkado.
> >
> > Could you give any pointers at all on where to start with using this
> > evolving node implementation like this? Theres no doc and I'm a bit lost
> > on
> > even which Tuscany modules, samples or tests are current. What I'd like
> > to
> > do is start exploring the updating of the old runtime-tomcat code to use
> > the
> > latest domain stuff so that as Tomcat starts up webapps are detected as
> > SCA
> > contributions and added to a single Tomcat SCA domain. One issue that I
> > remember came up last time doing this is that as this happens during
> > Tomcat
> > startup no http communication can take place so all the registrations of
> > contributions with the domain need to be in-vm.
> >
> >   ...ant
> >
>
> Hi Ant
>
> Am keen to work with you on this. While svn has been down I've spent time
> to resurrect a load balancing demo I have on my local disc (not checked in
> yet) and would like to update the webapps I'm using to the lasted domain
> code but of course I can't.
>
> Here's a summary of what I think is current in terms of
> domain/node/runtime support (but have to admit that there is an amount of
> guessing here).
>
> sca/distribution/standalone - not sure but think it's redundant -
> forerunner of runtime-standalone?
> sca/distribution/tomcat - not sure but think it's redundant - forerunner
> of runtime-tomcat?
> sca/distribution/war - not sure but think it's redundant - forerunner of
> runtime-war?
> sca/distribution/webapp - not sure but think it's redundant
> sca/modules/domain - old domain SPI
> sca/modules/domain-api - old domain API
> sca/modules/domain-impl - old domain Implementation - has been superseded
> by domain-manager
> sca/modules/domain-manager - new domain management application - replaces
> domain-impl
> sca/modules/host-embedded - original single JVM domain implementation -
> still used in most samples
> sca/modules/host-webapp - original webapp runtime - fires up tuscany based
> on web.xml filter
> sca/modules/host-webapp-junit - not sure but have a feeling it's something
> to do with running itests in different web containers
> sca/modules/node - old node SPI
> sca/modules/node-api - old node API
> sca/modules/node-impl - old node implementation that runs one or more
> composites in a single JVM as part of a distributed domain
> sca/modules/node2-api - new node API
> sca/modules/node2-impl - new node implementation. This node is coded to
> read it's configuration as an atom feed from the new domain-manager
> sca/modules/node2-launcher - start up a node from the command line
> sca/modules/node2-launcher-webapp - had noticed this before - maybe node2
> integration with webapps has been looked at. Let's see!
> sca/modules/runtime - I think this was the last attempt at providing a
> common runtime baseline to be specialized for different environments
> sca/modules/runtime-standalone - command line runtime
> sca/modules/runtime-tomcat - deep tomcat integration (IIRC)
> sca/modules/runtime-war - war rutime
> sca/modules/workspace - SPI for some of the machinery required to process
> contributions at the domain level. Used by domain-manager
> sca/modules/workspace-impl - Implementation of the workspace
> sca/modules/workspace-xml - Reading/writing workspace as XML
>
> So can we get together here and work out what the true picture is and how
> to mode modules/runtime* to node2. First things first I'm going to go look
> at node2-launcher-webapp.
>
> I think the start up process for nodes in a webapp will potentially be
> easier now as the node is just reading atom feeds and not making soap calls.
> Time will tell!
>
> Simon
>

One more question - what is a node?

May seem like a silly question but i'm not sure there's ever been much
consensus on a clear definition. Is it something for running a single
composite, or a single contribution, or a collection of related
contributions? How many nodes would there be on a Tomcat instance doing what
that user has posted about, one per webapp, one per Tomcat instance?

   ...ant


Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread Simon Laws
On Wed, Apr 30, 2008 at 12:00 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Wed, Apr 30, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > Bring this comment to the dev list:
> >
> > "The tuscany web app support doesn't use this evolving node
> > implementation
> > just yet. I don't imagine it would be difficult to plug it in "
> >  - http://apache.markmail.org/message/4hvdrcafhapy3kyy
> >
> > Coincidentally i was having a look at this just the other day after that
> > user posted about support for Tomcat with multiple webapps in the same
> > SCA
> > domain - http://apache.markmail.org/message/ttssxoruzpndkado.
> >
> > Could you give any pointers at all on where to start with using this
> > evolving node implementation like this? Theres no doc and I'm a bit lost
> > on
> > even which Tuscany modules, samples or tests are current. What I'd like
> > to
> > do is start exploring the updating of the old runtime-tomcat code to use
> > the
> > latest domain stuff so that as Tomcat starts up webapps are detected as
> > SCA
> > contributions and added to a single Tomcat SCA domain. One issue that I
> > remember came up last time doing this is that as this happens during
> > Tomcat
> > startup no http communication can take place so all the registrations of
> > contributions with the domain need to be in-vm.
> >
> >   ...ant
> >
>
> Hi Ant
>
> Am keen to work with you on this. While svn has been down I've spent time
> to resurrect a load balancing demo I have on my local disc (not checked in
> yet) and would like to update the webapps I'm using to the lasted domain
> code but of course I can't.
>
> Here's a summary of what I think is current in terms of
> domain/node/runtime support (but have to admit that there is an amount of
> guessing here).
>
> sca/distribution/standalone - not sure but think it's redundant -
> forerunner of runtime-standalone?
> sca/distribution/tomcat - not sure but think it's redundant - forerunner
> of runtime-tomcat?
> sca/distribution/war - not sure but think it's redundant - forerunner of
> runtime-war?
> sca/distribution/webapp - not sure but think it's redundant
> sca/modules/domain - old domain SPI
> sca/modules/domain-api - old domain API
> sca/modules/domain-impl - old domain Implementation - has been superseded
> by domain-manager
> sca/modules/domain-manager - new domain management application - replaces
> domain-impl
> sca/modules/host-embedded - original single JVM domain implementation -
> still used in most samples
> sca/modules/host-webapp - original webapp runtime - fires up tuscany based
> on web.xml filter
> sca/modules/host-webapp-junit - not sure but have a feeling it's something
> to do with running itests in different web containers
> sca/modules/node - old node SPI
> sca/modules/node-api - old node API
> sca/modules/node-impl - old node implementation that runs one or more
> composites in a single JVM as part of a distributed domain
> sca/modules/node2-api - new node API
> sca/modules/node2-impl - new node implementation. This node is coded to
> read it's configuration as an atom feed from the new domain-manager
> sca/modules/node2-launcher - start up a node from the command line
> sca/modules/node2-launcher-webapp - had noticed this before - maybe node2
> integration with webapps has been looked at. Let's see!
> sca/modules/runtime - I think this was the last attempt at providing a
> common runtime baseline to be specialized for different environments
> sca/modules/runtime-standalone - command line runtime
> sca/modules/runtime-tomcat - deep tomcat integration (IIRC)
> sca/modules/runtime-war - war rutime
> sca/modules/workspace - SPI for some of the machinery required to process
> contributions at the domain level. Used by domain-manager
> sca/modules/workspace-impl - Implementation of the workspace
> sca/modules/workspace-xml - Reading/writing workspace as XML
>
> So can we get together here and work out what the true picture is and how
> to mode modules/runtime* to node2. First things first I'm going to go look
> at node2-launcher-webapp.
>
> I think the start up process for nodes in a webapp will potentially be
> easier now as the node is just reading atom feeds and not making soap calls.
> Time will tell!
>
> Simon
>

A couple more to add to the list...

sca/modules/implementation-node - a model of a node in the distributed
domain, assigns a composite to the node and provides default binding details
sca/modules/implementation-node-xml - readers/writers for the model
sca/modules/implementation-node-runtime - some launchers and some web app
stuff in here also
sca/samples/calculator-distributed - a basic sample that uses the new
domain/node code
sca/tutorial/* - a multi composite store application that uses the new
domain/node code

Simon


Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 12:00 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Wed, Apr 30, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > Bring this comment to the dev list:
> >
> > "The tuscany web app support doesn't use this evolving node
> > implementation
> > just yet. I don't imagine it would be difficult to plug it in "
> >  - http://apache.markmail.org/message/4hvdrcafhapy3kyy
> >
> > Coincidentally i was having a look at this just the other day after that
> > user posted about support for Tomcat with multiple webapps in the same
> > SCA
> > domain - http://apache.markmail.org/message/ttssxoruzpndkado.
> >
> > Could you give any pointers at all on where to start with using this
> > evolving node implementation like this? Theres no doc and I'm a bit lost
> > on
> > even which Tuscany modules, samples or tests are current. What I'd like
> > to
> > do is start exploring the updating of the old runtime-tomcat code to use
> > the
> > latest domain stuff so that as Tomcat starts up webapps are detected as
> > SCA
> > contributions and added to a single Tomcat SCA domain. One issue that I
> > remember came up last time doing this is that as this happens during
> > Tomcat
> > startup no http communication can take place so all the registrations of
> > contributions with the domain need to be in-vm.
> >
> >   ...ant
> >
>
> Hi Ant
>
> Am keen to work with you on this. While svn has been down I've spent time
> to resurrect a load balancing demo I have on my local disc (not checked in
> yet) and would like to update the webapps I'm using to the lasted domain
> code but of course I can't.
>
> Here's a summary of what I think is current in terms of
> domain/node/runtime support (but have to admit that there is an amount of
> guessing here).
>
> sca/distribution/standalone - not sure but think it's redundant -
> forerunner of runtime-standalone?
> sca/distribution/tomcat - not sure but think it's redundant - forerunner
> of runtime-tomcat?
> sca/distribution/war - not sure but think it's redundant - forerunner of
> runtime-war?
> sca/distribution/webapp - not sure but think it's redundant
> sca/modules/domain - old domain SPI
> sca/modules/domain-api - old domain API
> sca/modules/domain-impl - old domain Implementation - has been superseded
> by domain-manager
> sca/modules/domain-manager - new domain management application - replaces
> domain-impl
> sca/modules/host-embedded - original single JVM domain implementation -
> still used in most samples
> sca/modules/host-webapp - original webapp runtime - fires up tuscany based
> on web.xml filter
> sca/modules/host-webapp-junit - not sure but have a feeling it's something
> to do with running itests in different web containers
> sca/modules/node - old node SPI
> sca/modules/node-api - old node API
> sca/modules/node-impl - old node implementation that runs one or more
> composites in a single JVM as part of a distributed domain
> sca/modules/node2-api - new node API
> sca/modules/node2-impl - new node implementation. This node is coded to
> read it's configuration as an atom feed from the new domain-manager
> sca/modules/node2-launcher - start up a node from the command line
> sca/modules/node2-launcher-webapp - had noticed this before - maybe node2
> integration with webapps has been looked at. Let's see!
> sca/modules/runtime - I think this was the last attempt at providing a
> common runtime baseline to be specialized for different environments
> sca/modules/runtime-standalone - command line runtime
> sca/modules/runtime-tomcat - deep tomcat integration (IIRC)
> sca/modules/runtime-war - war rutime
> sca/modules/workspace - SPI for some of the machinery required to process
> contributions at the domain level. Used by domain-manager
> sca/modules/workspace-impl - Implementation of the workspace
> sca/modules/workspace-xml - Reading/writing workspace as XML
>
> So can we get together here and work out what the true picture is and how
> to mode modules/runtime* to node2. First things first I'm going to go look
> at node2-launcher-webapp.
>
> I think the start up process for nodes in a webapp will potentially be
> easier now as the node is just reading atom feeds and not making soap calls.
> Time will tell!
>
> Simon
>

Great, working together would be good and i'm sure make getting somewhere
useful happen much quicker :)

Thanks for the list of module statuses thats helpful, i'll also go look the
node2-launcher-webapp one.

The comment on the use of atom feeds is interesting. To be honest i'd hope
we could have a way to avoid that being needed in this Tomcat use case, or
at least being optional. One issue we had last time when we tried to do this
was that there had to be a separate standalone "domain manager" running
before you could start up a Tomcat instance, and that sucks quite a bit IMHO
so i'd like to try to get a design from the beginning where its not needed.
This will all be happening in a single JVM and with the code bootstrapp

Re: [VOTE] Graduate Apache Tuscany as a Top Level Project

2008-04-30 Thread ant elder
On Wed, Apr 30, 2008 at 11:37 AM, Simon Nash <[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
> > We've done a lot of work since last October. We now have a diverse
> > community
> > of contributors and have demonstrated the ability to attract new
> > committers
> > to create an even more diverse community, we have shown we can do
> > releases
> > based on Apache guidelines, and we have shown we conduct our discussions
> > in
> > public within full view of the community and can resolve disagreements
> > on
> > the lists. I think we're ready, so please vote on the proposal below to
> > graduate Tuscany to a TLP.
> >
> > +1 from me.
> >
> >   ...ant
> >
> > X. Establish the Apache Tuscany Project
> >
> > WHEREAS, the Board of Directors deems it to be in the best
> > interests of the Foundation and consistent with the Foundation's
> > purpose to establish a Project Management Committee charged with
> > the creation and maintenance of open-source software that
> > simplifies the development and deployment of service oriented
> > applications and provides a managed service-oriented runtime
> > based on the standards defined by the OASIS OpenCSA group,
> > for distribution at no charge to the public.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > Committee (PMC), to be known as the "Apache Tuscany Project",
> > be and hereby is established pursuant to Bylaws of the
> > Foundation; and be it further
> >
> > RESOLVED, that the Apache Tuscany Project be and hereby is
> > responsible for the creation and maintenance of software
> > related to Apache Tuscany;
> > and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache Tuscany" be
> > and hereby is created, the person holding such office to
> > serve at the direction of the Board of Directors as the chair
> > of the Apache Tuscany Project, and to have primary responsibility
> > for management of the projects within the scope of
> > responsibility of the Apache Tuscany Project; and be it further
> >
> > RESOLVED, that the persons listed immediately below be and
> > hereby are appointed to serve as the initial members of the
> > Apache Tuscany Project:
> >
> >   - Adriano Crestani 
> >   - ant elder 
> >   - Brady Johnson 
> >   - Frank Budinsky 
> >   - Ignacio Silva-Lepe 
> >   - Jean-Sebastien Delfino 
> >   - kelvin goodson 
> >   - Luciano Resende 
> >   - Mark Combellack 
> >   - Matthieu Riou 
> >   - Mike Edwards 
> >   - Paul Fremantle 
> >   - Pete Robbins 
> >   - Raymond Feng 
> >   - Simon Laws 
> >   - Simon Nash 
> >   - Venkata Krishnan 
> >
> >  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
> > be appointed to the office of Vice President, Apache Tuscany, to
> > serve in accordance with and subject to the direction of the
> > Board of Directors and the Bylaws of the Foundation until
> > death, resignation, retirement, removal or disqualification,
> > or until a successor is appointed; and be it further
> >
> > RESOLVED, that the Apache Tuscany Project be and hereby
> > is tasked with the migration and rationalization of the Apache
> > Incubator Tuscany podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache
> > Incubator Tuscany podling encumbered upon the Apache Incubator
> > Project are hereafter discharged.
> >
> >  My sincere apologies.  This version of the charter is not correct,
> and I failed to notice the problem when casting my +1 vote.
>
> The first paragraph says:
>  WHEREAS, the Board of Directors deems it to be in the best
>  interests of the Foundation and consistent with the Foundation's
>  purpose to establish a Project Management Committee charged with
>  the creation and maintenance of open-source software that
>  simplifies the development and deployment of service oriented
>  applications and provides a managed service-oriented runtime
>  based on the standards defined by the OASIS OpenCSA group,
>  for distribution at no charge to the public.
>
> In our most recent vote (see [1]) on the wording of this paragraph,
> we agreed the following text:
>  WHEREAS, the Board of Directors deems it to be in the best
>  interests of the Foundation and consistent with the Foundation's
>  purpose to establish a Project Management Committee charged with
>  the creation and maintenance of open-source software for
>  distribution at no charge to the public, that simplifies the
>  development, deployment and management of distributed applications
>  built as compositions of service components.  These components
>  may be implemented with a range of technologies and connected
>  using a variety of communication protocols.  This software will
>  implement relevant open standards including, but not limited to,
>  the SCA standard defined by the OASIS OpenCSA member section,
>  and related technologies.
>
> Because of this problem, I wish to rescind my earlier +1 vote.
> Am I allowed to do this under Apache voting rules?  I'd also
> like to request that this vo

[jira] Created: (TUSCANY-2281) How to create ServiceReferences for references using multiplicity="1..n"

2008-04-30 Thread Daniel Stucky (JIRA)
How to create ServiceReferences for references using multiplicity="1..n"


 Key: TUSCANY-2281
 URL: https://issues.apache.org/jira/browse/TUSCANY-2281
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.2
Reporter: Daniel Stucky


At the moment it is not possible to create ServiceReferences for specific 
targets of references with multiplicity="1..n". 
See the mailing list for details: http://www.mail-archive.com/[EMAIL 
PROTECTED]/msg03024.html

A quote from Simon Laws' answer:
"The OASIS TC has proposed a solution to this issue 
(http://www.osoa.org/jira/browse/JAVA-9) but this isn't part of the API we have 
implemented as we have taken the V1 API. Can you raise a JIRA for this as I 
can't see one already and at least in that way we can track it."


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



Re: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread Simon Laws
On Wed, Apr 30, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:

> Bring this comment to the dev list:
>
> "The tuscany web app support doesn't use this evolving node implementation
> just yet. I don't imagine it would be difficult to plug it in "
>  - http://apache.markmail.org/message/4hvdrcafhapy3kyy
>
> Coincidentally i was having a look at this just the other day after that
> user posted about support for Tomcat with multiple webapps in the same SCA
> domain - http://apache.markmail.org/message/ttssxoruzpndkado.
>
> Could you give any pointers at all on where to start with using this
> evolving node implementation like this? Theres no doc and I'm a bit lost
> on
> even which Tuscany modules, samples or tests are current. What I'd like to
> do is start exploring the updating of the old runtime-tomcat code to use
> the
> latest domain stuff so that as Tomcat starts up webapps are detected as
> SCA
> contributions and added to a single Tomcat SCA domain. One issue that I
> remember came up last time doing this is that as this happens during
> Tomcat
> startup no http communication can take place so all the registrations of
> contributions with the domain need to be in-vm.
>
>   ...ant
>

Hi Ant

Am keen to work with you on this. While svn has been down I've spent time to
resurrect a load balancing demo I have on my local disc (not checked in yet)
and would like to update the webapps I'm using to the lasted domain code but
of course I can't.

Here's a summary of what I think is current in terms of domain/node/runtime
support (but have to admit that there is an amount of guessing here).

sca/distribution/standalone - not sure but think it's redundant - forerunner
of runtime-standalone?
sca/distribution/tomcat - not sure but think it's redundant - forerunner of
runtime-tomcat?
sca/distribution/war - not sure but think it's redundant - forerunner of
runtime-war?
sca/distribution/webapp - not sure but think it's redundant
sca/modules/domain - old domain SPI
sca/modules/domain-api - old domain API
sca/modules/domain-impl - old domain Implementation - has been superseded by
domain-manager
sca/modules/domain-manager - new domain management application - replaces
domain-impl
sca/modules/host-embedded - original single JVM domain implementation -
still used in most samples
sca/modules/host-webapp - original webapp runtime - fires up tuscany based
on web.xml filter
sca/modules/host-webapp-junit - not sure but have a feeling it's something
to do with running itests in different web containers
sca/modules/node - old node SPI
sca/modules/node-api - old node API
sca/modules/node-impl - old node implementation that runs one or more
composites in a single JVM as part of a distributed domain
sca/modules/node2-api - new node API
sca/modules/node2-impl - new node implementation. This node is coded to read
it's configuration as an atom feed from the new domain-manager
sca/modules/node2-launcher - start up a node from the command line
sca/modules/node2-launcher-webapp - had noticed this before - maybe node2
integration with webapps has been looked at. Let's see!
sca/modules/runtime - I think this was the last attempt at providing a
common runtime baseline to be specialized for different environments
sca/modules/runtime-standalone - command line runtime
sca/modules/runtime-tomcat - deep tomcat integration (IIRC)
sca/modules/runtime-war - war rutime
sca/modules/workspace - SPI for some of the machinery required to process
contributions at the domain level. Used by domain-manager
sca/modules/workspace-impl - Implementation of the workspace
sca/modules/workspace-xml - Reading/writing workspace as XML

So can we get together here and work out what the true picture is and how to
mode modules/runtime* to node2. First things first I'm going to go look at
node2-launcher-webapp.

I think the start up process for nodes in a webapp will potentially be
easier now as the node is just reading atom feeds and not making soap calls.
Time will tell!

Simon


Re: [VOTE] Graduate Apache Tuscany as a Top Level Project

2008-04-30 Thread Simon Nash

ant elder wrote:

We've done a lot of work since last October. We now have a diverse community
of contributors and have demonstrated the ability to attract new committers
to create an even more diverse community, we have shown we can do releases
based on Apache guidelines, and we have shown we conduct our discussions in
public within full view of the community and can resolve disagreements on
the lists. I think we're ready, so please vote on the proposal below to
graduate Tuscany to a TLP.

+1 from me.

   ...ant

X. Establish the Apache Tuscany Project

WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the Foundation's
purpose to establish a Project Management Committee charged with
the creation and maintenance of open-source software that
simplifies the development and deployment of service oriented
applications and provides a managed service-oriented runtime
based on the standards defined by the OASIS OpenCSA group,
for distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Apache Tuscany Project",
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby is
responsible for the creation and maintenance of software
related to Apache Tuscany;
and be it further

RESOLVED, that the office of "Vice President, Apache Tuscany" be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Tuscany Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Tuscany Project; and be it further

RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Tuscany Project:

   - Adriano Crestani 
   - ant elder 
   - Brady Johnson 
   - Frank Budinsky 
   - Ignacio Silva-Lepe 
   - Jean-Sebastien Delfino 
   - kelvin goodson 
   - Luciano Resende 
   - Mark Combellack 
   - Matthieu Riou 
   - Mike Edwards 
   - Paul Fremantle 
   - Pete Robbins 
   - Raymond Feng 
   - Simon Laws 
   - Simon Nash 
   - Venkata Krishnan 

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
be appointed to the office of Vice President, Apache Tuscany, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further

RESOLVED, that the Apache Tuscany Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Tuscany podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Tuscany podling encumbered upon the Apache Incubator
Project are hereafter discharged.


My sincere apologies.  This version of the charter is not correct,
and I failed to notice the problem when casting my +1 vote.

The first paragraph says:
 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the Foundation's
 purpose to establish a Project Management Committee charged with
 the creation and maintenance of open-source software that
 simplifies the development and deployment of service oriented
 applications and provides a managed service-oriented runtime
 based on the standards defined by the OASIS OpenCSA group,
 for distribution at no charge to the public.

In our most recent vote (see [1]) on the wording of this paragraph,
we agreed the following text:
 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the Foundation's
 purpose to establish a Project Management Committee charged with
 the creation and maintenance of open-source software for
 distribution at no charge to the public, that simplifies the
 development, deployment and management of distributed applications
 built as compositions of service components.  These components
 may be implemented with a range of technologies and connected
 using a variety of communication protocols.  This software will
 implement relevant open standards including, but not limited to,
 the SCA standard defined by the OASIS OpenCSA member section,
 and related technologies.

Because of this problem, I wish to rescind my earlier +1 vote.
Am I allowed to do this under Apache voting rules?  I'd also
like to request that this vote be restarted with the second
version of this paragraph substituted for the first version.

  Simon

[1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200803.mbox/[EMAIL 
PROTECTED]


Fwd: Is there are simple straightforward way of creating a Compoisite

2008-04-30 Thread ant elder
Bring this comment to the dev list:

"The tuscany web app support doesn't use this evolving node implementation
just yet. I don't imagine it would be difficult to plug it in "
  - http://apache.markmail.org/message/4hvdrcafhapy3kyy

Coincidentally i was having a look at this just the other day after that
user posted about support for Tomcat with multiple webapps in the same SCA
domain - http://apache.markmail.org/message/ttssxoruzpndkado.

Could you give any pointers at all on where to start with using this
evolving node implementation like this? Theres no doc and I'm a bit lost on
even which Tuscany modules, samples or tests are current. What I'd like to
do is start exploring the updating of the old runtime-tomcat code to use the
latest domain stuff so that as Tomcat starts up webapps are detected as SCA
contributions and added to a single Tomcat SCA domain. One issue that I
remember came up last time doing this is that as this happens during Tomcat
startup no http communication can take place so all the registrations of
contributions with the domain need to be in-vm.

   ...ant


[jira] Created: (TUSCANY-2280) No data transformation for fault types

2008-04-30 Thread Cezary Wisniewski (JIRA)
No data transformation for fault types
--

 Key: TUSCANY-2280
 URL: https://issues.apache.org/jira/browse/TUSCANY-2280
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.1, Java-SCA-1.2
Reporter: Cezary Wisniewski
 Fix For: Java-SCA-1.2, Java-SCA-1.1


DataTransformationInterceptor is not added to the InvocationChain when method 
has no parameters and no return type e.g.

void someMethod() throws MyException

DataTransformationInterceptor should be added to the chain because the 
exception has to be transformed. DataTransformationInterceptor is added to the 
chain and exception is transformed when the method has at least one parameter 
or return type e.g.

MyStruct someMethod() throws MyExcpetions
or
void someMethod(MyStruct param) throws MyException

The reason for such behavior is that DataBindingRuntimeWireProcessor only takes 
care of parameters and return types and ignores fault types (see 
DataBindingRuntimeWireProcessor.isTransformationRequired(Operation, Operation)


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



[jira] Updated: (TUSCANY-2279) itest/osgi-tuscany broken (policy-ws missing)

2008-04-30 Thread Graham Charters (JIRA)

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

Graham Charters updated TUSCANY-2279:
-

Attachment: Jira-2279-policy-ws-missing.patch

The following add tuscany-policy-security-ws to the extensions dependencies 
fixing the problem with the bundles created in itest/osgi-tuscany.

> itest/osgi-tuscany broken (policy-ws missing)
> -
>
> Key: TUSCANY-2279
> URL: https://issues.apache.org/jira/browse/TUSCANY-2279
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA OSGi Integration
>Affects Versions: Java-SCA-Next
> Environment: All
>Reporter: Graham Charters
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: Jira-2279-policy-ws-missing.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Looks like there's a new policy-ws module which has not been added to 
> itest/osgi-tuscany so the dependency is missing, which results in the package 
> not being available.
> I have a fix which I will attach shortly.

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



[jira] Created: (TUSCANY-2279) itest/osgi-tuscany broken (policy-ws missing)

2008-04-30 Thread Graham Charters (JIRA)
itest/osgi-tuscany broken (policy-ws missing)
-

 Key: TUSCANY-2279
 URL: https://issues.apache.org/jira/browse/TUSCANY-2279
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA OSGi Integration
Affects Versions: Java-SCA-Next
 Environment: All
Reporter: Graham Charters
Priority: Minor
 Fix For: Java-SCA-Next


Looks like there's a new policy-ws module which has not been added to 
itest/osgi-tuscany so the dependency is missing, which results in the package 
not being available.

I have a fix which I will attach shortly.

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



Re: Improving support for running in OSGi

2008-04-30 Thread Simon Nash

Yang Lei wrote:

I think enabling OSGI can help modularity with a clear definition of
package visibility, so we can have a much cleaner "module"
dependencies through osgi bundle import/export on package.   I think
it will help Tuscany adopters a lot in the scenarios such as: when
implementing new implementation type, binding type, or data binding
types, there is clear indication which set of packages can be used
(exported API/SPI ). So upgrading to new Tuscany level can be as
simple as plug and play if there is no API/SPI changes, and  version
control (multiple version co-existence) can also be made available
through OSGI capabilities.


+1 for the benefits to modularity.  For versioning, I see the value
more in terms of allowing multiple versions of third-party dependencies
to coexist, rather than having multiple versions of some parts of
Tuscany loaded at the same time.  Are there any scenarios that would
require the latter?

  Simon


Regards,

Yang

On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT)
<[EMAIL PROTECTED]> wrote:

Hi,


I'd like to get people's thoughts on whether the idea of 'promoting'
OSGi is a good one,

IMHO support of OSGi is very important and I glad to see increasing interest of 
the community here.


and get ideas on how best to proceed.

I personally have currently not a very deep insight into implementation details 
yet, but we are currently prototyping and have there also OSGi services.
What I could offer today is only to feed our findings about limitations and 
rooms for improvement back.
Another important thing which I see on the horizon, is the ongoing 
standardization of Distributed OSGi (RFC119) and the benefit to support that 
standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to keep 
an eye on that as well.

Regards,
Philipp

-Ursprüngliche Nachricht-
Von: Graham Charters [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 28. April 2008 09:48
An: tuscany-dev@ws.apache.org
Betreff: Improving support for running in OSGi


Hi All,

I'd like to get more involved in the OSGi support in Tuscany (both the
modularity work (itest/osgi-tuscany) and the implementation.osgi).  I
recently started looking at the work to run Tuscany in OSGi, embodied
in itest/osgi-tuscany and described in the thread entitled
"Classloading in Tuscany".  I've noticed a couple of others on the
list also interested in Tuscany running in OSGi and wondered if it
might be worth considering making this a "first-class" option.  At the
moment the five bundles are only built by folks who want the OSGi
support and go into the itest/osgi-tuscany directory to create it.
This can result in any problems being discovered late, but also could
create the impression that OSGi is considered a second-class
environment (which I don't believe is the case).

Aside from the obvious benefits to OSGi users in doing this, I think
there's a potential for Tuscany to use the OSGi build as a test-bed
for highlighting and working through modularity issues, which would
also benefit Tuscany in general, not just in an OSGi runtime.

I'd like to get people's thoughts on whether the idea of 'promoting'
OSGi is a good one, and get ideas on how best to proceed.  We could
then start discussing what some of the issues might be (e.g. size of
builds, time to build, etc...).

Regards,

Graham.